SR601_PA_MATCH_P(), because that macro assumes the io region you are
mapping lies within the 32-bit address space addressable by the CPU,
which might not allways be the case.
always enabling them.
It's not clear if this actually caused any problems, but it seems safer
to restore to the previous state in case pmap_activate is ever called
with interrupts disabled.
Bring in fixes and improvements from OpenBSD:
revision 1.25
- Simplify the arguments to bnx_tx_encap.
- Don't copy the bd_chain head pointers into temporary objects, they are
available globally.
From scottl@FreeBSD
revision 1.26
Overhaul the transmit path:
- Eliminate the bnx_dmamap_arg structure.
- Refactor the loop that fills the buffer descriptor so that it can be done
with a single set of logic in a single loop instead of two sets of logic.
- Eliminate the need to cache and pass descriptor indexes between the start
loop and the encap function.
- Change the start loop to always check the ifnet sendq for more work.
From scottl@FreeBSD
revision 1.27
make the exit label naming scheme match the current function names, removes
a FreeBSD-ism from the original driver.
revision 1.28 -> 1.30
- Ensure that at least 16 TX descriptors are kept unused in the ring.
- Use more complete error handling for TX load problems.
From scottl@FreeBSD
revision 1.31
replace a few more instances of hand rolled code with the LIST_FOREACH macro.
revision 1.33
In bnx_start, check the used_tx_bd count rather than the descriptors
mbuf pointer to see if the transmit ring is full. The mbuf pointer
is set only in the last descriptor of a multi-descriptor packet.
By relying on the mbuf pointers of the earlier descriptors, the
driver would sometimes overwrite a descriptor belonging to a
packet that wasn't completed yet. Also, tx_chain_prod wasn't
updated inside the loop, causing the wrong descriptor to be checked
after the first iteration. The upshot of all this was the loss of
some transmitted packets at medium to high packet rates.
In bnx_tx_encap, remove a couple of old statements that shuffled
around the tx_mbuf_map pointers. These now correspond 1-to-1 with
the transmit descriptors, and they are not supposed to be changed.
Correct a couple of inaccurate comments.
From jdp@FreeBSD
revision 1.43
Allow the bnx(4) driver to make use of all of the available hardware
multicast hash slots. The bnx(4) hardware supports 8 slots instead of
4 like the bge(4) hardware.
From Mike Karels via FreeBSD
Tested by Brad, biorn@ and Johan M:son Lindman
corresponding flags.
Revert softdep_trackbufs() to its state before vn_start_write() was added.
Remove from struct mount now unneeded flags IMNT_SUSPEND* and
members mnt_writeopcountupper, mnt_writeopcountlower and mnt_leaf.
Welcome to 4.99.17
Re-enable mmap. The problem is how uvm_fault handles page faults from
coda vnodes via container files, and executing a program caused the
same problem so disabling mmap only helped cp(1).
coda_open:
rename variables to match vnode_if.src
better comments about lock/reference state of vnodes
keep lock on container file until after VOP_OPEN, which requires locked vp
remove #if 0'd code to PNBUF_PUT
coda_link:
rename variables to match vnode_if.src
error out early if vp == dvp
check return value on vn_lock, and add comment questoining the lock
clarify lock handling, but unchanged logic
remove #if 0'd code to PNBUF_PUT
coda_rmdir:
error out early if vp == dvp
remove #if 0'd code to PNBUF_PUT
coda_grab_vnode:
add comments, and in particular question undocumented VFS_VGET semantics
coda_getpages:
question calling VOP_OPEN, which requires a locked vnode, with the
vnode we got (vop_getpages does not guarantee a locked vnode)
coda_putpages:
remove inexplicable simple_unlock(&vp->v_interlock);
add printf so we notice if this is ever called
add comment explaining that the implementation will lead to trouble,
because vnode_if.src says putpages is called with v_uobj.vmobjlock
held and is supposed to unlock it
With these changes and an uncommitted change to uvm_fault not to panic
if uvm objects are not equal, coda seems stable again.
* Add a try_set_TOOLDIR function which tries to be clever about setting
TOOLDIR if possible;
* Call try_set_TOOLDIR from rebuildmake;
* Add nobomb_getmakevar, which works like raw_getmakevar except
never bombs;
* Reimplement raw_getmakevar in terms of nobomb_getmakevar;
* Add a second arg to find_in_PATH to control the result when the
program cannot be found.
device properties - all it needs is width and height in pixels, stride in
bytes, depth in bits and the framebuffer address.
Features:
- unaccelerated fb console with colours and virtual consoles
- split into console handling and bus frontend
- so far there is only a PCI bus frontend which allows to mmap BARs belonging
to the graphics controller, others should be easy to add.
TODO:
- find an opaque way to change the palette ( probably pass a function
pointer as property ) since this would need to call some firmware interface
which is pretty much always MD
- find a clean way to mmap the framebuffer, just returning the physical
address works on macppc but not on other architectures. Problem is, that
we cannot rely on the address being a bus address - on macppc it is,
but for instance on sparc64 it's not.
got a panic in uvm_fault from ffs_write. I believe this is because cp
used mmap, the container file page was not in core, and uvm_fault
objected to the container file vnode and the coda vnode not matching.
I have long been plagued by crashes on cp from coda, and this was the
first time I got and understood a backtrace.
Clean up old comments that are no longer accurate.
Document refcounting better.
Note some questionable behaviors with XXX.
Clean up PNBUF_PUT and SAVESTART. Only do this where vnodeops(9) says
we should, and do it on error also.
In symlink, vput parent and free namebuf even in error cases.
matt