chip-dependant code this required the following changes:
- Instead of attaching the device in a generic way with some chip-dependant
routines, use a chip-dependant attach routine with some common code
factored out. The code is marginally bigger, but this allows the CMD64x
flag hack to go away.
- For chips that report per-channel 'irq triggered', test this before calling
wdcintr() for the native-pci irq case (compat intr can't be shared),
as wdcintr() has no good way to know if a irq was for it or not, and
ends up with irq loss. XXX for chips that don't have this feature irq sharing
will not work properly !
- add my copyrigth notice (could have been done some time ago I think :)
There are still some issues to be solved with the Promise controller and
ATAPI devices.
Many thanks to Paul Newhouse for shipping me 2 Ultra/33 boards for doing this
work.
now uses the DMACSR_READ bit and no longer keeps _nd_dmadir in softc
unified transfer cleanup code, now in routine next_dma_finish_xfer()
fixed bounds checking on registers after transfer.
removed checking for bus errors since the bit is always set on some nexts
(specifically, on mourning, a 25mhz 68040 mono slab)
fixed a couple of dma bugs involving chaining dma buffers.
a malloc'ed pointer and it tries to realloc(3) it if it had to grow it
before. su(1) gave it a pointer from the stack which caused realloc to
core dump.
since a few things don't yet work properly:
- Sense data isn't reported properly (err, at all).
- It doesn't work with anything other than the Iomega USB Zip drive.
- Hot-unplug doesn't work yet.
...but this is enough to make my shiny new USB Zip drive go.
detect a little earlier if we've dup-put'd. Otherwise, underflow occurs,
and subsequent allocations simply hang or fail (it thinks the hardlimit
has been reached).
DMACSR_READ is now a CSR status bit which can be used to know if current transfer is
from cpu to device.
the old DMACSR_READ bit is renamed DMACSR_SETREAD. This is a control bit that tells
the dma transfer to be from cpu to device.
Stops a denial of service attack where the user can put a named pipe or
any other device that blocks i/o in /var/tmp/vi.recover/recover.*
[from dynamo@ime.net]
and consider it to be like an RCC (receive copy complete). The RCC
code path has always checked for bad received packets.
- Trim the CRC length off the recived packet length; the EPIC/100 always
includes the CRC in the packet.
- Improve fatal error reporting.
bouyer