I'm not convinced there is anything major wrong with the patch but
them's the rules..
I am using my "David's mentor" hat to revert this as he's
offline for a while.
- remove dead code and fix warnings in pmap_zero_page/zero_page_area
- implement
pmap_clear_reference
pmap_ts_referenced
pmap_page_exists_quick
pmap_remove_all
- align pmap_qenter/qremove closer with i386 code
- fix vm_page locking in pmap_new_thread (from benno)
- add new parameter to pmap_clear_bit to return original
pte value
Approved by: benno
using the Rhine's internal shift registers which are designed
for the job. This reduces the amount of time we wait around shifting
bits, and seems to work better with some chips.
Also, provide a workaround for some newer cards which report fake PHYs
at multiple addresses. (As more cards are ID'd, I'm sure this part
of the code will have to be expanded to cover more cases.)
Submitted by: Thomas Nystrom <thn@saeab.se>
MFC after: 1 week
than having change_dir() release the vnode lock on success, hold the
lock so that we can use it later when invoking MAC checks and
VOP_ACCESS() in the chroot() code. Update the comment to reflect
this calling convention. Update callers to unlock the vnode
lock. Correct a typo regarding vnode naming in the MAC case that
crept in via the previous patch applied.
cases: we might multiply vrele() a vnode when certain classes of
failures occur. This appears to stem from earlier Giant/file
descriptor lock pushdown and restructuring.
Submitted by: maxim
under load.
This patch has been tested by Thomas and other for more than a month now,
and all (known) hangs seem to be solved.
Thomas's explanation of the patch:
* Fix the problem with the printing of the RX-error.
* Code from if_fet do better deal with the RX-recovery including a
timeout of the RX-turnoff.
* The call to vr_rxeof before vr_rxeoc have been moved to a point
where the RX-part of the chip is turned off. Otherwise there is a
window where new data could have been written to the buffer chain
before the RX-part is turned off. If this happens the chip will see
a busy rx-buffer. I have no evidence that this have occured but
god knows what the chip will do in this case!
* I have added a timeout of the TX-turnoff. I have checked and in
my 900 MHz system the flags for turnoff (both RX & TX) is seen at
the first check in the loop.
* I could see that I got the VR_ISR_DROPPED interrupt sometimes and
started to thinking about this. I then realized that no recovery is
needed for this case and therefore I only count it as an rxerror
(which was not done before).
* Finally I have changed the FIFO RX threshhold to 128 bytes. When I
did this the VR_ISR_DROPPED interrupt went away. Theory: The chip
will receive a complete frame before it tries to write it out to
memory then the RX threshold is set to store'n'forward. IF the frame
is large AND the next rx frame also is large AND the bus is busy
transfering a TX frame to the TX fifo THEN the second received
frame wont fit in the FIFO and is then dropped. By having the RX
threshold set to 128 the RX fifo is emptied faster.
MFC after: 5 days
Make passing the methods in a cdevsw structure optional.
Move "CANFREE" and "NOGIANT" flags into struct disk instead of the
cdevsw which may or may not be there.
Rename CANFREE to CANDELETE to match BIO_DELETE operation.
Add "OPEN" flag so drivers don't have to provide open/close methods
just to maintain such a flag.
Add temporary stopgap include of <sys/conf.h> to <sys/disk.h> until
the files which have them in the other order are fixed.
Add KASSERTS to make sure we don't get fed too many NULL pointers.
Clear our geom's softc pointer before we wither.
between any pair of values in range 4-96kHz. Thanks to Ken Marks for
discovering there were problems with the previous version.
o Use a non-recursive gcd routine.
interface was left in an active, but not connected, state, which resulted
in data being sent to it and the transmit queue filling up. This happened
because the driver never informed sppp that it shoulkd clean up the
connection. This fix informs sppp that it should clean things up.
The fix was actually developed and tested under -stable, so a short MFC
period seems appropriate, say 2 days.
Contributed by: Ari Suutari <ari.suutari@syncrontech.com>
