From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051018 Galeon/1.3.21 Description of problem: Using the install cdrom from the fedora download ftp site. When you boot up everything appears fine until you get to the point of where selecting your install source then the installer reports it is unable to locate any HDs onthe system and prompts the user to select additional drivers to install. There appears to be no driver specific for this via chipset and if you select VIA_SATA it has no apparent affect. If you switch to alt-f4 and use lspci you will see that the VT8251 controller is being recognized and properly identifed but there is no record of any attahed HDs. I have sucessfully installed both OpenBSD and FreeBSD on the same hardware. The chip set has 3 options in bios for this controller and all three appear to have the same result. Those options are SATA, RAID, and AHCI. I apologize for not having actual things to cut and paste but I see no feesible way to cut and paste output from the installer to this page. So if there is any specific information you require I will manually transcribe it here. Below is more hardware specs Motherboard: Asus A8V-MX North Bridge: VIA K8M800 South Bridge: VT8251 4x SATA ports with RAID 0, 1, 1+0, 5 and JBOD HD: "Western Digital Caviar RE2 WD4000YR 400GB Serial ATA150 RAID-specific Hard Drive - OEM" There are 4 of these installed. any more info just ask Jason Cribbins Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. insert latest fc4 bootable cdrom 2. turn on power to server 3. follow prompts as explained in documentation Actual Results: message will appear stating no HDs are found and it will offer an option to select the driver from a list Expected Results: It should see the available HDs and allow the use of diskdruid Additional info:
problems at install time aren't usually fixable. Your best bet is to either check out FC5-test1, or the unofficial FC4.2 iso mentioned in the bug I'm marking this a dupe of. *** This bug has been marked as a duplicate of 169613 ***
both FC5 and that respin were tested at the request of those on irc.freenode.org in the channel #fedora. Both have the exact same situation. Is there any planned support for these amd chipsets or should I try to sell them on ebay and buy intel? I hate to waiste a $2000 investment so any suggestion is welcome here.
I don't know how different the 8251 is from the 6420/6421 that the driver currently supports, so I'll defer that question to Jeff Garzik. VIA stuff isn't usually too hard to get documentation for though, so there's a lot more hope that the driver will support it at some point than there would be for some other vendors chipsets.
well if money is required to get someone to help out here I will consider it...I have too much at stake to let it go because someone didnt have the motivation to make this driver. thanks
Money is not required, test hardware is. If you can send me @ Red Hat a bare bones test box, I can probably get it going.
I wanted to add some notes. I have tried the latest kernel from FC5 updates (kernel-xen0-2.6.16-1.2080_FC5). While the parallel ATA works fine, the SATA drive is not currently recognized. There are discussions on viaarena.com that may be useful. For instance, there is supposedly a patch that works. http://web.ukonline.co.uk/paulrbarber/sata_via_20060221.c Most recent messages: http://forums.viaarena.com/messageview.aspx?catid=28&threadid=68455&STARTPAGE=13&FTVAR_FORUMVIEWTMP=Linear
Created attachment 127793 [details] Patch for ahci and sata_via source files. This was based on the patch provided in VIA Arena.
The above patch was added to kernel-2.6.16-1.2080_FC5.src.rpm and Linux was able to detect the disk. I added partitions, formatted, etc. For further testing I was copying large files (Xen images) from another disk (regular ATA) to the SATA disks, and then from one partition in the SATA disk to another. After a while I got errors: sd 0:0:0:0: SCSI error: return code = 0x8000002 sda: Current: sense key: Aborted Command Additional sense: Scsi parity error end_request: I/O error, dev sda, sector 172876361 ata1: port reset, p_is 40000000 is 1 pis 0 cmd 44017 tf 8451 ss 123 se 0 ata1: status=0x51 { DriveReady SeekComplete Error } ata1: error=0x84 { DriveStatusError BadCRC } ata1: port reset, p_is 40000000 is 1 pis 0 cmd 44017 tf 8451 ss 123 se 0 ata1: status=0x51 { DriveReady SeekComplete Error } ata1: error=0x84 { DriveStatusError BadCRC } ata1: port reset, p_is 40000000 is 1 pis 0 cmd 44017 tf 8451 ss 123 se 0 ata1: status=0x51 { DriveReady SeekComplete Error } ata1: error=0x84 { DriveStatusError BadCRC } ata1: port reset, p_is 40000000 is 1 pis 0 cmd 44017 tf 8451 ss 123 se 0 ata1: status=0x51 { DriveReady SeekComplete Error } ata1: error=0x84 { DriveStatusError BadCRC } ata1: port reset, p_is 40000000 is 1 pis 0 cmd 44017 tf 8451 ss 123 se 0 ata1: status=0x51 { DriveReady SeekComplete Error } ata1: error=0x84 { DriveStatusError BadCRC } ata1: port reset, p_is 40000000 is 1 pis 0 cmd 44017 tf 8451 ss 123 se 0 ata1: status=0x51 { DriveReady SeekComplete Error } ata1: error=0x84 { DriveStatusError BadCRC } sd 0:0:0:0: SCSI error: return code = 0x8000002 sda: Current: sense key: Aborted Command Additional sense: Scsi parity error end_request: I/O error, dev sda, sector 172876369 ...and so on (different sectors, same type of error).
Additional testing has failed. As a test I brought up 3 Xen virtual machines using images on the SATA disk (no raid, just big files on that disk), and set them to rebuild the kernel. Immediately after reporting an ata1 error the machine reboot: Apr 16 09:17:01 westbengal kernel: ata1: port reset, p_is 8000000 is 1 pis 0 cmd 44017 tf d0 ss 123 se 0 Apr 16 09:17:01 westbengal kernel: ata1: status=0x50 { DriveReady SeekComplete }Apr 16 09:17:01 westbengal kernel: sda: Current: sense key: No Sense Apr 16 09:17:01 westbengal kernel: Additional sense: No additional sense information Apr 16 09:18:01 westbengal kernel: ata1: handling error/timeout Apr 16 09:18:01 westbengal kernel: ata1: port reset, p_is 0 is 0 pis 0 cmd 4c017 tf 150 ss 123 se 80000 Apr 16 09:18:01 westbengal kernel: ata1: status=0x50 { DriveReady SeekComplete }Apr 16 09:18:01 westbengal kernel: ata1: error=0x01 { AddrMarkNotFound } Apr 16 09:18:01 westbengal kernel: sda: Current: sense key: No Sense Apr 16 09:18:01 westbengal kernel: Additional sense: No additional sense information Apr 16 09:19:02 westbengal kernel: ata1: handling error/timeout Apr 16 09:20:11 westbengal syslogd 1.4.1: restart. Apr 16 09:20:11 westbengal kernel: klogd 1.4.1, log source = /proc/kmsg started.Apr 16 09:20:11 westbengal kernel: Linux version 2.6.16-1.2080_FC5.rootRWMxen0 (root.ca) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #1 SMP Thu Apr 13 09:46:45 EDT 2006 I tried running again, and got a similar problem as with Comment #8 where it went into a state where it gave a "BadCRC" error with every attempt to access a block. When I set things up with the 3 Xen disk images on a PATA drive I have no problems.
I see this error in an Asus P5V800-MX too. Here are more links: Via driver download for FC 1,2,4 http://www.viaarena.com/default.aspx?PageID=420&OSID=15&CatID=1830&SubCatID=167 http://www.viaarena.com/Driver/via%20fc4%20v-raid%20v2%5B1%5D.10%20driver%20appnote%20ver0.8.gz VT8251 driver status page in the forum: http://forums.viaarena.com/messageview.aspx?catid=28&threadid=71754 In the forum status page, says that the driver will be in the Linux kernel 2.6.19 and that it is working. HTH Oliver
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
Based on comments in the bug, this should be happier with current kernels. If not, please reopen or file a new bug with information about how things fail.