linux-kernel - Re: Strange ATA problems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 Dec 2007 19:49:44 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Tejun Heo <htejun@...il.com>
Cc:	Christoph Anton Mitterer <calestyo@...entia.net>,
	linux-kernel@...r.kernel.org,
	IDE/ATA development list <linux-ide@...r.kernel.org>
Subject: Re: Strange ATA problems

Tejun Heo wrote:
>> Dec 14 01:06:33 fermat kernel: ata1: EH in ADMA mode, notifier 0x0
>> notifier_error 0x0 gen_ctl 0x1501000 status 0x400 next cpb count 0x0
>> next
>>  cpb idx 0x0
>> Dec 14 01:06:33 fermat kernel: ata1: CPB 0: ctl_flags 0x1f, resp_flags
>> 0x2
>> Dec 14 01:06:33 fermat kernel: ata1: CPB 1: ctl_flags 0x1f, resp_flags
>> 0x2
>> Dec 14 01:06:33 fermat kernel: ata1: CPB 2: ctl_flags 0x1f, resp_flags
>> 0x2
>> Dec 14 01:06:33 fermat kernel: ata1: CPB 3: ctl_flags 0x1f, resp_flags
>> 0x2
>> Dec 14 01:06:33 fermat kernel: ata1: CPB 4: ctl_flags 0x1f, resp_flags
>> 0x2
>> Dec 14 01:06:33 fermat kernel: ata1: CPB 5: ctl_flags 0x1f, resp_flags
>> 0x2
>> Dec 14 01:06:33 fermat kernel: ata1: CPB 6: ctl_flags 0x1f, resp_flags
>> 0x2
>> Dec 14 01:06:33 fermat kernel: ata1: CPB 7: ctl_flags 0x1f, resp_flags
>> 0x2
>> Dec 14 01:06:33 fermat kernel: ata1: CPB 8: ctl_flags 0x1f, resp_flags
>> 0x2
>> Dec 14 01:06:33 fermat kernel: ata1: CPB 9: ctl_flags 0x1f, resp_flags
>> 0x2
>> Dec 14 01:06:33 fermat kernel: ata1: CPB 10: ctl_flags 0x1f, resp_flags
>> 0x2

CPB flags stuck at 0x2 indicates that the controller issued the command 
to the drive and is waiting for completion. Usually seems to indicate 
some kind of SATA communication problem.

>>> If your USB cdrom is bus powered and you yanked it, it could have caused
>>> fluctuation in power which in turn can cause disruption on serial ATA
>>> bus leading to transmission error and timeouts.  There are other
>>> possibilities but this kind of thing does happen often with SATA.  Those
>>> highspeed low-voltage serial links are very susceptible to interferences.
>> Well,.. it actually "worked" again when I unplugged it, but the errors
>> from the cdrom above are probably unrelated..
>>
>>
>>> As long as EH recovered it properly, there's nothing to worry about.
>> What does that mean?
> 
> That means unless the problem continues to occur repeatedly, you don't
> have to worry about it.
> 

Yes, if it didn't recur, was likely just a transient glitch.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/