On Saturday, March 10, 2018 at 6:36:25 AM UTC+1, Glen H wrote: > On Thursday, March 8, 2018 at 8:55:56 AM UTC-5, Glen H wrote: > > On Thursday, March 8, 2018 at 8:12:59 AM UTC-5, Ed wrote: > > > On 03/07/2018 10:24 PM, 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 > > > > > > > > > > Are you passing the device through to another VM? > > > > > > The USB pass-through method has given me issues in the past for devices > > > that use a lot of bandwidth (webcams), though you are saying data is > > > lost after only a few bytes, I still might be suspect of the USB > > > passthrough system in qubes... > > > > > > So if you ARE passing through you might want to try running the scanner > > > software directly from sys-usb to see if you can eliminate the USB > > > passthrough as a source of problems. > > > > > > Ed > > > > Hi, I'll do some more tests in the next few days but just to answer some > > questions: > > > > 1) I have USB devices assigned in sys-usb > > > > 2) I use the devices panel widget to pass them to my AppVM. > > - then it shows up as "Bus 001 Device 002: ID 04f9:60a0 Brother > > Industries, Ltd ADS-2000" > > > > 3) The controller info from Dom0 is: > > > > 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC > > [8086:9c31] (rev 04) > > 00:1d.0 USB controller [0c03]: Intel Corporation 8 Series USB EHCI #1 > > [8086:9c26] (rev 04) > > > > I'll try testing in the debian-9 AppVM, test from sys-usb, and install > > Ubuntu too once I have time. One other thing I haven't investigated is > > "Configure strict reset for PCI devices" but it is grayed out in sys-usb > > Devices tab. > > > > Thanks for the help. > > > > Glen > > I ran some tests and the issue happens in sys-usb, Ubuntu (fresh install, no > Qubes). When I use Windows 7 on the same hardware it works. So it looks > like there is a driver issue with Linux. I tried updating the USB controller > in Windows and then switching back to Linux and the problem still exists. So > it seems the USB driver has an issue with reading data from my scanner. Any > recommendations for what I should do? > > Thanks, > > Glen
When narrowed down to a likely driver issue, then I'd suggest a next step to find the modules name that handles the driver/scanner. You can also check if it's the same module across different Linux systems, Debian/Fedora template, as well as the one on Ubuntu. Another thing you can do is look up the printer and see if you can find any Linux drivers to it to download, or if it was written directly to the kernel/modules. Another approach could be unofficial drivers, for example drivers that might work on hardware, where the driver wasn't build by the hardware company. Sometimes you see hardware company employee's write drivers in their free time too, and other times you find similar drivers/modules which can work, albeit not perfectly. It can also do damage to the hardware if a wrong driver is used, so you need to take precautions or be wary not to take the unofficial drivers or unofficial modules, if you want to avoid risk of damage. It could also be that you're already using an unofficial driver/module, and that the official one might work. For example, it might just be a module change you need to do, modules are kind of external drives to the drivers included in the kernel itself. So modules serves as a way to include drivers, without messing with the kernel too much. As far as I understand, it also makes it easier to maintain the kernel over the years, as modules can easily be out-dated and thrown away in favour for new ones, while keeping the kernel clean as it's been upgraded. But my understanding of kernels/modules is very vague, don't take it at face value, I might have gotten some details wrong. But in general, what I'd suggest, is to identity the driver (module). Also chances are its the same module in all Linux distro's, but as extra redundancy check it might be worth checking if its the same module. If more modules/drivers exist that can do the job, switching it might help. i.e. are there any drivers on the printers website? If you dare take the risk (risk of hardware damage), does it help to pick a driver from a similar scanner/printer by the same developer? It might be discourages to test that, but if you don't mind buying a new printer if it goes wrong, then it's worth a try. I didn't quite catch if the windows driver worked in Qubes Windows HVM? If yes, then as a last resort if nothing else works, an alternative could be to install a Windows system in Qubes purely for printing jobs, and then block any internet on it, and then print from there securely, since it doesn't have internet access anyway. It wastes a lot of disk space, but if you have a lot of disk space, then this one might work, or work until you find a better solution. -- 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/fe4bf176-0771-4e82-abac-cccb45078f03%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
