Opened 5 years ago

Closed 5 months ago

#11049 closed bug (fixed)

USB IO seems to stall for significant time

Reported by: jessicah Owned by: mmlr
Priority: normal Milestone: R1
Component: Drivers/USB Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


I have a BFS formatted partition without query support on a USB stick, and cloned haikuporter & haikuports onto this partition. And running haikuporter --no-dependencies vlc, it starts scanning all the ports like it does the first time you run it, which is taking a staggeringly long time, where it seems to halt for many seconds at a time.

In ProcessController, the only other process/thread I can spot using significant CPU is input_server/PathMonitor looper, which comes from BPathMonitor::_Init.

All other cores idle while a single core uses 100% in this looper (it in fact appears to use 100% all the time). I've tried dropping to KDL to try get some running information, but my keyboard doesn't work.

This is on hrev47514.

Change History (10)

comment:1 Changed 5 years ago by jessicah

Summary: BPathMonitor seems to cause IO issuesUSB IO seems to stall for significant time

Hmm, seems that was a red-herring. Problem must be somewhere inside USB I guess :( Not really sure how to debug further. Maybe someone else can replicate that can do serial debugging?

comment:2 Changed 5 years ago by jessicah

Or maybe somewhat related. I'm not seeing the same activity stalls quite as often as before (have disabled that BPath Monitor looper), though still pretty severe. Some of them are over 5 minutes long!!! Whether it's IO or not is debatable, but definitely some really odd behaviour. Not sure if this is related to #11010 or not; but that also shows significant stalls (though in this case, it's with redrawing...)

comment:3 Changed 5 years ago by jessicah

The same actions with haikuporter on an SSD, no USB disk attached, the stalls don't happen at all.

comment:4 Changed 5 years ago by diver

CPU eating input_server/PathMonitor looper just happened to me in vbox (hrev47979). Never saw it before.

comment:5 Changed 4 years ago by diver

Component: - GeneralDrivers/USB
Owner: changed from nobody to mmlr

comment:6 Changed 4 years ago by mmlr

This might be resolved by hrev49058. Please retest if you were able to reproduce this in some way. See also #11280 which seems related/the same.

comment:7 Changed 4 years ago by vidrep


Are you still able to reproduce this problem? It is certainly still an issue on my system. The oldest build I could find which shows this problem is hrev47458 (07/02/2014). Your ticket was created on 07/19/2014(17 days later). The next oldest build still available for testing (hrev47380) did not freeze, even after dozens of boots over 2 weeks. Can anybody see if there is a commit in that timeframe which may lead to a solution?

comment:8 Changed 4 years ago by jscipione

My best guess is hrev47398 specifically 5c9672e: Add watching support for installation location package changes, since it deals with file system watching.

comment:9 Changed 3 years ago by vidrep

This issue was resolved on my system 9 months ago (see ticket #11280). Can you test again?

comment:10 Changed 5 months ago by waddlesplash

Resolution: fixed
Status: newclosed

Assuming duplicate indeed; closing as fixed.

Note: See TracTickets for help on using tickets.