Haiku eat my processor

[miqlas]

Haiku run constantly with 60% CPU load. I checked the 'top' command, and i got this:

  thid   total    user  kernel %cpu        team name      thread name
    34 1440.66    0.00 1440.00 28.8      kernel_team scsi scheduler 1
  2680  692.49   22.00  669.00 13.8          Tracker        add poses
  2682  688.46   17.00  670.00 13.8          Tracker        add poses
   640  155.69   33.00  122.00  3.1      mail_daemon xyz@gmail.com

Haiku hrev35081, ASUS K8N mobo (NForce 3 250Gb), AMD Sempron 64, 2 HDD (Maxtor and Samsung) 1 ODD (Pioneer)

[miqlas]

My syslog

[anevilyak]

How many / what Tracker windows do you have open? Do those "add poses" threads ever disappear? If not, does the CPU usage stop if you kill Tracker? If it does, can you try running checkfs on your Haiku partitions?

[miqlas]

I was have only 2 open Tracker window. The add poses" threads don't dissapeared automatically. I rebooted, and now i dont~t have problem, it works correctly.

[anevilyak]

So it's not reproducible?

[miqlas]

No, i didn't see this anymore. Maybe it fixed itself :D Or it was a bug in the Matrix.

[anevilyak]

In that case, closing for now. If you do encounter it again, a) please reopen, and b) try the following: in ProcessController, pick the thread and pick "Debug This Thread!", go into the debugger, type "bt" at the prompt, and copy/paste the backtrace please.

[anevilyak]

And by "the thread" I mean one of the "add poses" threads :)

[jstressman]

Just hit this same problem. I had 11 Tracker windows open on various workspaces.

I had just dragged a folder full of music files into the MediaPlayer playlist and started playing a song. CPU usage was normal before that and I've been using the system for a day or so now without rebooting.

Followed your previous instructions:

(gdb) bt
#0  0xffff0114 in ?? ()
#1  0x003fc5da in BDirectory::GetNextDirents () from /boot/system/lib/libbe.so
#2  0x005c1a10 in BPrivate::CachedEntryIterator::GetNextDirents ()
   from /boot/system/lib/libtracker.so
#3  0x00627d2d in BPrivate::BPoseView::AddPosesTask ()
   from /boot/system/lib/libtracker.so
#4  0x007196e3 in thread_entry () from /boot/system/lib/libroot.so
#5  0x78443fec in ?? ()
(gdb) 

[anevilyak]

(In #8748) Most likely a duplicate of #5261.

[diver]

Was this folder on a BFS partition?

[jstressman]

The folder I dragged into the Playlist was on BFS. It was in a folder on my desktop. I had recently copied the files from NTFS to that folder, but I'm pretty sure I didn't see the CPU load jump until I dragged the files from the BFS folder into the Playlist. (I have ActivityMonitor running right on my desktop to keep an eye on CPU/MEM/NET for this very reason.)

I just cleared the playlist and dragged them in again, but couldn't repeat the load. I suppose there's a chance it related to the prior actions?

[Disreali]

@jstressman

If you just copied the files/folder from an NTFS volume, it could be that Haiku needs to identify all the files first, which does spike cpu usage.

Copy the folder from the NTFS volume to your desktop again, open the folder, select all files, and then select File->Identify. I bet you will see similar disk usage.

[Disreali]

I obviously meant CPU usage.

[jstressman]

Actually I've tried this several ways. Copying a couple folders over and dragging them into the playlist again... copying several over and highlighting them and choosing Identify, etc.

None of these actions registers so much as a blip out of the ordinary on my CPU.

I have a very powerful computer here and whatever that bug was before, it pegged 2 threads maximum, non-stop. They didn't stop until I killed them in the process of doing the backtrace.

Now maybe I can try replicating it with those exact files again to see if something in there was somehow responsible for this... but it really doesn't seem like it had anything to do with simply identifying the files, unless something about identifying those particular files triggered some underlying bug that caused the persistent heavy load.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed