Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Message too long USB OTG #246

Open
kk90 opened this issue Jan 14, 2016 · 4 comments
Open

Message too long USB OTG #246

kk90 opened this issue Jan 14, 2016 · 4 comments

Comments

@kk90
Copy link

kk90 commented Jan 14, 2016

Hello

I have same issue as mentioned in #159 it is marked as resolved but I have same problem with most recent version.

command:

ffmpeg -f video4linux2  -video_size 800x600 -i /dev/video0 -vframes 1 test.jpeg

result it this error:

ioctl(VIDIOC_STREAMON): Message too long             
/dev/video0: Message too long

and following stack trace:

WRN:L2841(drivers/usb/sunxi_usb/hcd/core/sw_hcd_host.c):[ 8863.335738] WRN:L2841(drivers/usb/sunxi_usb/hcd/core/sw_hcd_host.c):ERR: sw_hcd_urb_enqueue, ep packet is too big, maxpacket = 4992
ERR: sw_hcd_urb_enqueue, ep packet is too big, maxpacket = 4992
<3>uvcvideo: Failed to submit URB 0 (-90).
[ 8863.357971] uvcvideo: Failed to submit URB 0 (-90).
[sw_hcd]: sw_hcd_h_disable, epnum = 81
[ 8863.366858] [sw_hcd]: sw_hcd_h_disable, epnum = 81
[sw_hcd]: sw_hcd_urb_dequeue, sw_hcd(df8dd8f0, 0x0, 0x3f),urb(dfa04e80, 16, 0), dev = 2, ep = 7, dir = in
[ 8863.455833] [sw_hcd]: sw_hcd_urb_dequeue, sw_hcd(df8dd8f0, 0x0, 0x3f),urb(dfa04e80, 16, 0), dev = 2, ep = 7, dir = in
WRN:L3147(drivers/usb/sunxi_usb/hcd/core/sw_hcd_host.c):[ 8863.471319] WRN:L3147(drivers/usb/sunxi_usb/hcd/core/sw_hcd_host.c):ERR: not support type(3)
ERR: not support type(3)
sw_hcd_cleanup_urb: qh(0xdf3df300,0x7,0x3), urb(0xdfa04e80,16,0), ep(0xdf8dd9b8,2,0xdf3df300,0x  (null))
[ 8863.491221] sw_hcd_cleanup_urb: qh(0xdf3df300,0x7,0x3), urb(0xdfa04e80,16,0), ep(0xdf8dd9b8,2,0xdf3df300,0x  (null))
@LCS1969
Copy link

LCS1969 commented Jun 15, 2017

All,
I go the same error message while plug-in USB UVC camera into OTG port. The message is as below
<4>[13855.768643] [sw_hcd0]: sunxi_usb_host0_enable start <4>[13855.781806] [sw_hcd0]: open_usb_clock <4>[13855.797029] [sw_hcd0]: sunxi_usb_host0_enable end <6>[13856.400255] usb 3-1: new high-speed USB device number 12 using sunxi_hcd_host0 <4>[13931.313736] WRN:L2494(drivers/usb/sunxi_usb/hcd/core/sunxi_hcd_host.c):ERR: sunxi_hcd_urb_enqueue, ep packet is too big, maxpacket = 5120 <7>[13931.334599] usb 3-1: usbfs: usb_submit_urb returned -90

Any suggestion here? To update the firmware or is this HW bug?

Regards

@kk90
Copy link
Author

kk90 commented Jun 17, 2017 •
edited

Hi this is a known issue in linux-sunxi kernel, I suggest to migrate to mainline kernel. You can try to use Armbian built tool https://docs.armbian.com/Developer-Guide_Build-Preparation/ to have 4.x kernel for Allwinner SoCs (this worked for me)

@LCS1969
Copy link

LCS1969 commented Jul 4, 2017

Dear KK90,
thank you for your message. However, the link is not available anymore, could you suggest the correct link for me again?

@kk90
Copy link
Author

kk90 commented Jul 4, 2017

Please check the link again I edited post

amery pushed a commit that referenced this issue Sep 29, 2017
@fbq @bonzini
kvm/x86: Handle async PF in RCU read-side critical sections
b862789 
Sasha Levin reported a WARNING:

| WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329
| rcu_preempt_note_context_switch kernel/rcu/tree_plugin.h:329 [inline]
| WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329
| rcu_note_context_switch+0x16c/0x2210 kernel/rcu/tree.c:458
...
| CPU: 0 PID: 6974 Comm: syz-fuzzer Not tainted 4.13.0-next-20170908+ #246
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
| 1.10.1-1ubuntu1 04/01/2014
| Call Trace:
...
| RIP: 0010:rcu_preempt_note_context_switch kernel/rcu/tree_plugin.h:329 [inline]
| RIP: 0010:rcu_note_context_switch+0x16c/0x2210 kernel/rcu/tree.c:458
| RSP: 0018:ffff88003b2debc8 EFLAGS: 00010002
| RAX: 0000000000000001 RBX: 1ffff1000765bd85 RCX: 0000000000000000
| RDX: 1ffff100075d7882 RSI: ffffffffb5c7da20 RDI: ffff88003aebc410
| RBP: ffff88003b2def30 R08: dffffc0000000000 R09: 0000000000000001
| R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003b2def08
| R13: 0000000000000000 R14: ffff88003aebc040 R15: ffff88003aebc040
| __schedule+0x201/0x2240 kernel/sched/core.c:3292
| schedule+0x113/0x460 kernel/sched/core.c:3421
| kvm_async_pf_task_wait+0x43f/0x940 arch/x86/kernel/kvm.c:158
| do_async_page_fault+0x72/0x90 arch/x86/kernel/kvm.c:271
| async_page_fault+0x22/0x30 arch/x86/entry/entry_64.S:1069
| RIP: 0010:format_decode+0x240/0x830 lib/vsprintf.c:1996
| RSP: 0018:ffff88003b2df520 EFLAGS: 00010283
| RAX: 000000000000003f RBX: ffffffffb5d1e141 RCX: ffff88003b2df670
| RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffb5d1e140
| RBP: ffff88003b2df560 R08: dffffc0000000000 R09: 0000000000000000
| R10: ffff88003b2df718 R11: 0000000000000000 R12: ffff88003b2df5d8
| R13: 0000000000000064 R14: ffffffffb5d1e140 R15: 0000000000000000
| vsnprintf+0x173/0x1700 lib/vsprintf.c:2136
| sprintf+0xbe/0xf0 lib/vsprintf.c:2386
| proc_self_get_link+0xfb/0x1c0 fs/proc/self.c:23
| get_link fs/namei.c:1047 [inline]
| link_path_walk+0x1041/0x1490 fs/namei.c:2127
...

This happened when the host hit a page fault, and delivered it as in an
async page fault, while the guest was in an RCU read-side critical
section.  The guest then tries to reschedule in kvm_async_pf_task_wait(),
but rcu_preempt_note_context_switch() would treat the reschedule as a
sleep in RCU read-side critical section, which is not allowed (even in
preemptible RCU).  Thus the WARN.

To cure this, make kvm_async_pf_task_wait() go to the halt path if the
PF happens in a RCU read-side critical section.

Reported-by: Sasha Levin <levinsasha928@gmail.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
amery pushed a commit that referenced this issue Sep 13, 2018
@ummakynes
netfilter: conntrack: timeout interface depend on CONFIG_NF_CONNTRACK…
a874752 
…_TIMEOUT

Now that cttimeout support for nft_ct is in place, these should depend
on CONFIG_NF_CONNTRACK_TIMEOUT otherwise we can crash when dumping the
policy if this option is not enabled.

[   71.600121] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[...]
[   71.600141] CPU: 3 PID: 7612 Comm: nft Not tainted 4.18.0+ #246
[...]
[   71.600188] Call Trace:
[   71.600201]  ? nft_ct_timeout_obj_dump+0xc6/0xf0 [nft_ct]

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
@EliasKotlyar EliasKotlyar mentioned this issue Mar 16, 2019
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@LCS1969 @kk90