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]
Message-ID: <20110713131407.GN2872@htj.dyndns.org>
Date:	Wed, 13 Jul 2011 15:14:07 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Brian Norris <computersforpeace@...il.com>
Cc:	linux-ide@...r.kernel.org, Valdis.Kletnieks@...edu,
	"Rafael J. Wysocki" <rjw@...k.pl>, Jeff Garzik <jgarzik@...ox.com>,
	Michael Leun <lkml20100708@...ton.leun.net>,
	linux-kernel@...r.kernel.org, Jian Peng <jipeng2005@...il.com>,
	Kevin Cernekee <cernekee@...il.com>
Subject: Re: ahci_start_engine compliance with AHCI spec

Hello,

On Fri, Jul 08, 2011 at 04:01:17PM -0700, Brian Norris wrote:
> I am able to reproduce the regressions seen by Rafael and Michael on
> my Dell Latitude E6410 laptop, in case that's helpful.

Oh yes, it is.

> - ahci_init_one
> -- ata_host_activate
> --- ata_host_start
> ---- ahci_port_start
> ---- ahci_port_resume
> ----- ahci_start_port
> ------ ahci_power_up [1]
> ------ ahci_start_engine (DRQ or BSY *will* be active) [2]
> 
> and later
> 
> - scsi_error_handler
> -- ata_scsi_error
> --- ata_scsi_port_error_handler
> ---- ahci_error_handler
> ----- sata_pmp_error_handler
> ------ ata_eh_recover
> ------- ata_eh_reset
> -------- ata_do_reset
> --------- ahci_hardreset
> ---------- ahci_start_engine (DRQ, BSY cleared, link up)
> 
> I'm not sure if the "error_handler" and "hard reset" processes are
> intended for initialization...as I said I'm a little new!

That's how it's supposed to work.  EH is integral part of probing
sequence.

> I have a few other questions:
> 
> What operation could be putting devices in DRQ or BSY states during
> initialization but before ahci_start_engine?

Hmmm... I have no idea, maybe it has something to do with the first
D2H Reg FIS device sends after link gets reset during controller init?

> I bring up all of this because it seems that if I put some amount of
> "wait time" between [1] and [2] above, then my system transitions from
> DRQ to BSY and its link is connected (PxSSTS.DET == 0x3). I still
> don't know why the device is BSY, but at least it solves my problem...
> Perhaps I will try implementing the wait with ata_wait_register (or
> maybe ata_wait_ready + ata_phys_link_online) on the PxSSTS.DET flags
> and send a patch.

Hmmm... what happens if you don't comment out ahci_start_engine() call
from ahci_start_port()?

> Sorry if this e-mail is too complicated or disorganized. I've been
> racking my brain on this one for a few weeks now, and I've only come
> up with a few half answers and some more questions. Feel free to ask
> for more explanation, but don't worry if I don't respond immediately,
> as I am on vacation for all of next week. If I don't get to them
> before I leave, I will get to your replies when I return.

Is this the same IP block that Jian Peng was using?

Thanks.

-- 
tejun
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ