one for tasks of the host controllers. This is needed for drivers like
ural(4) that want to do synchronous USB transfers from the task handler.
Before the split timeouts could not be handled correctly as the task
thread was still blocked. From FreeBSD.
- merge if_vgevar.h into if_vge.c since no other file refers it
- rename some macro (VGE_TX_DESC_CNT -> VGE_NTXDESC etc.) and structs
- change prefixes of structure members to represent parents
- put TX and RX descriptors into single struct vge_control_data and
allocate DMA memory at once
- no need to specify BUS_DMA_ALLOCNOW
- define appropriate macro for offsets and addresses of DMA descriptors
- define struct vge_txsoft and vge_rxsoft, and put common data for
each descriptor into them
- remove struct vge_list_data and move its members into struct vge_softc
- remove #ifdef DEVICE_POLLING code we don't support
- merge vge_[tr]x_list_init() functions into vge_init()
- use aprint_error() to print errors
- put splnet(9) where appropriate and remove unused VGE_{LOCK,UNLOCK}() macro
- clear TX timeout only if there is no pending descriptor
- check dm_nsegs properly otherwise padding short packets could fail
- prepare zero'ed DMA memory to pad short packets rather than putting
random data
- fix a wrong VGE_TXDESCSYNC() usage which should be VGE_TXFRAGSYNC()
Tested on my i386 which is my development machine.
(more bus_dmamap_sync(9) cleanup will be done later)
- Remove the PCN_NO_PROM option. Instead, query the am79c970-no-eeprom
property, and read the MAC address from the CSRs if that property is TRUE.
In the ibmnws port:
- Implement device_register().
- In device_register(), set the am79c970-no-eeprom property for the
built-in Ethernet.
the vanilla ones. They are supposed to be identical to
{GENERIC,INSTALL}, apart from the different ncr5380 driver.
Instead of re-sync'ing, use a new feature of configure and just disable
the ncrscsi driver.
(Approved by Allen Briggs)
stack.
Fixes the "booting from disk memory corruption bug" which was a result
of pmap_extract silently failing against a scsipi_xfer data area allocat-
ed on kernel stack in _bus_dmamap_load_buffer
it, not the mtime of the file itself. This fixes the problems exposed when
unpacking software under a tmpfs and trying to build it because dependencies
were not calculated properly (e.g. autoconf 2.60 as reported by tls@).
I didn't know what header to put the prototype in, so it's both in
i386/mem.c and amd64/mem.c; probably can be moved later.
Tested on amd64, assumed working on i386. :)
yamt@ okay
If we already have an entry, we only print a message mentioning it if the
fingerprints mismatch; that may indicate a security issue.
If the fingerprints match, there's a good chance it's the same file
appearing multiple times as a hard-link, in which case print a message
only if the verbose level is 1 or more.
cbiere