scanner seen in Dom0 but not in AppVM

708 views
Skip to first unread message

ix4...@gmail.com

unread,
May 21, 2013, 5:51:55 PM5/21/13
to qubes...@googlegroups.com
Hi

My scanner seems to be recognised just fine by the kernel and appears in all the right places in Dom0:

dmesg:
[20170.161080] usb 2-7: New USB device found, idVendor=03f0, idProduct=3011
[20170.161096] usb 2-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[20170.161106] usb 2-7: Product: psc 1100 series
[20170.161113] usb 2-7: Manufacturer: Hewlett-Packard
[20170.161121] usb 2-7: SerialNumber: MY37GD95YJC0
[20170.170300] usblp 2-7:1.1: usblp0: USB Bidirectional printer dev 12 if 1 alt 0 proto 2 vid 0x03F0 pid 0x3011
[20171.707328] usblp0: removed
[20171.725878] usblp 2-7:1.1: usblp0: USB Bidirectional printer dev 12 if 1 alt 0 proto 2 vid 0x03F0 pid 0x3011

lsusb:
Bus 002 Device 012: ID 03f0:3011 Hewlett-Packard PSC 1100 series

Great!

Problem is, simple-scan in any AppVM does not see the scanner. Trying dmesg or lsusb inside an AppVM does not show any of the above signs of scanner recognition.

USB mouse/keyboard work fine across VMs, so... is there something I need to do to be able to scan in QubesOS?

Thanks

Alex

Zrubecz Laszlo

unread,
May 22, 2013, 3:32:10 AM5/22/13
to qubes...@googlegroups.com
On 21 May 2013 23:51, <ix4...@gmail.com> wrote:
>
> lsusb:
> Bus 002 Device 012: ID 03f0:3011 Hewlett-Packard PSC 1100 series
>
> Great!
>
> Problem is, simple-scan in any AppVM does not see the scanner. Trying dmesg
> or lsusb inside an AppVM does not show any of the above signs of scanner
> recognition.

You can't assign USB devices to AppVMs right now. You have to assign
the whole USB hub instead:

http://qubes-os.org/trac/wiki/AssigningDevices


--
Zrubi

Joanna Rutkowska

unread,
May 22, 2013, 3:54:32 AM5/22/13
to Zrubecz Laszlo, qubes...@googlegroups.com
s/USB hub/USB controller/

USB hub is a "switch-like" device you connect to your computer. USB
controller is a PCIe device, implemented by your chipset, seen by your
system (as reported by lspci).

joanna.


signature.asc

Zrubi

unread,
May 22, 2013, 4:17:27 AM5/22/13
to Joanna Rutkowska, qubes...@googlegroups.com
On Wed, May 22, 2013 at 9:54 AM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:

> s/USB hub/USB controller/

sure :)


--
Zrubi

ix4...@gmail.com

unread,
May 24, 2013, 4:27:25 AM5/24/13
to qubes...@googlegroups.com
Thanks for the pointer. I followed the instructions in the "Finding the right USB controller" section and
qvm-pci -a work [BDF]
 exited cleanly, but when I started the "work" vm the entire laptop locked up (blank screen, keyboard frozen, had to do hard reset).

Any logs I should be looking through next time I boot my Qubes laptop?

Alex

Joanna Rutkowska

unread,
May 24, 2013, 4:48:15 AM5/24/13
to ix4...@gmail.com, qubes...@googlegroups.com
Just do double-check you used the correct BDF -- can send the output of
your lspci and then tell which BDF you used?

j.

signature.asc

ix4...@gmail.com

unread,
May 24, 2013, 5:14:10 AM5/24/13
to Joanna Rutkowska, qubes...@googlegroups.com
Sure:

[alex@dom0 ~]$ xl list
Name                                        ID   Mem VCPUs    State    Time(s)
dom0                                         0  5918     4     r-----      87.7
netvm                                        1   200     4     -b----      22.6
firewallvm                                   2  1685     4     -b----      10.2
[alex@dom0 ~]$ lsusb | grep PSC
Bus 002 Device 009: ID 03f0:3011 Hewlett-Packard PSC 1100 series
[alex@dom0 ~]$ readlink /sys/bus/usb/devices/usb2
../../../devices/pci0000:00/0000:00:1d.0/usb2
[alex@dom0 ~]$ qvm-pci -a work 00:1d.0
[alex@dom0 ~]$

At this point, starting the "work" VM results in a lockup.

Cheers

-A

Joanna Rutkowska

unread,
May 24, 2013, 5:19:25 AM5/24/13
to ix4...@gmail.com, qubes...@googlegroups.com
... and the output of your lspci?


signature.asc

ix4...@gmail.com

unread,
May 24, 2013, 2:30:18 PM5/24/13
to Joanna Rutkowska, qubes...@googlegroups.com
lspci output from Dom0:

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4)
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b4)
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b4)
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4)
00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b4)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset Family LPC Controller (rev 04)
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04)
02:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
0a:00.0 SD Host controller: O2 Micro, Inc. Device 8221 (rev 05)

PS: It was not possible to copy/paste this information from Dom0 to this AppVM. Why? Well, turns out Shift-Ctrl-C is already defined as "copy" for both the Xfce terminal emulator AND konsole and Qubes doesn't bypass that. So I had to resort to output redirection to file and then transfer via USB stick :-P

-A

Joanna Rutkowska

unread,
May 24, 2013, 4:09:24 PM5/24/13
to ix4...@gmail.com, qubes...@googlegroups.com
On 05/24/13 20:30, ix4...@gmail.com wrote:> lspci output from Dom0:
Indeed the device you're trying to passthrough is a USB controller, and
so this should normally just work fine. So, this seems like a
Xen-specific problem, or a hardware-specific problem (e.g. VT-d not
enabled?) and I suggest you inquire about it on the xen-devel list...

> PS: It was not possible to copy/paste this information from Dom0 to
> this AppVM. Why? Well, turns out Shift-Ctrl-C is already defined as
> "copy" for both the Xfce terminal emulator AND konsole and Qubes
> doesn't bypass that. So I had to resort to output redirection to file
> and then transfer via USB stick :-P
>

No. Even if no other application handled this key combination, you still
would not be able to use it to copy/paste data from/to Dom0. This is
intentional, as there should normally (except for reporting error logs)
be no reason for any data exchange between the Dom0 and other VMs.
Perhaps allowing to copy from Dom0 wouldn't be that harmful (as we are
mainly concerned about pasting to Dom0), but this was not implemented
anyway.

joanna.

signature.asc

ix4...@gmail.com

unread,
May 24, 2013, 7:08:15 PM5/24/13
to Joanna Rutkowska, qubes...@googlegroups.com
VT-d is enabled in the BIOS. How can I verify it has made it OK all the way to the kernel? /proc/cpuinfo and dmesg don't show anything too obvious... Regarding taking this to xen-devel, what information would I need to include to help the xen devels troubleshoot this?
 
> PS: It was not possible to copy/paste this information from Dom0 to
> this AppVM. Why? Well, turns out Shift-Ctrl-C is already defined as
> "copy" for both the Xfce terminal emulator AND konsole and Qubes
> doesn't bypass that. So I had to resort to output redirection to file
> and then transfer via USB stick :-P
>

No. Even if no other application handled this key combination, you still
would not be able to use it to copy/paste data from/to Dom0. This is
intentional, as there should normally (except for reporting error logs)
be no reason for any data exchange between the Dom0 and other VMs.
Perhaps allowing to copy from Dom0 wouldn't be that harmful (as we are
mainly concerned about pasting to Dom0), but this was not implemented
anyway.


Ah - that explains it. Good candidate to document on http://qubes-os.org/trac/wiki/CopyPaste ?

Thanks

Alex 

ix4...@gmail.com

unread,
May 24, 2013, 7:40:16 PM5/24/13
to qubes...@googlegroups.com, Joanna Rutkowska
I just noticed that http://qubes-os.org/trac/wiki/HCL lists my Dell E6320 as "green". This should be heavily caveated as I'm having major problems with power management (suspend to RAM or restore from RAM usually fail, freezing the laptop), and the machine will not reboot or poweroff.

The VT-d issue remains to be figured out...

-A

Zrubecz Laszlo

unread,
May 25, 2013, 3:56:58 PM5/25/13
to qubes...@googlegroups.com
On 25 May 2013 01:40, <ix4...@gmail.com> wrote:

> I just noticed that http://qubes-os.org/trac/wiki/HCL lists my Dell E6320 as
> "green". This should be heavily caveated as I'm having major problems with
> power management (suspend to RAM or restore from RAM usually fail, freezing
> the laptop), and the machine will not reboot or poweroff.

Well the HCL reports are comes from the users, If they report
ewerithing working we mark it green.
But I'm pretty sure that 'Dell E6320' has a lot of variants...

That kernel issue is a known bug, but I'm also not sure how it will be resolved.

One workaround is a kernel downgrade to 3.7.4 - it is better for some
ppl, but the suspend has still prolems just as you reported.

But in the other hand Qubes R2B2 - is still a Beta release - which is
not for production jet...


> The VT-d issue remains to be figured out...

run the 'qubes-hcl-report' script it will tell ypo if it is enabled or not.
It will also produce a "Supporf File" - send it to the list please.



--
Zrubi

ix4...@gmail.com

unread,
May 25, 2013, 4:16:11 PM5/25/13
to Zrubecz Laszlo, qubes...@googlegroups.com
On 25 May 2013 20:56, Zrubecz Laszlo <ma...@zrubi.hu> wrote:
On 25 May 2013 01:40,  <ix4...@gmail.com> wrote:

> I just noticed that http://qubes-os.org/trac/wiki/HCL lists my Dell E6320 as
> "green". This should be heavily caveated as I'm having major problems with
> power management (suspend to RAM or restore from RAM usually fail, freezing
> the laptop), and the machine will not reboot or poweroff.

Well the HCL reports are comes from the users, If they report
ewerithing working we mark it green.
But I'm pretty sure that 'Dell E6320'  has a lot of variants...


Allow me to clarify. That's *my* HCL report that has been shown as all green. :-)
 
That kernel issue is a known bug, but I'm also not sure how it will be resolved.


Thanks - I was not aware of this.
 
One workaround is a kernel downgrade to 3.7.4 - it is better for some
ppl, but the suspend has still prolems just as you reported.

But in the other hand Qubes R2B2 - is still a Beta release - which is
not for production jet...


Completely understand - but presumably the reason QubesOS has been released to the public is exactly that - for people to test it and come back with comments/bugs/suggestions? We're your beta testers, right? :-)

> The VT-d issue remains to be figured out...

run the 'qubes-hcl-report'  script it will tell ypo if it is enabled or not.
It will also produce a "Supporf File" - send it to the list please.

 It reports that VT-d is active :-(

Report attached.

Thanks

Alex
Qubes-HCL-Dell_Inc.-Latitude_E6320-20130525.txt
Qubes-HCL-Dell_Inc.-Latitude_E6320-20130525.cpio.gz

Zrubi

unread,
May 26, 2013, 4:01:24 AM5/26/13
to qubes...@googlegroups.com
On Sat, May 25, 2013 at 10:16 PM, <ix4...@gmail.com> wrote:

> Allow me to clarify. That's *my* HCL report that has been shown as all
> green. :-)

Then, it is probably my mistake to mark it green :o - Sorry.
green 'mark' removed.


> Completely understand - but presumably the reason QubesOS has been released
> to the public is exactly that - for people to test it and come back with
> comments/bugs/suggestions? We're your beta testers, right? :-)

Sure... just like me ;)


--
Zrubi

Marek Marczykowski

unread,
May 26, 2013, 3:07:23 PM5/26/13
to Zrubecz Laszlo, qubes...@googlegroups.com
On 25.05.2013 21:56, Zrubecz Laszlo wrote:
> On 25 May 2013 01:40, <ix4...@gmail.com> wrote:
>
>> I just noticed that http://qubes-os.org/trac/wiki/HCL lists my Dell E6320 as
>> "green". This should be heavily caveated as I'm having major problems with
>> power management (suspend to RAM or restore from RAM usually fail, freezing
>> the laptop), and the machine will not reboot or poweroff.
>
> Well the HCL reports are comes from the users, If they report
> ewerithing working we mark it green.
> But I'm pretty sure that 'Dell E6320' has a lot of variants...
>
> That kernel issue is a known bug, but I'm also not sure how it will be resolved.
>
> One workaround is a kernel downgrade to 3.7.4 - it is better for some
> ppl, but the suspend has still prolems just as you reported.

Try kernel 3.9.2 (from qubes-dom0-unstable repo) and xen 4.1.5 (from
qubes-dom0-current-testing repo), it works better for me. Especially xen 4.1.5
contains few fixes addressing directly suspend issues.

--
Best Regards,
Marek Marczykowski
Invisible Things Lab

signature.asc

ix4...@gmail.com

unread,
May 27, 2013, 2:50:58 AM5/27/13
to qubes...@googlegroups.com, Zrubecz Laszlo, Marek Marczykowski
I first tried xen 4.1.5 by editing /etc/yum.repos.d/qubes-dom0.repo and changing the "current" repo to enabled = 0 and the "current-testing" repo to enabled = 1. Ran sudo qubes-dom0-update and got (among others) the xen updates. I then rebooted and started testing. The machine managed to standby and resume twice in a row, restoring networking and everything, which made me A Happy Bunny (TM). But then it failed on the 3rd time, again throwing my machine in a state of limbo. Had to do a hard power off to get out.

So I repeated the process by disabling current-testing repo and enabling "unstable", got the latest kernel, rebooted, tried suspending, machine hung on first try.

Looks like I'm back to square one with my Dell E6320 :-(

Is there a way to enable logging of the PM actions so that I can tell what fails when the machine tries to go to suspend and fails?

Alex

Zrubecz Laszlo

unread,
May 27, 2013, 4:49:22 AM5/27/13
to Marek Marczykowski, qubes...@googlegroups.com
On 26 May 2013 21:07, Marek Marczykowski
<marm...@invisiblethingslab.com> wrote:

> Try kernel 3.9.2 (from qubes-dom0-unstable repo) and xen 4.1.5 (from
> qubes-dom0-current-testing repo), it works better for me. Especially xen 4.1.5
> contains few fixes addressing directly suspend issues.

The 3.9.2 kernel causing the same issues as the 'default' 3.7.6
- high CPU temperature (+ noisy coolers)
- poweroff fail -> hard reboot instead
- suspend fail -> hard reboot instead

So I'm back to kernel 3.7.4 and xen 4.1.5 will see how it is working.
But it is hard to tell because maybe it will hang instead of sleep -
sometimes. (Just as the linux 3.7.4 + xen 4.1.2 did)

Jut noticed, that the kernel always wanna upgrade my CPU microcode,
but fails to do it:

[ 17.410210] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x1a
[ 17.414486] microcode: CPU0 update to revision 0x28 failed
[ 17.414500] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x1a
[ 17.414548] microcode: CPU1 update to revision 0x28 failed
[ 17.414560] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x1a
[ 17.414604] microcode: CPU2 update to revision 0x28 failed
[ 17.414615] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x1a
[ 17.414653] microcode: CPU3 update to revision 0x28 failed
[ 17.414700] microcode: Microcode Update Driver: v2.00 <tigran@aivazian

But not sure if it is related or not.


--
Zrubi

ix4...@gmail.com

unread,
May 29, 2013, 6:24:38 PM5/29/13
to qubes...@googlegroups.com

On 27 May 2013 07:50, <ix4...@gmail.com> wrote:
<snip>

Looks like I'm back to square one with my Dell E6320 :-(
 
<snip>

Hang on - with the latest Xen (from testing) & kernel (from unstable), suspending to RAM from KDE seems to work very well - heck, I even get my wifi connection back when it resumes. It appears that KDE is doing something extra that Xfce isn't, and I had been using Xfce as my default desktop environment, I mean, I didn't expect a desktop environment to have such an effect on suspending to RAM, but there you have it.

In short, suspend status on the E6320 w/ Xen 4.5 and linux 3.9.2:
Xfce still doesn't work for me (90% failure rate)
KDE works for me (100% success rate so far, been using it for a couple of days now)

Alex

Marek Marczykowski

unread,
May 29, 2013, 7:14:27 PM5/29/13
to ix4...@gmail.com, qubes...@googlegroups.com
Interesting. Can you try "sudo pm-suspend"? This is what should be called by
both KDE and Xfce...
signature.asc

ix4...@gmail.com

unread,
May 30, 2013, 4:19:20 AM5/30/13
to Marek Marczykowski, qubes...@googlegroups.com
Funnily enough after I sent out my last email claiming 100% KDE suspend success, I closed the lid and the laptop went into limbo - the screens and keyboard were deactivated but it was not sleeping and had to be reset via the power button once more.

dom0$ sudo pm-suspend
this morning had exactly the same effect - results in a state of limbo, in which hard reset is the only option out.

I wonder how many hard resets this poor filesystem will sustain before breaking.

Alex

Joanna Rutkowska

unread,
May 30, 2013, 4:25:29 AM5/30/13
to ix4...@gmail.com, Marek Marczykowski, qubes...@googlegroups.com
Probably unlimited number, because of journaling.

j.


signature.asc

Robert William Fuller

unread,
May 30, 2013, 9:18:59 AM5/30/13
to Joanna Rutkowska, ix4...@gmail.com, Marek Marczykowski, qubes...@googlegroups.com
I used to work on file system drivers. I like to type sync and wait
until the disk activity ceases before I do something that might require
a hard reset.

I abused a Windows system once with NTFS, hard resetting it because it
took so long to shut down. The system administrator had set us up with
roaming profiles, so it would take 10-15 minutes to log out of the
domain. Or you could just hit the reset button... Anyway, once after a
hard reset, NTFS decided to run chkdsk (Windows equivalent of fsck) and
proceeded to eat every single record in the MFT (master file table:
Windows equivalent of inodes.) I watched it destroy the file system,
sequentially, one MFT record at a time. NTFS is a journaled file
system, so it is supposed to be immune to a hard reset. Hence, I try to
always sync first.

Rob

signature.asc
Reply all
Reply to author
Forward
0 new messages