Re: [smartmontools-support] exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen

[Justin P. <jp...@lu...>]

On Sat, 30 Aug 2008, Jonas Petersson wrote:

> Hi Justin and thanks for your prompt response,
>
> That would be /sys/block/sda/device/queue_depth, right? I already checked 
> that and it was "1" so I guess there is nothing to do.
Correct..

>>  Also, do/not run smart tests during heavy I/O?
>
> They are certainly OK without heavy I/O. Those that take some time to run 
> where run during "normal" I/O - I kept using the system normally. The problem 
> occurs during low I/O conditions as far as I can tell. For example during the 
> night (slocate may run at some stage, but according to the logs the problems 
> has occured at 4 different time during the night and even a fairly long 
> slocate session can't possibly have covered more than 2 of them at worst).
I do not have the same exact problem you have, but I have a similar problem:

[189770.219773] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[189770.219784] ata1.00: cmd 35/00:40:9a:d9:7a/00:00:12:00:00/e0 tag 0 dma 32768 out
[189770.219786]          res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[189770.219790] ata1.00: status: { DRDY }
[189770.219795] ata1: hard resetting link
[189770.524770] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[189770.543960] ata1.00: configured for UDMA/133
[189770.543977] ata1: EH complete

I think its a chipset issue personally, I've spoken to various people about it
on LKML, and other mailing lists basically there is no ultimate box, I've tried
disabling noapic, apci=off etc, no luck.  I just ignore it, it doesn't seem
to affect anything (in my case) as of yet and via smart tests/etc I cannot/do
not see any form of drive failure, all tests pass normally and the smart
output looks good.

>
>
>>  Have you tried disabline smartmontools to see if the problem persists?
>
> Yes: Initially, it happened before I even installed smartmontools. It kept 
> happening with while smartd was running for a while. It kept happening when I 
> disabled smartd and just ran smartctl now and then. It also happened (one) 
> about 5 minutes after rebooting when no smartmontools programs either smartd 
> nor smartctl had efter run. In this particular case, the boot process 
> involved automatic installation of the nvidia binary driver which may have 
> caised a bit of heavy I/O for a while.
>
> Does this give you any further clues? Would a full dump of smartctl --all 
> help?
smartctl -a would be useful (#1)

An "lshw" run would also be useful, I am curious which chipset they are using
for the SATA I/O on that hardware type.

Justin.