Opened 5 years ago

Closed 4 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:
Has a Patch: no 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 5 years ago.
normal syslog
syslog-input_hangs (169.5 KB) - added by humdinger 5 years ago.
syslog with pegging PathMonitor looper

Download all attachments as: .zip

Change History (12)

Changed 5 years ago by humdinger

Attachment: syslog_ok added

normal syslog

Changed 5 years ago by humdinger

Attachment: syslog-input_hangs added

syslog with pegging PathMonitor looper

comment:1 Changed 5 years ago by humdinger

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 Changed 5 years ago by Giova84

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

comment:3 Changed 5 years ago by vidrep

Possible duplicate of #11280.

Version 0, edited 5 years ago by vidrep (next)

comment:4 Changed 5 years ago by Giova84

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 Changed 4 years ago by dsuden

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 Changed 4 years ago by vidrep

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 Changed 4 years ago by 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.

comment:8 in reply to:  7 Changed 4 years ago by vidrep

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:9 Changed 4 years ago by ttcoder

comment:10 Changed 4 years ago by pulkomandy

Blocked By: 11280 added
Resolution: duplicate
Status: newclosed

Yes. Let's track the problem there then.

Note: See TracTickets for help on using tickets.