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.

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.

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! :)

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.

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.

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.

...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.

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.

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.

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) {

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.

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.

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

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.

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: 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.

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...

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.