On Thursday, March 8, 2018 at 4:24:05 AM UTC+1, Glen H wrote: > Hi, > > I'm using R4 (having never used R3) and trying to get my scanner working but > it stops scanning a page half way through. After debugging with the author > of the scanner software they say the program asks for 128 KBytes of data and > the first 256 bytes of this data is dropped (lost). > > To fix this I've tried: > 1) Turning off USB 3.0 in BIOS (unfortunately this isn't really an option as > all the external ports are disabled). It doesn't revert back to USB 2.0 > 2) Set the ports to USB 2.0 via setpci: > > ``` > lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 > -d @ d0.l=0 > ``` > > Unfortunately neither of those made a difference. Using the scanner/software > in Windows on a different computer works. > > > I'm currently running a Qubes backup and then I'll try installing Ubuntu and > see if that works. If so would seem to be related to Qubes. > > Does anyone have any ideas? My laptop is a Dell e7440 with the latest BIOS. > > Thanks, > > Glen
These informations might give some extra insight; - Where is your USB controller? dom0? sys-usb? sys-net? somewhere else? directly in the AppVM? - It might be a bit annoying to do, but you could try install the printer on a different template. This would help you troubleshoot if the issue is template related or not template related. - If you then in addition do as you're already planning to that test it on Ubuntu, it also gives better insight. Maybe use Ubuntu live-boot to install the printer and test it though? So you can avoid installing it just fro that. If the printer works in another template, then you know it's a debian/fedora/whonix issue. If the printer doesn't work in another template, then it's likely not an issue in the templates (unless it's an universal kernel/driver or Qubes tools issue of ofc). But if it then works in Ubuntu, then you know it isn't a universal Linux/kernel issue. You're then more reasonably narrowed it down to potential culprits with some albeit rough, but useful estimates. btw if your USB controller is in dom0, then that already might be an explanation as to why it fails. You can also try temporarily pass the USB controller directly into an AppVM and test directly printing inside that AppVM (or alternatively use qvm-open-in-vm and open the doc in the AppVM that hold's the controller, and try print directly from the AppVM instead of using the qvm-usb features. This would rule out or rule in a bug in the qvm-usb as well. If you're up for some testings, then you should be able to narrow it down, maybe there are other useful ways to do this too, those mentioned are only the ones I could think of on the top of my head in the moment, there might be other good ways to narrow it down easily. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/227df168-1a6a-492e-a1ec-7c463caed814%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
