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);
next prev parent 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