On Sat, 29 Jun 1996, David Mosberger-Tang wrote:
> Well, for those of you who don't want to switch to a whole new driver
What about this "whole new driver"? Are you speeking about a 3rd one?
The original BSD driver and the Drew's driver are the same age.
The current version of the BSD ncr driver for linux is very closed to the
original one. Obviously, I have added some new code in order to take
advantage of Linux and fixed some bugs (and perhaps added some bugs too).
Scsi drivers, especially for ncr scsi controller, are very hard to write
and to test.
The FreeBSD ncr driver has been ported to NetBSD and Linux and IMHO can be
adapted to other UNIX systems.
As we share xfree86 drivers (S3,Mach64,etc..) among (free or not) unix systems,
we should be able to share scsi drivers.
IMHO, The only reason that may explain this situation is that free OSes must
ensure support of POSIX, SYSV and/or BSD system services or emulations in order i
to have some chance to be ever used. So, a xfree86 driver just need to map some
IO space and physical memory (mmio, frame buffer) with system specific code
and just run in user space.
It is more easy to make them portable. No need to reinvent the wheel or to
confront dynausors for that stuff.
I would be very interested in the actual percentage of systems running a
free UNIX and using a ncr53c8xx scsi controller.
Dec Alpha hardware is a special case.
> because of the ncr810 DISCONNECT bug, here is something to try: just
> delete the following lines in linux/arch/alpha/kernel/irq.c:device_interrupt:
>
> if (action) {
> /* quick interrupts get executed with no extra overhead */
> if (action->flags & SA_INTERRUPT) {
> while (action) {
> action->handler(irq, action->dev_id, regs);
> action = action->next;
> }
> ack_irq(ack);
> return;
> }
> }
Removing some code is a very nice way for debugging.
Note that I just looked into the source code and I think that I've guessed
something. IMHO, some other drivers will be happy of this change too.
You can note the following too:
We are currently using fast scsi-2 data transfer at up to 10 MB/sec with
singled ended devices. IMMHO that is not recommended but I do it.
However, I have checked that scsi parity checking is enabled for my hard disks
and that the controller and the driver I use check scsi parity.
Are pci scsi controllers from Buslogic and Adaptec supported under
Linux/Alpha? (My question is perhaps silly since I just begin with Alpha systems
and, at the moment, I donnot have access to Linux/Alpha boxes)
> I have tried this on a Cabriolet with disconnect enabled and have not
> been able to crash the machine anymore. Not proof positive, but it
> looks good. Could other people try this and let me know whether it
> works? In particular hearing from people with SCSI tape drives would
> be interesting.
> Linus found this bug while we were discussing how to best fix a bug in
> _another_ driver (qlogicisp1020). Turns out that both the Alpha
> version and the x86 version had seemingly sane interpretation of what
> the SA_INTERRUPT flag meant. Problem is: the two interpretations were
> different! Overall, this had the effect of leading to race conditions
> in certain drivers (notably the qlogicisp). Now that everything is in
> sync, it works much better. It also means that for the Alpha, the
> setting of SA_INTERRUPT has no effect whatsoever.
> --david
Gerard.