Bug 232897 - [msi] Fedora 7 does not work on MSI K9A without "pci=nomsi"
Summary: [msi] Fedora 7 does not work on MSI K9A without "pci=nomsi"
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-19 12:15 UTC by Yann Golanski
Modified: 2008-01-09 11:23 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-01-09 11:23:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Yann Golanski 2007-03-19 12:15:37 UTC
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 19:09:03 UTC
Assigning this to kernel since it's a driver issue.

Comment 2 Vaclav "sHINOBI" Misek 2007-03-21 22:45:32 UTC
If the SATA HDD's are unavailable try boot parameter pci=nomsi. It should help.

Comment 3 Dave Jones 2007-04-23 21:49:41 UTC
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 11:56:39 UTC
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 14:21:00 UTC
What messages are on the screen? Digital camera photo of the screen will do.

Comment 6 Vaclav "sHINOBI" Misek 2007-08-08 11:49:27 UTC
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 22:59:17 UTC
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 06:36:31 UTC
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-09 00:12:50 UTC
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 08:46:41 UTC
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 11:23:06 UTC
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.