does not trigger assertions in uvm_fault, and executing files from
coda works as well.
Code very lightly reviewed by wrstuden@; scrutiny by those who
understand vnode and especially {get,put}pages would be appreciated.
the host share them.
Before breaking out of the loop over descriptors in gem_rint(),
DMA-resynchronize the first Rx descriptor we found that does not
belong to the host. We must avoid a cached descriptor "covering"
a descriptor in RAM, because the cached descriptor may say that
the descriptor still belongs to the NIC, when that is not true,
and the driver will hang.
XXX I believe this driver only works by luck on hosts that both
XXX have a cacheline size greater than the size of a descriptor
XXX (16 bytes) and lack DMA/cache coherency. I need to add some
XXX trickery to make sure that we don't scribble over the NIC's
XXX changes to a descriptor when we flush a cached descriptor to
XXX RAM with bus_dmamap_sync(9).
break other implementations so lookup the physical number instead of
indexing it. Choosing random numbers here is legal according to the specs,
but not a logical choice and most likely done as a wierd kind of copy
protection.
Rogue implementation found to use this
*Microsoft CDIMAGE UDF
the seq used by the request. It will improve consistency with the answer of SADB_GET
request and helps some applications which relies both on seq and pid.
Reported by Karl Knutsson by pr/36119.
the "mountpoint" vnode twice due to an error branch.
thanks go to Gert Doering for reporting the problem and testing the fix
and to Juergen Hannken-Illjes for much of the analysis work leading to
the discovery of the problem cause
4 DMA memory segments, depending on how the buffer is in memory.
When receiving a packet, we allocate a new one to remplace the one we've
used. It can need more segments than the one it remplace, leading to
corrution of the RX descriptors, and a panic in bus_dmamap_sync() (DIAGNOSTIC
kernels) or possibly memory corruption.
Fix:
- bnx_get_buf() allocates as many buffer as possible, checking the number
of free RX descriptors. Because one receive buffer is not guaranteed to
be remplaced on receive, call bnx_get_buf() from bnx_tick() too.
This also improve error handling from bnx_get_buf().
- use MCLGET() instead of MEXTMALLOC() if we're running with the standard
ethernet MTU. This gives us more receive buffers and waste less memory.
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.
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.
the unlock parent, lock child, lock parent in the ISDOTDOT case.
Clean up and rewrite comments to match more closely current reality.
Sprinkle XXX where I'm not sure the current rules are being followed.
Reviewed by wrstuden@, who agreed that this is an improvement over the
current code, with concerns about LK_RETRY and whether the ISDOTDOT
locking is done soon enough.
updated path parameter is ever valid - especially when emul_find() fails.
Use the modified path for the access() calls.
Found when compiling with emul_find() hacked to always fail.
again. This is useful until locking is further developed and basically
any deadlocks can be solved by killing appropriate processes.
Thanks especially to Tommi Kyntola and Antti Louko for sitting down
with me and discussing resource ownership and locking strategies
in implementing this.
Make sure that if we pull a buffer off of the read queue that it really
is a read request. Lower in this routine we base which queue we
dequeue the request from on its read/write state. Thus if a write
op ever ended up on the read queue, we'd explode (dereference NULL).
workaround for the problem analyzed more deeply in kern/30831. In
short, the problem is keeping the vnode on the mount point vnode
list during reclaim. If reclaim happens to sleep (as is a possibility
with smbfs due to calling vrele() and therefore possibly VOP_INACTIVE),
code going through the entire mountpoint vnode list will hit
half-reclaimed vnodes.
implement volume control in software via audio filter framework.
XXX: audio filter framework doesn't let me pass parameters from the hw
softc to the filter, so the volume variables are globals for now.
are based on completely different alphabet, and typesetting with
one of modifiers pressed all the time is just a PITA). See
http://mail-index.netbsd.org/tech-kern/2007/03/29/0002.html for
usage details.
While here, perform the following small cleanups:
- KS_Cmd_Scroll* execution should be explicitly interrupted with 'break'.
- Some 'human' cleanups in ksym extraction algorithm (no func. changes).
- Add a note: implemented ksym translation isn't sufficient for l10n.
write the whole map in one shot so that we don't have to deal with the
map changing under us. Fixes the linux emulated jdk-1.6 where it was
losing the last map entry and could not find the stack on startup.
Do not set the DMMU secondary context to 0 (that would be kernel), and
add a few required membars after switching the secondary dmmu context.
This avoids SIRs caused by double kernel_data_faults, caused by spills
of obsolete user windows after the context for that user pmap is gone.
from putop. even though there's only one user currently, makes code
more readable
* move "delta" to a standard parameter in vntouser and get rid of the
specialcase vntouser_delta
- cv_wait and friends: after resuming execution, check to see if we have
been restarted as a result of cv_signal. If we have, but cannot take
the wakeup (because of eg a pending Unix signal or timeout) then try to
ensure that another LWP sees it. This is necessary because there may
be multiple waiters, and at least one should take the wakeup if possible.
Prompted by a discussion with pooka@.
- typedef struct lwp lwp_t;
- int -> bool, struct lwp -> lwp_t in a few places.
counterparts apart from not adding the new type to the link set and
hence not registering automatically at boot time. This can be used
to avoid a separate #ifdef _LKM path in some cases.
bunch of bugs.
* park structures are now always allocated from a pool instead of a
mixed stack/malloc allocation
* get rid of the whole adjbuf concept, always just alloc the maximal
amount of memory to satisfy a request
* little regression: don't allow interrupting wait from file system
to userspace; this had problems already before, but now the problems
really started to shine through. I'll try to make this work again
some day.
* fix bmap to return a sensible value in runp
As a result of this a user could supply a bad 'sockaddr' structure to
clnp_route() via connect(2).
Issue found by Christer Oberg and patch from christos@ (NetBSD-SA2007-004)
__attribute__((always_inline)) or gcc might decide not to inline them,
resulting in P2->P1 call while we mess with the cache, and kernel
would just hang immediately on boot.
platforms that don't provide these services.
In drm_mmap, don't wrap the return value with atop() if we're on macppc.
While we're here, fix:
pci_intr_establish(&dev->pa.pa_pc, ...);
to:
pci_intr_establish(dev->pa.pa_pc, ...);
The former doesn't even compile on macppc, and I'm amazed that it works at
all anywhere else.
