Bug 232897 - [msi] Fedora 7 does not work on MSI K9A without "pci=nomsi"
[msi] Fedora 7 does not work on MSI K9A without "pci=nomsi"
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-19 08:15 EDT by Yann Golanski
Modified: 2008-01-09 06:23 EST (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Yann Golanski 2007-03-19 08:15:37 EDT
Description of problem:
I tried to install Fedora 7 test2 over the weekend on my new machine and came
across some issues:

First, the installer cannot find the DVR and thus I had to use ftp to
get second stage image.

Second, the installer cannot find the hard drive and thus cannot
install.  I have some partitions that need destroying and recreating
as Linux ones but it does not even give me that option.

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

Fedora 7 test2 Prime.

How reproducible:

Run on similar hardware:
  AMD Athlon 64 X2 Dual Core 5000+
  MSI K9A Platinum Crossfire
  Sapphire ATI Radeon X1950 Pro ULTIMATE SILENT
  Western Digital Caviar SE16 500GB SATA-II
  Pioneer DVR-111BK

Steps to Reproduce:
1. Put in DVD.
2. reboot machine.
  
Actual results:

DVR is not accessible -- no device found.
Hard Disk is not accessible -- no device found.

Expected results:


Additional info:

I am more than happy to install and test patches but I do NOT have a running
version of Linux.  Fedora Core 6 kernel panics on the same hardware.  FreeBSD is
installed on the system so i can run Unix commands but cannot build Linux kernel
and expect them to work.

If anyone wants more information please do let me know.
Comment 1 David Cantrell 2007-03-21 15:09:03 EDT
Assigning this to kernel since it's a driver issue.
Comment 2 Vaclav "sHINOBI" Misek 2007-03-21 18:45:32 EDT
If the SATA HDD's are unavailable try boot parameter pci=nomsi. It should help.
Comment 3 Dave Jones 2007-04-23 17:49:41 EDT
This is probably the problem with the missing scsi_wait_scan module.  This will
be fixed in test4 (out soon), and is already fixed in the daily boot.iso's.
If you could test one of those, that would be appreciated.
Comment 4 Vaclav "sHINOBI" Misek 2007-07-25 07:56:39 EDT
Hmm this issue was fixed in kernel update 2.6.21-1.3228.fc7 , but it's broken
again in 2.6.22.1-27.fc7 and 2.6.22.1-33.fc7. Any idea what should go wrong? BTW
I have the same MB as original reporter. BTW should the version of product be
changed to fc7?
Comment 5 Chuck Ebbert 2007-07-25 10:21:00 EDT
What messages are on the screen? Digital camera photo of the screen will do.
Comment 6 Vaclav "sHINOBI" Misek 2007-08-08 07:49:27 EDT
I tried kernel-2.6.22.1-41.fc7 and the same problem. I tried to write down the
most important messages, if it's not sufficient, I'll try to borrow digital camera.

ahci module is loaded

ACPI: PCI Interrupt 0000:00:12.0[A] -> GSI 22 (level, low) -> IRQ 22
ahci 0000:00:12.0: controller can't do 64bit DMA forcing 32bit
ahci 0000:00:12.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci 0000:00:12.0: flags: ncq ilck led clo pmp pio slum part 
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
ata1: SATA max UDMA/133 cmd 0xffffc200005f8d00 ctl 0x0000000000000000 bmdma 0x00
00000000000000 irq 2300
ata2: SATA max UDMA/133 cmd 0xffffc200005f8d80 ctl 0x0000000000000000 bmdma 0x00
00000000000000 irq 2300
ata3: SATA max UDMA/133 cmd 0xffffc200005f8e00 ctl 0x0000000000000000 bmdma 0x00
00000000000000 irq 2300
ata4: SATA max UDMA/133 cmd 0xffffc200005f8e80 ctl 0x0000000000000000 bmdma 0x00
00000000000000 irq 2300

ata1.00: SATA link up 3.0Gbps (SStatus 123 SControl 300)
ata1.00: qc timeout (cmd 0xec)
ata1.00: failed to identify (I/O error, err_mask=0x4)
 and then tries to establish connection on 1.5 Gbps

This sequence is then repeated for all 4 SATA ports.

Booting has failed.
Kernel panic - not syncing: Attempted to kill init!

with pci=nomsi (from dmesg):

libata version 2.21 loaded.
ahci 0000:00:12.0: version 2.2
ACPI: PCI Interrupt 0000:00:12.0[A] -> GSI 22 (level, low) -> IRQ 22
ahci 0000:00:12.0: controller can't do 64bit DMA, forcing 32bit
ahci 0000:00:12.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci 0000:00:12.0: flags: ncq ilck led clo pmp pio slum part 
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
ata1: SATA max UDMA/133 cmd 0xffffc200005f8d00 ctl 0x0000000000000000 bmdma 0x00
00000000000000 irq 22
ata2: SATA max UDMA/133 cmd 0xffffc200005f8d80 ctl 0x0000000000000000 bmdma 0x00
00000000000000 irq 22
ata3: SATA max UDMA/133 cmd 0xffffc200005f8e00 ctl 0x0000000000000000 bmdma 0x00
00000000000000 irq 22
ata4: SATA max UDMA/133 cmd 0xffffc200005f8e80 ctl 0x0000000000000000 bmdma 0x00
00000000000000 irq 22
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7: ST3320620NS, 3.AEG, max UDMA/133
ata1.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133

etc. and system boots.
The difference seems to be in assigned IRQ. Without nomsi parameters 2300 with
nomsi 22.
Comment 7 Chuck Ebbert 2007-08-22 18:59:17 EDT
So, this is fixed with the "nomsi" parameter.
Was there a BIOS update available for the board?
Comment 8 Vaclav "sHINOBI" Misek 2007-08-23 02:36:31 EDT
Yup, IMHO there were 3 or 4 updates. I updated to the latest bios 3 days ago,
but nothing changed, so maybe it's a bad hw implementation, or persisting BIOS bug. 
Comment 9 Christopher Brown 2008-01-08 19:12:50 EST
Hello,

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.
Comment 10 Vaclav "sHINOBI" Misek 2008-01-09 03:46:41 EST
It works flawlessly in the latest kernels in F8, I don't know the status for F7
kernels, but I suppose they should be OK as well.
Comment 11 Christopher Brown 2008-01-09 06:23:06 EST
Hmmm. Thanks for the update Vaclav. No imformation from the original reporter
since filing though but I'll close this as NEXTRELEASE. If the OR wishes to
re-open if it is still occurring in F7 please do so...

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