Martin Ammermüller wrote:
> With high disk I/O and a 2.6.18-rc1 kernel i get these errors (depending
> upon the work i do, up to several times a day):
> 
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x400000 action 0x2 frozen
> ata1.00: (BMDMA stat 0x20)
> ata1.00: tag 0 cmd 0xc8 Emask 0x2 stat 0x58 err 0x0 (HSM violation)

Hmm... Interesting.  It gets HSM violation first.

> ata1: soft resetting port
> ata1: port is slow to respond, please be patient
> ata1: port failed to respond (30 secs)
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ATA: abnormal status 0xD8 on port 0xDCA18087
> ATA: abnormal status 0xD8 on port 0xDCA18087
> ATA: abnormal status 0xD8 on port 0xDCA18087
> ATA: abnormal status 0xD8 on port 0xDCA18087
> ATA: abnormal status 0xD8 on port 0xDCA18087
> ata1.00: qc timeout (cmd 0xec)
> ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> ata1.00: revalidation failed (errno=-5)
> ata1: failed to recover some devices, retrying in 5 secs
> ata1: hard resetting port
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: configured for UDMA/100
> ata1: EH complete

Then two timeouts while recovering.

> SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: drive cache: write back
> 
>> Anyways, if your harddisk is doing this regularly, 
>> your hardware is faulty.  Maybe the connection between the controller 
>> and the disk is the problem or the disk itself.
> 
> I did not get those errors with Windows XP and i am not the only one who
> has problems running this particular laptop model with a linux kernel.
> Ok, to be honest, there's actually only one person i know of which
> bothered enough about exactly the same errors to send me an e-mail (he
> discovered at least one of my messages to this list). But in my
> experience there are almost always others getting the same error, but
> which remain silent.

It might be that the drive is quirky and raises interrupts prematurely 
sometimes.  Depending on how the driver performs recovery, the effect 
can be hidden from user.  Can you try the attached patch and see how the 
kernel acts?

-- 
tejun