Norman Diamond wrote: > Alan Cox wrote: >> Norman Diamond <n0diamond@xxxxxxxxxxx> wrote: >> >>> It looks like both LIBATA and the old IDE drivers >>> have an off-by-one error in deciding whether to use >>> READ SECTOR(S) instead of READ SECTOR(S) EXT. >> This was fixed some time ago, you need a newer >> kernel. > > Well, either that or I need an older kernel. It was also > fixed in 2.6.20, for which I think there was a ready-made > Slax distribution. > > On another topic, trying 2.6.20 in whatever Slax > distribution it was, an Intel ICH7M had DMA enabled on > both /dev/hda and /dev/hdc. I understand that the change > which was made shortly after that is considered to be by > design not a bug. In 2.6.20 I didn't even have to type a > "combined_mode" parameter, it just worked. I understand > that the addition and subsequent deletion of the > "combined_mode" parameter are considered to be by design > not bugs. But it is not at all pleasant that my /dev/hda > runs at 1.3 megabytes per second in 2.6.24.3 and later, > when it used to run at 45 megabytes per second in 2.6.20. > Yeah I know libata is supposed to solve all this stuff. > Removed some bugs and added others. You really shouldn't use the IDE drivers with SATA devices, if that's what you're talking about as far as the previous behavior. They were really never designed for it. > > I can't go newer than 2.6.24.3 until I find a version > where TASKFILEs start working again. There might not be > one. Yeah I know libata is supposed to solve all this > stuff. I wonder how much time I'll need and how many > varieties of hardware I'll have to buy to see if it's > really fixed. Realistically, although some people still work on it, testing coverage of the old IDE drivers is not that great these days, since most distributions no longer use it. The crusty, byzantine IDE code base doesn't exactly make it easy for the inexperienced to debug problems, either.. -- 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
