#11174 closed bug (fixed)
Processor - idle missing
Reported by: | kim1963 | Owned by: | pdziepak |
---|---|---|---|
Priority: | blocker | Milestone: | R1/beta1 |
Component: | System/Kernel | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #11666 | |
Platform: | All |
Description (last modified by )
Updated from hrev47738 to hrev47748. CPU usage is zero. The cooling fan operates at the limit. Exhausting air is very hot. On hrev47738 - all right!
Kernel name: kernel_x86 built on: Aug 24 2014 17:04:07 version 0x1 4 Intel Core™ i3-2330M, revision 206a7 running at 2195MHz CPU #0: "Intel(R) Core(TM) i3-2330M CPU @ 2.20GHz" Raw CPUID: 0x0206a7, Type 0, family 6, model 42, stepping 7, features 0xbfebfbff FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CFLUSH DS ACPI MMX FXSTR SSE SSE2 SS HTT TM PBE Extended Intel: 0x15bae3bf SSE3 PCLMULDQ DTES64 MONITOR DS-CPL VMX EST TM2 SSSE3 CX16 xTPR PDCM PCID SSE4.1 SSE4.2 x2APIC POPCNT TSC-DEADLINE XSAVE AVX Extended AMD: type 0, family 0, model 0, stepping 0, features 0x28100000 NX RDTSCP 64 Power Management Features: L2 Data cache fully associative, 1 lines/tag, 64 bytes/line L2 cache: 0 KB, 1-way set associative, 0 lines/tag, 63 bytes/line Data TLB: 2M/4M-bytes pages, 4-way set associative, 32 entries Data TLB: 4k-byte pages, 4-way set associative, 64 entries Unknown cache descriptor 0x76 Unknown cache descriptor 0xff Inst TLB: 4K-bytes pages, 4-way set associative, 64 entries 64-byte Prefetching Shared 2nd-level TLB: 4K, 4-way set associative, 512 entries
Attachments (1)
Change History (33)
comment:1 by , 10 years ago
Description: | modified (diff) |
---|---|
Owner: | changed from | to
Platform: | x86 → All |
Status: | new → assigned |
comment:2 by , 10 years ago
follow-up: 5 comment:4 by , 10 years ago
The reporter might confirm which flavor he is using, probably a GCC4 kernel based one.
follow-up: 6 comment:5 by , 10 years ago
Replying to korli:
The reporter might confirm which flavor he is using, probably a GCC4 kernel based one.
hrev x86_gcc2 !!
comment:6 by , 10 years ago
comment:7 by , 10 years ago
Milestone: | R1 → R1/alpha5 |
---|
comment:8 by , 10 years ago
Priority: | normal → blocker |
---|
comment:9 by , 10 years ago
Assigning this to the A5 milestone makes sense to me, but I don't really agree that this should be a blocker. Does it prevent use of the computer in any way?
comment:10 by , 10 years ago
It puts the hardware in danger of overheating. I wouldn't want to run a computer that way.
comment:12 by , 10 years ago
comment:13 by , 10 years ago
That doesn't make any sense. None of those commits affect the kernel except for hrev48074, and that only affects x86_64 not x86_gcc2. Even if they did, you said that hrev47748 had the problem. right? So did it just vanish between hrev47748 and hrev48031?
This is starting to sound like an intermittent failure to me, unless there's something else going on.
comment:14 by , 10 years ago
Yes.
PS Changed 6 weeks ago by edglex
I also have this problem on hrev47826 with an i5-3230M
47826 - 48031 ?
comment:15 by , 10 years ago
The only one of those commits that has anything to do with the kernel is hrev47830, and that changed display code, not CPU code. CPUIdle code has not been touched since the scheduler merge in January or so, IIRC.
Are you sure nothing else is changing? Maybe reboot a few times on one hrev and make sure it happens none of those times?
comment:16 by , 10 years ago
http://s49.radikal.ru/i125/1410/79/64b4fba0c33f.png
hrev48074 x86_gcc2 -- retry bug!!!
hrev48068 x86_gcc2 -- no bug.
comment:17 by , 10 years ago
There wasn't any possibly related change in this commit range. So the problem must be somewhere else.
- Are you using the nightlies or compiling yourself? Maybe one of the buildbots generates different/broken images? (hrev48074 built by geist-bot3-ubuntu64 - hrev48068 built by zooey-bot2-suse)
- Does cold boot / reboot from haiku / reboot from another system makes any difference?
How to check which bot built which image:
- go to http://buildbot.haiku-os.org/builders/haiku-nightlies-x86_gcc2_hybrid and find matching build (in each build page, the build property "commit description" shows the hrev)
- look for slaveName in the build properties.
comment:18 by , 10 years ago
comment:19 by , 10 years ago
@kim1963, you realize that having "Idle Thread" use 100% CPU is *not* an indicator of the bug? The only indicator of the bug is your CPU getting very hot. So this screenshot doesn't demonstrate anything.
comment:20 by , 10 years ago
Diver helped investigate this with kim.
The package bundled in the nightlies works fine. But the packages in the repo trigger the issue. You can see they are different on these screenshots: http://i.imgur.com/h70W6dP.png http://i.imgur.com/XQAZH2K.png
So it is some misconfiguration of arfonzo's bot (which builds most of the packages for the repos) or the repository buildbot recipe leading to a broken system. We still don't know exactly what's different in that case, however.
comment:22 by , 10 years ago
Update to hrev48086 x86_gcc2 -- no bug!!! Update to hrev48100 x86_gcc2 -- retry bug!!! http://buildbot.haiku-os.org/buildslaves/arfonzo-bot1-debian
comment:23 by , 10 years ago
comment:24 by , 10 years ago
Milestone: | R1/alpha5 → R1/beta1 |
---|
comment:25 by , 10 years ago
Update to hrev48433 x86_gcc2 -- no bug Update to hrev48440 x86_gcc2 -- BUG !!! http://buildbot.haiku-os.org/builders/haiku-repository-x86_gcc2_hybrid/builds/987
comment:26 by , 10 years ago
comment:28 by , 10 years ago
Blocking: | 11666 added |
---|
comment:29 by , 10 years ago
4 Intel Core™ i3-3110M, revision 306a9 running at 2394MHz
CPU #0: "Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz"
Raw CPUID: 0x0306a9, Type 0, family 6, model 58, stepping 9, features 0xbfebfbff
FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CFLUSH DS ACPI MMX FXSTR SSE SSE2 SS HTT TM PBE
Extended Intel: 0x35bae3bf
SSE3 PCLMULDQ DTES64 MONITOR DS-CPL VMX EST TM2 SSSE3 CX16 xTPR PDCM PCID SSE4.1 SSE4.2 x2APIC POPCNT TSC-DEADLINE XSAVE AVX F16C
Extended AMD: type 0, family 0, model 0, stepping 0, features 0x28100000
NX RDTSCP 64
Power Management Features:
L2 Data cache fully associative, 1 lines/tag, 64 bytes/line L2 cache: 0 KB, 1-way set associative, 0 lines/tag, 63 bytes/line
Data TLB: 2M/4M-bytes pages, 4-way set associative, 32 entries Data TLB: 4k-byte pages, 4-way set associative, 64 entries Unknown cache descriptor 0x76 Unknown cache descriptor 0xff Inst TLB: 4K-bytes pages, 4-way set associative, 64 entries 64-byte Prefetching Shared 2nd-level TLB: 4K, 4-way set associative, 512 entries
comment:30 by , 10 years ago
comment:31 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
After hrev48973 the misbehaving buildbot was put offline: http://buildbot.haiku-os.org/buildslaves/arfonzo-bot1-debian
It uses a stable debian install, which has outdated libraries and cannot compile Haiku properly anymore. I am closing this ticket as I think any bot with more up to date software will not have this problem anymore. Please let us know if you hit the problem again.
It's also possible that hrev49058 helped fix this issue.
comment:32 by , 10 years ago
Please let us know if you hit the problem again.
OK http://buildbot.haiku-os.org/buildslaves/luroh-bot1-xubuntu64 - no bug
Possible candidates are:
btrev43089 hrev47741 hrev47742