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 2. 3. 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 2.0.51.22-r2 (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/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium2 -O3 -pipe" CHOST="i686-pc-linux-gnu" 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" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages notitles sandbox sfperms strict" GENTOO_MIRRORS="http://hazel.tps/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/tps/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" 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" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
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.