Kernel WARNING leading to reboot required about bladerf HOT 7 CLOSED

Are you running on a computer with USB2.0 or USB3.0?

On Wed, Jul 17, 2013 at 1:44 AM, smunaut [email protected] wrote:

See http://pastebin.com/AsBhyky3

Not sure why/how it happened, but it should just not be possible. Looks
like missing locking somewhere / bad concurrency / race ...

Result was that USB became unusable and the process accessing the bladrf
was left unkillable, using 100% of CPU. So just had to reboot ...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17
.

from bladerf.

USB 2.0

from bladerf.

Sorry for close/reopen... damn "close" button is just too damn big

from bladerf.

Ok, we'll try to reproduce this with our USB 2.0 machines. Who is the manufacturer of that EHCI?

"URB ffff880240736300 submitted while active" is a pretty clear indicator of what happened, we'll try to add more debugging to see what could cause this. Please hang tight!

from bladerf.

Nvidia:

00:04.0 USB controller: NVIDIA Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:04.1 USB controller: NVIDIA Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:06.0 USB controller: NVIDIA Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:06.1 USB controller: NVIDIA Corporation MCP79 EHCI USB 2.0 Controller (rev b1)

I think I found a concurrency issue, but it shouldn't cause this AFAICT :

11:03 < tnt> I mean, AFAICT there is an obvious URB overrun issue.
11:05 -!- ttyUSB3 [~o@gateway/tor-sasl/omlib] has joined #bladerf
11:06 < tnt> The __submit_rx_urb loop will only stop submitting URB if 1) there is too many in-flight or 2) if the number of "ready to be read" is equal to the total number of available URB.
11:07 < tnt> The counter for (1) is incremented when submitting the URB and decremented in the read call back. That's fine.
11:07 < tnt> The counter for (2) is incremented in the read call back and decremented when the userspace comes and read data off it.
11:07 < tnt> Now imagine that userspace doesn't read data fast enough.
11:11 < tnt> To be more explicit. Let's say data_in_inflight is 1 and data_in_cnt is NUM_DATA_URB-2. And then that 'in-flight' URB comes back and the call back is called. data_in_cnt becomes
NUM_DATA_URB-1, and __submit_rx_urb is called, and it will submit as much as NUM_CONCURRENT URBs, (during that loop data_in_cnt doesn't change). and all but one of those URBs were actually
already filled with data.

But something might have been an issue was having the CLI launched at the same time as GnuRadio.
(I don't know if it was the case for this bug, can't remember exactly).

Because when looking at open/release, several app can open the device but if one closes, it will shutdown stuff that could still be use by the other (and for example change the URB index pointers without any kind of locking)

from bladerf.

There was a timeout patch that was just pushed. Although it will not
solve the reference issue, it will help with Ctrl+Cing out of programs.
Also, concurrent file descriptor handling will be added tomorrow.
Give us a bit to investigate the #2 scenario you mentioned.

On 7/17/2013 2:21 AM, smunaut wrote:

Nvidia:

00:04.0 USB controller: NVIDIA Corporation MCP79 OHCI USB 1.1
Controller (rev b1)
00:04.1 USB controller: NVIDIA Corporation MCP79 EHCI USB 2.0
Controller (rev b1)
00:06.0 USB controller: NVIDIA Corporation MCP79 OHCI USB 1.1
Controller (rev b1)
00:06.1 USB controller: NVIDIA Corporation MCP79 EHCI USB 2.0
Controller (rev b1)

I think I found a concurrency issue, but it shouldn't cause this AFAICT :

11:03 < tnt> I mean, AFAICT there is an obvious URB overrun issue.
11:05 -!- ttyUSB3 [~o@gateway/tor-sasl/omlib] has joined #bladerf
11:06 < tnt> The __submit_rx_urb loop will only stop submitting URB if

1. there is too many in-flight or 2) if the number of "ready to be
   read" is equal to the total number of available URB.
   11:07 < tnt> The counter for (1) is incremented when submitting the
   URB and decremented in the read call back. That's fine.
   11:07 < tnt> The counter for (2) is incremented in the read call back
   and decremented when the userspace comes and read data off it.
   11:07 < tnt> Now imagine that userspace doesn't read data fast enough.
   11:11 < tnt> To be more explicit. Let's say data_in_inflight is 1 and
   data_in_cnt is NUM_DATA_URB-2. And then that 'in-flight' URB comes
   back and the call back is called. data_in_cnt becomes
   NUM_DATA_URB-1, and __submit_rx_urb is called, and it will submit as
   much as NUM_CONCURRENT URBs, (during that loop data_in_cnt doesn't
   change). and all but one of those URBs were actually
   already filled with data.

But something might have been an issue was having the CLI launched at
the same time as GnuRadio.
(I don't know if it was the case for this bug, can't remember exactly).

Because when looking at open/release, several app can open the device
but if one closes, it will shutdown stuff that could still be use by
the other (and for example change the URB index pointers without any
kind of locking)

—
Reply to this email directly or view it on GitHub
#17 (comment).

from bladerf.

Using the kernel code to access the device is deprecated in favor of libusb. When the kernel module is re-written, it will likely be re-written from scratch and need more vetting out, but not related to this.

from bladerf.