Opened 10 years ago

Closed 10 years ago

#11432 closed bug (duplicate)

PathMonitor looper sometimes pegs one core after bootup

Reported by: humdinger Owned by: korli
Priority: normal Milestone: R1
Component: Servers/input_server Version: R1/Development
Keywords: Cc:
Blocked By: #11280 Blocking:
Platform: All

Description

This is hrev48228.

Maybe 20% of all bootups, I experience input_servers "PathMonitor looper" pegging one core. While my wireless USB mouse still works, the keyboard is dead. Dunno when it started, but it's a fairly new issue (a few months at most). Attached a normal and a pegging syslog.

Related to #11049?

Attachments (2)

syslog_ok​ (169.4 KB ) - added by humdinger 10 years ago.
normal syslog
syslog-input_hangs​ (169.5 KB ) - added by humdinger 10 years ago.
syslog with pegging PathMonitor looper

Download all attachments as: .zip

Change History (12)

by humdinger, 10 years ago

Attachment: syslog_ok​ added

normal syslog

by humdinger, 10 years ago

Attachment: syslog-input_hangs​ added

syslog with pegging PathMonitor looper

comment:1 by humdinger, 10 years ago

One more thing: Watching the cpu meter, the core-pegging starts relatively late in the boot process. Maybe two seconds after the Desktop with the ActivityMonitor replicant appears.

comment:2 by Giova84, 10 years ago

This also happen for me, exactly as described by Humdinger. hrev48215

comment:3 by vidrep, 10 years ago

Possible duplicate of #11280 and #11049.

Last edited 10 years ago by vidrep (previous) (diff)

comment:4 by Giova84, 10 years ago

I also noticed another behaviour: sometimes instead of see that input_servers "PathMonitor looper" pegging one core (and in this case the input_server freezes completely: i have to hard reset the computer: i cannot use the usb wireless mouse nor the PS/2 keyboard), I only see that the wireless mouse works without issue (in this case input_server doesn't take the whole usage of one core), but the PS/2 keyboard does not work at all. In this case, using the mouse i can click on "Restart System" to back to normality. So for me, this issue is sometimes slightly different as described in the ticket.

comment:5 by dsuden, 10 years ago

This one is prevalent, and seems pretty serious. I'm noticing it across-the-board on the systems I set up. Not every boot, but often enough to be concerning. There's nothing that can be done to stop it (that I've found), other than rebooting.

comment:6 by vidrep, 10 years ago

I first saw this problem immediately after the GSOC 2014 LibUSB port was merged, along with other USB related issues that I had not experienced previously.

comment:7 by pulkomandy, 10 years ago

A debug report of the thread using 100% CPU would be useful. If it is the keyboard thread it should be possible to attach debugger to just that thread and keep the mouse working.

in reply to:  7 comment:8 by vidrep, 10 years ago

Replying to pulkomandy:

A debug report of the thread using 100% CPU would be useful. If it is the keyboard thread it should be possible to attach debugger to just that thread and keep the mouse working.

Have a look at these two tickets #11280 and #11049. Possibly all related.

comment:10 by pulkomandy, 10 years ago

Blocked By: 11280 added
Resolution: → duplicate
Status: new → closed

Yes. Let's track the problem there then.

Note: See TracTickets for help on using tickets.