(1) bpf peer attaches to interface netif0
(2) Packet is received by netif0
(3) ifp->if_bpf pointer is checked and handed off to bpf
(4) bpf peer detaches from netif0 resulting in ifp->if_bpf being
initialized to NULL.
(5) ifp->if_bpf is dereferenced by bpf machinery
(6) Kaboom
This race condition likely explains the various different kernel panics
reported around sending SIGINT to tcpdump or dhclient processes. But really
this race can result in kernel panics anywhere you have frequent bpf attach
and detach operations with high packet per second load.
Summary of changes:
- Remove the bpf interface's "driverp" member
- When we attach bpf interfaces, we now set the ifp->if_bpf member to the
bpf interface structure. Once this is done, ifp->if_bpf should never be
NULL. [1]
- Introduce bpf_peers_present function, an inline operation which will do
a lockless read bpf peer list associated with the interface. It should
be noted that the bpf code will pickup the bpf_interface lock before adding
or removing bpf peers. This should serialize the access to the bpf descriptor
list, removing the race.
- Expose the bpf_if structure in bpf.h so that the bpf_peers_present function
can use it. This also removes the struct bpf_if; hack that was there.
- Adjust all consumers of the raw if_bpf structure to use bpf_peers_present
Now what happens is:
(1) Packet is received by netif0
(2) Check to see if bpf descriptor list is empty
(3) Pickup the bpf interface lock
(4) Hand packet off to process
From the attach/detach side:
(1) Pickup the bpf interface lock
(2) Add/remove from bpf descriptor list
Now that we are storing the bpf interface structure with the ifnet, there is
is no need to walk the bpf interface list to locate the correct bpf interface.
We now simply look up the interface, and initialize the pointer. This has a
nice side effect of changing a bpf interface attach operation from O(N) (where
N is the number of bpf interfaces), to O(1).
[1] From now on, we can no longer check ifp->if_bpf to tell us whether or
not we have any bpf peers that might be interested in receiving packets.
In collaboration with: sam@
MFC after: 1 month
fixing speed negotiation.
Also fix the mpt_execute_req function to actually
match mpt_execute_req_a64. This may explain why
i386 users were having more grief.
can see the results of SPI negotiation w/o being overwhelmed
with other crap).
+ For U320 devices, check against both Settings *and* DV flags before
deciding whether we need to skip actual SPI settings for a device.
+ Go back to creating a 'physical disk' side of a raid/passthru bus that
is limited to the number of maximum physical disks. Actually, this isn't
probably *quite* right yet for one RAID volume, and if we ever end up
with finding a device that supports more than one RAID volume (not likely),
it probably won't quite be right either.
The problem here is that the creating of this 'physical' passthru sim is
just a cheap way to leverage off the CAM midlayer to do our negotiation
for us on the subentities that make up a RAID volume. It almost causes
more trouble than it is worth because we have to remember which side
we're talking to in terms of forming commands and which target ids are
real and so on. Bleah.
+ Skip trying to actually do SPI settings for the RAID volumes on the
real side of the raid/passthru bus pair- this just confuses the issue.
The underlying real physical devices will have the negotiation performed
and the Raid volume will inherit the resultant settings. At the sime time,
non-RAID devices can be on the same real bus, so *do* perform negotiations
with them.
+ At the end of doing all of the settings twiddling, *ahem*, remember to
go update the settings on the card itself (dunno how this got nuked).
At this point, negotiations *seem* to be being done (again) correctly for
both RAID volumes and their subentities. And they seem to be *mostly*
now right for other non-RAID entities on the same bus (I ended up with
3 out of 8 other disks still at narror/async- haven't the slightest
idea why yes).
Finally, negotiations on a normal bus seem to work (again).
There's still more work coming into this area, but we're in the
final stretch.
the passed target id is one of the RAID VolumeID. This result
is used to decide whether to try and do actual SPI negotiations
on the real side of the raid/passthru bus pair. The reason we
check this is that we can have both RAID volumes and real devices
on the same bus.
USBD_FORCE_SHORT_XFER to ensure that we actually build and execute
a transfer. This means that the various alloc_sqtd_chain functions
will always construct a transfer, so it is safe to modify the
allocated descriptors on return. Previously there were cases where
a zero length transfer would cause a NULL dereference.
Reported by: bp
- Reduce the number of RX and TX buffers bfe uses so that it does not use more
bounce buffers than busdma is willing to allow it to use
See if_bfe.c for comments on why this is now safe to do.
Also use BUS_DMA_ALLOCNOW to be on the safe side.
2. Look for the Descriptor Error, and Descriptor Protocol Error flags from
the card, and down the interface if we detect either.
#1 (along with fixes to busdma) makes sure that this card works in all
memory situations. Prior to this change, it was just luck that 512 count
RX/TX lists were properly aligned. Now we can use any size of RX/TX lists
and still have them properly aligned.
#2 ensures that we don't get into an endless interrupt storm if busdma fails
us. Descriptor Protocol Error would occur if we misaligned the TX/RX rings,
and Descriptor Error would occur if we tried to give the card descriptors
or rings with addresses > 1G. Trying to reinitialize the card isn't going
to fix these errors, hence we don't try.
host controllers to avoid the need to allocate any multi-page
physically contiguous memory blocks. This makes it possible to use
USB devices reliably on low-memory systems or when memory is too
fragmented for contiguous allocations to succeed.
The USB subsystem now uses bus_dmamap_load() directly on the buffers
supplied by USB peripheral drivers, so this also avoids having to
copy data back and forth before and after transfers. The ehci and
ohci controllers support scatter/gather as long as the buffer is
contiguous in the virtual address space. For uhci the hardware
cannot handle a physical address discontinuity within a USB packet,
so it is necessary to copy small memory fragments at times.
lost one set to a peninsula power failure last night. After
this, I can see both submembers and the raid volumes again,
but speed negotiation is still broken.
Add a mpt_raid_free_mem function to centralize the resource
reclaim and fixed a small memory leak.
Remove restriction on number of targets for systems with IM enabled-
you can have setups that have both IM volumes as well as other devices.
Fix target id selection for passthru and nonpastrhu cases.
Move complete command dumpt to MPT_PRT_DEBUG1 level so that just
setting debug level gets mostly informative albeit less verbose
dumping.
but large parts are rewritten by matk and tanimura.
This is old code, it's not maintained since 2003. We also don't have a
maintainer for this! Yuriy Tsibizov took it and uses it in his emu10kx
driver. Since the emu10kx driver will enter the tree "soon" (some bugs
have to be fixed after Yuriy return from his holidays), I add it here
already.
This also contains some changes to emu10k1 and cmi, so if you're lucky,
you can now make some kind of use of midi with those soundcards.
To all those poor souls which don't have such a card: feel free to send
patches, we don't have a maintainer for this.
To those which miss a specific feature in the midi code: feel free to
submit patches, we don't have a maintainer for this.
Oh, did I already told that it would be nice if someone would take care
of it? Maintainer with midi equipment wanted! :-)
If you get LOR's, submit a PR and notify multimedia@ please. If you get
panics, submit a PR with a backtrace (compile the sound system into your
kernel instead of using modules in this case) and notify multimedia@
please.
Written by: matk, tanimura
Submitted by: "Yuriy Tsibizov" <Yuriy.Tsibizov@gfk.ru>
Based upon: code from NetBSD
but large parts are rewritten by matk and tanimura.
This is old code, it's not maintained since 2003. We also don't have a
maintainer for this! Yuriy Tsibizov took it and uses it in his emu10kx
driver. Since the emu10kx driver will enter the tree "soon" (some bugs
have to be fixed after Yuriy return from his holidays), I add it here
already.
This also contains some changes to emu10k1 and cmi, so if you're lucky,
you can now make some kind of use of midi with those soundcards.
To all those poor souls which don't have such a card: feel free to send
patches, we don't have a maintainer for this.
To those which miss a specific feature in the midi code: feel free to
submit patches, we don't have a maintainer for this.
Oh, did I already told that it would be nice if someone would take care
of it? Maintainer with midi equipment wanted! :-)
If you get LOR's, submit a PR and notify multimedia@ please. If you get
panics, submit a PR with a backtrace (compile the sound system into your
kernel instead of using modules in this case) and notify multimedia@
please.
Written by: matk, tanimura
Submitted by: "Yuriy Tsibizov" <Yuriy.Tsibizov@gfk.ru>
Based upon: code from NetBSD
This used to make syscons switch to vty0 when we entered DDB but this
was lost in the KDB shuffle. We may want to bring it back down the road
but it should be done by calling cn_init_t/cn_term_t instead, possibly
with a flag argument saying "Debugger!"
other timeouts could not happen while suspending, including timeouts
for things like msleep. This caused the system to hang on suspend
when the cbb was enabled, since its suspend path powered down the
socket which used a timeout to wait for it to be done.
APM now creates a thread when it is enabled, and deletes the thread
when it is disabled. This thread takes the place of the timeout by
doing its polling every ~.9s. When the thread is disabled, it will
wakeup early, otherwise it times out and polls the varius things the
old timeout polled (APM events, suspend delays, etc).
This makes my Sony VAIO 505TS suspend/resume correctly when APM is
enabled (ACPI is black listed on my 505TS).
This will likely fix other problems with the suspend path where
drivers would sleep with msleep and/or do other timeouts. Maybe
there's some special case code that would use DELAY while suspending
and msleep otherwise that can be revisited and removed.
This was also tested by glebius@, who pointed out that in the patch I
sent him, I'd forgotten apm_saver.c
MFC After: 3 weeks
was done, I believe, to work around some cards having issues in the
suspend case. I think that this helped my Sony VAIO TS505 work better
when it had certain wireless cards in it and I did a apm -z. I've not
tested suspend/resume on other laptops in a long time, so I hope this
doesn't cause greif. Please let me know if it does.
