SCSI Driver Regression and Missing Code Block?

SCSI Driver Regression and Missing Code Block?

[Dominic Driver]

Hi Guys,

I had an interesting experience with my SATA DVD-RW Drives following a Kernel Upgrade from:

2.6.27.19-170.2.35.fc10.i686
to 
2.6.28.6 (Vanilla)

I had been previously using a Fedora 10 release, but required the 2.6.28 kernel in order to update the driver for my onboard Intel Graphics chip (apparently some modules required for this process had been moved into the kernel from 27->28). This was required to fix an issue which was preventing correct functionality of a C++ application I'm working on. This C++ application also has a heavy bias on DVD-ROM burning, and this is where my two problems lie.

Rebuilding went smoothly, and the 2.6.28.6 kernel ran as expected in all but 2 areas:
1) When reading from the disc in a DVD-RW Drive, The return values of the IOCTL Call CDROM_DRIVE_STATUS were not the same as the previous kernel values.

2) Maximum burning speed of the drive seems to be very slow; averaging 2.2X instead of the previous 10+X.

I rooted around in the source code to fix issue 1), and found the following code was completely omitted from the function

int sr_drive_status(struct cdrom_device_info *cdi, int slot)

in the file 

sr_ioctl.c:

	/* SK/ASC/ASCQ of 2/4/1 means "unit is becoming ready" */
	if (scsi_sense_valid(&sshdr) && sshdr.sense_key == NOT_READY
			&& sshdr.asc == 0x04 && sshdr.ascq == 0x01)
		return CDS_DRIVE_NOT_READY;

My Question is: Is this an intentional change, or an accidental omission? It's pretty weird to have a whole chunk like that missing from a function without a comment. I've had to manually replace this bit of code to regain the functionality I had in the 2.6.27 kernel. This is the only change I had to make, which is even stranger. How come it's different in 2.6.28.6?



Regarding issue 2) - I haven't found a solution to this yet. I've used various tools to check the speed of the drive, and it's set at maximum 16.4X. Using Growisofs to burn the DVDs also displays that the application is attempting to burn at 16.4X, but in reality it only averages 2.2X. This is a major issue for my application, as burn times are absolutely critical. 

If I boot my Linux machine using the previous kernel (2.6.27...) I get the maximum burn speeds back. Something has definitely changed in upgrading kernels. I even used the 2.6.27 config file when building the 2.6.28 kernel, so I know all the settings are the same. 

Have there been any fundamental changes in the SCSI driver from 2.6.27-19 to 2.6.28.6? how can I get my top burn speeds back?

Thanks in advance for any help or pointers you can give me. I've trawled the net, but the only posts I have found are for IDE drives, and the top solution is to fiddle with uDMA settings - obviously not an option here.

Best regards,
-- 
Dominic Driver
Engineer
Paragon Electronic Design Limited
Level 2 21-23 Andrews Avenue
ANZ House
PO Box 30-449, Lower Hutt
New Zealand

Direct: +64 4 5703892
Fax: +64 4 5703 871
mailto:dominic.driver@paragon.co.nz
http://www.paragon.co.nz

Re: SCSI Driver Regression and Missing Code Block?

[Matthew Wilcox]

On Wed, Apr 22, 2009 at 12:50:06PM +1200, Dominic Driver wrote:
> Hi Guys,
> 
> I had an interesting experience with my SATA DVD-RW Drives following a Kernel Upgrade from:
> 
> 2.6.27.19-170.2.35.fc10.i686
> to 
> 2.6.28.6 (Vanilla)

One of the problems with trying to diagnose the problem is that you're
going from a distro kernel to a vanilla kernel.  So it's not necessarily
something we've taken out -- it could be something they've put in and
we don't know about.

So it'd be really nice to see if 2.6.27 vanilla behaves like 2.6.28
vanilla or like 2.6.27-fc.  You might also want to try 2.6.29 as Fedora
do backport patches from later kernels.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: SCSI Driver Regression and Missing Code Block?

[Matthew Wilcox]

On Wed, Apr 22, 2009 at 06:35:12PM +1200, Dominic Driver wrote:
> Hi Matthew,
> 
> A look at the Vanilla 2.6.27.19 Kernel reveals that the section of code
> from the Fedora release that I reinserted is NOT present. This must be
> a Fedora patch. From my point of view, it's a very useful addition to
> the IOCTL responses, is it something to consider for inclusion in the
> Vanilla kernels?

It certainly is.  Peter Jones posted the patch to linux-scsi on July
11th last year.  I think it simply got overlooked.  James, you objected
to an earlier version of this patch; any problems with this version?

It appears to have been in Fedora for about six months, so it presumably
doesn't cause much end-user related trouble.


>From e85e03d7f680b62bb8d4d037fdde6dd94c9582a3 Mon Sep 17 00:00:00 2001
From: Peter Jones <pjones@redhat.com>
Date: Wed, 8 Oct 2008 15:10:39 -0400
Subject: [PATCH] make sr_mod report more accurate drive status after closing the door.

So, what's happening here is that the drive is reporting a sense of
2/4/1 ("logical unit is becoming ready") from sr_test_unit_ready(), and
then we ask for the media event notification before checking that result
at all.  The check_media_event_descriptor() call isn't getting a check
condition, but it's also reporting that the tray is closed and that
there's no media.  In actuality it doesn't yet know if there's media or
not, but there's no way to express that in the media event status field.

My current thought is that if it told us the device isn't yet ready, we
should return that immediately, since there's nothing that'll tell us
any more data than that reliably.
---
 drivers/scsi/sr_ioctl.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c
index ae87d08..7ee51ff 100644
--- a/drivers/scsi/sr_ioctl.c
+++ b/drivers/scsi/sr_ioctl.c
@@ -309,6 +309,11 @@ int sr_drive_status(struct cdrom_device_info *cdi, int slot)
 	if (0 == sr_test_unit_ready(cd->device, &sshdr))
 		return CDS_DISC_OK;
 
+	/* SK/ASC/ASCQ of 2/4/1 means "unit is becoming ready" */
+	if (scsi_sense_valid(&sshdr) && sshdr.sense_key == NOT_READY
+			&& sshdr.asc == 0x04 && sshdr.ascq == 0x01)
+		return CDS_DRIVE_NOT_READY;
+
 	if (!cdrom_get_media_event(cdi, &med)) {
 		if (med.media_present)
 			return CDS_DISC_OK;
-- 
1.6.0.1


-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."