On Thursday 15 November 2012 07:18:31 Adrian Chadd wrote:
Hi,
Here's what I have thus far. Please ignore the device_printf() change.
This works for me, both for hotplug cardbus wireless devices as well
as (inadvertently!) a USB bluetooth device.
What do you think?
It looks that you've hit
Hans brings up a very good point for USB - they split if_alloc and
if_attach across two different threads.
So this works for non-USB devices, but not for USB devices.
Hans, does each device implement its own workqueue for this kind of
delayed action, or is there some generic work queue that is
On Thursday 15 November 2012 20:16:12 Adrian Chadd wrote:
Hans brings up a very good point for USB - they split if_alloc and
if_attach across two different threads.
So this works for non-USB devices, but not for USB devices.
Hans, does each device implement its own workqueue for this kind
On Thursday 15 November 2012 20:32:06 Hans Petter Selasky wrote:
On Thursday 15 November 2012 20:16:12 Adrian Chadd wrote:
Hans brings up a very good point for USB - they split if_alloc and
if_attach across two different threads.
Fine, so maybe one of the following options could work:
1)
Hi,
Here's what I have thus far. Please ignore the device_printf() change.
This works for me, both for hotplug cardbus wireless devices as well
as (inadvertently!) a USB bluetooth device.
What do you think?
Adrian
20121114-vimage-1.diff
Description: Binary data
On Sunday 28 October 2012 19:47:20 Adrian Chadd wrote:
ping?
Marko - would you be willing to add the if_free() vnet context setup into
-HEAD?
Feel free to do it - though I'd suggest to use the CURVNET_SET_QUIET()
variant there, to reduce the console spam with VNET_DEBUG.
Marko
Index: if.c
ping?
Marko - would you be willing to add the if_free() vnet context setup into -HEAD?
Hans, what do you think about USB device attach? detach will be
covered by the above (I hope!) but we still need to do a
CURVNET_SET(vnet0); during hotplug attach.
Thanks,
Adrian
On 23 October 2012 10:37,
Hi,
I currently have not tested VIMAGE with USB devices.
Detach is the final exit for a USB device.
There is also shutdown, but softc still is around.
--HPS
On Sunday 28 October 2012 19:47:20 Adrian Chadd wrote:
ping?
Marko - would you be willing to add the if_free() vnet context setup
On Monday 22 October 2012 23:43:11 Adrian Chadd wrote:
Hi,
I don't mind tackling the net80211 clone detach path.
I do mind how the default for hotplug is argh, it doesn't work. :-)
So I'd like to come up with something to fix the basic device detach,
rather than having to actually add
On 23 October 2012 00:16, Marko Zec z...@fer.hr wrote:
As already mentioned earlier, I don't terribly object if you'd place
CURVNET_SET(ifp-if_vnet) inside if_free() and a limited number of similar
functions, but I don't quite believe this is will enough to solve the
device_detach() issue
On Monday 22 October 2012 01:03:19 Adrian Chadd wrote:
...
Obviously, handling device attach events is an exception from this
rule, and up to this date this was never properly addressed...
*laugh*.
The problem now is figuring out how to do it without modifying all the
drivers.
The
On 22 October 2012 03:08, Marko Zec z...@fer.hr wrote:
The only option I can think of now is to update all of the hotunpluggable
device_detach() handlers to do CURVNET_SET(ifp-if_vnet) before calling
further down into the networking stack, because as you already observed,
whatever triggers a
On 10/22/12 7:12 AM, Adrian Chadd wrote:
On 22 October 2012 03:08, Marko Zec z...@fer.hr wrote:
The only option I can think of now is to update all of the hotunpluggable
device_detach() handlers to do CURVNET_SET(ifp-if_vnet) before calling
further down into the networking stack, because as
On 22 October 2012 10:29, Julian Elischer jul...@freebsd.org wrote:
The trouble is going to be handling unplug and kldunload events too.
Does curvnet - vnet0 during kldunload events?
I think in unload events we probably need to cycle through all vnets and
do individual shutdowns of anything
On Monday 22 October 2012 19:41:19 Adrian Chadd wrote:
On 22 October 2012 10:29, Julian Elischer jul...@freebsd.org wrote:
The trouble is going to be handling unplug and kldunload events too.
Does curvnet - vnet0 during kldunload events?
I think in unload events we probably need to cycle
Hi,
I don't mind tackling the net80211 clone detach path.
I do mind how the default for hotplug is argh, it doesn't work. :-)
So I'd like to come up with something to fix the basic device detach,
rather than having to actually add CURVNET_*() calls around each
if_free() in each device detach
Hi all,
I have some crashes in the VIMAGE code on releng_9. Specifically, when
I enable VIMAGE and then hotplug some cardbus ath(4) NICs.
The panics are dereferencing the V_ ifindex and related fields.
If I start adding CURVNET_SET(vnet0) and CURVNET_RESTORE() around the
ifnet calls (attach,
On Sunday 21 October 2012 21:04:41 Adrian Chadd wrote:
Hi all,
I have some crashes in the VIMAGE code on releng_9. Specifically, when
I enable VIMAGE and then hotplug some cardbus ath(4) NICs.
The panics are dereferencing the V_ ifindex and related fields.
If I start adding
On 21 October 2012 12:36, Marko Zec z...@fer.hr wrote:
The right approach would be to do a single CURVNET_SET(vnet0) /
CURVNET_RESTORE() somewhere near the root of the call graph being triggered
by the hotplug attach event. Not having any hotpluggable hardware at hand
I cannot be more
On Sunday 21 October 2012 21:50:21 Adrian Chadd wrote:
On 21 October 2012 12:36, Marko Zec z...@fer.hr wrote:
The right approach would be to do a single CURVNET_SET(vnet0) /
CURVNET_RESTORE() somewhere near the root of the call graph being
triggered by the hotplug attach event. Not having
On 21 October 2012 14:22, Marko Zec z...@fer.hr wrote:
Right; would that be at the net80211 side, or something higher up (eg
at device_attach, which gets called from the cardbus/pci bridge
enumeration code.)
As high as it gets - if you get lucky, as a side effect you might even fix
similar
21 matches
Mail list logo
