From: Mauricio Martinez <mauricio@coe.neu.edu>
To: Corey Minyard <minyard@acm.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] 2.4.20 drivers/cdrom/cdu31a.c
Date: Tue, 11 Feb 2003 13:10:39 -0500 (EST) [thread overview]
Message-ID: <Pine.GSO.4.33.0302111235510.29078-100000@Amps.coe.neu.edu> (raw)
In-Reply-To: <3E43D552.8010707@acm.org>
Thanks for your reply. I guess there are still some drives like this
floating around. I can live without it, but it is good to use it in an old
486 as a jukebox and print server :)
Your patch makes much more sense that mine (I have no experience in Linux
driver development), and it makes the drive work *very well* (excellent
transfer rate and no system overload), but only if I remove the last hunk.
This last hunk tries to read again the data with 4 sectors less each time
(i.e. 16,14,12,...,4) which *i think* overloads the buffer leading to an
oops (and even a system reboot without warning!).
Hope this information helps.
-Mauricio
On Fri, 7 Feb 2003, Corey Minyard wrote:
> 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.
> >
> >
> >
>
next prev parent reply other threads:[~2003-02-11 18:00 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
2003-02-11 18:10 ` Mauricio Martinez [this message]
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=Pine.GSO.4.33.0302111235510.29078-100000@Amps.coe.neu.edu \
--to=mauricio@coe.neu.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=minyard@acm.org \
/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;
as well as URLs for NNTP newsgroup(s).