Albert Lee wrote:
Use polling pio for identify device.
This can save some time to detect the phantom device 1 during boot.
Signed-off-by: Albert Lee <albertcc@xxxxxxxxxx>
---
For the phantom slave device (found with some IBM DVD-RAM drive and
Intel ICHx chip), irq-pio has to wait 30 seconds timeout to detect them.
Use polling pio can detect the phantom slave quicker. (Verified ok by Tejun.)
Patch again the current upstream branch (b74ba22f030eb7ab88f7d8954ad18ecc0ac5ce3c).
For your review, thanks.
--- upstream/drivers/scsi/libata-core.c 2006-05-22 10:04:12.000000000 +0800
+++ polling_identify/drivers/scsi/libata-core.c 2006-05-22 11:07:02.000000000 +0800
@@ -1196,6 +1196,8 @@ static int ata_dev_read_id(struct ata_de
}
tf.protocol = ATA_PROT_PIO;
+ /* Use polling for early detection of phantom dev 1 */
+ tf.flags |= ATA_TFLAG_POLLING;
Sorry I didn't jump into the thread earlier. I'm trying out this new
no-work-on-weekends thing, which is a change from my usual
working-7-days-a-week thing. :)
NAK. The above change is going backwards from the direction we took by
merging irq-pio, and it reintroduces problems that irq-pio solved.
Additionally, for irq problems unrelated to libata (we will continue to
see such problems FOREVER), this simply shifts the I-notice-a-problem
moment from IDENTIFY DEVICE to SET FEATURES, or perhaps the first READ
or WRITE.
SATA is inherently event driven (read: irq-driven), and PATA has
traditionally been irq-driven in the Linux drivers/ide code. Using
polling for solving this specific problem just isn't enough
justification. We should be able to fix this elsewhere. Take a look at
the drivers/ide "bang at the door w/ IDENTIFY" probing method. We took
a different approach (device signature, etc.) but its still a useful
working case to examine.
As an aside, phantom devices make me think that somewhere we might be
getting device-select wrong, or accidentally skipping it entirely.
Jeff
-
: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
