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
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
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 do
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
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: i
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
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,
On 23 October 2012 00:16, Marko Zec 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 without ha
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
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 m
On Monday 22 October 2012 19:41:19 Adrian Chadd wrote:
> On 22 October 2012 10:29, Julian Elischer 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
On 22 October 2012 10:29, Julian Elischer 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 that is se
On 10/22/12 7:12 AM, Adrian Chadd wrote:
On 22 October 2012 03:08, Marko Zec 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 o
On 22 October 2012 03:08, Marko Zec 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 device_
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.
>
>
On 21 October 2012 14:22, Marko Zec 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 iss
On Sunday 21 October 2012 21:50:21 Adrian Chadd wrote:
> On 21 October 2012 12:36, Marko Zec 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 h
On 21 October 2012 12:36, Marko Zec 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 specific where
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 CURVNET_
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, det
21 matches
Mail list logo
