| Age | Commit message (Collapse) | Author |
|---|
|
The whole issue of processes and threads need looking at, as NetBSD
and OpenBSD do things slightly differently - think extra arg to
VOP_XXX calls for one.
|
|
|
|
|
|
caused by another device on the PCI bus. So we won't print them. Just ACK them and go.
|
|
|
|
an exact model number for it though...
|
|
<il11@mail.csuchico.edu>
|
|
on a combination of VIA South Bridge and old Toshiba drive.
DMA transfers of 4 bytes work for my old Mitsumi FX600 drive.
Assume Toshiba drive is in error.
Avoid situation by only invoking DMA transfers on transfers over 100 bytes.
Thanks to Tim Howe for the hardware for testing
|
|
|
|
based on netbsd driver.
testing helps from brad@
eisa untested, but should work (;
|
|
panics
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It is done inline for the CY82C693U since it only has one channel.
|
|
- actually check the returned scsi_status value and act accordingly
instead of ALWAYS returning XS_NOERROR
- always return the scsi status value in xs->status for completed
requests
- no longer reference ccb->xs and ccb->dmamap_xfer if an 'unallocated'
ccb is encountered
- immediately remove the ccb adw_isr_callback is working on from the
pending list, leaving it in limbo until it is put on the free list
just before any return
- 'freeze' a target only when a scsi_status indicating it is busy is
encountered, and 'thaw' a target whenever a bus reset is done or a
request completes
- check done_status, host_status and scsi_status in that order as is
done in the linux driver and was done here until very recently, which
seems cleaner to me. But opinions may vary. The only behaviour change
that should result is that done_status of QD_NO_STATUS no longer
causes a check of host_status values, but is an error causing a
XS_DRIVER_STUFFUP
- produce a more general error message with actual values for
host_status, scsi_status and done_status values, with references to
adw(4) for more details on the error where appropriate (man page
update coming)
- take what seems like appropriate action for all known host_status,
scsi_status and done_status values with more use of XS_RESET where
appropriate
- use adw_reset_bus() instead of AdwResetSCSIBus() in
adw_async_callback() so pending requests are requeued and devices left
unfrozen when this happens
- print an error message with the code # when adw_async_callback is
called with an unknown code.
|
|
|
|
|
|
|
|
need #if NBPFILTER > 0 around a couple of spots.
|
|
|
|
|
|
|
|
provides better (not perfect) reset sequence. The most significant
change is asserting output enable reg before power up. Stop routing
interrupt during reset.
From NetBSD.
|
|
|
|
|
|
instrumentation for interrupts, specific topology preferences for
the 2200. Fix the hole in the OpenBSD port becuause there'd been
no maxluns limit from the midlayer and have the command routine
bounce commands > the maxluns for a particular controller (in
particular, Qlogic FC cards where we can't tell when it hasn't been
us that have loaded the F/W whether or not SCCLUN is in effect
or not).
|
|
getting LIVENGOOD (newer chipset) support. There will be a bit more
coming down the pipe with this in a couple of weeks when I get the
board that does 10/100/1000 all through CAT-5 cable....
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bridges so that hot insertion and removal works; from NetBSD.
|
|
|
|
|
|
not PCI_BCR_INTR; from NetBSD.
|
|
fix for this (rev 1.7) as this is the better way to do it. This fixes the
problem seen with reboot while an xl(4) CardBus card is in a slot on my Toshiba
Tecra 550CDT (so it should fix the same problem espie@ has seen on a different
model Toshiba laptop).
|
|
modifier keys (SHIFT, CTRL, ALT, etc.), and a key "up" event is received,
only delete the key repeat timeout if the key that generated the "up"
event is the key currently being repeated. When a key "down" event is
received, the opposite -- only delete the key repeat if the key that generated
the "down" event is _not_ the key currently being repeated.
Playing here is a bit dangerous since we are constraining the conditions in
which a timeout(9) is deleted (we don't want to mistakenly get stuck in a
non-legitamite key repeat).
Using timeout(9) for this is kind of gross. I guess it is done here to avoid
key repeat code in all of the actual hardware keyboard drivers.
There is still a bug here. If you have a key held down and detach your
keyboard (by either unplugging it or doing a KVM switch), the timeout is not
deleted and the key continues to repeat until it gets the keyboard back and
receives an interrupt. Perhaps we should not be ignoring typematic keys after
all?
|
|
switching virtual terminals.
|
|
|
