Kernel Oops when trying to record from USB Audio Mic (Akiro Kinobo) #588
Comments
|
Can you post a full Is this reproducible if you e.g. change the arecord parameters (channels, bitrate)? |
Seems to happen with any parameters. |
|
Do you have the ability to connect to the GPIO serial port? I.e. PC -> USB/3.3v serial dongle -> GPIO? |
|
Yes, I have USB TTL cable. |
|
Good. For some background, there are very few situations that can hit that BUG(). One possibility is that your device is babbling and continuously transmitting data, but I need to get a debug kernel to you to verify this. |
|
OK, here is the text output from the serial console: |
|
After doing an rpi-update I'm getting the exact same problem. I'm on the same kernel (3.12.18) after being on stock 3.10 |
|
Current workaround is to downgrade the firmware using
|
|
That worked. But now I'm back to my buzzing USB audio recording, which works if I set dwc_otg.speed=1 but that kills my USB bar-code scanner....sigh... |
|
Well, the new firmware is not guaranteed to fix the buzzing. |
|
I realise this, I was just being optimistic. Thanks for lodging this bug and pointing me to that commit. |
|
@pierrep please post a full lsusb -v for the device. As a workaround, can you try adding the following in /boot/cmdline.txt: |
|
@P33M I tried the dwc_otg.fiq_fsm_enable=0 workaround and it worked! Audio is much improved. Thanks! here is the usb audio lsusb output: |
|
|
|
Also, just pointing out that audio recording was better with dwc_otg.speed=1, currently the audio recording is a little scratchy and has a little bit of weird modulation in it, but it's massively improved from the prior output. I have a C-Media USB audio card as well as a Tenx one on hand. Haven't tried these out yet but will give them a go. |
|
It's overwhelmingly likely that this JMTek chipset is an audio chipset that does something "bad". It's not one I've seen in the wild before. Can you post a photo of the device with this chipset? Manufacturer/model number label if possible. |
|
"Akiro" by Kinobo: http://www.amazon.com/USB-2-0-Microphone-Recognition-Software/dp/B008CNZOJY . Works perfectly with Windows and Intel NUC running Ubuntu 14.04, but not on RPi. |
|
I've ordered one. Should be here tomorrow. |
|
Pretty nondescript: |
|
Generic DAC is generic - which means that it used the chipset du jour. The Akiro device is much more likely to have a fixed design. |
|
I can reproduce the crash. I was right. The device returns 138 bytes on an endpoint with wMaxPacketSize = 100 bytes. |
|
Great news. Hope you'll be able to workaround this issue as the device works fine on other systems. |
|
No other systems use buggy OTG hardware in host mode with the expectation that it be used as a desktop PC. |
|
Oh, I see that there is a hardware limitation of the OTG mode. Does it mean that this device will never work properly with RPi? |
|
No, because I've fixed the bug. The otg core was (somewhat correctly) raising a device babble interrupt which wasn't being handled - despite the complete-split packet being smaller that the maximum isochronous packet size that can be returned from the hub. It appears that the host channel internal transfer length counter is also used to determine babble. |
|
Cool! How's the audio quality after fixing the bug? |
|
No idea, my singing voice is terrible. Ambient audio is being recorded fine, though. |
|
I see your bugfix commit in the UPDATE: compiled and installed your kernel branch with the patch. It works, no more distortion like with older firmwares and no crash like with the latest official firmware. Thanks a lot. Precompiled kernel/modules for those who want to try it. |
|
Can you cherry pick P33M@06ee59b in the next firmware build. |
popcornmix
pushed a commit
to raspberrypi/firmware
that referenced
this issue
May 16, 2014
See: raspberrypi/linux#588 kernel: Perform I2C combined transactions when possible See: raspberrypi/linux#318 kernel: V4L2: Increase the MMAL timeout to 3sec See: raspberrypi/linux#592 kernel: i2c-bcm2708: fixed baudrate See: raspberrypi/linux#592 firmware: Avoid calling hdcp_shutdown() when hotplug deasserted See: http://forum.stmlabs.com/showthread.php?tid=11003&pid=101848#pid101848 firmware: hello_fft: Update readme to mention use with GL See: http://www.raspberrypi.org/forums/viewtopic.php?f=68&t=76189 firmware: Clear unused pixels in the subsample image in H264 codec See: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=76845&p=551515#p551515
popcornmix
pushed a commit
to Hexxeh/rpi-firmware
that referenced
this issue
May 16, 2014
See: raspberrypi/linux#588 kernel: Perform I2C combined transactions when possible See: raspberrypi/linux#318 kernel: V4L2: Increase the MMAL timeout to 3sec See: raspberrypi/linux#592 kernel: i2c-bcm2708: fixed baudrate See: raspberrypi/linux#592 firmware: Avoid calling hdcp_shutdown() when hotplug deasserted See: http://forum.stmlabs.com/showthread.php?tid=11003&pid=101848#pid101848 firmware: hello_fft: Update readme to mention use with GL See: http://www.raspberrypi.org/forums/viewtopic.php?f=68&t=76189 firmware: Clear unused pixels in the subsample image in H264 codec See: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=76845&p=551515#p551515
|
The fix is in latest firmware. @CrazyCoder please rpi-update and test. |
|
@popcornmix updated to |
|
@popcornmix seems to work after checking SD from another system and reinstalling the firmware, not sure what it was. |
|
Okay to close? |
|
@popcornmix Yes, closing.Thank you and @P33M for the quick fix. |
anholt
pushed a commit
to anholt/linux
that referenced
this issue
Jul 18, 2015
[ 1572.417121] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1572.421010] IP: [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915] [ 1572.424970] PGD 1766a3067 PUD 1767a2067 PMD 0 [ 1572.428892] Oops: 0000 [#1] SMP [ 1572.432787] Modules linked in: ipv6 dm_mod iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore serio_raw pcspkr lpc_ich i2c_i801 mfd_core battery ac acpi_cpufreq i915 button video drm_kms_helper drm [ 1572.441720] CPU: 2 PID: 18853 Comm: kworker/u8:0 Not tainted 4.0.0_kcloud_3f0360_20150429+ raspberrypi#588 [ 1572.446298] Workqueue: i915 i915_gem_retire_work_handler [i915] [ 1572.450876] task: ffff880002f428f0 ti: ffff880035724000 task.ti: ffff880035724000 [ 1572.455557] RIP: 0010:[<ffffffffa00b2514>] [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915] [ 1572.460423] RSP: 0018:ffff880035727ce8 EFLAGS: 00010286 [ 1572.465262] RAX: ffff880073f1643c RBX: ffff880002da9058 RCX: ffff880073e5db40 [ 1572.470179] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880035727ce8 [ 1572.475107] RBP: ffff88007bb11a00 R08: 0000000000000000 R09: 0000000000000000 [ 1572.480034] R10: 0000000000362200 R11: 0000000000000008 R12: 0000000000000000 [ 1572.484952] R13: ffff880035727d78 R14: ffff880002dc1c98 R15: ffff880002dc1dc8 [ 1572.489886] FS: 0000000000000000(0000) GS:ffff88017fd00000(0000) knlGS:0000000000000000 [ 1572.494883] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1572.499859] CR2: 0000000000000000 CR3: 000000017572a000 CR4: 00000000001006e0 [ 1572.504842] Stack: [ 1572.509834] ffff88017b0090c0 ffff880073f16438 ffff880002da9058 ffff880073f1643c [ 1572.514904] 0000000000000246 ffff880100000000 ffff88007bb11a00 ffff880002ddeb10 [ 1572.519985] ffff8801759f79c0 ffffffffa0092ff0 0000000000000000 ffff88007bb11a00 [ 1572.525049] Call Trace: [ 1572.530093] [<ffffffffa0092ff0>] ? i915_gem_context_free+0xa8/0xc1 [i915] [ 1572.535227] [<ffffffffa009b969>] ? i915_gem_request_free+0x4e/0x50 [i915] [ 1572.540347] [<ffffffffa00b5533>] ? intel_execlists_retire_requests+0x14c/0x159 [i915] [ 1572.545500] [<ffffffffa009d9ea>] ? i915_gem_retire_requests+0x9d/0xeb [i915] [ 1572.550664] [<ffffffffa009dd8c>] ? i915_gem_retire_work_handler+0x4c/0x61 [i915] [ 1572.555825] [<ffffffff8104ca7f>] ? process_one_work+0x1b2/0x31d [ 1572.560951] [<ffffffff8104d278>] ? worker_thread+0x24d/0x339 [ 1572.566033] [<ffffffff8104d02b>] ? cancel_delayed_work_sync+0xa/0xa [ 1572.571140] [<ffffffff81050b25>] ? kthread+0xce/0xd6 [ 1572.576191] [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162 [ 1572.581228] [<ffffffff8179b3c8>] ? ret_from_fork+0x58/0x90 [ 1572.586259] [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162 [ 1572.591318] Code: de 48 89 e7 e8 09 4d 00 e1 48 85 c0 74 27 48 89 68 10 48 8b 55 38 48 89 e7 48 89 50 18 48 8b 55 10 48 8b 12 48 8b 12 48 8b 52 38 <8b> 12 89 50 08 e8 95 4d 00 e1 48 83 c4 30 5b 5d 41 5c c3 41 55 [ 1572.596981] RIP [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915] [ 1572.602464] RSP <ffff880035727ce8> [ 1572.607911] CR2: 0000000000000000 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90112#c23 Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
neuschaefer
pushed a commit
to neuschaefer/raspi-binary-firmware
that referenced
this issue
Feb 27, 2017
See: raspberrypi/linux#588 kernel: Perform I2C combined transactions when possible See: raspberrypi/linux#318 kernel: V4L2: Increase the MMAL timeout to 3sec See: raspberrypi/linux#592 kernel: i2c-bcm2708: fixed baudrate See: raspberrypi/linux#592 firmware: Avoid calling hdcp_shutdown() when hotplug deasserted See: http://forum.stmlabs.com/showthread.php?tid=11003&pid=101848#pid101848 firmware: hello_fft: Update readme to mention use with GL See: http://www.raspberrypi.org/forums/viewtopic.php?f=68&t=76189 firmware: Clear unused pixels in the subsample image in H264 codec See: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=76845&p=551515#p551515
popcornmix
pushed a commit
that referenced
this issue
Jan 22, 2018
When a tail call fails, it is documented that the tail call should continue execution at the following instruction. An example tail call sequence is: 12: (85) call bpf_tail_call#12 13: (b7) r0 = 0 14: (95) exit The ARM assembler for the tail call in this case ends up branching to instruction 14 instead of instruction 13, resulting in the BPF filter returning a non-zero value: 178: ldr r8, [sp, #588] ; insn 12 17c: ldr r6, [r8, r6] 180: ldr r8, [sp, #580] 184: cmp r8, r6 188: bcs 0x1e8 18c: ldr r6, [sp, #524] 190: ldr r7, [sp, #528] 194: cmp r7, #0 198: cmpeq r6, #32 19c: bhi 0x1e8 1a0: adds r6, r6, #1 1a4: adc r7, r7, #0 1a8: str r6, [sp, #524] 1ac: str r7, [sp, #528] 1b0: mov r6, #104 1b4: ldr r8, [sp, #588] 1b8: add r6, r8, r6 1bc: ldr r8, [sp, #580] 1c0: lsl r7, r8, #2 1c4: ldr r6, [r6, r7] 1c8: cmp r6, #0 1cc: beq 0x1e8 1d0: mov r8, #32 1d4: ldr r6, [r6, r8] 1d8: add r6, r6, #44 1dc: bx r6 1e0: mov r0, #0 ; insn 13 1e4: mov r1, #0 1e8: add sp, sp, #596 ; insn 14 1ec: pop {r4, r5, r6, r7, r8, sl, pc} For other sequences, the tail call could end up branching midway through the following BPF instructions, or maybe off the end of the function, leading to unknown behaviours. Fixes: 39c13c2 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Jan 31, 2018
commit f4483f2 upstream. When a tail call fails, it is documented that the tail call should continue execution at the following instruction. An example tail call sequence is: 12: (85) call bpf_tail_call#12 13: (b7) r0 = 0 14: (95) exit The ARM assembler for the tail call in this case ends up branching to instruction 14 instead of instruction 13, resulting in the BPF filter returning a non-zero value: 178: ldr r8, [sp, #588] ; insn 12 17c: ldr r6, [r8, r6] 180: ldr r8, [sp, #580] 184: cmp r8, r6 188: bcs 0x1e8 18c: ldr r6, [sp, #524] 190: ldr r7, [sp, #528] 194: cmp r7, #0 198: cmpeq r6, #32 19c: bhi 0x1e8 1a0: adds r6, r6, #1 1a4: adc r7, r7, #0 1a8: str r6, [sp, #524] 1ac: str r7, [sp, #528] 1b0: mov r6, #104 1b4: ldr r8, [sp, #588] 1b8: add r6, r8, r6 1bc: ldr r8, [sp, #580] 1c0: lsl r7, r8, #2 1c4: ldr r6, [r6, r7] 1c8: cmp r6, #0 1cc: beq 0x1e8 1d0: mov r8, #32 1d4: ldr r6, [r6, r8] 1d8: add r6, r6, #44 1dc: bx r6 1e0: mov r0, #0 ; insn 13 1e4: mov r1, #0 1e8: add sp, sp, #596 ; insn 14 1ec: pop {r4, r5, r6, r7, r8, sl, pc} For other sequences, the tail call could end up branching midway through the following BPF instructions, or maybe off the end of the function, leading to unknown behaviours. Fixes: 39c13c2 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This started to occur after updating to firmware with 3.12.18 kernel, older firmware doesn't have this problem.
Bus 001 Device 007: ID 0c76:160a JMTek, LLC.Issue occurs after
arecord -f cd -c 1 -D hw:1,0 test.wavThe text was updated successfully, but these errors were encountered: