If I put in the Sempron single processor, works fine.

 

With Athlon x2: Kernel panic on queued up writes to *any* Sil3132 port.  If you do a "dd" with a small blocksize and a small count <= 100k, write works fine.

If you use "dd" with more than 200k, it immediately reboots.

 

"dd" reads work fine in any combination.

 

"dd" read+write work fine for the non-Sil3132 ports on the mainboard.

 

I was able to do an Unraid parity-sync with the Athlon x2.  The parity disk was using one of the mainboard ports (non-Sil3132), and the rest of the discs only have a couple of blocks written during the sync.  parity sync completed fine.  However, when I went to write my first file to a disk on a Sil3132 port, reboot.

 

Took out the Athlon x2, put in the Sempron x1 and it works fine.

 

Put in a different Athlon x2, problem comes back.

 

Boot Ubuntu desktop live CD (with 8.0.4 LTS), Athlon x2, and problem does not occur.

 

I strongly suspect this has something to do with the uniprocessor kernel + the Sil3132 driver + APIC or MSI.

 

I'd post to the Sil3132 driver bugs area, but I'm afraid of the comments "Your running a uni-processor kernel with a dual processor CPU - who in their right mind would do that?  Why would we want to test that?"

 

So, instead of going out and trying to find a single processor AM2+ CPU on a Sunday, I convinced my neighbor that it was time for him to have a free CPU upgrade.  It took longer to explain to him why I was so anxious to upgrade his computer for him to a dual processor than it took to do the upgrade 

 

So, for me, the FOUR DAYS that I wasted tracking this down and the 1TB of media I lost have made it so that I would tell anyone that "Unraid is only proven with single CPU systems".  The single-core kernel that Unraid is based on sees very little testing with multi-core CPUs in the general linux community, so you will be the alpha tester when you fire up your multi-core Unraid box.  Of course, this is only my opinion, and I'm not only entitled to it, I've earned it.

 

Has anyone asked recently about the availability of a multi-core Unraid kernel?  Single processor CPUs are getting hard to find with current mainboards.  Also, since I don't have any laying around from older systems, it raises the total cost of ownership for Unraid to have to go buy a single processor.

 

Yes, Unraid is a great product, but this is clearly an area of future vulnerability as the availability of single-core processors plummet.  Few people are ever going to test the non-SMP kernel and drivers with an SMP capable processor.

 

Just as a counterpoint, in no way disrespectful of your experiences, I am using an 'AMD Athlon 64 X2 4600+(65Watt version) 2.4GHz dual core', plus a SiI3132-based addon card (using sata_sil24 v1.1 driver) with 2 drives attached, and unRAID 4.3.3, without any issues, except that my motherboard currently requires the boot option noapic (get boot-time kernel panic without noapic).  Having seen a number of syslogs, I can say that the Linux kernels have for quite awhile dealt correctly with multiple processors, whether SMP or non-SMP.  I don't know if I can say a majority of users have dual core CPU's, but a sizable percentage do.  The following is what I have often seen in my own as well as numerous other users' syslogs:

Processor #0 15:11 APIC version 16
Processor #1 15:11 APIC version 16
WARNING: NR_CPUS limit of 1 reached.  Processor ignored.

 

I am in no way downplaying the seriousness of what you have experienced, and agree 'something' is very wrong.  I only want to say though that more data points are necessary, before we make any conclusions.  May I suggest reverting to an earlier kernel, such as in unRAID v4.2.4?  You might also want to try some of the boot options here.

Thanks Rob,

 

I had scoured the forums during those four days of trial and error, and I had already tried all of the boot options in all the combinations.  I created a matrix, tested each one, and checked the box in the matrix.

 

I found that without apic or acpi, the driver satasil_24 driver would not load on my system for the 4th and 5th Sil3132 cards.  Perhaps this is because the bios does not load for the 4th and 5th cards during the boot-up so it does not assign interrupts prior to boot.

 

I did try changing to 3 different bios versions in my mainboard, and I did try the different versions of the bios for the PCIe sil3132 card.  There is a "raid" version and an "ide" version.  I tried the current revision as well as the prior revision of the bios.

 

I'm sure it is something specific to my mainboard and the dual processor.  It would eventually be fixed if enough people ran their dual processors with a non-SMP kernel.

 

I had "burned-in" this setup for a week by using Ubuntu before I made the move.  I had even done testing with Unraid *before* moving my production drives over.  The parity rebuild worked fine (the parity drive was non-Sil3132, on the MB port).  Only once I had my production disks moved over and I attempted a write to one of the data disks on the Sil3132 controller did things go south.  Actually, I assumed it had to be the hard drive and went off in the wrong direction at first...

 

Anyway, It's working great now.  I'm getting 5x the speed on data/parity rebuilds than I did with the old PCI Sil3114 cards I was using.  I think I will post the hardware to the "it works" section.  My 16 x 1TB array rebuilds parity in 6 hours now.  When do the 2TB drives come out? 

 

I purchased some $42 AMD LE-1640 uni-processors (45W, 2.6GHz, 1MB L2) last night before they disappear so that I'm covered for the array builds I have planned for the rest of this year.

 

Overall, I'm pleased with how things worked out.  The old quote "A bad day fishing is better than a good day at work" applies in some way here.

 

"Prevailing over a difficult Unraid build is better than buying a Buffalo drive"

 

I wonder how many of the "doesn't work" posts might have actually worked if the tests were done with a uni-processor?