Bug 229621
Summary: | [ACPI] rawhide kernels fail to boot with drives on ATIIXP controller | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | ||||||||||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||||||
Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> | ||||||||||||
Severity: | high | Docs Contact: | |||||||||||||
Priority: | medium | ||||||||||||||
Version: | rawhide | CC: | triage, wtogami | ||||||||||||
Target Milestone: | --- | ||||||||||||||
Target Release: | --- | ||||||||||||||
Hardware: | All | ||||||||||||||
OS: | Linux | ||||||||||||||
Whiteboard: | bzcl34nup | ||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||
Clone Of: | Environment: | ||||||||||||||
Last Closed: | 2008-04-03 22:30:26 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: | |||||||||||||||
Attachments: |
|
Description
Michal Jaegermann
2007-02-22 05:44:56 UTC
Does this happen with today's rawhide? > Does this happen with today's rawhide?
I am afraid so. The only difference is that now I see
anaconda installer init version 11.2.0.26 starting
and a kernel version used is 2.6.20-1.2947.fc7 but the rest
looks exactly the same as before.
I see that I did not mention that before - this is x86_64
machine I am trying to boot that way.
I will be not able to hold to that machine which refuses to boot for too long. Hence I tried the same experiment with quite a bit older box (my regular test machine). This one boots; at least well enough that a server directory which I try to feed it for further loading is of a wrong version - which is correct. :-) But a machine which boots is using sata_via and sata_promise controllers. While trying to boot a machine which gets into trouble when I look what I ended with on "INFO" screen I see this: found USB controller ehci-hcd modules to insert ehci-hcd loaded ehci-hcd from /modules/modules.cgz inserted /tmp/ehci-hcd.ko load module set done found USB controller ohci-hcd modules to insert ohci-hcd loaded ohci-hcd from /modules/modules.cgz inserted /tmp/ohci-hcd.ko load module set done found USB controller ohci-hcd modules to insert load module set done found USB controller ohci-hcd modules to insert load module set done found USB controller ohci-hcd modules to insert load module set done found USB controller ohci-hcd modules to insert load module set done After that the boot is stuck. On that other machine, if I will stop boot in the right moment, I can see on "INFO" screen roughly the same thing as above but with "uhci-hcd" replacing "ohci-hcd". That is followed by modules to insert hid keybdev load module set done no firewire controller found modules to insert mii e100 skge libata sata_via sata_promise pata_via followed by correspondig "loaded" and "inserted" messages for all modules on that list and "load module set done" and we are on a merry way to continue that process. An attempt to boot with "nousb" passed to a rawhide kernel changes the picture somewhat. It looks like that: .... no firewire controller found modules to insert skge libata ahci pata_atiixp loaded skge from /modules/modules.cgz loaded libata from /modules/modules.cgz loaded ahci from /modules/modules.cgz loaded pata_atiixp from /modules/modules.cgz inserted /tmp/skge.o inserted /tmp/libata.o and I am stuck again with "Loading ahci driver ..." displaying on a main screen. On "syslog" screen I have a bunch of "failed to IDENTIFY (I/O error, err_mask=0x104) and "SATA link down (SStatus 0 SControl 300)" even if there was "SATA link up 3.0 Gbps" a number of times earlier on that screen. If I will pass "irqpoll", which was required on that machine to install FC6, then everything locks up including a keyboard. Option "all-generic-ide" seems to be ignored. I am getting with it the same "SATA link down" errors like above. BTW - the current kernel-2.6.19-1.2911.fc6 from FC6 just boots and runs on this machine without a need for any additional boot parameters (a need to turn off MMCONF is autodetected). Created attachment 148843 [details]
dmesg from 2.6.19-1.2911.fc6
Before will anybody ask. :-) Attached are dmesg from a succesful boot,
an ouput from 'lscpi -tv' and an output of dmidecode for the system
in question
Created attachment 148844 [details]
tree of PCI devices
Created attachment 148845 [details]
dmidecode output
I also tried to boot as described earlier using 'pci=nomsi'. It did not help. It does not go away like with 'irqpoll' but I could not squeeze past 'ahci' driver either. I checked how far I can get with booting kernel-2.6.20-1.2949.fc7.x86_64 on the hardware in question. With various boot options I can think of, or without, I see on my screen: ..... Setting up hotplug. logips2pp: Detected unknown logitech mouse model 1 input: PS/2 Logitech Mouse as /class/input/input1 and nothing after that. It just sits and waits. Alt-Ctr-Del at that moment gives "md: stopping all md devices" and reboots. Created attachment 149228 [details]
2.6.20-1.2962.fc7 booting with 'acpi=off irqpoll'
With anaconda-11.2.0.28-1 boot images (after raid.py) got fixed,
which are using kernel-2.6.20-1.2962.fc7, I can boot the hardware
in question __provided__ I will use 'acpi=off irqpoll'. A kernel
will lock up without 'acpi=off' and if I will skipp 'irqpoll' then
disks are invisible.
Disks in question now show up as /dev/sda and /dev/sdb.
I attach a full anaconda syslog from such boot (and another one
with 'irqpoll' taken out).
Created attachment 149229 [details]
2.6.20-1.2962.fc7 booting with only 'acpi=off' - no disks
This is an excerpt from anaconda.log from this boot
22:58:53 INFO : inserted /tmp/libata.ko
22:58:55 INFO : inserted /tmp/pata_atiixp.ko
23:02:06 INFO : inserted /tmp/ahci.ko
23:02:06 INFO : modules to insert usb-storage
Note over three minutes gap between inserting pata_atiixp.ko and ahci.ko.
It corresponds to 'ahci' module probing interfaces and getting nowhere.
That corresponds to lines in syslog like:
<6>ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
<4>ata3.00: qc timeout (cmd 0xec)
<4>ata3.00: failed to IDENTIFY (I/O error, err_mask=0x104)
and more of the same kind.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. That is really related to bug 436591. I have doubts about NOTABUG resolution there but no better ideas. |