Recent F12 update makes input sluggish & breaks ssh?

[Thetargos]

I just noticed it this morning, attributed it to be a driver bug or some such, but I'm afraid this has more to do with a recent update than something else... All of a sudden, input in my F12 system is sluggish as hell... At first I thought it to be a problem with display drivers (and I'm sure something to that end is involved, as the sluggishness appears only when I enter the session, not before)... Lemme try and describe what I'm seeing:

First of all the laptop is using a synaptics touchpad. When I try to move the mouse pointer with it, there is a sensible (very long in terms of user interactivity) latency between the movement of my finger and the movement of the mouse pointer. All input events take way too long to be noticed by the computer. I WAS using Compiz and attributed this to be a driver issue, but this even happens if I have no composition whatsoever! Also fake transparency for stuff like Cairo-Dock or the GNOME terminal is wrong (transparency is displaying the GDM wallpaper instead of the session's wallpaper). Not only is mouse input sluggish, also keyboard input is unbearably slow, and I cannot point a finger to what the culprit may be, as I see no reasonable component recently updated that could have caused this. See attached file for my Yum.log for December.

Trying to check some additional information for this post, I found out that I can't SSH into the machine either. I can ping it just fine, just cannot start an SSH session, checked all the pertinent settings (firewall, services, etc) and all seems to be OK, and yet, I cannot connect to the machine... It may have something to do with the wireless, however I can start an SSH session from the laptop to my desktop just fine, so I don't think the interface may be a problem.

[Thetargos]

UPDATE

Apparently this was not caused by any updates, but rather by a workaround that I used by suggestion of smolt or some other tool regarding the BIOS on this computer. So it happens that this BIOS has some serious APIC flaws which may incur in threading problems and what not, so there is a wiki page that suggests to pass to the kernel the arguments

noapic irqpoll

However, since I found this issue (back in Fedora 8) I instead used:

noapic noioapic

So I switched the command-line options to the ones suggested in said wiki, and guess what? That was the root (pun intended) of this performance degradation. Apparently the solution I had been using was much better in that it did not interfere with the general performance of the computer. It got to a point where even cpufreq would not work properly and made the machine feel as if the CPU had only two speed steps (no pun intended here) 800 MHz and 1.9 GHz, where it shoudl have at least four states. So apparently forcing irq polling was a terrible idea and I should stick to my tried and true solution (at least until a workaround for this bug is embedded into the kernel). So if you happen to have a Toshiba laptop, with Phoenix BIOS and a K8-compatible CPU, and see some messages about a BIOS bug in dmesg or when booting up the kernel, just pass these two arguments, instead of the recommended ones