From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1 Description of problem: After installing the x86_64 kernel-2.6.15-1.1830_FC4 and rebooting, the system gets to probing the IDE ports (apparently successfuly) then spontaneously reboots, making the kernel completely unusable on this playform. No log is available as a result, but the dmesg from the earlier kernel-2.6.14-1.1656_FC4 is attached. Version-Release number of selected component (if applicable): kernel-2.6.15-1.1830_FC4 How reproducible: Always Steps to Reproduce: 1.Reboot 2.Select kernel 2.6.15-1.1830_FC4 3.Watch boot process until IDE probes, then system reboots Actual Results: System reboots during initialization Expected Results: Normal system initialization Additional info: System is an ASUS K8V SE Deluxe with AMD64 3200+ lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] 00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 00:08.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak 378/SATA 378) (rev 02) 00:09.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 11) 00:0a.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) 00:0c.0 Mass storage controller: Promise Technology, Inc. PDC20262 (FastTrak66/Ultra66) (rev 01) 00:0d.0 Serial controller: Siig Inc CyberSerial (1-port) 16550 00:0e.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 00:0e.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: nVidia Corporation NV31 [GeForce FX 5600XT] (rev a1) 02:08.0 FireWire (IEEE 1394): NEC Corporation IEEE 1394 Host Controller (rev 01) 02:09.0 USB Controller: NEC Corporation USB (rev 41) 02:09.1 USB Controller: NEC Corporation USB (rev 41) 02:09.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
Created attachment 124127 [details] Dmesg under earlier kernel
does booting with acpi=off help ?
No, acpi=off has no impact, it still reboots at the same point.
I built the vanilla (kernel.org) 2.6.15.2 kernel with the Fedora kernel-2.6.15-x86_64.config, and the reboot during the boot does not occur. It doesn't appear to be an upstream problem, but rather one of the Fedora patches. If you suspect a particular patch, let me know and I'll back it out.
Created attachment 124341 [details] Serial console boot of kernel-2.6.15-1.1831_FC4, no additional options I managed to get a serial console attached (hard to find a non-"legacy free" laptop these days), and captured the messages up to the spontaneous reboot. On the 2.6.14-1.1656_FC4 kernel, the next messages that would appear at the point of reboot are: Freeing unused kernel memory: 180k freed *** Reboot occurs here on 2.6.15-1.1831_FC4 *** Write protecting the kernel read-only data: 809k SCSI subsystem initialized libata version 1.12 loaded. sata_via version 1.1 ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 sata_via(0000:00:0f.0): routed to hard irq line 5 ata1: SATA max UDMA/133 cmd 0xB000 ctl 0xA802 bmdma 0x9800 irq 5 ata2: SATA max UDMA/133 cmd 0xA400 ctl 0xA002 bmdma 0x9808 irq 5 ata1: SATA link down (SStatus 0) scsi0 : sata_via input: ImPS/2 Generic Wheel Mouse on isa0060/serio1 ata2: SATA link down (SStatus 0) scsi1 : sata_via sata_promise version 1.02 ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 sata_promise PATA port found ata3: SATA max UDMA/133 cmd 0xFFFFC20000004200 ctl 0xFFFFC20000004238 bmdma 0x0 irq 10 ata4: SATA max UDMA/133 cmd 0xFFFFC20000004280 ctl 0xFFFFC200000042B8 bmdma 0x0 irq 10 ata5: PATA max UDMA/133 cmd 0xFFFFC20000004300 ctl 0xFFFFC20000004338 bmdma 0x0 irq 10 ata3: SATA link down (SStatus 0) scsi2 : sata_promise ata4: SATA link down (SStatus 0) scsi3 : sata_promise ATA: abnormal status 0x8 on port 0xFFFFC2000000431C ata5: disabling port scsi4 : sata_promise ieee1394: Initialized config rom entry `ip1394' ohci1394: $Rev: 1313 $ Ben Collins <bcollins> ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[11] MMIO=[fdd00000-fdd007ff] Max Packet=[2048] ACPI: PCI Interrupt 0000:02:08.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 ohci1394: fw-host1: Unexpected PCI resource length of 1000! ohci1394: fw-host1: OHCI-1394 1.1 (PCI): IRQ=[11] MMIO=[fce00000-fce007ff] Max Packet=[65536] ohci1394: fw-host1: Serial EEPROM has suspicious values, attempting to setting m ax_packet_size to 512 bytes sbp2: $Rev: 1306 $ Ben Collins <bcollins> md: raid1 personality registered as nr 3 md: Autodetecting RAID arrays. md: autorun ... md: considering hda3 ... md: adding hda3 ... md: hda2 has different UUID to hda3 md: hda1 has different UUID to hda3 md: adding hdg3 ... md: hdg2 has different UUID to hda3 md: hdg1 has different UUID to hda3 md: created md2 md: bind<hdg3> md: bind<hda3> md: running: <hda3><hdg3> raid1: raid set md2 active with 2 out of 2 mirrors md: considering hda2 ... md: adding hda2 ... md: hda1 has different UUID to hda2 md: adding hdg2 ... md: hdg1 has different UUID to hda2 md: created md1 md: bind<hdg2> md: bind<hda2> md: running: <hda2><hdg2> raid1: raid set md1 active with 2 out of 2 mirrors md: considering hda1 ... md: adding hda1 ... md: adding hdg1 ... md: created md0 md: bind<hdg1> md: bind<hda1> md: running: <hda1><hdg1> raid1: raid set md0 active with 2 out of 2 mirrors md: ... autorun DONE. md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. ieee1394: Host added: ID:BUS[0-00:1023] GUID[00e01800008321d0] ieee1394: Host added: ID:BUS[1-00:1023] GUID[00004c0100000000] security: 3 users, 6 roles, 888 types, 109 bools security: 55 classes, 244139 rules SELinux: Completing initialization. SELinux: Setting up existing superblocks. ...
Created attachment 124342 [details] Serial console boot of kernel-2.6.15-1.1831_FC4, acpi=off, for reference
I'm seeing the same behavior with both kernel-2.6.15-1.1830_FC4 and kernel-2.6.15-1.1831_FC4. kernel-2.6.14-1.1656_FC4 works fine. This is on a AMD64 system.
A little more random information: With kernel-2.6.15-1.1831_FC4 - the boot says "weird, boot CPU (#0) not listed by the BIOS". I'm not sure if that's a normal message though, as in a normal boot (2.6.14-1.1656) the screen flys by too fast to see anything. - the boot hangs for a couple seconds at the second time it says "testing NMI watchdog..." - after the ide lines, and right before reboot, the last line starts with something about a Bug and Spinlock. The line disappears to quickly to see what the rest of it says. Is there anyway to log or slow down the boot messages without figuring out how to get a serial console hook up?
I saw something about a bug on screen as well just before the reboot (which cleared the screen), however it didn't show up on the serial console.
can you try the kernel at http://people.redhat.com/davej/kernels/Fedora/FC-4 ?
1832 Seems to work great for me. Good thing too. I'm so used to using yum to upgrade stuff, that I did rpm -Uvh kernel-blah before remembering that causes erasing off all the old (working) kernels...
Confirming 1832 is working; thanks!
could you check that the -smp kernel reboots as the regular 1381 kernel did? Ideally, I'd like to fix things so that both kernels work. (Esp as FC5 will only ship an SMP kernel for x86-64) If it does reboot, I have a patch that I'd like to try, so I'll get another build done with that once you've confirmed it's also broken in the same way.
Do you want me to try the SMP kernel on a single processor (I don't have an SMP 86_64)? If so, you want: - Boot 1381 SMP kernel on a single processor and confirm reboot problem - Boot 1832 SMP kernel on a single processor and confirm problem corrected Or are you looking for someone with an SMP x86_64 that can recreate the issue?
No, that's exactly what I wanted to know, thanks. I'll be pushing the next FC4 update live later this week once upstream has pushed 2.6.15.5
kernel-smp-2.6.15-1.1832_FC4 works fine for me as well (this is on a uniprocessor system). The only difference I noted, was that the smp kernel paused for a couple seconds at "testing nmi watchdog".