Opened 11 years ago

Closed 2 years ago

Last modified 13 months ago

#5261 closed bug (not reproducible)

Haiku eat my processor

Reported by: miqlas Owned by: marcusoverhagen
Priority: normal Milestone:
Component: Drivers/Disk Version: R1/alpha1
Keywords: scsi scheduler, cpu, load, Cc:
Blocked By: Blocking: #8748
Platform: All


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

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

Attachments (1)

syslog (138.2 KB ) - added by miqlas 11 years ago.
My syslog

Download all attachments as: .zip

Change History (17)

by miqlas, 11 years ago

Attachment: syslog added

My syslog

comment:1 by anevilyak, 11 years ago

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?

comment:2 by miqlas, 11 years ago

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.

comment:3 by anevilyak, 11 years ago

So it's not reproducible?

comment:4 by miqlas, 11 years ago

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

comment:5 by anevilyak, 11 years ago

Resolution: invalid
Status: newclosed

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.

comment:6 by anevilyak, 11 years ago

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

comment:7 by jstressman, 9 years ago

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/
#2  0x005c1a10 in BPrivate::CachedEntryIterator::GetNextDirents ()
   from /boot/system/lib/
#3  0x00627d2d in BPrivate::BPoseView::AddPosesTask ()
   from /boot/system/lib/
#4  0x007196e3 in thread_entry () from /boot/system/lib/
#5  0x78443fec in ?? ()

comment:8 by jstressman, 9 years ago

Resolution: invalid
Status: closedreopened

comment:9 by anevilyak, 9 years ago

Blocking: 8748 added

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

comment:10 by diver, 9 years ago

Was this folder on a BFS partition?

comment:11 by jstressman, 9 years ago

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?

comment:12 by Disreali, 9 years ago


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.

comment:13 by Disreali, 9 years ago

I obviously meant CPU usage.

comment:14 by jstressman, 9 years ago

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.

comment:15 by waddlesplash, 2 years ago

Resolution: not reproducible
Status: reopenedclosed

comment:16 by nielx, 13 months ago

Milestone: R1

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

Note: See TracTickets for help on using tickets.