|Summary:||kernel locks up when installer reboots|
|Product:||[Fedora] Fedora||Reporter:||Alexandre Oliva <oliva>|
|Component:||kernel||Assignee:||Dave Jones <davej>|
|Status:||CLOSED RAWHIDE||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-01-13 15:49:05 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Alexandre Oliva 2005-05-31 07:22:27 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4 Description of problem: I've managed to install FC4-re0530.1 on my AMD64 notebook, after overcoming bug 159182. At the end of the install, when the installer was rebooting the system, the kernel printed some oopses containing references to timer and ext3 commit, and then died. This happened twice: once when the installer rebooted after the installer backtrace in bug 159182, once after the bug was worked around and install completed successfully. This problem didn't happen on the i686 box that installed successfully. A few potentially-significant differences, besides the different arch, are that the i686 box isn't using raid at all (the amd64 one has /boot and the volume group containing / in raid 1 physical volumes), and the i686 box doesn't have any firewire-connected disks (the amd64 has two, and one of them holds raid 1 members of the volume group holding the root filesystem, while both of them hold raid 1 members of physical volumes of a separate volume group). Version-Release number of selected component (if applicable): kernel-2.6.11-1.1366_FC4 (FC4-re0530.1) How reproducible: Didn't try Steps to Reproduce: 1.Boot the x86_64 installer on my HP Presario r3004US 2.Reboot after some data is written to the disks Actual Results: Oops on reboot Expected Results: No such oops was present in FC4-re0523.0 Additional info: I've tried one reboot after installing and updating several packages after install was complete, and the oops didn't occur; the box rebooted cleanly. No filesystem corruption seems to have occurred, and no raid resyncing was needed. It's possible that the installer is just leaving some mounted filesystem behind, and the kernel fails to unmount it cleanly.
Comment 1 Alexandre Oliva 2005-05-31 16:20:33 UTC
Got it on i686 (athlon) as well, on 3 other boxes that use raid devices for /boot and for physical volumes containing the root filesystem. It goes like this (typos are all mine): [scrolled out] softlockup_tick+0x86/0x160 timer_interrupt+0x63/0x170 handle_IRQ_event+0x33/0x60 __do_IRQ+0xbc/0x2e0 do_IRQ+0x51/0x90 ======== common_interrupt+0x1a/0x20 delay_pmtmr+0x7/0x20 __delay+0x9/0x10 panic+0x13b/0x1b0 die+0x18b/0x270 do_invalid_op+0x0/0xa0 do_invalid_op+0x91/0xa0 submit_bh+0x133/0x140 mpage_writepages+0x158/0x3c0 recalc_taks_prio+0xd9/0x1b0 __sync_single_inode+0x13e/0x350 __writeback_single_inode+0x22/0x230 error_code+0x4f/0x60 submit_bh+0x133/0x140 sync_dirty_buffer+0x48/0xf0 ext3_put_super+0x14f/0x160 [ext3] generic_shutdown_super+0x83/0x240 kill_block_super+0x1d/0x30 deactivate_super+0x82/0xf0 sys_umount+0x33/0x80 vfs_write+0xa9/0x110 sys_write+0x3c/0x70 syscall_call+0x7/0xb
Comment 2 Dave Jones 2005-06-01 05:41:08 UTC
any chance you can get at the stuff that scrolled off the top ? serial console maybe ?
Comment 3 Alexandre Oliva 2005-06-01 11:47:52 UTC
No serial cable here, and I'm going to be away again until Saturday evening :-(
Comment 4 Alexandre Oliva 2005-06-08 14:44:18 UTC
Created attachment 115222 [details] snapshot taken after install completed and crashed at 80x60 'fraid this is the best I could do without going out to purchase a serial cable. There's a complete trace, but there's a previous trace that's already partially scrolled out.
Comment 5 Alexandre Oliva 2006-01-13 15:49:05 UTC
(Long) fixed in rawhide, AFAICT.