Intel SASMF8I

Intel SASMF8I

[Marco Schindler]

[-- Attachment #1: Type: text/plain, Size: 130 bytes --]

Hello,
this card (using LSISAS1068(E)) is not recognized by FUSION_SAS, after
patching the device code it appears to work nicely.

[-- Attachment #2: fusion.mpt.lsi8208elp.patch --]
[-- Type: text/plain, Size: 1443 bytes --]

Signed-off-by: Marco Schindler <marco.schindler@gmail.com>
diff -ru --exclude=auto.conf --exclude=autoconf.h --exclude=mptsas.mod.c --exclude='*.o' --exclude='*.ko' linux.old/drivers/message/fusion/lsi/mpi_cnfg.h linux.new/drivers/message/fusion/lsi/mpi_cnfg.h
--- linux.old/drivers/message/fusion/lsi/mpi_cnfg.h	2009-01-27 23:37:45.000000000 +0100
+++ linux.new/drivers/message/fusion/lsi/mpi_cnfg.h	2009-01-27 23:53:07.000000000 +0100
@@ -569,6 +569,7 @@
 #define MPI_MANUFACTPAGE_DEVID_SAS1066E             (0x005A)
 #define MPI_MANUFACTPAGE_DEVID_SAS1068              (0x0054)
 #define MPI_MANUFACTPAGE_DEVID_SAS1068E             (0x0058)
+#define MPI_MANUFACTPAGE_DEVID_SAS1068_820XELP      (0x0059)
 #define MPI_MANUFACTPAGE_DEVID_SAS1078              (0x0062)
 
 
diff -ru --exclude=auto.conf --exclude=autoconf.h --exclude=mptsas.mod.c --exclude='*.o' --exclude='*.ko' linux.old/drivers/message/fusion/mptsas.c linux.new/drivers/message/fusion/mptsas.c
--- linux.old/drivers/message/fusion/mptsas.c	2009-01-27 23:37:45.000000000 +0100
+++ linux.new/drivers/message/fusion/mptsas.c	2009-01-27 23:54:00.000000000 +0100
@@ -3335,6 +3335,8 @@
 		PCI_ANY_ID, PCI_ANY_ID },
 	{ PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVID_SAS1078,
 		PCI_ANY_ID, PCI_ANY_ID },
+	{ PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVID_SAS1068_820XELP,
+		PCI_ANY_ID, PCI_ANY_ID },
 	{0}	/* Terminating entry */
 };
 MODULE_DEVICE_TABLE(pci, mptsas_pci_table);

Re: Intel SASMF8I

[Ilia Mirkin]

On Fri, Mar 19, 2010 at 6:39 PM, Marco Schindler
<marco.schindler@gmail.com> wrote:
> Hello,
> this card (using LSISAS1068(E)) is not recognized by FUSION_SAS, after
> patching the device code it appears to work nicely.
>

I was 99% of the way there to submit a similar patch (actually there's
a few more places where you want to add the new ID), but noticed a
previous discussion when a comparable patch was rejected. Turns out
there was a jumper on my motherboard (Supermicro X8DT3) which switches
between "raid" and "regular" mode (except they were called something
much fancier), and the regular mode switches the PCI ID to 0x58 which
in turn is recognized. [And the mptsas driver doesn't support the RAID
features anyways... there's a what appears to be proprietary driver
for that, megasr, which I did not need.]

Re: Intel SASMF8I

[Marco Schindler]

On 19.03.10 23:46, Ilia Mirkin wrote:
> On Fri, Mar 19, 2010 at 6:39 PM, Marco Schindler
> <marco.schindler@gmail.com>  wrote:
>> Hello,
>> this card (using LSISAS1068(E)) is not recognized by FUSION_SAS, after
>> patching the device code it appears to work nicely.
>>
>
> I was 99% of the way there to submit a similar patch (actually there's
> a few more places where you want to add the new ID), but noticed a
> previous discussion when a comparable patch was rejected. Turns out
> there was a jumper on my motherboard (Supermicro X8DT3) which switches
> between "raid" and "regular" mode (except they were called something
> much fancier), and the regular mode switches the PCI ID to 0x58 which
> in turn is recognized. [And the mptsas driver doesn't support the RAID
> features anyways... there's a what appears to be proprietary driver
> for that, megasr, which I did not need.]

SASMF8I doesn't seem to have any jumpers for "regular" mode and I don't 
want to use the sw raid of the chip. As far as I remember megasr didn't 
let me access drives directly. Is there no option then, except patching 
locally?

Re: Intel SASMF8I

[Christoph Hellwig]

On Sat, Mar 20, 2010 at 12:04:16AM +0100, Marco Schindler wrote:
> SASMF8I doesn't seem to have any jumpers for "regular" mode and I don't  
> want to use the sw raid of the chip. As far as I remember megasr didn't  
> let me access drives directly. Is there no option then, except patching  
> locally?

I think we should add it in that case.  There's no reason to cripple
Linux on hardware just because the bios pretends it has some useless
fake raid capabilities.