public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Mauricio Martinez <mauricio@coe.neu.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.4.20 drivers/cdrom/cdu31a.c
Date: Fri, 07 Feb 2003 09:48:34 -0600	[thread overview]
Message-ID: <3E43D552.8010707@acm.org> (raw)
In-Reply-To: <Pine.GSO.4.33.0302070833310.15863-100000@Amps.coe.neu.edu>

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

I don't guess anyone I've sent documentation to has taken up support of 
this drive.  It's amazing that any of these things are still running, 
since I think they stop manufacturing them in 1994.  I don't think I 
have a machine that it will even work in any more.  I guess they were 
well-built drives.

The change you are suggesting is probably not the best, you probably 
need to fix it higher up to do multiple requests if nsect is > 4.  I've 
attached a patch.  It compiles, but I obviously can't test it.

Looking through the code, there's obvious SMP problems and a few other 
things.  I have a new machine with an ISA slot (I think), I might try to 
plug it in.

-Corey

Mauricio Martinez wrote:

>This patch fixes the kernel oops while trying to read a data CD. Thanks to
>Brian Gerst and Faik Uygur for your suggestions.
>
>It looks like the variable nblocks must be <= 4 so the read ahead buffer
>size is not exceeded (which is the cause of the oops). Changing its value
>doesn't seem to be the right way, but it makes the device work properly.
>
>Feedback of any sort welcome.
>
>  
>

[-- Attachment #2: linux-cdu31a.diff --]
[-- Type: text/plain, Size: 2463 bytes --]

--- drivers/cdrom/cdu31a.c.old	Fri Feb  7 09:16:08 2003
+++ drivers/cdrom/cdu31a.c	Fri Feb  7 09:42:53 2003
@@ -1341,7 +1341,7 @@
 #endif
 }
 
-/* read data from the drive.  Note the nsect must be <= 4. */
+/* read data from the drive.  Note the nblocks must be <= 4. */
 static void
 read_data_block(char *buffer,
 		unsigned int block,
@@ -1364,7 +1364,7 @@
 	bytesleft = nblocks * 512;
 	offset = 0;
 
-	/* If the data in the read-ahead does not match the block offset,
+	/* If the data in the read ahead does not match the block offset,
 	   then fix things up. */
 	if (((block % 4) * 512) != ((2048 - readahead_dataleft) % 2048)) {
 		sony_next_block += block % 4;
@@ -1384,9 +1384,9 @@
 			       readahead_buffer + (2048 -
 						   readahead_dataleft),
 			       readahead_dataleft);
-			readahead_dataleft = 0;
 			bytesleft -= readahead_dataleft;
 			offset += readahead_dataleft;
+			readahead_dataleft = 0;
 		} else {
 			/* The readahead will fill the whole buffer, get the data
 			   and return. */
@@ -1533,7 +1533,7 @@
 
 /*
  * The OS calls this to perform a read or write operation to the drive.
- * Write obviously fail.  Reads to a read ahead of sony_buffer_size
+ * Writes obviously fail.  Reads to a read ahead of sony_buffer_size
  * bytes to help speed operations.  This especially helps since the OS
  * uses 1024 byte blocks and the drive uses 2048 byte blocks.  Since most
  * data access on a CD is done sequentially, this saves a lot of operations.
@@ -1546,6 +1546,7 @@
 	unsigned int res_size;
 	int num_retries;
 	unsigned long flags;
+	char *buffer;
 
 
 #if DEBUG
@@ -1616,6 +1617,7 @@
 
 		block = CURRENT->sector;
 		nblock = CURRENT->nr_sectors;
+		buffer = CURRENT->buffer;
 
 		if (!sony_toc_read) {
 			printk("CDU31A: TOC not read\n");
@@ -1695,8 +1697,17 @@
 				}
 			}
 
-			read_data_block(CURRENT->buffer, block, nblock,
-					res_reg, &res_size);
+			if (nblock >= 4) {
+				read_data_block(buffer, block, 4,
+						res_reg, &res_size);
+				nblock -= 4;
+				block += 4;
+				buffer += 4 * 512;
+			} else {
+				read_data_block(buffer, block, nblock,
+						res_reg, &res_size);
+				nblock = 0;
+			}
 			if (res_reg[0] == 0x20) {
 				if (num_retries > MAX_CDU31A_RETRIES) {
 					end_request(0);
@@ -1714,6 +1725,8 @@
 					     translate_error(res_reg[1]),
 					     block, nblock);
 				}
+				goto try_read_again;
+			} else if (nblock > 0) {
 				goto try_read_again;
 			} else {
 				end_request(1);

  reply	other threads:[~2003-02-07 15:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-07 13:43 [PATCH] 2.4.20 drivers/cdrom/cdu31a.c Mauricio Martinez
2003-02-07 15:48 ` Corey Minyard [this message]
2003-02-11 18:10   ` Mauricio Martinez
2003-02-11 18:52     ` Corey Minyard
2003-02-14 13:53       ` Mauricio Martinez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E43D552.8010707@acm.org \
    --to=minyard@acm.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mauricio@coe.neu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox