Re: [patch] enhance powerd(8) to handle max temperature
On Thu, 2007-08-02 at 22:13 -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> "Alexandre \"Sunny\" Kovalenko" <[EMAIL PROTECTED]> writes:
> : On Thu, 2007-08-02 at 10:08 -0700, Nate Lawson wrote:
> : > M. Warner Losh wrote:
> : > > In message: <[EMAIL PROTECTED]>
> : > > Nate Lawson <[EMAIL PROTECTED]> writes:
> : > > : Hajimu UMEMOTO wrote:
> : > > : >> On Mon, 30 Jul 2007 23:31:33 +0200
> : > > : >> Pietro Cerutti <[EMAIL PROTECTED]> said:
> : > > : > gahr> My patch is really just a first draft that I wrote in order
> to have
> : > > : > gahr> feedbacks on the general idea to implement a temperature
> controlling
> : > > : > gahr> system inside powerd, and doesn't implement hysteresis as you
> noted, and
> : > > : > gahr> your feedback is that it's not a good idea, which I respect.
> : > > : >
> : > > : > It is rather backward, IMHO. I did implement a passive cooling
> : > > : > feature as an enhancement of powerd(8) like you did, during initial
> : > > : > phases. Then, I implemented it in our kernel as a result.
> : > > :
> : > > : I'll take a look at your patch. Umemoto-san is right in that you
> really
> : > > : want the kernel to control cooling. What happens if powerd dies/hangs
> : > > : and your system burns up? Passive cooling is often a last resort to
> : > > : keep the system from overheating.
> : > >
> : > > I keep getting the system shutting down on my HP by FreeBSD because
> : > > the temperature exceeds the _CRT value. Maybe there's something wrong
> : > > with my values, since it happens a lot:
> : > >
> : > > hw.acpi.thermal.min_runtime: 0
> : > > hw.acpi.thermal.polling_rate: 10
> : > > hw.acpi.thermal.user_override: 0
> : > > hw.acpi.thermal.tz0.temperature: 0.0C
> : > > hw.acpi.thermal.tz0.active: -1
> : > > hw.acpi.thermal.tz0.passive_cooling: 1
> : > > hw.acpi.thermal.tz0.thermal_flags: 0
> : > > hw.acpi.thermal.tz0._PSV: 90.0C
> : > > hw.acpi.thermal.tz0._HOT: -1
> : > > hw.acpi.thermal.tz0._CRT: 94.0C
> : > > hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1
> : > >
> : > > Note: temperature is always 0.0C.
> : > >
> : > > What can I do to help my situation, if I really want the kernel doing
> : > > the cooling?
> : >
> : > Your embedded controller is timing out. Thus you're getting a bogus
> : > value for _TMP.
> : I have sort of picked up this thread in the middle... was it determined
> : that EC is timing out? The reason for asking is -- I used to have a
> : laptop where _TMP would just read value from the memory location, which
> : was never populated anywhere else in ASL. Call to _PSV method would go
> : figure current temperature and start fan, if necessary. Ugly...
> :
> : Dumping ASL (using instructions from handbook) and looking for something
> : like
> :
> : Method (_TMP, 0, NotSerialized)
> :
> : might be a real eye opener.
> :
> : If you would like me to take a look at your ASL, send it to me privately
> : -- I've only done it for one laptop, so no claims of the great skill
> : there, but maybe it is as simple as the other one ;)
It just dawned on me that I have hit Reply, not Reply All previously,
which has likely caused my reply to be buried somewhere in the bowels of
your SPAM filtering software. So, here it goes again:
>
> Method (_TMP, 0, NotSerialized)
> {
> If (\_SB.PCI0.LPC0.ECOK ())
> {
> Multiply (\_SB.PCI0.LPC0.EC0.THEM, 0x0A, Local0)
> Add (Local0, 0x0AAC, Local0)
> Return (Local0)
> }
>
> Return (DTMP)
> }
Could you, please, change
Return(DTMP)
in the snippet above to
Return(0x0B10)
compile your ASL, overwrite it on boot and let me know what temperature
reading is -- it either will stay at 0.0C or at 10.0C, which is not at
all useful for day-to-day operation but will tell me which code path has
been taken.
Also, please, either send me *all* of your ASL or put it up somewhere
for download.
--
Alexandre "Sunny" Kovalenko
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
debug kernels + -fomit-frame-pointer == unhappy gdb
Just got reminded of this... I noticed some kernel builds use -fomit-frame-pointer by default, even if you do a debug kernel. That kinda defeats the purpose since gdb uses the frame pointer when examining the stack, like, when doing backtraces, i.e. you lose function calls in backtraces when the kernel is built like that. So, should this be changed? Juergen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pccard0: Card has no functions!
Hi, I have Nokia Card Phone 2.0 (on a supported HW list) in a PCMCIA to PCI adapter. I have used this combination some time ago (2-3 years) and it worked without any problems. I don't remember what FreeBSD version I used that time. I tried to get it working under FreeBSD 6.2R today but was not successful. I can see those messages after boot: Status is 0x3410 cbb0: card inserted: event=0x, state=3410 pccard0: chip_socket_enable cbb_pcic_socket_enable: cbb0: cbb_power: 5V pccard0: read_cis cis mem map 0xe7286000 (resource: 0xfe31) pccard0: CIS tuple chain: CISTPL_END ff cis mem map e7286000 CISTPL_LINKTARGET expected, code ff observed pccard0: check_cis_quirks pccard0: Card has no functions! cbb0: PC Card card activation failed I have spent hours on google trying to find any solution how to make it work. I have played with the hw.cbb.start_memory, tried to disable acpi, recompiled a GENERIC kernel... Any help would be wellcomed. Relevant messages from dmesg (full dmesg at http://artax.karlin.mff.cuni.cz/~cernm0bm/claire.dmesg.txt): acpi0: on motherboard pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib5: at device 30.0 on pci0 pci5: on pcib5 cbb0: irq 23 at device 2.0 on pci5 cbb0: Found memory at fe30 cbb0: Secondary bus is 6 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 /boot/loader.conf: hw.pci.allow_unsupported_io_range="1" hw.cbb.start_memory="0x8600" hw.cbb.debug="1" hw.cardbus.debug="1" hw.cardbus.cis_debug="1" hw.pccard.debug="1" hw.pccard.cis_debug="1" pciconf -lv: [EMAIL PROTECTED]:2:0: class=0x060700 card=0x010114ef chip=0x04751180 rev=0x80 hdr=0x02 vendor = 'Ricoh Co Ltd' device = 'RL5c475 CardBus Controller' class= bridge subclass = PCI-CardBus Regards, Marian Cerny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Australian cvs repository
On 16/08/2007, at 8:49 AM, [EMAIL PROTECTED] wrote: Robert McKenzie wrote: Has anyone noted that the Australian cvs repository seems to be so hopelessly out of sink that you cannot do a clean build using a clean cvsup. Because we are so far away it is hard to keep things sinkronized. We really need to plug those holes. Aaargh! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Australian cvs repository
Kris Kennaway <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: > > Robert McKenzie <[EMAIL PROTECTED]> writes: > > > Has anyone noted that the Australian cvs repository seems to be so > > > hopelessly out of sink that you cannot do a clean build using a > > > clean cvsup. > > Because we are so far away it is hard to keep things sinkronized. > How is that the case? Humor detector on the fritz again, Kris? :) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Australian cvs repository
On Thu, Aug 16, 2007 at 08:49:21AM +1000, [EMAIL PROTECTED] wrote: > Robert McKenzie wrote: > > Has anyone noted that the Australian cvs repository seems to be so > > hopelessly out of sink that you cannot do a clean build using a clean > > cvsup. > > Because we are so far away it is hard to keep things sinkronized. How is that the case? Kris pgpvFAMUF7waG.pgp Description: PGP signature
Re: Australian cvs repository
Robert McKenzie wrote: > Has anyone noted that the Australian cvs repository seems to be so > hopelessly out of sink that you cannot do a clean build using a clean > cvsup. Because we are so far away it is hard to keep things sinkronized. -- tonym ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Modifying bridged traffic
Eric Anderson wrote: What is the easiest way to play with modifying data in-transit within an ethernet bridge? For instance, say I have something like this: [BOX 1] <> [ BOX 2 ] <> [ BOX 3 ] And BOX 2 is a FreeBSD box with bridging enabled between two ethernet interfaces, how can I parse/modify the ethernet frames as they pass through? maybe with the help of netgraph... (ng_ether, ng_tee etc). Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Liar, n.: A lawyer with a roving commission. -- Ambrose Bierce, "The Devil's Dictionary" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Modifying bridged traffic
Eric Anderson wrote: What is the easiest way to play with modifying data in-transit within an ethernet bridge? For instance, say I have something like this: [BOX 1] <> [ BOX 2 ] <> [ BOX 3 ] And BOX 2 is a FreeBSD box with bridging enabled between two ethernet interfaces, how can I parse/modify the ethernet frames as they pass through? a netgraph bridge can do that (you can hook two ng_bridges together and capture all the packets that flow between them... There are also some patches that allow divert sockets to be attached to a bridging ipfw firewall. Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
