| Age | Commit message (Collapse) | Author |
|---|
|
With this change sensorsd(8) now correctly detects state changes when
docking and undocking.
ok mlarkin@
|
|
a driver does not implement a specific *_activate() handler and that our
USB stack sets the dying flag before detaching a device, these specific
handlers can die.
|
|
to use BGE_STD_RX_RING_CNT instead of BGE_JUMBO_RX_RING_CNT.
ok dlg@
|
|
|
|
|
|
invalid. When such thing happens, it means that the address is no
longer configured on the system but still referenced by some routes.
So do not return such ifa in ifa_ifwithroute().
Fix a panic reported by Pierre Bardou.
ok mikeb@, henning@
|
|
fields.
found by steven roberts, who also tested this fix for me
|
|
|
|
Izumi Tsutsui, thanks!
ok miod@
|
|
The interface has been disabled by default for about 4 years and
currently there's not much value in having it around at all.
ok deraadt
|
|
The interface has been disabled by default for about 4 years and
currently there's not much value in having it around at all.
ok deraadt
|
|
device tables and kernel config files. ok deraadt
|
|
ok guenther@
|
|
them up and the others i found in this file.
no functional change.
|
|
putting this into the tree to make it easier to test.
|
|
putting this in the tree to make it easier for people to test.
|
|
putting this in the tree to make it easier for people to test.
|
|
the right shape now, we dont have to do it by hand all over the place
any more.
rework the rxr ring management to use if_rxring while here.
largely based on if_sk.c r1.152 and if_skvar.h r1.4 by kettenis.
tested by me on:
skc0 at pci3 dev 11 function 0 "Schneider & Koch SK-98xx" rev 0x12, GEnesis (0x0): apic 3 int 5
sk0 at skc0 port A: address 00:00:5a:99:8a:ec
xmphy0 at sk0 phy 0: XMAC II Gigabit PHY, rev. 2
and this from ian mcwilliam
skc0 at pci0 dev 9 function 0 "D-Link DGE-530T B1" rev 0x11, Yukon Lite (0x9): apic 2 int 17
sk0 at skc0 port A: address 00:17:9a:ba:b5:39
eephy0 at sk0 phy 0: 88E1011 Gigabit PHY, rev. 5
tested by brad@ too
|
|
add an explicit rwlock around the global state (the pool list and serial
number) rather than rely on implicit process exclusion, splhigh and splvm.
the only things touching the global state come from process context so we
can get away with an rwlock instead of a mutex. thankfully.
ok matthew@
|
|
interrupts in PIC rev 1; from IRIX via Linux 2.5.69.
This doesn't fix the lost SCSI interrupts jasper@ eventually experiences on
Origin 350 systems, but this can't hurt anyway.
|
|
No change but ordering in the generated files, so I won't even bother to
regen them - this is only a `documentation' change.
|
|
|
|
Shuffle the code around slightly, so we special case the 5209 chipset
instead of semi-randomly.
Tested on rts5227 by me, and rts5209 by stsp@
OK stsp@
|
|
|
|
also adds a broadcast entry flagged with RTF_BROADCAST.
Prior to this change broadcast entries were simple clonned ARP entries,
that would be deleted once their timer expired since they would always
be incomplete.
With this change they are now persistant and identifiable with a new flag.
Committing early to be able to deal with any potential fallout before we
start relying on this.
ok florian@, mikeb@, henning@
|
|
|
|
When pms(4) is attached to a touchpad it generally presents two different
wsmouse(4) devices: one for the touchpad itself and one for the clitpad
and/or some interleaved packets. But since both devices are writing to
the same pckbc slot, a race can occur if they try to change the state at
the same time.
So prevent two process opening the two /dev/wsmouse* node at the same time
to corrupt the magic sequences needed to enable/disable the touchpad.
ok schadchin@
|
|
while (space) {
IFQ_POLL;
myx_dequeue(free descr);
IFQ_DEQUEUE;
etc;
}
with
while (space && myx_dequeue(free descr)) {
IFQ_DEQUEUE;
etc;
}
|
|
Those two functions take one dev_t argument, not int. Match declarations
with reality. No functional changes.
|
|
|
|
depend upon the address being at the beginning of a cache line, for we may
arrive in the middle of a line thanks to a branch. Noticed the hard way...
|
|
|
|
found by benoit@
|
|
ok miod@, who has offerred to help with any MD fallout
ok guenther@
|
|
malloc.h instead.
|
|
and a count of the mbufs.
struct mbuf_list and the ml_foo() apis can be used to build lists of
mbufs where you dont need locking (eg, on the stack).
struct mbuf_queue and mq_foo() wrap mbuf_lists with a mutex, and
limits the number of mbufs that can be queued. they can be useful
for moving mbufs between contexts/subsystems.
with help from jmc@ for the manpage bits
mpi@ is keen
|
|
containing an item when its returned to the pool. this means you
need to do an inexact comparison between an items address and the
page address, cos a pool page can contain many items.
previously this used RB_FIND with a compare function that would do math
on every node comparison to see if one node (the key) was within the other
node (the tree element).
this cuts it over to using RB_NFIND to find the closest tree node
instead of the exact tree node. the node compares turns into simple
< and > operations, which inline very nicely with the RB_NFIND. the
constraint (an item must be within a page) is then checked only
once after the NFIND call.
feedback from matthew@ and tedu@
|
|
`bus error upon instruction fetch' exceptions where the faulting address is
in the kernel, and at the very beginning of an I$ cache line.
(I've experienced these on an R16000 Fuel since several months already)
|
|
made it so struct pool was only visible to _KERNEL. tedu broke it
too when he added the size argument to the kernel free
functions.
this fixes both issues. the main change is to provide a local version of
struct pool with just the bit (pr_size) needed for extent to run.
if extents take advantage of more malloc/pool features (eg, {M,PR}_ZERO
then this will need to be updated again.
found by and based on a diff from Theo Buehler
ok mpi@
|
|
|
|
|
|
obsolete. No objections from the usual suspects.
|
|
|
|
|
|
adapters can use "IEEE sgl".
tested dlg yasuoka
ok dlg jsg
|
|
|
|
each EHCI root hub). OK deraadt@ jsg@
|
|
millert@ and jmc@ agree that "overriden" is wrong
|
|
|
|
the hint returned is over VM_MAXUSER_ADDRESS, apparently; better be safe for
now while this is investigated further.
|
