Messages in this thread |  | | | Date | Mon, 15 Mar 2010 14:21:34 +0100 | | Subject | Re: [git patches] libata updates for 2.6.34 | | From | Zeno Davatz <> |
| |
On Mon, Mar 15, 2010 at 2:06 PM, Jeff Garzik <jeff@garzik.org> wrote: > On 03/15/2010 03:33 AM, Zeno Davatz wrote: >> >> On Mon, Mar 15, 2010 at 3:55 AM, Jeff Garzik<jeff@garzik.org> wrote: >>> >>> On 03/09/2010 11:26 PM, Tejun Heo wrote: >>>> >>>> Hello, Linus, Jeff. >>>> >>>> On 03/10/2010 07:12 AM, Jeff Garzik wrote: >>>>> >>>>> Coincedentally, it looks like someone else just reported the same >>>>> problem, with 2.6.34-rc1. >>>>> >>>>> It definitely sounds like a race. READ DMA is a DMA command as the >>>>> name >>>>> implies, so that eliminates the possibility of polling-related paths in >>>>> ata_sff_interrupt (libata-sff.c). >>>>> >>>>> I'll flip some of my machines to the icky slow boring piix mode, rather >>>>> than sexy AHCI mode :) to see if I can reproduce. I have had a feeling >>>>> that we needed a more sophisticated IRQ handling setup, this may be >>>>> what >>>>> was needed. Lost interrupt recovery should occur faster than 30 >>>>> seconds >>>>> in any case, and should not require a hard reset if the hardware >>>>> functions just fine outside of the lost-interrupt / race that just >>>>> occurred. >>>> >>>> Yeap, there is a race condition with clearing which I don't think we >>>> can solve completely but with some modification I think we can at >>>> least cover known failure cases. >>>> >>>> For longer term, I don't think we can solve this by diddling with the >>>> SFF registers. The interface is just way too ancient and horrid to >>>> build anything reliable on top of. I'm planning on implementing >>>> smarter IRQ storm handling and stepped timeouts for ATA commands. >>> >>> A tester on this bug >>> http://bugzilla.kernel.org/show_bug.cgi?id=15537 >>> seemed to find success with the patch. >> >> Thanks for the Update! >> >> I will wait some more and then test rc-2. > > Can you test the patch, please?
Sure. I done:
/usr/src/linux> sudo patch -p1 < teo patching file drivers/ata/libata-sff.c Hunk #1 FAILED at 1667. Hunk #2 FAILED at 1700. Hunk #3 FAILED at 1718. Hunk #4 FAILED at 1770. Hunk #5 FAILED at 1792. Hunk #6 FAILED at 1801. Hunk #7 FAILED at 1818. 7 out of 7 hunks FAILED -- saving rejects to file drivers/ata/libata-sff.c.rej
Is that the expected outcome? Can I ignore the "failed" output?
Now I guess I still need to do "make", lilo and reboot.
Let me know.
Best Zeno -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |