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
-----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
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
-----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
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
l4-hackers@os.inf.tu-dresden.de