0x02000000. This error was causing the chip to always include the
ethernet CRC along with every received frame (the driver turns on
PN_NETCFG_NO_RXCRC, but it was frobbing the wrong bit).
almost works properly. Unfortunately, there is no way to flush
the rx fifo without resetting the channel, which also flushes the
tx fifo. We avoid resetting even when both fifos need to be flushed,
since resetting seems to cause the rx to lose sync if it is done
while data is arriving.
Reminded by: NIST-PCTS
Attempt to determine (at mount time if not done so already) via density code
whether a device should default to fixed mode or not. Attempts to set to
variable that fail will cause fixed to be selected.
Similarly, the '2 filemarks at EOM' quirk is now determined (or attempted to
be determined) via density code. Some as yet not entirely tested code for
coping with 2FM@EOD position is now also in place.
hardware is interrupt-driven to a fault and sending a BREAK requires
mode switching. Always running in the BREAK-capable mode as in PR 8318
would double the overhead for sending \0's.
Reminded by: PR 8318
Use the host message loop for any unknown message types instead of performing
a reject message in the sequencer. Pass reject messages to the host
message loop too which frees up a sequencer interrupt type slot.
Default to issuing a bus reset if initiator mode is enabled. It seems
that the reset scsi bus bit is not defined in the same location for
all aic78xx BIOSes, so attempting to honor this setting will have to
wait until I get more information on how to detect it.
Nuke some unused variables.
aborted prior to disabling our lun. This requires a second set of
links since we use the ones in the ccb_hdr during normal operations.
Nuke some unused variables.
and out of kernel address space (via the pass(4) and xpt(4) peripheral
drivers) to 64K (DFLTPHYS). Some controllers, like the Adaptec 1542,
don't support more than 64K transactions.
We plan on eventually having the capability of limiting this size based
on min(MAXPHYS, controller max), but since that capability isn't here yet,
limit things to the lowest common denominator.
<kvm.h> is self-sufficient again.
Moved typedefs and forward struct declarations out of __BEGIN_DECLS/
__END_DECLS.
Don't comment out the prototype for kvm_uread(). This was a 4 year
old kludge for previous breakage of self-sufficiency. The prototypwe
was broken instead.
Fixed bitrot (const poisoning) in the type of kvm_uread().
Fixed order of the declaration of kvm_uread().
Not tested on the if_sr, if_cx and if_ar drivers, but
expected to work just the same as it used to.
Any users of these drivers (or even better: donors
of hardware for them) please contact phk@freebsd.org
so we can test the next batch of changes to if_sppp.
fixes a type mismatch in the call to kvm_uread(). The bug has gone
undetected for almost 3 years because kvm_uproc()'s protoype has been
disabled for almost 4 years.
Trust sysctlbyname() to work properly if it succeeds.
Fixed style bugs in revs. 1.19 and 1.22.
reporting since this past summer. (I think Daniel O'Conner was the first.)
The problem appears to have been something like this:
- cdda2wav by default passes in a buffer that is close to the 128K MAXPHYS
limit.
- many times, the buffer is not page aligned
- vmapbuf() truncates the address, so that it is page aligned
- that causes the total size of the buffer to be greater than MAXPHYS,
which of course is a bad thing.
Here's a quote from the PR (kern/9067):
==================
In particular, note bp->b_bufsize = 0x0001f950 and bp->b_data = 0xf2219960
(which does not start on a page boundary). vunmapbuf() loops through all
the pages without any difficulty until addr reaches 0xf2239000, and then
the panic occurs. This seems to indicate that we are exceeding MAXPHYS
since we actually started from the middle of a page (the data is being
transfered to a non page aligned location).
To complete the description, note that the system call originates from
ReadCddaMMC12() (in scsi_cmds.c of cdda2wav) with a request to read 55
audio sectors of 2352 bytes (which is calculated to fall under MAXPHYS).
This in turn ends up calling scsi_send() (in scsi-bsd.c) which calls
cam_fill_csio() and cam_send_ccb(). This results in a CAMIOCOMMAND ioctl
with a ccb function code of XPT_SCSI_IO.
==================
The fix is to change the size check in cam_periph_mapmem() so that it is
like the one in minphys(). In particular, it is something like:
if ((buffer_length + (buf_ptr & PAGE_MASK)) > MAXPHYS)
buffer is too big
My fix is based on the one in the PR, but I cleaned up a fair number of
things in cam_periph_mapmem(). The checks for each buffer to be mapped
are now in a separate loop from the actual mapping operation. With the new
arrangement, we don't have to bother with unmapping any previously mapped
buffers if one of the checks fails.
Many thanks to James Liu for tracking this down. I'd appreciate it if some
vm-savvy folks would look this over. I believe this fix is correct, but I
could be wrong.
PR: kern/9067 (also, kern/8112)
Reviewed by: gibbs
Submitted by: "James T. Liu" <jtliu@phlebas.rockefeller.edu>
an unimprovement here. I thought it would be an improvement, as in libkvm,
but here we can access the strings directly.
Use sysctlbyname() instead of sysctl() and trust it to give a nonzero
address if it succeeds.
