dev/microcode/aic7xxx_seq.h,
dev/ic/aic7xxxreg.h:
Remove intrinsic knowledge about SDTR and WDTR messages and replace it
with a generic message system that allows the kernel driver to handle
SDTR, WDTR and any other type of extended message it chooses too. This
makes the sequencer code much simpler, makes extended message handling
debuggable since the bulk of the work is in the kernel driver, and saves
lots of instruction space.
Regen microcode header file.
dev/ic/aic7xxx.c, dev/ic/aic7xxxvar.h:
Add code to handle WDTR and SDTR negotiation in light of the changes in
the message interface to the sequencer. Don't reject targets that
negotiate async by sending an SDTR with a 0 offset. Use an sdtr message
with 0,0 to negotiate async when a target suggests a period that is too
long for us to handle. Some tape and cdrom drives don't like us doing
the message reject that we did in the past.
Fix a problem with handing the QUEUE FULL condition.
Fix a race condition (most likely the cause of the SCB paging problems) that
might allow the sequencer to get unpaused before the condition that caused
it to be paused (a SEQINT) was handled.
Race condition pointed out by Doug Ledford <dledford@dialnet.net> and
by "Dan Willis" <dan@plutotech.com>.
dev/pci/ahc_pci.c:
Add support for the 2940AU, an aic7860 based controller.
dev/pci/pcidevs.h, dev/pci/pcidevs_data.h:
Add product IDs for the 2940AU, aic7860 and aic7855.
Regen data file.
scsi/scsi_message.h:
Add MSG_EXT_SDTR_LEN and MSG_EXT_WDTR_LEN - the length of bytes in these
extended messages.
Thanks to Chuck Cranor <chuck@maria.wustl.edu> for testing these changes
out for me.
multi-channel driver), or to SCSI_CHANNEL_ONLY_ONE if a
single-channel driver.
(2) use scsiprint() rather than a locally-defined autoconfig print
function, and kill any locally-defined print function.
a char *, because that's what was really intended, and because
if the print function modifies the string, various things could become
unhappy (so the string should _not_ be modified).
the lowest bit set. This isn't any more or less valid according to the PCI
spec, but it deals with lame devices that don't implement all of the top
bits.
values, i.e. 0xfffffffe and 0xffffffff respectively. The changed
definitions were incorrect, according to the PCI Local Bus Specification
(Revision 2.0). Further rationale and a workaround for the broken
devices that instigated the change provided in a message to
current-users@netbsd.org, dated Mon, 05 Aug 1996 22:06:58 -0400,
message ID 16773.839297218@ux2.sp.cs.cmu.edu>.
christos