Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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


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.