Virtual PC and feisty fawn

[trekfan1]

On Virtual PC 2004 SP1 and 2007 the pointer mouse is not work after updating the 2.6.17 kernel to 2.6.19 and later, on edgy (2.6.17) the mouse is working!

[Kyle McMartin (kyle)]

Thanks for your report, can you please attach the output of "dmesg" from when it works on edgy, and if you not boot to X in feisty, please attach a "dmesg" from there as well. Without this, it's impossible to fix your bug.

Thanks,
  Kyle

[trekfan1 (trekfan1)]

On feisty is possible to boot to X but mouse pointer is still freeze on center screen and not possibile to move with mouse!

I have posted the output the dmesg of feisty and edgy (on virtual pc) to phpfi.com:

http://phpfi.com/217921 (feisty)

http://phpfi.com/ 217924 (edgy)

On feisty have another problem under virtual pc, the lan is not working if not type on console:

sudo dhclient3 eth1

Screenshot: http://xs413.xs.to/xs413/07110/network_abort.JPG.xs.jpg

[Richard Kent Jordan (rjordan)]

I am running into the same issue. The mouse pointer appears in the center of the screen, but it is unresponsive. I have tried changing my xconfig to point to /dev/psaux and tried unloading and reloading psmouse all with no avail. Let me know if I can provide any more details, or help in any way. Thanks.

[Tod Pike (tgp-cs)]

I'm experiencing this also - here is some more information that might be useful.
Under 6.10, /proc/bus/input/devices has this in it for the mouse:

I: Bus=0011 Vendor=0002 Product =000a Version=0000
N: Name="TPPS/2 IBM TrackPoint"
P: Phys=isaa0060/serio1/input0
S: Sysfs=/class/input/input2
H: Handlers=mouse0 event2 ts0
B: EV=7
B: Key=70000 0 0 0 0 0 0 0 0
B: REL=3

dmesg shows this for the mouse detection

[ 74.314014] trackpoint.c: failed to get extended button data
[ 77.824105] IBM TrackPoint firmware: 0x01, buttons: 0/0
[ 77.828432] input: TPPS/2 IBM TrackPoint as /class/input/input2
[ 77.957034] ts: Compaq touchsceen protocol output

Whereas on 7.04, I see:
[ 16.962594] mice: PS/2 mouse device common for all mice
[ 16.988251] input: Macintosh mouse button emulation as /class/input/input0

I can provide more information if needed.

[Connah (connah)]

Same problem here. Installing Feisty Fawn under Virtual PC and the mouse is frozen in the center of the screen. The keyboard APPEARS to work because I can change virtual terminals. But I cannot access any desktop items via any keyboard hot keys or shortcuts. Anyone have any idea how I can get the mouse to work? This is the 3rd problem I've run into. Getting this installed under Virtual PC is a bear! Thanks! :)

Connah

[Tod Pike (tgp-cs)]

Well, if you really cannot wait for a fix, there is a very bad alternative:
the accessibility options. Use alt-F1 to access the menu options, and
use the keyboard to move over to preferences -> keyboard. You can
use the tab key to move among the options, and go down to accessibility.
You can then enable the accessibility options, tab over to "mouse" and
enable mouse keys.

Now, you can use the keyboard number keys to move the mouse around.
Horrible, but it does work.

[Connah (connah)]

> Well, if you really cannot wait for a fix, there is a very bad alternative:
> the accessibility options. Use alt-F1 to access the menu options

Todd, thanks a ton! I'm a newbie and just excited to try it out.
That'll get me going! I appreciate your taking the time to write. Take
care!

Matthew

[Daveski (dave-everything-it)]

I confirm that I have the same problem. My virtual Edgy install worked OK, but I upgraded to Feisty via the Update Manager and now the mouse does not work.

The Virtual PC software does not appear to 'capture' the mouse pointer when you click on the virtual machine. Normally the windows pointer disappears and the virtual machine pointer starts to move (but is trapped inside the virtual machine). You must release the pointer by pressing a magic key. It seems it is the capture process that is not working which suggests to me that the Virtual PC software does not think that the host machine has mouse support.

[Daveski (dave-everything-it)]

Looks like the issue might be in the 2.6.19 kernel and later.

Other distros are reporting the same problem:

http://www.linuxquestions.org/questions/showthread.php?t=521011
http://www.linuxquestions.org/questions/showthread.php?t=510698
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223606

[Connah (connah)]

> Normally the windows pointer
> disappears and the virtual machine pointer starts to move (but is
> trapped inside the virtual machine). You must release the pointer by
> pressing a magic key.

Hi! Thanks for the input! Perhaps I am misunderstanding but does that
last sentence imply the mouse can be released so that it will work?
What is this maaaaaagical key? (Simpsons reference) :)

[Michael Wexler (wexler)]

No, the idea is that once you enter a working VM, mouse and keyboard are "captured" by the virtual machine and the host machine cannot see them. You press a key, usually Right Alt (but this is user configurable), to tell the VM to "let go" and allow you to do other things on the host machine (answer emails, move a card in solitare, etc.)

This is not germane to the current bug, because the VM is not even grabbing the mouse. The bug must somehow tell Virtual PC that the VM doesn't need the mouse, so its not really being captured, as far as I can tell.

[Joe Soroka (launchpad-joesoroka)]

This is probably a duplicate of:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/91330
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/108221
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/108382

...and it's clearly affecting all other distros too, so this might not be the right place, but here goes.

See line 630 of /usr/src/linux-source-2.6.20/drivers/input/serio/i8042.c:
---------------------------------------------------------------------------------------------
 if (wait_for_completion_timeout(&i8042_aux_irq_delivered,
     msecs_to_jiffies(250)) == 0) {
/*
 * AUX IRQ was never delivered so we need to flush the controller to
 * get rid of the byte we put there; otherwise keyboard may not work.
 */
  i8042_flush();
  retval = -1;
 }
---------------------------------------------------------------------------------------------
Commenting out the i8042_flush(); and retval = -1; lines 'fixes' the problem.

before:
$ dmesg | grep "i8042 AUX" || echo nothing
nothing

after:
$ dmesg | grep "i8042 AUX" || echo nothing
[ 69.766263] serio: i8042 AUX port at 0x60,0x64 irq 12

BTW I increased the timeout from 250ms to 20 seconds, and it didn't make a difference, so that's not it. It's just not responding at all.

This bug is marked as being of 'Undecided' importance and 'Needs Info', perhaps due to its "eau de M$", but the aforementioned probable dupes are marked as 'High' importance and 'Confirmed' status. I hope this 'Info' can expedite the help for all those other people suddenly without a mouse on their primary, non-virtual, machines.

[Joe Soroka (launchpad-joesoroka)]

You might not want to go through the trouble of building your own kernel, especially in light of https://bugs.launchpad.net/ubuntu/+source/kernel-package/+bug/90283

In that case, you can try out the patch that I am attaching. It goes through alot of effort just to change two bytes in the kernel, from "85 c0 test eax, eax" to "40 40 inc eax inc eax". It's based very loosely on the discussion at http://www.cpqlinux.com/binary-kernel.html which is somewhat out of date, and doesn't work.

Anyway, I'm posting this here because Virtual PC users can stand the pain of a binary kernel patch. If it doesn't work or borks things up, you just chuck out your 'undo' disk. It would probably work for the people waiting on https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/108382 as well, but it's a little more risky for them.

Having said that, it doesn't change much. It leaves the old kernel in place, and comes with an uninstaller script, so it might be worth a try for them too.

Security-wise, your on your own. Running a shell script that requires sudo, which then patches your kernel in obscure ways is not something to be taken lightly. Have a good look through the script before you run it.

Basically all it does is change the bytes corresponding to line 631, from
     msecs_to_jiffies(250)) == 0) {
to
     msecs_to_jiffies(250)) + 2) {

[MD Mosley (micmos85)]

I just tried the script from the previous post and it is working for me. VPC now correctly captures the mouse when I click in the VPC window and I can navigate with it normally. Thank you for working on this problem.

[Joe Soroka (launchpad-joesoroka)]

Haven't tried it - just saw it in the patch queue:
http://ring.aist.go.jp/archives/linux/kernel.org/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/broken-out/input-fix-aux-port-detection-with-some-i8042-chips.patch
http://ring.aist.go.jp/archives/linux/kernel.org/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/broken-out/input-fix-aux-port-detection-with-some-i8042-chips-fix.patch

[Tod Pike (tgp-cs)]

I would also like to confirm that the patch supplied worked just fine.
A very elegant patch, did a good job of making backups.

[BobN (robert-nadler)]

I third that confirmation. Upgraded from 6.10 to 7.04 on VPC-2007 and lost mouse capture. The patch worked great.
Thank you.

[Joe Soroka (launchpad-joesoroka)]

Regarding the diffs in the patch queue that I mentioned above... I just tried building a kernel with them, and it didn't help. I even increased the timeout from 100*50us to 10000*50us and it didn't make a difference.

[Joe Soroka (launchpad-joesoroka)]

Also, I said in my description above that:
"Basically all it does is change the bytes corresponding to line 631, from
     msecs_to_jiffies(250)) == 0) {
to
     msecs_to_jiffies(250)) + 2) {"

That's just not true... It does the opposite. It's more like
     msecs_to_jiffies(250)) == -2) {

[Matt Andrews (mqatrombone)]

Another dmesg from Virtual PC 2007.

[Matt Andrews (mqatrombone)]

The attached is the lspci -vvvnn output from feisty under vpc 2007, like the previous dmesg.

[Bill Farmer (williamjfarmer)]

How did you calculate the offset to the patched code in the patch script above? I want to apply the same patch to the new security update kernel 2.6.20-16.28 which has been published. I can see how to update the script apart from calculating the offset.
Bill

[Joe Soroka (launchpad-joesoroka)]

I don't remember precisely how I got the offset. Basically, I went to build the kernel the normal ubuntu way, but I changed the 250ms to something else, which ended up being easily searchable. Then also, somehow, due to some bug in the build process, I ended up with an uncompressed vmlinux... Then I found, inside the vmlinux, the 'easily searchable' number from above, I disassembled the bytes around it and figured out which ones matched with which source lines... and, well, there ya go. Not exactly easily repeatable.

[Matt Andrews (mqatrombone)]

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223606

There appears to be a less invasive workaround at the bottom of this bug report.
Add the kernel parameter "i8042.noloop" (without the quotes). This cause Virtual PC 2007 to behave as expected for me.

[indianabeck (davidb-beckb)]

Sorry to be so Unix stupid but I downloaded the Joe Soroka two byte patch script but don't know how to run it. Could someone help me out?

Dab

[Phillip Lougher (phillip-lougher)]

indianabeck: the two byte patch will only work on 2.6.20-15.27 (not the latest 2.6.20-16.28). Adding the kernel parameter "i8042.noloop" is a better way, this is effectively what the two byte patch achieves, and it is kernel version independent.

[indianabeck (davidb-beckb)]

Philip,

Thanks. Can you tell me how I would add the kernel parameter? Do I edit
a file like I did when I added the "tulip" network driver?

IndianaBeck

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
Phillip Lougher
Sent: Thursday, May 31, 2007 10:09 AM
To: David A. Beck
Subject: [Bug 87262] Re: Virtual PC and feisty fawn

indianabeck: the two byte patch will only work on 2.6.20-15.27 (not the
latest 2.6.20-16.28). Adding the kernel parameter "i8042.noloop" is a
better way, this is effectively what the two byte patch achieves, and it
is kernel version independent.

--
Virtual PC and feisty fawn
https://bugs.launchpad.net/bugs/87262
You received this bug notification because you are a direct subscriber
of the bug.

[Phillip Lougher (phillip-lougher)]

On 5/31/07, David A. Beck <email address hidden> wrote:
> Philip,
>
> Thanks. Can you tell me how I would add the kernel parameter? Do I edit
> a file like I did when I added the "tulip" network driver?
>

This is probably covered in a FAQ somewhere. A google brings this up,
which is a good description of what you have to do...

http://grumpymole.blogspot.com/2007/05/ubuntu-how-to-edit-grub-boot-parameters.html

Phillip

[indianabeck (davidb-beckb)]

Hot Zig! Phillip This fixed 7.04 for me on Virtual PC 2007. :)

[trekfan1 (trekfan1)]

Yeah! the fix is already work on gutsy with kernel 2.6.22 thx!

[kacheng (kacheng)]

Phillip's kernel parameter fixes the no mouse issue for 7.10 in VirtualPC 2007.
Thanks!

[Leann Ogasawara (leannogasawara)]

I'm just curious why this report is also targeted against the Hardy kernel but there are no comments here regarding this being in issue with Hardy. I'm marking this Invalid against the Hardy kernel for now until we receive further information.

Also, I'm reassigning the Ubuntu Hardy kernel source package from 'linux-source-2.6.24' to just 'linux'. Beginning with the Hardy release the package naming convention changed from linux-source-2.6.x to just linux. Sorry for any confusion.

Thanks.

[William L. DeRieux IV (williamderieux)]

As requested by Leann Ogasawara:

I have confirmed this to an issue in Ubuntu 8.04.1 (Hardy) with kernel 2.6.24-19-386.

This problem also affects the lastest linux kernel and at the time I wrote this it was, 2.6.25.6.

Adding i8042.noloop to the kernel parameters fixes the problem in hardy as well as the 2.6.25.6 kernel.

Maybe this kernel option should be added permanently to the kernel options (from the stock setup) --
at least until the actual problem is fixed.