Warning: these drivers do not work yet.
ftp://ftp.yggdrasil.com/private/adam/scsi-linux-2.5.6-diff.gz
This patch allows all of the SCSI drivers that are available on
x86 to build, except for these:
o The NCR53c80-based drivers (according to Alan Cox, there
is a new driver in the 2.4.x tree, and I don't want to
add a port of that driver to this already huge patch).
o 53c7,8xx - I believe we have other scsi drivers that
cover the same hardware, so I have skipped this driver.
o dpt_i2o - I need to understand the i2o system a little more
to determine whether all of the similar looking code in
drivers/messages/i2o and dpt_i2o is redundant or necessary.
The patch adds a little code to scsi.c to allow scsi drivers
to tell the mid-level code to automatically map and unmap gather/scatter
lists. This has simplified the porting process immensely.
The patch also adds a routine for using the SCSI request
scratchpad area for accessing scsi requests in memory (primarily
for non-DMA drivers). This eliminated some code replicated in
a multiple scsi drivers and basically enabled me to the need to
add very many calls to kmap and kunmap in each driver.
There are also a few patches that juat add PCI or ISAPnP
device ID's, so that the boards will work with automatic
module loading based on device ID's.
I owe an email to Tim Sullivan who tried my BusLogic and found
that it paniced at initialization. So, these drivers probably do not
work yet. Nevertheless, I would be interested in people looking
at the patch or even trying it just to see how it fares on other
hardware. All that I know is that the code compiles and has no undefined
symbols, except for scsi_reset_host in BusLogic.c (I guess you can
comment it out for now, which is I told Tim to try).
I want to emphasize that this patch is just a snapshot of
work in progress at this point. I just finished getting the drivers
to compile and link. I am going to step away from this for a while,
perhaps until tomorrow, but I thought I should post this in case
anyone is interested.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
On Tue, Mar 12, 2002 at 12:56:21PM -0800, Adam J. Richter wrote:
> o The NCR53c80-based drivers (according to Alan Cox, there
> is a new driver in the 2.4.x tree, and I don't want to
> add a port of that driver to this already huge patch).
I believe changes to NCR53c80 were recently reverted back because
these "fixes" lead to massive data corruption. It is preferable
that the driver remains unbuildable, and therefore doesn't cause
data corruption than to be buildable and case data corruption.
Alan has always advocated taking the 2.4 driver as an important
first step in fixing it for 2.5 - this provides a sound base for the
2.5 fixes to be built upon. Not doing this just makes whoevers job
to really fix the driver harder.
Hint: kernel programming is not about getting things to build. It's
about making this work properly.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
>> o The NCR53c80-based drivers (according to Alan Cox, there
>> is a new driver in the 2.4.x tree, and I don't want to
>> add a port of that driver to this already huge patch).
>I believe changes to NCR53c80 were recently reverted back because
>these "fixes" lead to massive data corruption. It is preferable
>that the driver remains unbuildable, and therefore doesn't cause
>data corruption than to be buildable and case data corruption.
Are you talking about an event that occurred in the 2.4
tree or the 2.5 tree? Are you saying that the newer driver in
2.4 was reverted back to the older driver (i.e., the one that
is in 2.5), or are you saying that someone made some attempt
at porting the 2.5 tree's NCR53C80 driver the new DMA mapping
interface and then backed them out?
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
On Tue, Mar 12, 2002 at 03:55:36PM -0800, Adam J. Richter wrote:
> Are you talking about an event that occurred in the 2.4
> tree or the 2.5 tree? Are you saying that the newer driver in
> 2.4 was reverted back to the older driver (i.e., the one that
> is in 2.5), or are you saying that someone made some attempt
> at porting the 2.5 tree's NCR53C80 driver the new DMA mapping
> interface and then backed them out?
Someone had a go at "making 2.5 compile" without taking Alan's 2.4
changes. It went into Linus tree. It got subsequently reverted
because of the reasons I outlined in my previous mail.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
>On Tue, Mar 12, 2002 at 03:55:36PM -0800, Adam J. Richter wrote:
>> Are you talking about an event that occurred in the 2.4
>> tree or the 2.5 tree? Are you saying that the newer driver in
>> 2.4 was reverted back to the older driver (i.e., the one that
>> is in 2.5), or are you saying that someone made some attempt
>> at porting the 2.5 tree's NCR53C80 driver the new DMA mapping
>> interface and then backed them out?
>Someone had a go at "making 2.5 compile" without taking Alan's 2.4
>changes. It went into Linus tree. It got subsequently reverted
>because of the reasons I outlined in my previous mail.
Maybe you are thinking of the patches that I posted a
while ago that included an update to some locking changes for
a bunch of the scsi drivers. Alan spoke up and said that
I should not apply the NCR53C80 part of those patches because
I had made a mistake and becuase there was a newer driver in 2.4,
and provided some tips on porting the 2.4 driver. I immediately
said I would follow Alan's advice and not submit patches
based on the old NCR53C80-based drivers.
Maybe you were thinking of some other event when you
said "I believe changes to NCR53c80 were recently reverted back because
these 'fixes' lead to massive data corruption." If so, I would be
interested in hearing about it.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
On Tue, Mar 12, 2002 at 04:23:24PM -0800, Adam J. Richter wrote:
> Maybe you are thinking of the patches that I posted a
> while ago that included an update to some locking changes for
> a bunch of the scsi drivers. Alan spoke up and said that
> I should not apply the NCR53C80 part of those patches because
> I had made a mistake and becuase there was a newer driver in 2.4,
Someone else did exactly the same thing you did, and somehow
Linus picked it up that time. Anyway, its backed out now,
so its a moot point.
> Maybe you were thinking of some other event when you
> said "I believe changes to NCR53c80 were recently reverted back because
> these 'fixes' lead to massive data corruption." If so, I would be
> interested in hearing about it.
The data corruption issue was the lack of fixed locking and
assorted fixes that Alan did after the 2.4/2.5 split.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Wed, Mar 13, 2002 at 12:02:29AM +0000, Russell King wrote:
>
> Someone had a go at "making 2.5 compile" without taking Alan's 2.4
> changes. It went into Linus tree. It got subsequently reverted
> because of the reasons I outlined in my previous mail.
I pushed that revert to Linus. It was basically a cp of the driver
from the 2.4 tree to the current 2.5 one, diff and send.
At least if someone now tries to "fix" it, it won't be lacking
any of the locking fixes that Alan did for 2.4.17
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
>I pushed that revert to Linus. It was basically a cp of the driver
>from the 2.4 tree to the current 2.5 one, diff and send.
Thanks for the information. If I understand you correctly,
you are saying that Linus's current 2.5 tree (2.5.7-pre1) has the
new driver from 2.4, albeit one that does not compile.
Diffing the 2.4.18 and 2.5.6 versions of NCR53C8x.c and
fdomain.c, they look the same, aside from some io_request_lock's
replaced by scsi_host->host_lock. dtc.c appears to have a few
minor changes, which I assume are for 2.5. So, it looks like
the NCR53C80 drivers in 2.5.7-pre1 are approximately the correct
starting point for generating working NCR53C80 drivers in 2.5 (as
opposed to recopying them from 2.4). Please correct me if I am wrong.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
> Diffing the 2.4.18 and 2.5.6 versions of NCR53C8x.c and
> fdomain.c, they look the same, aside from some io_request_lock's
> replaced by scsi_host->host_lock. dtc.c appears to have a few
> minor changes, which I assume are for 2.5. So, it looks like
> the NCR53C80 drivers in 2.5.7-pre1 are approximately the correct
> starting point for generating working NCR53C80 drivers in 2.5 (as
> opposed to recopying them from 2.4). Please correct me if I am wrong.
I don't know what has been merged beyond Dave Jones tree. DaveJ should be
able to tell you. A general give away that you have the right one is that
they are formatted to the linux CodingStyle document.
Alan
> I believe changes to NCR53c80 were recently reverted back because
> these "fixes" lead to massive data corruption. It is preferable
> that the driver remains unbuildable, and therefore doesn't cause
> data corruption than to be buildable and case data corruption.
Someone "fixed" the 2.5 one by just frobbing randomly with the
io_request_lock without noticing its not always used per queue in the driver
(study the host list code - and dont think you can just clean that up by
using SHIRQ - that wont help on some non x86 stuff). I fed Dave Jones
the 2.4 stuff where the locking is fixed (tho using io_request_lock) and
actually works SMP.
Dave then I suspect fed it to Linus
>[...] A general give away that you have the right one is that
>they are formatted to the linux CodingStyle document.
>Alan
Actually, there are many indentation changes between the
NCR drivers in 2.4.18 and 2.5.6, but looking at the changes with
"diff -w" shows very few other changes, just really ancilliary
things like option parsing.
I was a little surprised to see things like procedure
declaration lines ending in "{", which I understand confuses vi
(or some vi's). Examples from g_NCR53C80.c include internal_setup,
generic_NCR5380_setup, generic_NCR53C400_setup, and many others.
I believe the code in 2.5.6 is your new NCR driver,
in spite of the formatting differences.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
> NCR drivers in 2.4.18 and 2.5.6, but looking at the changes with
> "diff -w" shows very few other changes, just really ancilliary
> things like option parsing.
That sounds like its some half step
> I was a little surprised to see things like procedure
> declaration lines ending in "{", which I understand confuses vi
My driver doesn't have lines ending in { like that
> I believe the code in 2.5.6 is your new NCR driver,
> in spite of the formatting differences.
Sounds like a weird half change - best to pick up the 2.4.18 one otherwise
it'll be a nightmare to merge future fixes into both
>> NCR drivers in 2.4.18 and 2.5.6, but looking at the changes with
>> "diff -w" shows very few other changes, just really ancilliary
>> things like option parsing.
>That sounds like its some half step
I think I may have gotten confused here. Are you only
talking about the NCR53*80* drivers (pas16, seagate, t128,
dmx3191, dtc), or the '80 and the '9x drivers (NCR53C9x.c,
blz1230, bzl2060, cyberstorm, cyberstormII, dec_esp, fastlane,
jazz_esp, mac_esp, mac_53c9x, oktago_esp, sun3x_esp), or both?
NCR5380.c in 2.4.18 and 2.5.7-pre1 are identical files,
as is NCR5380.h. If those are the only files that you were
talking about being reverted/upgraded, then my statements
about the diffs were in error, and I apologize for the confusion.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
> I think I may have gotten confused here. Are you only
> talking about the NCR53*80* drivers (pas16, seagate, t128,
> dmx3191, dtc), or the '80 and the '9x drivers (NCR53C9x.c,
5380 - I've not touch the 9x stuff - so NCR5380, g_NCR5380, t128 etc.
> NCR5380.c in 2.4.18 and 2.5.7-pre1 are identical files,
Cool