Ross S. W. Walker wrote:
Ray Van Dolson wrote:
Hi all, we're trying to install CentOS 5.1 on a Sun Ultra
- This is
an AMD-powered machine and we're using the x86_64 version of CentOS 5.1. The machine is using the NVidia CK804 chipset and has SATA disks. It also has 16GB's of memory which prompted us to upgrade
the BIOS on
the machine from 1.1 to 1.6 per this (we also have the two quadro cards):
http://docs.sun.com/source/819-3954-18/index.html#0_37092
The install goes fine up until the installer is trying to format the disks. Part of the way through it simply dies and pops up an error saying that the installer couldn't format the LVM volume and we have to reboot.
An examination of dmesg output shows that there are many SATA errors occuring at this point. Timeouts and such.
After a reboot, the SATA drive no longer shows up -- not
even in BIOS.
It's as if the formatting has instructed the drive to deactivate itself. :) A hard reset and reseat of the drive in the
SATA enclosure
brings it back again.
First thought was that the slot or SATA port was bad, so we
have moved
to others with the same result.
Solaris 10 x86 installs perfectly on this machine, so I'm
starting to
think that the sata_nv driver is to blame here.
We're in the process of trying 32-bit CentOS 5.1 on the system just for giggles, and may try Fedora 8 as well or RHEL 5.1 and use our paid support to track this issue down, but thought I'd run it by everyone here.
Didn't see any existing issues in bugzilla.redhat.com or bugs.centos.org.
Any insights on this?
I will get the exact error messages posted up here soon (output from dmesg, etc).
Try "acpi=noirq" as a kernel argument. Some AMD chipsets have problems letting the OS know what irq the 8250 timer is on, the nvidia one is definitely a problem, I have the same chipset in a couple of Dell Dimension e521 desktops :-(
My explaination wasn't totally accurate. The acpi=noirq disables the ACPI IRQ routing table lookup for IRQ redirects and reprogramming. Some AMD chipsets had a bug in the way this table was built that caused 2.6 kernels to fail in getting a hook into the table which caused all kinds of intermittent problems. By disabling this feature you run the possibility of IRQ conflicts that will need to use the IRQ management in the BIOS to resolve. Updating the BIOS of the system sometimes fixes the problem.
It just turns out that the system timer irq was my "symptom" that I experienced, but it is different for different systems/configurations.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.