Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 104017 - Device not ready. Make sure there is a disc in the drive.
Summary: Device not ready. Make sure there is a disc in the drive.
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Daniel Drake (RETIRED)
Depends on:
Reported: 2005-08-28 03:57 UTC by Thomas Schweikle
Modified: 2005-09-29 02:58 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

Kernel configuration used for kernel 2.6.11-r9 (config,51.55 KB, text/plain)
2005-08-28 04:06 UTC, Thomas Schweikle
Loaded modules (modules.txt,2.28 KB, text/plain)
2005-08-28 18:46 UTC, Thomas Schweikle

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Schweikle 2005-08-28 03:57:49 UTC
The message "Device not ready. Make sure there is a disc in the drive." is
entered every few seconds into kernel message log. The log is messed up with
this message and unusable, since the ring buffer fills up, old entrys are
deletet. Sometimes this is the only entry I have!

Extremely bad: what device? The message: "Device not ready. Make sure there is a
disc in the drive." does not tell anything about it!

This is for kernel
- 2.6.11-r9
- 2.6.12-r9

Reproducible: Always
Steps to Reproduce:
1. Install Gentoo 2005.1

Actual Results:  
All few seconds a new entry "Device not ready. Make sure there is a disc in the
drive." is entered into the kernel log.

Expected Results:  
The message should have had entered only one time.
The message should include the device expected to have a disk inserted.

Portage (default-linux/x86/2005.1, gcc-3.4.3, glibc-2.3.5-r1,
2.6.11-gentoo-r9 i686)
System uname: 2.6.11-gentoo-r9 i686 Pentium II (Deschutes)
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
CFLAGS="-march=pentium2 -O3 -pipe"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.1/share/config
/usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown
/usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref
/usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium2 -O3 -pipe"
FEATURES="autoconfig distlocks fixpackages notitles sandbox sfperms strict"
USE="x86 X alsa apache2 apm arts avi bitmap-fonts browserplugin cdr crypt cups
curl eds emboss encode esd fam flac foomaticdb fortran gd gdbm gif gpm gstreamer
gtk gtk2 imagemagick imlib ipv6 java jpeg junit kde ldap libg++ libwww
linguas_de linguas_en linguas_fr mad mikmod motif mozcalendar mozdevelop mozilla
mozsvg mozxmlterm mp3 mpeg ncurses netboot nls nptl ogg oggvorbis opengl oss pam
pdflib perl png python qt quicktime readline ruby samba sdl slang snmp softmmu
speex spell ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts
vorbis xine xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Comment 1 Thomas Schweikle 2005-08-28 04:06:38 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:
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2005-08-28 05:36:33 UTC
I suspect this has nothing to do w/ kernel but rather w/ broken KDE. See Bug 98668 .
Comment 3 Thomas Schweikle 2005-08-28 09:36:37 UTC
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

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!
Comment 4 Daniel Drake (RETIRED) gentoo-dev 2005-08-28 13:08:05 UTC
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
Comment 5 Thomas Schweikle 2005-08-28 18:44:31 UTC
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.
Comment 6 Thomas Schweikle 2005-08-28 18:46:54 UTC
Created attachment 67125 [details]
Loaded modules

There is no Compaq Fiber Channel 64-Bit/66MHz HBA installed.
Comment 7 Daniel Drake (RETIRED) gentoo-dev 2005-08-29 02:16:38 UTC
When you refer to the "kernel message log", what log exactly are you talking
about? Do these messages also appear in "dmesg"?
Comment 8 Daniel Drake (RETIRED) gentoo-dev 2005-08-29 02:20:19 UTC
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.
Comment 9 Thomas Schweikle 2005-08-29 10:27:42 UTC
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
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;
                                printk(KERN_INFO "ioctl_internal_command: "
                                       "ILLEGAL REQUEST asc=0x%x ascq=0x%x\n",
                                       sshdr.asc, sshdr.ascq);
>>>             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 */
                default:        /* Fall through for non-removable media */
                        printk(KERN_INFO "ioctl_internal_command: <%d %d %d "
                               "%d> return code = %x\n",
                        scsi_print_req_sense("   ", sreq);

        result = sreq->sr_result;
        SCSI_LOG_IOCTL(2, printk("IOCTL Releasing command\n"));
        return result;

The question: from where is this function triggered? Hotplug?
Comment 10 Daniel Drake (RETIRED) gentoo-dev 2005-09-01 12:12:55 UTC
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?
Comment 11 Thomas Schweikle 2005-09-02 01:42:33 UTC
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"?
Comment 12 Daniel Drake (RETIRED) gentoo-dev 2005-09-02 05:34:30 UTC
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."
Comment 13 Thomas Schweikle 2005-09-02 05:50:34 UTC
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

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.
Comment 14 Daniel Drake (RETIRED) gentoo-dev 2005-09-02 06:11:05 UTC
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.
Comment 16 Daniel Drake (RETIRED) gentoo-dev 2005-09-29 01:13:47 UTC
Please reopen when you respond to comment #15
Comment 17 Thomas Schweikle 2005-09-29 01:45:16 UTC
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.
Comment 18 Daniel Drake (RETIRED) gentoo-dev 2005-09-29 02:42:55 UTC
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.
Comment 19 Daniel Drake (RETIRED) gentoo-dev 2005-09-29 02:58:56 UTC
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.