I wonder if anyone might hazard a guess or provide any suggestions..

I've got a Tyan S2882 "Thunder K8S Pro" AMD Opteron server I'm having issues with. For the past year+ it's had Fedora Core3 X86_64 installed and working fine, and stable. The RAID feature was not supported and I had disabled it in the BIOS and used software mirroring in Linux. With the advent of 2.6.15+ in FC5 the RAID feature does appear to be supported. The box has been running out of space for a while and I've needed a good excuse to upgrade it.. So I replaced the pair of 200GB SATA drives with some 300GB drives, enabling the hardware RAID in the BIOS, building a RAID1 mirror set and installing FC5 on it. It's primarily a MySQL server for developers to work with, nothing graphical is ever done on it, Fedora Core is just fine for this...

Anyway, after a bit of heavy use it "freezes". I can still ping it and can still telnet to open TCP services and get a connect, but no header back.

Since it's got Seagate drives, I'm wondering if this note from the Linux SATA status report is relevant:

http://linux-ata.org/sata-status.html#sii311x
Silicon Image 3112/3114
Summary: No TCQ/NCQ. Looks like a PATA controller, but with full SATA control including hotplug and PM.

libata driver status: Production, but appears to have issues with newer Seagate NCQ drives, and issues with "screaming interrupts."

Update: The "screaming interrupts" issues appear to be fixed, when polling is disabled. drivers/ide driver status: Beta?



If so, how does one "disable polling"? Any other thoughts or suggestions? Thanks...

IMHO, Silicon Image controllers are a piece of crap. I recommend Highpoint SATA controllers like RocketRAID 1520 or 1540. If you are a Promise controller fan, they also suck in Linux. Highpoint SATA controllers are the only SATA controller that works well. Seagate SATA hard drives are pathetic.

There is no hardware RAID on the motherboard when using SATA. It is actually software RAID.

I won't disagree with you on that point.. When we first received this server, it was a test to try and go cheaper than the SuperMicro equipment we more commonly used. Right off the bat when the built-in "RAID" was not supported by a current Linux kernel (of the time), I formed a bad opinion of it. Now though 2.6.15 does support it and it might be "software RAID" but the kernel shows it as a single device at least "as if" it were real RAID.

The 1520 you mentioned is only ~$60 so that might be an option. Is Linux kernel support rock-solid without the need to install additional drivers at boot time? The note about Highpoint on that same SATA Status Page isn't overly promising. I've gotten Marvell SATA chipsets to work in Linux but not natively, boot diskettes, rebuilding kernels, etc.. The very thing I'll deal with for an extra specialized card but loathe to have to fool with for my root disk controller.

---
http://linux-ata.org/sata-status.html#hpt
HighPoint (HPT)
Some of the recent HighPoint cards are based on the Marvell 88SX50xx chips. These will be supported by the Marvell libata driver (in progress, see above).

I have had no contact with HighPoint. If there are SATA cards besides the Marvell-based ones (are there?), someone should poke HPT to send me a card and docs.

libata driver status: Use sata_mv.
---

Would you have a recommendation on hard drives then? What you call pathetic, I call pretty-much-the-best-that-can-be-had today... 5yr warranty, NCQ, etc...

http://www.seagate.com/cda/products/...81,631,00.html

Also, with recent acquisitions, there isn't a whole lot of choices other than Seagate...

Thanks!

OK, after a bit more testing I have some info on this problem...

Tyan 2882 1U Opteron server, 4GB RAM, 2X Seagate 300GB SATA drives, on-board Silicon Image "RAID", Fedora Core 5 X86_64.

What was freezing up the box was a developer running a PERL data conversion program that was opening up a very large file and slurping it all into an array for sequential processing: "@ARRAY=<FILE>". I had him change that to a "while (<FILE>) {" to process a record at a time and what was consistently locking up the box, is not any longer. (So far, it's processing now and is not finished and has used about 70% of physical RAM at this point...)

Next, to investigate a bit further and to see what was going on we ran it the old way while I had top running. At the exact moment all physical RAM was exhausted, it froze up. SWAP was not being used at this point and I assumed it was about to start trying to swap. So as an experiment I removed the swap line entirely from /etc/fstab and rebooted and tried the test again. Without the ability to swap at all, it again froze the moment physical RAM was exhausted.

So I put the swap space back in play, rebooted with "kernel.sysrq = 1" in /etc/sysctl.conf and added some console=tty0... info on the grub boot line and intentionally locked it up and grabbed some traces. I don't really know what to do with them though and can't submit them to RedHat as I usually do, this is Fedora not RHEL

Suggestions, thoughts, ideas? Open a bug request with Fedora or the kernel developers or ??? Pointers on where/how to do that? Thanks.

The best IDE/SATA hard drives are from IBM/Hitachi and Western Digital. For a server, Western Digital Raptor hard drives are better.

The Highpoint RocketRAID 1520 or 1540 uses the hpt366 module that comes from the kernel. The 1840 and up uses the Marvell chip.

Your problems is like everybody's problems with Silicon Image controllers. Silicon Image controllers are poor when dealing with large requests. What I read, it happens on every Linux distribution because it is a kernel problem.

The last time I checked Fedora Core 5 is beta. I do not like Fedora anyways, so I recomend Gentoo.