aue panic in 3.0

[Ignatios Souvatzis]

Hi,

I've seen occasional aue panics (on netbsd-3.0), due to ltsleep() in
multicast filter setting in interupt context - I think related to neighbour
discovery. Is this a known and fixed in -current bug, or do I need to hunt
that one myself?

Regards,
-is

[Ignatios Souvatzis]

Post by Ignatios Souvatzis
I've seen occasional aue panics (on netbsd-3.0), due to ltsleep() in
multicast filter setting in interupt context - I think related to neighbour
discovery. Is this a known and fixed in -current bug, or do I need to hunt
that one myself?

*sigh*

To document:

ltsleep,
usbd_transfer
usb_do_request_flags_pipe
usb_do_request_flags
aud_csr_read_1
aue_setmulti
aue_ioctl
in6_addmulti
in6_joingroup
in6_update_ifa
in6_ifadd
prelist_update
nd6_ra_input
icmp6_input

Is usbd_transfer supposed to not be called from interupt context?

[moved to tech-kern for this question.]

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ignatios Souvatzis]

That is true but I think 'can' is not 'will' - if the driver wants to call
usbd_transfer from interrupt context, the allocation can be arranged
safely in advance, so far as I can tell..?

and secondly in the case which Ignatios reported, USBD_SYNCHRONOUS is
set, so usbd_transfer will sleep!

yeah :)

Well, I've moved multicast filter setting (which is about all
initialization) to a workqueue(9) (which is something like a wrapper
around a working thread).

I wonder if the ipv6 Neighbour Discovery code should do this instead at
a higher level, so that the ioctl() function is never called from
interupt context...

-is

[Hans Petter Selasky]

Post by Ignatios Souvatzis

That is true but I think 'can' is not 'will' - if the driver wants to
call usbd_transfer from interrupt context, the allocation can be arranged
safely in advance, so far as I can tell..?

and secondly in the case which Ignatios reported, USBD_SYNCHRONOUS is
set, so usbd_transfer will sleep!

yeah :)

Well, I've moved multicast filter setting (which is about all
initialization) to a workqueue(9) (which is something like a wrapper
around a working thread).
I wonder if the ipv6 Neighbour Discovery code should do this instead at
a higher level, so that the ioctl() function is never called from
interupt context...

What do you do if the USB device is reading/writing registers while it is
detached? Do you tear down that workqueue first?

--HPS

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Iain Hibbert]

Is usbd_transfer allowed to be called from interrupt context?

The answer is no. Deep inside the [old] USB system, usbd_transfer can
allocate memory when it is called, that can sleep

That is true but I think 'can' is not 'will' - if the driver wants to call
usbd_transfer from interrupt context, the allocation can be arranged
safely in advance, so far as I can tell..?

Last time I checked, the NetBSD USB stack will start allocating memory
at the moment usbd_transfer() is called. This is USB hardware memory
like transfer descriptors and DMA memory for the data-buffers.s And it
can sleep! The old system is simply wrong. It is not possible to
pre-allocate all memory. Only some parts like the "struct usbd_xfer" and
"struct usbd_xfer -> buffer".

The allocation inside usbd_transfer() seems to be those parts that you
mention can be pre-allocated, and the sleep is only when USBD_SYNCHRONOUS
is set..

Further down _NOWAIT does seem to be used where it is needed (so far as I
can see :)

Without defending the USB stack particularly, I think the real lack is one
of documentation.. There is no indication of what should be done and what
is possible.

Secondly you will get another headache if you try to modify the USB network
drivers into using pre-allocated USB transfers. That is, many times the USB
network drivers will read a value before they write a value, and that has to
sleep.

My concern is the ubt(4) driver which I wrote, but that seems (to me) to
safely allocate everything in advance and deals transfers asynchronously -
certainly I've had no issues with it in a fairly low memory system and
running Firefox & gcc etc (with painful swapping)

iain

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de