Jeff Garzik wrote: > 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. Currently if the device fails to IDENTIFY DEVICE, new EH will retry for 3 times and offline it. So, the faulty/phantom device won't cause trouble to SET FEATURES and normal operation of libata. (The impact is, 90 seconds boot time for irq-pio and 15 seconds boot time for polling-pio to IDENTIFY DEVICE and EH recovery.) > > 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. Agree. We need better way to identify the phantom slave. Will check if any clue we can use, before banging the door by IDENTIFY. -- albert > > 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
