Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Jan 2011 23:39:16 +0100
From:      "Arno J. Klaassen" <arno@heho.snv.jussieu.fr>
To:        Alexander Motin <mav@FreeBSD.org>
Cc:        acpi@FreeBSD.org, John Baldwin <jhb@FreeBSD.org>
Subject:   Re: Tyan S3992-E: hpet no longer working
Message-ID:  <wpoc7o1izv.fsf@heho.snv.jussieu.fr>
In-Reply-To: <4D2B8944.6030200@FreeBSD.org> (Alexander Motin's message of "Tue\, 11 Jan 2011 00\:33\:40 %2B0200")
References:  <wpk4ij3u9f.fsf@heho.snv.jussieu.fr> <201101101500.45783.jhb@freebsd.org> <4D2B67E4.70907@FreeBSD.org> <201101101515.47127.jhb@freebsd.org> <wpwrmc4f9n.fsf@heho.snv.jussieu.fr> <4D2B8944.6030200@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Motin <mav@FreeBSD.org> writes:

> Arno J. Klaassen wrote:
>> Sure .. that said, the BIOS I use is the last official release for this
>> board (Sept 2009) and not even a more recent beta-release is available.
>> 
>> I would expect reporting a disabled device which cannot be enabled via
>> de BIOS a bug deserving a newer release.
>> 
>> Anyway, this bug isn't very harmful for me, but the non-hpet
>> timecounters don't seem that fun either :
>> 
>>  # uptime
>>    10:27PM  up 2 days,  5:44
>> 
>>  # sysctl kern.timecounter.hardware kern.timecounter.choice 
>>    kern.timecounter.hardware: ACPI-safe
>>    kern.timecounter.choice: TSC(-100) i8254(0) ACPI-safe(850) dummy(-1000000)
>> 
>>  # vmstat -i | fgrep cpu:
>>    cpu0:timer                      38599321        199
>>    cpu6:timer                       2151003         11
>>    cpu1:timer                       7121075         36
>>    cpu3:timer                       1808269          9
>>    cpu5:timer                       3832463         19
>>    cpu2:timer                       2399988         12
>>    cpu7:timer                       2013444         10
>>    cpu4:timer                      21630368        111
>> 
>>   (default HZ ....)
>> 
>> Maybe I should try downgrading the BIOS?
>
> So what here seems not funny to you? Lower timer interrupt rate is not a
> bug but feature of 9-CURRENT.

the standard deviation in the values; I don't have another 8-way by
hand, but a 4-way 6-STABLE gives :

  cpu0: timer                   3299774936       2000
  cpu2: timer                   3299757640       2000
  cpu3: timer                   3299757640       2000
  cpu1: timer                   3299757640       2000

and my 8-STABLE notebook (with kern.hz=100) :

  cpu0: timer                    323161363        400
  cpu1: timer                    323161114        400

A range from 9 to 199 is 'funny', maybe I choose the wrong word, but
I didn't see such discrepancies before. Sorry

Best, Arno




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?wpoc7o1izv.fsf>