The commit log in FreeBSD's if_vr.c rev 1.43 says
"This is really only for the VT6102, but it doesn't hurt the older chips,"
but at least it hurts my VT86C100A (which returns a product ID of VT3043)
on macppc and causes kernel MCHK trap while the same board on i386
and VT6102 on macppc have no problem with it.
- in vr_rxeoc() (i.e. on RX error interrupts), disable RX before
calling vr_rxeof() and check it actually stopped
- no recovery is needed for VR_ISR_DROPPED, so just account ierrors
- also account ierrors in vr_rxeoc()
vge_encap() should bail out if there is not enough free
TX descriptor _OR_ TX descriptor is still owned by the chip.
Anyway, we already check if the TX descriptor already has an mbuf
to be sent in vge_start() so no need to bother to check sc_tx_free
and VGE_TDSTS_OWN in the descriptor in normal case, then make it use
KASSERT(9) or wrap with #ifdef DIAGNOSTIC.
XXX1: I don't know why original FreeBSD driver checks
if a number of free TX descriptors is more than two, not zero.
XXX2: Is it better to check a number of free descriptors in vge_start()
like other our drivers rather than mbuf chain for each descriptor?
Fix checksum error problem on sending fragmented large packets,
which was introduced in rev 1.14.
BTW, should we have m_defrag() in MI for other drivers?
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.
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.
This should make 3c575CT work and fix following PRs:
kern/12965: 3com 575CT does not work
port-i386/16295: Problems in pci routing table and ex0 (3c575c-tx) networking
- remove an empty statement in if() clause by inverting logic
- use KDASSERT(9) rather than #ifdef DEBUG + KASSERT(9)
- replace commented out M_WRITABLE() with !M_READONLY(9)
The passed size doesn't mean anything really and can only help detect
corrupted configuration files, which should be done in userland anyway.
Note it's possible to trigger a kernel panic by passing a junk
pointer in the 'fingerprint' member of the parameters, but then again
that's true for anything that copies in data from a userland-supplied
pointer. And we have plenty of those.
At the moment, Veriexec only allows the super-user to open the pseudo
device, so it's ~okay. Maybe we should address that in copy(9) or
something?
fatal.. A `long write in progress' is a retry again later command that is
issued when a device returns immediately after a write request but needs
some time before it can handle read requests.
drives are probed using the SATA way (from FreeBSD). While here add the
VT8237A SATA Controller to the tables, should fix PR kern/34927.
Thanks to the César Catrián Carreño and paul (at) whooppee.com for
tests.
tsutsui