From: Mark Lord <liml@rtr.ca>
To: Roger While <simrw@sim-basis.de>
Cc: linux-ide@vger.kernel.org, Alan Cox <alan@redhat.com>,
Tejun Heo <htejun@gmail.com>
Subject: Re: libata/SATA noprobe
Date: Wed, 18 Apr 2007 12:23:18 -0400 [thread overview]
Message-ID: <462645F6.50702@rtr.ca> (raw)
In-Reply-To: <6.1.1.1.2.20070418164107.02c87a30@192.168.6.12>
Roger While wrote:
> Is there any knob/option to prevent libata
> probing non-existent channels ?
> Specifically how can I stop the kernel probing
> the second SATA? -
..
> <6>ata1.00: ATA-7, max UDMA/133, 490234752 sectors: LBA48 NCQ (depth 0/1)
> <6>ata1.00: ata1: dev 0 multi count 8
> <6>ata1.00: configured for UDMA/133
> <6>scsi1 : ata_piix
> <4>ata2: port is slow to respond, please be patient (Status 0xff)
> <3>ata2: port failed to respond (30 secs, Status 0xff)
> <3>ata2: SRST failed (status 0xFF)
> <3>ata2: SRST failed (err_mask=0x100)
> <4>ata2: softreset failed, retrying in 5 secs
> <3>ata2: SRST failed (status 0xFF)
> <3>ata2: SRST failed (err_mask=0x100)
> <4>ata2: softreset failed, retrying in 5 secs
> <3>ata2: SRST failed (status 0xFF)
> <3>ata2: SRST failed (err_mask=0x100)
> <3>ata2: reset failed, giving up
..
Ugh. That could really slow down system startup.
There is no parameter to avoid it,
just one to reduce the delay while it probes. Not ideal.
But it really could be more clever here, and notice the 0xff patterns,
and have an early exit if there's obviously nothing attached.
Or perhaps there's some register it could read to see if the
port was disabled in the BIOS (I'm betting it is still "enabled",
but it could be good to check if we don't already).
Maybe just do it in the ata_piix subdriver. Tejun, Alan?
-ml
next prev parent reply other threads:[~2007-04-18 16:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-18 14:41 libata/SATA noprobe Roger While
2007-04-18 16:23 ` Mark Lord [this message]
2007-04-18 16:28 ` Tejun Heo
2007-04-18 18:44 ` Roger While
-- strict thread matches above, loose matches on Subject: below --
2007-04-19 18:29 Roger While
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=462645F6.50702@rtr.ca \
--to=liml@rtr.ca \
--cc=alan@redhat.com \
--cc=htejun@gmail.com \
--cc=linux-ide@vger.kernel.org \
--cc=simrw@sim-basis.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).