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"
