1 Set or clear OACTIVE as transmit buffers are depleted or
replenished, respectively. Do not use 802.11 acknowledgements
as a criteria for clearing OACTIVE.
2 Let each transmit queue count down to timeout independently,
and get rid of the shared countdown (sc_tx_timer). When
we add a packet to a transmit queue, restart the queue's
countdown. Stop a transmit queue's countdown when the
queue empties.
status correctly (which we never were doing before). Add an underrun
checker for 24XX. The process of sorting this out led to a whole bunch
of endian surprises that had to be dealt with. Fix NVRAM endian issues
for the 24XX as well.
Do a little 2200 related cleanup- in particular, turn off complaints about
not finding a fast posting handle when running with RIO enabled- we are
somehow getting duplicate completions in this case. If we ignore them and
don't complain, all is well, and we actually start averaging > 2 commands
completed per interrupt.
- There's no need to set edata->units again, it was set already before.
- Remove the last ENVSYS_SVALID assignment that overrides previous
assignments (found by mhitch@).
(Part 2: drivers)
* Support for detachable sensors.
* Cleaned up the API for simplicity and efficiency.
* Ability to send capacity/critical/warning events to powerd(8).
* Adapted all the code to the new locking order.
* Compatibility with the old envsys API: the ENVSYS_GTREINFO
and ENVSYS_GTREDATA ioctl(2)s are supported.
* Added support for a 'dictionary based communication channel' between
sysmon_power(9) and powerd(8), that means there is no 32 bytes event
size restriction anymore.
* Binary compatibility with old envstat(8) and powerd(8) via COMPAT_40.
* All drivers with the n^2 gtredata bug were fixed, PR kern/36226.
Tested by:
blymn: smsc(4).
bouyer: ipmi(4), mfi(4).
kefren: ug(4).
njoly: viaenv(4), adt7463.c.
riz: owtemp(4).
xtraeme: acpiacad(4), acpibat(4), acpitz(4), aiboost(4), it(4), lm(4).
(Part 2: drivers)
* Support for detachable sensors.
* Cleaned up the API for simplicity and efficiency.
* Ability to send capacity/critical/warning events to powerd(8).
* Adapted all the code to the new locking order.
* Compatibility with the old envsys API: the ENVSYS_GTREINFO
and ENVSYS_GTREDATA ioctl(2)s are supported.
* Added support for a 'dictionary based communication channel' between
sysmon_power(9) and powerd(8), that means there is no 32 bytes event
size restriction anymore.
* Binary compatibility with old envstat(8) and powerd(8) via COMPAT_40.
* All drivers with the n^2 gtredata bug were fixed, PR kern/36226.
Tested by:
blymn: smsc(4).
bouyer: ipmi(4), mfi(4).
kefren: ug(4).
njoly: viaenv(4), adt7463.c.
riz: owtemp(4).
xtraeme: acpiacad(4), acpibat(4), acpitz(4), aiboost(4), it(4), lm(4).
less than 16 bytes) of each SCSI command block (acb), just
prepare DMA safe buffer in struct osiop_ds and copy commands
into the buffer on each transfer to save resources and
reduce small and unaligned cache flush ops.
As a side effect, sizeof struct osiop_ds (DMA safe data buffer)
is now 256 bytes (including padding) so it could be more
cacheline friendly on bus_dmamap_sync(9) ops.
Tested on Express5800/230 (arc) and EWS4800/360AD (ews4800mips),
and no visible performance difference on bonnie.
(hppa and mvme68k are untested)
* During initialization, use the right port index when setting up the
physical pointers for a port. Fixes issue with non-contigous ports.
Reviewed by Manuel.
* Allocate commands on-demand.
* Update a bunch of constants and some structures.
* Use __attribute__ ((__packed__)) instead of __packed to be consistent.
* Support more commands for devices that can apparently handle them.
* Support a "new comm. interface" present in more recent Adaptec
firmware. This reduces the amount of PCI bus traffic in handling
commands.
* Support larger commands going to the adapter--if the adapter can
support them.
* Support 64-bit commands for archs where sizeof(bus_addr_t) > 4 and
for adapters that advertise SGMAP64.
* Handle the WINDOW4G option and NO4GB quirk by excluding 2G-4G window
unless we have the WINDOW4G capability without the NO4GB quirk.
* Ask the adapter more about its capabilities and try to use those if
they seem sane.
* Do our bus_dmamap_sync() inside dequeue_fib instead of following,
since we have the information that we need there.
* Provide access functions for some adapters that I haven't seen yet
(MIPS-based "Rocket" adapters). Not yet used.
Enable a few more bits in the I/O requested by ld and check for the fast
response bit when reading back from the queue.
Both changes come from reading the FreeBSD driver and testing on a Dell
CERC SATA controller.
system has. This has the (scary-because-we've-been-running-so-long-
without-it) commit message (for the first version of the change):
Tell the controller how much physical memory we have. Without this
there was a chance that our DMA regions would collide with the
memory window used by the cache on the controller. The result would
be massive data corruption. This seemed to mainly affect systems with
>2GB of memory.
The major changes are:
+ 4Gb (24XX) card support
+ Rewritten fabric and loop evaluation code
+ New f/w sets
The 4Gb changes required major rototilling, which caused a rewrite of
fabric and loop eval code. The latter can now be set up to tune for
dynamic device arrival/departure if the framework is set up for it,
or to be firm about waiting for devices.
Testing has been principally on amd64, i386 and sparc64 and seems to
not have broken things for me.
* Include definitions of adapter-initiated fibs.
* Send aifs back to the adapter after we receive them.
* Use indexes instead of pointers in 32-bit hardware registers.
* If we get a message that there's a printf from the adapter, but we have
a NUL in the first character of the printf string, change the NUL to a
space.
My SGI issued IBM DORS-32160 will respond to every message with a sync
negotiation (even IDENTIFY) until it gets a response it likes (and it
definitely doesn't like async). Unfortunately, this locks us into an endless
loop after sending IDENTIFY, since the device responds with a SYNC
negotiation that we refuse to accept. This refusal results in a new
target-initiated sync negotiation, and so on...
To work around this, permit negotiating sync mode on an unexpected
target-initiated sync negotiation.
> - With the PCIe devices, it looks issuing a TX command while there's
> already a transmission in progress doesn't have any effect. In other
> words, if you send two packets in rapid succession, the second one may
> end up sitting in the TX DMA ring until another transmit command is
> issued later in the future. Basically, if re_txeof() sees that there
> are still descriptors outstanding, it needs to manually resume the
> TX DMA channel by issuing another TX command to make sure all
> transmissions are flushed out. (The PCI devices seem to keep the
> TX channel moving until all descriptors have been consumed. I'm not
> sure why the PCIe devices behave differently.)
* dev/ic/ug.c (main code shared by the attachments)
* dev/isa/ug_isa.c (isa attachment)
* dev/acpi/ug_acpi.c (acpi attachment)
That means that ug(4) can now be attached via ACPI.
Thanks to Mihai Chelaru for the good work.
