Possible bug in e1000 driver from ORe package
Hi, There is possible bug in e1000 driver from ORe package. The heart of the problem is that e1000_probe() function in /trunk/l4/pkg/ore/server/lib26/net/e1000/e1000_main.c file does NOT set 'irq' field in 'net_device' structure (e.g. with assignment netdev->irq = pdev->irq;). Instead it stores pointer to pci_device structure and uses its 'irq' field value (like this adapter->pdev->irq). As a result ORe always outputs message like this one (because it uses netdev->irq value): ore | Device = lo, IRQ = 0, MAC = 00:00:00:00:00:00 ore | Device = eth0, IRQ = 0, MAC = 00:30:18:49:F9:DA ore | Device = eth1, IRQ = 0, MAC = 00:30:18:49:F9:DB And when I try to boot L4Linux with ORe stub driver, the driver fails to init device due to wrong irq number: eth0: Overwriting IRQ type for IRQ 0 with l4ore type! eth0: request_irq(0, ...) EBUSY is returned. Solution is obvious but unfortunately it changes original e1000 Linux driver. That's why I'm not sure that it is proper way to fix the problem. Here is. =================================================================== --- e1000_main.c (revision 433) +++ e1000_main.c (working copy) @@ -931,6 +931,7 @@ } } + netdev->irq = pdev->irq; netdev->open = &e1000_open; netdev->stop = &e1000_close; netdev->hard_start_xmit = &e1000_xmit_frame; Does it make sense? Best regards, Alexander Valitov -- View this message in context: http://www.nabble.com/Possible-bug-in-e1000-driver-from-ORe-package-tp223096... Sent from the L4 mailing list archive at Nabble.com.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
There is possible bug in e1000 driver from ORe package. The heart of the problem is that e1000_probe() function in /trunk/l4/pkg/ore/server/lib26/net/e1000/e1000_main.c file does NOT set 'irq' field in 'net_device' structure (e.g. with assignment netdev->irq = pdev->irq;). Instead it stores pointer to pci_device structure and uses its 'irq' field value (like this adapter->pdev->irq).
As a result ORe always outputs message like this one (because it uses netdev->irq value):
ore | Device = lo, IRQ = 0, MAC = 00:00:00:00:00:00 ore | Device = eth0, IRQ = 0, MAC = 00:30:18:49:F9:DA ore | Device = eth1, IRQ = 0, MAC = 00:30:18:49:F9:DB
And when I try to boot L4Linux with ORe stub driver, the driver fails to init device due to wrong irq number:
eth0: Overwriting IRQ type for IRQ 0 with l4ore type! eth0: request_irq(0, ...)
EBUSY is returned.
Hmm. In this case, this would be a bug in Linux' 2.6.20.19 e1000 driver. Do you know if (and how) this has been fixed in some recent version? If so, a future update will fix this bug and you should use your workaround until then. Cheers, Bjoern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmtVUsACgkQP5ijxgQLUNlM6gCfSvpbs034j27sySLk1AmjD79s BWUAniw4mFZkwaXUkTithMNi1xvYdhja =8CDO -----END PGP SIGNATURE-----
Hi, Björn Döbel wrote:
Hmm. In this case, this would be a bug in Linux' 2.6.20.19 e1000 driver. Do you know if (and how) this has been fixed in some recent version? If so, a future update will fix this bug and you should use your workaround until then.
I’ve performed short investigation. It looks like the issue isn’t fixed in Linux 2.6.28.7 yet. But problem is known. It was reported to driver developers in maillist http://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg00496.html. Unfortunately from mentioned thread it is not clear was the patch accepted by developers or not. So additionally I’ve checked is the patch applied to working kernel branch in git repo. It is not. So there is strong possibility that the patch was rejected. In this case I forced to use my patched version of e1000 driver. Regards, Alexander Valitov -- View this message in context: http://www.nabble.com/Possible-bug-in-e1000-driver-from-ORe-package-tp223096... Sent from the L4 mailing list archive at Nabble.com.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
I’ve performed short investigation. It looks like the issue isn’t fixed in Linux 2.6.28.7 yet. But problem is known. It was reported to driver developers in maillist http://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg00496.html. Unfortunately from mentioned thread it is not clear was the patch accepted by developers or not. So additionally I’ve checked is the patch applied to working kernel branch in git repo. It is not. So there is strong possibility that the patch was rejected. In this case I forced to use my patched version of e1000 driver.
Sure, go ahead and use it. And thanks for pointing this out so that others may use this patch if they bash into this issue. I won't apply this patch to ORe, though, exactly because we don't want to mess with the imported drivers. Cheers, Bjoern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmuRJkACgkQP5ijxgQLUNlHjwCfa/W67T55saD9YB1LboX7XlE4 NO0AmgINm2cB7Xza0Fff8q6VVSfAmjCo =7aTO -----END PGP SIGNATURE-----
Hi, Björn Döbel wrote:
I won't apply this patch to ORe, though, exactly because we don't want to mess with the imported drivers.
I agree. That makes good sense. There is another workaround for the issue. I've just discovered it here http://www.nabble.com/Possible-bug-in-e1000-driver-from-ORe-package-td223096.... If you use it you don't have to change original driver. When you'd like to use ORe from L4Linux with Intel e1000 series NIC you can circumvent the problem with stub driver wrong IRQ requested by giving additional options to L4Linux command line (this cmd line is in .cfg file that you load by grub). Like these one: "l4ore.oredev=DEV l4ore.irqnum=IRQ", where DEV is attached device name discovered by ORe (e.g. lo, eth0, eth1 and so on) and IRQ is irq number assigned by BIOS to this particular DEV (BIOS usually prints irq assignment during boot). E.g. in my case I could add to command line: "l4ore.oredev=eth0 l4ore.irqnum=11" Effectively these options force the stub driver to override device name and irq returned by ORe server with specified one. I didn't try it by myself but judging from ORe stub driver source code it should work. Regards, Alexander Valitov -- View this message in context: http://www.nabble.com/Possible-bug-in-e1000-driver-from-ORe-package-tp223096... Sent from the L4 mailing list archive at Nabble.com.
participants (2)
-
Alexander Valitov -
Björn Döbel