Latest working kernel version: 2.6.24.7 Earliest failing kernel version: 2.6.25.6 (also seen on 2.6.25.4) Distribution: Slackware 12.1 (x86) Hardware Environment: Intel P4 32-bit, 4GB RAM, Lots of HD space, 1xSATA DVD+RW and 1xIDE DVD+RW Software Environment: bash ver. 3.1.17(2), mount ver. 2.13.1 (util-linux-ng) Problem Description: CD/DVD containing valid data fails to mount in SATA DVD+RW drive when mount(8) command issued from console. Instead, "medium not found" message is displayed. After waiting 20-25 seconds and re-issuing mount command, disc mounts fine. This behavior does _not_ occur on IDE DVD+RW drive on same computer, nor did this behavior occur with 2.6.24[.x] or earlier kernels. Discs used to reproduce the problem all have valid data and file systems. Problem can be reproduced with either storebought CDs/DVDs, or CD-R/DVD+/-R containing valid UDF or ISO9660 fs and data. /etc/fstab and udev are all configured appropriately for mount command issued. Steps to reproduce: 1. Ensure no disc is mounted and SATA DVD drive tray is open (extended). Place CD or DVD on tray. 2. In shell: $ mount /media/dvd0 3. Tray closes, but immediately after closing, shell shows message "mount: No medium found" and returns prompt. Disc is not mounted. 4. Re-issuing above mount command in shell within a few (2-4) seconds again gets "mount: No medium found" message and a prompt. Disc remains unmounted. 5. Wait about 20-25 seconds after first mount command issued and retry. Mount will then be successful. Please note that doing the above in 2.6.24.7 (and earlier) would cause the shell to block until the disc was mounted (assuming it was mountable) instead of the "No medium found" messages. The IDE DVD drive on this computer (yes, two DVD burners on the same PC) does _not_ exhibit this behavior, even when running same kernel. Below is a BASH script and its output. /media/dvd0 is the mount point of the SATA drive /dev/sr0, and /media/dvd1 is the mount point of the IDE drive /dev/hdc. ========= demo.sh ========== #!/bin/sh for DRIVE in dvd0 dvd1 do echo while true do echo "$(date +%s.%N) mount /media/${DRIVE}" mount /media/${DRIVE} if [ ${?} -eq 0 ]; then break fi sleep 0.5 done echo "$(date +%s.%N) mount succeeded." echo echo "Contents of /media/${DRIVE} are:" echo "$(ls -1 /media/${DRIVE})" echo done ======== End demo.sh =========== Below is the output of running the above script. Before the script was run, both drive trays were ejected (open). A Debian Etch disc 1 DVD was placed in the /media/dvd0 (SATA) tray, and an Etch disc 2 DVD was placed in the /media/dvd1 (IDE) tray. ======== Output of demo.sh ======== 1213323099.766990388 mount /media/dvd0 mount: No medium found 1213323101.783767667 mount /media/dvd0 mount: No medium found 1213323102.932494608 mount /media/dvd0 mount: No medium found 1213323104.358153665 mount /media/dvd0 mount: No medium found 1213323105.506916265 mount /media/dvd0 mount: No medium found 1213323106.655628941 mount /media/dvd0 mount: No medium found 1213323107.804383561 mount /media/dvd0 mount: No medium found 1213323108.953112140 mount /media/dvd0 mount: No medium found 1213323110.378777718 mount /media/dvd0 mount: No medium found 1213323111.527538089 mount /media/dvd0 mount: No medium found 1213323112.676269230 mount /media/dvd0 mount: No medium found 1213323113.806000861 mount /media/dvd0 1213323118.829925134 mount succeeded. Contents of /media/dvd0 are: README.html README.mirrors.html README.mirrors.txt README.txt autorun.bat autorun.inf debian dists doc install isolinux md5sum.txt pics pool tools 1213323118.927907914 mount /media/dvd1 1213323139.241765949 mount succeeded. Contents of /media/dvd1 are: README.html README.mirrors.html README.mirrors.txt README.txt autorun.bat autorun.inf boot debian dists md5sum.txt pics pool ========== end of output from demo.sh ======== Supporting documentation and debug files can be found at the URLs below: Kernel config: http://www.cs.txstate.edu/~pr1037/kernel-debug/2.6.25.6/config-2.6.25.6-DBUG cpuinfo: http://www.cs.txstate.edu/~pr1037/kernel-debug/2.6.25.6/cpuinfo.txt /etc/fstab file: http://www.cs.txstate.edu/~pr1037/kernel-debug/2.6.25.6/fstab iomem: http://www.cs.txstate.edu/~pr1037/kernel-debug/2.6.25.6/iomem.txt ioports: http://www.cs.txstate.edu/~pr1037/kernel-debug/2.6.25.6/ioports.txt lspci -vvv (as root): http://www.cs.txstate.edu/~pr1037/kernel-debug/2.6.25.6/lspci-vvv.txt kernel modules: http://www.cs.txstate.edu/~pr1037/kernel-debug/2.6.25.6/modules.txt /proc/scsi/scsi: http://www.cs.txstate.edu/~pr1037/kernel-debug/2.6.25.6/scsi.txt output of ver_linux (in /scripts directory of kernel source): http://www.cs.txstate.edu/~pr1037/kernel-debug/2.6.25.6/ver_linux_output.txt All the above files can be viewed as a directory listing at http://www.cs.txstate.edu/~pr1037/kernel-debug/2.6.25.6/ Finally, a small request: I'd like to try to figure this out on my own and propose/submit a patch (assuming this hasn't already been done). I'm sincerely interested in participating in the kernel development/testing process, but I'm new at it. Granted, I've used Linux for around 10 years now (exclusively for 4), but now I'd like to get even more involved. Thank you for your assistance. -Patrick A. Read-
This is probably caused by the use of GET MEDIA EVENT in sr and ide drive status function. This is a real and annoying problem, so if you wanna give a shot at fixing this, please give it some rush. Thanks.
I'm focusing my debugging to the drivers/scsi/sr.{h,c} source files, the sr_test_unit_ready() function in particular, as this is new to 2.6.25. I noticed in the changelog for 2.6.25 that this function is a near-duplication of scsi_test_unit_ready() function, but modified to fix a "wrong characteristic of eating NOT_READY returns". I'm not familiar with the "NOT_READY returns" behavior (but I'm looking into it). I'll be searching through the Documentation tree and the LKML archives for any other info regarding drivers/scsi/sr.{h,c}. If you believe that there is a better place (source code, documents, etc.) to research this issue then please advise... Thank you.
I doubt it's TUR itself. There's linux-scsi discussion thread. http://thread.gmane.org/gmane.linux.scsi/42453