recursion from the VM is handled (and the calling code that allocates
buckets knows how to deal with it), we do not want to prevent allocation
from the slab header zones (slabzone and slabrefzone) if uk_recurse is
not zero for them. The reason is that it could lead to NULL being
returned for the slab header allocations even in the M_WAITOK
case, and the caller can't handle that (this is also explained in a
comment with this commit).
The problem analysis is documented in our mailing lists:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=153445+0+archive/2004/freebsd-current/20041231.freebsd-current
(see entire thread for proper context).
Crash dump data provided by: Peter Holm <peter@holm.cc>
reject. For example:
Checking for rejected mail hosts:
48 getherbalnow.info (451... resolve)
46 absorb.com (451... resolve)
4 tgmart01.codns.com (553... exist)
3 kali.com.cn (451... resolve)
2 genie.com (451... resolve)
1 zv.qy (553... exist)
1 zd.hinet.hr (553... exist)
....
The bit in parenthesis is the reject code and the last word on the line -
enough to give the admin a better chance of seeing real problems (hopefully!).
While I'm here, remove the "<" at the start of rejects coming from "from"
addresses without a name@ part.
I had to rewrite the patch given by the submitter as this script has been
sed'ified (used to be perl) and I think the reject code is useful....
PR: 17377
Idea from: root at ns dot internet dot dk
MFC after: 7 days
This is just a workaround for a know problem with Motorola E1000
phone. Something is wrong with the configuration of L2CAP/RFCOMM
channel. Even though we set L2CAP MTU to 132 bytes (default RFCOMM
MTU 127 + 5 bytes RFCOMM frame header) and the phone accepts it,
the phone still sends oversized L2CAP packets. It appears that the
phone wants to use bigger (667 bytes) RFCOMM frames, but it does
not segment them according to the configured L2CAP MTU. The 667
bytes RFCOMM frame size corresponds to the default L2CAP MTU of
672 bytes (667 + 5 bytes RFCOMM frame header).
This problem only appears if connection was initiated from the
phone. I'm not sure who is at fault here, so for now just put
workaround in place. Quick look at the spec did not reveal any
anwser.
Tested by: Jes < jjess at freebsd dot polarhome dot com >
MFC after: 3 days
allows my 3com cards to work again. It appears that this code was
once there, but I removed it when I added the alignment issues.
MFC After: 5 days
PR: 70639 (and likely others)
FreeBSD manual pages:
- POSIX-copyright contains copyright text to be used in manual pages
which has POSIX text inserted.
- deshallify.sh is a shell script which removes many of the ``shall''
statements from the POSIX text and therefore making the text more
readable.
Real work to make this happen by: nectar, ru
libraries live there too. Also point to ar(1) which contains a nice
description of what an 'archive library' is.
PR: docs/76056
Submitted by: Enrique Matías Sanchez <cronopios@gmail.com>
MFC after: 3 days
o Implement a shiny new algorithm to keep track of finger movement at
slow speeds. This dramatically reduces the level of questionable
language from users trying to resize windows.
o Properly catch the many extra buttons and dials which manufacturers
are known to screw onto Synaptics touchpad controllers. Currently,
up to seven buttons are known to work, more should work too.
o Add a number of sysctls allowing one to tune the driver to taste in
a simple way:
# Should the extra buttons act as axes or as middle button
hw.psm.synaptics.directional_scrolls
# These control the 'stickiness' at low speeds
hw.psm.synaptics.low_speed_threshold
hw.psm.synaptics.min_movement
hw.psm.synaptics.squelch_level
PR: kern/75725
Submitted by: Jason Kuri <jay@oneway.com>
MFC after: 1 month
fe1: <EAGLE Technology NE200 ETHERNET LAN MBH10302 04>
As reported by Sean Shapira. This appears to be working. Eagle used
Fujitsu's vendor number, with a product number of 4 (which is the same
as the vendor number, which is a little suspect). Since there's no
apparent conflict, go ahead and use it.
Submitted by: Sean Shapira
card, and works with that driver. However, Eagle is using Fujitsu's
vendor number and a product code of 4, which seems a little odd.
Still, there's no conflicts...
1/ doesn't matter on most of our architectures
2/ will never happen unless we start queueing multiple trasactions
to a single endpoint at one time (which we do not allow yet).
If anyone has a big_endian machine with EHCI they might check this
if they are having problems with EHCI but it's unlikely even there..
Submitted by: Hans Petter Selasky <hselasky@c2i.net>
MFC after: 3 days
