Bug 79470
Summary: | Kernel panic on reboot (but not on powerup), IBM Thinkpad 570 + RH8 | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <jahf> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | me |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-09-30 15:40:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Need Real Name
2002-12-11 23:35:28 UTC
FYI, I decided to confirm that the problem existed before performing any updates. I reinstalled RH8 from CD onto the system, formatting the old RH8 partitions. After a fresh install rebooting still causes the kernel panic with the older 2.4.18-14 kernel. The only other anomaly I could think of was that I had the CD tray open this whole time. I powered up and rebooted with the CD tray closed (and empty) the entire time. No change, still panics if I reboot but will load properly from a cold boot. Also, as an FYI, I've had Mandrake 8.1, Gentoo 1.4 (that was fun :), Win98 and Win2K Pro (Win2K until this morning) all running on this machine in the past few months (it was my lab laptop until I got a 2nd one). I haven't experienced this problem on other OSes, so I'm assuming that it is related to RH8 and not my hardware. can you try adding "reboot=c" to the vmlinuz line of /boot/grub/grub.conf ? that changes the method the kernel uses for rebooting. (of course you need to reboot after this change, and then reboot AGAIN to see if it has effect) Steps: * edited /boot/grub/grub.conf * appended " reboot=c" to the vmlinux line after root=LABEL=/ * powered down/powered up * rebooted machine from gdm Result: no change ... I read up on the reboot= parameter in the kernel and decided to try a combination of options to see if I have any luck. Questions: 1) Can you tell me what the default is with nothing specified? I'm assuming warm,hard. 2) Documentation on a page about lilo with redhat shows the order of options to be {hard|bios},{warm|cold}. However other pages reverse that to {warm|cold},{hard|bios}. Does the order matter with RH8+2.4.18+Grub? ... NEW TESTS: Combinations of reboot= SUMMARY: no combination seems to work, though changing combinations produced a new result. DETAILS: * no "reboot=" parameter (default) - case described by initial bug report * reboot=c - fail as per initial bug * reboot=cold - fail as per initial bug * reboot=cold,hard - fails as initial bug report * reboot=cold,bios - fails as initial bug report and as per =cold,hard * reboot=warm - ugly freeze after reboot, new result: (note: lots of lines similar to the first 4 quoted, only typed in the last 4) ... [<c0114ed5>] apm_cpu_idle [kernel] 0 (0xc0341fc4)) [<c0107040>] default_idle [kernel] 0x0 (0xc0341fd0)) [<c0105000>] stext [kernel] 0x0 (0xc0341fd4)) [<c01070d4>] cpu_idle [kernel] 0x24 (0xc0341fdc)) Code: Bad EIP value. <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing ... * reboot=warm,hard - fail during reboot as per initial report * reboot=warm,bios - fail with new ugly error as per =warm ERRATA: I tried to reproduce the weird error on =warm and =warm,bios and on repeats they both failed as per the initial bug. Unsure what the cause would have been. RESULT: no change, still no successes on rebooting. Possibly the problem lies outside the reboot= kernel code? > RESULT: no change, still no successes on rebooting. Possibly the problem lies
> outside the reboot= kernel code?
quite possible; the reboot= code is obviously first suspect in a problem as you
reported. the APM oops you gave makes me wonder if you can try "apm=off" and see
if that helps ? maybe using apm confuses things ;(
* removed "reboot=c" from the vmlinuz line * added apm=off to the vmlinuz line No change, assuming that's where apm=off should have gone. Problem is still consistently the same as from initial report ... ie: Loading ext3 module Mounting /proc filesystem Creating block devices Creating root device mkrootdev: label / not found Mounting root filesystems mount: error 2 mounting ext3 pivotroot: pivot_root(/sysroot,sysroot/initrd) failed: 2 umount /initrd/proc failed: 2 Freeing unused kernel memory: 172k freed Kernel panic: No init found. Try passing init= option to kernel. The first error in the listing above is "mrootdev: label / not found" ... is there anything that would cause the system to loose the drive geometry during a reboot but would not be a problem during boot from a power up? Addendum ... I decided to keep reading on other peoples' problems involving pivotroot messages and ended up trying the following with no success. Just adding this to streamline possible tests. * edited grub.conf from "root=LABEL=/" to "root=/dev/hda5", reverted on failure * edited /etc/fstab to change "LABEL=/" to "/dev/hda5" and "LABEL=/boot" to "/dev/hda2" (/dev/hda1 is an empty 100MB vfat partition in case I have to use DOS to update firmware at some point), reverted on failure * created a new initrd image with mkinitrd ... didn't expect this to work, reverted on failure * I logged the IDE section of dmesg during a successful boot, follows this. I tried to compare it to a failed reboot but it goes by very fast. Is there a way for me to keep the dmesg info from a failed boot attempt? When I boot again from power-up it's obviously replaced with the new, successful boot. ... (note: the following is from a successful boot) Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 31 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x1800-0x1807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1808-0x180f, BIOS settings: hdc:pio, hdd:pio hda: IBM-DBCA-204860, ATA DISK drive hdc: CRN-8241B, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 blk: queue c03afd84, I/O limit 4095Mb (mask 0xffffffff) blk: queue c03afd84, I/O limit 4095Mb (mask 0xffffffff) hda: 8007552 sectors (4100 MB) w/420KiB Cache, CHS=993/128/63, UDMA(33) ide-floppy driver 0.99.newide Partition check: hda: hda1 hda2 hda3 hda4 < hda5 > Floppy drive(s): fd0 is 1.44M ... NOTE: I have noticed each time that during a fresh power-on boot, the "Partition check:" segment of booting takes virtually no time to complete and spit out "hda: hda1 hda2 hda3 hda4 < hda5 >". However, when it does the "Partition check:" during reboot, it takes 4-6 seconds during which the hard drive is very active, before it spits out the result (which passes to quickly for me to confirm 100% that it succeeds) and proceeds to halt the boot as mentioned above. ... I'll quit pegging you with fresh entries until you've had a chance to read through what I've posted today. Thanks for looking at this. Haven't heard anything recently here. I didn't find any answers on Google, just someone else who claims to have had this same problem since Red Hat 7.3 ... see <a href="http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=1cf0b4c8.0212111527.1ec7e5b3%40posting.google.com&rnum=1&prev=/groups%3Fq%3Dkernel%2Bpanic%2Bon%2Breboot%252C%2BIBM%2BThinkpad%2B570%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den%26btnG%3DGoogle%2BSearch"> this article</a>. If there is anything else I can do to help this along, please let me know. Thanks, /Geoff Requesting an update ... will this be fixed? It was working in previous Red Hat and Mandrake versions, so it would seem to be something that could be tracked down. It appears that your bios doesnt restart hard disks that the OS placed (correctly) into power saving mode when soft booting and decides no disk is present. Its hard to be sure. For what it's worth, I also have a Thinkpad 570 which exhibits the exact same behavior after I install Fedora Core 1. Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/ |