Bug 159185 - kernel locks up when installer reboots
Summary: kernel locks up when installer reboots
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-31 07:22 UTC by Alexandre Oliva
Modified: 2015-01-04 22:19 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-01-13 15:49:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
snapshot taken after install completed and crashed at 80x60 (151.58 KB, image/gif)
2005-06-08 14:44 UTC, Alexandre Oliva
no flags Details

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.


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