2011/4/18 :
> I don't seem to have a hw.acpi.thermal sysctl node on my box. Can
> someone please try this patch?
Works for me too.
$> sysctl -a | grep temp
[...]
hw.acpi.thermal.tz0.temperature: 62.0C
dev.cpu.0.temperature: 55.0C
dev.cpu.1.temperature: 56.0C
[...]
By the way, why the temperatu
On 2011/04/20 10:48, Ryan Stone wrote:
> On Tue, Apr 19, 2011 at 10:13 PM, David Xu wrote:
>> Have you tested that current code causes segfault ?
>> anyway, I can not reproduce it on my machne.
>>
>> Regards,
>> David Xu
>
> Yes, I had an application where libstdc++ was calling pthread_once
> whi
On Tue, Apr 19, 2011 at 10:58 PM, David Xu wrote:
>
> But I don't touch curthread unless it is blocked by another thread.
>
You do a THR_CLEANUP_PUSH(curthread, once_cancel_handler,
once_control); before calling *init_routine. THR_CLEANUP_PUSH touches
curthread->cleanup;
On 2011/04/20 10:48, Ryan Stone wrote:
> On Tue, Apr 19, 2011 at 10:13 PM, David Xu wrote:
>> Have you tested that current code causes segfault ?
>> anyway, I can not reproduce it on my machne.
>>
>> Regards,
>> David Xu
>
> Yes, I had an application where libstdc++ was calling pthread_once
> whi
Masoom Shaikh wants you to try Dropbox! Dropbox lets you bring all your photos,
docs and videos with you anywhere and share them easily.
Get started here:
http://www.dropbox.com/link/20.19I4vT5g3K/Njg3MzIzMDI4Nw?src=referrals_bulk9
- The Dropbox Team
___
On Tue, Apr 19, 2011 at 10:13 PM, David Xu wrote:
> Have you tested that current code causes segfault ?
> anyway, I can not reproduce it on my machne.
>
> Regards,
> David Xu
Yes, I had an application where libstdc++ was calling pthread_once
while constructing a static object. As near as I can t
On 2011/04/20 00:53, Ryan Stone wrote:
> In r179417 the implementation of pthread_once in libthr was changed
> from using a global pthread_mutex_t for synchronization to rolling its
> own synchronization mechanism. Unfortunately, this introduced a bug.
> Calling _pthread_mutex_lock implicitly ensu
On Tue, Apr 19, 2011 at 08:17:37PM -0400, J. Hellenthal wrote:
>On Tue, Apr 19, 2011 at 02:22:10PM +0200, Ulrich Spörlein wrote:
>>On Tue, 19.04.2011 at 12:15:00 +0100, Bruce Cran wrote:
>>> There's a new tool that can be used to find spelling mistakes in code:
>>> codespell
>>> from http://www.p
On Tue, Apr 19, 2011 at 02:22:10PM +0200, Ulrich Spörlein wrote:
>On Tue, 19.04.2011 at 12:15:00 +0100, Bruce Cran wrote:
>> There's a new tool that can be used to find spelling mistakes in code:
>> codespell
>> from http://www.politreco.com has already been used to find mistakes in both
>> Linu
on 19/04/2011 21:02 Doug Barton said the following:
> On 4/19/2011 9:44 AM, m...@freebsd.org wrote:
>> As an aside, what kind of h/w do I need
>> for hw.acpi.thermal to show up? I don't see it on my Dell desktop...
The hardware can be anything with ACPI compatibility, but your DSDT has to
[correc
On Tue, Apr 19, 2011 at 09:44:50AM -0700, m...@freebsd.org wrote:
> On Tue, Apr 19, 2011 at 7:48 AM, Taku YAMAMOTO
> wrote:
> >...
> > We should have 10 _ACx values like this:
> > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
>
> D'oh, I didn't read the original source carefully enough
2011/4/19 :
> On Tue, Apr 19, 2011 at 11:02 AM, Doug Barton wrote:
>> On 4/19/2011 9:44 AM, m...@freebsd.org wrote:
>>>
>>> As an aside, what kind of h/w do I need
>>> for hw.acpi.thermal to show up? I don't see it on my Dell desktop...
>>
>> The hardware is likely to be there for any reasonably
On Tue, Apr 19, 2011 at 11:02 AM, Doug Barton wrote:
> On 4/19/2011 9:44 AM, m...@freebsd.org wrote:
>>
>> As an aside, what kind of h/w do I need
>> for hw.acpi.thermal to show up? I don't see it on my Dell desktop...
>
> The hardware is likely to be there for any reasonably modern Dell desktop.
On 4/19/2011 9:44 AM, m...@freebsd.org wrote:
As an aside, what kind of h/w do I need
for hw.acpi.thermal to show up? I don't see it on my Dell desktop...
The hardware is likely to be there for any reasonably modern Dell
desktop. Do you have coretemp loaded?
Doug
--
Nothin' ever
On 2011-04-19 13:21, Alexander Leidinger wrote:
...
You probably also want to remove the code that uses __INTEL_COMPILER
in source tree if you want to be really thorough.
Ok, new patch attached. Some of the contributed sources also contain
instances of __INTEL_COMPILER, but these are all from
In r179417 the implementation of pthread_once in libthr was changed
from using a global pthread_mutex_t for synchronization to rolling its
own synchronization mechanism. Unfortunately, this introduced a bug.
Calling _pthread_mutex_lock implicitly ensured that _thr_check_init()
had been called. In
On Tue, Apr 19, 2011 at 7:48 AM, Taku YAMAMOTO wrote:
>> This patch works.
>>
>> FreeBSD 9.0-CURRENT #1: Tue Apr 19 10:52:58 MSD 2011
>>
>> # sysctl hw.acpi.thermal
>> hw.acpi.thermal.min_runtime: 0
>> hw.acpi.thermal.polling_rate: 10
>> hw.acpi.thermal.user_override: 0
>> hw.acpi.thermal.tz0.temp
On Tuesday 19 April 2011 13:15:00 Bruce Cran wrote:
> There's a new tool that can be used to find spelling mistakes in code:
> codespell from http://www.politreco.com has already been used to find
> mistakes in both Linux and LLVM. I ran it on sys/ and it found lots of
> potential typos - the full
On 19.04.2011 13:15, Bruce Cran wrote:
There's a new tool that can be used to find spelling mistakes in code: codespell
from http://www.politreco.com has already been used to find mistakes in both
Linux and LLVM. I ran it on sys/ and it found lots of potential typos - the
full diff (which I know
> This patch works.
>
> FreeBSD 9.0-CURRENT #1: Tue Apr 19 10:52:58 MSD 2011
>
> # sysctl hw.acpi.thermal
> hw.acpi.thermal.min_runtime: 0
> hw.acpi.thermal.polling_rate: 10
> hw.acpi.thermal.user_override: 0
> hw.acpi.thermal.tz0.temperature: 67.5C
> hw.acpi.thermal.tz0.active: -1
> hw.acpi.ther
of course I know that Vimage is still very much experimental and still very
much unfinished as well, but I would like to use it to try and set up a box
where everything is seggregated into jails as much as possible, compiling
the kernel with vimage support works like a charm and the system even boo
On Tue, Apr 19, 2011 at 12:15:00PM +0100, Bruce Cran wrote:
> There's a new tool that can be used to find spelling mistakes in code:
> codespell
> from http://www.politreco.com has already been used to find mistakes in both
> Linux and LLVM. I ran it on sys/ and it found lots of potential typos
On Tue, 19.04.2011 at 12:15:00 +0100, Bruce Cran wrote:
> There's a new tool that can be used to find spelling mistakes in code:
> codespell
> from http://www.politreco.com has already been used to find mistakes in both
> Linux and LLVM. I ran it on sys/ and it found lots of potential typos - th
Quoting Dimitry Andric (from Mon, 18 Apr 2011
21:47:00 +0200):
On 2011-04-18 16:34, Alexander Kabaev wrote:
...
Please review the attached patch, which cleans up the ICC bits.
You probably also want to remove the code that uses __INTEL_COMPILER
in source tree if you want to be really thoro
There's a new tool that can be used to find spelling mistakes in code:
codespell
from http://www.politreco.com has already been used to find mistakes in both
Linux and LLVM. I ran it on sys/ and it found lots of potential typos - the
full diff (which I know does contain some incorrect changes)
On Mon, Apr 18, 2011 at 08:43:56AM -0700, m...@freebsd.org wrote:
> On Mon, Apr 18, 2011 at 5:05 AM, John Baldwin wrote:
> >
> > I suspect it is still there, but sysctl doesn't know how to display it
> > anymore. This is probably due to the changes with formatting of sysctl
> > information. ?mdf@
26 matches
Mail list logo
