On Sat, 22 Jul 2000, Joerg Schilling wrote:
You definitely should send a bug report to the Linux SCSI kernel group
for this bug.
For your final information a attach a email from Dough which solves
the problem.
--
ciao
norb
+---+
| Norbert Preining http://www.logic.at/people/preining |
| University of Technology Vienna, Austria[EMAIL PROTECTED] |
| DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key |
+---+
From [EMAIL PROTECTED] Tue Jul 25 02:39:12 2000
Received: from gear.torque.net (IDENT:[EMAIL PROTECTED] [204.138.244.1])
by alpha.logic.tuwien.ac.at (8.9.3/8.9.3) with ESMTP id CAA11773
for [EMAIL PROTECTED]; Tue, 25 Jul 2000 02:39:11 +0200 (MET DST)
Received: from torque.net (dial3.torque.net [204.138.244.13])
by gear.torque.net (8.9.3/8.9.3) with ESMTP id UAA06328;
Mon, 24 Jul 2000 20:39:08 -0400
Sender: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Date: Mon, 24 Jul 2000 20:42:15 -0400
From: Douglas Gilbert [EMAIL PROTECTED]
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.0-test4 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Matthew Dharm [EMAIL PROTECTED]
CC: Norbert Preining [EMAIL PROTECTED]
Subject: [FIX?] kernel oops with sandisk/cdrecord/???
References: [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: RO
X-Status: A
Content-Length: 2032
Lines: 51
Matthew Dharm wrote:
Okay... here is the first section of that last set of logs you sent us
where things begin to look bad.
The command is INQUIRY, and we're requesting 0x24 bytes (36 bytes).
However, we provide an allocation of 512 bytes. The driver sends the
command and then attempts to transfer the data.
It manages to put 56 bytes into the buffer (which is strange, but _should_
be legal since we have a 512 byte allocation). We manage to exchange
status information, and then return with a good result code.
Then, it looks like __free_pages_ok() goes bad when it notices that
page-mapping != NULL. At this point, I have no idea what's going on. As
far as I can tell, usb-storage is operating just fine.
Following Doug's suggestion, I looked for places where the driver might be
altering the information about the scatter-gather segments. I can't seem
to find any. I'm pretty careful about not messing with those data
structures, as I know they are managed by another part of the kernel.
Doug, do you have any more ideas?
Matthew,
Yes!! In file:
/usr/src/linux/drivers/usb/storage/protocol.c
The processing of a SCSI INQUIRY assumes it will never
get a scatter gather list and has lines like this:
((unsigned char *)us-srb-request_buffer)[2] |= 0x2;
Notice if it _was_ given a scatter gather list [cause
sg is/was warped] then it would turn a 0th element address
like 0xc59d8000 into 0xc59f8000 just as the sg's debug
indicated. It wouldn't happen all the time because that
bit may already be set.
Rather than Matthew staying up all night making
protocol.c scatter gather aware, how about Norbert
fetches my latest sg driver (version 3.1.16) in
a tarball from the table in:
http://www.torque.net/sg
and trying it. It will fix this problem (I hope).
[That version has been out for 2 weeks but I haven't
got it into 2.4 yet, the corresponding fix is in
2.2.17pre? as a related problem broke the sym53c416
driver.]
Apologies for all the excitement.
Doug Gilbert
PGP signature
