CPU problems after 8.0-STABLE update
Akephalos Akephalos
I installed 8.0 release and used it very briefly until updating through
cvsup to the latest stable source. I had no problems with the release (DVD)
version, except that my wireless card wasn't detected, so updating was the
natural thing to do. My hardware is an ASUS dual Turion laptop (K50AB), and
my working setup was like this:
- /boot/loader.conf:
cpufreq_load="YES"
hint.acpi_throttle.0.disabled="1"
- /etc/rc.conf:
powerd_enable="YES"
It was working fine, the CPU frequency was scaling as expected, I checked it
numerous times while working and idle with 'sysctl dev.cpu.0.freq'. Also,
the load was displayed correctly in the taskmanager (I don't remember what
was displayed in 'top', but I suppose it was ok).
Now, after updating through buildworld, powerd doesn't scale the frequency
anymore. My observations pointed out that the problem is that the CPU load
is not detected correctly anymore:
- I got three frequency steps: 575, 1150 and 2300 (correctly detected by
dev.cpu.0.freq_levels while cpufreq module is loaded), but powerd scales
down the frequency to the minimum, 575 then keeps it like that no matter of
the load - dev.cpu.0.freq shows 575 and I got large build times because of
it. To be able to use it fully, I have to kill powerd and set the frequency
manually, or disable it at startup.
- 'top -P' displays only one CPU and its load is 0% everything all the time,
despite any load
- I can't see anything in a taskmanager, the last time I tried with xfce and
CURRENT (CURRENT had the same issue)
- dev.cpu.0.cx_usage shows 100%.
---
I'd like to find out the problem, why the CPU level is not detected
correctly and how to fix this/report.
Thanks,
Mihai
Andriy Gapon
> - 'top -P' displays only one CPU and its load is 0% everything all the time,
> despite any load
So this is probably the root cause.
Do you I have any unusual messages in dmesg after the upgrade?
Anything about RTC?
--
Andriy Gapon
Attilio Rao
What architecture is it?
May you try setting machdep.lapic_allclocks to 1 in /boot/loader.conf?
May you report #dmesg | grep atrtc
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
Akephalos Akephalos
the system installed at all so i won't be able to test the issue any more.
@Andriy: I checked dmesg for RTC (with grep -i) and is was not there. Among
the messages it seemed that the system detected my dual CPU type and stuff.
There was something containing 'rtc', possibly 'atrtc' what Attilio asked
for, but it's irrelevant as long as I don't remember the message - it didn't
seem to e an error.
@Attilio: my CPU is AMD Turion 64 X2. Because I don't have FreeBSD installed
any more, I can't tell you the report, I am very sorry, my computer was not
usable as a workstation (port-related) and I was forced to uninstall to try
something else.
I think the problem can be replicated on any computer with this processor,
it happened to me for two times, once updating to CURRENT and once to
STABLE, through buildkernel/world, hopefully someone else will be able to
provide the feedback.
Thank you!
Mihai
Andriy Gapon
So we weren't fast enough and lost you :-(
Holidays, you know.
--
Andriy Gapon
Akephalos
Andriy Gapon <a...@icyb.net.ua> wrote:
>
> So we weren't fast enough and lost you :-(
> Holidays, you know.
>
> --
> Andriy Gapon
It's ok, I had to experiment fast with different things. My intention is to rebuild the system up to the next week-end - if I have the time, with overnight buildings, maybe tomorrow or so and I'll come up with the answers you require.
Cheers,
Mihai
Akephalos Akephalos
> What architecture is it?
> May you try setting machdep.lapic_allclocks to 1 in /boot/loader.conf?
> May you report #dmesg | grep atrtc
>
>
> Thanks,
> Attilio
>
>
> --
> Peace can only be achieved by understanding - A. Einstein
>
# dmesg | grep -B 5 -A 5 -i rtc
acpi_button0: <Sleep Button> on acpi0
acpi_button1: <Power Button> on acpi0
acpi_tz0: <Thermal Zone> on acpi0
battery0: <ACPI Control Method Battery> on acpi0
acpi_acad0: <AC Adapter> on acpi0
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
---
I set machdep.lapic_allclocks to 1 at statup - top works now!! I can see
both processors with top -P, btw, everything looks fine, although I get core
dump for xfce4-taskmanager and can't test it (it's probably related to
something else).
---
I started powerd - it scales the frequencies correctly now.
This seems to be the solution, is this a bug should I report or leave things
like this?
Thanks a lot!
Mihai
Andriy Gapon
> On Sun, Apr 4, 2010 at 7:28 PM, Attilio Rao <att...@freebsd.org
> <mailto:att...@freebsd.org>> wrote:
>
> What architecture is it?
> May you try setting machdep.lapic_allclocks to 1 in /boot/loader.conf?
> May you report #dmesg | grep atrtc
>
>
> Thanks,
> Attilio
>
>
> --
> Peace can only be achieved by understanding - A. Einstein
>
>
> # dmesg | grep -B 5 -A 5 -i rtc
> acpi_button0: <Sleep Button> on acpi0
> acpi_button1: <Power Button> on acpi0
> acpi_tz0: <Thermal Zone> on acpi0
> battery0: <ACPI Control Method Battery> on acpi0
> acpi_acad0: <AC Adapter> on acpi0
> atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> kbd0 at atkbd0
> atkbd0: [GIANT-LOCKED]
> atkbd0: [ITHREAD]
> ---
Is this before or after setting machdep.lapic_allclocks?
If after, could you please check what happens without the change?
> I set machdep.lapic_allclocks to 1 at statup - top works now!! I can see
> both processors with top -P, btw, everything looks fine, although I get
> core dump for xfce4-taskmanager and can't test it (it's probably related
> to something else).
> ---
>
> I started powerd - it scales the frequencies correctly now.
>
> This seems to be the solution, is this a bug should I report or leave
> things like this?
Bug report never hurts :-)
Could you please tell us what system us this (motherboard model)?
Also, could you post output of acpidump -dt?
Thanks!
--
Andriy Gapon
Attilio Rao
Uhm, may you tell me which revision did you update to? May you update
to the latest now, recompile your kernel, remove the hint
machdep.lapic_allclocks and report if it works or not?
Akephalos
Attilio Rao <att...@freebsd.org> wrote:
> > I set machdep.lapic_allclocks to 1 at statup - top works now!! I can see
> > both processors with top -P, btw, everything looks fine, although I get core
> > dump for xfce4-taskmanager and can't test it (it's probably related to
> > something else).
> > ---
> >
> > I started powerd - it scales the frequencies correctly now.
> >
> > This seems to be the solution, is this a bug should I report or leave things
> > like this?
>
> Uhm, may you tell me which revision did you update to? May you update
> to the latest now, recompile your kernel, remove the hint
> machdep.lapic_allclocks and report if it works or not?
>
> Thanks,
> Attilio
>
>
> --
> Peace can only be achieved by understanding - A. Einstein
Attilio, I csup-dated several hours ago and rebuilt and installed the kernel (and world, in case it matters).
%uname -a
FreeBSD free.bsd369441.org 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Apr 8 03:01:13 EEST 2010 ro...@free.bsd369441.org:/usr/obj/usr/src/sys/GENERIC amd64
The problem persists without the machdep trick, I see only one processor in top with 0.0% CPU load.
--
Akephalos
Andriy Gapon
> Attilio, I csup-dated several hours ago and rebuilt and installed the kernel
> (and world, in case it matters).
>
> %uname -a FreeBSD free.bsd369441.org 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu
> Apr 8 03:01:13 EEST 2010
> ro...@free.bsd369441.org:/usr/obj/usr/src/sys/GENERIC amd64
>
> The problem persists without the machdep trick, I see only one processor in
> top with 0.0% CPU load.
>
Interesting, I couldn't see anything obviously wrong about your hardware.
Could you please post a verbose dmesg from a problematic boot somewhere?
Also, output of 'vmstat -i' and Interrupt request lines portion of 'devinfo -u'
output.
Thanks!
--
Andriy Gapon
Andriy Gapon
> 2010/4/8 Andriy Gapon <a...@icyb.net.ua>:
> anything wrong with it.
> Also the fact that the setting machdep.lapic_all=1 fixes this means
> that this may be an atrtc working problem.
> Maybe new atom machine expose a problem with it?
This doesn't look like an atom machine :-)
A mobile AMD rather.
> I'm thinking if we might switch this into an opt-in rather than an
> opt-out feature.
What's strange is that there is no diagnostics from RTC.
--
Andriy Gapon
Attilio Rao
I watched again the patch I committed to STABLE_8 and I can't find
anything wrong with it.
Also the fact that the setting machdep.lapic_all=1 fixes this means
that this may be an atrtc working problem.
Maybe new atom machine expose a problem with it?
I'm thinking if we might switch this into an opt-in rather than an
opt-out feature.
Attilio
Akephalos
Andriy Gapon
Thank you for the data.
So looks like RTC indeed doesn't generate any interrupts after startup.
Still I would like to get a _verbose_ dmesg :-)
--
Andriy Gapon
Andriy Gapon
> On Thu, 08 Apr 2010 16:33:09 +0300
> Andriy Gapon <a...@icyb.net.ua> wrote:
>
>> Thank you for the data.
>> So looks like RTC indeed doesn't generate any interrupts after startup.
>> Still I would like to get a _verbose_ dmesg :-)
>>
>> --
>> Andriy Gapon
>
>
> Mihai
>
Everything seems to be correct, yet RTC doesn't work...
Could yo please also send output of the following command:
dd if=/dev/mem bs=0x1000 skip=0xfed00 count=1 | hd
--
Andriy Gapon
Akephalos
Andriy Gapon <a...@icyb.net.ua> wrote:
> on 08/04/2010 15:44 Akephalos said the following:
> > On Thu, 08 Apr 2010 16:33:09 +0300
> > Andriy Gapon <a...@icyb.net.ua> wrote:
> >
> >> Thank you for the data.
> >> So looks like RTC indeed doesn't generate any interrupts after startup.
> >> Still I would like to get a _verbose_ dmesg :-)
> >>
> >> --
> >> Andriy Gapon
> >
> > Sorry, I missed that, here it is :D.
> >
> > Mihai
> >
>
> Everything seems to be correct, yet RTC doesn't work...
> Could yo please also send output of the following command:
> dd if=/dev/mem bs=0x1000 skip=0xfed00 count=1 | hd
>
> --
> Andriy Gapon
Here it is:
---
00000000 01 83 53 43 7e b1 29 04 00 00 00 00 00 00 00 00 |..SC~.).........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 10 80 00 00 ff ff c0 00 ff ff ff ff 00 00 00 00 |................|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000120 10 80 00 00 ff ff c0 00 ff ff ff ff 00 00 00 00 |................|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000140 10 80 00 00 ff ff c0 00 ff ff ff ff 00 00 00 00 |................|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00001000
---
Thanks,
Mihai
--
Akephalos
Andriy Gapon
Really shooting in the dark here: are there any BIOS options about HPET and RTC on
this system? Can you try playing with them?
--
Andriy Gapon
Jakub Lach
Andriy Gapon wrote:
>
>
> Really shooting in the dark here: are there any BIOS options about HPET
> and RTC on
> this system? Can you try playing with them?
>
>
Hello. I have similar problem. Once in few boots performance would be
sluggish and
top would be at 0%. It started on 4th April I think. After today's update,
problem is persistent.
Currently, as I type letters are appearing with considerable delay.
I'm using HPET, 8-STABLE amd64 r206412
(Thinkpad T400)
best regards,
-Jakub Lach
--
View this message in context: http://old.nabble.com/CPU-problems-after-8.0-STABLE-update-tp28131503p28189840.html
Sent from the freebsd-stable mailing list archive at Nabble.com.
Attilio Rao
>
>
>
> Andriy Gapon wrote:
>>
>>
>> Really shooting in the dark here: are there any BIOS options about HPET
>> and RTC on
>> this system? Can you try playing with them?
>>
>>
>
> Hello. I have similar problem. Once in few boots performance would be
> sluggish and
> top would be at 0%. It started on 4th April I think. After today's update,
> problem is persistent.
> Currently, as I type letters are appearing with considerable delay.
>
> I'm using HPET, 8-STABLE amd64 r206412
Ok, r206421 switches the default tunable for machdep.lapic_allclock in
order to enable atrtc usage only if it is properly turned off.
I will MFC in a week.
Akephalos
I'm sorry for this late reply.
I can't see any option like that in bios, unfortunately, there are few options that can be changed. In case it was forgotten, on the firs install (8.0 release version) it was all fine, I think diffing or tracing the changes from there might point to a solution?
Thanks,
Mihai