Hi,
I own a neat little AMD64 Shuttle SN85G4 (V1) which works great with FC3, so I recommended buying the same to my dad. He bought the same, but it's V3 now, which apparently features a newer nForce3 250 chipset, and possibly some other minor changes. I only had an i386 FC3 install DVD handy when he got it, and with only a modem connection, it really was my only option, so I installed that... things went fine (except the Radeon 9200 through the DVI output, the display went all black all the time after a few seconds, VGA works fine though). My problem here is that it installed flawlessly on the Serial-ATA hard drive attached to that nForce3 250 chipset (sata_nv module), but the machine was never able to boot from the installed system.
I tried all that I could and came to these conclusions : - It's not an IRQ problem (it shares IRQ11 with the firewire, but also does at install time and I tried with another IRQ and firewire disabled, same thing). - It's not an ACPI or APIC issue (or at least isn't fixed by disabling them).
I actually really don't know what the problem can be. I tried with the latest updated kernel, same thing. I also tried creating an initrd which preloads all the same modules anaconda loads before loading sata_nv (usb, firewire, scsi, forcedeth) in case the reverse engineered eth driver did something weird that helped, or in case the delay in loading them gave enough time to the drive to spin up or something, but no go.
Booting the install CD in rescue more _always_ works at getting the Serial-ATA drive detected, whereas booting the installed system _never_ does (grub is there, and the initrd is loaded fine). The error on google only shows LKML reports about problems with sata_via back in the 2.4 days.
The exact error is this : ata1 is slow to respond, please be patient ata1 failed to respond (30 secs)
All the kernel messages above (about detecting the chipset and both ata1 and ata2) are identical for the kernel used in anaconda and the one installed. The kernel version, as well as the libata and sata_nv versions reported are identical too...
So I was wondering what the issue could be. Some anaconda magic that the installed system doesn't perform? Having an i686 kernel on that x86-64 machine and anaconda having yet another one?
For now I've put a good old parallel ATA drive, but still can't access the Serial-ATA drive from that installed and booting system :-(
Matthias
On Mon, Jan 03, 2005 at 04:29:48PM +0100, Matthias Saou wrote:
So I was wondering what the issue could be. Some anaconda magic that the installed system doesn't perform? Having an i686 kernel on that x86-64 machine and anaconda having yet another one?
I seem to recall that anaconda boots an i586 kernel.
Once upon a time, Ralf Ertzinger fedora-devel@camperquake.de said:
On Mon, Jan 03, 2005 at 04:29:48PM +0100, Matthias Saou wrote:
So I was wondering what the issue could be. Some anaconda magic that the installed system doesn't perform? Having an i686 kernel on that x86-64 machine and anaconda having yet another one?
I seem to recall that anaconda boots an i586 kernel.
Not for FC3; I can't boot the installer on an AMD K6-III (sigh).
It sounds like your problem is *nearly* identical to mine on the Shuttle SN95G5, except you can actually get the installer to boot:
https://bugzilla.redhat.com/beta/show_bug.cgi?id=135302
There is also another SATA-related installer bug that might be related. One of the comments in #135302 points to an OSDL kernel bugzilla entry with more information.
You wouldn't happen to be using a Seagate SATA drive would you?
The kernel bugzilla entry has a small workaround (that has been included in 2.6.10) that fixes the problem for me. I ended up having to do a two-drive monte from a spare PATA drive to get it installed: 1. Install on PATA hard-drive 2. Compile src.rpm with patched sata_nv.c 3. Create a boot disk (this *should* have been step 3, but wasn't) 4. Reboot with new kernel 5. Migrate data from PATA hard-drive (LVM2 makes this much easier) 6. Run grub-install on the SATA hard-drive and hope it gets everything correct. 7. Remove the old hard-drive. 8. Don't update to anything less than a 2.6.10 kernel.
Note that you might want to reboot between step 5 and 6 to make sure the data migrated correctly as well as between 6 and 7. I know I had to do some extra work to get grub-install working correctly (this was why making the boot disk should have been step 3).
Since you don't have any problem getting it installed, it doesn't sound like you'll have to go through all of those machinations, but I hope this helps.
Shahms King wrote :
It sounds like your problem is *nearly* identical to mine on the Shuttle SN95G5, except you can actually get the installer to boot:
https://bugzilla.redhat.com/beta/show_bug.cgi?id=135302
There is also another SATA-related installer bug that might be related. One of the comments in #135302 points to an OSDL kernel bugzilla entry with more information.
OK... bugzilla.redhat.com was down when I was struggling with all this a few days ago, so I hadn't found all that info since google doesn't seem to index all of it. Nor does it seem to have indexed the OSDL bug for that matter.
You wouldn't happen to be using a Seagate SATA drive would you?
Nope, Maxtor DiamondMax 10 (IIRC, the "10" I'm sure of) 200GB.
The kernel bugzilla entry has a small workaround (that has been included in 2.6.10) that fixes the problem for me. [...]
Thanks for the pointer and tip. Unfortunately, downloading a kernel source rpm simply wasn't an option, and I only had the install DVD (which doesn't contain the .src.rpms anymore), so I would have been stuck anyway without a single kernel to recompile.
What _really_ puzzles me is that the FC3 install works fine for me. Booting the DVD in rescue mode too. But no installed system is able to see the SATA drive again...
Thanks for all the pointers! Now I just need to figure out how to explain all this to a non-expert over the phone... *sigh*
Matthias
On Mon, 2005-01-03 at 17:25 +0100, Matthias Saou wrote:
Thanks for the pointer and tip. Unfortunately, downloading a kernel source rpm simply wasn't an option, and I only had the install DVD (which doesn't contain the .src.rpms anymore), so I would have been stuck anyway without a single kernel to recompile.
What _really_ puzzles me is that the FC3 install works fine for me. Booting the DVD in rescue mode too. But no installed system is able to see the SATA drive again...
Thanks for all the pointers! Now I just need to figure out how to explain all this to a non-expert over the phone... *sigh*
It looks like Rawhide has a 2.6.10 kernel in it finally, so if you can explain updating to a Rawhide kernel over the phone you might be set. It should be as simple as:
# yum --enablerepo=development install kernel
On Monday, January 03, 2005 9:30 AM, Matthias Saou wrote:
Hi,
I own a neat little AMD64 Shuttle SN85G4 (V1) which works great with FC3, so I recommended buying the same to my dad. He bought the same, but it's V3 now, which apparently features a newer nForce3 250 chipset, and possibly some other minor changes. I only had an i386 FC3 install DVD handy when he got it, and with only a modem connection, it really was my only option, so I installed that... things went fine (except the Radeon 9200 through the DVI output, the display went all black all the time after a few seconds, VGA works fine though). My problem here is that it installed flawlessly on the Serial-ATA hard drive attached to that nForce3 250 chipset (sata_nv module), but the machine was never able to boot from the installed system.
Sounds a lot like: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140367
Is the serial ata drive by any chance a Seagate? If so, you may want to try this kernel: http://www.wtamu.edu/~mlauterbach/kernel-2.6.9-1.681_FC3_SATA.root.i686.rpm
All that is changed in this kernel is a line or two commented out. I have yet to get around to making and verifying that this will fix the x86_64 version of FC3 yet. x86_64 and i386 versions of FC3 both behaved exactly the same for me.
Matthew E. Lauterbach
devel@lists.stg.fedoraproject.org