From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.10) Gecko/20071213 Fedora/2.0.0.10-3.fc8 Firefox/2.0.0.10 Description of problem: If I boot Fedora and there is a CD/DVD in the drive, the system reboots just before GDM login appears. If the drive is empty on boot, it completes OK. Then if I insert a disc while X is running, the system hangs/freezes and I have to do a hard reset. Or if at a VT/Console it reboots upon insertion. I have tried booting to runlevel 3 and disabling RHGB and watching the system start and it reboots right at the point of the HAL daemon loading. If I do an interactive boot and choose not to start 'haldaemon' the system boots with a disc in the drive. As soon as 'hald' is started from the console, it reboots. I tried running hal-disable-polling --udi /org/freedesktop/Hal/devices/storage_model_DVDRAM_GSA_H66N then starting /sbin/service hald --daemon=yes and it works as expected apart from the media in the DVD-RW drive is not recognised. The drive in question has a SATA interface and make is LG (DVD-RW) Version-Release number of selected component (if applicable): hal-0.5.10-1.fc8 How reproducible: Always Steps to Reproduce: 1. Boot with CD media in drive 2. System reboots at haldaemon startup 3. Take out CD, system boots as expected Actual Results: System rebooted Expected Results: GDM login screen should appear and media should be accessible after insertion Additional info: I have attached the output of lspci -vvxx and dmesg
Created attachment 291077 [details] lspci -vvxx output
Created attachment 291078 [details] 'dmesg' output
Claiming this as while the trigger is udev polling the problem appears to be kernel related DavidZ - is there an easy way to run the polling in init 3 and see if we get a trace before the crash ?
Looks related to the sata_nv 4GB crash Can you boot with mem=3G on the boot line and see if that cures it ?
Adding mem=3G to the grub boot line has cured the problem.
Great. I now know which kernel problem this is.
Strange thing is, it also cures another problem I had, in which when X loads, if I press ctrl+alt+f{x} to switch to a VT, the monitor goes into power save mode, and all I can do is switch back to X on VT7. I don't know if that is related or not. But my video card is a NVIDIA also.
It may be a side effect. Once the disk bug is fixed in a newer kernel then we can find out - it may be another bug tripped by the magic 4G B boundary
A fix for this is targetted for 2.6.24
Update: I have upgraded to kernel 2.6.24.3-12.fc8 and it looks like the problem still remains, however I don't know if an attempt to fix the bug has been made yet. I removed mem=3G from the boot line and booted. This time instead of a reboot, my system just hung on the RHGB fedora boot screen. Adding the parameter back on the boot line cures the problem immediately.
I have exactly the same problem. I found that I can burn cd/dvd normally, without the reboot issue. It only affect dvd/cd with data.
Hello again, Someone on irc channel advised me to use this kernel, to see if it fix the problem: http://koji.fedoraproject.org/koji/buildinfo?buildID=42735 But is does not! I am using the mem=3G hack for now! Thx for the efforts! Ufa
Just to let you know, this issue DOES affect the burning process too, although it appears it was successful.
FYI: "sata_nv: fix ATAPI issues with memory over 4GB (v7) This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode on systems with memory located above 4GB. We need to delay setting the 64-bit DMA mask until the PRD table and padding buffer are allocated so that they don't get allocated above 4GB and break legacy mode (which is needed for ATAPI devices). Also, if either port is in ATAPI mode we need to set the DMA mask for the PCI device to 32-bit to ensure that the IOMMU code properly bounces requests above 4GB, as it appears setting the bounce limit does not guarantee that we will not try to map requests above this point. Reported to fix https://bugzilla.redhat.com/show_bug.cgi?id=351451" I dont know if it will fix our issue (maybe is the same as https://bugzilla.redhat.com/show_bug.cgi?id=351451), but I will test it as soon as my distro release this new kernel. :) See you soon!
Fix now upstream - it is the same fix yes