Epson V500 USB BOGUS urb flags Windows VM with kernel 3.14.4-100 f19

[jce_vb]

After install of Fedora f19 kernel 3.14.4-100.fc19.x86_64 in late May, a Windows 2000 virtual machine under VirtualBox 4.3.12 r93733 running support software for a USB Epson V500 scanner has started to get continuous (about 2 per second) kernel WARNING messages indicating a problem with "BOGUS urb flags" from usb_submit_urb: "WARNING: CPU: 0 PID: 16621 at drivers/usb/core/urb.c:476 usb_submit_urb+0x28d/0x5c0() ... BOGUS urb flags, 1 --> 0"

This happens as long as the VM is up and the V500 scanner is powered-up and connected to the VM once the USB has first been recognized by WIN2K and the device driver installed even when both WIN2K and the scanner are sitting idle (device driver dependency from a re-install of the software in a cloned machine). The original VM with the problem had been running for several years under different releases of Fedora and different releases of VirtualBox with no problem.

A 2nd machine running VirtualBox 4.3.6 r91406 shows the same problem with the new 3.14.4-100 kernel.

Temporarily reverting to my previous kernel 3.13.11-100.fc19.x86_64 causes the problem to disappear (for both of the previously mentioned VirtualBox releases).

I reported the problem to Fedora bugzilla, but since I can only recreate the problem using a VirtualBox VM, got predictable response that it is a problem with VirtualBox drivers even though a kernel change started the symptoms. Subsequent testing shows V500 scanner hardware works without any logged warnings, both from "iscan" native Linux scanner package and from a just-built Windows 2000 QEMU/KVM virtual machine running the same Windows software as on the VirtualBox Win2K VM. Circumstantial evidence would appear to point to some kind of VirtualBox incompatibility with the recent 3.14.4-100 kernel.

[jce_vb]

VBox log associated with problem

[jce_vb]

Fedora message.log subset with warning errors during same time period

[jce_vb]

I forgot to add that the scanner software under the WIN2K2 VM still appears to function and produce correct results despite all the errors recorded in the system message log while it and the scanner are up. But adding almost 500 MB in spurious messages to the system message log every 8 hours tends to consume a significant amount of resources and makes seeing anything else of interest in the message log difficult and time consuming.

[Ertan ERBEK]

I experince same problem with Realtek Wifi ethernet.

[Ertan ERBEK]

Log export like this,

Jun 10 15:29:19 homless kernel: WARNING: CPU: 2 PID: 25284 at drivers/usb/core/urb.c:476 usb_submit_urb+0x28d/0x5c0() Jun 10 15:29:19 homless kernel: usb 3-2.1: BOGUS urb flags, 1 --> 0 Jun 10 15:29:19 homless kernel: Modules linked in: rtl8187 eeprom_93cx6 ax88179_178a usbnet rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt vmnet(OF) parport_pc vmw_vsock_vmci_transport vsock vmw_vmci vmmon(OF) ccm nf_conntrack_tftp nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT bnep bluetooth 6lowpan_iphc 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 ip6table_security ip6table_raw 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 vboxpci(OF) vboxnetadp(OF) vboxnetflt(OF) vboxdrv(OF) ch341 ppdev parport fuse rtsx_pci_sdmmc rtsx_pci_ms mmc_core iTCO_wdt memstick iTCO_vendor_support bbswitch(OF) Jun 10 15:29:19 homless kernel: arc4 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media snd_hda_codec_hdmi x86_pkg_temp_thermal snd_hda_codec_via coretemp snd_hda_codec_generic kvm_intel ath9k ath9k_common kvm ath9k_hw crct10dif_pclmul crc32_pclmul snd_hda_intel crc32c_intel ath snd_hda_codec ghash_clmulni_intel mac80211 snd_hwdep snd_seq snd_seq_device microcode cfg80211 joydev snd_pcm serio_raw i2c_i801 rfkill rtsx_pci snd_timer r8169 lpc_ich snd mfd_core mii mei_me soundcore mei shpchp tpm_infineon tpm_tis tpm acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd sunrpc binfmt_misc mxm_wmi i915 i2c_algo_bit drm_kms_helper drm i2c_core wmi video [last unloaded: vmnet] Jun 10 15:29:19 homless kernel: CPU: 2 PID: 25284 Comm: EMT-1 Tainted: PF W O 3.14.6-200.fc20.x86_64 #1 Jun 10 15:29:19 homless kernel: Hardware name: CLEVO CO. W110ER /W110ER , BIOS 1.02.11 PM v3 07/01/20 Jun 10 15:29:19 homless kernel: 0000000000000000 00000000aa90e9e0 ffff8800a5975ca8 ffffffff816f0252 Jun 10 15:29:19 homless kernel: ffff8800a5975cf0 ffff8800a5975ce0 ffffffff8108a1cd ffff8803e140dcc0 Jun 10 15:29:19 homless kernel: ffff8800b8268000 0000000000000002 0000000000000001 0000000000000020 Jun 10 15:29:19 homless kernel: Call Trace: Jun 10 15:29:19 homless kernel: [<ffffffff816f0252>] dump_stack+0x45/0x56 Jun 10 15:29:19 homless kernel: [<ffffffff8108a1cd>] warn_slowpath_common+0x7d/0xa0 Jun 10 15:29:19 homless kernel: [<ffffffff8108a24c>] warn_slowpath_fmt+0x5c/0x80 Jun 10 15:29:19 homless kernel: [<ffffffff814e4c6d>] usb_submit_urb+0x28d/0x5c0 Jun 10 15:29:19 homless kernel: [<ffffffff814f0d2d>] proc_do_submiturb+0xc6d/0xcc0 Jun 10 15:29:19 homless kernel: [<ffffffff814f122f>] usbdev_do_ioctl+0x4af/0x1080 Jun 10 15:29:19 homless kernel: [<ffffffffa0566fca>] ? rtR0MemFree+0x5a/0x70 [vboxdrv] Jun 10 15:29:19 homless kernel: [<ffffffff814f1e2e>] usbdev_ioctl+0xe/0x20 Jun 10 15:29:19 homless kernel: [<ffffffff811fd050>] do_vfs_ioctl+0x2e0/0x4a0 Jun 10 15:29:19 homless kernel: [<ffffffff811fd291>] SyS_ioctl+0x81/0xa0 Jun 10 15:29:19 homless kernel: [<ffffffff81121e76>] ? audit_syscall_exit+0x1f6/0x2a0 Jun 10 15:29:19 homless kernel: [<ffffffff81700629>] system_call_fastpath+0x16/0x1b Jun 10 15:29:19 homless kernel: ---[ end trace 21b305f834140e34 ]--- Jun 10 15:29:19 homless kernel: xhci_hcd 0000:00:14.0: WARN Event TRB for slot 6 ep 2 with no TDs queued? Jun 10 15:29:19 homless kernel: ------------[ cut here ]------------

[Ertan ERBEK]

Full log file

[Ertan ERBEK]

I think this is USB problem not USB based device problem also this problem start when Windows operation system complate driver setup then this problem occure. Because I experince this problem with two diffrent brand Wifi USB devie also one USB 3.0 ethernet adaptör.

[jj]

Same problem with fc20 and the latest kernels. Please fix this problem, since it is a nuisance that within notime my messages files contains Gb's of data.

[Ertan ERBEK]

My idea that problem source not VirtualBox, that problem created by Kernel and why I told this because Qemu and KVM also have that problem. When Guest start use USB device then this problem occure.

[jce_vb]

ertanerbek, If you can re-create the problem with VirtualBox completely out of the picture, perhaps you should create a problem report on the Linux side. In my case, the problem occurred ONLY with a VirtualBox VM and with all Windows OS tried (Win2K, WinXP, and Win7). Since I couldn't reproduce the problem without VirtualBox, Fedora dismissed my attempt to go that route, ​https://bugzilla.redhat.com/show_bug.cgi?id=1103799, as not their problem. For me, when using same app and same Win2K level under QEMU/KVM the problem disappeared. I didn't attempt to prove whether or not QEMU/KVM also worked in my case with WinXP and Win7 as experience under VirtualBox suggested the Win OS version was not significant. Obviously a Linux kernel change made the problem visible, but I could not demonstrate to Fedora that the problem was theirs rather than VirtualBox doing something that was no longer valid. I am running under 64-bit f19, my QEMU support is at 2:1.4.2-15 level, and my current hardware is Intel Core i5-3450 which supports hardware virtualization.

[Ertan ERBEK]

Dear That problem start after 3.14* firmware upgrade.

[Christoph Makita]

Same problem here, but with an iPhone and an Android Smartphone and Virtualbox under Debian Linux 7 (Wheezy).

After Debian updated Backports-Kernel from 3.14.[0-3] (where it worked without trouble) to 3.14.7, same problem occured. But only with USB-devices, which are connected explicitly through into Windows-VM. Windows-VM works perfectly, but when connecting the iPhone or the Android Smartphone, same messages as shown above occurs. No trouble with other USB-Devices connected to the host.

No Problem without older 3.14 Kernel (.0 to .3 it think) and no problem with 3.13.x or older.

[Christoph Makita]

Still the same problem after upgrading kernel to 3.14.12 and VirtualBox to 4.3.14 :(

Reverted to kernel 3.13.10 and anything's fine.

Problem report found on Red Hat Bugzilla – Bug 1103799 (​https://bugzilla.redhat.com/show_bug.cgi?id=1103799#c1):

"This is a problem with the virtualbox drivers. Fedora doesn't provide or support these. Please contact whomever you got them from."

[Frank Mehnert]

The reason for this warning is that a warning which in older Linux kernels was only enabled in DEBUG mode is now always enabled (I think the change was in Linux 3.14). We are working on a fix, no promises yet when the fix will be available.

[Don Hughes]

Same problem with VB 4.3.12 and SuSE kernel 3.15.6 every time I attach a USB storage device. Generated 7,000,000 log entries before I noticed. No problem with earlier kernel.

[Don Hughes]

I received this from SuSE:

usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK for output URBs. That causes usbcore to log messages without limit for a nonsensical disallowed combination. The fix is to silently drop the attribute in usbfs. The problem is reported to exist since 3.14 https://www.virtualbox.org/ticket/13085

Signed-off-by: Oliver Neukum <oneukum@…> CC: stable@… ---

drivers/usb/core/devio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c index 257876e..0b59731 100644 --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1509,7 +1509,7 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb

u = (is_in ? URB_DIR_IN : URB_DIR_OUT); if (uurb->flags & USBDEVFS_URB_ISO_ASAP)

u |= URB_ISO_ASAP;

• if (uurb->flags & USBDEVFS_URB_SHORT_NOT_OK)

+ if (uurb->flags & USBDEVFS_URB_SHORT_NOT_OK && is_in)

u |= URB_SHORT_NOT_OK;

if (uurb->flags & USBDEVFS_URB_NO_FSBR)

u |= URB_NO_FSBR;

-- 1.8.4.5

[sergiomb]

Replying to ...don:

I received this from SuSE:

usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK for output URBs. That causes usbcore to log messages without limit for a nonsensical disallowed combination. The fix is to silently drop the attribute in usbfs. The problem is reported to exist since 3.14 https://www.virtualbox.org/ticket/13085

Signed-off-by: Oliver Neukum <oneukum@…> CC: stable@… ---

drivers/usb/core/devio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c index 257876e..0b59731 100644 --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1509,7 +1509,7 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb

u = (is_in ? URB_DIR_IN : URB_DIR_OUT); if (uurb->flags & USBDEVFS_URB_ISO_ASAP)

u |= URB_ISO_ASAP;

• if (uurb->flags & USBDEVFS_URB_SHORT_NOT_OK)

+ if (uurb->flags & USBDEVFS_URB_SHORT_NOT_OK && is_in)

u |= URB_SHORT_NOT_OK;

if (uurb->flags & USBDEVFS_URB_NO_FSBR)

u |= URB_NO_FSBR;

-- 1.8.4.5

Hi, seems we got a similar problem on Fedora 20 kernel 3.15.7-200

with VirtualBox-4.3.14 , since 3.14, you mean kernel-3.14 or VirtualBox-4.3.14 ?

[sergiomb]

flooding patch for kernl 3.15

[sergiomb]

the patch in attach fix oops on kernel host when plug USB on guest .

Thanks,

[sergiomb]

Hi, good news

Greg KH wrote :

​http://www.spinics.net/lists/linux-usb/msg111380.html

The patch is already in Linus's tree, you can see it there. It's also already marked for the stable tree inclusion, so after Linus releases a -rc kernel with it in it, the stable kernel developers will be able to pick it up and put it in their kernels.

So there's really nothing to do here at the moment, the process will happen automatically.

[jce_vb]

Resolution by any means including via kernel patch will be most welcome, but I hope there are some explanatory comments that would "discourage" future kernel patchers who do not understand this patch's purpose from eliminating this flooding patch on the grounds that it addresses a condition that should never occur and is thus redundant.

Is creation of an output URB with URB_SHORT_NOT_OK set a violation of the current Linux semantics associated with URBs? If it is, then VirtualBox should not be allowing a VM to cause the passing of a URB that violates those semantics and there should perhaps be a patch at that level as well. If the Linux semantics are unclear, then a long-term kernel patch is probably the best solution, but adequate comments may reduce the odds of future regression. Otherwise someone may just interpret this as an expedient temporary fix until all applications with URB semantic issues have been found and fixed.

[sergiomb]

Replying to jce_vb:

Patch is already in kernel 3.17-rc1 ​https://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv3.x%2Ftesting%2Fpatch-3.17-rc1.xz;z=7355

other thing , please report Virtualbox problems with fedora in rpmfusion bugzilla , ​https://bugzilla.rpmfusion.org/enter_bug.cgi?product=Fedora&component=VirtualBox

[lavacano]

VBox log with patch applied to kernel-3.16

[lavacano]

Driver Messages with patch applied to kernel-3.16

[lavacano]

Replying to sergiomb:

Replying to jce_vb:

Patch is already in kernel 3.17-rc1 ​https://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv3.x%2Ftesting%2Fpatch-3.17-rc1.xz;z=7355

other thing , please report Virtualbox problems with fedora in rpmfusion bugzilla , ​https://bugzilla.rpmfusion.org/enter_bug.cgi?product=Fedora&component=VirtualBox

Patch fails to fix problem.

[sergiomb]

Replying to lavacano:

Patch fails to fix problem.

have you updated VirtualBox extensions to 4.3.14 ?

VirtualBox -> main menu -> help -> check for updates , and install new Oracle Vm VirtualBox extensions 4.3.14

[lavacano]

Replying to sergiomb:

Replying to lavacano:

Patch fails to fix problem.

have you updated VirtualBox extensions to 4.3.14 ?

VirtualBox -> main menu -> help -> check for updates , and install new Oracle Vm VirtualBox extensions 4.3.14

It says I am running the most recent version. This VBox is

[ebuild   R    ] app-emulation/virtualbox-modules-4.3.14  USE="-pax_kernel" 0 KiB
[ebuild   R    ] app-emulation/virtualbox-bin-4.3.14.95030  USE="additions chm python -debug -headless -rdesktop-vrdp -sdk -vboxwebsrv" 0 KiB

and steps I get to get the usb oops and virtualbox crash are:

---

1. Associate my Samsung S5 usb with the wintel box
2. Send an update using Samsung Kies 3, Verizon Update Manager or odin309.zip
3. When my phone recognizes the update my phone powers off, still connected to USB
4. When phone powers off Vbox crashes, (oops happens I believe) (vbox manager shows virtualmachine failure)

What should happen:

---

VBox should continue to run after the phone powers off, phone then boots into flash mode where it can receive ~2gb of data from USB (this has not happened until the phone boots back up the crash is from something else and happens before data payload is sent)

[lavacano]

Also FWIW I had used this exact same set of software in a previous version of vbox that worked (I believe 4.2.26) I will downgrade today and see if it works.

[lavacano]

Other tickets that may be duplicates:

https://www.virtualbox.org/ticket/13309

https://www.virtualbox.org/ticket/13239

[lavacano]

Confirming 4.3.12 works, no oops. nothing changed in virtualmachine only host software and kernel modules.

[sergiomb]

Patch is in kernel 3.16.2:

​https://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv3.x%2Fpatch-3.16.2.xz;z=83

[Frank Mehnert]

VBox 4.3.16 does also contain a fix. Please don't forget to update the Extension Pack.

[jce_vb]

Confirmed that going from VirtualBox 4.3.14 to 4.3.16 (with Extension_Pack) resolved the symptoms under Fedora kernel-3.14.17-100.fc19(64-bit). From earlier discussion it would appear that kernel 3.16.2 may also resolve, but no telling how long before that is available for Fedora since 3.14.17 only just came out, so thanks for fixing this on the VirtualBox level.

Regarding lavacano's comment that Fedora/VirtualBox problems should have been reported under rpmfusion bugzilla, that didn't seem appropriate here since rpmfusion's re-packaged version of VirtualBox was not being used, rather the package straight from the VirtualBox site, and there are some significant differences in packaging. In the past on an earlier release of Fedora I tried using the Fedora/rpmfusion packaging of VirtualBox and after enduring several kernel updates and VirtualBox updates finally gave up because of repeated package dependency issues and reverted back to the direct-from-VirtualBox version. The rpmfusion package attempted to create dependencies to install a companion kmod-VirtualBox package that is both dependent on kernel version and VirtualBox version, and invariably they either got the packaging messed up or the kmod kernel/VirtualBox combination I required would not be available when needed. The original VirtualBox packaging, which just dynamically builds the required module on the install system, appears to be a much more dependable upgrade approach (once you get the pre-requisite packages installed).

[sergiomb]

Replying to jce_vb:

Confirmed that going from VirtualBox 4.3.14 to 4.3.16 (with Extension_Pack) resolved the symptoms under Fedora kernel-3.14.17-100.fc19(64-bit). From earlier discussion it would appear that kernel 3.16.2 may also resolve, but no telling how long before that is available for Fedora since 3.14.17 only just came out, so thanks for fixing this on the VirtualBox level.

I just check, patch are in kernel 3.14.18

​https://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv3.x%2Fpatch-3.14.18.xz;z=797 but what I like to know if the patch in kernel is correct ? or if we should ask to upstream kernel to revert the patch since is correct warning, when uurb->flags & USBDEVFS_URB_SHORT_NOT_OK

Regarding lavacano's comment that Fedora/VirtualBox problems should have been reported under rpmfusion bugzilla, that didn't seem appropriate here since rpmfusion's re-packaged version of VirtualBox was not being used, rather the package straight from the VirtualBox site, and there are some significant differences in packaging. In the past on an earlier release of Fedora I tried using the Fedora/rpmfusion packaging of VirtualBox and after enduring several kernel updates and VirtualBox updates finally gave up because of repeated package dependency issues and reverted back to the direct-from-VirtualBox version. The rpmfusion package attempted to create dependencies to install a companion kmod-VirtualBox package that is both dependent on kernel version and VirtualBox version, and invariably they either got the packaging messed up or the kmod kernel/VirtualBox combination I required would not be available when needed. The original VirtualBox packaging, which just dynamically builds the required module on the install system, appears to be a much more dependable upgrade approach (once you get the pre-requisite packages installed).

I'm maintainer of VirtualBox in rpmfusion and if you install kmod-VirtualBox meta package things go smooth , also you can use akmod-VirtualBox that works with custom kernels , I don't have any report (last 2 years more or less ) except when rpmfusion builder went down and no kmod was available .