Bug 459542 - kdump hangs at boot
kdump hangs at boot
Status: CLOSED DUPLICATE of bug 456001
Product: Fedora
Classification: Fedora
Component: kexec-tools (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-19 17:14 EDT by Pontus Enhager
Modified: 2008-09-02 16:43 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-02 16:43:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
photo of screen (147.69 KB, image/jpeg)
2008-08-19 17:14 EDT, Pontus Enhager
no flags Details
serial console output (30.24 KB, text/plain)
2008-08-19 17:18 EDT, Pontus Enhager
no flags Details
sysreport (635.11 KB, application/octet-stream)
2008-08-20 14:11 EDT, Pontus Enhager
no flags Details
kdump initrd from /boot/ (1.40 MB, application/octet-stream)
2008-08-26 15:22 EDT, Pontus Enhager
no flags Details

  None (edit)
Description Pontus Enhager 2008-08-19 17:14:56 EDT
Created attachment 314577 [details]
photo of screen

Description of problem:
Whilst trying to diagnose another issue (likely kernel related), i tried to make a kdump. With a CVS-version from kdump i actually got it to panic and reboot. During the boot however, the computer hangs at the mouse initialisation

Version-Release number of selected component (if applicable):

kernel-2.6.25.14-108.fc9.x86_64
kexec-tools-1.102pre-12.fc9.x86_64
system-config-kdump-1.0.13-2.fc9.noarch

How reproducible:
every time (except when booting with a really ancient kernel)

Steps to Reproduce:
1.Enable kdump
2.Boot
3.Alt-SysRq-c

  
Actual results:
see attached boot picture (contains some info not available in the seriel-console-output 

Expected results:
successfull kdump
possibility to resolve other faults :(

Additional info:
will attach serial console dump in next entry
Comment 1 Pontus Enhager 2008-08-19 17:18:26 EDT
Created attachment 314578 [details]
serial console output

attaching serial console output
Comment 2 Pontus Enhager 2008-08-19 17:25:48 EDT
without the mouse attached, the system stops at "waiting for sda" until i plug in the mouse, inducing the message following that phrase, and stopping again

if i try to get a kdump from a X session, nothing at all happens (except from the desktop photo getting some false colors), i.e. no reboot. THe computer simply hangs

the attached dumps are from a initlevel 3 boot
Comment 3 Neil Horman 2008-08-20 07:19:04 EDT
Can you explain a bit more about what you mean in your description about using a CVS version of kexec-tools?  If you're not using the latest version of kexec from the fedora repo, I'm not sure I'm going to be able to help you too much.

As for why  your mouse is causing difficulty with boot, I can't even begin to guess.  There shouldn't be any commnication that we wait for, especially in  aPS/2 mouse.  Does the same thing happen if you try to boot using a USB mouse?

Also, if you could send in a sysreport of your system, that would be helpful.  Thanks!
Comment 4 Pontus Enhager 2008-08-20 14:09:25 EDT
if that package is officially released now, it ought to be the same, but i checked it out with fedora-cvs as it at that time was not released (please cf https://bugzilla.redhat.com/show_bug.cgi?id=443878)

same result with usb connection(of the same mouse) if i remember correctly i will check that once more 

will attach sysreport
Comment 5 Pontus Enhager 2008-08-20 14:11:57 EDT
Created attachment 314647 [details]
sysreport

sysreport
Comment 6 Pontus Enhager 2008-08-20 14:22:00 EDT
yep stops at "waiting for sda..." again i.e. the same as trying without mouse & keyboard
Comment 7 Neil Horman 2008-08-20 14:53:54 EDT
So it sounds like you have two separate issues here:
1)  your mouse prevents boot up of kdump (why I have no idea).  Since  unplugging the mouse or using a different mouse gets you father than if you dont.  I would separate that out into another bug.  Also I would try using a different (non-logitech) ps2 mouse.  Lets see if its just something about that mouse specifically thats causing problems

2) You're stuck waiting for sda2 to appear during kdump.  I'll look at your sysreport and see whats going on there.
Comment 8 Neil Horman 2008-08-20 15:09:49 EDT
I think you may be seeing  bz 442678.  CAn you try the patch there?
Comment 9 Pontus Enhager 2008-08-20 15:17:52 EDT
are you sure that i get any longer without the mouse ? if i try without the mouse plugged in, waits until it stops and IF I plug in the mouse after that, the computer emits the mouse message and continues stopped, (YOU are the expert so I really should rest my case here). My (amateur) guess would be that it is the sda issue that  bites me, the logs (both photo and serial console both states that:

logips2pp: Detected unknown logitech mouse model 127
input: ImExPS/2 Logitech Explorer Mouse as /devices/platform/i8042/serio1/input/input2

so it seems that the mouse gets identified and initialised at least

i think (not 100% though that the photo and the syslog relates to the same boot, but the screen contains more than the serial console do (i do not know why but that is the way it is)

i will try to borrow a non logitec mouse at work tomorrow
Comment 10 Neil Horman 2008-08-20 15:55:38 EDT
I might be misunderstanding what you're reporting to me, so correct me if I'm wrong but what I understand here is that:

IF you have the mouse plugged in you hang after you see the message:
input: ImExPS/2 Logitech Explorer Mouse as
/devices/platform/i8042/serio1/input/input2

IF you don't have the mouse plugged in (or you use a usb mouse) you hang at the message:
waiting for sda...

The former is a message from the kernel that occurs during kernel boot up /initalization.  The latter is a message written out from the initramfs for kdump, which waits for all block devices need to save the vmcore in the location specified in /etc/kdump.conf.

Since the latter message requires complete initialization of the kernel (mounting the initramfs and running /init is what the kerel does after finishing execution in start_kernel) I'm concluding that without the mouse you get father with the mouse.
Comment 11 Pontus Enhager 2008-08-21 01:06:17 EDT
ok well i tried another time, now with a different (albeit logitec USB) mouse i had, no difference.

i have to say that i was not able to reproduce the "mouse initialisation" message if i connect the mouse back in after the sda message appeared, although i saw that a couple of days ago. I will try to get another mouse at work today.

i tried the patch at the same time with NO effect at all
Comment 12 Neil Horman 2008-08-21 07:02:24 EDT
When you say no difference, are you saying that you still hung at the mouse initialization message or the "waiting for sda message"?  If you mean the latter then it is in fact a difference.  In fact if you look through your logs and see that the mouse you used in comment 11 contains the "logips2pp:..." intialization messages, that would indicate you're using the same driver for this mouse and not hanging on its initialization, which would in turn suggest something is misbehaving in the mouse itself.

When you say "i tried the patch at the same time..." I assume you mean that you still hung at the "waiting for sda message"?  would it be possible for you to send me the initrd that kdump generated on your system, as well as the log from this most recent test?  Thank you!
Comment 13 Pontus Enhager 2008-08-26 15:20:34 EDT
hung at the "waiting for sda" so you are right

i applied the patch, compiled and restarted

i will attach the initrd i think that you are after (the one in /boot/) please correct me if i am wrong !

i will also try to make a new dump
Comment 14 Pontus Enhager 2008-08-26 15:22:04 EDT
Created attachment 315034 [details]
kdump initrd from /boot/
Comment 15 Neil Horman 2008-08-27 10:40:50 EDT
Ahh, it appears that your initrd is not including any modules for your hard drives.  I assume that sda exists and is normally in use in your system under normal use?  What kind of HBA are you using?
Comment 16 Pontus Enhager 2008-08-30 08:57:25 EDT
i am sorry but i do not know what a HBA is, or how i deduce what type i use. Could you give me a hint ?

yes sda is currently used the root lvm and the swap partition currently resides on that disc
Comment 17 Neil Horman 2008-09-02 07:14:04 EDT
An HBA is a host bus adapter.  Its the card that interfaces your hard drives to your motherboard.
Comment 18 Pontus Enhager 2008-09-02 14:08:37 EDT
pontus@selleri ~]$ /sbin/lspci
00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port (rev 02)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GT] (rev a1)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
04:00.0 FireWire (IEEE 1394): NEC Corporation uPD72874 IEEE1394 OHCI 1.1 3-port PHY-Link Ctrlr (rev 01)
04:01.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01)
Comment 19 Pontus Enhager 2008-09-02 14:35:32 EDT
[pontus@selleri ~]$ cat /sys/class/scsi_host/host*/proc_name
ata_piix
ata_piix
usb-storage

so i'd guess that ata_piix is used
Comment 20 Neil Horman 2008-09-02 15:33:06 EDT
hmm, I think you may have a duplicate bug of  bz 456001.  Can you please provide for me the output of:
ls -l /sys/block/sda/device
cat /sys/block/sda/device/modalias
Comment 21 Pontus Enhager 2008-09-02 16:10:21 EDT
[pontus@selleri ~]$ ls -l /sys/block/sda/device
lrwxrwxrwx 1 root root 0 2008-09-02 18:32 /sys/block/sda/device -> ../../../0:0:0:0
[pontus@selleri ~]$ cat /sys/block/sda/device/modalias
scsi:t-0x00
Comment 22 Pontus Enhager 2008-09-02 16:18:33 EDT
ok that was a loong bug which lost me halfways...

anyway my system has its root file system on a normal sata disk (not USB), however a USB disk is usually physically attached but rarely started (external power supply)

(i do not however know whether this info is of any help to you)
Comment 23 Neil Horman 2008-09-02 16:43:54 EDT
yeah, its the same bug.  The title on that says usb-storage, but its not constrained to that type of device (apparently).  There appears to be some set of devices (which includes your hard drive), which have a device link that mamkes the underlying type of device ambiguous.  Since kdump uses that data to determine the underlying device type, it gets confused and bad things happen.  I'm going to close this as a dup of that.  I need to find a way to determine device type tht doesn't rely on parsing /sys/block/<dev>/device

*** This bug has been marked as a duplicate of bug 456001 ***

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