Hi, I am running 2.6.24.7 with either -rt11 or -rt12 on a MPC5200B custom board. If /home is mounted via NFS with -o nolock and I execute > dd if=/dev/zero of=/home/danielsch/uhu bs=1024 count=200000 The following happens: [ 126.164933] net eth0: transmit queue overrun [ 126.169331] net eth0: transmit queue overrun [ 126.173737] net eth0: transmit queue overrun [ 126.178147] net eth0: transmit queue overrun [ 126.182589] net eth0: transmit queue overrun [ 126.187035] net eth0: transmit queue overrun [ 126.191440] net eth0: transmit queue overrun [ 126.195857] net eth0: transmit queue overrun [ 126.200264] net eth0: transmit queue overrun [ 126.204677] net eth0: transmit queue overrun [ 131.164733] printk: 1502017 messages suppressed. [ 131.169468] net eth0: transmit queue overrun [ 136.164732] printk: 1513122 messages suppressed. [ 136.169467] net eth0: transmit queue overrun [ 141.164731] printk: 1513112 messages suppressed. [ 141.169492] net eth0: transmit queue overrun [ 146.164732] printk: 1513094 messages suppressed. [ 146.169467] net eth0: transmit queue overrun [ 151.164732] printk: 1513107 messages suppressed. ... Etc. I can not stop dd via Ctrl-C, the target is not reachable via ping, although the last messages will repeat endlessly, so something still works. It looks like an endless loop in the kernel (look at the printk suppression numbers) and maybe the MPC5200B bestcomm task is stuck. This doesn't happen with either stock 2.6.24.7 or 2.6.24-rt1. I have not tested any kernels in between. Also it seems to be specific to the network layer, as writing on CF card or other stress acitivities do not show any problems. Can anybody with the same architecture reproduce this problem ? Any idea on how to debug it ? See attachment for my kernel config. Best regards, Daniel Schnell. P.S. BTW, latency wise -rt11 and above are big steps forward.
Attachment:
linuxconfig.gz
Description: linuxconfig.gz
