Description of problem: 2930 and 2932 had spin-lock out of the gate. I was trying 2932 to test the new nv drv which error on spin-lock, irq-lock, page fault type info data. Before I could write it down it continued and dump more so I was going to reboot into the 2925 kernel when I got the idea that just maybe the irq problem was with the power cycle or always on m/b and nic. So I turned off the power switch, the monitor, and sound base. letting it sit for a couple of minutes. Sure enough, when turned it back on and booted the kernel 2932 came up and it seems to be working (and with the new nv drv?) but the following dump was in dmesgs. Version-Release number of selected component (if applicable): kernel-2.9.20-1.2532 How reproducible: Steps to Reproduce: 1. If kernel dump at boot up power off all equipment and then reboot. 2. May or may not effect everyone. 3. Actual results: System started but with dump in dmesg. Expected results: Additional info: attached txt file
Created attachment 148255 [details] dmesg dump txt
Kernel 2932 can not start up on Pent iv after Feb 17 th updates. BUG bad null pointer. BUG bad irq interrupt and various dumps. It's broke, needs git14. :) Darwin
Created attachment 148422 [details] OOPS - 2.6.20-1.2932.fc7 The kernel 2.6.20-1.2932.fc7 OOPSes when trying to install from the current development tree. The kernel also fails to communicate after geting DHCP reply (see bug #228949).
Created attachment 148423 [details] Today 2.6.20-1.2932 (02-20-2007) OOPS (Installation from devel tree)
Created attachment 148731 [details] kernel 2940 eek trace call Pent iv ht Intel865BGF Darwin
Is this still a problem with the current builds ?
kernel-2.6.20-1.3023.fc7 from FC 6.92 (Test 3) does not work. I'll try current devel tree tomorow (kernel-2.6.20-1.3094.fc7).
kernel-2.6.20-1.3104 (22-4-2007) works OK and atl1 driver works OK too. I tryed to run network installation. Thank you! :-)
On 3104 (on Intel865BGF Pent IV 2.4 ht) the problems have been reduced to 1. Need to press enter on every line in greb to start with normal rhgb quite otherwise (if it fails) (see BZ 23660 - no it is not a grub problem unless the timer and cpu0 not syncing are related?) 2. Shutdown and power off, power off monitor, sound, and then mobo. Wait at least a minute. Reboot usually work 50% of the time. Otherwise; 3. I get a dead stop at hotplug message - try nohotplug (w/o rhgb quite) Or a vga lock (repeat #2. On board intel extreme not used, FX5200 agpx8 being used.) Or just a dump of a second screen. (go into multiple parms until I boot or try #2 again if it takes more than 3 times. ) On the other hand a Pent III slot1 800 Apollo-133 via has only not booted on one kerenl. It runs great. Darwin
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp