Re: [Cooker] IDE patches unstable?
--- "Guy T. Rice" [EMAIL PROTECTED] wrote: On Fri, 07 Jul 2000, Thierry Vignaud wrote: I don't think it's an eide driver bug : it's just that the new driver stress more hardware (if your eide hd and controller reports to support udma, you just want to use it). Huh. According to hdparm, it's not using dma at all. /dev/hdb: multcount= 16 (on) I/O support = 0 (default 16-bit) unmaskirq= 0 (off) using_dma= 0 (off) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 977/255/63, sectors = 15698592, start = 0 the problem won't appear with kernel-linus because it's nicer with hardware (try hdparm -Tt on /dev/hda to compare). For me, it's a hardware bug (hd or cable; eg, for udma66, lots of read error were due to bad cables ...) This is bull! I have 2.2.16-9mdk working fine with UDMA33 ***AND*** UDMA66! But 2.2.17-0.5mdk or hackkernel-2.4.0-0.8mdk hangs. Alas, I don't have udma66, my motherboard is older than that... As far as I'm concerned, if one piece of software can read a piece of hardware perfectly, whereas another piece of software has difficulty with it, that's an obvious software problem. There may be hardware issues involved, but what it boils down to is the second piece of software isn't robust enough to support as much hardware as the first one does. The second piece of software is doing something with the hardware in question that it shouldn't. If there's no way to disable that feature (i.e. some hdparm setting to make it work), the software's busted and needs to be fixed. Well said, exactly my thoughts. If Linux still has support for arcane or ancient hardware that nobody uses anymore, why shouldn't it support new widely used hardware (read WD drives) with some minor problems (if this is the case, which I doubt). As I said before, I have **four** harddrives in a Promise66, plus I am using the onboard IDE too! "/usr" and "/home" are in a raid0 stripe containing a DMA mode2 (UDMA33) drive and a DMA mode4 (UDMA66) drive, and they work very good with 2.2.16! And I really pound my drives, since I run a lot of I/O intensive processes with large datasets that keep and my stripes busy almost 40-60% of the time. = Eugenio Diaz, BSEE/BSCE Linux Engineer [EMAIL PROTECTED] __ Do You Yahoo!? Get Yahoo! Mail Free email you can access from anywhere! http://mail.yahoo.com/
Re: [Cooker] IDE patches unstable?
On Fri, 07 Jul 2000, Thierry Vignaud wrote: I don't think it's an eide driver bug : it's just that the new driver stress more hardware (if your eide hd and controller reports to support udma, you just want to use it). Huh. According to hdparm, it's not using dma at all. /dev/hdb: multcount= 16 (on) I/O support = 0 (default 16-bit) unmaskirq= 0 (off) using_dma= 0 (off) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 977/255/63, sectors = 15698592, start = 0 the problem won't appear with kernel-linus because it's nicer with hardware (try hdparm -Tt on /dev/hda to compare). For me, it's a hardware bug (hd or cable; eg, for udma66, lots of read error were due to bad cables ...) Alas, I don't have udma66, my motherboard is older than that... As far as I'm concerned, if one piece of software can read a piece of hardware perfectly, whereas another piece of software has difficulty with it, that's an obvious software problem. There may be hardware issues involved, but what it boils down to is the second piece of software isn't robust enough to support as much hardware as the first one does. The second piece of software is doing something with the hardware in question that it shouldn't. If there's no way to disable that feature (i.e. some hdparm setting to make it work), the software's busted and needs to be fixed.
Re: [Cooker] IDE patches unstable?
"Guy T. Rice" [EMAIL PROTECTED] writes: I installed Mandrake 7.1 on several computers at work and everything worked flawlessly. However, I installed it on my home computer, and discovered a bug. My primary HD remains readable, but my second HD (slave drive on the same IDE bus) becomes unreadable. Actually, it appears to read, but sometimes a single bit will be set that shouldn't be. It's about a one in a million chance, but one bit in a million means attempting to gunzip any file over 125K usually results in an error, only extremely small RPMs can be installed, etc. I have an identical copy of a particular large file on my primary and secondary HD. If I compare the two (with "cmp"), it reports a difference at a particular byte, and continues to report it at that byte. But if I reboot, it reports the first difference at a different byte. (Perhaps caching accounts for this -- rebooting clears the cache and read errors are more or less random.) This probably did not occur in 7.0. It also disappears if I switch to kernel-linus. It reappears if I switch back to the standard kernel (either the one off the final 7.1 CD or the new one in updates). From this I surmise the problem is caused by one of the kernel patches that was added between 7.0 and 7.1. Here's a bit of hardware info, let me know if you want anything else: Excerpt from dmesg (booting under kernel-2.2.16-9mdk): (...) hdb: QUANTUM Bigfoot TX8.0AT, 7665MB w/69kB Cache, CHS=977/255/63 (hdb is the one that reads incorrectly.) Quantum Bigfoot are said to be not as reliable as other hd (there was some series that all crashed after some times (the rw head just stick on the hd :-( )). I don't think it's an eide driver bug : it's just that the new driver stress more hardware (if your eide hd and controller reports to support udma, you just want to use it). the problem won't appear with kernel-linus because it's nicer with hardware (try hdparm -Tt on /dev/hda to compare). For me, it's a hardware bug (hd or cable; eg, for udma66, lots of read error were due to bad cables ...) see you.
Re: [Cooker] IDE patches unstable?
For me, it's a hardware bug (hd or cable; eg, for udma66, lots of read error were due to bad cables ...) No way! The 2.2.17-*mdk rpms have IDE fucked up. On my machine it hangs (lock keys don't switch lights) when it goes to check the partition tables, with an UDMA time-out. 2.2.16-9mdk works fine. Several other people have also complained. I have a gateway PPro200 G6 + Promise Ultra66 + 3x WD drives + 1x Maxtor. It chokes on one of the 3 WD. All the drives are on the Promise card, the mobo IDE only has a CDROM and a CDRW. According to /proc/ide/* the IDE chipsets on the machine are "Intel PII3X" for the mobo, and "PDC20262" for the Promise card. = Eugenio Diaz, BSEE/BSCE Linux Engineer [EMAIL PROTECTED] __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/
Re: [Cooker] IDE patches unstable?
Eugenio Diaz wrote: For me, it's a hardware bug (hd or cable; eg, for udma66, lots of read error were due to bad cables ...) No way! The 2.2.17-*mdk rpms have IDE fucked up. On my machine it hangs (lock keys don't switch lights) when it goes to check the partition tables, with an UDMA time-out. 2.2.16-9mdk works fine. Several other people have also complained. I have a gateway PPro200 G6 + Promise Ultra66 + 3x WD drives + 1x Maxtor. It chokes on one of the 3 WD. Andre Hedrick has had quite a lot to say about the WD, expecially in combo with Maxtor (on same cable) and their ability to destroy each other's data with timing chatter. http://kt.linuxcare.com circa mid-February. There are some severe hardware problems, a result of cheap corner-cutting design (like blowing off the CRC) which are exacerbated by 486, 586, and 686 code. I am running an overclocked Duron which hits the IDE bus at 70 MHz and haven't had a whimper out of the IBM drives there. I will give 2.2.17 a trial and report within 24 hours. (I know a Seagate ST38641 just plain locks up in this situation, even without the overclocking) Civileme All the drives are on the Promise card, the mobo IDE only has a CDROM and a CDRW. According to /proc/ide/* the IDE chipsets on the machine are "Intel PII3X" for the mobo, and "PDC20262" for the Promise card. = Eugenio Diaz, BSEE/BSCE Linux Engineer [EMAIL PROTECTED] __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/
