From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 Description of problem: I AM able to write cds with k3b (thanks!). However, I cannot mount or read CDROMS that have been written. I can take to other computers, or reboot into windows, and can read same disks. This is a Dell Inspiron 8600 and the cdrom is modular. THe system sees it as /dev/hdc. I put the disk in the drive, and it just whirs and whines and never stops detecting itself, so I can't get mount /media/cdrecorder to work. I have had the problem occasionally with FC2, but with FC3T3, I have it all the time. Some info from /var/log/messages Oct 31 11:25:52 pols111 kernel: hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) Oct 31 19:31:18 pols111 kernel: ide1: BM-DMA at 0xbfa8-0xbfaf, BIOS settings: hdc:DMA, hdd:pio Version-Release number of selected component (if applicable): 2.6.99-1.649 How reproducible: Always Steps to Reproduce: 1. Start system 2. Insert data cd into system 3. never can be mounted Actual Results: I'm monitoring /var/log/messages as this happens. Oct 31 23:20:17 pols111 kernel: cdrom: This disc doesn't have any tracks I recognize! Oct 31 23:28:14 pols111 kernel: hdc: irq timeout: status=0xd0 { Busy } Oct 31 23:28:14 pols111 kernel: hdc: irq timeout: error=0xd0LastFailedSense 0x0d Oct 31 23:28:14 pols111 kernel: hdc: DMA disabled Oct 31 23:28:15 pols111 kernel: hdc: ATAPI reset complete Oct 31 23:28:34 pols111 kernel: hdc: irq timeout: status=0xd0 { Busy } Oct 31 23:28:34 pols111 kernel: hdc: irq timeout: error=0xd0LastFailedSense 0x0d [it goes on like that many times over] Oct 31 23:29:54 pols111 kernel: hdc: ATAPI reset complete Oct 31 23:29:58 pols111 kernel: hdc: packet command error: status=0x51 { DriveReady SeekComplete Error } Oct 31 23:29:58 pols111 kernel: hdc: packet command error: error=0x54 Oct 31 23:29:58 pols111 kernel: ide: failed opcode was 100 Oct 31 23:29:58 pols111 kernel: cdrom: open failed. Expected Results: mount! Additional info: I'm claiming this is high priority because people who can't mount cdroms are generally incapable of doing anything useful. I have tried restarting and looking in the bios to see if I need to turn on/off DMA for drives, but there is no such option. When I first installed FC3t3, I used to see the hard disk partitions as /media/idedisk1, but now those disappeared. In the startup info from /var/log/messages, there is one other interesting tidbit. Oct 31 11:25:51 pols111 kernel: hda: max request size: 1024KiB Oct 31 11:25:51 pols111 kernel: hda: 117210240 sectors (60011 MB) w/7884KiB Cache, CHS=16383/255/63, UDMA(100) Oct 31 11:25:51 pols111 kernel: hda:<7>Losing some ticks... checking if CPU frequency changed. Oct 31 11:25:51 pols111 kernel: hda1 hda2 hda3 hda4 <<7>Losing some ticks... checking if CPU frequency changed. Oct 31 11:25:52 pols111 kernel: hda5<7>Losing some ticks... checking if CPU frequency changed. Oct 31 11:25:52 pols111 kernel: hda6<7>Losing some ticks... checking if CPU frequency changed. Oct 31 11:25:52 pols111 kernel: hda7<7>Losing some ticks... checking if CPU frequency changed. Oct 31 11:25:52 pols111 kernel: Losing too many ticks! Oct 31 11:25:52 pols111 kernel: TSC cannot be used as a timesource. Oct 31 11:25:52 pols111 kernel: Possible reasons for this are: Oct 31 11:25:52 pols111 kernel: You're running with Speedstep, Oct 31 11:25:52 pols111 kernel: You don't have DMA enabled for your hard disk (see hdparm), Oct 31 11:25:52 pols111 kernel: Incorrect TSC synchronization on an SMP system (see dmesg). Oct 31 11:25:52 pols111 kernel: Falling back to a sane timesource now. Oct 31 11:25:52 pols111 kernel: hda8 hda9 hda10 hda11 hda12 hda13 hda14 > Oct 31 11:25:52 pols111 kernel: hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) Oct 31 11:25:52 pols111 kernel: Uniform CD-ROM driver Revision: 3.20
I really need help with this. After upgrading to FC3,I still have the same problem that CD's don't mount. The drive grinds away and the /var/log/messages output has this: Nov 8 22:19:13 pols111 kernel: hdc: irq timeout: status=0xd0 { Busy } Nov 8 22:19:13 pols111 kernel: hdc: irq timeout: error=0xd0LastFailedSense 0x0d Nov 8 22:19:13 pols111 kernel: hdc: DMA disabled Nov 8 22:19:14 pols111 kernel: hdc: ATAPI reset complete This happens if the kernel line in grub.conf has /dev/hdc=cdrom or /dev/hdc=ide-cd HOWEVER, here's the new information. If I change it to /dev/hdc=ide-scsi, then I CAN MOUNT CDs! Hooray. However, I can't write them. The warnings at start time say ide-scsi is deprecated and should not be used for cd writing. People keep telling me to turn off autorun and this will go away, but I can't tell which end is up now that there is "hal" and "udev" and "gnome-volume-manager" and all that other stuff monitoring the cdrom. If I could just stop the system from scanning the cdrom, then maybe it would work.
There have been some updates that may help you with the automounting stuff. There have been kernel updates since you filed this bug too. Try making sure you have all the latest updates and see if that helps.
The hal and kernel updates to FC3 resolved this problem for me on 2004-12-2.
I was pre-mature to close this bug. Some CD-R's work, some don't. Factory-made cdrom's work, always. When I closed the bug, it just so happened I was using a CD-R that was written somehow differently than others. The problem is caused by the fact that some CDR devices don't report back to haldaemon the media type, so haldaemon times out. The kernel experts tell me that the long term fix will be in the kernel support for ide-cd devices (you know, in the startup line where it says hdc=ide-cd (or, in the old days before kenel 2.6, hdc=ide-scsi). There are ways to trick haldaemon to leave the cdrom alone, which I think is the best option right now. Short term fix suggested by folks in the fedora-test email list. Turn off haldaemon /sbin/service haldaemon stop mount cd manually mount -t iso9660 /dev/cdrom /media/cdrom When done, use umount as in the old days umount /media/cdrom and if you want haldaemon running, restart it /sbin/service haldaemon start You can change settings in hald.conf to stop it from trying to automount the cdrom. If you do that, then there's no need to kill the daemon.. I've had several people explain the problem to me. I think it is a kernel driver problem in the ide module, the one which we are now told to use for CDR instead of ide-scsi. If you use the kernel ide-scsi, then cdroms will mount fine. Put that in grub.conf, you'll see. However, you can no longer write CDRs with that. On the other hand, if you leave the ide option default (hdc=ide-cd), you can write CDRs, but the haldaemon & kernel can't work together to mount them automatically. This is a problem only because of the CDR format, which apparently does not always fill up the CD to the very end, and so the device which scans the end for information about the media type doesn't get info it wants. At the suggestion of Alan Cox, I started a bug report on the kernel.org. That was a while ago, I've not heard back about it. I've gotten many emails about this problem from other users who found my report in this bugzilla, so I'm just posting this note to calm their nerves and discouraging them from writing to me directly about it, because it is tiring me out to answer those emails.
Thanks for the update.
After applying the kernel upgrades over the past two weeks, this problem has gotten worse. Now, even if I kill the haldaemon and mount with mount -t iso9660 /dev/cdrom /mnt/cdrom the mount fails and the messages file gets this: Feb 8 23:03:36 pols111 haldaemon: haldaemon -TERM succeeded Feb 8 23:04:46 pols111 su(pam_unix)[5536]: session opened for user root by pauljohn(uid=500) Feb 8 23:04:56 pols111 kernel: hdc: irq timeout: status=0xd0 { Busy } Feb 8 23:04:56 pols111 kernel: hdc: irq timeout: error=0xd0 { LastFailedSense=0x0d } Feb 8 23:04:56 pols111 kernel: hdc: DMA disabled Feb 8 23:04:56 pols111 kernel: hdc: ATAPI reset complete Feb 8 23:05:16 pols111 kernel: hdc: irq timeout: status=0xd0 { Busy } Feb 8 23:05:16 pols111 kernel: hdc: irq timeout: error=0xd0 { LastFailedSense=0x0d } Feb 8 23:05:16 pols111 kernel: hdc: ATAPI reset complete Feb 8 23:05:35 pols111 kernel: hdc: irq timeout: status=0xd0 { Busy } Feb 8 23:05:35 pols111 kernel: hdc: irq timeout: error=0xd0 { LastFailedSense=0x0d } Feb 8 23:05:35 pols111 kernel: hdc: ATAPI reset complete Feb 8 23:05:35 pols111 kernel: hdc: tray open Feb 8 23:05:35 pols111 kernel: end_request: I/O error, dev hdc, sector 64 Feb 8 23:05:35 pols111 kernel: isofs_fill_super: bread failed, dev=hdc, iso_blknum=16, block=16 Feb 8 23:05:55 pols111 kernel: hdc: irq timeout: status=0xd0 { Busy } Feb 8 23:05:55 pols111 kernel: hdc: irq timeout: error=0xd0 { LastFailedSense=0x0d } Feb 8 23:05:55 pols111 kernel: hdc: ATAPI reset complete I rebooted into MS Windows and don't have this trouble. Why aren't more people having this problem? Is it my particular model of CDR??
i think i have three manifestations that stem from this same problem, and this is the closest bug i can find (also see bug 145097 and bug 144743) 1) could not install from DVD / CD-ROM with my new hardware. the DVD and CD would boot and, after a significant pause, allow for language, keyboard, and install method prompts - but would then fail to detect the installation media. hw is asus pundit-r, sony dvd PATA hda, maxtor 300GB SATA hdc 2) booting with CD / DVD media in the drive leads to kernel panic: Red Hat nash version 4.1.18 starting Reading all physical volumes. This may take a while... hda: timeout waiting for DMA hda: drive not ready for command Kernel panic - not syncing: drivers/ide/pci/atiixp.c:109: spin_lock(drivers/ide/ide.c:c03795e8) already locked by drivers/ide/ide-io.c/169 and inspecting /var/log/messages shows the last entries: hda: DMA timeout retry hda: timeout waiting for DMA hda: status timeout: status=0xd0 { Busy } ide: failed opcode was: unknown hda: drive not ready for command hda: ATAPI reset complete 3) attempting a mount of CD or DVD media results in a system hang with the last portion of the syslog identical to that above. reproduced with ALL latest FC3 updates and these two kernels: kernel-2.6.10-1.766_FC3 AND kernel-2.6.10-1.1146_FC4 lspci and hdparm output to follow in attachments.
Created attachment 111234 [details] promised hdparm output
Created attachment 111235 [details] promised 'lspci -v' output
not sure what this proves, but for a workaround i can hdparm -d0 /dev/hda to disable DMA for /dev/hda (my CD/DVD) and the haldaemon service auto-mounts the media just fine. is there a way to do this for a single device on the boot line? (not ide=nodma, but does something like hda=nodma work?)
I am seeing the same problem but only intermittently and only with CD-R media, DVD+RW and CD-RW media mount fine. /var/log/messages say: Mar 2 21:12:45 localhost kernel: hdc: irq timeout: status=0xd0 { Busy } Mar 2 21:12:45 localhost kernel: hdc: irq timeout: error=0xd0 { LastFailedSense=0x0d } Mar 2 21:12:45 localhost kernel: hdc: ATAPI reset complete Mar 2 21:13:03 localhost kernel: hdc: irq timeout: status=0xd0 { Busy } Mar 2 21:13:03 localhost kernel: hdc: irq timeout: error=0xd0 { LastFailedSense=0x0d } Mar 2 21:13:03 localhost kernel: hdc: ATAPI reset complete Mar 2 21:13:24 localhost kernel: SELinux: initialized (dev hdc, type iso9660), uses genfs_contexts uname -a: Linux localhost.localdomain 2.6.10-1.766_FC3 #1 Wed Feb 9 23:06:42 EST 2005 i686 i686 i386 GNU/Linux I'm running FC3 and an up-todate system as at 2005-Mar-02 Turning on or off dma on /dev/hdc (my DVD+-RW/CD-RW) does not seem to affect the intermittent mount behaviour. /dev/hdc is an NEC-6100A/6500A DVD/CD writer.
Did some more bug tracking to bug 3362 on kernel.org "ide-cdrom end of media bug" which then led me to http://marc.theaimsgroup.com/?l=linux-ide&m=110485007824374&w=2 which lists an ide-io.c rq->buffer=NULL bug. which led me to a workaround that works (at least for me). The workaround is to turn off DMA access to the CDROM before first DMA-enabled access of the CDROM. DMA is turned on by default for my drive and thus the bug manifests. hdparm -d0 /dev/hdc (as root) turns off DMA on the CDROM for me. Parit Bhargava explains it well in his bug report above to linux-ide. If I understand it correctly, a call to ide_dma_timeout_retry() in linux/drivers/ide/ide-io.c is made when the drive is in DMA, the rq->buffer=NULL bug messes up the internal ide-io data structures which causes ide-cd to go crazy.
I spoke to soon - turning off DMA even before initial access still provides intermmitent mounts. It seems the first few mount are consistently OK then it turns intermittently bad.
(In reply to comment #7) > 1) could not install from DVD / CD-ROM with my new hardware. > the DVD and CD would boot and, after a significant pause, allow > for language, keyboard, and install method prompts - but would > then fail to detect the installation media. I am trying to do a fresh install of FC3 and I have exately the same symptoms as mentioned above. In console 4 it repeats: end_request: I/O error, dev hdc, sector 64 isofs_fill_super: bread failed, dev=hdc, iso_blknum=16, block=16 everytime I ask it to retry my Local CDROM. DMA is turned off for my old SONY 24xCDRom. Does anyone know of a kernel parameter that will allow it to install, at least?
Even though Alan seems to think this is a hal bug (which I really can't fathom but maybe it's just me), I'm curious about the state of this in o FC3 (with all the latest updates) and o Rawhide (with all the latest updates) Thanks!
I dont currently think its HAL btw
In fairness to Alan, he always thought it was really a kernel problem that just manifested through haldaemon. With FC3, on that particular laptop with that particular disk drive, with SOME disks, the only workaround for me is to turn off haldaemon and mount the disk manually. I bought a different modular drive, one that can write DVDs, and it does not have so much trouble mounting disks. I did have to set ide=nodma in order to run the FC4 install, though. I've since learned that may be due to some acpi thing that malfunctions, and turning of dma co-incidentally hits the acpi problem too. I notice the problem arises much less frequently if I create the CD-R using the "dao" option. I've also learned one tidbit. If a disk fails to mount automatically, and then I kill haldaemon, then a manual mount may fail if tried immediately, but if I let the computer sit for an hour, then the manual mount will work. My theory is that when you kill the haldaemon, it does not really stop all those processes that are trying to access the disk. Again, all "factory printed" disks mount autmatically just fine, only the home made ones are dubious, and not all of them, just some. In the absolutely newest kernel for FC4, 2.6.12, I have had 2 total system lockups related to trying to use CD-Rs. There is no message about a kernel panic in the logs, but if I put a disk in and let it automount, and then do cp -R /media/cdrecorder /home/pauljohn The system locks up, no response to keyboard, no error messages, no nothing. If somebody told me how to get a diagnostic on that problem, I would do it once more just to see if it is a related ide problem. I am inclined to think it might be because I snooped in the usenet and there were miscellaneous discussions about the kernel's ide subsystem in 2.6.11->.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
I am running FC4 now and have the same problem. I just upgraded to kernel 2.6.12-1.1398_FC4 and the same thing happens. Sometimes, with some disks, the automounting facility in haldaemon/gnome fails, and dmesg shows this: hdc: irq timeout: status=0xd0 { Busy } ide: failed opcode was: unknown hdc: DMA disabled hdc: ATAPI reset complete hdc: irq timeout: status=0xd0 { Busy } ide: failed opcode was: unknown hdc: ATAPI reset complete The one BIG difference now is that the device quits trying after a while, so a manual mount is possible. Before, it was necessary to manually kill haldaemon. On the other hand, twice I have had total system lockup while trying to manually mount drives while haldaemon is still on. It is a total lock, the screen and keyboard freeze and only the power button can unstick it. So I have learned to turn off haldaemon anyway before manually mounting a drive.
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
This problem is solved with the FC4 updated kernel-2.6.12-1.1456_FC4 and the related other updates. Thanks a lot. I'm marking this as closed.