Tejun Heo wrote: > Albert Lee wrote: > >> Tejun Heo wrote: >> >>> Jonathan Blake Benson wrote: >>> >>>> I posted a couple of months ago regarding enabling libata.atapi on a >>>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller. I >>>> decied to give kernel 2.6.16 (release, was previously using rc-1) a >>>> shot, and it no longer longer panics. I still have a Lite-ON DVD ROM >>>> drive connected via a sil3611 bridge to port number 4, hoping that I >>>> can avoid using the onboard CMD646. >>>> >>>> No panic this time, though it appears to throw a machine check. The >>>> system continues all the way to multi-user, and the Maxtor drives are >>>> usable. Hope the attached dmesg helps. Let me know if I can be of >>>> any assitance. >>>> >>> Can you build your kernel with ATA_DEBUG set and post dmesg? Just >>> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of >>> include/linux/libata.h >>> >> >> For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR >> workaround should also be turned on as well. (in linux/libata.h) >> >> My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without >> the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems >> need it. > > > Is there any way to make this thing automatic? 'Recompile with #define > tweak if you have some invisible bridge chip' doesn't sound too hot. > The bridge is transparent to the software. So, it's hard to detect the chip used. Maybe the SiImage developers know how to detect the chip? For the time being, maybe we can use a module paramater instead of compile time #ifdef. Will submit a patch for this later. -- Albert - : 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
