scanner seen in Dom0 but not in AppVM

[ix4...@gmail.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]

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]

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.

[Zrubi]

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]

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]

Just do double-check you used the correct BDF -- can send the output of
your lspci and then tell which BDF you used?

j.

[ix4...@gmail.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]

... and the output of your lspci?

[ix4...@gmail.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]

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.

[ix4...@gmail.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]

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]

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]

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

[Zrubi]

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]

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

[ix4...@gmail.com]

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]

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]

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]

Interesting. Can you try "sudo pm-suspend"? This is what should be called by
both KDE and Xfce...

[ix4...@gmail.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]

Probably unlimited number, because of journaling.

j.

[Robert William Fuller]

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