Alan Cox wrote: >> Well, if we change that in #upstream now, -mm will receive it and after >> 2.6.24 is released, it will end up in -rc1. We can change it back if >> the damage is too grave. > > Getting it in -rc is going to mess up other testing. It's perfect for -mm > testing not -rc testing. It eventually has to end up in -rc. If not for 2.6.25-rc1 is too early, we can put it in #testing and put it into #upstream later. >> Yeah, ALi seems to be genuine driver problem. I don't think using PIO >> for misc ATAPI commands is extreme considering Windows is doing it. > > Windows does a lot of things that are bad and ugly workarounds for messes > in the past. We have the ability to do a lot better than that. I agree. It's double edged sword tho. We're not gonna get much test coverage over those messes of the past and as I said, those are what I'm primarily worried about. Command type dependent quick fallback might help but ancient controllers are more likely to bring the whole machine down when a DMA transaction goes south. >> Another thing is check_atapi_dma in sata_promise. It mentions losing >> interrupt which is exactly what happens if the drive tries to transfer >> more data but DMA buffer is short on several controllers. I wonder >> whether this is unnecessary with DMA draining added. > > Is it like the inic where you must do transfers in specific chunk sizes ? I don't think so. It does READ_CD and READ_DVD_STRUCTURE via DMA. The first one isn't 2k aligned the second is of variable size. I think the driver was just working around buggy userland which issues commands like mode sense with longer allocation size than actual buffer size. -- tejun - 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
