keramida [Tue, 11 Jan 2005 10:47:51 +0000 (10:47 +0000)]
Fix a typo in a comment that may be confusing if one doesn't really
check what the code does. Separators are spaces, commas or tabs;
not '*' characters (as one may assume by reading the old comment).
joerg [Tue, 11 Jan 2005 08:51:21 +0000 (08:51 +0000)]
The total sum of blocks for the -l and -s option is printed always,
regardless whether the output is to a terminal or not. As this is
consistent with the SUSPv2 specification (even though we do not
otherwise fully implement SUSPv2's ls(1) options), document this as it
is now, rather than trying to change the behaviour itself.
PR: docs/76072
Submitted by: Sebastian Rey <Sebastian.rey@gmx.net>
MFC after: 1 week
grehan [Tue, 11 Jan 2005 08:09:50 +0000 (08:09 +0000)]
- allow a device hint to disable probing a slot on a Uninorth PCI bus.
e.g. at the loader:
set hint.pcib.1.skipslot=26
This allows undocumented and problematic hardware on some systems
to be ignored, for instance, the USB keyboard/mouse that shows up
on a 12" albook that doesn't exist nor do anything other than eat up
the syscons keyboard. Another one is the unused USB cell in the old
366MHz iBook that locks up the machine when probed.
In a way this is temporary, since there are better fixes for the
above problems, but will be useful in the meantime by allowing
a keyboard to be used to help debug said fixes :)
phk [Tue, 11 Jan 2005 07:36:22 +0000 (07:36 +0000)]
Remove the unused credential argument from VOP_FSYNC() and VFS_SYNC().
I'm not sure why a credential was added to these in the first place, it is
not used anywhere and it doesn't make much sense:
The credentials for syncing a file (ability to write to the
file) should be checked at the system call level.
Credentials for syncing one or more filesystems ("none")
should be checked at the system call level as well.
If the filesystem implementation needs a particular credential
to carry out the syncing it would logically have to the
cached mount credential, or a credential cached along with
any delayed write data.
imp [Tue, 11 Jan 2005 06:48:38 +0000 (06:48 +0000)]
Add a few cards from NetBSD. They don't work yet, since the code to
read the ethernet address from the attribute space hasn't been
implemented. Also add flags for the MBH10302. The flags and maddr
fields will be used when reading from the attribute space...
bmilekic [Tue, 11 Jan 2005 03:33:09 +0000 (03:33 +0000)]
While we want the recursion protection for the bucket zones so that
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>
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
emax [Tue, 11 Jan 2005 01:39:53 +0000 (01:39 +0000)]
Make default RFCOMM session MTU match default L2CAP MTU.
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
imp [Tue, 11 Jan 2005 01:17:07 +0000 (01:17 +0000)]
Final attempt to make aha 1542A working. If not, oh well, I don't
have the card and no way to reproduce problems. We do this by
applying the workaround to firmware revsion 0.
imp [Tue, 11 Jan 2005 00:32:43 +0000 (00:32 +0000)]
Properly calculate the offset in mapping the memory of pccards. This
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.
dougb [Tue, 11 Jan 2005 00:25:38 +0000 (00:25 +0000)]
1. s/women/woman/ when the singular is intended
2. Remove some duplicates
3. Slightly improve a punch line, "and then cut off her head"
instead of "and cut her head off."
simon [Mon, 10 Jan 2005 18:09:17 +0000 (18:09 +0000)]
Add support files for using text from the POSIX specification in
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.
keramida [Mon, 10 Jan 2005 16:06:13 +0000 (16:06 +0000)]
/usr/lib doesn't contain only archive (ar(1) style) libraries. Shared
libraries live there too. Also point to ar(1) which contains a nice
description of what an 'archive library' is.
philip [Mon, 10 Jan 2005 13:05:58 +0000 (13:05 +0000)]
Make life for owners of Synaptics Touchpads more pleasant :-)
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
imp [Mon, 10 Jan 2005 03:48:17 +0000 (03:48 +0000)]
Add support for:
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.
imp [Mon, 10 Jan 2005 03:45:21 +0000 (03:45 +0000)]
Add Eagle NE200 Ethernet LAN MBH10302 card. This appears to be a fe
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...
dwhite [Mon, 10 Jan 2005 02:34:26 +0000 (02:34 +0000)]
Free the shared devq last since CAM expects it to be there if
xpt_alloc_device() gets called, which can happen during detach in
certain situations. Fixes module unload.
julian [Sun, 9 Jan 2005 23:49:45 +0000 (23:49 +0000)]
fix a "little-endian-big-endian confusion that luckily:
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
imp [Sun, 9 Jan 2005 22:17:39 +0000 (22:17 +0000)]
In my last commit, I'd assumed that LINE30 was always defined. It
turns out that LINE30_ROW was always defined, not LINE30. I confused
this for LINE30 and did the unifdef -DLINE30 using that mistaken
belief. This corrects that problem.
marcel [Sun, 9 Jan 2005 18:58:08 +0000 (18:58 +0000)]
Don't panic when we're asked to allocate a resource type that we know
won't exist for EBus. Just fail the allocation by returning NULL.
Now drivers that are MI can try resources that the driver knows may
be used by the device.
Revert previous revision. Including bsd.compat.mk is necessary
both from sys.mk (to handle old knobs set in /etc/make.conf),
and from here (to handle old knobs set in individual makefiles).
rwatson [Sun, 9 Jan 2005 07:34:55 +0000 (07:34 +0000)]
Mark the IPX netisr as MPSAFE so that inbound IPX traffic is processed
without Giant, and can be directly dispatched in the ithread when
net.isr.enable is turned on.
rwatson [Sun, 9 Jan 2005 05:34:37 +0000 (05:34 +0000)]
Recent changes have locked down most of the highly dynamic data
structures in IPX/SPX -- primarily, sequence numbering, PCB lists,
and PCBs for IPX raw sockets, IPX datagram sockets, and IPX/SPX.
As such, remove remove NET_NEEDS_GIANT() for IPX, and remove the
assertion of Giant in the ipxintr() IPX input path.
Note that IPX/SPX is not fully MPSAFE, and that there are some
problems with IPX/SPX locking that will require some further work.
However, it is now safe enough to run in general without the Giant
lock.
rwatson [Sun, 9 Jan 2005 05:31:16 +0000 (05:31 +0000)]
Use the IPX PCB list mutex and IPX PCB mutexes to lock down the SPX
portion of IPX/SPX:
- Protect IPX PCB lists with the IPX PCB list mutex, in particular
when calling PCB and PCB list manipulation routines in ipx_pcb.c.
- Protect both IPX PCB state and SPX PCB state using the IPX PCB
mutex.
- Generally annotate locking, as well as adding liberal use of lock
assertions to document locking requirements.
- Where possible, use unlocked reads when reading integer or smaller
sized socket options on SPX sockets.
- De-spl throughout.
Notes:
- spx_input() expects both the list mutex and PCB mutex to be held
on entry, but will release both on return. Because sonewconn() is
called from spx_input(), it may actually drop one PCB lock and
acquire another during generation of a new connection, meaning the
caller is not in a position to unlock the PCB mutex.
rwatson [Sun, 9 Jan 2005 05:25:02 +0000 (05:25 +0000)]
Clean up return handling for a number of SPX-related routines that
were derived from more complex TCP versions of the same:
- spx_close(), spx_disconnect(), spx_drop(), and spx_usrclosed() all
always free's the spxpcb invalidating the argument, so a return
value is not required to indicate if it has.
- Annotate that the cb arguments to each of these functions is
invalidated via a comment.
- When tearing down a pcb due to sonewconn() having failed, mark the
cb as NULL; later, when deciding whether to store trace information
due to SO_DEBUG, check that cb is not NULL before dereferencing or
a NULL pointer dereference may occur.
rwatson [Sun, 9 Jan 2005 05:15:59 +0000 (05:15 +0000)]
Protect ipx_pexseq with the IPX PCB list mutex.
When processing socket options against IPX PCBs, generally protect
PCB fields using the IPX PCB mutex. Where possible, use unlocked
reads on integer values to avoid locking overhead.
rwatson [Sun, 9 Jan 2005 05:13:14 +0000 (05:13 +0000)]
Acquire or assert the IPX PCB list lock or IPX PCB lock during various
protocol methods relating to IPX. Conditionally acquire the PCB list
lock in the send operation only if the socket requires binding in order
to use the requested address.
Remove spl's generally no longer required during these accesses.
rwatson [Sun, 9 Jan 2005 05:10:43 +0000 (05:10 +0000)]
Assert or acquire the IPX PCB list lock or IPX PCB locks throughout
the IPX-related PCB routines. In general, the list lock is required
to iterate the PCB list, either for read or write; the PCB lock is
required to access or modify a PCB. To change the binding of a PCB,
both locks must be held.