|
Bugzilla – Full Text Bug Listing |
| Summary: | Frozen shutdown on a dell precision 690 | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Alip Budianto <rabbit8888> |
| Component: | Other | Assignee: | Matthias Koenig <mkoenig> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | chrubis, dimstar, markus.kossmann, werner |
| Version: | Alpha 2 | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | openSUSE 11.0 | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Alip Budianto
2008-02-28 07:49:43 UTC
Where exactly the system freeze, could you attach photo taken with digital camera from time it freeze (You should hit <esc> in order to see messages instead of splash green screen). Please reopen the bug if you can provide the needed information, thanks. This might be the same issue I see on my notebook (Dell Latitude D620): Shutdown never completes (nor does reboot). It actually hangs at dismounting drives. On the screen is visible to read: /etc/init.d/boot.d/K11boot.localfs line 113 Segmentation Fault umount -av $mtab -t $nofs -O no_netdev Oops: umount failed Trying extra sync. According K11boot.localfs, it should issue sync; sleep 1; sync and then give another text telling that this should be completed... It does not pass over this though. The only way is to force off the notebook and of course it goes for a FS-check at next boot. Werner: same issue as on my machine ... (not sure if we already have a bug on this) A SIGSEGV for umount isn't that what we want. Dominique, you seem to be able to reproduce this issue. Can you please give some more information how to reproduce this? What is the content of /etc/fstab? If you are able to get a coredump of the segfaulting mount this would be highly appreciated. that looks like #378095. However I got that running a KOTD on 10.3 and never have seen that running factory on the same system. And latest reiserfs changes in KOTD 20080419... seems to have changed the problem to a system freeze during normal operation. Matthias, my /etc/fstab looks simply like: /dev/disk/by-id/scsi-SATA_TOSHIBA_MK1234G_47FFTM21T-part5 swap swap defaults 0 0 /dev/disk/by-id/scsi-SATA_TOSHIBA_MK1234G_47FFTM21T-part6 / ext3 acl,user_xattr 1 1 /dev/disk/by-id/scsi-SATA_TOSHIBA_MK1234G_47FFTM21T-part7 /home reiserfs acl,user_xattr 1 2 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 For the coredump I have to see what I can do. If it's just unmounting /home that segfaults, it might work... if it's / it will probably more difficult, no? So if you have any tricks for me, please do not keep them for yourself ;) I tried to gdb umount it... seems not really to work (it segfaults, but then I get the message program no longer exists, and no backtrace available). But I've seen that the hang apparently seems to be the umount of /home (which is a reiserfs partition). the other partitions seemed still to be mounted afterwards. remounting /home otoh did not work... it was stale. in the log I find the following: Apr 22 23:34:37 401-1130 klogd: Apr 22 23:34:37 401-1130 klogd: Pid: 18485, comm: umount Tainted: G N (2.6.25-rc9-17-pae #1) Apr 22 23:34:37 401-1130 klogd: EIP: 0060:[<c0189d55>] EFLAGS: 00010296 CPU: 0 Apr 22 23:34:37 401-1130 klogd: EIP is at shrink_dcache_for_umount_subtree+0x130/0x1e0 Apr 22 23:34:37 401-1130 klogd: EAX: 00000054 EBX: f573d63c ECX: f7967f28 EDX: 00000086 Apr 22 23:34:37 401-1130 klogd: ESI: f8dd2b6e EDI: 00000001 EBP: f61b5ec8 ESP: f61b5e98 Apr 22 23:34:37 401-1130 klogd: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Apr 22 23:34:37 401-1130 klogd: Process umount (pid: 18485, ti=f61b4000 task=f611d0e0 task.ti=f61b4000) Apr 22 23:34:37 401-1130 klogd: Stack: c038314b f573d63c 000002b4 f573d69c 00000001 f8dd2b6e f794bf4c f573d69c Apr 22 23:34:37 401-1130 klogd: 000050a2 f794be00 f8dd0254 f7423ac0 f61b5ed4 c0189e32 f794be00 f61b5ee4 Apr 22 23:34:37 401-1130 klogd: c017c456 f70de480 f8de5274 f61b5ef0 c017c520 f794be00 f61b5efc f8dbc13e Apr 22 23:34:37 401-1130 klogd: Call Trace: Apr 22 23:34:37 401-1130 klogd: [<c0189e32>] shrink_dcache_for_umount+0x2d/0x3a Apr 22 23:34:37 401-1130 klogd: [<c017c456>] generic_shutdown_super+0x15/0xd0 Apr 22 23:34:37 401-1130 klogd: [<c017c520>] kill_block_super+0xf/0x20 Apr 22 23:34:37 401-1130 klogd: [<f8dbc13e>] reiserfs_kill_sb+0x7d/0x80 [reiserfs] Apr 22 23:34:37 401-1130 klogd: [<c017c5d3>] deactivate_super+0x54/0x66 Apr 22 23:34:37 401-1130 klogd: [<c018e00a>] mntput_no_expire+0x41/0x69 Apr 22 23:34:37 401-1130 klogd: [<c018e724>] sys_umount+0x29f/0x2c3 Apr 22 23:34:37 401-1130 klogd: [<c018e755>] sys_oldumount+0xd/0xf Apr 22 23:34:37 401-1130 klogd: [<c01059e4>] sysenter_past_esp+0x6d/0xa9 Apr 22 23:34:37 401-1130 klogd: [<ffffe430>] 0xffffe430 Apr 22 23:34:37 401-1130 klogd: ======================= Apr 22 23:34:37 401-1130 klogd: Code: 1c 8b 30 8b 43 24 89 45 ec 8b 43 0c 85 c0 74 03 8b 50 20 8d 81 4c 01 00 00 50 56 57 ff 75 ec 52 53 68 4b 31 38 c0 e8 03 db 15 00 <0f> 0b 83 c4 1c eb fe 8b 7b 18 39 df 75 04 31 ff eb 03 f0 ff 0f Apr 22 23:34:37 401-1130 klogd: EIP: [<c0189d55>] shrink_dcache_for_umount_subtree+0x130/0x1e0 SS:ESP 0068:f61b5e98 Apr 22 23:34:37 401-1130 klogd: ---[ end trace c77e20af2ba670fc ]--- The reference to bug #378095 seems to be correct. Ok, thanks for the info. The kernel trace indeed looks like #378095. *** This bug has been marked as a duplicate of bug 378095 *** |