Date: Wed, 26 Jun 2002 03:12:27 -0700 From: Dave Hayes <dave@jetcafe.org> To: Gavin Atkinson <gavin@ury.york.ac.uk> Cc: Soeren Schmidt <sos@freebsd.dk>, stable@FreeBSD.ORG Subject: Re: ATA tags bug fix committed to -releng4 Message-ID: <200206261012.g5QACW091684@hokkshideh2.jetcafe.org>
next in thread | raw e-mail | index | archive | help
Gavin Atkinson <gavin@ury.york.ac.uk> writes: > If you mean the READ_BIG timeouts I and others were having with my > DVD drive, then no, this patch has not fixed them. The DVD-ROM works > fine in both UDMA and WDMA under both linux and windows. I currently run a number of FreeBSD 4.5-p4 machines directly off of CDROM. That means I can guarantee they are all running the exact same code, no slight divergences of kernel configuration or anything like that. There are a few of these machines that I've seen the READ_BIG errors on. They happen occasionally but fairly consistantly when you run the OS off of CDROM. Here are some dmesg snippets from machines that have the problem: Machine A: acd0: DVD-ROM <TOSHIBA DVD-ROM SD-M1612> at ata0-master using PIO4 acd0: READ_BIG - ILLEGAL REQUEST asc=64 ascq=00 error=01 Machine B: acd0: CDROM <ATAPI CD ROM VER 5.1a> at ata1-master using PIO4 acd0: READ_BIG command timeout - resetting (...we then change the CD drive on the -same- machine...) acd0: CDROM <SONY CDU4811> at ata1-master using PIO4 acd0: READ_BIG command timeout - resetting Machine C: acd0: CD-RW <LG CD-RW CED-8120B> at ata1-master using PIO4 acd0: READ_BIG - ILLEGAL REQUEST asc=64 ascq=00 error=00 Here are some from machines that do not have the problem: Machine 1: acd0: CDROM <SONY CDU4811> at ata1-master using PIO4 Machine 2: acd0: CDROM <TOSHIBA CD-ROM XM-6702B> at ata0-master using PIO4 It's very important to note that these are all -older- CDROM/DVD-ROM devices, as in 2-3 years older. I hope this data helps. The problem has existed since before the ata MFC (unless 4.5-p4 somehow got the MFC). <relatedtangent> I have a theory on why we see so many problems, culled mostly from other experts telling me random things here and there. The caveat on this is that I am not working on device drivers every day, nor do I know much about low level hardware details. With the following, I've merely observed the data given to me and drafted a theory to support the data. If I'm wrong, tell me...and I'd really love to know why I'm wrong if I am. Also, apologies if this has been touched upon before...you never know when a discussion is "verboten" on this list. ;) We all are painfully aware of how these different ATAPI drives work just fine with linux and windows, while on FreeBSD it's touch and go. Some people never see any problems, others of us have yet to have burncd or cdrecord (or whatever) work a CD-RW drive properly enough to burn CDs. A while ago, someone knowledgable (might have even been Soren) told me that both linux and windows use some sort of SCSI emulation layer between their operating system and ATAPI devices. According to Soren, FreeBSD uses a direct ATAPI subsystem, it doesn't go through this layer (most probably for speed). So I contend that the vendor support for the emulation is a lot less sloppy than the support for direct ATAPI. Thus, it's a LOT more work to keep up a direct ATAPI driver suite, especially since there seems to be some hardware dependance involved. (Anyone noticed how little free time Soren has?) My question would be: why don't we have an interface to the more robust SCSI emulation layer of these devices? I recognize there is loss of speed to be endured, but the upside is that we could use a lot more drives on FreeBSD. </relatedtangent> ------ Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< Half of being smart is knowing what you're dumb at. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206261012.g5QACW091684>