USB IO seems to stall for significant time

[jessicah]

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.

[jessicah]

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?

[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...)

[jessicah]

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

[diver]

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

[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.

[vidrep]

Jessicah,

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?

[jscipione]

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

[vidrep]

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

[waddlesplash]

Assuming duplicate indeed; closing as fixed.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone