Today I plan to post patches to make everything in
linux-2.5.2-pre11/drivers/scsi compile, at least everything under
x86, compiled as modules. They compile, and, the only undefined
symbol in when I boot is scsi_mark_host_reset in BusLogic.c.
However, the 2.5.2-pre11 patches are completely untested.
I have already delayed a day in trying to find time to
prepare patches individually with explanations, so, in the interest
of making the changes available quickly, here is a straight diff
from linux-2.5.2-pre11/drivers/scsi to my 2.5/drivers/scsi tree,
which should be handy for any driver maintainers who are kind
enough to catch my errors before I post them separately.
A few notes about this big diff:
1. In addition to the compilation fixes, these changes
also add all(?) missing pci_device_id tables.
2. For some drivers, I needed to make some small changes
to facilitate the change from io_request_lock to host->host_lock,
mostly for interrupt handlers that may service multiple host
controllers in one call or that did not figure out which
host controller they were dealing with right away. In a
couple of cases, I removed some locks which I think are
unnecessary, in one case switching to use of atomic_t.
3. scsi_debug.c changes are incomplete in that they ifdef out
some checks that need to be ported to bio.
Linus: unless I hear otherwise from you, I plan to repost these
changes in smaller sets with clearer explanations (although you're
welcome to apply this huge patch if you want).
--
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 Fri, Jan 11 2002, Adam J. Richter wrote:
> Today I plan to post patches to make everything in
> linux-2.5.2-pre11/drivers/scsi compile, at least everything under
> x86, compiled as modules. They compile, and, the only undefined
> symbol in when I boot is scsi_mark_host_reset in BusLogic.c.
> However, the 2.5.2-pre11 patches are completely untested.
Please hang on with this for a week or so, there will be other changes
to SCSI drivers required. You'll just end up doing the work twice.
--
Jens Axboe
Jens Axboe wrote:
>On Fri, Jan 11 2002, Adam J. Richter wrote:
>
>> Today I plan to post patches to make everything in
>>linux-2.5.2-pre11/drivers/scsi compile, at least everything under
>>x86, compiled as modules. They compile, and, the only undefined
>>symbol in when I boot is scsi_mark_host_reset in BusLogic.c.
>>However, the 2.5.2-pre11 patches are completely untested.
>>
>
>Please hang on with this for a week or so, there will be other changes
>to SCSI drivers required. You'll just end up doing the work twice.
>
For the record. We have a file called: sun3_NCR5380.c inside dirvers/scis.
There appers to be code there, which is using some of the oboslted error
handling facilities.
But under a compilation switch, there is code for the new error
management as well
already there, with some notes about the midlayer having problems.
If there is nobody supporting this driver, pleas consider switching
those macros... the
oboslete stuff,won't compile anyway.
However I doubt, that sun3 is supported anyway at all... so if not, then
please
consider this driver seriously for total removal ftom the kernel soruce
tree.
Here is the actual cided code:
#if 1 /* XXX Should now be done by midlevel code, but it's broken XXX */
/* XXX see below XXX */
/* MSch: old-style reset: actually abort all command processing here */
/* After the reset, there are no more connected or disconnected commands
* and no busy units; to avoid problems with re-inserting the commands
* into the issue_queue (via scsi_done())
And later down:
#else /* 1 */
/* MSch: new-style reset handling: let the mid-level do what it can */
/* ++guenther: MID-LEVEL IS STILL BROKEN.
* Mid-level is supposed to requeue all commands that were active on the
* various low-l
Both are quite at the end of the file...
Unless you started with the 2.4.17/2.4.18pre for most of the NCR5380 based
drivers don't bother. The one in 2.5 doesn't even work in 2.2 SMP
Alan
> + if (!atomic_dec_and_test(&main_running)) {
> NCR5380_main();
This change is not required
> /* Run the coroutine if it isn't already running. */
> + spin_unlock_irq(&instance->host_lock);
> run_main();
> + spin_lock_irq(&instance->host_lock);
This hangs the machine recursively re-entering under load.
I specifically told people not to hack on the old NCR5380 driver. You've
taken a semi broken driver, destroyed it completely and risked disk corruption
for anyone who uses it.
What really annoys me is that I've already asked you specifically not to
submit patches to that driver but to take the 2.4.18pre version of the
driver and port that one forward if you must fiddle with it. Instead you've
wasted your time, and tried to make the future merge harder.
Its absolutely obvious from the changes that you have no grasp how the
locking in that driver is handled, nor what it depends upon. If you had
understood that locking you'd have realised you were hacking on a driver
version that was totally flawed.
How many other maintainers have you ignored trying to send in untested
patches to their drivers ?
Alan
Alan Cox writes:
>What really annoys me is that I've already asked you specifically not to
>submit patches to that driver but to take the 2.4.18pre version of the
>driver and port that one forward if you must fiddle with it. [...]
I imagine that would be annoying, but I think you are
misremembering. Searching my mail since January 16, 2001, for
"NCR5380" and "53C80", I do not see any note remotely like that.
I don't think I have posted a patch or said anything about the
Linux scsi drivers on linux-kernel for years.
Now that I am aware of your request regarding using the 2.4.18pre
version of the NCR driver for future maintenance of the 2.5 driver,
I am happy to follow 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."
> I imagine that would be annoying, but I think you are
> misremembering. Searching my mail since January 16, 2001, for
> "NCR5380" and "53C80", I do not see any note remotely like that.
> I don't think I have posted a patch or said anything about the
> Linux scsi drivers on linux-kernel for years.
Maybe I got the wrong person - if so I apologise.
> Now that I am aware of your request regarding using the 2.4.18pre
> version of the NCR driver for future maintenance of the 2.5 driver,
> I am happy to follow it.
I think you'll find it a lot easier to follow too. The thing to watch is
that the queue of devices to process on an IRQ is not per host but driver
global. The rest should be obvious, but watch the co-routine locking. If
you get that wrong the driver does occasionally recurse down the stack and
explode mysteriously.
Alan