SiI 3132 goes crazy and marks both disks as "Reserved" after each reboot

[Lev Serebryakov]

Hello, Freebsd-hardware.

I've added SiI 3132-based controller with two SATA disks to system,
and almost lost my sanity: "gstripe" configuration becomes lost after
each reboot. After some investigation, I found, that after each reboot
last sector of disk contains SiI meta-information instead of
GEOM:STRIPE one.

SiI RAID uitility shows disks as "Reserved disks," but refuse to
delete RAID volume, as here is no one.

How to reset this state? And where SiI controller store information
(additional to last sector)?

[p***@pluto.rain.com]

Post by Lev Serebryakov
Hello, Freebsd-hardware.
I've added SiI 3132-based controller with two SATA disks to
system, and almost lost my sanity: "gstripe" configuration
becomes lost after each reboot. After some investigation,
I found, that after each reboot last sector of disk contains
SiI meta-information instead of GEOM:STRIPE one.
SiI RAID uitility shows disks as "Reserved disks," but refuse
to delete RAID volume, as here is no one.
How to reset this state? And where SiI controller store
information (additional to last sector)?

Dunno what-all else may be needed, but one way to preserve the SiI
metadata would be, instead of gstriping the disks themselves, make
a slice (MBR) or partition (GPT) on each disk -- a little smaller
than the whole disk -- and gstripe those slices or partitions.

[Cameron Berkenpas]

Post by p***@pluto.rain.com

Post by Lev Serebryakov
Hello, Freebsd-hardware.
I've added SiI 3132-based controller with two SATA disks to
system, and almost lost my sanity: "gstripe" configuration
becomes lost after each reboot. After some investigation,
I found, that after each reboot last sector of disk contains
SiI meta-information instead of GEOM:STRIPE one.
SiI RAID uitility shows disks as "Reserved disks," but refuse
to delete RAID volume, as here is no one.
How to reset this state? And where SiI controller store
information (additional to last sector)?

Dunno what-all else may be needed, but one way to preserve the SiI
metadata would be, instead of gstriping the disks themselves, make
a slice (MBR) or partition (GPT) on each disk -- a little smaller
than the whole disk -- and gstripe those slices or partitions.
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware

[Lev Serebryakov]

Hello, Perryh.

Post by p***@pluto.rain.com

Post by Lev Serebryakov
How to reset this state? And where SiI controller store
information (additional to last sector)?

Dunno what-all else may be needed, but one way to preserve the SiI
metadata would be, instead of gstriping the disks themselves, make
a slice (MBR) or partition (GPT) on each disk -- a little smaller
than the whole disk -- and gstripe those slices or partitions.

My task is directly the opposite: I want make SiI 3132 to FORGET about
all RAID-related stuff and to don't touch HDDs in any way and behave
as simple SATA HBA.

[Dieter BSD]

Post by Lev Serebryakov
I've added SiI 3132-based controller with two SATA disks to system,
and almost lost my sanity: "gstripe" configuration becomes lost after
each reboot. After some investigation, I found, that after each reboot
last sector of disk contains SiI meta-information instead of
GEOM:STRIPE one.

I have a couple of SiI 3132 controllers (Masscool XWT-PCIE10) with
GPT partitioned disks, and the last sectors still appear to contain
the Sec GPT headers after several reboots.

Post by Lev Serebryakov
How to reset this state? And where SiI controller store information
(additional to last sector)?

I suspect your card's BIOS code.  You could see if your mainboard
has an option to not run expansion card BIOS code.  You could see if
there is a better version of BIOS code available for your card.

<KLUDGE>
If all else fails, you could create a backup copy of the last sector
and have dd(1) restore it from rc.local or cron @reboot.
</KLUDGE>