Bug 179917 - Reboot after IDE probe with kernel-2.6.15-1.1830_FC4
Reboot after IDE probe with kernel-2.6.15-1.1830_FC4
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-03 16:03 EST by Mace Moneta
Modified: 2015-01-04 17:24 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-04 15:30:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Dmesg under earlier kernel (22.69 KB, text/plain)
2006-02-03 16:05 EST, Mace Moneta
no flags Details
Serial console boot of kernel-2.6.15-1.1831_FC4, no additional options (8.33 KB, text/plain)
2006-02-07 16:29 EST, Mace Moneta
no flags Details
Serial console boot of kernel-2.6.15-1.1831_FC4, acpi=off, for reference (7.03 KB, text/plain)
2006-02-07 16:30 EST, Mace Moneta
no flags Details

  None (edit)
Description Mace Moneta 2006-02-03 16:03:14 EST
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)
Comment 1 Mace Moneta 2006-02-03 16:05:59 EST
Created attachment 124127 [details]
Dmesg under earlier kernel
Comment 2 Dave Jones 2006-02-03 16:37:16 EST
does booting with acpi=off help ?
Comment 3 Mace Moneta 2006-02-03 16:54:49 EST
No, acpi=off has no impact, it still reboots at the same point.
Comment 4 Mace Moneta 2006-02-05 11:21:19 EST
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.
Comment 5 Mace Moneta 2006-02-07 16:29:10 EST
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@debian.org>
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@debian.org>
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.
...
Comment 6 Mace Moneta 2006-02-07 16:30:31 EST
Created attachment 124342 [details]
Serial console boot of kernel-2.6.15-1.1831_FC4, acpi=off, for reference
Comment 7 Andy Loening 2006-02-08 12:45:42 EST
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.

Comment 8 Andy Loening 2006-02-08 13:06:28 EST
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?
Comment 9 Mace Moneta 2006-02-08 13:57:13 EST
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.
Comment 10 Dave Jones 2006-02-19 00:36:27 EST
can you try the kernel at http://people.redhat.com/davej/kernels/Fedora/FC-4 ?
Comment 11 Andy Loening 2006-02-19 02:10:30 EST
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...
Comment 12 Mace Moneta 2006-02-19 10:57:42 EST
Confirming 1832 is working; thanks!
Comment 13 Dave Jones 2006-02-23 21:13:28 EST
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.
Comment 14 Mace Moneta 2006-02-23 21:39:18 EST
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?
Comment 15 Dave Jones 2006-02-27 00:15:05 EST
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
Comment 16 Andy Loening 2006-03-01 20:12:38 EST
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".

Note You need to log in before you can comment on or make changes to this bug.