Add newer Intel / VIA i386 chipsets.
Correct one S3 chip, add one.
Mostly from Carl Shapiro <css@samsara.dialup.access.net> per PR kern/4169
and kern/4170 (identical).
correspond to the ANA numbers... certainly includes ANA-5940.
- add Efficient Nets product 0x0000. according to linux pci.h
the 0x0000 is an FPGA version of the midway card and the 0x0002
is the ASIC version.
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.
(1) remove the 'UNSUPP' keyword from the device list,
because it can't be reasonably used (becuase different
devices may be supported on different machines, for
good reason).
(2) enhance pci_devinfo so that class/subclass information
is optional (so pci_devinfo can be used by drivers that
match classes of devices, and want to look up the
devices' names easily).
(3) more known vendors and devices.