Messages in this thread | | | Date | Thu, 5 Feb 2004 23:05:36 +0100 | From | Vojtech Pavlik <> | Subject | Re: [BUG] 2.6.2 crazy mouse under heavy load |
| |
On Thu, Feb 05, 2004 at 01:59:12PM -0700, Bob Gill wrote: > The exception seems to be coming from > linux-2.6.2/drivers/input/mouse/psmouse-base.c, specifically from > > if (psmouse->state == PSMOUSE_ACTIVATED && > psmouse->pktcnt && time_after(jiffies, psmouse->last + > HZ/2)) { > printk(KERN_WARNING "psmouse.c: %s at %s lost > synchronization, throwing %d bytes away.\n", > psmouse->name, psmouse->phys, psmouse->pktcnt); > psmouse->pktcnt = 0; > } > > > where (for me) HZ is 1804768000, and therefore HZ/2 is 902384000,
This looks very wrong. HZ should be 1000 on a normal machine. Maybe you were looking at jiffies?
> psmouse->pktcnt is 3, and (I assume) PSMOUSE_ACTIVATED is non-0 after > boot. I assume that pktcnt is fed by interrupt, and the problem then is > that psmouse->last + HZ/2 blows past the jiffies value, causing the > warning message to be issued. When mouse service finally comes back, > pktcnt is non-zero (and possibly whatever the maximum is that it will > hold), and when it flushes, the mouse pointer goes nuts for a second. > The real problem then, is why does the sum of ps->last + HZ/2 grow to > beyond the size of jiffies (or what is delaying the mouse service)?
Exactly. The if statement means "If no data arrived for more than half a second, and we're in the middle of a packet, something is wrong - we better should start from scratch."
The goal of that statement is to resynchronize the mouse data stream if a byte is lost.
-----
There are two scenarios of this message appearing (assuming 4-byte packets):
#1 Messages always appearing in pairs, and the sum being 4. This is a delayed or lost interrupt. Since the driver polls the controller in addition to servicing interrupts, if the controller has the byte, regardless of whether an interrupt arrived, it'll be processed.
#2 Messages appearing single, with numbers from 1 to 3. This is a lost byte. The controller either didn't receive the byte at all or something very fishy happened.
> This is just a rough guesstimate of what is going on, but seems to fit > the facts. Cheers!
-- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |