[Bug 12303] New: Current kernels die with RAID0 on sata_sil

bugzilla-daemon at bugzilla.ubuntu.com bugzilla-daemon at bugzilla.ubuntu.com
Thu Jun 30 19:40:32 UTC 2005


Please do not reply to this email.  You can add comments at
http://bugzilla.ubuntu.com/show_bug.cgi?id=12303
Ubuntu | linux

           Summary: Current kernels die with RAID0 on sata_sil
           Product: Ubuntu
           Version: unspecified
          Platform: i386
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: linux
        AssignedTo: fabbione at ubuntu.com
        ReportedBy: unit3 at demoni.ca
         QAContact: kernel-bugs at lists.ubuntu.com


I've just tested linux-image-2.6.10-5 packages for k7, k7-smp, and 686-smp, with
the following results:

I have a backup server with .5 TB of temporary RAID0 storage on a Silicon Image
SATA controller (0000:02:08.0 RAID bus controller: Silicon Image, Inc. (formerly
CMD Technology Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 01)).

If I start up an Amanda job to back up 5 servers simultaneously (which starts a
gzip operation for each backup, and outputs the gzipped data to a file on the
RAID0 array), it will run for about 2 minutes at full processor usage (100%
user), when suddenly the wait usage (presumable software RAID) grows to 100%. In
both the K7 kernels, it'll be 100% on all available processors, whereas on the
686-smp kernel, it'll be 100% just on one processor. At that point, all activity
to the RAID array, from Amanda to a simple "ls", is completely dead, and nothing
but a reboot restores functionality.

I didn't have these problems with I had the exact same drives in a machine with
a VIA SATA controller, so it seems to be a problem with the Silicon Image
controller, or maybe an interaction with sata_sil and software RAID0.

-- 
Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.




More information about the kernel-bugs mailing list