Bug 1103799

Description of problem:
May 29 22:15:11 bp6375 kernel: [138231.813377] WARNING: CPU: 0 PID: 16621 at drivers/usb/core/urb.c:476 usb_submit_urb+0x28d/0x5c0()
May 29 22:15:11 bp6375 kernel: [138231.813379] usb 1-1.1: BOGUS urb flags, 1 --> 0
May 29 22:15:11 bp6375 kernel: [138231.813380] Modules linked in: tcp_lp fuse bnep bluetooth 6lowpan_iphc xt_nat xt_mark nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle vboxpci(OF) ip6table_security vboxnetadp(OF) vboxnetflt(OF) ip6table_raw vboxdrv(OF) ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw snd_hda_codec_hdmi iTCO_wdt snd_hda_codec_via snd_hda_codec_generic eeepc_wmi asus_wmi sparse_keymap rfkill iTCO_vendor_support snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal coretemp snd_seq ppdev snd_seq_device kvm_intel kvm crct10dif_pclmul snd_pcm snd_timer crc32_pclmul crc32c_intel snd ghash_clmulni_intel e1000e ptp pps_core tpm_infineon tpm_tis usblp lpc_ich mfd_core mei_me mei wmi serio_raw joydev i2c_i801 tpm soundcore parport_pc parport shpchp microcode uinput binfmt_misc i915 i2c_algo_bit drm_kms_helper ata_generic drm pata_acpi i2c_core video loop
May 29 22:15:11 bp6375 kernel: [138231.813420] CPU: 0 PID: 16621 Comm: EMT Tainted: GF       W  O 3.14.4-100.fc19.x86_64 #1
May 29 22:15:11 bp6375 kernel: [138231.813421] Hardware name: ASUSTeK Computer INC. BM6875_BM6675_BP6375/BM6875_BM6675_BP6375, BIOS 0806 07/26/2013
May 29 22:15:11 bp6375 kernel: [138231.813422]  0000000000000000 000000002f980c8f ffff8801f111fca8 ffffffff816ef1d2
May 29 22:15:11 bp6375 kernel: [138231.813424]  ffff8801f111fcf0 ffff8801f111fce0 ffffffff8108a1bd ffff880213545f00
May 29 22:15:11 bp6375 kernel: [138231.813426]  ffff88020a26b000 0000000000000002 0000000000000001 0000000000000020
May 29 22:15:11 bp6375 kernel: [138231.813428] Call Trace:
May 29 22:15:11 bp6375 kernel: [138231.813432]  [<ffffffff816ef1d2>] dump_stack+0x45/0x56
May 29 22:15:11 bp6375 kernel: [138231.813436]  [<ffffffff8108a1bd>] warn_slowpath_common+0x7d/0xa0
May 29 22:15:11 bp6375 kernel: [138231.813438]  [<ffffffff8108a23c>] warn_slowpath_fmt+0x5c/0x80
May 29 22:15:11 bp6375 kernel: [138231.813440]  [<ffffffff814e418d>] usb_submit_urb+0x28d/0x5c0
May 29 22:15:11 bp6375 kernel: [138231.813441]  [<ffffffff814f024d>] proc_do_submiturb+0xc6d/0xcc0
May 29 22:15:11 bp6375 kernel: [138231.813446]  [<ffffffff811cbe85>] ? __kmalloc+0x55/0x240
May 29 22:15:11 bp6375 kernel: [138231.813454]  [<ffffffffa040be8d>] ? rtR0MemAllocEx+0x19d/0x280 [vboxdrv]
May 29 22:15:11 bp6375 kernel: [138231.813456]  [<ffffffff814f074f>] usbdev_do_ioctl+0x4af/0x1080
May 29 22:15:11 bp6375 kernel: [138231.813461]  [<ffffffffa040bfca>] ? rtR0MemFree+0x5a/0x70 [vboxdrv]
May 29 22:15:11 bp6375 kernel: [138231.813463]  [<ffffffff814f134e>] usbdev_ioctl+0xe/0x20
May 29 22:15:11 bp6375 kernel: [138231.813465]  [<ffffffff811fcc30>] do_vfs_ioctl+0x2e0/0x4a0
May 29 22:15:11 bp6375 kernel: [138231.813467]  [<ffffffff811fce71>] SyS_ioctl+0x81/0xa0
May 29 22:15:11 bp6375 kernel: [138231.813469]  [<ffffffff81121c76>] ? __audit_syscall_exit+0x1f6/0x2a0
May 29 22:15:11 bp6375 kernel: [138231.813472]  [<ffffffff816ff569>] system_call_fastpath+0x16/0x1b
May 29 22:15:11 bp6375 kernel: [138231.813473] ---[ end trace a78e2c2aa1a60a06 ]---
May 29 22:15:11 bp6375 kernel: [138231.819333] ------------[ cut here ]------------




Version-Release number of selected component (if applicable):
These message first observed with kernel 3.14.4-100.fc19.x86_64 .  They do not occur when booting with my previous kernel 3.13.11-100.fc19.x86_64 .

At this point, I am only able to create the problem when running a Windows virtual machine with support for an Epson V500 scanner under VirtualBox, but it was the introduction of the new kernel that started the symptoms.  Same problem occurs with both VirtualBox 4.3.12 r93733 and VirtualBox 4.3.6 r91406, both of which work without error messages on the previous kernel version.  Problem also appears to be independent of which Windows Operating System is used in the virtual machine, as it occurs with multiple versions of Windows (Win2K, XP, Win7) when running the latest Epson V500 support.


How reproducible: 100%


Steps to Reproduce:
1.  Connect Epson V500 USB scanner to Fedora system and power up
2.  Start a VirtualBox Windows VM with V500 scanner support installed
3.  As soon as Windows VM starts to initialize, error messages begin in the message log and continue until scanner is powered down or the VM is shut down.

Actual results:
The error sequence in message log occurs several times per second (different CPU ordinals) for as long as VirtualBox Windows VM with driver support for Epson V500 scanner (idVendor=04b8, idProduct=0130) is active and scanner is powered up and connected to the VM.   The Scan Application in the VM still appears to function correctly, but Fedora message log fills up with repeated WARNING messages whether scanner is actively being used or not and independent of whether the actual scanning application is active, consuming resources.


Expected results:
Function With no WARNING messages filling up message log.


Additional info:
This is a VirtualBox Virtual Machine and Windows application that has been functional for several years under multiple Fedora releases and multiple VirtualBox releases. 

There is a native Linux iscan application that does work with the V500 scanner without the "BOGUS urb flag" messages, but this lacks many support features of the Windows-only Epson Scan utility and device driver, only available under Linux via a Windows VM.

Unclear whether this is a flat-out kernel bug, or some VirtualBox/kernel compatibility issue, or something unexpected that the Windows device driver is doing that is producing an unusual USB communications sequence that was thought impossible by writers of Linux USB support, but kernel 3.14.4-100 is definitely causing previously functioning USB stuff under a virtual machine to now fill up the message log with errors.