Aaron VonderHaar wrote:
When ripping from a scsi device (/dev/sg*) with linux kernel 2.6.11,
my kernel log is filled with messages like
=== dmesg ===
sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in;
program cdparanoia not setting count and/or reply_len properly
printk: 40 messages suppressed.
sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
program cdparanoia not setting count and/or reply_len properly
printk: 128 messages suppressed.
sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
program cdparanoia not setting count and/or reply_len properly
printk: 149 messages suppressed.
sg_write: data in/out 16464/16464 bytes for SCSI command 0xbe--guessing data in;
program cdparanoia not setting count and/or reply_len properly
printk: 153 messages suppressed.
sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
program cdparanoia not setting count and/or reply_len properly
printk: 153 messages suppressed.
=== END ===
After taking a hard look at the cdparanoia code handle_scsi_cmd(), and
the kernel sg driver, I've found the problem is this bit of code in
the kernel,
=== linux/drivers/scsi/sg.c LINE 566 ===
/*
* SG_DXFER_TO_FROM_DEV is functionally equivalent to SG_DXFER_FROM_DEV,
* but is is possible that the app intended SG_DXFER_TO_DEV,
because there
* is a non-zero input_size, so emit a warning.
*/
if (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV)
if (printk_ratelimit())
printk(KERN_WARNING
"sg_write: data in/out %d/%d bytes for
SCSI command 0x%x--"
"guessing data in;\n" KERN_WARNING " "
"program %s not setting count and/or
reply_len properly\n",
old_hdr.reply_len - (int)SZ_SG_HEADER,
input_size, (unsigned int) cmnd[0],
current->comm);
=== END ===
As I said, this is in kernel 2.6.11. I noticed that this piece of
code is absent from 2.6.9, so is presumably a new error-checking
addition, which unfortunately breaks cdparanoia (the following comment
seems to explain why cdparanoia must set the count "incorrectly"),
=== cdparanoia-III-alpha9.8/interface/scsi_interface.c LINE 130 ===
/* The following is one of the scariest hacks I've ever had to use.
The idea is this: We want to know if a command fails. The
generic scsi driver (as of now) won't tell us; it hands back the
uninitialized contents of the preallocated kernel buffer. We
force this buffer to a known value via another bug (nonzero data
length for a command that doesn't take data) such that we can
tell if the command failed. Scared yet? */
=== END ===
With this new warning being logged for nearly every SCSI command
(hundreds of times per second), my system becomes unresponsive and
ripping is considerably slowed.
If I remove the warning code from the kernel and recompile it, ripping
seems to proceed as normal.
I'm not sure what ought to be done about this, but I though I should
at least record my hours' worth of bewilderment for the next person
who googles this error message.
Alan Cox has sent fixes for some of the problems in sg to one of the
maintainers, but they don't seem to be in mainline. Perhaps he could
send them to akpm and see if he is interested in fixing problems. Once
the problem with error reporting is fixed (and that may not be the fix
Alan has devised) by someone then paranoia can get rid of the egregious
hack.
I've expanded the recipients list, perhaps we'll get a status on (a) if
the fix Alan has will cause correct error reporting, and (b) when it can
be put in mainline. The paranoia can clean up its act.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |