Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

uvcvideo: USB isochronous frame lost #238

Closed
Berryfier opened this Issue · 28 comments

6 participants

@Berryfier

Symptoms: Moving pictures from a USB webcam are not fluid, they appear jerky or freeze frame. Individual images are delivered with intervals of various lengths between images.

To reproduce the problem:

  • use 2013-02-09 raspbian
  • plug in a webcam camera to the Pi USB (camera powered seperately - not from Pi)
  • at a terminal enter as root: sudo echo 0xFFFF > /sys/module/uvcvideo/parameters/trace
  • start an application which uses uvcvideo (e.g. mjpg-streamer)
  • after a few seconds, stop the application
  • at a terminal enter as root: sudo echo 0x0000 > /sys/module/uvcvideo/parameters/trace
  • look in /var/log/kern.log (example below using UVC Camera Logitech 046d:0991)

Feb 27 22:09:12 raspberrypi kernel: [ 5359.989325] uvcvideo: Frame complete (EOF found).
Feb 27 22:09:12 raspberrypi kernel: [ 5359.989374] uvcvideo: frame 20 stats: 59/1267/1593 packets, 1/39/1593 pts (early initial), 1592/1593 scr, last pts/stc/sof 3111250099/3120608861/1217
Feb 27 22:09:12 raspberrypi kernel: [ 5360.154221] uvcvideo: USB isochronous frame lost (-63).
Feb 27 22:09:12 raspberrypi kernel: [ 5360.166469] uvcvideo: USB isochronous frame lost (-63).
Feb 27 22:09:12 raspberrypi kernel: [ 5360.174708] uvcvideo: USB isochronous frame lost (-63).
Feb 27 22:09:12 raspberrypi kernel: [ 5360.186959] uvcvideo: USB isochronous frame lost (-63).
Feb 27 22:09:12 raspberrypi kernel: [ 5360.187038] uvcvideo: Frame complete (EOF found).
Feb 27 22:09:12 raspberrypi kernel: [ 5360.187069] uvcvideo: frame 21 stats: 59/1259/1583 packets, 1/39/1583 pts (early initial), 1582/1583 scr, last pts/stc/sof 3120851941/3130210964/1417
Feb 27 22:09:12 raspberrypi kernel: [ 5360.387163] uvcvideo: Frame complete (EOF found).
Feb 27 22:09:12 raspberrypi kernel: [ 5360.387237] uvcvideo: frame 22 stats: 59/1274/1599 packets, 1/39/1599 pts (early initial), 1598/1599 scr, last pts/stc/sof 3130453789/3139813066/1617
Feb 27 22:09:12 raspberrypi kernel: [ 5360.387420] uvcvideo: UVC Camera (046d:0991): PTS 3130453789 y 3720.807754 SOF 3720.807754 (x1 2155366602 x2 2156854928 y1 254607360 y2 256638976 SOF offset 250)
Feb 27 22:09:12 raspberrypi kernel: [ 5360.387465] uvcvideo: UVC Camera (046d:0991): SOF 3720.807754 y 994343961 ts 5360.593856 buf ts 5360.427484 (x1 246808576/12726/1837 x2 261554176/12951/1868 y1 1000000000 y2 1028159890)
Feb 27 22:09:12 raspberrypi kernel: [ 5360.387772] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
Feb 27 22:09:12 raspberrypi kernel: [ 5360.388090] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
Feb 27 22:09:12 raspberrypi kernel: [ 5360.395368] uvcvideo: USB isochronous frame lost (-63).
Feb 27 22:09:13 raspberrypi kernel: [ 5360.551643] uvcvideo: USB isochronous frame lost (-63).
Feb 27 22:09:13 raspberrypi kernel: [ 5360.568016] uvcvideo: USB isochronous frame lost (-63).
Feb 27 22:09:13 raspberrypi kernel: [ 5360.576270] uvcvideo: USB isochronous frame lost (-63).
Feb 27 22:09:13 raspberrypi kernel: [ 5360.584517] uvcvideo: USB isochronous frame lost (-63).
Feb 27 22:09:13 raspberrypi kernel: [ 5360.588666] uvcvideo: Frame complete (EOF found).
Feb 27 22:09:13 raspberrypi kernel: [ 5360.588705] uvcvideo: frame 23 stats: 57/1265/1583 packets, 1/39/1583 pts (early initial), 1582/1583 scr, last pts/stc/sof 3140055631/3149415169/1817'''

@ghollingworth ghollingworth was assigned
@P33M
Owner

Having spent a while with GPIO/oscilloscope debugging while sorting out other issues, I can say the following:

There is a very large chunk of time spent in_interrupt() when a set of isoc transcations complete, especially with uvcvideo transfers. The driver by default queues 5x URBs of 32 transactions each. Once a 32-burst transaction is complete, the uvcvideo completion handler is called from within the dwc_otg interrupt handler and it blocks for anything up to 700uS. This will cause multiple queued isoc transactions to get dropped due to frame overrun, as seen with the -63 return code. Typical time spent in_interrupt() for a normal xfercomp interrupt handle (no URB completion) is approx 30uS. Still huge, but at least less than a microframe.

I believe this is a rather large smoking gun - given that the dwc driver coders apparently have never heard of bottom-half interrupt handlers, it would definitely be worth splitting completion functions off into a softirq/tasklet.

@ghollingworth
@ghollingworth
@P33M
Owner

So what would break if we split URB completion off into a tasklet? If using the high priority softirq, nothing else scheduling-wise would be allowed to run until it completed but the myriad of hardware interrupts that the dwc usb core generates would still get serviced.

The only thing I could think of would be multiple calls to a completion tasklet if we got multiple URBs completing in a very short space of time - needing some sort of queuing mechanism should there be a pileup of completed transfers.

@Berryfier: have you tried tweaking the driver parameters? Try modprobe with nodrop=1 which should deliver corrupted frames rather than no frames.

@Berryfier

@P33M : thank you for your suggestion to tweak the driver parameters. With the camera unplugged, and as root, I entered 'sudo modprobe uvcvideo nodrop=1'. I then plugged in the camera, and started guvcview. The image motion was much more fluid, there were no freeze frames, and the frame rates achieved were much greater; 15fps@320x240, 7 fps@640x480. This is all with the camera sending MJPEG. I notice that with the tweak the CPU is maxed out with the 640x480 picture@7fps. Without the tweak, CPU use is always low, whatever the picture size, the display rarely exceeding 1fps. I also ran the trace and checked the kern.log. I was surprised to still see the large amount of uvcvideo: USB isochronous frame lost (-63) which appears as frequently as occurs without the tweak. It seems a fix is still needed. I've not (yet) noticed any corruption of the pictures either with or without the tweak.

@ghost

Is it possible this issue is somehow linked to issue #199 ?

@P33M
Owner

Uh

I think I fixed it...

https://gist.github.com/P33M/5213278

What I did was implement a tasklet to split the return of the URB to the various device drivers from the time we spend sitting with interrupts disabled. Previously my crummy uncompressed-frame webcam would fail repeatedly with lost isoc packets when trying uvccapture, now everything works first time.

Comments on the code would be appreciated before I submit a pull request. This is a fairly big structural change for the driver.

@ghost

I'll test it this evening and let you know. Thanks for the effort.

@ghollingworth
@P33M
Owner

After playing with it a bit it seems stable with ethernet/usb disk/webcam activity.

I installed guvcview to test streaming from the cam - at 640x480 there is still the odd corrupted frame with nodrop=1 but with corrupted frames dropped I am getting approx 60% valid frames (camera is spitting out 30fps) of uncompressed video at 640x480 - a data rate of 17MB/s. Guvcview is maxing out the CPU anyways so I can't tell if the drops are more due to corruption or lack of cycles.

Increasing USB loading, as expected, does not alter the error rate of the video. Other interrupt sources (sd card, timers, etc) appear to cause a packet drop if they take longer than 125uS to complete, or the isoc transaction happens near the end of a uframe and servicing the interrupt takes it past the SOF for the next frame.

My Sidewinder X4 keyboard - previously unusuable on the pi, as of recent kernels more useable - is still missing keypresses though I think slightly less than before.

@ghost

Can someone, please, point me out to some guide how to compile the kernel including the patch from P33M?

@P33M
Owner

I've pushed the commit to my repo. https://github.com/P33M/linux

If you follow the standard kernel compilation guide: http://elinux.org/RPi_Kernel_Compilation

But substitute my repo for the official one, you will get the patch. I strongly recommend using cross-compilation from another machine unless you have 12 hours to spare.

Note that you will need to install both the compiled modules AND the kernel.img to your SD card.

@ghost

Thanks for the effort and the guide. And the tip to cross-compile ;)
I did it accordingly (replacing the raspberrypi by P33M in github address) and all seemed to work well.
I compiled the kernel image and modules, tgz them and moved both to my Pi into appropriate locations.
The Pi booted (HURAY!!!), uname -a shows
3.6.11+ #1 PREEMPT
But, unfortunately, the result is still the same - the camera complains about Non-zero status and even with nodrop=1 and timeout=5000 parameters, the behaviour is exactly the same. After 5 records, the module simply stops responding.
Is there something I should have set/patched during the kernel compilation? Or is the fix not helping in this case?

@P33M
Owner

@RKlauco That's interesting. It's possible there's another issue - the errors that I get are -63 (they do still occur, but much less than previously) which are due to frame overruns.

  • What camera produces this result?
  • What userland application are you using to stream/record the images?
  • Can you do a lsusb -v for the camera and post the output?

Looking at the driver, -5 is returned for periodic transfers when the transfer halted but there are no other interrupts set. I've not seen them in my case - further testing required!

Edit: -5 is a URB state, -63 is a individual iso_desc state - so rather than individual transfers failing, your URB is being aborted.

@ghost
@P33M
Owner

I've done some cross comparison between the current HEAD and #255 - and borrowed a Logitech Quickcam Pro 5000 (uvcvideo device, but with a much broader feature set than my ebay special) which supports multiple framerates and mjpeg capture.

For both cameras the difference is, well, an order of magnitude. With YUYV mode on the Logitech I was getting about 1/10th of a frame transmitted OK on any resolution >320x240 - and a substantially reduced framerate with mjpg. CPU usage was also much higher I assume due to uvcvideo trying to reassemble frames which included lost packets.

I can also confirm that this change significantly improves the usability of my Sidewinder X4 keyboard used in X11 - from maddeningly frequent keystroke misses to a couple every sentence.

@ghost
@Berryfier

After rpi-update with the tasklet there are now on average just 1% uvcvideo: USB isochronous frame lost (-63). The ones that are lost seem to be grouped. To help a decision on whether the bug issue can be closed here is a kern.log extract with the largest grouping found.
Mar 25 10:25:41 raspberrypi kernel: [ 734.924825] uvcvideo: Frame complete (EOF found).
Mar 25 10:25:41 raspberrypi kernel: [ 734.924895] uvcvideo: frame 3110 stats: 16/258/533 packets, 1/11/533 pts (early initial), 532/533 scr, last pts/stc/sof 3393711660/3396838904/1177
Mar 25 10:25:41 raspberrypi kernel: [ 734.925043] uvcvideo: UVC Camera (046d:0991): PTS 3393711660 y 3337.238159 SOF 3337.238159 (x1 2149152577 x2 2150640899 y1 220987392 y2 223019008 SOF offset 177)
Mar 25 10:25:41 raspberrypi kernel: [ 734.925084] uvcvideo: UVC Camera (046d:0991): SOF 3337.238159 y 1000297238 ts 734.802418 buf ts 734.766231 (x1 217317376/9204/1324 x2 349569024/9430/1355 y1 1000000000 y2 1028242902)
Mar 25 10:25:41 raspberrypi kernel: [ 734.925663] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 734.926276] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 734.992755] uvcvideo: Frame complete (EOF found).
Mar 25 10:25:41 raspberrypi kernel: [ 734.992859] uvcvideo: frame 3111 stats: 16/259/533 packets, 1/12/533 pts (early initial), 532/533 scr, last pts/stc/sof 3396912178/3400037594/1244
Mar 25 10:25:41 raspberrypi kernel: [ 734.993045] uvcvideo: UVC Camera (046d:0991): PTS 3396912178 y 3403.901123 SOF 3403.901123 (x1 2149216765 x2 2150705084 y1 225443840 y2 227475456 SOF offset 177)
Mar 25 10:25:41 raspberrypi kernel: [ 734.993087] uvcvideo: UVC Camera (046d:0991): SOF 3403.901123 y 1007007491 ts 734.877129 buf ts 734.830356 (x1 219414528/9748/1392 x2 234160128/9973/1423 y1 1000000000 y2 1028204899)
Mar 25 10:25:41 raspberrypi kernel: [ 734.993661] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 734.994285] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 735.060755] uvcvideo: Frame complete (EOF found).
Mar 25 10:25:41 raspberrypi kernel: [ 735.060872] uvcvideo: frame 3112 stats: 17/261/534 packets, 1/12/534 pts (early initial), 533/534 scr, last pts/stc/sof 3400112696/3403242287/1310
Mar 25 10:25:41 raspberrypi kernel: [ 735.061114] uvcvideo: UVC Camera (046d:0991): PTS 3400112696 y 3470.564285 SOF 3470.564285 (x1 2149280951 x2 2150769273 y1 229900288 y2 231931904 SOF offset 177)
Mar 25 10:25:41 raspberrypi kernel: [ 735.061156] uvcvideo: UVC Camera (046d:0991): SOF 3470.564285 y 1011332920 ts 734.949460 buf ts 734.898298 (x1 221511680/10292/1460 x2 236322816/10518/1491 y1 1000000000 y2 1028280905)
Mar 25 10:25:41 raspberrypi kernel: [ 735.061742] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 735.062367] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 735.096988] uvcvideo: USB isochronous frame lost (-63).
Mar 25 10:25:41 raspberrypi kernel: [ 735.105238] uvcvideo: USB isochronous frame lost (-63).
Mar 25 10:25:41 raspberrypi kernel: [ 735.125121] uvcvideo: Frame complete (EOF found).
Mar 25 10:25:41 raspberrypi kernel: [ 735.125203] uvcvideo: frame 3113 stats: 16/255/529 packets, 1/11/529 pts (early initial), 528/529 scr, last pts/stc/sof 3403313213/3406440977/1377
Mar 25 10:25:41 raspberrypi kernel: [ 735.125382] uvcvideo: UVC Camera (046d:0991): PTS 3403313213 y 3537.227355 SOF 3537.227355 (x1 2149153096 x2 2150641418 y1 234094592 y2 236126208 SOF offset 177)
Mar 25 10:25:41 raspberrypi kernel: [ 735.125424] uvcvideo: UVC Camera (046d:0991): SOF 5585.227355 y 1027373519 ts 735.029690 buf ts 734.966316 (x1 238354432/10805/1524 x2 370671616/11032/1555 y1 1000000000 y2 1028367909)
Mar 25 10:25:41 raspberrypi kernel: [ 735.126026] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 735.126649] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 735.137199] uvcvideo: USB isochronous frame lost (-63).
Mar 25 10:25:41 raspberrypi kernel: [ 735.145394] uvcvideo: USB isochronous frame lost (-63).
Mar 25 10:25:41 raspberrypi kernel: [ 735.193280] uvcvideo: Frame complete (EOF found).
Mar 25 10:25:41 raspberrypi kernel: [ 735.193384] uvcvideo: frame 3114 stats: 16/256/529 packets, 1/12/529 pts (early initial), 528/529 scr, last pts/stc/sof 3406513731/3409639666/1444
Mar 25 10:25:41 raspberrypi kernel: [ 735.193560] uvcvideo: UVC Camera (046d:0991): PTS 3406513731 y 3603.890411 SOF 3603.890411 (x1 2149265293 x2 2150753615 y1 238616576 y2 240648192 SOF offset 177)
Mar 25 10:25:41 raspberrypi kernel: [ 735.193602] uvcvideo: UVC Camera (046d:0991): SOF 5651.890411 y 1027654593 ts 735.098383 buf ts 735.030677 (x1 240648192/11352/1593 x2 372899840/11578/1624 y1 1000000000 y2 1028186898)
Mar 25 10:25:41 raspberrypi kernel: [ 735.194183] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 735.196742] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 735.197408] uvcvideo: USB isochronous frame lost (-63).
Mar 25 10:25:41 raspberrypi kernel: [ 735.257501] uvcvideo: Frame complete (EOF found).
Mar 25 10:25:41 raspberrypi kernel: [ 735.257577] uvcvideo: frame 3115 stats: 17/262/531 packets, 1/12/531 pts (early initial), 530/531 scr, last pts/stc/sof 3409714248/3412838357/1510
Mar 25 10:25:41 raspberrypi kernel: [ 735.257731] uvcvideo: UVC Camera (046d:0991): PTS 3409714248 y 3670.553359 SOF 3670.553359 (x1 2149137441 x2 2150625760 y1 242810880 y2 244842496 SOF offset 177)
Mar 25 10:25:41 raspberrypi kernel: [ 735.257771] uvcvideo: UVC Camera (046d:0991): SOF 3670.553359 y 999965765 ts 735.134794 buf ts 735.098839 (x1 240713728/11865/1657 x2 372965376/12091/1688 y1 1000000000 y2 1028236901)
Mar 25 10:25:41 raspberrypi kernel: [ 735.258376] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 735.258957] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 735.325442] uvcvideo: Frame complete (EOF found).
Mar 25 10:25:41 raspberrypi kernel: [ 735.325543] uvcvideo: frame 3116 stats: 17/264/534 packets, 1/12/534 pts (early initial), 533/534 scr, last pts/stc/sof 3412914766/3416043049/1577
Mar 25 10:25:41 raspberrypi kernel: [ 735.325713] uvcvideo: UVC Camera (046d:0991): PTS 3412914766 y 3737.216476 SOF 3737.216476 (x1 2149201627 x2 2150689948 y1 247267328 y2 249298944 SOF offset 177)
Mar 25 10:25:41 raspberrypi kernel: [ 735.325755] uvcvideo: UVC Camera (046d:0991): SOF 3737.216476 y 1004024336 ts 735.206848 buf ts 735.163060 (x1 242810880/12409/1725 x2 257622016/12635/1756 y1 1000000000 y2 1028230900)
Mar 25 10:25:41 raspberrypi kernel: [ 735.326330] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 735.326944] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
Mar 25 10:25:41 raspberrypi kernel: [ 735.393416] uvcvideo: Frame complete (EOF found).

@P33M
Owner

@Berryfier - what are you doing with the webcam output - saving to the SD card? Are you also in LXDE or just terminal mode?

I have noticed that other interrupt sources, if active, can cause dropped isoc packets. I get marginally fewer lost isoc packets if saving to a USB pendrive than the SD card.

@Berryfier

@P33M. I was using mjpg-streamer 960x720 10fps, displaying pictures with omxplayer, and all done on the pi in terminal mode (using HDMI, USB keyboard and mouse, and two terminals F1 and F2 ). An ethernet wired network is connected, but I wasn't using the pi for anything else. Maybe the pi's own housekeeping activity is sufficient to cause these now rare dropped isoc packets. As regards picture flow, I don't see any further improvement since the nodrop tweak, which I still have in place. The noticeable difference is the elimination of most 'frame lost' messages from the log.

@Berryfier

@P33M BTW, I would also say that later on, when using guvcview in the LXDE, I noticed that CPU indicator was lower than before for the various frame rates and picture sizes, and that higher frame rates were achieved as the CPU maxed out.

@ghost

OK. I tested the latest changes. I installed everything according the instructions (last time I forgot the files from firmware to put into /boot directory.
This time, the progress is much better.
Now, the HD3000 webcam works with no problem, even streaming over ethernet at 1280x720 ~2-3fps (quite impressive).
On 640x360 it gives more than 5fps, still sufficient (although there is 3-4 seconds delay).
The (until now) buggy VX-700 webcam works too!!! No errors in log, still works for 5-6 minutes (not enough time to test this minute, I'll test this evening. Anyhow, 6 minutes with no errors is a clean record.
The mjpg_streamer takes aprox. 3% of CPU no matter what resolution/framerate I select, which seems reasonable, as the camera is sending encoded mjpeg stream directly over the network and the software is not doing any calculations.

Congratulations on the fix, btw.

@ghost

Oh, one more significant improvement - until now, the HD3000 did have color artifacts all over bottom half of the picture. This is also fixed!
hd3000

@P33M
Owner

While much improved, the story with 2 webcams at once is a bit different, especially with large transfer sizes (used with uncompressed video streams).

The core USB controller will "schedule" each host channel's access to the bus during a microframe. Most of the time the transactions are bunched up toward the start of the microframe (and successful) but for some reason sometimes they are pushed to start in the latter half. This effect is exacerbated with more HCs enabled/demanding bus time.

Even with the tasklet patch, the dwc_otg irq handler still takes a good 15-20uS on a xfercomp interrupt which has consequences for the next HC assigned an isoc transaction further along in the microframe - by the time the ARM has finished with the first transaction, the microframe has already overrun causing a packet drop.

Suggested mitigations are:-

  • Use lower resolutions on uncompressed streams
  • Force capture programs to use compressed streams (mjpg or h264)

Reducing the packet size appears to drastically reduce the chance of an overrun error occuring. I've managed to get 3 simultaneous streams from 3 webcams with
480x360 MJPG
352x288 YUYV
352x288 YUYV
and only a small amount of garbling on webcam 2, but with 2 @ 640x480 YUYV it ends up with one webcam being nearly unusable.

@Rayn0r

Using the patched kernel under https://github.com/P33M/linux with uvccapture on my Raspberry Pi, now delivers un-garbled images at 1920x1080 very quickly. For me this patch fixed the webcam related issues I had before.

@popcornmix
Owner

@Rayn0r
Is that any different to runnning the kernel you get from rpi-update? I believe that has all P33M's fixes in.

@Rayn0r

@popcornmix
Judging from your comment, I assume there is a difference between running "apt-get update/upgrade" and "rpi-update". If so, I have not upgraded to the most recent kernel on my device so far. All I did was cross-compile the above mentioned kernel-repository and copy the result to my Raspberry.
Looking at the commits for both repos, I'd say the fix is contained in both of them.

@hoeken

i just wanted to chime in and say this fix is awesome. completely fixed my USB webcam issues!

webcam-corrupted
webcam

@ssvb ssvb referenced this issue from a commit in ssvb/linux-rpi
Asias He virtio-blk: Use block layer provided spinlock
Block layer will allocate a spinlock for the queue if the driver does
not provide one in blk_init_queue().

The reason to use the internal spinlock is that blk_cleanup_queue() will
switch to use the internal spinlock in the cleanup code path.

        if (q->queue_lock != &q->__queue_lock)
                q->queue_lock = &q->__queue_lock;

However, processes which are in D state might have taken the driver
provided spinlock, when the processes wake up, they would release the
block provided spinlock.

=====================================
[ BUG: bad unlock balance detected! ]
3.4.0-rc7+ #238 Not tainted
-------------------------------------
fio/3587 is trying to release lock (&(&q->__queue_lock)->rlock) at:
[<ffffffff813274d2>] blk_queue_bio+0x2a2/0x380
but there are no more locks to release!

other info that might help us debug this:
1 lock held by fio/3587:
 #0:  (&(&vblk->lock)->rlock){......}, at:
[<ffffffff8132661a>] get_request_wait+0x19a/0x250

Other drivers use block layer provided spinlock as well, e.g. SCSI.

Switching to the block layer provided spinlock saves a bit of memory and
does not increase lock contention. Performance test shows no real
difference is observed before and after this patch.

Changes in v2: Improve commit log as Michael suggested.

Cc: virtualization@lists.linux-foundation.org
Cc: kvm@vger.kernel.org
Cc: stable@kernel.org
Signed-off-by: Asias He <asias@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2c95a32
@P33M P33M closed this
@schlalek schlalek referenced this issue from a commit in schlalek/rpi-bluetooth
@borkmann borkmann test_bpf: add tests related to BPF_MAXINSNS
Couple of torture test cases related to the bug fixed in 0b59d88
("ARM: net: delegate filter to kernel interpreter when imm_offset()
return value can't fit into 12bits.").

I've added a helper to allocate and fill the insn space. Output on
x86_64 from my laptop:

test_bpf: #233 BPF_MAXINSNS: Maximum possible literals jited:0 7 PASS
test_bpf: #234 BPF_MAXINSNS: Single literal jited:0 8 PASS
test_bpf: #235 BPF_MAXINSNS: Run/add until end jited:0 11553 PASS
test_bpf: #236 BPF_MAXINSNS: Too many instructions PASS
test_bpf: #237 BPF_MAXINSNS: Very long jump jited:0 9 PASS
test_bpf: #238 BPF_MAXINSNS: Ctx heavy transformations jited:0 20329 20398 PASS
test_bpf: #239 BPF_MAXINSNS: Call heavy transformations jited:0 32178 32475 PASS
test_bpf: #240 BPF_MAXINSNS: Jump heavy test jited:0 10518 PASS

test_bpf: #233 BPF_MAXINSNS: Maximum possible literals jited:1 4 PASS
test_bpf: #234 BPF_MAXINSNS: Single literal jited:1 4 PASS
test_bpf: #235 BPF_MAXINSNS: Run/add until end jited:1 1625 PASS
test_bpf: #236 BPF_MAXINSNS: Too many instructions PASS
test_bpf: #237 BPF_MAXINSNS: Very long jump jited:1 8 PASS
test_bpf: #238 BPF_MAXINSNS: Ctx heavy transformations jited:1 3301 3174 PASS
test_bpf: #239 BPF_MAXINSNS: Call heavy transformations jited:1 24107 23491 PASS
test_bpf: #240 BPF_MAXINSNS: Jump heavy test jited:1 8651 PASS

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Nicolas Schichan <nschichan@freebox.fr>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
a4afd37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.