http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=ATS1315-ND
Unfortunately, it didn't solve the particular problem I was seeing
(random hangs during heavy compiles) despite the cpu being cooler (it
seems, based on bottom-of-board temp).
I also got one of these but fried it before I could put it in place:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=563-1108-ND
(stupid smart fans ;)
> This heatsink looks nice. Fan quite dangerously -- 8k RPM! :-) Well,
> do you use this temp monitoring program?
> http://hardwarebug.org/files/omap4_temp.c -- do you think it provides
> temperatures in Celsius or Fahrenheit? If in C, then my board is in
> real danger I guess while compiling for a few minutes where it goes up
> to 91.
Those temperatures are Celsius. 91 is a bit high, but still within a
reasonable range. TJmax is typically over 100 C for devices like this,
although I can't find a figure for the OMAP4430.
--
Måns Rullgård
ma...@mansr.com
btw, which kernel, and what bootargs?
This sounds a bit similar to highmem bugs that were seen on 2.6.35 kernel
BR,
-R
Karel Gardas <karel....@gmail.com> writes:
> 2011/6/27 Måns Rullgård <ma...@mansr.com>:
>> Karel Gardas <karel....@gmail.com> writes:
>>
>>> Hello,
>>>
>>> am I right you are the author of this excellent temp monitoring tool
>>> for Pandaboard? If so, then I've observed one issue with it. If you
>>> keep it running in a loop like:
>>>
>>> while(true)
>>> do
>>> sudo ./omap4_temp
>>> sleep 5
>>> done
>>>
>>> for some time, it'll stop working and in fact start consume 100% CPU.
>>> When this happen there is no way to recover temp reading again.
>>> Perhaps reboot will be able to help, but I've not rebooted my board
>>> yet.
>>>
>>> Have you seen this behavior already?
>>
>> No, I haven't seen that happen. Could you try to find out where it is
>> hanging? There are two loops that spin until a particular bit in a
>> register is set or cleared, and it seems like this isn't happening for
>> some reason. Attaching a debugger should tell where it is stuck.
>>
> It's the first cycle, line 90:
>
> 88
> 89 *temp = 0x200;
> 90 while (!(*temp & 0x100)) __asm__ ("" ::: "memory");
> 91 *temp = 0;
> 92 while (*temp & 0x100) __asm__ ("" ::: "memory");
> 93 tempval = *temp;
> 94
--
Måns Rullgård
ma...@mansr.com
overheated?
>
> Karel Gardas<karel....@gmail.com> writes:
>
>> 2011/6/27 M�ns Rullg�rd<ma...@mansr.com>:
>>> Karel Gardas<karel....@gmail.com> writes:
>>>
>>>> Hello,
>>>>
>>>> am I right you are the author of this excellent temp monitoring tool
>>>> for Pandaboard? If so, then I've observed one issue with it. If you
>>>> keep it running in a loop like:
>>>>
>>>> while(true)
>>>> do
>>>> sudo ./omap4_temp
>>>> sleep 5
>>>> done
>>>>
>>>> for some time, it'll stop working and in fact start consume 100% CPU.
>>>> When this happen there is no way to recover temp reading again.
>>>> Perhaps reboot will be able to help, but I've not rebooted my board
>>>> yet.
>>>>
>>>> Have you seen this behavior already?
>>>
>>> No, I haven't seen that happen. Could you try to find out where it is
>>> hanging? There are two loops that spin until a particular bit in a
>>> register is set or cleared, and it seems like this isn't happening for
>>> some reason. Attaching a debugger should tell where it is stuck.
>>>
>> It's the first cycle, line 90:
>>
>> 88
>> 89 *temp = 0x200;
>> 90 while (!(*temp& 0x100)) __asm__ ("" ::: "memory");
>> 91 *temp = 0;
>> 92 while (*temp& 0x100) __asm__ ("" ::: "memory");
it's a crystal oscillator.