Hi all,

 

Noticed these things in the syslog today, about 2 days after the events. Obviously didn't notice anything but something is happening.

 

I've disabled the onboard NIC as I was having issues with it being a realtek (can't remember which one but I think it is the 8111E) so have a PCI intel Pro 100/1000 NIC running.

 

Is it something I worry about or seeing as I didn't even notice just ignore?

 

Thanks Josh

 

Jul 29 16:37:09 Tower kernel: mdcmd (70): spindown 20 (Routine)
Jul 29 18:22:12 Tower kernel: mdcmd (71): spindown 5 (Routine)
Jul 29 18:23:03 Tower kernel: mdcmd (72): spindown 20 (Routine)
Jul 29 18:53:16 Tower kernel: mdcmd (73): spindown 6 (Routine)
Jul 29 20:05:07 Tower kernel: mdcmd (74): spindown 20 (Routine)
Jul 29 20:42:24 Tower kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang (Network)
Jul 29 20:42:24 Tower kernel:   Tx Queue             <0>
Jul 29 20:42:24 Tower kernel:   TDH                  <dc>
Jul 29 20:42:24 Tower kernel:   TDT                  <c6>
Jul 29 20:42:24 Tower kernel:   next_to_use          <c6>
Jul 29 20:42:24 Tower kernel:   next_to_clean        <da>
Jul 29 20:42:24 Tower kernel: buffer_info[next_to_clean]
Jul 29 20:42:24 Tower kernel:   time_stamp           <2c8bb3a>
Jul 29 20:42:24 Tower kernel:   next_to_watch        <df>
Jul 29 20:42:24 Tower kernel:   jiffies              <2c8bc28>
Jul 29 20:42:24 Tower kernel:   next_to_watch.status <0>
Jul 29 20:42:26 Tower kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang (Network)
Jul 29 20:42:26 Tower kernel:   Tx Queue             <0>
Jul 29 20:42:26 Tower kernel:   TDH                  <dc>
Jul 29 20:42:26 Tower kernel:   TDT                  <c6>
Jul 29 20:42:26 Tower kernel:   next_to_use          <c6>
Jul 29 20:42:26 Tower kernel:   next_to_clean        <da>
Jul 29 20:42:26 Tower kernel: buffer_info[next_to_clean]
Jul 29 20:42:26 Tower kernel:   time_stamp           <2c8bb3a>
Jul 29 20:42:26 Tower kernel:   next_to_watch        <df>
Jul 29 20:42:26 Tower kernel:   jiffies              <2c8bcf0>
Jul 29 20:42:26 Tower kernel:   next_to_watch.status <0>
Jul 29 20:42:28 Tower kernel: ------------[ cut here ]------------
Jul 29 20:42:28 Tower kernel: WARNING: at net/sched/sch_generic.c:261 dev_watchdog+0xff/0x17f() (Minor Issues)
Jul 29 20:42:28 Tower kernel: Hardware name: System Product Name
Jul 29 20:42:28 Tower kernel: NETDEV WATCHDOG: eth0 (e1000): transmit queue 0 timed out (Network)
Jul 29 20:42:28 Tower kernel: Modules linked in: md_mod xor e1000 pata_jmicron jmicron ahci mvsas libsas scst scsi_transport_sas (Drive related)
Jul 29 20:42:28 Tower kernel: Pid: 0, comm: swapper Not tainted 2.6.32.9-unRAID #8 (Errors)
Jul 29 20:42:28 Tower kernel: Call Trace: (Errors)
Jul 29 20:42:28 Tower kernel:  [<c102449e>] warn_slowpath_common+0x60/0x77 (Errors)
Jul 29 20:42:28 Tower kernel:  [<c10244e9>] warn_slowpath_fmt+0x24/0x27 (Errors)
Jul 29 20:42:28 Tower kernel:  [<c123b505>] dev_watchdog+0xff/0x17f (Errors)
Jul 29 20:42:28 Tower kernel:  [<c102be2e>] ? mod_timer+0xd0/0xdb (Errors)
Jul 29 20:42:28 Tower kernel:  [<f84e88b7>] ? e1000_watchdog+0x44d/0x455 [e1000] (Errors)
Jul 29 20:42:28 Tower kernel:  [<c123b406>] ? dev_watchdog+0x0/0x17f (Errors)
Jul 29 20:42:28 Tower kernel:  [<c102bb23>] run_timer_softirq+0x105/0x158 (Errors)
Jul 29 20:42:28 Tower kernel:  [<c1028261>] __do_softirq+0x84/0xf8 (Errors)
Jul 29 20:42:28 Tower kernel:  [<c10282fb>] do_softirq+0x26/0x2b (Errors)
Jul 29 20:42:28 Tower kernel:  [<c1028556>] irq_exit+0x29/0x2b (Errors)
Jul 29 20:42:28 Tower kernel:  [<c10042c5>] do_IRQ+0x80/0x96 (Errors)
Jul 29 20:42:28 Tower kernel:  [<c1002f29>] common_interrupt+0x29/0x30 (Errors)
Jul 29 20:42:28 Tower kernel:  [<c1008160>] ? default_idle+0x2d/0x42 (Errors)
Jul 29 20:42:28 Tower kernel:  [<c1008367>] c1e_idle+0xb4/0xce (Errors)
Jul 29 20:42:28 Tower kernel:  [<c1001a14>] cpu_idle+0x3a/0x4e (Errors)
Jul 29 20:42:28 Tower kernel:  [<c128a8bf>] rest_init+0x53/0x55 (Errors)
Jul 29 20:42:28 Tower kernel:  [<c13f580c>] start_kernel+0x27b/0x280 (Errors)
Jul 29 20:42:28 Tower kernel:  [<c13f5091>] i386_start_kernel+0x91/0x96 (Errors)
Jul 29 20:42:28 Tower kernel: ---[ end trace 6d7b8d7192958db1 ]---
Jul 29 20:42:28 Tower kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang (Network)
Jul 29 20:42:28 Tower kernel:   Tx Queue             <0>
Jul 29 20:42:28 Tower kernel:   TDH                  <dc>
Jul 29 20:42:28 Tower kernel:   TDT                  <c6>
Jul 29 20:42:28 Tower kernel:   next_to_use          <c6>
Jul 29 20:42:28 Tower kernel:   next_to_clean        <da>
Jul 29 20:42:28 Tower kernel: buffer_info[next_to_clean]
Jul 29 20:42:28 Tower kernel:   time_stamp           <2c8bb3a>
Jul 29 20:42:28 Tower kernel:   next_to_watch        <df>
Jul 29 20:42:28 Tower kernel:   jiffies              <2c8bdb8>
Jul 29 20:42:28 Tower kernel:   next_to_watch.status <0>
Jul 29 20:42:28 Tower ifplugd(eth0)[1522]: Link beat lost. (Network)
Jul 29 20:42:31 Tower kernel: e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX (Network)
Jul 29 20:42:31 Tower ifplugd(eth0)[1522]: Link beat detected. (Network)
Jul 29 23:40:12 Tower kernel: mdcmd (75): spindown 5 (Routine)
Jul 30 00:27:07 Tower kernel: mdcmd (76): spindown 20 (Routine)
Jul 30 00:27:37 Tower kernel: mdcmd (77): spindown 6 (Routine)
Jul 30 01:30:55 Tower kernel: mdcmd (78): spindown 20 (Routine)
Jul 30 02:46:50 Tower kernel: mdcmd (79): spindown 5 (Routine)

Some older Intel cards/chipsets do this. I might just be "cosmetic", even if horribly ugly. Do you know what card you have? Can we at least see your syslog? The output of ifconfig eth0?

 

Is it doing it under load or even while idle? Causing hangs or just polluting your syslog?

 

You might try disabling message signal interrupts, if it doesn't cause problems for other devices (PCIe cards). Add pci=nomsi to your kernel parameters in /boot/syslinux.cfg.

 

e.g.:

  append initrd=bzroot pci=nomsi

 

 

Thanks, ifconfig and syslog attached.

 

From memory it is an intel pro 1000 GB PCI card. That is about all I can remember. It's the first time it happened and I only noticed it a few days later as I was checking the syslog for more power failures (I have another post in here about that) I just saw a lot of red so i wouldn't have even noticed it. I think I was watching some avi files off it at the time but didn't notice anything.

 

Thanks Josh

 

eth0      Link encap:Ethernet  HWaddr 00:07:e9:10:42:96  
          inet addr:192.168.80.2  Bcast:192.168.80.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:328366639 errors:593502 dropped:0 overruns:0 frame:486798
          TX packets:358838270 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:908012328 (865.9 MiB)  TX bytes:147731843 (140.8 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:196251 errors:0 dropped:0 overruns:0 frame:0
          TX packets:196251 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:17852244 (17.0 MiB)  TX bytes:17852244 (17.0 MiB)

syslog-2011-08-01.txt

There's a possibility of a nic fix, depending on the card's age and chipset. Can you give us the output from "ethtool -e eth0"?

 

Did you get a chance to try the pci=nomsi option? I'd ignore everything below until you eliminate it.

 

Otherwise, what talk I've seen of the driver says it behaves like this in cases where resources aren't provided as expected. It's usually on systems with over 4GB RAM and due to one or another BIOS fault (often AMD boards) but I haven't found any good explanation. This sensitivity suggests you might help it out by minimizing memory fragmentation, increasing rx buffers, etc. All those rx errors (without overruns), tx hangs and the watchdog tripping are in the same neighborhood.

 

(feeling like a broken record here) Update the MB BIOS if something's available. Disable everything you don't need in the BIOS. Sound, serial, parallel, 1394, pata, etc. Minimize the built-in-video memory allocation and memory hole.

 

Test.

 

If the problems remain the we'll want to try giving the driver more breathing space (buffers & descriptors).

 

As for the UPS, whatever it is... (I shouldn't cross-think without at least reading the other thread) Have you tried using its windows software to reduce its sensitivity to voltage changes? Summertime can encourage weird grid behavior. Switch the USB cable to a win machine, use whatever mfg-supplied software to reduce sensitivity, and then switch it back.