Bug 242561 - F7 ICH8 Chipset slow module load and unable to see disks in installer
Summary: F7 ICH8 Chipset slow module load and unable to see disks in installer
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 7
Hardware: x86_64 Linux
low
high
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: FCMETA_SATA
TreeView+ depends on / blocked
 
Reported: 2007-06-04 20:11 UTC by Matt Darcy
Modified: 2018-04-11 17:47 UTC (History)
7 users (show)

Fixed In Version: 2.6.23.9-85.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-04 00:35:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
bootlog showing the error (no extra kernel options) (19.27 KB, text/plain)
2007-06-09 14:09 UTC, Sven Neuhaus
no flags Details
successful boot with kernel parameter noirqdebug (19.19 KB, text/plain)
2007-06-09 14:10 UTC, Sven Neuhaus
no flags Details

Description Matt Darcy 2007-06-04 20:11:19 UTC
Description of problem:
Loading F7 on a motherboard with an ICH8 Sata controller provides long loading
times for the ata_piix kernel module. (approx 4 minutes) Once this module loads
the installer can see none of the disks connected to the ICH8 controller.

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

How reproducible:
Every time

Steps to Reproduce:
1. boot from ICH8 Sata insalled board (MSI 965 Neo in my case)
2. Boot from Fedora 7 x86_64 dvd (I've seen reports of this on x86 too) watch
kernel modules load
3. Check what disks are visable for use at install time.
  
Actual results:
No disks are available for use at install time

Expected results:
Disks conectted to the controller should be usable for the installer.

Additional info:
This issue appears to have been noted in FC 7 - Test 4. A work around exists but
is unstable. 
Details:booting Fedora with the noprobe argument and then manually loading the
Intel ATA driver (ata_piix), you are %90 of the time able to see and install F7
to the sata drives.

Comment 1 Cory Eakins 2007-06-06 12:11:08 UTC
I'm also running a MSI P965 Neo.  I have a LG IDE DVD connected to the JMicron
IDE port, and a Seagate SATA hard drive connected to the ICH8 controller.  And
see the same results installing from the Fedora 7 x86 dvd.

I tried attaching the SATA hard drive to JMicron controller - System installs
fine, but at boot time you get dumped to the grub> prompt.  If you move the
drive back to the ICH8 controller after install the system will start to boot,
then hang with a complaint about IRQ 19 (suggests irqpoll kernel option, which
doesn't help) and the system hangs.


Comment 2 Matt Darcy 2007-06-07 15:25:52 UTC
I have other bugs logged with this board, one thing that seems common across 
all these bugs I've logged against this board is the IRQ warnings and errors.

I have tried this board with CentOS 5 and it suffers the same warnings - but on 
different IRQ's and this time the network card vanishes rather than disc 
controllers.

I will try disabling as many on board devices as possible (currenlty gameport, 
sound card and parallel port are disabled) I will try disabling usb as it 
shares the same chipset.

Comment 3 Sven Neuhaus 2007-06-09 14:07:34 UTC
I have the same board and the same problems.
The board is a MSI P965 Neo with BIOS V1.8

I have two Seagate ST3320620AS S-ATA drives connected to IDE primary master and
IDE secondary master (those are the S-ATA ports of the intel chipset not the
JMicron ports).
I have a LG "HL-DT-ST DVDRAM GSA-H10N" drive connected to the parallel ATA port,
but I don't think it has anything to do with this bug. It also happens when I
disable the Jmicron IDE in the BIOS completely.

I am attaching 2 logs of kernel messages, the first one shows the problems,
ata1.00 and ata2.00 are disabled and there is nothing to boot from.

The second log shows a successful boot with the "noirqdebug" kernel option.


Comment 4 Sven Neuhaus 2007-06-09 14:09:05 UTC
Created attachment 156647 [details]
bootlog showing the error (no extra kernel options)

There are hangs during boot after these lines:

usb 7-6.1.2: configuration #1 chosen from 1 choice 
			     
ata1: failed to recover some devices, retrying in 5 secs		       

(2x)

ata1.00: disabled							       

scsi1 : ata_piix  

ata2: failed to recover some devices, retrying in 5 secs		       

(2x)

Comment 5 Sven Neuhaus 2007-06-09 14:10:24 UTC
Created attachment 156648 [details]
successful boot with kernel parameter noirqdebug

Comment 6 Sven Neuhaus 2007-06-09 14:42:21 UTC
I noticed there was a new BIOS available for the MSI P965 Neo (V1.9). I updated
my BIOS but the problem remains.

Comment 7 Matt Darcy 2007-06-10 13:36:29 UTC
Disable USB in the bios and try booting with just the agp=off and irqpoll 
options in the installer, the driver loaded very quick and the disks where 
visable.

It appears that irq assignment on this board is really messed up and causes 
problems. I'll link to other bugs this board has that stop when disabling usb 
in the bios.

Comment 8 Christopher Brown 2007-09-13 20:35:10 UTC
Hello folks,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Cheers
Chris

Comment 9 Sven Neuhaus 2007-09-14 08:01:52 UTC
Yes this bug is still present with the MSI P965 Neo mainboard, the latest BIOS
(1.10) and the latest F7 kernel.
Disabling USB makes this error go away. Not a very nice option though.

I hope there is some kind of better workaround than using the irqpoll kernel
option - Windows XP has no problems with this board.

Comment 10 Sven Neuhaus 2007-09-14 08:03:58 UTC
In my(In reply to comment #9)
> I hope there is some kind of better workaround than using the irqpoll kernel
> option

Sorry, I meant the "noirqdebug" kernel option (which seems to give better
performance than the irqpoll option).

Comment 11 Chuck Ebbert 2007-09-14 19:17:37 UTC
Try "nolapic"

Comment 12 Matt Darcy 2007-11-02 10:30:56 UTC
nolapic make works the same as the current work around for me. 

However I find that if I enable USB the IRQ issues come back and the disks on 
the controller are not visable again.

I've just updated to the current fedora kernel and will re-test this again.

I'm currently having to run with USB ports disabled.

Comment 13 Christopher Brown 2007-12-13 16:07:33 UTC
Hi Matt,

I take it things have not improved. I ran a diff against your good and bad boots
and even the log starts getting corrupted. E.g.

-uhci_hcd 0000:00:1d.2: UHCI Host Controller
+uhci_h0000:00:1d.2: UHCI Host ntroller

The bad boot log does complain about an unknown boot option, though I don't
really trust this. Could you try:

Kernel command line: ro root=LABEL=/ pci=routeirq

and see if you have any success. Can you also attach output of lspci -vvxxx and
lsmod.

Cheers
Chris

Comment 14 Sven Neuhaus 2007-12-13 18:54:05 UTC
I upgraded to F8, installed the latest kernel RPM and the problem went away for me!

Comment 15 Christopher Brown 2008-01-03 23:01:19 UTC
(In reply to comment #14)
> I upgraded to F8, installed the latest kernel RPM and the problem went away
for me!

Thanks for the feedback Sven. Matt, any success with the suggestions above?

Comment 16 Matt Darcy 2008-01-04 00:27:48 UTC
just finished an update myself to F8 - problem gone away. Resolved with Fedora 
8 latest (current) kernel.

Nice job.

Comment 17 Sven Neuhaus 2008-04-03 12:23:49 UTC
For the record: This bug returned with F8 kernel 2.6.24. See bug #436681.
Not sure if that bug describes the exact same problem...


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