Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Jord Tanner]

On Tue Dec 30 2003 - 16:11:40 EST Brad House wrote:

        Ok, I just ported the 2.00.9 driver to 2.6.0.
        It still has these warnings during compilation as I did not
        attempt to apply my 64bit fixes from before as I've been told
        they are just plain wrong :/
        
        But, I suppose this should work fine in 32bit mode, I would
        greatly appreciate any help in porting it for 64bit platforms.
        
        The patch can be downloaded here :
        http://dev.gentoo.org/~brad_mssw/kernel_patches/megaraid/megaraid-v2.00.9-linux2.6.patch
        And only applies to the source from ftp.lsil.com, it's not a
        kernel-patch
        per-se, but copying the result over to the drivers/scsi will
        compile inplace
        of the current versions.
        
        Please CC me on any replies!
        -Brad House <brad_mssw@xxxxxxxxxx>



This thread has been inactive for a while, but I've not found anything
more relevant to my situation. 

I'm running 2.6.3-gentoo (and 2.6.5-gentoo) with a LSILogic SATA
Megaraid 150-6 raid controller on a dual Opteron system. The entire
system is compiled in 64bit. We are seeing random database corruption
when access very large Postgres tables (more than 10 million rows).
Other than that, the system runs beautifully.

As far as I can tell, no amd64 specific patches have been applied to the
megaraid driver in 2.6.3 (version 2.00.3). Brad House has posted a 2.6
patch for megaraid 2.00.9, but his previous amd64 patches were removed.
LSI tech support has suggested I upgrade to 2.00.9, but the LSI source
is for 2.4.

So my questions are:

        - Could the 2.00.3 driver be responsible for random data
        corruption when running on 2.6.3 in 64bit?
        - Is it safe to run Brad House's 2.6 megaraid 2.00.9 patches in
        64 bit mode on amd64?
        - Are there any patches for megaraid 2.00.9 (or higher, I see
        2.00.10-3 has just been released) that combine patches for 2.6
        and amd64?
        
TIA,


-- 
Jord Tanner <jord@indygecko.com>

RE: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Mukker, Atul]

It is 64-bit safe and tested, to some degree, on 64-bit platforms as well.

Thanks
-Atul Mukker

> -----Original Message-----
> From: Jord Tanner [mailto:jord@indygecko.com]
> Sent: Friday, April 16, 2004 3:22 PM
> To: Mukker, Atul
> Cc: linux-kernel@vger.kernel.org; brad_mssw@gentoo.org
> Subject: RE: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)
> 
> 
> 
> Thanks Atul!
> 
> After patching for 2.6.5 the 2.20.0.B2 driver compiled clean and the
> machine in now running with that driver. We are about to run 
> some stress
> tests to see if we can duplicate the previous problems. 
> 
> Given that we are running a 64bit compile, and the previous 
> attempts by
> Brad House to make amd64 modifications were abandonded, could you
> comment on whether you think the newest megaraid code
> (ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-unified
> -2.20.0.B2.04.14.2004)
> is 64bit safe?  
> 
> TIA
> 
> Jord Tanner
> Independent Gecko Consultants
> 
> On Fri, 2004-04-16 at 09:35, Mukker, Atul wrote:
> > Please use the latest driver 2.20.0.B2, about to be 
> released today. Please
> > provide a feedback if you see the same issues.
> > 
> > -Atul Mukker
> > LSI Logic
> > 
> > > -----Original Message-----
> > > From: Jord Tanner [mailto:jord@indygecko.com]
> > > Sent: Friday, April 16, 2004 9:57 AM
> > > To: linux-kernel@vger.kernel.org
> > > Cc: brad_mssw@gentoo.org; Atulm@lsil.com
> > > Subject: Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)
> > > 
> > > 
> > > 
> > > On Tue Dec 30 2003 - 16:11:40 EST Brad House wrote:
> > > 
> > >         Ok, I just ported the 2.00.9 driver to 2.6.0.
> > >         It still has these warnings during compilation as 
> I did not
> > >         attempt to apply my 64bit fixes from before as 
> I've been told
> > >         they are just plain wrong :/
> > >         
> > >         But, I suppose this should work fine in 32bit 
> mode, I would
> > >         greatly appreciate any help in porting it for 
> 64bit platforms.
> > >         
> > >         The patch can be downloaded here :
> > >         
> > > http://dev.gentoo.org/~brad_mssw/kernel_patches/megaraid/megar
> > > aid-v2.00.9-linux2.6.patch
> > >         And only applies to the source from ftp.lsil.com, 
> it's not a
> > >         kernel-patch
> > >         per-se, but copying the result over to the 
> drivers/scsi will
> > >         compile inplace
> > >         of the current versions.
> > >         
> > >         Please CC me on any replies!
> > >         -Brad House <brad_mssw@xxxxxxxxxx>
> > > 
> > > 
> > > 
> > > This thread has been inactive for a while, but I've not 
> found anything
> > > more relevant to my situation. 
> > > 
> > > I'm running 2.6.3-gentoo (and 2.6.5-gentoo) with a LSILogic SATA
> > > Megaraid 150-6 raid controller on a dual Opteron system. 
> The entire
> > > system is compiled in 64bit. We are seeing random 
> database corruption
> > > when access very large Postgres tables (more than 10 
> million rows).
> > > Other than that, the system runs beautifully.
> > > 
> > > As far as I can tell, no amd64 specific patches have been 
> > > applied to the
> > > megaraid driver in 2.6.3 (version 2.00.3). Brad House has 
> posted a 2.6
> > > patch for megaraid 2.00.9, but his previous amd64 patches 
> > > were removed.
> > > LSI tech support has suggested I upgrade to 2.00.9, but 
> the LSI source
> > > is for 2.4.
> > > 
> > > So my questions are:
> > > 
> > >         - Could the 2.00.3 driver be responsible for random data
> > >         corruption when running on 2.6.3 in 64bit?
> > >         - Is it safe to run Brad House's 2.6 megaraid 2.00.9 
> > > patches in
> > >         64 bit mode on amd64?
> > >         - Are there any patches for megaraid 2.00.9 (or 
> higher, I see
> > >         2.00.10-3 has just been released) that combine 
> patches for 2.6
> > >         and amd64?
> > >         
> > > TIA,
> > > 
> > > 
> > > -- 
> > > Jord Tanner <jord@indygecko.com>
> > > 
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe 
> > > linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> > > 
> -- 
> Jord Tanner <jord@indygecko.com>
> 

RE: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Mukker, Atul]

Please use the latest driver 2.20.0.B2, about to be released today. Please
provide a feedback if you see the same issues.

-Atul Mukker
LSI Logic

> -----Original Message-----
> From: Jord Tanner [mailto:jord@indygecko.com]
> Sent: Friday, April 16, 2004 9:57 AM
> To: linux-kernel@vger.kernel.org
> Cc: brad_mssw@gentoo.org; Atulm@lsil.com
> Subject: Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)
> 
> 
> 
> On Tue Dec 30 2003 - 16:11:40 EST Brad House wrote:
> 
>         Ok, I just ported the 2.00.9 driver to 2.6.0.
>         It still has these warnings during compilation as I did not
>         attempt to apply my 64bit fixes from before as I've been told
>         they are just plain wrong :/
>         
>         But, I suppose this should work fine in 32bit mode, I would
>         greatly appreciate any help in porting it for 64bit platforms.
>         
>         The patch can be downloaded here :
>         
> http://dev.gentoo.org/~brad_mssw/kernel_patches/megaraid/megar
> aid-v2.00.9-linux2.6.patch
>         And only applies to the source from ftp.lsil.com, it's not a
>         kernel-patch
>         per-se, but copying the result over to the drivers/scsi will
>         compile inplace
>         of the current versions.
>         
>         Please CC me on any replies!
>         -Brad House <brad_mssw@xxxxxxxxxx>
> 
> 
> 
> This thread has been inactive for a while, but I've not found anything
> more relevant to my situation. 
> 
> I'm running 2.6.3-gentoo (and 2.6.5-gentoo) with a LSILogic SATA
> Megaraid 150-6 raid controller on a dual Opteron system. The entire
> system is compiled in 64bit. We are seeing random database corruption
> when access very large Postgres tables (more than 10 million rows).
> Other than that, the system runs beautifully.
> 
> As far as I can tell, no amd64 specific patches have been 
> applied to the
> megaraid driver in 2.6.3 (version 2.00.3). Brad House has posted a 2.6
> patch for megaraid 2.00.9, but his previous amd64 patches 
> were removed.
> LSI tech support has suggested I upgrade to 2.00.9, but the LSI source
> is for 2.4.
> 
> So my questions are:
> 
>         - Could the 2.00.3 driver be responsible for random data
>         corruption when running on 2.6.3 in 64bit?
>         - Is it safe to run Brad House's 2.6 megaraid 2.00.9 
> patches in
>         64 bit mode on amd64?
>         - Are there any patches for megaraid 2.00.9 (or higher, I see
>         2.00.10-3 has just been released) that combine patches for 2.6
>         and amd64?
>         
> TIA,
> 
> 
> -- 
> Jord Tanner <jord@indygecko.com>
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

RE: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Jord Tanner]

Thanks Atul!

After patching for 2.6.5 the 2.20.0.B2 driver compiled clean and the
machine in now running with that driver. We are about to run some stress
tests to see if we can duplicate the previous problems. 

Given that we are running a 64bit compile, and the previous attempts by
Brad House to make amd64 modifications were abandonded, could you
comment on whether you think the newest megaraid code
(ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-unified-2.20.0.B2.04.14.2004)
is 64bit safe?  

TIA

Jord Tanner
Independent Gecko Consultants

On Fri, 2004-04-16 at 09:35, Mukker, Atul wrote:
> Please use the latest driver 2.20.0.B2, about to be released today. Please
> provide a feedback if you see the same issues.
> 
> -Atul Mukker
> LSI Logic
> 
> > -----Original Message-----
> > From: Jord Tanner [mailto:jord@indygecko.com]
> > Sent: Friday, April 16, 2004 9:57 AM
> > To: linux-kernel@vger.kernel.org
> > Cc: brad_mssw@gentoo.org; Atulm@lsil.com
> > Subject: Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)
> > 
> > 
> > 
> > On Tue Dec 30 2003 - 16:11:40 EST Brad House wrote:
> > 
> >         Ok, I just ported the 2.00.9 driver to 2.6.0.
> >         It still has these warnings during compilation as I did not
> >         attempt to apply my 64bit fixes from before as I've been told
> >         they are just plain wrong :/
> >         
> >         But, I suppose this should work fine in 32bit mode, I would
> >         greatly appreciate any help in porting it for 64bit platforms.
> >         
> >         The patch can be downloaded here :
> >         
> > http://dev.gentoo.org/~brad_mssw/kernel_patches/megaraid/megar
> > aid-v2.00.9-linux2.6.patch
> >         And only applies to the source from ftp.lsil.com, it's not a
> >         kernel-patch
> >         per-se, but copying the result over to the drivers/scsi will
> >         compile inplace
> >         of the current versions.
> >         
> >         Please CC me on any replies!
> >         -Brad House <brad_mssw@xxxxxxxxxx>
> > 
> > 
> > 
> > This thread has been inactive for a while, but I've not found anything
> > more relevant to my situation. 
> > 
> > I'm running 2.6.3-gentoo (and 2.6.5-gentoo) with a LSILogic SATA
> > Megaraid 150-6 raid controller on a dual Opteron system. The entire
> > system is compiled in 64bit. We are seeing random database corruption
> > when access very large Postgres tables (more than 10 million rows).
> > Other than that, the system runs beautifully.
> > 
> > As far as I can tell, no amd64 specific patches have been 
> > applied to the
> > megaraid driver in 2.6.3 (version 2.00.3). Brad House has posted a 2.6
> > patch for megaraid 2.00.9, but his previous amd64 patches 
> > were removed.
> > LSI tech support has suggested I upgrade to 2.00.9, but the LSI source
> > is for 2.4.
> > 
> > So my questions are:
> > 
> >         - Could the 2.00.3 driver be responsible for random data
> >         corruption when running on 2.6.3 in 64bit?
> >         - Is it safe to run Brad House's 2.6 megaraid 2.00.9 
> > patches in
> >         64 bit mode on amd64?
> >         - Are there any patches for megaraid 2.00.9 (or higher, I see
> >         2.00.10-3 has just been released) that combine patches for 2.6
> >         and amd64?
> >         
> > TIA,
> > 
> > 
> > -- 
> > Jord Tanner <jord@indygecko.com>
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe 
> > linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
-- 
Jord Tanner <jord@indygecko.com>

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Jord Tanner]

Paul,

(I'm not subscribed to the list, so if this doesn't make it through,
please forward it for me)

After some testing, the machine works much better with the new
(2.20.0.B2) megaraid driver, but we still get the occasional postgres
corrupted data. The symptoms are somewhat different now (corrupted pages
contain mostly blanks, whereas with the 2.00.3 driver the pages were
filled with FF), so I think there may be multiple causes. We were
running XFS on LVM2 on linux RAID0 on megaraid RAID1. I switched from
XFS to JFS yesterday, and at this point have not had any more problems.
We are continuing to test, and once we have a stable configuration, I'll
post the details.

Jord Tanner
Independent Gecko Consultants

On Thu, 2004-04-22 at 09:18, Paul Wagland wrote:
> Hi Jord,
> 
> In response to this thread I seem to recall that you mentioned that you  
> would test out the new driver and see if it resolved your problem. I  
> was wondering if you had any results from this testing yet?
> 
> Thanks in advance,
> Paul
> 
> On Apr 16, 2004, at 21:21, Jord Tanner wrote:
> 
> >
> > Thanks Atul!
> >
> > After patching for 2.6.5 the 2.20.0.B2 driver compiled clean and the
> > machine in now running with that driver. We are about to run some  
> > stress
> > tests to see if we can duplicate the previous problems.
> >
> > Given that we are running a 64bit compile, and the previous attempts by
> > Brad House to make amd64 modifications were abandonded, could you
> > comment on whether you think the newest megaraid code
> > (ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-unified
> > -2.20.0.B2.04.14.2004)
> > is 64bit safe?
> >
> > TIA
> >
> > Jord Tanner
> > Independent Gecko Consultants
> >
> > On Fri, 2004-04-16 at 09:35, Mukker, Atul wrote:
> >> Please use the latest driver 2.20.0.B2, about to be released today.  
> >> Please
> >> provide a feedback if you see the same issues.
> >>
> >> -Atul Mukker
> >> LSI Logic
> >>
> >>> -----Original Message-----
> >>> From: Jord Tanner [mailto:jord@indygecko.com]
> >>> Sent: Friday, April 16, 2004 9:57 AM
> >>> To: linux-kernel@vger.kernel.org
> >>> Cc: brad_mssw@gentoo.org; Atulm@lsil.com
> >>> Subject: Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)
> >>>
> >>>
> >>>
> >>> On Tue Dec 30 2003 - 16:11:40 EST Brad House wrote:
> >>>
> >>>         Ok, I just ported the 2.00.9 driver to 2.6.0.
> >>>         It still has these warnings during compilation as I did not
> >>>         attempt to apply my 64bit fixes from before as I've been told
> >>>         they are just plain wrong :/
> >>>
> >>>         But, I suppose this should work fine in 32bit mode, I would
> >>>         greatly appreciate any help in porting it for 64bit  
> >>> platforms.
> >>>
> >>>         The patch can be downloaded here :
> >>>
> >>> http://dev.gentoo.org/~brad_mssw/kernel_patches/megaraid/megar
> >>> aid-v2.00.9-linux2.6.patch
> >>>         And only applies to the source from ftp.lsil.com, it's not a
> >>>         kernel-patch
> >>>         per-se, but copying the result over to the drivers/scsi will
> >>>         compile inplace
> >>>         of the current versions.
> >>>
> >>>         Please CC me on any replies!
> >>>         -Brad House <brad_mssw@xxxxxxxxxx>
> >>>
> >>>
> >>>
> >>> This thread has been inactive for a while, but I've not found  
> >>> anything
> >>> more relevant to my situation.
> >>>
> >>> I'm running 2.6.3-gentoo (and 2.6.5-gentoo) with a LSILogic SATA
> >>> Megaraid 150-6 raid controller on a dual Opteron system. The entire
> >>> system is compiled in 64bit. We are seeing random database corruption
> >>> when access very large Postgres tables (more than 10 million rows).
> >>> Other than that, the system runs beautifully.
> >>>
> >>> As far as I can tell, no amd64 specific patches have been
> >>> applied to the
> >>> megaraid driver in 2.6.3 (version 2.00.3). Brad House has posted a  
> >>> 2.6
> >>> patch for megaraid 2.00.9, but his previous amd64 patches
> >>> were removed.
> >>> LSI tech support has suggested I upgrade to 2.00.9, but the LSI  
> >>> source
> >>> is for 2.4.
> >>>
> >>> So my questions are:
> >>>
> >>>         - Could the 2.00.3 driver be responsible for random data
> >>>         corruption when running on 2.6.3 in 64bit?
> >>>         - Is it safe to run Brad House's 2.6 megaraid 2.00.9
> >>> patches in
> >>>         64 bit mode on amd64?
> >>>         - Are there any patches for megaraid 2.00.9 (or higher, I see
> >>>         2.00.10-3 has just been released) that combine patches for  
> >>> 2.6
> >>>         and amd64?
> >>>
> >>> TIA,
> >>>
> >>>
> >>> -- 
> >>> Jord Tanner <jord@indygecko.com>
> >>>
> >>> -
> >>> To unsubscribe from this list: send the line "unsubscribe
> >>> linux-kernel" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>> Please read the FAQ at  http://www.tux.org/lkml/
> >>>
> > -- 
> > Jord Tanner <jord@indygecko.com>
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe  
> > linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
-- 
Jord Tanner <jord@indygecko.com>

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Christoph Hellwig]

On Thu, Apr 22, 2004 at 11:22:17AM -0700, Jord Tanner wrote:
> filled with FF), so I think there may be multiple causes. We were
> running XFS on LVM2 on linux RAID0 on megaraid RAID1.

That looks like eating lots of stack...  So you might aswell have had stack
overruns.

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Andi Kleen]

"Brad House" <brad_mssw@gentoo.org> writes:
>
> diff -ruN linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.c
> linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.c
> --- linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.c	2003-12-29
> 23:51:43.000000000 -0500
> +++ linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.c	2003-12-29
> 23:54:01.005469936 -0500
> @@ -1292,7 +1292,7 @@
>
>  			/* Calculate Scatter-Gather info */
>  			mbox->m_out.numsgelements = mega_build_sglist(adapter, scb,
> -					(u32 *)&mbox->m_out.xferaddr, (u32 *)&seg);
> +					(dma_addr_t *)&mbox->m_out.xferaddr, (u32 *)&seg);

I'm pretty sure it's completely broken. You're changing the layout of 
a data structure that is shared with the firmware. Using a 32bit
int here is fine when the driver sets the correct dma mask or 
only stuffs pci_alloc_consistent() memory in there (i think it's
the later here)

Even though the driver prints lots of warnings at compile time it
actually works on AMD64 as is. But in many cases you should
use megaraid2.c instead of megaraid.c.

-Andi

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Brad House]

Well, the point was it _didn't_ work on AMD64 with 2.6.0 at all.
Which was what I was trying to fix.  Also, it is a megaraid2 series
driver in the 2.6.0 kernel (2.00.3), I've since ported the 2.00.9
2.4 driver to 2.6.0, but have not yet had it tested (I did not
make the 64bit changes I had posted a patch for).
I guess we'll see, I hope bumping to 2.00.9 works.

-Brad

> "Brad House" <brad_mssw@gentoo.org> writes:
>>
>> diff -ruN linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.c
>> linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.c
>> --- linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.c	2003-12-29
>> 23:51:43.000000000 -0500
>> +++ linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.c	2003-12-29
>> 23:54:01.005469936 -0500
>> @@ -1292,7 +1292,7 @@
>>
>>  			/* Calculate Scatter-Gather info */
>>  			mbox->m_out.numsgelements = mega_build_sglist(adapter, scb,
>> -					(u32 *)&mbox->m_out.xferaddr, (u32 *)&seg);
>> +					(dma_addr_t *)&mbox->m_out.xferaddr, (u32 *)&seg);
>
> I'm pretty sure it's completely broken. You're changing the layout of  a
> data structure that is shared with the firmware. Using a 32bit
> int here is fine when the driver sets the correct dma mask or
> only stuffs pci_alloc_consistent() memory in there (i think it's
> the later here)
>
> Even though the driver prints lots of warnings at compile time it
> actually works on AMD64 as is. But in many cases you should
> use megaraid2.c instead of megaraid.c.
>
> -Andi

[PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Brad House]

In an attempt to fix a Gentoo user's problem, and get rid
of compilation warnings for 64bit (on AMD64 mainly) megaraid
compilation, I have created this patch, and needs some
extensive testing.

The only thing I wasn't sure about was what unsigned integer
was guaranteed to be the exact size of a pointer, and it seemed
that looking in include/asm-x86_64/types.h that  dma_addr_t
was the only one that fit the bill.

Anyhow, the patch is inlined below, as well as available
for download here:
http://dev.gentoo.org/~brad_mssw/kernel_patches/2.6.0/megaraid_64bit_patch.diff

Please CC: me on any replies as I am not subscribed to this
list!

-Brad House
brad_mssw@gentoo.org

diff -ruN linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.c
linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.c
--- linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.c	2003-12-29
23:51:43.000000000 -0500
+++ linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.c	2003-12-29
23:54:01.005469936 -0500
@@ -1292,7 +1292,7 @@

 			/* Calculate Scatter-Gather info */
 			mbox->m_out.numsgelements = mega_build_sglist(adapter, scb,
-					(u32 *)&mbox->m_out.xferaddr, (u32 *)&seg);
+					(dma_addr_t *)&mbox->m_out.xferaddr, (u32 *)&seg);

 			return scb;

@@ -2262,7 +2262,7 @@
  * Note: For 64 bit cards, we need a minimum of one SG element for
read/write
  */
 static int
-mega_build_sglist(adapter_t *adapter, scb_t *scb, u32 *buf, u32 *len)
+mega_build_sglist(adapter_t *adapter, scb_t *scb, dma_addr_t *buf, u32 *len)
 {
 	struct scatterlist	*sgl;
 	struct page	*page;
@@ -2962,8 +2962,8 @@
 			mbox->m_out.numsectors);
 	len += sprintf(page+len, "  LBA          = 0x%02x\n",
 			mbox->m_out.lba);
-	len += sprintf(page+len, "  DTA          = 0x%08x\n",
-			mbox->m_out.xferaddr);
+	len += sprintf(page+len, "  DTA          = 0x%08lx\n",
+			(unsigned long int)mbox->m_out.xferaddr);
 	len += sprintf(page+len, "  Logical Drive= 0x%02x\n",
 			mbox->m_out.logdrv);
 	len += sprintf(page+len, "  No of SG Elmt= 0x%02x\n",
@@ -4048,7 +4048,7 @@
 	megacmd_t	mc;
 	megastat_t	*ustats;
 	int		num_ldrv;
-	u32		uxferaddr = 0;
+	dma_addr_t	uxferaddr = 0;
 	struct pci_dev	*pdev;

 	ustats = NULL; /* avoid compilation warnings */
diff -ruN linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.h
linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.h
--- linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.h	2003-12-29
23:51:43.000000000 -0500
+++ linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.h	2003-12-29
23:54:01.005469936 -0500
@@ -125,7 +125,7 @@
 	/* 0x1 */ u8 cmdid;
 	/* 0x2 */ u16 numsectors;
 	/* 0x4 */ u32 lba;
-	/* 0x8 */ u32 xferaddr;
+	/* 0x8 */ dma_addr_t xferaddr;
 	/* 0xC */ u8 logdrv;
 	/* 0xD */ u8 numsgelements;
 	/* 0xE */ u8 resvd;
@@ -173,7 +173,7 @@
 	u8 reqsensearea[MAX_REQ_SENSE_LEN];
 	u8 numsgelements;
 	u8 scsistatus;
-	u32 dataxferaddr;
+	dma_addr_t dataxferaddr;
 	u32 dataxferlen;
 } __attribute__ ((packed)) mega_passthru;

@@ -201,7 +201,7 @@
 	u8 reqsenselen;
 	u8 reqsensearea[MAX_REQ_SENSE_LEN];
 	u8 rsvd4;
-	u32 dataxferaddr;
+	dma_addr_t dataxferaddr;
 	u32 dataxferlen;
 } __attribute__ ((packed)) mega_ext_passthru;

@@ -211,7 +211,7 @@
 } __attribute__ ((packed)) mega_sgl64;

 typedef struct {
-	u32 address;
+	dma_addr_t address;
 	u32 length;
 } __attribute__ ((packed)) mega_sglist;

@@ -561,7 +561,7 @@
 	u8	opcode;
 	u8	subopcode;
 	u32	lba;
-	u32	xferaddr;
+	dma_addr_t	xferaddr;
 	u8	logdrv;
 	u8	rsvd[3];
 	u8	numstatus;
@@ -1016,7 +1016,7 @@
 static int mega_print_inquiry(char *, char *);

 static int mega_build_sglist (adapter_t *adapter, scb_t *scb,
-			      u32 *buffer, u32 *length);
+			      dma_addr_t *buffer, u32 *length);
 static inline int mega_busywait_mbox (adapter_t *);
 static int __mega_busywait_mbox (adapter_t *);
 static void mega_rundoneq (adapter_t *);

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Jeff Garzik]

On Tue, Dec 30, 2003 at 12:10:27AM -0500, Brad House wrote:
> In an attempt to fix a Gentoo user's problem, and get rid
> of compilation warnings for 64bit (on AMD64 mainly) megaraid
> compilation, I have created this patch, and needs some
> extensive testing.
> 
> The only thing I wasn't sure about was what unsigned integer
> was guaranteed to be the exact size of a pointer, and it seemed
> that looking in include/asm-x86_64/types.h that  dma_addr_t
> was the only one that fit the bill.

It's not this simple, unfortuantely...


> diff -ruN linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.c
> linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.c
> --- linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.c	2003-12-29
> 23:51:43.000000000 -0500
> +++ linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.c	2003-12-29
> 23:54:01.005469936 -0500
> @@ -1292,7 +1292,7 @@
> 
>  			/* Calculate Scatter-Gather info */
>  			mbox->m_out.numsgelements = mega_build_sglist(adapter, scb,
> -					(u32 *)&mbox->m_out.xferaddr, (u32 *)&seg);
> +					(dma_addr_t *)&mbox->m_out.xferaddr, (u32 *)&seg);

Casting just hides a bug.  The real fix is to pass a full 64-bit address
into the s/g list, if it supports 64-bit addresses.  if it doesn't, you
need to make sure the driver doesn't set highmem_io, make sure the
driver doesn't set a 64-bit DMA mask, and make sure the driver does set
a 32-bit DMA mask.


>  			return scb;
> 
> @@ -2262,7 +2262,7 @@
>   * Note: For 64 bit cards, we need a minimum of one SG element for
> read/write
>   */
>  static int
> -mega_build_sglist(adapter_t *adapter, scb_t *scb, u32 *buf, u32 *len)
> +mega_build_sglist(adapter_t *adapter, scb_t *scb, dma_addr_t *buf, u32 *len)
>  {
>  	struct scatterlist	*sgl;
>  	struct page	*page;
> @@ -2962,8 +2962,8 @@
>  			mbox->m_out.numsectors);
>  	len += sprintf(page+len, "  LBA          = 0x%02x\n",
>  			mbox->m_out.lba);
> -	len += sprintf(page+len, "  DTA          = 0x%08x\n",
> -			mbox->m_out.xferaddr);
> +	len += sprintf(page+len, "  DTA          = 0x%08lx\n",
> +			(unsigned long int)mbox->m_out.xferaddr);

just use 'unsigned long'.  Further, the printk() mask is wrong as it's
obviously longer than 8 chars on 64-bit.


>  	len += sprintf(page+len, "  Logical Drive= 0x%02x\n",
>  			mbox->m_out.logdrv);
>  	len += sprintf(page+len, "  No of SG Elmt= 0x%02x\n",
> @@ -4048,7 +4048,7 @@
>  	megacmd_t	mc;
>  	megastat_t	*ustats;
>  	int		num_ldrv;
> -	u32		uxferaddr = 0;
> +	dma_addr_t	uxferaddr = 0;
>  	struct pci_dev	*pdev;
> 
>  	ustats = NULL; /* avoid compilation warnings */
> diff -ruN linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.h
> linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.h
> --- linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.h	2003-12-29
> 23:51:43.000000000 -0500
> +++ linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.h	2003-12-29
> 23:54:01.005469936 -0500
> @@ -125,7 +125,7 @@
>  	/* 0x1 */ u8 cmdid;
>  	/* 0x2 */ u16 numsectors;
>  	/* 0x4 */ u32 lba;
> -	/* 0x8 */ u32 xferaddr;
> +	/* 0x8 */ dma_addr_t xferaddr;
>  	/* 0xC */ u8 logdrv;
>  	/* 0xD */ u8 numsgelements;
>  	/* 0xE */ u8 resvd;
> @@ -173,7 +173,7 @@
>  	u8 reqsensearea[MAX_REQ_SENSE_LEN];
>  	u8 numsgelements;
>  	u8 scsistatus;
> -	u32 dataxferaddr;
> +	dma_addr_t dataxferaddr;
>  	u32 dataxferlen;
>  } __attribute__ ((packed)) mega_passthru;
> 
> @@ -201,7 +201,7 @@
>  	u8 reqsenselen;
>  	u8 reqsensearea[MAX_REQ_SENSE_LEN];
>  	u8 rsvd4;
> -	u32 dataxferaddr;
> +	dma_addr_t dataxferaddr;
>  	u32 dataxferlen;
>  } __attribute__ ((packed)) mega_ext_passthru;
> 
> @@ -211,7 +211,7 @@
>  } __attribute__ ((packed)) mega_sgl64;
> 
>  typedef struct {
> -	u32 address;
> +	dma_addr_t address;
>  	u32 length;
>  } __attribute__ ((packed)) mega_sglist;
> 
> @@ -561,7 +561,7 @@
>  	u8	opcode;
>  	u8	subopcode;
>  	u32	lba;
> -	u32	xferaddr;
> +	dma_addr_t	xferaddr;
>  	u8	logdrv;
>  	u8	rsvd[3];
>  	u8	numstatus;
> @@ -1016,7 +1016,7 @@
>  static int mega_print_inquiry(char *, char *);
> 
>  static int mega_build_sglist (adapter_t *adapter, scb_t *scb,
> -			      u32 *buffer, u32 *length);
> +			      dma_addr_t *buffer, u32 *length);
>  static inline int mega_busywait_mbox (adapter_t *);
>  static int __mega_busywait_mbox (adapter_t *);
>  static void mega_rundoneq (adapter_t *);


Not that easy.  You gotta know the hardware (and firmware)...

	Jeff

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Brad House]

Hmm, I don't think this driver is as complex as others may
be to port.  But then again, I'm probably wrong b/c I'm mainly
a userland guy, not a kernel guy :/
But, nonetheless, I've made some changes:

>>  			/* Calculate Scatter-Gather info */
>>  			mbox->m_out.numsgelements = mega_build_sglist(adapter, scb,
>> -					(u32 *)&mbox->m_out.xferaddr, (u32 *)&seg);
>> +					(dma_addr_t *)&mbox->m_out.xferaddr, (u32 *)&seg);
>
> Casting just hides a bug.

Well, the  xferaddr is actually a dma_addr_t now, so that cast really
does nothing, the only reason it's there is because they previously
casted it as (u32 *).  I removed the cast just so it couldn't obscure
warnings, and it didn't.

Also, I use  dma_addr_t even though it may have nothing to do with dma
where it's used. I'm more familiar with userland stuff, so I wasn't sure
what to use. In userland I'd use  uintptr_t.

> The real fix is to pass a full 64-bit address

I did find a few instances where they recast the addresses,
which was improper, but it does appear that the original address
in the original driver was coming in as 64bit (dma_addr_t as originally
written), but were passing it around and casting it as a u32, so I
think the interfaces allowed for it to work, they just wrote it
unware of 64bit systems.

Also, they tried to stuff the address returned here :
ext_inq = pci_alloc_consistent(adapter->dev,
                                sizeof(mraid_ext_inquiry), &dma_handle);
(the dma_handle) into a u32 which I just fixed.

> into the s/g list, if it supports 64-bit addresses.  if it doesn't, you
> need to make sure the driver doesn't set highmem_io, make sure the
> driver doesn't set a 64-bit DMA mask, and make sure the driver does set
> a 32-bit DMA mask.

The driver already does this it appears, without me needing to do it,
Part of which is covered by this:
 /* Set the Mode of addressing to 64 bit if we can */
                if((adapter->flag & BOARD_64BIT)&&(sizeof(dma_addr_t) ==
8)) {
                        pci_set_dma_mask(pdev, 0xffffffffffffffffULL);
                        adapter->has_64bit_addr = 1;
                }
                else  {
                        pci_set_dma_mask(pdev, 0xffffffff);
                        adapter->has_64bit_addr = 0;
                }


>
> Not that easy.  You gotta know the hardware (and firmware)...

The thing is the symptoms were that systems with > 4GB of RAM oddly
enough would cause major data corruption, but reducing it to 4GB would
solve the problem (mostly, still some oddities supposedly).  It seemed
like an addressing issue, and it was pretty blatant that the addresses
were being truncated, and that's what I was trying to solve.
Like I said, it partially works at this time, so I doubt there is anything
seriously wrong with the driver other than what I've fixed here, but
I could definately be wrong :/

I did find some more issues of casting though, which I've inlined below and
is located at :
http://dev.gentoo.org/~brad_mssw/kernel_patches/2.6.0/megaraid_64bit_patch-2.diff

-Brad


diff -ruN linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.c
linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.c
--- linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.c	2003-12-29
23:51:43.000000000 -0500
+++ linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.c	2003-12-30
01:32:55.253327136 -0500
@@ -742,7 +742,7 @@
 	 * if not succeeded, then issue MEGA_MBOXCMD_ADAPTERINQ command and
 	 * update enquiry3 structure
 	 */
-	mbox->m_out.xferaddr = (u32)adapter->buf_dma_handle;
+	mbox->m_out.xferaddr = adapter->buf_dma_handle;

 	inquiry3 = (mega_inquiry3 *)adapter->mega_buffer;

@@ -765,7 +765,7 @@

 		inq = &ext_inq->raid_inq;

-		mbox->m_out.xferaddr = (u32)dma_handle;
+		mbox->m_out.xferaddr = dma_handle;

 		/*issue old 0x04 command to adapter */
 		mbox->m_out.cmd = MEGA_MBOXCMD_ADPEXTINQ;
@@ -1292,7 +1292,7 @@

 			/* Calculate Scatter-Gather info */
 			mbox->m_out.numsgelements = mega_build_sglist(adapter, scb,
-					(u32 *)&mbox->m_out.xferaddr, (u32 *)&seg);
+					&mbox->m_out.xferaddr, (u32 *)&seg);

 			return scb;

@@ -2262,7 +2262,7 @@
  * Note: For 64 bit cards, we need a minimum of one SG element for
read/write
  */
 static int
-mega_build_sglist(adapter_t *adapter, scb_t *scb, u32 *buf, u32 *len)
+mega_build_sglist(adapter_t *adapter, scb_t *scb, dma_addr_t *buf, u32 *len)
 {
 	struct scatterlist	*sgl;
 	struct page	*page;
@@ -2292,12 +2292,12 @@
 		if( adapter->has_64bit_addr ) {
 			scb->sgl64[0].address = scb->dma_h_bulkdata;
 			scb->sgl64[0].length = cmd->request_bufflen;
-			*buf = (u32)scb->sgl_dma_addr;
+			*buf = scb->sgl_dma_addr;
 			*len = (u32)cmd->request_bufflen;
 			return 1;
 		}
 		else {
-			*buf = (u32)scb->dma_h_bulkdata;
+			*buf = scb->dma_h_bulkdata;
 			*len = (u32)cmd->request_bufflen;
 		}

@@ -2962,8 +2962,8 @@
 			mbox->m_out.numsectors);
 	len += sprintf(page+len, "  LBA          = 0x%02x\n",
 			mbox->m_out.lba);
-	len += sprintf(page+len, "  DTA          = 0x%08x\n",
-			mbox->m_out.xferaddr);
+	len += sprintf(page+len, "  DTA          = 0x%lx\n",
+			(unsigned long)mbox->m_out.xferaddr);
 	len += sprintf(page+len, "  Logical Drive= 0x%02x\n",
 			mbox->m_out.logdrv);
 	len += sprintf(page+len, "  No of SG Elmt= 0x%02x\n",
@@ -3599,7 +3599,7 @@
 		return len;
 	}

-	mc.xferaddr = (u32)disk_array_dma_handle;
+	mc.xferaddr = disk_array_dma_handle;

 	if( adapter->flag & BOARD_40LD ) {
 		mc.cmd = FC_NEW_CONFIG;
@@ -4048,7 +4048,7 @@
 	megacmd_t	mc;
 	megastat_t	*ustats;
 	int		num_ldrv;
-	u32		uxferaddr = 0;
+	dma_addr_t	uxferaddr = 0;
 	struct pci_dev	*pdev;

 	ustats = NULL; /* avoid compilation warnings */
@@ -4078,13 +4078,13 @@
 	switch( uioc.opcode ) {

 	case GET_DRIVER_VER:
-		if( put_user(driver_ver, (u32 *)uioc.uioc_uaddr) )
+		if( put_user(driver_ver, uioc.uioc_uaddr) )
 			return (-EFAULT);

 		break;

 	case GET_N_ADAP:
-		if( put_user(hba_count, (u32 *)uioc.uioc_uaddr) )
+		if( put_user(hba_count, uioc.uioc_uaddr) )
 			return (-EFAULT);

 		/*
@@ -4291,7 +4291,7 @@
 			memset(&mc, 0, sizeof(megacmd_t));

 			mc.cmd = MEGA_MBOXCMD_PASSTHRU;
-			mc.xferaddr = (u32)pthru_dma_hndl;
+			mc.xferaddr = pthru_dma_hndl;

 			/*
 			 * Issue the command
@@ -4374,7 +4374,7 @@

 			memcpy(&mc, MBOX(uioc), sizeof(megacmd_t));

-			mc.xferaddr = (u32)data_dma_hndl;
+			mc.xferaddr = data_dma_hndl;

 			/*
 			 * Issue the command
@@ -4636,7 +4636,7 @@

 	memset((void *)adapter->mega_buffer, 0, MEGA_BUFFER_SIZE);

-	mbox->m_out.xferaddr = (u32)adapter->buf_dma_handle;
+	mbox->m_out.xferaddr = adapter->buf_dma_handle;

 	raw_mbox[0] = IS_BIOS_ENABLED;
 	raw_mbox[2] = GET_BIOS;
@@ -4675,7 +4675,7 @@

 	memset((void *)adapter->mega_buffer, 0, MEGA_BUFFER_SIZE);

-	mbox->m_out.xferaddr = (u32)adapter->buf_dma_handle;
+	mbox->m_out.xferaddr = adapter->buf_dma_handle;

 	/*
 	 * Non-ROMB firware fail this command, so all channels
@@ -4730,7 +4730,7 @@

 	memset((void *)adapter->mega_buffer, 0, MEGA_BUFFER_SIZE);

-	mbox->m_out.xferaddr = (u32)adapter->buf_dma_handle;
+	mbox->m_out.xferaddr = adapter->buf_dma_handle;

 	adapter->boot_ldrv_enabled = 0;
 	adapter->boot_ldrv = 0;
@@ -4936,7 +4936,7 @@

 	memset((void *)adapter->mega_buffer, 0, MEGA_BUFFER_SIZE);

-	mbox->m_out.xferaddr = (u32)adapter->buf_dma_handle;
+	mbox->m_out.xferaddr = adapter->buf_dma_handle;

 	raw_mbox[0] = MAIN_MISC_OPCODE;
 	raw_mbox[2] = GET_MAX_SG_SUPPORT;
@@ -4981,7 +4981,7 @@

 	memset((void *)adapter->mega_buffer, 0, MEGA_BUFFER_SIZE);

-	mbox->m_out.xferaddr = (u32)adapter->buf_dma_handle;
+	mbox->m_out.xferaddr = adapter->buf_dma_handle;

 	/*
 	 * Try to get the initiator id. This command will succeed iff the
@@ -5091,7 +5091,7 @@
 		mc.cmd = MEGA_MBOXCMD_ADPEXTINQ;
 	}

-	mc.xferaddr = (u32)dma_handle;
+	mc.xferaddr = dma_handle;

 	if ( mega_internal_command(adapter, LOCK_INT, &mc, NULL) != 0 ) {
 		return -1;
@@ -5174,13 +5174,13 @@
 	pthru->cdb[5] = 0;


-	pthru->dataxferaddr = (u32)buf_dma_handle;
+	pthru->dataxferaddr = buf_dma_handle;
 	pthru->dataxferlen = 256;

 	memset(&mc, 0, sizeof(megacmd_t));

 	mc.cmd = MEGA_MBOXCMD_PASSTHRU;
-	mc.xferaddr = (u32)pthru_dma_handle;
+	mc.xferaddr = pthru_dma_handle;

 	rval = mega_internal_command(adapter, LOCK_INT, &mc, pthru);

diff -ruN linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.h
linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.h
--- linux-2.6.0-gentoo-r1.old/drivers/scsi/megaraid.h	2003-12-29
23:51:43.000000000 -0500
+++ linux-2.6.0-gentoo-r1/drivers/scsi/megaraid.h	2003-12-30
01:32:55.257326528 -0500
@@ -125,7 +125,7 @@
 	/* 0x1 */ u8 cmdid;
 	/* 0x2 */ u16 numsectors;
 	/* 0x4 */ u32 lba;
-	/* 0x8 */ u32 xferaddr;
+	/* 0x8 */ dma_addr_t xferaddr;
 	/* 0xC */ u8 logdrv;
 	/* 0xD */ u8 numsgelements;
 	/* 0xE */ u8 resvd;
@@ -173,7 +173,7 @@
 	u8 reqsensearea[MAX_REQ_SENSE_LEN];
 	u8 numsgelements;
 	u8 scsistatus;
-	u32 dataxferaddr;
+	dma_addr_t dataxferaddr;
 	u32 dataxferlen;
 } __attribute__ ((packed)) mega_passthru;

@@ -201,7 +201,7 @@
 	u8 reqsenselen;
 	u8 reqsensearea[MAX_REQ_SENSE_LEN];
 	u8 rsvd4;
-	u32 dataxferaddr;
+	dma_addr_t dataxferaddr;
 	u32 dataxferlen;
 } __attribute__ ((packed)) mega_ext_passthru;

@@ -211,7 +211,7 @@
 } __attribute__ ((packed)) mega_sgl64;

 typedef struct {
-	u32 address;
+	dma_addr_t address;
 	u32 length;
 } __attribute__ ((packed)) mega_sglist;

@@ -561,7 +561,7 @@
 	u8	opcode;
 	u8	subopcode;
 	u32	lba;
-	u32	xferaddr;
+	dma_addr_t	xferaddr;
 	u8	logdrv;
 	u8	rsvd[3];
 	u8	numstatus;
@@ -1016,7 +1016,7 @@
 static int mega_print_inquiry(char *, char *);

 static int mega_build_sglist (adapter_t *adapter, scb_t *scb,
-			      u32 *buffer, u32 *length);
+			      dma_addr_t *buffer, u32 *length);
 static inline int mega_busywait_mbox (adapter_t *);
 static int __mega_busywait_mbox (adapter_t *);
 static void mega_rundoneq (adapter_t *);

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Jeff Garzik]

Brad House wrote:
> Hmm, I don't think this driver is as complex as others may
> be to port.  But then again, I'm probably wrong b/c I'm mainly
> a userland guy, not a kernel guy :/
> But, nonetheless, I've made some changes:

The only thing that matters is the hardware s/g list capabilities. 
Driver complexity is irrelevant.


>>> 			/* Calculate Scatter-Gather info */
>>> 			mbox->m_out.numsgelements = mega_build_sglist(adapter, scb,
>>>-					(u32 *)&mbox->m_out.xferaddr, (u32 *)&seg);
>>>+					(dma_addr_t *)&mbox->m_out.xferaddr, (u32 *)&seg);
>>
>>Casting just hides a bug.
> 
> 
> Well, the  xferaddr is actually a dma_addr_t now, so that cast really
> does nothing, the only reason it's there is because they previously
> casted it as (u32 *).  I removed the cast just so it couldn't obscure
> warnings, and it didn't.
> 
> Also, I use  dma_addr_t even though it may have nothing to do with dma
> where it's used. I'm more familiar with userland stuff, so I wasn't sure
> what to use. In userland I'd use  uintptr_t.
> 
> 
>>The real fix is to pass a full 64-bit address
> 
> 
> I did find a few instances where they recast the addresses,
> which was improper, but it does appear that the original address
> in the original driver was coming in as 64bit (dma_addr_t as originally
> written), but were passing it around and casting it as a u32, so I
> think the interfaces allowed for it to work, they just wrote it
> unware of 64bit systems.
> 
> Also, they tried to stuff the address returned here :
> ext_inq = pci_alloc_consistent(adapter->dev,
>                                 sizeof(mraid_ext_inquiry), &dma_handle);
> (the dma_handle) into a u32 which I just fixed.
> 
> 
>>into the s/g list, if it supports 64-bit addresses.  if it doesn't, you
>>need to make sure the driver doesn't set highmem_io, make sure the
>>driver doesn't set a 64-bit DMA mask, and make sure the driver does set
>>a 32-bit DMA mask.
> 
> 
> The driver already does this it appears, without me needing to do it,
> Part of which is covered by this:
>  /* Set the Mode of addressing to 64 bit if we can */
>                 if((adapter->flag & BOARD_64BIT)&&(sizeof(dma_addr_t) ==
> 8)) {
>                         pci_set_dma_mask(pdev, 0xffffffffffffffffULL);
>                         adapter->has_64bit_addr = 1;
>                 }
>                 else  {
>                         pci_set_dma_mask(pdev, 0xffffffff);
>                         adapter->has_64bit_addr = 0;
>                 }

This code is completely bogus and wrong (not your fault, but still). 
Take a look at tg3.c for the right way to do it.

The driver continues to have obvious 64-bit issues that your patch 
doesn't address.  Your main test platform should really be a 32-bit 
system with PAE, and >4GB of RAM.

	Jeff

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Samuel Flory]

   Wouldn't it be more useful to port megaraid2 from 2.4?

-- 
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Brad House]

Well, I thought this was megaraid2
from the .h file:
#define MEGARAID_VERSION        \
        "v2.00.3 (Release Date: Wed Feb 19 08:51:30 EST 2003)\n"

Perhaps I should search around and see if I can find a later one
though ??

-Brad

>    Wouldn't it be more useful to port megaraid2 from 2.4?
>
> --
> There is no such thing as obsolete hardware.
> Merely hardware that other people don't want.
> (The Second Rule of Hardware Acquisition)
> Sam Flory  <sflory@rackable.com>

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Samuel Flory]

Brad House wrote:
> Well, I thought this was megaraid2
> from the .h file:
> #define MEGARAID_VERSION        \
>         "v2.00.3 (Release Date: Wed Feb 19 08:51:30 EST 2003)\n"
> 
> Perhaps I should search around and see if I can find a later one
> though ??
> 

   There is a 2.00.9 in 2.4.  In theory you should really be asking on
linux-megaraid-devel@dell.com.
> 
> 
>>   Wouldn't it be more useful to port megaraid2 from 2.4?
>>
>>--
>>There is no such thing as obsolete hardware.
>>Merely hardware that other people don't want.
>>(The Second Rule of Hardware Acquisition)
>>Sam Flory  <sflory@rackable.com>
> 
> 
> 
> 


-- 
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Brad House]

Ok, I just ported the 2.00.9 driver to 2.6.0.
It still has these warnings during compilation as I did not
attempt to apply my 64bit fixes from before as I've been told
they are just plain wrong :/

But, I suppose this should work fine in 32bit mode, I would
greatly appreciate any help in porting it for 64bit platforms.

The patch can be downloaded here :
http://dev.gentoo.org/~brad_mssw/kernel_patches/megaraid/megaraid-v2.00.9-linux2.6.patch
And only applies to the source from ftp.lsil.com, it's not a kernel-patch
per-se, but copying the result over to the drivers/scsi  will compile inplace
of the current versions.

Please CC me on any replies!
-Brad House <brad_mssw@gentoo.org>

I've also inlined it here:
# To use this patch, you must extract the megaraid 2.00.9 tarball
# from
ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-2.00.9/megaraid.tgz
# and   mv megaraid2.c megaraid.c
#       mv megaraid2.h megaraid.h
# Then
#       patch -p1 < megaraid-v2.00.9-linux2.6.patch
# This patch is based off the v2.00.5 linux2.5.6x patch from
#
ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-2.00.5/megaraid2005-2.5.6x.patch.gz
# TODO: - Figure out if megaraid_isr_iomapped and megaraid_isr_memmapped
are implemented
#         correctly
#       - Make it 64bit clean, as it gets 'cast to pointer from integer of
different size'
#         warnings
# Brad House <brad_mssw@gentoo.org> 12/30/03
diff -ruN megaraid-v2.00.9/megaraid.c megaraid-v2.00.9-linux2.6/megaraid.c
--- megaraid-v2.00.9/megaraid.c	2003-09-09 15:24:36.000000000 -0400
+++ megaraid-v2.00.9-linux2.6/megaraid.c	2003-12-30 16:18:06.298221000 -0500
@@ -32,18 +32,20 @@

 #include <linux/mm.h>
 #include <linux/fs.h>
-#include <linux/blk.h>
+#include <linux/blkdev.h>
 #include <asm/uaccess.h>
 #include <linux/delay.h>
 #include <linux/reboot.h>
 #include <linux/module.h>
 #include <linux/list.h>
+#include <linux/interrupt.h>
+#include <linux/proc_fs.h>
+#include <scsi/scsicam.h>

-#include "sd.h"
 #include "scsi.h"
 #include "hosts.h"

-#include "megaraid2.h"
+#include "megaraid.h"

 MODULE_AUTHOR ("LSI Logic Corporation");
 MODULE_DESCRIPTION ("LSI Logic MegaRAID driver");
@@ -88,10 +90,10 @@
  * The File Operations structure for the serial/ioctl interface of the
driver
  */
 static struct file_operations megadev_fops = {
+	.owner		= THIS_MODULE,
 	.ioctl		= megadev_ioctl,
 	.open		= megadev_open,
 	.release	= megadev_close,
-	.owner		= THIS_MODULE,
 };

 /*
@@ -174,11 +176,6 @@
 	}

 	if(hba_count) {
-		/*
-		 * re-order hosts so that one with bootable logical drive
-		 * comes first
-		 */
-		mega_reorder_hosts();

 #ifdef CONFIG_PROC_FS
 		mega_proc_dir_entry = proc_mkdir("megaraid", &proc_root);
@@ -320,13 +317,12 @@

 		if( pci_resource_flags(pdev, 0) & IORESOURCE_MEM ) {

-			if( check_mem_region(mega_baseport, 128) ) {
+			if (!request_mem_region(mega_baseport, 128,
+					"MegaRAID: LSI Logic Corporation.")) {
 				printk(KERN_WARNING
 					"megaraid: mem region busy!\n");
 				continue;
 			}
-			request_mem_region(mega_baseport, 128,
-					"MegaRAID: LSI Logic Corporation.");

 			mega_baseport =
 				(unsigned long)ioremap(mega_baseport, 128);
@@ -362,7 +358,7 @@

 		did_scsi_reg_f = 1;

-		scsi_set_pci_device(host, pdev);
+		scsi_set_device(host, &pdev->dev);

 		adapter = (adapter_t *)host->hostdata;
 		memset(adapter, 0, sizeof(adapter_t));
@@ -400,7 +396,7 @@
 		// the lock in host structure.
 		adapter->host_lock = &adapter->lock;

-		host->lock = adapter->host_lock;
+		scsi_assign_lock(host, adapter->host_lock);

 		host->cmd_per_lun = max_cmd_per_lun;
 		host->max_sectors = max_sectors_per_io;
@@ -926,7 +922,7 @@
 	scb_t	*scb;
 	int	busy=0;

-	adapter = (adapter_t *)scmd->host->hostdata;
+	adapter = (adapter_t *)scmd->device->host->hostdata;

 	scmd->scsi_done = done;

@@ -1000,7 +996,7 @@
 	/*
 	 * We know what channels our logical drives are on - mega_find_card()
 	 */
-	islogical = adapter->logdrv_chan[cmd->channel];
+	islogical = adapter->logdrv_chan[cmd->device->channel];

 	/*
 	 * The theory: If physical drive is chosen for boot, all the physical
@@ -1012,12 +1008,13 @@
 	if( adapter->boot_pdrv_enabled ) {
 		if( islogical ) {
 			/* logical channel */
-			channel = cmd->channel -
+			channel = cmd->device->channel -
 				adapter->product_info.nchannels;
 		}
 		else {
-			channel = cmd->channel; /* this is physical channel */
-			target = cmd->target;
+			/* this is physical channel */
+			channel = cmd->device->channel;
+			target = cmd->device->id;

 			/*
 			 * boot from a physical disk, that disk needs to be
@@ -1034,13 +1031,13 @@
 	}
 	else {
 		if( islogical ) {
-			channel = cmd->channel;	/* this is the logical channel
-						 */
+			/* this is the logical channel */
+			channel = cmd->device->channel;
 		}
 		else {
-			channel = cmd->channel - NVIRT_CHAN;	/* physical
-								   channel */
-			target = cmd->target;
+			/* physical channel */
+			channel = cmd->device->channel - NVIRT_CHAN;
+			target = cmd->device->id;
 		}
 	}

@@ -1048,7 +1045,7 @@
 	if(islogical) {

 		/* have just LUN 0 for each target on virtual channels */
-		if (cmd->lun) {
+		if (cmd->device->lun) {
 			cmd->result = (DID_BAD_TARGET << 16);
 			cmd->scsi_done(cmd);
 			return NULL;
@@ -1075,7 +1072,7 @@

 	}
 	else {
-		if( cmd->lun > 7) {
+		if( cmd->device->lun > 7) {
 			/*
 			 * Do not support lun >7 for physically accessed
 			 * devices
@@ -1138,15 +1135,15 @@
 		case READ_CAPACITY:
 		case INQUIRY:

-			if(!(adapter->flag & (1L << cmd->channel))) {
+			if(!(adapter->flag & (1L << cmd->device->channel))) {

 				printk(KERN_NOTICE
 					"scsi%d: scanning scsi channel %d ",
 						adapter->host->host_no,
-						cmd->channel);
+						cmd->device->channel);
 				printk("for logical drives.\n");

-				adapter->flag |= (1L << cmd->channel);
+				adapter->flag |= (1L << cmd->device->channel);
 			}

 			/* Allocate a SCB and initialize passthru */
@@ -1448,7 +1445,7 @@
 		(channel << 4) | target : target;

 	pthru->cdblen = cmd->cmd_len;
-	pthru->logdrv = cmd->lun;
+	pthru->logdrv = cmd->device->lun;

 	memcpy(pthru->cdb, cmd->cmnd, cmd->cmd_len);

@@ -1459,15 +1456,15 @@
 	switch (cmd->cmnd[0]) {
 	case INQUIRY:
 	case READ_CAPACITY:
-		if(!(adapter->flag & (1L << cmd->channel))) {
+		if(!(adapter->flag & (1L << cmd->device->channel))) {

 			printk(KERN_NOTICE
 				"scsi%d: scanning scsi channel %d [P%d] ",
 					adapter->host->host_no,
-					cmd->channel, channel);
+					cmd->device->channel, channel);
 			printk("for physical devices.\n");

-			adapter->flag |= (1L << cmd->channel);
+			adapter->flag |= (1L << cmd->device->channel);
 		}
 		/* Fall through */
 	default:
@@ -1511,7 +1508,7 @@
 		(channel << 4) | target : target;

 	epthru->cdblen = cmd->cmd_len;
-	epthru->logdrv = cmd->lun;
+	epthru->logdrv = cmd->device->lun;

 	memcpy(epthru->cdb, cmd->cmnd, cmd->cmd_len);

@@ -1521,15 +1518,15 @@
 	switch(cmd->cmnd[0]) {
 	case INQUIRY:
 	case READ_CAPACITY:
-		if(!(adapter->flag & (1L << cmd->channel))) {
+		if(!(adapter->flag & (1L << cmd->device->channel))) {

 			printk(KERN_NOTICE
 				"scsi%d: scanning scsi channel %d [P%d] ",
 					adapter->host->host_no,
-					cmd->channel, channel);
+					cmd->device->channel, channel);
 			printk("for physical devices.\n");

-			adapter->flag |= (1L << cmd->channel);
+			adapter->flag |= (1L << cmd->device->channel);
 		}
 		/* Fall through */
 	default:
@@ -1791,7 +1788,7 @@
  * Find out if our device is interrupting. If yes, acknowledge the interrupt
  * and service the completed commands.
  */
-static void
+static irqreturn_t
 megaraid_isr_iomapped(int irq, void *devp, struct pt_regs *regs)
 {
 	adapter_t	*adapter = devp;
@@ -1809,7 +1806,7 @@

 	spin_unlock_irqrestore(adapter->host_lock, flags);

-	return;
+	return IRQ_RETVAL(1);
 }


@@ -1885,7 +1882,7 @@
  * Find out if our device is interrupting. If yes, acknowledge the interrupt
  * and service the completed commands.
  */
-static void
+static irqreturn_t
 megaraid_isr_memmapped(int irq, void *devp, struct pt_regs *regs)
 {
 	adapter_t	*adapter = devp;
@@ -1903,7 +1900,7 @@

 	spin_unlock_irqrestore(adapter->host_lock, flags);

-	return;
+	return IRQ_RETVAL(1);
 }


@@ -1993,6 +1990,7 @@
 	mbox_t	*mbox = NULL;
 	u8	c;
 	scb_t	*scb;
+	int	islogical;
 	int	cmdid;
 	int	i;

@@ -2074,9 +2072,9 @@
 #if MEGA_HAVE_STATS
 			{

-			int	islogical = adapter->logdrv_chan[cmd->channel];
 			int	logdrv = mbox->logdrv;

+			islogical = adapter->logdrv_chan[cmd->device->channel];
 			/*
 			 * Maintain an error counter for the logical drive.
 			 * Some application like SNMP agent need such
@@ -2112,23 +2110,31 @@
 		 * hard disk and not logical, request should return failure! -
 		 * PJ
 		 */
-		if(cmd->cmnd[0] == INQUIRY) {
-			int islogical = adapter->logdrv_chan[cmd->channel];
+		islogical = adapter->logdrv_chan[cmd->device->channel];
+		if( cmd->cmnd[0] == INQUIRY && !islogical ) {

-			if(!islogical) {
-				if( cmd->use_sg ) {
-					sgl = (struct scatterlist *)
-						cmd->request_buffer;
-					c = *(u8 *)sgl[0].address;
+			if( cmd->use_sg ) {
+				sgl = (struct scatterlist *)
+					cmd->request_buffer;
+
+				if( sgl->page ) {
+					c = *(unsigned char *)
+					page_address((&sgl[0])->page) +
+					(&sgl[0])->offset;
 				}
 				else {
-					c = *(u8 *)cmd->request_buffer;
+					printk(KERN_WARNING
+						"megaraid: invalid sg.\n");
+					c = 0;
 				}
+			}
+			else {
+				c = *(u8 *)cmd->request_buffer;
+			}

-				if(IS_RAID_CH(adapter, cmd->channel) &&
-						((c & 0x1F ) == TYPE_DISK)) {
-					status = 0xF0;
-				}
+			if(IS_RAID_CH(adapter, cmd->device->channel) &&
+					((c & 0x1F ) == TYPE_DISK)) {
+				status = 0xF0;
 			}
 		}

@@ -2245,12 +2251,11 @@
 		break;

 	case MEGA_BULK_DATA:
-		pci_unmap_page(adapter->host->pci_dev, scb->dma_h_bulkdata,
+		pci_unmap_page(adapter->dev, scb->dma_h_bulkdata,
 			scb->cmd->request_bufflen, scb->dma_direction);

 		if( scb->dma_direction == PCI_DMA_FROMDEVICE ) {
-			pci_dma_sync_single(adapter->host->pci_dev,
-					scb->dma_h_bulkdata,
+			pci_dma_sync_single(adapter->dev, scb->dma_h_bulkdata,
 					scb->cmd->request_bufflen,
 					PCI_DMA_FROMDEVICE);
 		}
@@ -2258,12 +2263,11 @@
 		break;

 	case MEGA_SGLIST:
-		pci_unmap_sg(adapter->host->pci_dev, scb->cmd->request_buffer,
+		pci_unmap_sg(adapter->dev, scb->cmd->request_buffer,
 			scb->cmd->use_sg, scb->dma_direction);

 		if( scb->dma_direction == PCI_DMA_FROMDEVICE ) {
-			pci_dma_sync_sg(adapter->host->pci_dev,
-					scb->cmd->request_buffer,
+			pci_dma_sync_sg(adapter->dev, scb->cmd->request_buffer,
 					scb->cmd->use_sg, PCI_DMA_FROMDEVICE);
 		}

@@ -2334,8 +2338,7 @@

 		offset = ((unsigned long)cmd->request_buffer & ~PAGE_MASK);

-		scb->dma_h_bulkdata = pci_map_page(adapter->host->pci_dev,
-						  page, offset,
+		scb->dma_h_bulkdata = pci_map_page(adapter->dev, page, offset,
 						  cmd->request_bufflen,
 						  scb->dma_direction);
 		scb->dma_type = MEGA_BULK_DATA;
@@ -2357,8 +2360,7 @@
 		}

 		if( scb->dma_direction == PCI_DMA_TODEVICE ) {
-			pci_dma_sync_single(adapter->host->pci_dev,
-					scb->dma_h_bulkdata,
+			pci_dma_sync_single(adapter->dev, scb->dma_h_bulkdata,
 					cmd->request_bufflen,
 					PCI_DMA_TODEVICE);
 		}
@@ -2373,7 +2375,7 @@
 	 *
 	 * The number of sg elements returned must not exceed our limit
 	 */
-	sgcnt = pci_map_sg(adapter->host->pci_dev, sgl, cmd->use_sg,
+	sgcnt = pci_map_sg(adapter->dev, sgl, cmd->use_sg,
 			scb->dma_direction);

 	scb->dma_type = MEGA_SGLIST;
@@ -2402,7 +2404,7 @@
 	*len = (u32)cmd->request_bufflen;

 	if( scb->dma_direction == PCI_DMA_TODEVICE ) {
-		pci_dma_sync_sg(adapter->host->pci_dev, sgl, cmd->use_sg,
+		pci_dma_sync_sg(adapter->dev, sgl, cmd->use_sg,
 				PCI_DMA_TODEVICE);
 	}

@@ -2633,19 +2635,6 @@
 	return buffer;
 }

-/* shouldn't be used, but included for completeness */
-static int
-megaraid_command (Scsi_Cmnd *cmd)
-{
-	printk(KERN_WARNING
-	"megaraid critcal error: synchronous interface is not implemented.\n");
-
-	cmd->result = (DID_ERROR << 16);
-	cmd->scsi_done(cmd);
-
-	return 1;
-}
-

 /**
  * megaraid_abort - abort the scsi command
@@ -2663,13 +2652,13 @@
 	long			iter;
 	int			rval = SUCCESS;

-	adapter = (adapter_t *)scp->host->hostdata;
+	adapter = (adapter_t *)scp->device->host->hostdata;

 	ASSERT( spin_is_locked(adapter->host_lock) );

 	printk("megaraid: aborting-%ld cmd=%x <c=%d t=%d l=%d>\n",
-		scp->serial_number, scp->cmnd[0], scp->channel, scp->target,
-		scp->lun);
+		scp->serial_number, scp->cmnd[0], scp->device->channel, scp->device->id,
+		scp->device->lun);


 	list_for_each_safe( pos, next, &adapter->pending_list ) {
@@ -2752,20 +2741,20 @@


 static int
-megaraid_reset(Scsi_Cmnd *cmd)
+megaraid_reset(Scsi_Cmnd *scp)
 {
 	adapter_t	*adapter;
 	megacmd_t	mc;
 	long		iter;
 	int		rval = SUCCESS;

-	adapter = (adapter_t *)cmd->host->hostdata;
+	adapter = (adapter_t *)scp->device->host->hostdata;

 	ASSERT( spin_is_locked(adapter->host_lock) );

 	printk("megaraid: reset-%ld cmd=%x <c=%d t=%d l=%d>\n",
-		cmd->serial_number, cmd->cmnd[0], cmd->channel, cmd->target,
-		cmd->lun);
+		scp->serial_number, scp->cmnd[0], scp->device->channel, scp->device->id,
+		scp->device->lun);


 #if MEGA_HAVE_CLUSTERING
@@ -3866,44 +3855,40 @@
 #endif


+
 /**
  * megaraid_biosparam()
- * @disk
- * @dev
- * @geom
  *
  * Return the disk geometry for a particular disk
- * Input:
- *	Disk *disk - Disk geometry
- *	kdev_t dev - Device node
- *	int *geom  - Returns geometry fields
- *		geom[0] = heads
- *		geom[1] = sectors
- *		geom[2] = cylinders
  */
 static int
-megaraid_biosparam(Disk *disk, kdev_t dev, int *geom)
+megaraid_biosparam(struct scsi_device *sdev, struct block_device *bdev,
+		    sector_t capacity, int geom[])
 {
-	int heads, sectors, cylinders;
-	adapter_t *adapter;
+	adapter_t	*adapter;
+	unsigned char	*bh;
+	int	heads;
+	int	sectors;
+	int	cylinders;
+	int	rval;

 	/* Get pointer to host config structure */
-	adapter = (adapter_t *)disk->device->host->hostdata;
+	adapter = (adapter_t *)sdev->host->hostdata;

-	if (IS_RAID_CH(adapter, disk->device->channel)) {
+	if (IS_RAID_CH(adapter, sdev->channel)) {
 			/* Default heads (64) & sectors (32) */
 			heads = 64;
 			sectors = 32;
-			cylinders = disk->capacity / (heads * sectors);
+			cylinders = (ulong)capacity / (heads * sectors);

 			/*
 			 * Handle extended translation size for logical drives
 			 * > 1Gb
 			 */
-			if (disk->capacity >= 0x200000) {
+			if ((ulong)capacity >= 0x200000) {
 				heads = 255;
 				sectors = 63;
-				cylinders = disk->capacity / (heads * sectors);
+				cylinders = (ulong)capacity / (heads * sectors);
 			}

 			/* return result */
@@ -3912,23 +3897,30 @@
 			geom[2] = cylinders;
 	}
 	else {
-		if( !mega_partsize(disk, dev, geom) )
-			return 0;
+		bh = scsi_bios_ptable(bdev);

-		printk(KERN_WARNING
+		if( bh ) {
+			rval = scsi_partsize(bh, capacity,
+					    &geom[2], &geom[0], &geom[1]);
+			kfree(bh);
+			if( rval != -1 )
+				return rval;
+		}
+
+		printk(KERN_INFO
 		"megaraid: invalid partition on this disk on channel %d\n",
-				disk->device->channel);
+				sdev->channel);

 		/* Default heads (64) & sectors (32) */
 		heads = 64;
 		sectors = 32;
-		cylinders = disk->capacity / (heads * sectors);
+		cylinders = (ulong)capacity / (heads * sectors);

 		/* Handle extended translation size for logical drives > 1Gb */
-		if (disk->capacity >= 0x200000) {
+		if ((ulong)capacity >= 0x200000) {
 			heads = 255;
 			sectors = 63;
-			cylinders = disk->capacity / (heads * sectors);
+			cylinders = (ulong)capacity / (heads * sectors);
 		}

 		/* return result */
@@ -3940,78 +3932,6 @@
 	return 0;
 }

-/*
- * mega_partsize()
- * @disk
- * @geom
- *
- * Purpose : to determine the BIOS mapping used to create the partition
- *	table, storing the results (cyls, hds, and secs) in geom
- *
- * Note:	Code is picked from scsicam.h
- *
- * Returns : -1 on failure, 0 on success.
- */
-static int
-mega_partsize(Disk *disk, kdev_t dev, int *geom)
-{
-	struct buffer_head *bh;
-	struct partition *p, *largest = NULL;
-	int i, largest_cyl;
-	int heads, cyls, sectors;
-	int capacity = disk->capacity;
-
-	int ma = MAJOR(dev);
-	int mi = (MINOR(dev) & ~0xf);
-
-	int block = 1024;
-
-	if (blksize_size[ma])
-		block = blksize_size[ma][mi];
-
-	if (!(bh = bread(MKDEV(ma,mi), 0, block)))
-		return -1;
-
-	if (*(unsigned short *)(bh->b_data + 510) == 0xAA55 ) {
-
-		for (largest_cyl = -1,
-			p = (struct partition *)(0x1BE + bh->b_data), i = 0;
-			i < 4; ++i, ++p) {
-
-			if (!p->sys_ind) continue;
-
-			cyls = p->end_cyl + ((p->end_sector & 0xc0) << 2);
-
-			if (cyls >= largest_cyl) {
-				largest_cyl = cyls;
-				largest = p;
-			}
-		}
-	}
-
-	if (largest) {
-		heads = largest->end_head + 1;
-		sectors = largest->end_sector & 0x3f;
-
-		if (!heads || !sectors) {
-			brelse(bh);
-			return -1;
-		}
-
-		cyls = capacity/(heads * sectors);
-
-		geom[0] = heads;
-		geom[1] = sectors;
-		geom[2] = cyls;
-
-		brelse(bh);
-		return 0;
-	}
-
-	brelse(bh);
-	return -1;
-}
-

 /**
  * megaraid_reboot_notify()
@@ -4181,7 +4101,6 @@
 	 */
 	if( !capable(CAP_SYS_ADMIN) ) return -EACCES;

-	MOD_INC_USE_COUNT;
 	return 0;
 }

@@ -4770,7 +4689,6 @@
 static int
 megadev_close (struct inode *inode, struct file *filep)
 {
-	MOD_DEC_USE_COUNT;
 	return 0;
 }

@@ -5184,7 +5102,7 @@
 	int		tgt;
 	int		ldrv_num;

-	tgt = cmd->target;
+	tgt = cmd->device->id;

 	if ( tgt > adapter->this_id )
 		tgt--;	/* we do not get inquires for initiator id */
@@ -5228,185 +5146,6 @@
 	return ldrv_num;
 }

-
-/**
- * mega_reorder_hosts()
- *
- * Hack: reorder the scsi hosts in mid-layer so that the controller with the
- * boot device on it appears first in the list.
- */
-static void
-mega_reorder_hosts(void)
-{
-	struct Scsi_Host *shpnt;
-	struct Scsi_Host *shone;
-	struct Scsi_Host *shtwo;
-	adapter_t *boot_host;
-	int i;
-
-	/*
-	 * Find the (first) host which has it's BIOS enabled
-	 */
-	boot_host = NULL;
-	for (i = 0; i < MAX_CONTROLLERS; i++) {
-		if (mega_hbas[i].is_bios_enabled) {
-			boot_host = mega_hbas[i].hostdata_addr;
-			break;
-		}
-	}
-
-	if (!boot_host) {
-		printk(KERN_NOTICE "megaraid: no BIOS enabled.\n");
-		return;
-	}
-
-	/*
-	 * Traverse through the list of SCSI hosts for our HBA locations
-	 */
-	shone = shtwo = NULL;
-	for (shpnt = scsi_hostlist; shpnt; shpnt = shpnt->next) {
-		/* Is it one of ours? */
-		for (i = 0; i < MAX_CONTROLLERS; i++) {
-			if ((adapter_t *) shpnt->hostdata ==
-				mega_hbas[i].hostdata_addr) {
-				/* Does this one has BIOS enabled */
-				if (mega_hbas[i].hostdata_addr == boot_host) {
-
-					/* Are we first */
-					if (!shtwo)	/* Yes! */
-						return;
-					else	/* :-( */
-						shone = shpnt;
-				} else {
-					if (!shtwo) {
-						/* were we here before? xchng
-						 * first */
-						shtwo = shpnt;
-					}
-				}
-				break;
-			}
-		}
-		/*
-		 * Have we got the boot host and one which does not have the
-		 * bios enabled.
-		 */
-		if (shone && shtwo)
-			break;
-	}
-	if (shone && shtwo) {
-		mega_swap_hosts (shone, shtwo);
-	}
-
-	return;
-}
-
-
-static void
-mega_swap_hosts (struct Scsi_Host *shone, struct Scsi_Host *shtwo)
-{
-	struct Scsi_Host *prevtoshtwo;
-	struct Scsi_Host *prevtoshone;
-	struct Scsi_Host *save = NULL;
-
-	/* Are these two nodes adjacent */
-	if (shtwo->next == shone) {
-
-		if (shtwo == scsi_hostlist && !shone->next) {
-
-			/* just two nodes */
-			scsi_hostlist = shone;
-			shone->next = shtwo;
-			shtwo->next = NULL;
-		} else if (shtwo == scsi_hostlist) {
-			/* first two nodes of the list */
-
-			scsi_hostlist = shone;
-			shtwo->next = shone->next;
-			scsi_hostlist->next = shtwo;
-		} else if (!shone->next) {
-			/* last two nodes of the list */
-
-			prevtoshtwo = scsi_hostlist;
-
-			while (prevtoshtwo->next != shtwo)
-				prevtoshtwo = prevtoshtwo->next;
-
-			prevtoshtwo->next = shone;
-			shone->next = shtwo;
-			shtwo->next = NULL;
-		} else {
-			prevtoshtwo = scsi_hostlist;
-
-			while (prevtoshtwo->next != shtwo)
-				prevtoshtwo = prevtoshtwo->next;
-
-			prevtoshtwo->next = shone;
-			shtwo->next = shone->next;
-			shone->next = shtwo;
-		}
-
-	} else if (shtwo == scsi_hostlist && !shone->next) {
-		/* shtwo at head, shone at tail, not adjacent */
-
-		prevtoshone = scsi_hostlist;
-
-		while (prevtoshone->next != shone)
-			prevtoshone = prevtoshone->next;
-
-		scsi_hostlist = shone;
-		shone->next = shtwo->next;
-		prevtoshone->next = shtwo;
-		shtwo->next = NULL;
-	} else if (shtwo == scsi_hostlist && shone->next) {
-		/* shtwo at head, shone is not at tail */
-
-		prevtoshone = scsi_hostlist;
-		while (prevtoshone->next != shone)
-			prevtoshone = prevtoshone->next;
-
-		scsi_hostlist = shone;
-		prevtoshone->next = shtwo;
-		save = shtwo->next;
-		shtwo->next = shone->next;
-		shone->next = save;
-	} else if (!shone->next) {
-		/* shtwo not at head, shone at tail */
-
-		prevtoshtwo = scsi_hostlist;
-		prevtoshone = scsi_hostlist;
-
-		while (prevtoshtwo->next != shtwo)
-			prevtoshtwo = prevtoshtwo->next;
-		while (prevtoshone->next != shone)
-			prevtoshone = prevtoshone->next;
-
-		prevtoshtwo->next = shone;
-		shone->next = shtwo->next;
-		prevtoshone->next = shtwo;
-		shtwo->next = NULL;
-
-	} else {
-		prevtoshtwo = scsi_hostlist;
-		prevtoshone = scsi_hostlist;
-		save = NULL;
-
-		while (prevtoshtwo->next != shtwo)
-			prevtoshtwo = prevtoshtwo->next;
-		while (prevtoshone->next != shone)
-			prevtoshone = prevtoshone->next;
-
-		prevtoshtwo->next = shone;
-		save = shone->next;
-		shone->next = shtwo->next;
-		prevtoshone->next = shtwo;
-		shtwo->next = save;
-	}
-	return;
-}
-
-
-
 #ifdef CONFIG_PROC_FS
 /**
  * mega_adapinq()
@@ -5554,6 +5293,7 @@
 		mega_passthru *pthru )
 {
 	Scsi_Cmnd	*scmd;
+	struct	scsi_device *sdev;
 	unsigned long	flags = 0;
 	scb_t	*scb;
 	int	rval;
@@ -5571,7 +5311,11 @@
 	scmd = &adapter->int_scmd;
 	memset(scmd, 0, sizeof(Scsi_Cmnd));

-	scmd->host = adapter->host;
+	sdev = kmalloc(sizeof(struct scsi_device), GFP_KERNEL);
+	memset(sdev, 0, sizeof(struct scsi_device));
+	scmd->device = sdev;
+
+	scmd->device->host = adapter->host;
 	scmd->buffer = (void *)scb;
 	scmd->cmnd[0] = MEGA_INTERNAL_CMD;

@@ -5615,6 +5359,7 @@

 	rval = scmd->result;
 	mc->status = scmd->result;
+	kfree(sdev);

 	/*
 	 * Print a debug message for all failed commands. Applications can use
@@ -5642,7 +5387,7 @@
 {
 	adapter_t	*adapter;

-	adapter = (adapter_t *)scmd->host->hostdata;
+	adapter = (adapter_t *)scmd->device->host->hostdata;

 	scmd->state = 1; /* thread waiting for its command to complete */

diff -ruN megaraid-v2.00.9/megaraid.h megaraid-v2.00.9-linux2.6/megaraid.h
--- megaraid-v2.00.9/megaraid.h	2003-09-05 12:45:15.000000000 -0400
+++ megaraid-v2.00.9-linux2.6/megaraid.h	2003-12-30 16:16:07.743244000 -0500
@@ -129,7 +129,6 @@
 	.detect =			megaraid_detect,	\
 	.release =			megaraid_release,	\
 	.info =				megaraid_info,		\
-	.command =			megaraid_command,	\
 	.queuecommand =			megaraid_queue,		\
 	.bios_param =			megaraid_biosparam,	\
 	.max_sectors =			MAX_SECTORS_PER_IO,	\
@@ -140,12 +139,10 @@
 	.present =  			0,			\
 	.unchecked_isa_dma =		0,			\
 	.use_clustering =		ENABLE_CLUSTERING,	\
-	.use_new_eh_code =		1,			\
 	.eh_abort_handler =		megaraid_abort,		\
 	.eh_device_reset_handler =	megaraid_reset,		\
 	.eh_bus_reset_handler =		megaraid_reset,		\
 	.eh_host_reset_handler =	megaraid_reset,		\
-	.highmem_io =			1			\
 }


@@ -1103,19 +1100,18 @@
 static inline void mega_runpendq(adapter_t *);
 static int issue_scb_block(adapter_t *, u_char *);

-static void megaraid_isr_memmapped(int, void *, struct pt_regs *);
+static irqreturn_t megaraid_isr_memmapped(int, void *, struct pt_regs *);
 static inline void megaraid_memmbox_ack_sequence(adapter_t *);
-static void megaraid_isr_iomapped(int, void *, struct pt_regs *);
+static irqreturn_t megaraid_isr_iomapped(int, void *, struct pt_regs *);
 static inline void megaraid_iombox_ack_sequence(adapter_t *);

 static void mega_free_scb(adapter_t *, scb_t *);

 static int megaraid_release (struct Scsi_Host *);
-static int megaraid_command (Scsi_Cmnd *);
 static int megaraid_abort(Scsi_Cmnd *);
 static int megaraid_reset(Scsi_Cmnd *);
-static int megaraid_biosparam (Disk *, kdev_t, int *);
-
+static int megaraid_biosparam(struct scsi_device *, struct block_device *,
+              sector_t, int []);
 static int mega_build_sglist (adapter_t *adapter, scb_t *scb,
 			      u32 *buffer, u32 *length);
 static inline int mega_busywait_mbox (adapter_t *);
@@ -1137,8 +1133,6 @@
 static int mega_init_scb (adapter_t *);

 static int mega_is_bios_enabled (adapter_t *);
-static void mega_reorder_hosts (void);
-static void mega_swap_hosts (struct Scsi_Host *, struct Scsi_Host *);

 #ifdef CONFIG_PROC_FS
 static void mega_create_proc_entry(int, struct proc_dir_entry *);
@@ -1171,7 +1165,6 @@
 static mega_ext_passthru* mega_prepare_extpassthru(adapter_t *,
 		scb_t *, Scsi_Cmnd *, int, int);
 static void mega_enum_raid_scsi(adapter_t *);
-static int mega_partsize(Disk *, kdev_t, int *);
 static void mega_get_boot_drv(adapter_t *);
 static inline int mega_get_ldrv_num(adapter_t *, Scsi_Cmnd *, int);
 static int mega_support_random_del(adapter_t *);

Re: [PATCH 2.6.0] megaraid 64bit fix/cleanup (AMD64)

[Matt Domsch]

>    There is a 2.00.9 in 2.4.  In theory you should really be asking on
> linux-megaraid-devel@dell.com.

linux-megaraid-devel@dell.com is closed and gone now (only archives
remain).  megaraid driver issues should be discussed on
linux-scsi@vger.kernel.org now.  Atul had ported 2.00.6 or so to 2.6
already and posted it to linux-scsi for comment, before the hard
freeze hit; James may have newer code pending somewhere.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com