This list is intended for discussions about the L4 microkernel family and software running on top of L4. ()

headers Björn Döbel | 1 Mar 18:33

Hi,

bad news: it works for me on my e1000 test machine and on Qemu.

Can you try to run your setup in Qemu (-net nic,model=e1000,vlan=0 -net
tap,vlan=0)?

 Bjoern

Hi,

Björn Döbel wrote:
> 
> bad news: it works for me on my e1000 test machine and on Qemu.
> 

I'm sure it does as my binary ORe module works with another e1000 series
network card. It don't work with only one particular NIC type 8086:1076
(VendorID:DeviceID).

good news: I manage to get it running. It looks like problem was due to bug
in DDE library.

let's look at function ioremap() in file
/l4/pkg/dde/linux26/lib/src/arch/l4/res.c (revision 433):

void __iomem * ioremap(unsigned long phys_addr, unsigned long size)
{
	struct list_head *pos, *head;
	head = &dde_mem_regions;

	list_for_each(pos, head) {
		struct dde_mem_region *mreg = list_entry(pos, struct dde_mem_region,
		                                         list);
		if (mreg->pa >= phys_addr && mreg->pa + mreg->size > phys_addr)
			return (void *)(mreg->va + (phys_addr - mreg->pa));
	}

Hi,

> good news: I manage to get it running. It looks like problem was due to bug
> in DDE library.

Ack. Patch applied. Thanks for finding this.

Bjoern

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)

Hi,

I'm trying to run L4Linux with ORe. I can successfully run L4Linux without
ORe and can run ORe without L4Linux (arping works). But when I try to run
L4Linux with ORe, boot process hangs up after message from stub driver:

eth0: Overwriting IRQ type for IRQ 10 with l4ore type!
eth0: request_irq(10, ...)
l4lx    | l4x_ore_irq_startup
l4lx    | l4lx_thread_create: Created thread 10.0b (L4OreRcv)
eth0: interface up.

After some time a following message (with some additional info - see it in a
boot log given at the end of letter) appears:

BUG: soft lockup - CPU#0 stuck for 61s! [pump:92]

I guess it caused by the ORe stub driver but it's only guess.
What could it be? What could I try to do?

Here is my 'L4Linux cfg file' and 'boot log':

L4Linux cfg file:

task "vmlinuz4" "earlyprintk=yes mem=64M load_ramdisk=1 ramdisk_size=16384
root=/dev/ram l4env_rd=drops.rd"
  all_sects_writable
  allow_vga
  allow_cli

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.

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 <at> 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-tp22309613p22325327.html
Sent from the L4 mailing list archive at Nabble.com.

_______________________________________________
l4-hackers mailing list

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 <at> 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,

I'll try to reproduce this, but this will probably take some time. :/

Bjoern

Hi,

When ORe stub driver initializes virtual interface in l4x_ore_init_device()
function, It tries to allocate hardware MAC address for all devices EXCEPT
"lo" device:

if (strcmp(devname, "lo"))
	priv->config.ro_keep_device_mac = 1;
else
	priv->config.ro_keep_device_mac = 0;

Here if devname=="lo" then strcmp() returns 0 and we tries to get virtual
MAC for "lo".
Is it intended behavior?
Why do we need HW MAC for HW NIC and virtual one for "lo"?
How in this case several Linux instances will use the same HW MAC?

Best Regards, Alexander Valitov
--

-- 
View this message in context: http://www.nabble.com/Question-about-ORs-stub-driver-behavior-tp22326115p22326115.html
Sent from the L4 mailing list archive at Nabble.com.

10	February 2012
24	January 2012
23	December 2011
42	November 2011
60	October 2011
46	September 2011
39	August 2011
44	July 2011
52	June 2011
45	May 2011
31	April 2011
47	March 2011
71	February 2011
61	January 2011
21	December 2010
66	November 2010
6	October 2010
16	September 2010
28	August 2010
1	July 2010
10	June 2010
15	May 2010
30	April 2010
14	March 2010
15	February 2010
26	January 2010
20	December 2009
16	November 2009
25	October 2009
18	September 2009
27	August 2009
29	July 2009
21	June 2009
15	May 2009
96	April 2009
84	March 2009
49	February 2009
24	January 2009
25	December 2008
29	November 2008
66	October 2008
19	September 2008
13	August 2008
20	July 2008
35	June 2008
49	May 2008
37	April 2008
74	March 2008
17	February 2008
99	January 2008
17	December 2007
34	November 2007
39	October 2007
110	September 2007
79	August 2007
123	July 2007
73	June 2007
79	May 2007
52	April 2007
60	March 2007
29	February 2007
47	January 2007
80	December 2006
63	November 2006
49	October 2006
38	September 2006
113	August 2006
35	July 2006
68	June 2006
75	May 2006
39	April 2006
44	March 2006
20	February 2006
52	January 2006
27	December 2005
54	November 2005
70	October 2005
77	September 2005
74	August 2005
114	July 2005
182	June 2005
76	May 2005
26	April 2005
83	March 2005
105	February 2005
24	January 2005
13	December 2004
18	November 2004
27	October 2004
38	September 2004
8	August 2004
6	July 2004
10	June 2004
11	May 2004
1	March 2004
10	February 2004
27	January 2004

Re: Problem with starting ORe

Re: Problem with starting ORe

Re: Problem with starting ORe

Possible bug in e1000 driver from ORe package

Problem with L4Linux ORe stub driver

Re: Possible bug in e1000 driver from ORe package

Re: Possible bug in e1000 driver from ORe package

Re: Possible bug in e1000 driver from ORe package

Re: Problem with L4Linux ORe stub driver

Question about ORs stub driver behavior

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31