Date: Tue, 3 Apr 2007 00:39:39 -0700 From: "Josh Carroll" <josh.carroll@gmail.com> To: "Scott Long" <scottl@samsco.org> Cc: freebsd-scsi@freebsd.org, bug-followup@freebsd.org, Thomas Quinot <thomas@freebsd.org> Subject: Re: kern/103602: drive gets wedged on READ CD CAPACITY if no disc is in Message-ID: <8cb6106e0704030039if46397fvfc993d9c9e19e1fc@mail.gmail.com> In-Reply-To: <8cb6106e0703281531k4c5bebecp5566c64c8f458a74@mail.gmail.com> References: <20070313205731.GB3866@melamine.cuivre.fr.eu.org> <8cb6106e0703261057j55b554f9h84a894a4dbd19991@mail.gmail.com> <20070326180018.GA23771@melamine.cuivre.fr.eu.org> <460829E9.3080102@samsco.org> <8cb6106e0703261318o120c620ar6b2461802632fc01@mail.gmail.com> <8cb6106e0703262119g5a9afd4m2c3d5665c85c4969@mail.gmail.com> <4608A35E.3010404@samsco.org> <8cb6106e0703262157m7fd0ae96p3bb5368af797dc6b@mail.gmail.com> <460AA9E3.4030106@samsco.org> <8cb6106e0703281531k4c5bebecp5566c64c8f458a74@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm unable to get past the INQUIRY with the cam_xpt.c patch with the > serial inquiry workaround along with the cam and scsi_cd patches. Ok, I was able to find the right combination of patches to get this to work. I cvsup'd today (4/2/2007) so all the patches to the files in sys/dev/ata appear to already have been committed. I patched cam_xpt.c with the patch that removes "REQUIRE_GIANT" in two places, and sets the serial inquiry quirk for my drive. I also patched with Scott's scsi_cd.c patch. Rather than paste thousands of lines of code in this update again, I'm throwing the dmesg output up on my web server, so I hope that's ok. I figure it's easier to follow without it (the SNR is too high :)) Anyway, I was able to get booted again to test. Without a CD in the drive after boot, I get a huge number of interrupts still on the ata controller, and I see a lot of READ CAPACITY timeouts. But it finally stops and I still have /dev/cd0 and the interrupts are no longer "storming". Here is the dmesg output from the start of the boot process up to the point where the interrupt storm stops and things settle down: http://pflog.net/atapicam/dmesg.post_boot.gz I then issued the following cdrecord command: cdrecord -scanbus Here is the dmesg output from that command: http://pflog.net/atapicam/dmesg.cdrecord.scanbus.gz I then issued a cdrecord command to burn a CD-RW at 4x: cdrecord -v dev=2,1,0 /path/to/file.iso There were some long timeouts during which the interrupts were storming as well (based on the delta in the # before and after the cdrecord command). But it ultimately finished, and I was able to mount the resulting burned disc. The only data I could get from dmesg was during the tail end of the cd write, since the dmesg buffer was clobbered. Here's that dmesg output: http://pflog.net/atapicam/dmesg.cdrecord.burn.gz What's odd is the drive still hangs on various commands when there is no disc in the drive, or there is a blank CD-RW in the drive. For example, trying to mount the blank'd CD-RW disc with /dev/cd0 takes almost a few minutes to timeout during which I see: acd0: FAILURE - READ_TOC timed out (I see this 6 times) g_vfs_done(): cd0[READ(offset=32768, length=2048)]error = 5 mount_cd9660: /dev/cd0: Input/output error If I issue the same mount command against /dev/acd0, it immediately gives me the Input/output error. Another note. On a different boot, I tried using cdrecord to blank the disc, which worked, though I saw quite a few errors (camcontrol debug off prior). The command issued was: cdrecord dev=2,1,0 blank=fast The errors I saw in dmesg were: acd0: FAILURE - READ_DVD_STRUCTURE timed out (I imagine this is because I didn't specify a media type) acd0: FAILURE - READ_BUFFER timed out acd0: FAILURE - MODE_SELECT_BIG ILLEGAL REQUEST asc=0x24 ascq=0x00 (I saw this right before the cdrecord command finished) I hope this updated info helps. It seems to still hang on the READ CAPACITY command, though at least now I'm able to use the device after the drive calms down. Though I am still seeing other commands time out as well, cdrecord appears to still work albeit very slowly (due in part I'm sure to WITNESS, but also due to these multi-second (minute?) timeouts). Thanks, Josh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8cb6106e0704030039if46397fvfc993d9c9e19e1fc>