- USRobotics WorldPort 14.4 modem
- Mototola Personal Messenger 100c CDPD modem
- Socket Communications PageCard
Note: Most of this should be replaced with a com-port-detecting
heuristic better than the previous two.
cascaded and that it will be unmasked when DMA is thawed after being
frozen. (This also has the effect of making sure that no device ever
erroneously gets DRQ 4.)
1) Quirk entries for Storage Tek 9490 (Timberline) and D3 (Redwood)
drives.
2) Modification to st_loadtape to do a REWIND to BOT if the
action is a load and the tape doesn't support the LOAD command
(9490, SD3, and IBM 3590).
3) Cleaned up the 'undersized user record' error message to
make a little more sense.
Various bug fixes:
kern/1275: Now returns values in dsreg and erreg and sets resid
(as best as it can for a 16 but integer). See also
a recent change to mtio.h. We are declining to fix
the portion of this bug about naming a more specific
SCSI device. Since there is nothing programmatic
you can do with that information, it is not useful
to pass back at this time.
A side effect of this change is that doing MTIOCGET
also forces a mode sense (to get the current state
of WRITE PROTECT).
kern/5647: Now no longer logs to the console ILI or Filemark or (first)
EOM (on write) errors (unless SCSIDEBUG is set).
kern/5525: Substantially increased timeouts for a variety of
operations, and split them into categories of
I/O, Space, and Control operations (each have
likely different inherent times). I/O is for
reads/writes. Control is for mode sense/select.
Space is for spacing the tape.
Until EOM handling is changed, though kern/391 is still not fixed. A side
effect of EOM handling is that you now always 'lose' (to the writing
application's view) the last write since EIO is what is returned on
EOM detection during writes. Hopefully the reader applications don't
get too bent out of shape by this.
takes to do IELEM can be proportional to the number of elements, but is
also affected by wierd things like how readable the barcodes on the
media are. There are worst case scenarios I've seen where there are
white labels on the back of tapes with pencilled in labels which is
*just* close enough to being a bar code that an Exabyte 120 would
peer at them myopically and long enough for a *really* long time to
pass in inventorying the jukebox.
I've upped the limit to be proportional to 5 minutes per element. That
is long enough that someone I'm sure will complain about "you wait
to long and should time out" for broken h/w.
As is also noted in the PR, there are a lot of other issues here. It's
really also a question as to whether to update this driver or go
with CAM's driver. This one doesn't have switching between block
descriptors and not, doesn't support volume tag setting, and so on.
Time is limited. This PR should have been closed and fixed right away,
tho.
as the Shark's CS8900 Ethernet, which want to use the DMA controller in
this mode (as opposed to single mode).
[Editor's note: committed from a Shark using a new bus_dma back-end
and a CS8900 driver converted to use the MI code :-]
-display DEC special graphics and DEC technical characters as far as
possible
-implement the font switching controls (need documentation!)
-behave well if double-width characters are requested
-simplify the state machine: store CSI command modifiers in variables
instead of dedicating own states to each of them
which contain 'standard' com- and lpt-type ports. Some of these present
as PCI simple-communications/serial or simple-communications/parallel
devices, but many do not. (Additionally, there is no document that I can
find that describes the "specific well-konwn register-level" description
of how the 'standard' devices' config space headers shold work.) Eventually,
some of the devices driven by this code should become simple pci attachments
for the 'lpt' and 'com' drivers, but that requires solid documentation.
the BAR-printing function to print a name for the register, factor out
a common register-bits function which can handle the fact that type 2
headers have a different size than is usual, and actually do something
useful with the rest of the bits in the type 2 header.
Before, the probe routine (mcd_find() would succeed even if the probe
code thought it had a response, but didn't recognize the ID-code byte.
Now, only do the promiscuous match if MCD_PROMISC is configured.
- Don't enable interrupts on attach time; we don't have to
- Don't assume that because a card has a cfe entry that matches one
of the standard com ports, is a modem; my floppy was recognized as
a modem! Require a match of the cis strings against *[Mm][Oo][Dd][Ee][Mm]*
- Print things in order so that we don't mess up the output with un-needed
newlines
- Using an array of cis identifiers to find e modem should not use the
function number; it is not reliable. For example 3c562[A-D] are different
Maybe this can go away altogether and print parts of the cis strings
to take a single character at a time, where the character is an "int" now.
The old interface (took a string) was never called with more than 1
char to print, and the "int" allows us to handle charsets cleanly.
It should be able to parse escape sequences up to VT300, but not everything
is implemented. Most notably, there is no font handling - all displayable
characters are handed to the graphics driver. To solve this, a serious
interface change to the graphics driver is needed (Unicode?).
thorpej