On Sun, 19 Jul 2009 12:05:19 -0700, jw <jwde...@gmail.com> wrote: > Wow, thanks for the 'bad cable' idea.
I've seen this error on systems where the manufacturer / composer had chosen a 40 pin cable because of "economy reasons". Hard diks and optical disc drives that could run as UMDA66 or even UDMA100 would show up as UDMA33 and run slowly and / or buggy. Putting in the recommended 80 pin cable usually solved the problem. In fact, even the so called "80 pin cable" has only 40 pins on the plugs, but 80 wires connecting them. :-) > I replaced the (brand new) cable > and it's working, now. Previously, it was the right kind, it must have > just been flakey. Judging from today's "quality hardware"... that's quite possible. > The device still shows as UDMA33 though. Don't know > if that represents a different problem. Maybe the drive isn't faster, so it's no problem. You can always check the drive's capabilities with these commands: # atacontrol cap acd0 If you've loaded the atapicam facility (via kldload or compiled into your kernel), you can as well use this: # camcontrol devlist # camcontrol inquiry 1:0:0 If you're already using cdrtools from the ports, there's another means of diagnostics: # cdrecord -scanbus # cdrecord dev=1,0,0 -inq # cdrecord dev=1,0,0 -prcap > Odd that it would have read a mounted CD just fine through the bad cable... Maybe this is due to the error correction that is included in the data CD format (ISO-9660) which has a different block size than the audio CD format (2048 vs. 2352). -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"