Description of problem: Fedora 12 freezes when booting 2.6.32.9-67 Version-Release number of selected component (if applicable): 2.6.32.9-67 How reproducible: Happens everytime I try to boot with 2.6.32.9-67 Steps to Reproduce: 1. Select 2.6.32.9-67 from the grub boot menu 2. 3. Actual results: The screen freezes at the usb5 device screen and doesn't respond to ctrl+alt+del Expected results: Boot into Fedora 12 gnome Additional info: Fedora works fine when booting 2.6.31.12-174.2.22 in the grub menu. I tried looking in the logs to find where it stopped but I didn't see anything.
System does boot, however it takes 20mins to do so. I thought I was running a overheating 386 it was so slow. When it finally made it into x-windows the network card didn't get a ip address. I am using nvidia driver NVIDIA-Linux-x86_64-190.53 instead of the open source. Here are a few places that took 3 minutes to process through. Clocksource tsc unstable (delta = 300016037024 ns) dracut: Starting plymouth daemon dracut: rd_NO_DM: removing DM RAID activation dracut: rd_NO_MD: removing MD RAID activation firewire_core: created device fw0: GUID 001af7730000241d, S400 SELinux: 8192 avtab hash slots, 154319 rules. I have the dmesg, boot, and Xorg files from /var/log directory if you want me to post them.
Today I had a similar problem with the kernel 2.6.32.9-67, I added a iommu=soft as kernel parameter and this solved the problem for me. Of course 'iommu=soft' is only a workaround...
(In reply to comment #2) > Today I had a similar problem with the kernel 2.6.32.9-67, I added a > > iommu=soft > > as kernel parameter and this solved the problem for me. > > Of course 'iommu=soft' is only a workaround... Thanks for info JM. I rebooted and tried the kernel parameter but it still got stuck at the clocksource tsc unstable on 2.6.32.9-67 and 2.6.32.9-70. Just my luck it wouldn't be that simple.
System specs AMD Phenom(tm) II X4 810 Processor GA-MA790XT-ud4p mobo 4gb of ram GeForce GTX 260
found this in dmesg pci 0000:00:13.0: OHCI: BIOS handoff failed (BIOS bug?) 00000184
Dell Latitude won't boot on 2.6.32 kernels -- has encrypted disk problems I always boot in verbose mode. When the first screen comes up after selecting which kernel to boot, the screen that sits for a second or two before overwriting some of the lines, the very first line says "at4 failed" or something similar. Happens so fast it's hard to catch. Now the screen starts that lists all the boot details. The first thing that happens is I'm requested for the password that unlocks the /home directory, which is normal. I enter the password, and hit return. A series of "failed lp" messages (or something similar -- I'll have more time to go back later) follows, and then I'm asked again for the password for the encrypted partition. Now I'm in an endless loop where I enter the password and the response is that it's the wrong key. Hit Cntl-Alt-Del to reboot and select a 2.6.31 kernel which boots OK.
More details on Dell Latitude. When booting a 2.6.31 kernel, the first line says booting fedora <kernel version> which does not change until moving to the next screen. For a 2.6.32 kernel, the top line morphs into something like at4: failed to resume link SControl0 before moving to the next screen. The next screen now shows a series of errors: ln: creating symbolic link /dev/stdn Permission denied <Repeat same error for /dev/stout, /dev/stderr , /dev/core> /bin/mknod /dev/lp0 Permission denied /bin/chown cannot access lp0 No such file or directory <Repeat the above two lines for lp1, lp2, lp3> udevd [636] error creating queue file udevd [638] error sening message - connection refused <Repeat the above line for [640] and [641]> Set host name to bob [OK] Unable to make device from temporary-cryptsetup-661 /dev/mapper/temporary-cryptsetup-661: open failed. No such device or directory. It's at this point where I reboot. Is this an encrypted disk problem, or could it be that the kernel is completing failing to access the disk at all? Only /home is encrypted.
(In reply to comment #7) > More details on Dell Latitude. > > When booting a 2.6.31 kernel, the first line says > booting fedora <kernel version> > which does not change until moving to the next screen. For a 2.6.32 kernel, the > top line morphs into something like > at4: failed to resume link SControl0 > before moving to the next screen. > > The next screen now shows a series of errors: > ln: creating symbolic link /dev/stdn Permission denied > <Repeat same error for /dev/stout, /dev/stderr , /dev/core> > > /bin/mknod /dev/lp0 Permission denied > /bin/chown cannot access lp0 No such file or directory > <Repeat the above two lines for lp1, lp2, lp3> > > udevd [636] error creating queue file > udevd [638] error sening message - connection refused > <Repeat the above line for [640] and [641]> > > Set host name to bob [OK] > Unable to make device from temporary-cryptsetup-661 > /dev/mapper/temporary-cryptsetup-661: open failed. No such device or directory. > > It's at this point where I reboot. Is this an encrypted disk problem, or could > it be that the kernel is completing failing to access the disk at all? Only > /home is encrypted. Easiest way to find out if it is a encryption problem is to make another partition copy your home dir over there and edit your fstab to reflect the change. You could also move your /home directory to root if you don't have free space to make a partition.
The failure to boot continues for all 2.6.32 kernels. My conclusion is that the kernel is failing to read (or find) the disk when it says: at4: failed to resume link SControl10 This is a MAJOR problem for me. I've been on Fedora since FC2 and, unless this is fixed, I will not make the transition to FC13.
2.6.32.11-99.fc12 has the same problem.
Kernel 2.6.32.10-90.fc12.x86_64 , 2.6.32.9-70.fc12.x86_64 , 2.6.32.11-99.fc12.x86_64 all have the same problem. The boot goes through the normal start on initialize of hardware. It will usually stall at Serial: 8250/16550 driver, 4 ports. If I hit the power button it will go until it hits ohci_hcd 0000:00:13.1 irq 18, io mem 0xfe02a000. If I hit the power button again it will go to the Interactive part of the boot process. I can hit the any key on the keyboard and it will go to the next line after I get to the udev part. I uninstalled nvidia driver but that didn't affect the issue. I tried putting the following in kernel line of grub. Clocksource=acpi_pm and clocksource=hpet. Both didn't affect the issue. I tried putting notsc in the kernel line which didn't do anything. I have a work around which is put acpi=off in the kernel line of grub. I don't have any stalling problems. Before I put acpi=off in the grub the stalling also happened at shutdown and restarting. A side note is that I tried the latest Fedora 13 Beta and had the same issue. I have three 7200.11 Seagate hdd raid5. If I took them out of the machine it booted fine but then I couldn't install to them. I don't know what they did in 2.6.32 and 2.6.33 but I hope they get it fixed by 2.6.34. If anything is need I guess shoot me email. Hope this solution works for any one else having the problem.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: Upgrading Fedora 12 64bit to new 2.6.32 kernels Consequence: After selecting kernel in grub the boot process stalls and take about 15 minutes to complete. Shutdown takes 6 minutes to complete. Fix: put acpi=off in the kernel line of grub Result: The computer boots and shuts down properly
I had not done a clean install on my computer since maybe FC8. After a clean install of FC12 and the latest kernel, computer is working as it should be. That is, all the problems I was encountering per my posts above have disappeared. Dell Latitude D630.
After another view of the log I saw that the agpart driver was loading and then I would get the clocksource error. I did a little googling and put this in my grub.conf file. iommu=noagp,noaperture The computer booted up normally. For some reason it thinks I have a agp card when I have a pci express 2.0. I didn't have this issue in 2.6.31 kernels.
Created attachment 416959 [details] Smolt Profile, system specs
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -2,6 +2,6 @@ Consequence: After selecting kernel in grub the boot process stalls and take about 15 minutes to complete. Shutdown takes 6 minutes to complete. -Fix: put acpi=off in the kernel line of grub +Fix: put iommu=noagp,noaperture in the kernel line of grub Result: The computer boots and shuts down properly
Created attachment 416961 [details] dmesg without iommu=noagp,noaperture in grub
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -2,6 +2,6 @@ Consequence: After selecting kernel in grub the boot process stalls and take about 15 minutes to complete. Shutdown takes 6 minutes to complete. -Fix: put iommu=noagp,noaperture in the kernel line of grub +Fix: put acpi=off in the kernel line of grub Result: The computer boots and shuts down properly
(In reply to comment #14) > After another view of the log I saw that the agpart driver was loading and then > I would get the clocksource error. I did a little googling and put this in my > grub.conf file. iommu=noagp,noaperture The computer booted up normally. For > some reason it thinks I have a agp card when I have a pci express 2.0. I > didn't have this issue in 2.6.31 kernels. Disregard this after rebooting the stalling began so this didn't fix the issue.
Issue also affects 2.6.32.12-115.fc12.x86_64 and 2.6.32.14-127.fc12.x86_64
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.