macro which replace them with mem*() functions in #ifdef _KERNEL as noted
in man pages
- move declarations of bcopy(3) and bzero(3) into <lib/libsa/stand.h>
since they are still in libsa for some MD standalone sources
(I guess all bcmp(3) in standalone sources have been replaced with memcmp(3)
but they should be replaced with memcmp() anyway)
provides those declarations.
It's possible that these can be removed later when we find out whether
these functions are actually needed in the kernel, but meanwhile, this
allows alpha, hp700 and the powerpc ports (who all build these as part
of libkern) to complete their builds.
device will remain in a wait-for-more-stuff-to-be-written state delaying other
SCSI calls, esp. some read-size or read-layout calls, until its told there is
no more comming.
To fix this, on last close explicitly flush the caches releasing the device
from this mode and allowing other SCSI commands to reach it.
This fixes PR 40528
so that it can return 128KB, 256KB and 512KB properly instead of
truncated 0MB or rounded 1MB.
Problem reported by nisimura@ on port-amd64 and port-i386.
> 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.
