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:	Wed, 29 Nov 2006 17:55:51 +0900
From:	Tejun Heo <htejun@...il.com>
To:	"Berck E. Nash" <flyboy@...il.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>
Subject: Re: 2.6.18 - AHCI detection pauses excessively

Berck E. Nash wrote:
> Tejun Heo wrote:
> 
>> Yeah, I did and forgot about this thread too.  Sorry.  This is on the
>> top of my to-do list now.  I'm attaching the patch.  TIA.
> 
> That didn't fix the problem, but did change the messages.  I've attached 
> the entire log, including the weird errors on power-off from the same 
> device that gives problems on boot, which I suspect are related.

Hmm... this is difficult.  The problem is that everything looks normal 
until command is issued.  My primary suspect still is ahci powering down 
phy during initialization.  Can you please test the attached patch again?

[--snip--]
> Mounting root filesystem read-only...done.
> Will now halt.
> [ 9371.896444] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> [ 9371.903036] ata2.00: (irq_stat 0x40000001)
> [ 9371.907228] ata2.00: cmd e0/00:00:00:00:00/00:00:00:00:00/00 tag 0 data 0 in
> [ 9371.907229]          res 51/04:00:01:01:80/00:00:00:00:00/a0 Emask 0x1 (device error)
> [ 9371.931688] ata2.00: configured for UDMA/133
> [ 9371.936073] ata2: EH complete

Weird, the drive is failing STANDBY IMMEDIATE.

[--snip--]
> [ 9372.152310] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> [ 9372.158882] ata2.00: (irq_stat 0x40000001)
> [ 9372.163079] ata2.00: cmd 94/00:00:00:00:00/00:00:00:00:00/00 tag 0 data 0 in
> [ 9372.163080]          res 51/04:00:01:01:80/00:00:00:00:00/a0 Emask 0x1 (device error)
> [ 9372.187505] ata2.00: configured for UDMA/133

Then, a series of obsolete STANDBY failures.  Who's issuing these 
commands?  It's not libata, libata uses STANDBY (0xe2).  Is it some kind 
of gentoo thing?  Anyways, doesn't really matter although it's 
surprising that the drive fails STANDBY IMMEDIATE.

Thanks.

-- 
tejun

View attachment "patch" of type "text/plain" (1544 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ