linux 2.6.22.6 network problem - Beacon EmbeddedWorks

Create Account

Create Account

You are here: >> >> >>

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

Forums
Search Forum
Advanced SearchTopicsPosts

Prev Go to previous topic

Go to next topic

Last Post 10 Sep 2008 08:32 AM by hrhaan

linux 2.6.22.6 network problem

11 Replies

Sort:


You are not authorized to post a reply.

Author

Messages

tombrus

New Member
Posts:

19 Mar 2008 09:11 AM
Hi, I got 2.6.22.6 booting now, but the network chip does not respond as expected. Anybody any hints (should I switch on the irqpoll option? how?): Quote: eth0: SMSC911x/921x identified at 0xc4a00000, IRQ: 90 eth0: SMSC911x MAC Address: 00:08:ee:01:7c:03 eth0: link down IP-Config: Complete: device=eth0, addr=192.168.3.250, mask=255.255.255.0, gw=192.168.3.1, host=192.168.3.250, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=192.168.3.85, rootpath= Looking up port of RPC 100003/2 on 192.168.3.85 irq 90: nobody cared (try booting with the "irqpoll" option) [<c0029d58>] (dump_stack+0x0/0x14) from [<c006a1b8>] (__report_bad_irq+0x3c/0x8c) [<c006a17c>] (__report_bad_irq+0x0/0x8c) from [<c006a490>] (note_interrupt+0x288/0x2dc) r4:00000000 [<c006a208>] (note_interrupt+0x0/0x2dc) from [<c006b240>] (handle_edge_irq+0x160/0x1b4) [<c006b0e0>] (handle_edge_irq+0x0/0x1b4) from [<c0038070>] (mxc_gpio_irq_handler+0x90/0xb0) r7:0000005a r6:c0341290 r5:00000000 r4:c006b0e0 [<c0037fe0>] (mxc_gpio_irq_handler+0x0/0xb0) from [<c0025048>] (__exception_text_start+0x48/0x64) r8:00000001 r7:00000002 r6:00000000 r5:c0340ad8 r4:00000034 [<c0025000>] (__exception_text_start+0x0/0x64) from [<c0025aa4>] (__irq_svc+0x44/0x80) Exception stack(0xc0337f40 to 0xc0337f88) 7f40: 00000002 c0336000 c0358510 c0358514 c0336000 c0027064 c0020df8 c037aaf8 7f60: c0027064 4107b364 8001ea54 c0337f94 c0337f70 c0337f88 c002e938 c00270a4 7f80: 20000013 ffffffff r6:00000001 r5:0000ffff r4:ffffffff [<c0027064>] (default_idle+0x0/0x48) from [<c0026ea8>] (cpu_idle+0x30/0x64) [<c0026e78>] (cpu_idle+0x0/0x64) from [<c0285b0c>] (rest_init+0x70/0x80) r5:c0357e84 r4:c0336000 [<c0285a9c>] (rest_init+0x0/0x80) from [<c0008b94>] (start_kernel+0x22c/0x288) r4:c0362688 [<c0008968>] (start_kernel+0x0/0x288) from [<80008030>] (0x80008030) r6:c0339cf4 r5:c035838c r4:00e5387d handlers: [<c016e1c8>] (smsc911x_irqhandler+0x0/0x1f8) Disabling IRQ #90 and digging... -Tom

tombrus

New Member
Posts:

20 Mar 2008 07:58 AM
Edit: remark removed by myself; it was invalid. -Tom.

tombrus

New Member
Posts:

26 Mar 2008 12:49 PM
I hope someone can help me with this issue, I am pretty stuck at the moment... What I found out so far: there are 5 interrupts from the network chip that are handled correctly, the 6th and subsequent thousands of interrupts are not handled correctly. I printk various register values from the ethernet chip. at the first 5 interrupts everything seems fine from interrupt 6 onward the chip seems to be vanished, even the register holding the chip's version number returns bogus values the first 5 interrupts seem to be caused by the initialisation (sending a loopback packet etc). All this is handled according to what the driver expects. at interrupt 6 the kernel tries to contact the NFS server for the boot partition the interrupt routine gets (bogus) 0 values out of the interrupt registers of the network chip and concludes (erroneously) that it is not his interrupt the kernel then concludes (after 1000's of interrupts) that there is something wrong and shuts down the interrupt => no more network The only explanation I can think of is that the mmu tables get garbled after 5 interrupts and that the virtual address that is supposed to be translated to the physical network chips address is translated to somewhere else. To check this theory, I would like some help: how can I translate a virtual address to a physical address? Then I could printk the physical address and check its consistency. how can I dump the mmu translation tables to check if something is damaged? do I understand correctly that the ARM mmu tables are separate (but in parallel with) from the linux tables? Then those could also get out of sync. I can hardly believe that I am the only one with this problem, since I am not doing anything special. The only possibility is that I have some kernel build config setting different from what other people have. Could somebody with a working 2.6.22.6 kernel please mail me his config file (or put it on the list here) so I can compare? It would make me more then happy. Cheers, Tom

ecastelo

New Member
Posts:

28 Mar 2008 06:30 PM
I am using the litekit.config. No modifications I see this issues sometimes. But if restart my system hosting the nfs filesystem, the problem goes aways. Seems to happen only when i hit the reset or power button while the board has linux running. Rico

tombrus

New Member
Posts:

29 Mar 2008 05:41 AM
Thanks for commenting Rico. "Good" to hear that you are experiencing this issue to (at least some of the time). I never ever managed to go past this IRQ 90 issue. Could other people experiencing this problem to (or just see it once) please comment to. Thanks I am currently trying to figure out if it is the board or the software that is failing, Magnus is helping me I keep you all posted on developments... -Tom

lilja.magnus@gmail.com

New Member
Posts:

31 Mar 2008 07:26 AM
Which version of lolo are you all trying with? Originally I had 2.3.x (x =5 I think) installed and was booting 2.6.22-linux without any problems. A couple of days ago I installed Lolo 2.4.0 and after I also got the network problems described in this thread. Switching back to Lolo 2.3.5pl2 makes Linux boot without any "irq 90:"-problems, atleast it booted two times in a row. /Magnus

tombrus

New Member
Posts:

31 Mar 2008 12:54 PM
I am still using the 2.3.5xxx version (I don't know exactly which one, I will report it tomorrow when I have access to the board). I know it is the one before the 2.4.0 version, the version that was originally on the board. This is starting to be a pretty weird problem. You would expect that booting the linux kernel would fully program the network chip and that the exact lolo version *could* have no influence. I am confused. Specially because you have the same problem with lolo 2.4.0 as I have with 2.3.5. I wonder if my board would function properly with 2.4.0 . Maybe some LogicPD people could say something about this.... Maybe there are some hidden features of the board that are not setup by the Linux kernel (actually the network driver) and so the setting that lolo pushes in are maintained (only a vague idea, but maybe it sparks some idea for a LogicPD engineer). -Tom

tombrus

New Member
Posts:

01 Apr 2008 06:25 AM
ok, I am using lolo 2.3.5-IMX31_10 0001. Is this different from 2.3.5p2? I don't know, LogicPD? But the weird thing is that I used mlilja's kernel and bootloader (that he kindly mailed me) to boot my board and, guess what, I still get the same IRQ-90 problem. At the same time this kernel image boots perfectly well on his board. We also compared jumpers and hardware revision numbers: all identical. I am now tempted to believe that the board is flaky. My last resort is to burn lolo 2.3.5p2 on it and see what happens. If that still gives no booting kernel I think I will return the board or demand a replacement. -Tom

tombrus

New Member
Posts:

01 Apr 2008 08:30 AM
I compared the binary image of 2.3.5p2 with a dump of what is on my board (2.3.5-IMX31_10 0001): *they differ.* Of course I do not know the impact of the difference, but these versions of lolo differ that is clear. The 2.3.5-IMX31_10 0001 version can not be downloaded from the download site (http://www.logicpd.com/auth/downloads/i.MX31/), only the p2 version is there. So when I update to 2.3.5p2 I can not go back. I will update anyway, since I got nothing to loose... -Tom

tombrus

New Member
Posts:

01 Apr 2008 08:54 AM
Updated lolo to version 2.3.5p2: still IRQ-90 problems. I am out of options. -Tom

richard.laborde@logicpd.com

Basic Member
Posts:247

01 Apr 2008 09:53 AM
tombrus - The 2.3.5-p2 update has the following in the Release notes: --) Fixed bug where 64MB of RAM was being reported when 128MB RAM was installed --) Added auto detection of 64MB or 128MB RAM. --) Support ethernet chip SMSC9218. Do you know if your kit has Production boards? Send the part number from the SOM into our Ask A Question System and I'll check for you. Thanks

hrhaan

New Member
Posts:

10 Sep 2008 08:32 AM
I had the same sort of network issues an got the network working. See my post in: "Port of LTIB R13 for the PDK (Linux 2.6.24) to MX31 Litekit" viewtopic.php?f=29&t=1573

You are not authorized to post a reply.

Forums Freescale / NXP SOMs and Development Kits i.MX31 LITEKIT Development Kit