> > + status = ata_sff_altstatus(ap); > > + if (!(status & ATA_BUSY)) > > + return; > > Shouldn't this rather be > > if (status & ATA_BUSY) > return; > ? Doh yes - I thought I fixed that after debugging it backwards in qemu > > + ata_port_printk(ap, KERN_WARNING, "lost interrupt (Status 0x%x)\n", > > + status); > > >From your changelog entry I got the impression that this is known to > happen on various controllers and there is nothing the user or you > (kernel developers) can do about it. So, will this become a debug level > message later too? Probably it shouldn't. It occurs but rarely on such boxes and as you get a long pause before the recovery we need to know. It may also be that we eventually should move buggier controllers to run with a parallel sanity checking timer just as networking sometimes does > > + * ata_sff_drain_fifo - Stock FIFO drain logic for SFF controllers > > + * @ap: port to drain > > There is no @ap argument. Good point ;) > > + * pcmcia_8bit_drain_fifo - Stock FIFO drain logic for SFF controllers > > + * @ap: port to drain > > No argument @ap. Ditto - there was one originally ;) Thanks Alan -- To unsubscribe from this list: 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
