Bugzilla – Bug 12772
Ethernet link goes down during boot, needs reboot to fix
Last modified: 2009-10-09 10:52:31 UTC
I've noticed a few times (twice over about 100 or more reboots) when I reboot baby (using a wired connection) (possibly when I type 'reboot' not sure), it boots up with link down. Disconnecting and reconnecting the cable has no effect. Rebooting fixes the problem. This was with fw r6491. Not sure what the bug target should be.... Here' a dmesg snippet, showing when it goes up, then later down. mice: PS/2 mouse device common for all mice MXC keypad loaded input: mxckpd as /class/input/input0 eth0: status: link up, 100MBit Full Duplex, auto-negotiation complete. eth0: enable RMII gasket MXC WatchDog Driver 2.0 MXC Watchdog # 0 Timer: initial timeout 60 sec input: Unspecified device as /class/input/input1 input: msp430 as /class/input/input2 firmware: requesting msp430.txt i.MX ADC at 0x50030000 irq 46 mxsdhci: MXC Secure Digital Host Controller Interface driver mxsdhci: MXC SDHCI Controller Driver. mmc0: SDHCI detect irq 0 irq 9 PIO Advanced Linux Sound Architecture Driver Version 1.0.16. AIC3104 Audio Codec 0.1<6>DMA Sound Buffers Allocated:UseIram=1 buf->addr=78000000 buf->area=c4860000 size=65536 DMA Sound Buffers Allocated:UseIram=1 buf->addr=83d80000 buf->area=fde97000 size=65536 asoc: aic3104-dai <-> imx-ssi-1 mapping ok AIC3104 WRITE 0: 00000000 AIC3104 WRITE 1: 00000080 AIC3104 WRITE 43: 00000080 AIC3104 WRITE 44: 00000080 AIC3104 WRITE 47: 00000080 AIC3104 WRITE 64: 00000080 AIC3104 WRITE 54: 00000080 AIC3104 WRITE 71: 00000080 AIC3104 WRITE 82: 00000080 mmc0: queuing CIS tuple 0x01 length 3 AIC3104 WRITE 92: 00000080 AIC3104 WRITE 86: 00000008 AIC3104 WRITE 93: 00000008 mmc0: queuing CIS tuple 0x1a length 5 AIC3104 WRITE 25: 00000080 mmc0: queuing CIS tuple 0x1b length 8 AIC3104 WRITE 38: 00000020 mmc0: queuing CIS tuple 0x14 length 0 AIC3104 WRITE 40: 00000080 AIC3104 WRITE 51: 0000000d AIC3104 WRITE 65: 00000009 AIC3104 WRITE 14: 00000080 AIC3104 WRITE 13: 00000080 AIC3104 WRITE 15: 00000028 AIC3104 WRITE 16: 00000028 AIC3104 WRITE 17: 000000ff AIC3104 WRITE 18: 000000ff AIC3104 WRITE 19: 00000004 AIC3104 WRITE 22: 00000004 ###### sound/soc/codecs/tlv320aic3104.c:1194 aic3104_dapm_event AIC3104 WRITE 65: 00000008 mmc0: queuing CIS tuple 0x80 length 1 mmc0: queuing CIS tuple 0x81 length 1 mmc0: queuing CIS tuple 0x82 length 1 mmc0: new SDIO card at address 0001 AIC3104 WRITE 51: 0000000c ALSA device list: #0: baby (aic3104) oprofile: using timer interrupt. TCP cubic registered NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com> ieee80211_crypt: registered algorithm 'NULL' VFS: Mounted root (cramfs filesystem) readonly. Freeing init memory: 128K UBIFS: recovery needed UBIFS: recovery completed UBIFS: mounted UBI device 0, volume 2, name "ubifs" UBIFS: file system size: 9418752 bytes (9198 KiB, 8 MiB, 73 LEBs) UBIFS: journal size: 1032193 bytes (1008 KiB, 0 MiB, 6 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: lzo UBIFS: reserved for root: 444870 bytes (434 KiB) msp430: firmware ok (185) AR6000 Reg Code = 0x40000060 eth0: enable RMII gasket eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX. eth0: status: link down. AIC3104 WPAGE 0: 00000001 AIC3104 MSB WRITE 1: 00000058 AIC3104 LSB WRITE 2: 0000001b AIC3104 MSB WRITE 27: 000000fe AIC3104 LSB WRITE 28: 00000030 AIC3104 MSB WRITE 3: 000000a7 AIC3104 LSB WRITE 4: 000000e5
Can qa automate this test somehow, and see how often ethernet fails. I'm marking as MP target for now, but maybe it's really a PLD bug.
Bump. Is this being looked at by QA?
QA has not looked at this yet, if some one can help us with a perl script that can do the testing that would be nice.
Tom are you just looking for a percentage from QA or something else? I'm not sure what benefit an automated test script would be for this.
(In reply to comment #4) > Tom are you just looking for a percentage from QA or something else? I'm not > sure what benefit an automated test script would be for this. Richard in comment #1 wanted to get a better sense of the frequency, I think. So far, only I have complained about it, seeing it twice over probably 150 restarts.
Reset priority before triage.
Testing r6865. Not sure if this is the same bug or a different bug, but... Tried setting up a wired connection. Directly after selecting "Connect to ethernet network" I yanked the ethernet cable from the router. Baby spun on "Connecting to Ethernet" for a long while before finally declaring there was no DHCP server found. But there's more... While watching that DHCP error Baby rebooted itself, got as far as "Free your Music" then rebooted itself again. The point being the reboot here. (I'll file a separate bug for the inappropriate error.)
This sounds like bug 13021 maybe related
I had Ryan reboot a PVT unit (latest build) 50 times last Friday and he didn't note this problem. He noted that sometimes during the boot process the unit didn't respond to ping, but recovered. This bug continues to worry me greatly, and I am communicating with Suzhou on additional testing, but I can't quite bring myself to slam on the brakes for the whole project for it.
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.