per device info taken from FreeBSD driver. Tested by snj@ on 8111C.
Should closes PR kern/40955.
Note on old 8169 chips IP hw csum must be enabled to use TCP/UDP hw csums,
but I'm not sure if these newer chips still have the same restriction.
z8530sc.c:
Check pending interrupts in a loop until all requests are handled.
The old comments said it would cause horrible latency to sun3x floppy etc,
but serial ports should have higher priority than disks anyway.
z8530tty.c:
Don't enable and disable TX interrupts on each transmit start and completion
because it could cause possible race conditions.
Instead, set ZSWR0_RESET_TXINT on each TIE interrupt to clear the request
as other kbd drivers attached at zs(4).
Tested on cobalt, macppc, news68k, sparc, and sun3.
> Fix a bug in calculation of checksum deduction:
> - To get 16 bit one's complement value from uint32_t variable,
> higher 16 bits should be ignored.
> - RFC 1624 describes methods to recalculate checksum field in headers,
> i.e. one's complement of one's complement sum that could be 0x0000,
> but we don't have to use the strategy to deduct one's complement sum
> itself which won't be zero but should be 0xffff.
- To get 16 bit one's complement value from uint32_t variable,
higher 16 bits should be ignored.
- RFC 1624 describes methods to recalculate checksum field in headers,
i.e. one's complement of one's complement sum that could be 0x0000,
but we don't have to use the strategy to deduct one's complement sum
itself which won't be zero but should be 0xffff.
Found on debugging mec(4) on sgimips O2.
There are still about 1600 left, but they have ',' or /* ... */
in the actual variable definitions - which my awk script doesn't handle.
There are also many that need () -> (void).
(The script does handle misordered arguments.)
in IP headers, so we have to deduct not only IP option headers but all
IP headers. But in TCP/UDP layer we can assume the IP header is valid
and a sum of the IP header part should be 0xffff, so we don't have to
bother to deduct it from the computed checksum.
which don't have EXT_RFA and IPCB support. From hme(4) driver and
FreeBSD's fxp(4). Tested on i82559.
XXX: Probably we should have a common function to parse RX packet headers
XXX: to handle a raw checksum value and share it among hme(4) and gem(4) etc.
because EXT_RFA for RX cksum is always available with IPCB for TX cksum
but i82558 and i82559 have only EXT_TXCB without IPCB.
Tested on the following fxp cards:
fxp0 at pci0 dev 14 function 0: Intel i82557 Ethernet, rev 2
fxp0 at pci0 dev 14 function 0: i82559 Ethernet, rev 8
fxp0 at pci0 dev 14 function 0: i82550 Ethernet, rev 12
conditional on FXPF_EXT_TXCB, so, replace all uses with that
- for the pci frontend, reestablish some flags lost the the prior
changes and simplify one of the cases
this fixes PR 40677 and may fix PR 40431.
to the device's cache anyway and so cmdh_prdbc reports a completed
transfer. If we use it to update ata_bio->bcount this has 2 conseqences:
- the automatic LBA48 workaround doesn't qick in because bcount is used
to compute the last sector of the transfer (wd(4) part of kern/40569)
- wd(4) will report a B_ERROR buffer with a b_resid of 0, which panics
a DIAGNOSTIC kernel
Fix by ignoring cmdh_prdbc if we had a write with errors, and in this case
leave ata_bio->bcount at its initial value.
While there use NOERROR instead of 0 for ata_bio->error (cosmetic).
thanks to Matthias Scheler for tests.
sense structures in icp_scr map; otherwise we'll compute an offset past the
allocated memory (and past the end of the dmap map) from the ic_ident.
To be safe use ICP_NCCB_RESERVE instead of 2; as I'm not sure why
ICP_NCCB_RESERVE is 4.
upc_submatch() whereby it made sure that the correct driver attached.
Since this didn't really belong in the submatch function anyway,
reintroduce it in the match functions for upc's children.
This allows my A5000 to find at least one of its hard disks.
ID pair. Misuse of the revision numbers was causing some of the chip
features to be disabled on some integrated Intel chips. So, move the
determination of the features into the bus frontend, where the
vendor/product ID is known. (Note: sc_rev should be removed. The
microcode patch stuff is also busted and needs to be fixed.) Also,
poll the actual flow control status in inphy, rather than making
assumptions.
contributed anonymously.
rather than using just drive 0 status. Another drive with a different
status would cause the previous status state to flip-flop and repeatedly
output state change messages.