August 10, 200916 yr Greetings, I've been having some errors appear in the log (that I just noticed), and I don't know what they mean. I googled, but only one result showed on the Ubuntu forums that didn't seem to produce any answers. (It did show the problem was drives connected to the Promise TX4 card, which mine are) My media interface is via an original xbox using xbmc that connects with the unRAID server. For some time now numerous drives spin up without cause (mostly will browsing my video library via xbmc). All the info and thumbs (everything) is locally cached, so it should not spin up the drives, but it appears it does for some reason and this error is the result. This also seems to happen across all the drives (randomly) - not just the ones connected to the TX4 cards. Can someone help me determine what is going on and what this error means. Here is a brief segment of the log. All my specs are in my sig. There is also a full log (From a different session) attached Thx. Aug 9 20:11:30 Tower kernel: ata13: exception Emask 0x10 SAct 0x0 SErr 0x180000 action 0xa frozen Aug 9 20:11:30 Tower kernel: ata13: hotplug_status 0x8 Aug 9 20:11:30 Tower kernel: ata13: SError: { 10B8B Dispar } Aug 9 20:11:36 Tower kernel: ata13: port is slow to respond, please be patient (Status 0xff) Aug 9 20:11:40 Tower kernel: ata13: soft resetting link Aug 9 20:11:40 Tower kernel: ata13: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 9 20:11:40 Tower kernel: ata13.00: configured for UDMA/133 Aug 9 20:11:40 Tower kernel: ata13: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xb t4 Aug 9 20:11:40 Tower kernel: ata13: hotplug_status 0x80 Aug 9 20:11:41 Tower kernel: ata13: soft resetting link Aug 9 20:11:41 Tower kernel: ata13: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 9 20:11:42 Tower kernel: ata13.00: configured for UDMA/133 Aug 9 20:11:42 Tower kernel: ata13: EH complete Aug 9 20:11:42 Tower kernel: sd 13:0:0:0: [sdn] 976773168 512-byte hardware sectors (500108 MB) Aug 9 20:11:42 Tower kernel: sd 13:0:0:0: [sdn] Write Protect is off Aug 9 20:11:42 Tower kernel: sd 13:0:0:0: [sdn] Mode Sense: 00 3a 00 00 Aug 9 20:11:42 Tower kernel: sd 13:0:0:0: [sdn] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Aug 9 20:11:42 Tower kernel: sd 13:0:0:0: [sdn] 976773168 512-byte hardware sectors (500108 MB) Aug 9 20:11:42 Tower kernel: sd 13:0:0:0: [sdn] Write Protect is off Aug 9 20:11:42 Tower kernel: sd 13:0:0:0: [sdn] Mode Sense: 00 3a 00 00 Aug 9 20:11:42 Tower kernel: sd 13:0:0:0: [sdn] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
August 19, 200916 yr Author Has anyone had a chance to think about this issue and what may be causing it? I've done some searching and there are numerous posts about certain parts of the error message - mostly to do with "smartd" - but not sure how this causes such an issue. The error also appears random - or perhaps I haven't realised what it causing it yet. I would not have known anything was untoward as the system has been seemingly operating flawlessly. I only happened to check the syslog in unmenu and noticed the red lines to draw my attention. Now the damn thing has me worried. Wish I'd never seen it!
August 19, 200916 yr This wiki page may have some explanation http://ata.wiki.kernel.org/index.php/Libata_error_messages According to it, the "timeout" error is most often affiliated with a missing interrupt: Controller failed to respond to an active ATA command. This could be any number of causes. Most often this is due to an unrelated interrupt subsystem bug (try booting with 'pci=nomsi' or 'acpi=off' or 'noapic'), which failed to deliver an interrupt when we were expecting one from the hardware. Joe L.
August 24, 200916 yr Author This wiki page may have some explanation http://ata.wiki.kernel.org/index.php/Libata_error_messages According to it, the "timeout" error is most often affiliated with a missing interrupt: Controller failed to respond to an active ATA command. This could be any number of causes. Most often this is due to an unrelated interrupt subsystem bug (try booting with 'pci=nomsi' or 'acpi=off' or 'noapic'), which failed to deliver an interrupt when we were expecting one from the hardware. Joe L. Thx Joe. That page was really helpful - never found it myself with a google. Part of the info on that page (10B8B Dispar) suggests a bad SATA lead (Or power supply) - I think?? For some reason my Disk 1 keeps spinning up - perhaps even causing the other drives (which appear completely random) to spin up?? I'll try a cable replacement.
August 24, 200916 yr Not sure if the sysctl vm.block_dump=1 command is in your kernel, but did you try it as described here: http://lime-technology.com/forum/index.php?topic=4193.msg37084#msg37084 It does work in the current unRAID 4.5beta6 version, but I do not know when it was introduced in the kernel. Joe L.
August 26, 200916 yr Author Not sure if the sysctl vm.block_dump=1 command is in your kernel, but did you try it as described here: http://lime-technology.com/forum/index.php?topic=4193.msg37084#msg37084 It does work in the current unRAID 4.5beta6 version, but I do not know when it was introduced in the kernel. Joe L. Thx for that - I'll give that command a go and see what happens. Update - seems that command is available in 4.3.3. I got a lot of syslog stuff about reading blocks. Question? How long can I leave this on before it fills up the log/sucks heaps of RAM? Update 2 - It appears the exception error problem is only taking place on the Seagate drives in my system (500Gb). There are 4 still in the array, but only 3 seem to have this issue. Weird. Thankfully they are being swapped out for WD .
August 26, 200916 yr Update - seems that command is available in 4.3.3. I got a lot of syslog stuff about reading blocks. Question? How long can I leave this on before it fills up the log/sucks heaps of RAM? That would depend on how much memory you have installed, and how much file activity you have occurring. Since you were looking for what was spinning up your disk, I assumed you might enable it when you did not expect a lot of activity. You can see how big the syslog is getting by typing ls -l /var/log/syslog Joe L.
August 27, 200916 yr Author Update - seems that command is available in 4.3.3. I got a lot of syslog stuff about reading blocks. Question? How long can I leave this on before it fills up the log/sucks heaps of RAM? That would depend on how much memory you have installed, and how much file activity you have occurring. Since you were looking for what was spinning up your disk, I assumed you might enable it when you did not expect a lot of activity. You can see how big the syslog is getting by typing ls -l /var/log/syslog Joe L. Thx Joe, I'll give a whirl and see what I can see.
Archived
This topic is now archived and is closed to further replies.