Bug 432585

Summary: 2.6.23.14-115.fc8 doesn't see sata drives on via vt8251
Product: [Fedora] Fedora Reporter: SteveB <zzybaloobah>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-09 05:58:58 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 Flags
boot log from fc8 (/var/log/messages)
none
boot log from fc6 (working) /var/log/messages
none
lspci and lspci -v -v from (working) fc6 and broken fc8 none

Description SteveB 2008-02-13 05:28:03 UTC
Description of problem:
kernels 2.6.23.1-42 (including installer DVD) and
2.6.23.14-115 don't see sata drives on via vt8251 southbridge
on Asus A8V-MX MB (BIOS 0503).  System works fine on FC6. 

Version-Release number of selected component (if applicable):
2.6.23.1-42.fc8 and 2.6.23.14-115.fc8

How reproducible:
Always

Steps to Reproduce:
1.Install FC8 on a regular pata drive in machine
2.Boot to FC8 with either kernel
3.
  
Actual results:
Kernel only sees pata drive

Expected results:
Kernel should see pata and 2 sata drives

Additional info:
1) The system currently runs fine at FC6, with just SATA drives.
   I was able to install FC8 to an IDE drive and that boots, but
   it still doesn't see the SATA drives
2) This is very similar to bug 242831 (same chipset and errors)
   His was fixed with a BIOS upgrade, but I'm running the latest
   BIOS for my MB.  Also similar to bugs 243170, 242696, and others,
   but mine is on a Asus A8V-MX, BIOS 0503, Via VT8251 southbridge.
3) during boot, following messages show up in /var/log/messages
   (full logs attached)
ahci 0000:00:0f.0: controller can't do NCQ, turning off CAP_NCQ
ahci 0000:00:0f.0: AHCI 0001.0000 32 slots 4 ports 3 Gbps 0xf impl IDE mode
ahci 0000:00:0f.0: flags: 64bit pm led clo pmp pio slum part
scsi2 : ahci
scsi3 : ahci  (similarly for scsi4 & 5)
ata3: SATA max UDMA/133 cmd 0xf882ed00 ctl 0x00000000 bmdma 0x00000000 irq 221
ata4: SATA max UDMA/133 cmd 0xf882ed80 ctl 0x00000000 bmdma 0x00000000 irq 221
ata5: SATA max UDMA/133 cmd 0xf882ee00 ctl 0x00000000 bmdma 0x00000000 irq 221
ata6: SATA max UDMA/133 cmd 0xf882ee80 ctl 0x00000000 bmdma 0x00000000 irq 221
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: qc timeout (cmd 0xec)
ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: qc timeout (cmd 0xec)
ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata3: limiting SATA link speed to 1.5 Gbps
ata3.00: limiting speed to UDMA7:PIO5
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata3.00: qc timeout (cmd 0xec)
ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata3: EH pending after completion, repeating EH (cnt=4)
(similarly for ata4, which is the other SATA drive)
4) I've tried passing nomsi as a kernel argument in grub.conf and
   passing noacpi=1 as an option to libata in /etc/modprobe.conf
   I've tried setting the drives (in BIOS) as either SATA or AHCI.
   I probably haven't tried *every* permutation of the above; in
   particular, for the most part, I've left the drives as AHCI.

Comment 1 SteveB 2008-02-13 05:28:03 UTC
Created attachment 294743 [details]
boot log from fc8 (/var/log/messages)

Comment 2 SteveB 2008-02-13 05:28:56 UTC
Created attachment 294744 [details]
boot log from fc6 (working) /var/log/messages

Comment 3 SteveB 2008-02-13 05:43:58 UTC
Created attachment 294746 [details]
lspci and lspci -v -v from (working) fc6 and broken fc8

Comment 4 SteveB 2008-02-14 13:56:48 UTC
I just tried 2.6.23.15-137.fc8 last night.
Same problem.


Comment 5 Chuck Ebbert 2008-02-20 18:35:57 UTC
(In reply to comment #0)
> 4) I've tried passing nomsi as a kernel argument in grub.conf

That's "pci=nomsi" (see https://fedoraproject.org/wiki/KernelCommonProblems)

>    passing noacpi=1 as an option to libata in /etc/modprobe.conf
>    I've tried setting the drives (in BIOS) as either SATA or AHCI.
>    I probably haven't tried *every* permutation of the above; in
>    particular, for the most part, I've left the drives as AHCI.

You need to rebuild the initrd or reinstall the kernel after changing options in
modprobe.conf

Comment 6 SteveB 2008-02-20 19:19:58 UTC
Me bad, sorry for the poor troubleshooting on my end.
pci=nomsi fixed it.  Not sure why I didn't catch that.
Thanks!
Please close this as NOTABUG.



Comment 7 Bug Zapper 2008-11-26 09:48:17 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Bug Zapper 2009-01-09 05:58:58 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.