From owner-freebsd-scsi@FreeBSD.ORG Tue Apr 3 07:39:41 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F41CF16A408 for ; Tue, 3 Apr 2007 07:39:40 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 967E613C487 for ; Tue, 3 Apr 2007 07:39:40 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1586428ana for ; Tue, 03 Apr 2007 00:39:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dj7Vvux3l0CbV2Gy28azeeqFm4v71Kf4AZA/jqEZ42+Xz5eEFJ7knQK5+yngtV/Sh6nCVVdU41VCVBb2JeaagHK1RJ+XZT7HzgB9qECuhjrKihXRSyr9gmedN3mJWLJjLvkcvB3baxYJpeGAi9wbd09rKLjK0su3HmrJw5S/Rv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XnegNETnQZcB5I5xqo9SNaYOM+LiWeAb5Dz8EG41yBTOIpbutmFtt6pOmh+ULiiuFgS2kWu5ykGbQcQ+ZirWmS+9uohmjiWudpKlLGuxHMp9peK/ADiGnsvboK5H/AnTgWVKup7SpNw5bc6iUJKrKvAAI/sUASoOriJ/db1U+ao= Received: by 10.100.13.12 with SMTP id 12mr4100822anm.1175585979700; Tue, 03 Apr 2007 00:39:39 -0700 (PDT) Received: by 10.100.231.18 with HTTP; Tue, 3 Apr 2007 00:39:39 -0700 (PDT) Message-ID: <8cb6106e0704030039if46397fvfc993d9c9e19e1fc@mail.gmail.com> Date: Tue, 3 Apr 2007 00:39:39 -0700 From: "Josh Carroll" To: "Scott Long" In-Reply-To: <8cb6106e0703281531k4c5bebecp5566c64c8f458a74@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> Cc: freebsd-scsi@freebsd.org, bug-followup@freebsd.org, Thomas Quinot Subject: Re: kern/103602: drive gets wedged on READ CD CAPACITY if no disc is in X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 07:39:41 -0000 > 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