| Summary: | Device not ready. Make sure there is a disc in the drive. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Thomas Schweikle <tps> |
| Component: | [OLD] Core system | Assignee: | Daniel Drake (RETIRED) <dsd> |
| Status: | RESOLVED LATER | ||
| Severity: | major | CC: | kernel |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=3173d8c342971a03857d8af749a3f57da7d06b57;hp=ba482ef4b16bad5172d2be693d4b2420b84c84e7 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Kernel configuration used for kernel 2.6.11-r9
Loaded modules |
||
|
Description
Thomas Schweikle
2005-08-28 03:57:49 UTC
Created attachment 67057 [details]
Kernel configuration used for kernel 2.6.11-r9
Kernel configuration used for kernel 2.6.11-r9. Loaded modules:
tulip
psmouse
ieee1394
ohci1394
I suspect this has nothing to do w/ kernel but rather w/ broken KDE. See Bug 98668 . I have these too, if I do not use KDE, but twm. I suspect it is related to hotpluging and autodetecting cdrom inserts. Maybe it is a problem related to having more than one cdrom in the system. I could not find this having only one cdrom. On some systems it does not occure with more cdrom, on some it does. But apart from these suggestons: the kernel should report which device it expects to be equiped with media! This message comes from the Compaq Fibre Channel 64-bit/66Mhz HBA driver which is known to be broken, it can't be compiled unless you disable the "Select only drivers expected to compile cleanly" option This can not be the only one exausting this message. The driver isn't loaded even if I've compiled it as module. I have attached what modules are loaded. There is no Compaq Fiber Channel 64-Bit/66Mhz HBA installed. Created attachment 67125 [details]
Loaded modules
There is no Compaq Fiber Channel 64-Bit/66MHz HBA installed.
When you refer to the "kernel message log", what log exactly are you talking about? Do these messages also appear in "dmesg"? There is no other place in the kernel that prints this message. Also, you can't judge it on the basis that the module isnt loaded. This driver is old and broken and when you attempt to modprobe it, it probably will print this message and return failure - refusing to load the module at all. To #7: yes: dmesg was meant.
To #8: There must be. This driver isn't even compiled: "SCSI_CPQFCTS" is missing
from the config file! AFAIK the driver defaults to "no" and thus is not
available at all. A quick prove: "find /lib/modules/2.6.11-gentoo-r9/ -iname
'cpqf*'" -> no output.
Thus: this string *can not* be related to this driver! A simple search gave:
find . -type f -exec grep -Hi 'Device not ready. Make sure there is a disc in
the drive.' {} \;
Binary file ./vmlinux matches
Binary file ./.tmp_vmlinux1 matches
Binary file ./.tmp_vmlinux2 matches
Binary file ./drivers/built-in.o matches
Binary file ./drivers/scsi/scsi_ioctl.o matches
Binary file ./drivers/scsi/built-in.o matches
Binary file ./drivers/scsi/scsi_mod.o matches
Binary file ./arch/i386/boot/compressed/vmlinux.bin matches
Or in short: this string is somewhere build up inside the scsi-subsystem.
Looking closer takes you to scsi_ioctl.c:
yew scsi # find . -type f -exec grep -Hi 'Device not ready' {} \;
./scsi_transport_spi.c: * (reservation conflict, device not ready, etc) just
./scsi_error.c: * 0 - Device is ready. 1 - Device NOT ready.
./scsi_error.c: * 0 - Device is ready. 1 - Device NOT ready.
Binary file ./scsi_ioctl.o matches
./cpqfcTSinit.c: printk(KERN_INFO "Device not ready. Make sure
there is a disc in the drive.\n");
./scsi_ioctl.c: printk(KERN_INFO "Device not ready. Make
sure"
Binary file ./built-in.o matches
Binary file ./scsi_mod.o matches
Looking again a bit closer inside scsi_ioctl.c. The marked lines are exausting
this string:
static int ioctl_internal_command(struct scsi_device *sdev, char *cmd,
int timeout, int retries)
{
struct scsi_request *sreq;
int result;
struct scsi_sense_hdr sshdr;
SCSI_LOG_IOCTL(1, printk("Trying ioctl with scsi command %d\n", *cmd));
sreq = scsi_allocate_request(sdev, GFP_KERNEL);
if (!sreq) {
printk(KERN_WARNING "SCSI internal ioctl failed, no memory\n");
return -ENOMEM;
}
sreq->sr_data_direction = DMA_NONE;
scsi_wait_req(sreq, cmd, NULL, 0, timeout, retries);
SCSI_LOG_IOCTL(2, printk("Ioctl returned 0x%x\n", sreq->sr_result));
if ((driver_byte(sreq->sr_result) & DRIVER_SENSE) &&
(scsi_request_normalize_sense(sreq, &sshdr))) {
switch (sshdr.sense_key) {
case ILLEGAL_REQUEST:
if (cmd[0] == ALLOW_MEDIUM_REMOVAL)
sdev->lockable = 0;
else
printk(KERN_INFO "ioctl_internal_command: "
"ILLEGAL REQUEST asc=0x%x ascq=0x%x\n",
sshdr.asc, sshdr.ascq);
break;
>>> case NOT_READY: /* This happens if there is no disc in drive */
>>> if (sdev->removable && (cmd[0] != TEST_UNIT_READY)) {
>>> printk(KERN_INFO "Device not ready. Make sure"
>>> " there is a disc in the drive.\n");
>>> break;
}
case UNIT_ATTENTION:
if (sdev->removable) {
sdev->changed = 1;
sreq->sr_result = 0; /* This is no longer
considered an error */
break;
}
default: /* Fall through for non-removable media */
printk(KERN_INFO "ioctl_internal_command: <%d %d %d "
"%d> return code = %x\n",
sdev->host->host_no,
sdev->channel,
sdev->id,
sdev->lun,
sreq->sr_result);
scsi_print_req_sense(" ", sreq);
break;
}
}
result = sreq->sr_result;
SCSI_LOG_IOCTL(2, printk("IOCTL Releasing command\n"));
scsi_release_request(sreq);
return result;
}
The question: from where is this function triggered? Hotplug?
Ah, missed that due to the linewrap. Am I right in saying you can reproduce the error by running "touch /dev/scd0" when a CD is not inserted? Yes, I can. I've compiled a kernel with debug simbols now, allowing to trace waht is going on. This showed two things: 1. hotplug is checking all few seconds if there is a disk in one of the CDROM drives, triggering the log entry. 2. I am not sure why this entry is ever entered to the log. Reading the code this shouldn't be done (if I interpret it correctly), since a CDROM is "removable". Maybe the cd-writer isn't correctly tagged being "removable"? The code logic says: if (device is removable and command wasnt TEST_UNIT_READY) then print "Device not ready. Make sure there is a disc in the drive." Yes, but SCSI-Traces tell "TEST_UNIT_READY" being used. The actual seen code isn't "TEST_UNIT_READY". Thus the message is printed. AFAIK there are two possibilities: 1. TEST_UNIT_READY was somewhere redefined, different parts of the kernel using different values. 2. hotplug doesn't use TEST_UNIT_READY to find out if there is a disk in the drive. 3. The hardware does not faciliate TEST_UNIT_READY, responding with an error, which in tune isn't handled correctly. Well, a command is obviously being sent alongside TEST_UNIT_READY which isn't a TEST_UNIT_READY - this should be fairly obvious from the debug logs, where it says "Trying ioctl with scsi command xy" right before "Device not ready. Make sure there is a disc in the drive." By the way, I doubt hotplug is the cause of this, I don't think hotplug polls devices in this way. Its likely to be KDE's drive watching thing, or GNOME's hal, or something similar. Please try this patch: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=3173d8c342971a03857d8af749a3f57da7d06b57;hp=ba482ef4b16bad5172d2be693d4b2420b84c84e7 Please reopen when you respond to comment #15 Yes, the patch quietens these messages, but as of my reading these messages shouldn't be exausted with the original unpatched routine, since it is only printed if the device is removable *and* the command used was *not* TEST_UNIT_READY. For me it looks like the command used to test unit readyness is not TEST_UNIT_READY. There must be an error somewhere else. At the moment I am looking into the different hotplug handling routines. AFAIK some of them use other commands than TEST_UNIT_READY to find out if there is something inserted into a CDROM drive. The fix provided doesn't cure what is wrong, but makes it invisible. It's quite normal for other commands to follow a TEST_UNIT_READY. Testing on a usb-storage device, I touch the device node and it recieves a TEST_UNIT_READY, which my driver reports error and sets some sense bits, then it recieves a REQUEST_SENSE where the driver then reports the "no media present" sense magic, then the SCSI subsytem figures it out. This is just an example, I have no idea if it has relevence here. Just because other commands are being executed does not mean something is wrong. This patch was written to solve this exact issue, by the SCSI maintainer, I'm pretty certain it is the correct fix and will merge into gentoo-sources. If you are still interested for your own understanding on what is going on, it should be easy to enable scsi logging so that the SG_LOG_IOCTL calls take effect, making it very obvious which commands are being executed. Actually, as this patch has dependencies on other patches I am going to leave it for now as this is a non-critical problem (unless of course you'd like to simplify it to apply against 2.6.13, it may be easy but I have no way of testing). Otherwise it will be fixed in 2.6.14. |
