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
Created attachment 314578 [details] serial console output attaching serial console output
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
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!
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
Created attachment 314647 [details] sysreport sysreport
yep stops at "waiting for sda..." again i.e. the same as trying without mouse & keyboard
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.
I think you may be seeing bz 442678. CAn you try the patch there?
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
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.
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
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!
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
Created attachment 315034 [details] kdump initrd from /boot/
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?
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
An HBA is a host bus adapter. Its the card that interfaces your hard drives to your motherboard.
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)
[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
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
[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
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)
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 ***