• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 100 subscribers
  • Views 1424 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM1808 emac Driver Becomes Unresponsive

Todd Cowling
Prodigy 150 points
Other Parts Discussed in Thread: AM1808

When testing the ethernet interface at the University of New Hampshire Ethernet InterOperability labs we encounter an error in the davinci_emac.c driver where the corresponding interface no longer sends or recieves traffic and which also generates the following Backtrace and stack dump:

 

------------[ cut here ]------------

WARNING: at drivers/net/davinci_emac.c:1052 emac_rx_handler+0x10c/0x128()

Modules linked in: ipv6 arb_enc_dsp arb_enc_tc72 arb_enc_status_remote arb_enc_adm1032 arb_enc_aes arb_enc_pic arb_enc_r

Backtrace:

[<c09c271c>] (dump_backtrace+0x0/0x114) from [<c0c88580>] (dump_stack+0x18/0x1c)

 r7:00000000 r6:c0ba3ca4 r5:c0d341cc r4:0000041c

[<c0c88568>] (dump_stack+0x0/0x1c) from [<c09d2140>] (warn_slowpath_common+0x54/0x6c)

[<c09d20ec>] (warn_slowpath_common+0x0/0x6c) from [<c09d217c>] (warn_slowpath_null+0x24/0x2c)

 r9:000000ec r8:0000003c r7:c78c9b00 r6:c78583c0 r5:c071d6c0

r4:c78c9800

[<c09d2158>] (warn_slowpath_null+0x0/0x2c) from [<c0ba3ca4>] (emac_rx_handler+0x10c/0x128)

[<c0ba3b98>] (emac_rx_handler+0x0/0x128) from [<c0ba4964>] (__cpdma_chan_free+0xc8/0xcc)

 r8:0000003c r7:10000000 r6:c59ca500 r5:c59a1c00 r4:60000013

[<c0ba489c>] (__cpdma_chan_free+0x0/0xcc) from [<c0ba4aa4>] (__cpdma_chan_process+0x13c/0x174)

[<c0ba4968>] (__cpdma_chan_process+0x0/0x174) from [<c0ba4b0c>] (cpdma_chan_process+0x30/0x50)

 r9:000000ec r8:c78c9b0c r7:c78c9800 r6:00000040 r5:c59ca500

r4:0000003f

[<c0ba4adc>] (cpdma_chan_process+0x0/0x50) from [<c0ba39a8>] (emac_poll+0x6c/0x200)

 r7:c78c9800 r6:00000040 r5:00010001 r4:c78c9b00

[<c0ba393c>] (emac_poll+0x0/0x200) from [<c0bfdbcc>] (net_rx_action+0xb4/0x208)

[<c0bfdb18>] (net_rx_action+0x0/0x208) from [<c09d7d90>] (__do_softirq+0x88/0x118)

[<c09d7d08>] (__do_softirq+0x0/0x118) from [<c09d7e6c>] (irq_exit+0x4c/0xb0)

[<c09d7e20>] (irq_exit+0x0/0xb0) from [<c09be080>] (asm_do_IRQ+0x80/0xa0)

[<c09be000>] (asm_do_IRQ+0x0/0xa0) from [<c09beb8c>] (__irq_svc+0x4c/0x9c)

Exception stack(0xc0543d60 to 0xc0543da8)

3d60: 00000000 0000013e 00000000 00000000 c0e8c900 c743f2f8 c06fc380 000000ba

3d80: 0013d4ec 00000000 00000000 c0543dec c061b480 c0543da8 c0a0b93c c0a0c5f8

3da0: 80000013 ffffffff

 r5:febfd000 r4:ffffffff

[<c0a0c304>] (filemap_fault+0x0/0x458) from [<c0a22904>] (__do_fault+0x54/0x42c)

[<c0a228b0>] (__do_fault+0x0/0x42c) from [<c0a23db0>] (handle_mm_fault+0x358/0x7f8)

[<c0a23a58>] (handle_mm_fault+0x0/0x7f8) from [<c09c4470>] (do_page_fault+0xe8/0x1dc)

[<c09c4388>] (do_page_fault+0x0/0x1dc) from [<c09c45f8>] (do_translation_fault+0x24/0xac)

[<c09c45d4>] (do_translation_fault+0x0/0xac) from [<c09be250>] (do_PrefetchAbort+0x3c/0x9c)

 r7:c0543fb0 r6:00000005 r5:00000000 r4:c0d69e3c

[<c09be214>] (do_PrefetchAbort+0x0/0x9c) from [<c09bef04>] (ret_from_exception+0x0/0x10)

Exception stack(0xc0543fb0 to 0xc0543ff8)

3fa0:                                     000a5f38 0000001b 00000008 00000001

3fc0: 00000000 00000000 000a5f80 00000000 0000001b 00000000 000a6088 000a6b20

3fe0: 000a6088 bef14a18 4035ef88 4035f45c 20000010 ffffffff

 r8:0000001b r7:00000000 r6:000a5f80 r5:00000000 r4:ffffffff

---[ end trace 5fc4827a59ec57ac ]---

 

 

This occurs when the interface is subjected to ARP requests for its IP at about 5% of capacity.  Is anyone aware of this issue and how can the issue be resolved.

  • 0
    Intellectual 710 points

    Todd,

    Since the path to your driver is drivers/net/davinci_emac.c I assume that your are using an older kernel version, the driver has been moved to drivers/net/ethernet/ti/davinci_emac.c in newer versions. Current kernel versions include a few fixes for the davinci emac:

    net/davinci: do not use all descriptors for tx packets
    commit 86d8c07ff2448eb4e860e50f34ef6ee78e45c40c
    Author: Sascha Hauer s.hauer@pengutronix.de

    davinci_emac: Do not free all rx dma descriptors during init
    commit 5d69703263d588dbb03f4e57091afd8942d96e6d
    Author: Christian Riesch christian.riesch@omicron.at

    davinci_mdio: Fix MDIO timeout check
    commit 5b76d0600b2b08eef77f8e9226938b7b6bde3099
    Author: Christian Riesch christian.riesch@omicron.at

    Without these patches I experienced similar problems. Could you please try again with the current mainline kernel? I would like to hear about your results. Could you please also post some more details how to reproduce this problem? I would like to try this with my board. Thanks!

    Hope that helps! Regards, Christian

  • 0 in reply to Christian Riesch
    Prodigy 150 points

    Christian,

    We have upgraded to the latest sdk (version 05.05) and the issue continues to exist.  An applications engineer within TI has also replicated the issue with the latest sdk and has escalated the issue to get the kernel team involved.

    I am going to post the details to replicate the issue a little later.

    Todd

  • 0 in reply to Todd Cowling
    Intellectual 710 points
    Hi Todd,
    Todd Cowling said:

    Christian,

    We have upgraded to the latest sdk (version 05.05) and the issue continues to exist.

    I just downloaded sdk 05.05, the kernel that is included is 2.6.37 (from January 2011) and does not include the patches that I mentioned above. I recommend to try this again with a current mainline kernel (e.g. 3.5) from kernel.org, or you could backport the patches to the sdk kernel.
    An applications engineer within TI has also replicated the issue with the latest sdk and has escalated the issue to get the kernel team involved.

    I am going to post the details to replicate the issue a little later.

    Todd

    I am looking forward to getting your instructions, I'll give it a try on my hardware ;-) Regards, Christian
  • 0 in reply to Christian Riesch
    Prodigy 150 points

    Christian,

    The Ethernet driver "lockup" was duplicated by capturing a single ARP request broadcast for the device under test (DUT)in Wireshark, then replaying it with no inter request delay in an infinite loop. The setup was a Linux desktop configured with eth1 as the interface to the test subnet, a single 5-port switch OR direct link with a crossover cable to the DUT. All tests were run on the Linux desktop, sending on the test subnet, except for pings to test the current state of communications between the DUT and the desktop.


    We used the bittwist tool (Bit-Twist from http://bittwist.sourceforge.net/ ) to replay the ARP request capture using the following options: -i eth1 -m 0 -r 100 -l 0

    Indicating to use the eth1 interface, set the interval multiplier to zero (i.e. no interval between replays), the rate to 100Mbps and loop forever.

    Todd

  • 0 in reply to Todd Cowling
    Intellectual 710 points
    Todd, I haven't got time for more testing now, but I could do a short test and I am now pretty sure that this problem is fixed by one of the three patches that I mentioned above. With the AM1808 experimenter's kit from LogicPD and the kernel from sdk 05.05 I could reproduce what you have described. However, with a newer kernel (all three patches applied; but tested on a custom board, not on the experimenter's kit) I don't get these messages and the network interface was still working. Regards, Christian
  • 0 in reply to Christian Riesch
    TI__Genius 13505 points

    Hi Christian,

    I'm impressed you've been able to fix the problem with a kernel update.  I've attempted a few hacks on the 2.6.37 kernel driver that came close to fixing the issue, but the driver still died at the application level. 

    I've not attempted updating the kernel myself- could I trouble you for some hints to duplicate this?

     

  • 0 in reply to Michael Erdahl
    Intellectual 710 points

    Hi Michael,

    I have just uploaded a configuration for the AM1808 experimenter's kit and Kernel 3.6-rc5 to the Files section of my account in this forum, so you could try this:

    Get the kernel source of 3.6-rc5, e.g. with git:

    git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux

    Checkout v3.6-rc5

    git checkout v3.6-rc5

    Get the da850evm.cfg file from the Files section of my account here, copy it to the linux directory, rename it to ".config", and compile

    make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage

    and boot linux/arch/arm/boot/uImage on the board. This kernel should contain the fixes for the network driver.

    Hope that helps! Regards, Christian

  • 0 in reply to Christian Riesch
    TI__Genius 13505 points

    Thanks Christian, that worked! 

  • 0 in reply to Christian Riesch
    Intellectual 295 points

    Hi Christian,

    I finally got a chance to try this and I got the project to build but the system console stops working after uncompressing LINUX

    U-Boot > run TFTP_bootcmd
    Using DaVinci-EMAC device
    TFTP from server 192.168.0.1; our IP address is 192.168.0.7
    Filename 'uImage-am1808evm'.
    Load address: 0xc0700000
    Loading: #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    ###############################################
    done
    Bytes transferred = 12137328 (b93370 hex)
    ## Booting kernel from Legacy Image at c0700000 ...
    Image Name: Linux-3.6.0
    Image Type: ARM Linux Kernel Image (uncompressed)
    Data Size: 12137264 Bytes = 11.6 MiB
    Load Address: c0008000
    Entry Point: c0008000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
    OK

    Starting kernel ...

    Uncompressing Linux... done, booting the kernel.

    I looked into the change from ttyS0 to ttyO0 but that didn't fix it either.

    Are you using UART1 (ttyS0) for the getty console?

    Until I can get the console working I don't know if it will be possible to get any further.

  • 0 in reply to Mellissa Dalby
    Intellectual 710 points
    Mellissa Dalby said:

    I looked into the change from ttyS0 to ttyO0 but that didn't fix it either.

    Are you using UART1 (ttyS0) for the getty console?

    Until I can get the console working I don't know if it will be possible to get any further.

    Hi Mellissa, IIRC UART1 is ttyS1, not ttyS0. The kernel configuration that I uploaded is for the experimenter's kit from Logicpd. It uses ttyS2 (UART2) as console. Regards, Christian