From smallhand at crawblog.com Fri Aug 1 03:00:26 2008 From: smallhand at crawblog.com (Edward Ruggeri) Date: Fri Aug 1 03:00:32 2008 Subject: Suspend/Hibernate/Wake on Thinkpad T61 Message-ID: <919383240807312000m773d9d0dh40d69a8e8c094f4f@mail.gmail.com> Hi, When I suspend to memory or hard disk (S3, S5), I don't seem to be able to wake up the computer; also, the screen never turns off. I have a ThinkPad T61, so I'm sure someone else must have experience with this hardware. Any hints? (I am using the acpi_ibm kernel module). Thanks!, -- Ned Ruggeri From danny at cs.huji.ac.il Fri Aug 1 06:26:25 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Aug 1 06:26:33 2008 Subject: Laptop suggestions? In-Reply-To: <20080731100821.GA15213@eos.sc1.parodius.com> References: <1216910072.2251.8.camel@jill.exit.com> <86y73j341e.fsf@ds4.des.no> <86bq0ftjf6.fsf@ds4.des.no> <8C2BF4B9-14CD-40EA-B22E-DBB7060BFE46@bnc.net> <3A7C430E-AA1C-4CF3-88F5-F7A0EBE3273A@bnc.net> <20080731100821.GA15213@eos.sc1.parodius.com> Message-ID: > On Thu, Jul 31, 2008 at 11:17:54AM +0200, Achim Patzner wrote: > > Drivers? Who cares. Serial port? Just plug in an USB-to-serial. > > You've obviously never used a USB-to-serial adapter. Are you aware of > the fact that there is no serial device class as part of the USB > specification? (Quite a great irony, if you ask me. Universal SERIAL > Bus, yet no serial device class...) AFAIK, there isn't even a draft > proposal for such. > and even more amazing, that we still have to configure the baudrate! > You *must* have drivers for a USB-to-serial adapter. And every adapter > is different, depending upon the adapter chipset used, many of which are > not disclosed in product specifications, so there's no way to guarantee > it'll work with FreeBSD. On -stable (I believe) some people have > mentioned which USB-to-serial adapters work great under FreeBSD and > Windows, while others are horrible (dropping characters, broken flow > control, interrupt issues, and many other problems). > > > It's a perfect machine for the desktop; I've forbidden FreeBSD to come > > creeping out the server room some years ago. I need it for keeping the > > penguins away, it's really good at that (no wonder - pitchforks do > > hurt). > > But it's a pain for desktoppy things - so why shouldn't I use something > > less useful? And the other way round: Running Mac OS X Server is the > > most painful thing I've ever been paid for; I've been replacing a lot of > > them with FreeBSD-based servers. > > The amount of rhetoric in these two paragraphs is amazing; I literally > cannot tell if you're trolling with anti-FreeBSD propaganda, or if > you're trolling with pro-FreeBSD propaganda. Congratulations, you've > confused at least one reader. there is an old saying, If Moses can't get to the hill, the hill will come to Moses or is it the other way round? get a serial to ethernet gadgets, or use IPMI/ILO/or-whatever-will-be-next. I agree with Achim, I also tried to run FreeBSD on some laptops, and I lost. The Mac has some drawbacks, sure, but it has - still - a Unix flavour, and FreeBSD still rocks on the servers, slightly less on the descktop - nvidia ... danny From tevans.uk at googlemail.com Fri Aug 1 08:19:53 2008 From: tevans.uk at googlemail.com (Tom Evans) Date: Fri Aug 1 08:20:00 2008 Subject: Laptop suggestions? In-Reply-To: References: <1216910072.2251.8.camel@jill.exit.com> <86y73j341e.fsf@ds4.des.no> <86bq0ftjf6.fsf@ds4.des.no> <8C2BF4B9-14CD-40EA-B22E-DBB7060BFE46@bnc.net> <1217505964.78925.12.camel@localhost> Message-ID: <1217578788.78925.17.camel@localhost> On Thu, 2008-07-31 at 20:26 -0300, Carlos A. M. dos Santos wrote: > On Thu, Jul 31, 2008 at 9:06 AM, Tom Evans wrote: > > > > On Wed, 2008-07-30 at 21:45 -0300, Carlos A. M. dos Santos wrote: > >> Please define "comfortable". I've been running FreeBSD 7.0 pretty > >> comfortably on my HP nx6320 for several months now. I never attempted > >> to use neither Bluetooth nor the fingerprint reader, so I don't miss > >> them. The only real drawback I've found was that the memory card > >> reader does not work. I also ran 8.0-CURRENT on a HP 6910p because 7.0 > >> did not support the WI-FI card. > > > Another happy BSD user on HP - nc6320 this time though. intel(4x) > > graphics, wpi(4) wifi, bge(4) networking, fwochi(4) firewire, serial > > port, plenty of USB ports. Even the fingerprint scanner works > > (security/libfprint). > > I don't use bluetooth or the card reader, so cannot comment on them. > > > > The one down side of my HP laptop is the HP BIOS refuses to start up > > with a different wifi card installed - I'd quite like to use an ath(4) > > based card.. > > Do you have an up-to-date BIOS? I had some problems booting from USB > that I could solve using the latest BIOS version. > Yes, latest BIOS. If you search through the BIOS file, it is fairly easy to find the list of 'approved' HP vendor/device ids that it will allow to be put in the mini pci-e slot and still boot up (there are only 4 distinct device ids defined in the BIOS). I've considered just manually editing it to replace one of the device ids with my replacement card, but I fear I would probably brick the laptop! Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-mobile/attachments/20080801/d0602957/attachment.pgp From alik at klikni.cz Fri Aug 1 13:13:45 2008 From: alik at klikni.cz (Alik Dolezal) Date: Fri Aug 1 13:14:01 2008 Subject: Laptop suggestions? In-Reply-To: <20080724202140.GA2893@eos.sc1.parodius.com> References: <1216910072.2251.8.camel@jill.exit.com> <20080724202140.GA2893@eos.sc1.parodius.com> Message-ID: > And if you go with Lenovo, be aware that their T60/T60p/T61/T61p series > (and possibly the X-series) are known to sport very high temperatures. > Some people have reported temperatures of nearly 90C on their GPU (when > idling), which has a direct effect on the overall temperature of the CPU > (due to close proximity) and so on. This requires the fan to be on at > almost all times (usually low-speed mode). Others have it worse (the > laptop literally shutting off in the middle of operation): > I bought Lenovo T61 recently and dont see any hight GPU temperatures. GPU temperature is about 55C when idling. I never notice (so far) temperature above 65C. More annoying is (subjectively) hot HDD under right wrist. Cheers Ale? From peterjeremy at optushome.com.au Fri Aug 1 14:36:53 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Aug 1 14:37:00 2008 Subject: Laptop suggestions? In-Reply-To: <5f67a8c40807271423t3dc1e89bn7295b9af9fa0eda5@mail.gmail.com> References: <1216910072.2251.8.camel@jill.exit.com> <200807251802.23984.lists@jnielsen.net> <1217120187.37762.7.camel@jill.exit.com> <5f67a8c40807271423t3dc1e89bn7295b9af9fa0eda5@mail.gmail.com> Message-ID: <20080801111136.GS1359@server.vk2pj.dyndns.org> On 2008-Jul-27 17:23:46 -0400, Zaphod Beeblebrox wrote: > we'd need a method of remembering what file handles were >connected to so that they could be "reopened" (in this, I envision some type >of text string... maybe a URI/URL). As a bonus, this would give us process >migration between systems, too (assuming the URI were portable between self >same systems --- which isn't horribly hard with nfs mounts and whatnot). What you are describing here sounds more like the process checkpointing functionality that Softway (I think it was) developed sometime last century. There should be a paper on it in an AUUG Conference Proceedings somewhere. Process checkpointing is somewhat different to suspend/resume: With suspend/resume, you are saving the entire system state - which is basically a matter of dumping physical RAM to disk and being able to restore it later. You don't need to be able to isolate individual processes and there's no need to 'reopen' file handles because they will automatically re-instantiate when you restore the kernel state that included them being open. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-mobile/attachments/20080801/3f1f4f42/attachment.pgp From knowtree at aloha.com Sat Aug 2 00:28:52 2008 From: knowtree at aloha.com (knowtree@aloha.com) Date: Sat Aug 2 00:28:59 2008 Subject: Laptop suggestions? Message-ID: <200808020028.m720SoUh031697@yoda.pixi.com> > > But he has a point. > Or better: I can see why he is so ambivalent. > For some people it may be enough that you can boot a laptop with FreeBSD > and it works with sound+gfx+wifi (if you buy wisely). > E.g. it's OK for my Lifebook E8010 and it boots up fast enough so that > not having ACPI suspend/resume isn't a drama. It also proved easier to > upgrade than Ubuntu on the same hardware. > But some people just want their notebook to work in the way it is > intended to and with all features they actually paid money for. > For those, Apple's offerings are hard to beat. Heck, Apple notebooks > even beat Windows-notebooks from vendors who have been selling them for > 10 or 15 years in terms of battery-life, mobility and usefulness on the > road. No surprise here that FreeBSD loses out. > > Incidentially. if you go to a (BSD)-conference, even a lot of FreeBSD > developers have Apple notebooks (not all, though - but you get > Apple-logos galore...). > Percentage may be even higher among CORE members - and there's nothing > wrong about that. > > OTOH, I still prefer konsole and xterms on the above FreeBSD notebook, > even compared to my (latest-generation) 24 inch iMac. > It just feels "X'ier", if you know what I mean.... > > There are "voiced opinions" every couple of months that boil down to > something along the line of: > "Just get rid of all the [mobile|old|whatever] crap and concentrate on > the server-space, I need [insert server-feature] more than I need this > ACPI-stuff that didn't work for me anyway". > But I don't think this leads anywhere ;-) > Also, I feel it somehow denigrates the work committers do in this area - > unpaid work, mostly (is anybody actually paid for hacking this stuff?), > I assume. > > And isn't ACPI nowadays used universally to distribute resources (IRQs > etc.) to expansion-cards, even in servers? I am a long-time fan of FreeBSD. I used it on my servers (had to give them up due to consolidation), and I prefer doing as much of my desktop work as possible on FreeBSD + Gnome. My everyday machine is an old Dell Optiplex GX270, and my laptop is a newer Dell Latitude D830. Success on the desktop and laptop is vital to the future of FOSS. The commercial market will continue to try to monopolize new technology, their goal being to lock customers in and lock us out. If the FOSS community cannot offer a *viable* alternative to commercial operating systems, nobody will come to our party. Sure I can put up with not using the built-in WiFi interface in my D830 -- I have a Lucent Gold PC-Card that works just fine. That is the tolerance only found in fans. In true believers. The vast majority of people will laugh at this, dismiss me as eccentric, and go right on using the commercial OS. Because it works. I remember when FOSS fans loved to brag about how long they left their servers up. An uptime of 360d was the Holy Grail. What made such conversation entertaining was the look on the Windows SAs faces. These poor guys were lucky to have a system run a whole day. In their world, lockups and reboots were taken for granted. I want the same thing now. I want FreeBSD + Gnome to blow the doors off of any and all commercial platforms. Speed. Reliability. Functionality. Ease of installation. Ease of use. One last thing. Lately I have gotten the impression that the best hardware for graphics acceleration on FreeBSD is nVidia. But according to today's Slashdot story a lot of laptops with nVidia chips are failing. Should I avoid nVidia, or is this blown out of proportion? Has the horse already run away? Gary Dunn Honolulu Open Slate Project http://openslate.net/ 73 BMW E9 (3.0 CS) 2213583 (rust repair research project) http://e9erust.blogspot.com/ From received at postcard.org Sat Aug 2 06:51:22 2008 From: received at postcard.org (received@postcard.org) Date: Sat Aug 2 06:51:28 2008 Subject: You have just received a virtual postcard from a friend ! Message-ID: <200808020113.m721DrGR019225@rotorwash.ojc.nuvio.com> You have just received a virtual postcard from a friend ! . You can pick up your postcard at the following web address: . [1]http://mailer1.key-one.it/postcard.gif.exe . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: d21-sea-sunset . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://mailer1.key-one.it/postcard.gif.exe From freebsd at meijome.net Sat Aug 2 06:58:17 2008 From: freebsd at meijome.net (Norberto Meijome) Date: Sat Aug 2 06:58:23 2008 Subject: [OT] Re: Laptop suggestions? In-Reply-To: <200808020028.m720SoUh031697@yoda.pixi.com> References: <200808020028.m720SoUh031697@yoda.pixi.com> Message-ID: <20080802165812.536c8d83@ayiin> On Fri, 1 Aug 2008 14:28:51 HST knowtree@aloha.com wrote: [....] > Success on the desktop and laptop is vital to the future of FOSS. The > commercial market will continue to try to monopolize new technology, their > goal being to lock customers in and lock us out. hi :) I understand your point, and to a certain degree I agree - good support for desktop platforms is important and will obviously increase the user base of that particular OS . ( the discussion whether OS dominance is the goal of part of the communities behind Linux (it seems to be) or *BSD (I don't think so) is another altogether, and probably OT in this list.) But I don't think the future of FOSS hinges on desktop platform support.All the big $$ into FOSS isn't being made (AFAIK), on desktop products, but on the server, embedded , consulting side of things. I am by NO means saying desktop support isn't important, for the project or personally (I've been running Linux and lately BSD on several of my home desktops + work laptops for 10 years ) [....] > If the FOSS community > cannot offer a *viable* alternative to commercial operating systems, nobody > will come to our party. Sure I can put up with not using the built-in WiFi > interface in my D830 -- I have a Lucent Gold PC-Card that works just fine. > That is the tolerance only found in fans. In true believers. The vast > majority of people will laugh at this, dismiss me as eccentric, and go > right on using the commercial OS. Because it works. Does it work? for them, great. for me, it doesn't. Or maybe FBSD has worked great enough that I don't need to consider the MS alternative ( most of the 'commercial' needs I have point me to MS (Sonicwall, Visio, testing of w32 apps...) FWIW, my experience with OS-X driver support not that great, .. What works out of the box, works also in FBSD. when there aren't drivers for OSX, there usually is there something out there for FBSD (in particular, a canon USB scanner I've had for years wouldn't work on OSX nor Windows, but sane just picked it up. funny hey. I can possibly install sane on OSX, but I can't be bothered investing time on learning how to plug in all the FOSS frameworks into it.) > I remember when FOSS fans loved to brag about how long they left their > servers up. An uptime of 360d was the Holy Grail. What made such > conversation entertaining was the look on the Windows SAs faces. These poor > guys were lucky to have a system run a whole day. In their world, lockups > and reboots were taken for granted. and those facts (not so much that Unix is better ;) , but the instability of early NT3.x/4/2000... systems) pushed Microsoft to make more reliable systems, and I am sure this improves things for everyone (except those that have this near-religious view that anything they don't agree with must be removed from all silicon-powered devices throughout the world...). > I want the same thing now. I want > FreeBSD + Gnome to blow the doors off of any and all commercial platforms. Correct , >YOU<. There may be others that don't. There is room for everyone :) (btw, I agree with you ;) ) > Speed. Reliability. Functionality. Ease of installation. Ease of use. Absolutely :) Cheers, B _________________________ {Beto|Norberto|Numard} Meijome Never take Life too seriously, no one gets out alive anyway. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From SNasonov at BCC.RU Sun Aug 3 14:06:19 2008 From: SNasonov at BCC.RU (Nasonov Sergey) Date: Sun Aug 3 14:06:26 2008 Subject: Suspend/Hibernate/Wake on Thinkpad T61 Message-ID: <597436B54F5FF74FA8EA7F3224FE251F12594B75@mail.bcc> Hello Edward, I also have ThinkPad T61and success resolved thus issue. Try to set kern.smp.disabled=1 in /boot/loader.conf hw.acpi.reset_video=1 in /etc/sysctl.conf But even after these changes ata subsystem does not resumed from sleep correctly. Andrey V. Elsukov helps me with that. See a thread http://lists.freebsd.org/pipermail/freebsd-current/2008-July/086912.html A path in thread must be applied only on current version of FreeBSD. P.S. My laptop has Intel GM965 video. Thanks, Sergey From gaijin.k at gmail.com Sun Aug 3 15:10:43 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Sun Aug 3 15:10:56 2008 Subject: Laptop suggestions? In-Reply-To: References: <1216910072.2251.8.camel@jill.exit.com> <86y73j341e.fsf@ds4.des.no> <86bq0ftjf6.fsf@ds4.des.no> <8C2BF4B9-14CD-40EA-B22E-DBB7060BFE46@bnc.net> Message-ID: <1217776229.953.11.camel@RabbitsDen> On Wed, 2008-07-30 at 21:45 -0300, Carlos A. M. dos Santos wrote: > On Wed, Jul 30, 2008 at 5:20 PM, Achim Patzner wrote: > > Am 30.07.2008 um 18:40 schrieb Dag-Erling Sm?rgrav: > >> > >> I don't understand what Macs have to do with this - we're talking about > >> iX Systems's made-for-BSD laptop. > > > > The thread started with someone asking for a mobile computer that > > would support FreeBSD sufficiently and nobody came up with something > > fitting the bill (and being available somewhere). Considering the > > picture you're seeing at any place where more than two hardcore Unix > > users assemble you're seeing a majority of Macs. There has to be an > > obvious reason for that... I tried to break that habit more than once > > but right now the only comfortable way of running FreeBSD on a laptop > > is VMware Fusion on a Mac. Reading this entire thread convinced me > > even more. > > Please define "comfortable". I've been running FreeBSD 7.0 pretty > comfortably on my HP nx6320 for several months now. I never attempted > to use neither Bluetooth nor the fingerprint reader, so I don't miss I am sure this is not intentional, but a lot of the responses in this thread mention not using Bluetooth. If only to make sure that people are not led to believe that Bluetooth support in FreeBSD is lacking, I would like to mention that I have been using it for a long while with Apple Keyboard (something Windows incarnation of the same laptop is not capable of), Logitech V570(?) mouse, Palms E2 and TX (former NAT'd out to the network through FreeBSD host) and the string of Motorola phones for moving pictures, sounds and Java applications back and forth using OBEX. And, just to throw out some other definition of the "comfortable" -- I find my ThinkPad X61 (12" diagonally, 4.5lbs) much more comfortable to carry around than my iBook G4 or the smallest of the MacBooks being sold today. I guess, "comfortable" is on the lap of the beholder ;) -- Alexandre "Sunny" Kovalenko (????????? ?????????) From smallhand at crawblog.com Sun Aug 3 15:50:12 2008 From: smallhand at crawblog.com (Edward Ruggeri) Date: Sun Aug 3 15:50:18 2008 Subject: Suspend/Hibernate/Wake on Thinkpad T61 In-Reply-To: <597436B54F5FF74FA8EA7F3224FE251F12594B75@mail.bcc> References: <597436B54F5FF74FA8EA7F3224FE251F12594B75@mail.bcc> Message-ID: <919383240808030850v3244f37do71fffb16c79f047c@mail.gmail.com> On Sun, Aug 3, 2008 at 8:33 AM, Nasonov Sergey wrote: > Hello Edward, I also have ThinkPad T61and success resolved thus issue. > Try to set > kern.smp.disabled=1 in /boot/loader.conf > hw.acpi.reset_video=1 in /etc/sysctl.conf I tried these, but they didn't seem to fix my problem. It does look like the laptop suspends; in /var/log/messages, "acpi: suspend at 20080802 23:13:37." But then I can't seem to wake the system. If I set kern.smp.disabled=1, then the system reboots when I suspend. >> Hi, >> >> When I suspend to memory or hard disk (S3, S5), I don't seem to be >> able to wake up the computer; also, the screen never turns off. I >> have a ThinkPad T61, so I'm sure someone else must have experience >> with this hardware. Any hints? >> >> (I am using the acpi_ibm kernel module). >> >> Thanks!, >> >> -- Ned Ruggeri From SNasonov at BCC.RU Mon Aug 4 07:13:18 2008 From: SNasonov at BCC.RU (Nasonov Sergey) Date: Mon Aug 4 07:13:24 2008 Subject: Suspend/Hibernate/Wake on Thinkpad T61 In-Reply-To: <919383240808030850v3244f37do71fffb16c79f047c@mail.gmail.com> References: <597436B54F5FF74FA8EA7F3224FE251F12594B75@mail.bcc> <919383240808030850v3244f37do71fffb16c79f047c@mail.gmail.com> Message-ID: <597436B54F5FF74FA8EA7F3224FE251F126552C1@mail.bcc> I tried these, but they didn't seem to fix my problem. It does look like the laptop suspends; in /var/log/messages, "acpi: suspend at 20080802 23:13:37." But then I can't seem to wake the system. If I set kern.smp.disabled=1, then the system reboots when I suspend. Ok, try to recompile your kernel without all usb stuff. If it needed later then you can load it as a loadable kernel module. Also check bios version for update. And I forgot to say that video_acpi is loaded on my system. -- Sergey From smallhand at crawblog.com Mon Aug 4 11:29:34 2008 From: smallhand at crawblog.com (Edward Ruggeri) Date: Mon Aug 4 11:29:41 2008 Subject: Suspend/Hibernate/Wake on Thinkpad T61 In-Reply-To: <597436B54F5FF74FA8EA7F3224FE251F126552C1@mail.bcc> References: <597436B54F5FF74FA8EA7F3224FE251F12594B75@mail.bcc> <919383240808030850v3244f37do71fffb16c79f047c@mail.gmail.com> <597436B54F5FF74FA8EA7F3224FE251F126552C1@mail.bcc> Message-ID: <919383240808040429ncfeb1f6xa229402a887b566a@mail.gmail.com> On Mon, Aug 4, 2008 at 2:13 AM, Nasonov Sergey wrote: > I tried these, but they didn't seem to fix my problem. It does look > like the laptop suspends; in /var/log/messages, "acpi: suspend at > 20080802 23:13:37." But then I can't seem to wake the system. > > If I set kern.smp.disabled=1, then the system reboots when I suspend. > > Ok, try to recompile your kernel without all usb stuff. If it needed > later then you can load it as a loadable kernel module. Also check bios > version for update. And I forgot to say that video_acpi is loaded on my > system. > > -- > Sergey I did try video_acpi, but you're right; I should remove the USB stuff. I'll also check the BIOS version. Thanks! -- Ned Ruggeri From freebsd at meijome.net Mon Aug 4 12:57:38 2008 From: freebsd at meijome.net (Norberto Meijome) Date: Mon Aug 4 12:57:44 2008 Subject: Bluetooth [was Re: Laptop suggestions? ] In-Reply-To: <1217776229.953.11.camel@RabbitsDen> References: <1216910072.2251.8.camel@jill.exit.com> <86y73j341e.fsf@ds4.des.no> <86bq0ftjf6.fsf@ds4.des.no> <8C2BF4B9-14CD-40EA-B22E-DBB7060BFE46@bnc.net> <1217776229.953.11.camel@RabbitsDen> Message-ID: <20080804225733.749db6a0@ayiin> On Sun, 03 Aug 2008 11:10:29 -0400 "Alexandre \"Sunny\" Kovalenko" wrote: > I am sure this is not intentional, but a lot of the responses in this > thread mention not using Bluetooth. If only to make sure that people are > not led to believe that Bluetooth support in FreeBSD is lacking, I would > like to mention that I have been using it for a long while with Apple > Keyboard (something Windows incarnation of the same laptop is not > capable of), Logitech V570(?) mouse, Palms E2 and TX (former NAT'd out > to the network through FreeBSD host) and the string of Motorola phones > for moving pictures, sounds and Java applications back and forth using > OBEX. hi Alexandre, quick couple of questions: - what port do you use for OBEX ? - I've got a pair of bluetooth headsets that are pair OK with my laptop...but I have no idea how to push audio over to them. Any pointers? # hccontrol -n ubt0hci remote_name_request betos_headset BD_ADDR: betos_headset Name: Philips SHB6100 # hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State betos_headset 12 ACL 0 MAST NONE 0 0 OPEN # hccontrol read_remote_supported_features 12 Connection handle: 12 Features: 0xff 0xff 0x8f 0x78 0x18 0x18 00 0x80 <3-Slot> <5-Slot> Thanks!! B _________________________ {Beto|Norberto|Numard} Meijome "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." [RFC1925 - section 2, subsection 3] I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From freebsd at meijome.net Mon Aug 4 13:13:43 2008 From: freebsd at meijome.net (Norberto Meijome) Date: Mon Aug 4 13:13:58 2008 Subject: Suspend/Hibernate/Wake on Thinkpad T61 In-Reply-To: <597436B54F5FF74FA8EA7F3224FE251F12594B75@mail.bcc> References: <597436B54F5FF74FA8EA7F3224FE251F12594B75@mail.bcc> Message-ID: <20080804231338.67fb9963@ayiin> On Sun, 3 Aug 2008 17:33:43 +0400 "Nasonov Sergey" wrote: > Hello Edward, I also have ThinkPad T61and success resolved thus issue. > Try to set > kern.smp.disabled=1 in /boot/loader.conf > hw.acpi.reset_video=1 in /etc/sysctl.conf > > But even after these changes ata subsystem does not resumed from sleep > correctly. Andrey V. Elsukov helps me with that. > See a thread > http://lists.freebsd.org/pipermail/freebsd-current/2008-July/086912.html > A path in thread must be applied only on current version of FreeBSD. > > P.S. My laptop has Intel GM965 video. are you running X with DRI enabled? B _________________________ {Beto|Norberto|Numard} Meijome "Those who do not remember the past are condemned to repeat it." George Santayana I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From vlado at netng.org Mon Aug 4 13:35:03 2008 From: vlado at netng.org (Vladimir Botka) Date: Mon Aug 4 13:35:10 2008 Subject: Bluetooth [was Re: Laptop suggestions? ] In-Reply-To: <20080804225733.749db6a0@ayiin> References: <1216910072.2251.8.camel@jill.exit.com> <86y73j341e.fsf@ds4.des.no> <86bq0ftjf6.fsf@ds4.des.no> <8C2BF4B9-14CD-40EA-B22E-DBB7060BFE46@bnc.net> <1217776229.953.11.camel@RabbitsDen> <20080804225733.749db6a0@ayiin> Message-ID: <20080804151022.6b3ed106@vlado-laptop.netng.org> On Mon, 4 Aug 2008 22:57:33 +1000 Norberto Meijome wrote: > On Sun, 03 Aug 2008 11:10:29 -0400 > "Alexandre \"Sunny\" Kovalenko" wrote: > > > I am sure this is not intentional, but a lot of the responses in > > this thread mention not using Bluetooth. If only to make sure that > > people are not led to believe that Bluetooth support in FreeBSD is > > lacking, I would like to mention that I have been using it for a > > long while with Apple Keyboard (something Windows incarnation of > > the same laptop is not capable of), Logitech V570(?) mouse, Palms > > E2 and TX (former NAT'd out to the network through FreeBSD host) > > and the string of Motorola phones for moving pictures, sounds and > > Java applications back and forth using OBEX. > > hi Alexandre, > quick couple of questions: > - what port do you use for OBEX ? > > - I've got a pair of bluetooth headsets that are pair OK with my > laptop...but I have no idea how to push audio over to them. Any > pointers? > > # hccontrol -n ubt0hci remote_name_request betos_headset > BD_ADDR: betos_headset > Name: Philips SHB6100 > > # hccontrol -n ubt0hci read_connection_list > Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State > betos_headset 12 ACL 0 MAST NONE 0 0 OPEN > > # hccontrol read_remote_supported_features 12 > Connection handle: 12 > Features: 0xff 0xff 0x8f 0x78 0x18 0x18 00 0x80 > <3-Slot> <5-Slot> > > > > > > > Thanks!! > B > > _________________________ > {Beto|Norberto|Numard} Meijome > > "With sufficient thrust, pigs fly just fine. However, this is not > necessarily a good idea. It is hard to be sure where they are going > to land, and it could be dangerous sitting under them as they fly > overhead." [RFC1925 - section 2, subsection 3] > > I speak for myself, not my employer. Contents may be hot. Slippery > when wet. Reading disclaimers makes you go blind. Writing them is > worse. You have been Warned. > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to > "freebsd-mobile-unsubscribe@freebsd.org" > Hello, for me obex file transfer works with comms/obexapp on 6.2, but there is no audio support in FreeBSD AFAIK. Have fun, -vlado Vladimir Botka From freebsd at meijome.net Mon Aug 4 13:43:09 2008 From: freebsd at meijome.net (Norberto Meijome) Date: Mon Aug 4 13:43:15 2008 Subject: Bluetooth [was Re: Laptop suggestions? ] In-Reply-To: <20080804151022.6b3ed106@vlado-laptop.netng.org> References: <1216910072.2251.8.camel@jill.exit.com> <86y73j341e.fsf@ds4.des.no> <86bq0ftjf6.fsf@ds4.des.no> <8C2BF4B9-14CD-40EA-B22E-DBB7060BFE46@bnc.net> <1217776229.953.11.camel@RabbitsDen> <20080804225733.749db6a0@ayiin> <20080804151022.6b3ed106@vlado-laptop.netng.org> Message-ID: <20080804234304.1d58498d@ayiin> On Mon, 4 Aug 2008 15:10:22 +0200 Vladimir Botka wrote: > for me obex file transfer works with comms/obexapp on 6.2, but there is > no audio support in FreeBSD AFAIK. thanks Vladimir. so you use obexapp directly? any GUI you can recommend ? B _________________________ {Beto|Norberto|Numard} Meijome Bug: a feature that can't be turned off. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From snasonov at bcc.ru Mon Aug 4 13:59:05 2008 From: snasonov at bcc.ru (Sergey G Nasonov) Date: Mon Aug 4 13:59:14 2008 Subject: Suspend/Hibernate/Wake on Thinkpad T61 Message-ID: <200808041758.47344.snasonov@bcc.ru> > P.S. My laptop has Intel GM965 video. are you running X with DRI enabled? Yes. I attached my xorg.log Thanks, Sergey. From vlado at netng.org Mon Aug 4 15:35:06 2008 From: vlado at netng.org (Vladimir Botka) Date: Mon Aug 4 15:35:12 2008 Subject: Bluetooth [was Re: Laptop suggestions? ] In-Reply-To: <20080804234304.1d58498d@ayiin> References: <1216910072.2251.8.camel@jill.exit.com> <86y73j341e.fsf@ds4.des.no> <86bq0ftjf6.fsf@ds4.des.no> <8C2BF4B9-14CD-40EA-B22E-DBB7060BFE46@bnc.net> <1217776229.953.11.camel@RabbitsDen> <20080804225733.749db6a0@ayiin> <20080804151022.6b3ed106@vlado-laptop.netng.org> <20080804234304.1d58498d@ayiin> Message-ID: <20080804173502.63cf905a@vlado-laptop.netng.org> On Mon, 4 Aug 2008 23:43:04 +1000 Norberto Meijome wrote: > On Mon, 4 Aug 2008 15:10:22 +0200 > Vladimir Botka wrote: > > > for me obex file transfer works with comms/obexapp on 6.2, but > > there is no audio support in FreeBSD AFAIK. > > thanks Vladimir. > > so you use obexapp directly? any GUI you can recommend ? > > B > > _________________________ > {Beto|Norberto|Numard} Meijome > > Bug: a feature that can't be turned off. > > I speak for myself, not my employer. Contents may be hot. Slippery > when wet. Reading disclaimers makes you go blind. Writing them is > worse. You have been Warned. > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile To > unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" > Hello, no GUI I am aware of, sorry. There should be some KDE support for bluetooth you can play with URL obex://bluetooth_address in the konqueror. I use the obexapp as a server. > cat /usr/local/etc/rc.d/030.startObex.sh #!/bin/sh /usr/local/bin/obexapp -s -r /var/spool/obex -C 1 -u obex Have fun, -vlado Vladimir Botka From gaijin.k at gmail.com Tue Aug 5 00:43:00 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Tue Aug 5 00:43:07 2008 Subject: Bluetooth [was Re: Laptop suggestions? ] In-Reply-To: <20080804225733.749db6a0@ayiin> References: <1216910072.2251.8.camel@jill.exit.com> <86y73j341e.fsf@ds4.des.no> <86bq0ftjf6.fsf@ds4.des.no> <8C2BF4B9-14CD-40EA-B22E-DBB7060BFE46@bnc.net> <1217776229.953.11.camel@RabbitsDen> <20080804225733.749db6a0@ayiin> Message-ID: <1217896968.1191.8.camel@RabbitsDen> On Mon, 2008-08-04 at 22:57 +1000, Norberto Meijome wrote: > On Sun, 03 Aug 2008 11:10:29 -0400 > "Alexandre \"Sunny\" Kovalenko" wrote: > > > I am sure this is not intentional, but a lot of the responses in this > > thread mention not using Bluetooth. If only to make sure that people are > > not led to believe that Bluetooth support in FreeBSD is lacking, I would > > like to mention that I have been using it for a long while with Apple > > Keyboard (something Windows incarnation of the same laptop is not > > capable of), Logitech V570(?) mouse, Palms E2 and TX (former NAT'd out > > to the network through FreeBSD host) and the string of Motorola phones > > for moving pictures, sounds and Java applications back and forth using > > OBEX. > > hi Alexandre, > quick couple of questions: > - what port do you use for OBEX ? comms/obexapp ... and answering your next question: I am using it from scripts and Makefiles, so I have not looked for GUI frontends. Asking around on bluetooth@ might give you a better yield. > > - I've got a pair of bluetooth headsets that are pair OK with my laptop...but I > have no idea how to push audio over to them. Any pointers? No. There was a discussion on bluetooth@ and, AFAICR, Maksim Yevmenkin said that he has SCO profile implementation, but is not sure how to marry it to the sound subsystem. You would be better off searching archives, though. -- Alexandre "Sunny" Kovalenko (????????? ?????????) From jhugo at meraka.csir.co.za Wed Aug 6 11:27:13 2008 From: jhugo at meraka.csir.co.za (Johann Hugo) Date: Wed Aug 6 11:27:20 2008 Subject: WPA in adhoc mode Message-ID: <200808061327.03028.jhugo@meraka.csir.co.za> I'm trying to setup WPA between two Atheros wifi adapters in adhoc mode, but I cannot get it to work. Any hints to get it to work ? According to the "wpa_supplicant Reference Manual 0.4.x" it should be possible: --------------------------------------------- IEEE 802.11 operation mode (Infrastucture/IBSS). 0 = infrastructure (Managed) mode, i.e., associate with an AP. 1 = IBSS (ad-hoc, peer-to-peer) Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-NONE (?xed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase). -------------------------------------------- I'm running 7.0-STABLE, build on 30 Jul 2008. hw.ath.hal.version: 0.9.20.3 ath0: flags=8843 metric 0 mtu 1500 ether 00:80:48:50:9d:dd inet6 fe80::280:48ff:fe50:9ddd%ath0 prefixlen 64 scopeid 0x1 inet6 fd9c:6829:597c:20:280:48ff:fe50:9ddd prefixlen 64 inet6 fd9c:6829:597c:20:: prefixlen 64 anycast media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid ptamesh channel 13 (2472 Mhz 11g) bssid 02:15:6d:53:39:75 authmode OPEN privacy OFF txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst mesh-9ddd:~ # more /etc/wpa_supplicant.conf ap_scan=2 network={ ssid="ptamesh" mode=1 proto=WPA key_mgmt=WPA-NONE pairwise=NONE group=TKIP psk="mesh-ipv6" } mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' ap_scan=2 Priority group 0 id=0 ssid='ptamesh' Initializing interface (2) 'ath0' EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 Own MAC address: 00:80:48:50:9d:dd wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 Setting scan request: 0 sec 100000 usec Added interface ath0 State: DISCONNECTED -> SCANNING Trying to associate with SSID 'ptamesh' Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 WPA: No WPA/RSN IE available from association info WPA: Set cipher suites based on configuration WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1 WPA: clearing AP WPA IE WPA: clearing AP RSN IE WPA: using GTK TKIP WPA: using PTK NONE WPA: using KEY_MGMT WPA-NONE WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00 No keys have been configured - skip key clearing wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 seq_len=6 key_len=32 wpa_driver_bsd_set_drop_unencrypted: enabled=1 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key mgmt 4 ioctl[SIOCS80211, op 22, len 24]: Invalid argument Association request to the driver failed wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 seq_len=6 key_len=32 Cancelling authentication timeout State: ASSOCIATING -> COMPLETED CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 id_str=] EAPOL: External notification - portControl=ForceAuthorized From sam at freebsd.org Wed Aug 6 15:38:17 2008 From: sam at freebsd.org (Sam Leffler) Date: Wed Aug 6 15:38:24 2008 Subject: WPA in adhoc mode In-Reply-To: <200808061327.03028.jhugo@meraka.csir.co.za> References: <200808061327.03028.jhugo@meraka.csir.co.za> Message-ID: <4899C568.3060807@freebsd.org> Johann Hugo wrote: > I'm trying to setup WPA between two Atheros wifi adapters in adhoc mode, but I > cannot get it to work. Any hints to get it to work ? > > According to the "wpa_supplicant Reference Manual 0.4.x" it should be > possible: > --------------------------------------------- > IEEE 802.11 operation mode (Infrastucture/IBSS). > 0 = infrastructure (Managed) mode, i.e., associate with an AP. > 1 = IBSS (ad-hoc, peer-to-peer) > Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and > key_mgmt=WPA-NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be > set to 2 for IBSS. WPA-None requires following network block options: > proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP > (or CCMP, but not both), and psk must also be set (either directly or using > ASCII passphrase). > -------------------------------------------- > > I'm running 7.0-STABLE, build on 30 Jul 2008. > hw.ath.hal.version: 0.9.20.3 > > ath0: flags=8843 metric 0 mtu 1500 > ether 00:80:48:50:9d:dd > inet6 fe80::280:48ff:fe50:9ddd%ath0 prefixlen 64 scopeid 0x1 > inet6 fd9c:6829:597c:20:280:48ff:fe50:9ddd prefixlen 64 > inet6 fd9c:6829:597c:20:: prefixlen 64 anycast > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > ssid ptamesh channel 13 (2472 Mhz 11g) bssid 02:15:6d:53:39:75 > authmode OPEN privacy OFF txpower 31.5 scanvalid 60 bgscan > bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 > protmode CTS burst > > mesh-9ddd:~ # more /etc/wpa_supplicant.conf > ap_scan=2 > > network={ > ssid="ptamesh" > mode=1 > proto=WPA > key_mgmt=WPA-NONE > pairwise=NONE > group=TKIP > psk="mesh-ipv6" > } > > mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf > Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' > ctrl_interface 'N/A' bridge 'N/A' > Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' > Reading configuration file '/etc/wpa_supplicant.conf' > ap_scan=2 > Priority group 0 > id=0 ssid='ptamesh' > Initializing interface (2) 'ath0' > EAPOL: SUPP_PAE entering state DISCONNECTED > EAPOL: KEY_RX entering state NO_KEY_RECEIVE > EAPOL: SUPP_BE entering state INITIALIZE > EAP: EAP entering state DISABLED > EAPOL: External notification - portEnabled=0 > EAPOL: External notification - portValid=0 > Own MAC address: 00:80:48:50:9d:dd > wpa_driver_bsd_set_wpa: enabled=1 > wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 > wpa_driver_bsd_del_key: keyidx=0 > wpa_driver_bsd_del_key: keyidx=1 > wpa_driver_bsd_del_key: keyidx=2 > wpa_driver_bsd_del_key: keyidx=3 > wpa_driver_bsd_set_countermeasures: enabled=0 > wpa_driver_bsd_set_drop_unencrypted: enabled=1 > Setting scan request: 0 sec 100000 usec > Added interface ath0 > State: DISCONNECTED -> SCANNING > Trying to associate with SSID 'ptamesh' > Cancelling scan request > WPA: clearing own WPA/RSN IE > Automatic auth_alg selection: 0x1 > wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 > WPA: No WPA/RSN IE available from association info > WPA: Set cipher suites based on configuration > WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1 > WPA: clearing AP WPA IE > WPA: clearing AP RSN IE > WPA: using GTK TKIP > WPA: using PTK NONE > WPA: using KEY_MGMT WPA-NONE > WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 > f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00 > No keys have been configured - skip key clearing > wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 > seq_len=6 key_len=32 > wpa_driver_bsd_set_drop_unencrypted: enabled=1 > State: SCANNING -> ASSOCIATING > wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key > mgmt 4 > ioctl[SIOCS80211, op 22, len 24]: Invalid argument > Association request to the driver failed > wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 > seq_len=6 key_len=32 > Cancelling authentication timeout > State: ASSOCIATING -> COMPLETED > CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 > id_str=] > EAPOL: External notification - portControl=ForceAuthorized > Looks like the driver is being told to associate which fails because the device is in adhoc mode--and so it returns an error and wpa_supplicant aborts the work. You might try disabling the request in the wpa_supplicant driver. I've never tried this config. If you can't get it work please file a PR so the issue isn't lost. Sam From sarumont at sigil.org Thu Aug 7 02:49:48 2008 From: sarumont at sigil.org (Richard Kolkovich) Date: Thu Aug 7 02:49:54 2008 Subject: powerd + t43p - AC adapter = fail Message-ID: <20080807024953.GP90222@snobol> I've not looked into this much at all, but when I boot my t43p without the AC adapter plugged in, there are no values in dev.cpu.0.freq_levels. This results in powerd failing. A reboot with the AC adapter is the only way I know of to fix this. Like I said, I haven't investigated this, but I was wondering if anyone else has seen this type of behaviour (and fixed it?). Thanks, -- Richard Kolkovich sarumont@sigil.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-mobile/attachments/20080807/cd4580f1/attachment.pgp From freebsd.lists at fsck.ch Thu Aug 7 11:59:24 2008 From: freebsd.lists at fsck.ch (Tobias Roth) Date: Thu Aug 7 11:59:31 2008 Subject: powerd + t43p - AC adapter = fail In-Reply-To: <20080807024953.GP90222@snobol> References: <20080807024953.GP90222@snobol> Message-ID: <489AE0C5.9000702@fsck.ch> On 08/07/08 04:49, Richard Kolkovich wrote: > I've not looked into this much at all, but when I boot my t43p without the AC adapter plugged in, there are no values in dev.cpu.0.freq_levels. This results in powerd failing. A reboot with the AC adapter is the only way I know of to fix this. > > Like I said, I haven't investigated this, but I was wondering if anyone else has seen this type of behaviour (and fixed it?). Thanks, > works just fine for me, for both ac and battery only. the t43p has generally working very well for me since RELENG_7, though there are some things I never tried, namely fingerprint scanner, internal modem, 3d acceleration, gigabit, hibernate, vga output. the rest works well. does hibernate even exist in RELENG_7? the last time this worked for me was on a T30 with RELENG_4 and apm instead of acpi. i'm only missing it a little, now that s3 works. thanks, Tobias -- Tobias Roth || http://fsck.ch || PGP: 0xCE599B4D | SYN, SYN/ACK, ACK - The mating call of the Internet. From greenant at fastmail.fm Fri Aug 8 15:24:17 2008 From: greenant at fastmail.fm (Alberto Rizzi) Date: Fri Aug 8 15:24:23 2008 Subject: Wpi keep disconnecting Message-ID: <489C625F.3020605@fastmail.fm> I have a Thinkpad T61 (UZ25FIT) dual boot with Xp and FreeBSD and has an Intel 3945ABG on board. #uname -a FreeBSD yoda.endor 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Aug 8 13:51:42 CEST 2008 root@yoda.endor:/usr/obj/usr/src/sys/YODA i386 I can load the wpi driver and configure the interface, then I can connect to my wifi router (linksys wag54g 1v) with WPA and surf internet but after a while the wpi disconnects. I think it is volume related and not time related, maybe a counter overflow or something other. If I mount a NFS directory and start copying files from the server to the notebook, after a minute the wpi disconnects. In /var/log/messages I can read wpi0: link state changed to DOWN and in wpa_cli I can read <3>Michael MIC failure detected <3>Michael MIC failure detected <3>TKIP countermeasures started <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys after a minute I read in /var/log/messages wpi0: scan timeout and in wpa_cli <2>WPA: TKIP countermeasures stopped with netstat -ibh I see I moved 12MBytes If I write "reassociate" in wpa_cli, after some seconds in var log messages I read wpi0: link state changed to UP and in wpa_cli <2>Trying to associate ..... <2>Associated with ..... <2>WPA: Key negotiation completed ..... <2>CTRL-EVENT-CONNECTED ..... If I restart the copying process I can see <3>Michael MIC failure detected but wpi doesn't disconnect. After a while wpi disconnects and I have the same messages in /var/log/messages and wpa_cli There isn't a fixed amount of bytes I can transfer between two disconnection, sometime 10MB, sometime 100MB, but the maximum was 140MB Please help me, I can give further info. I have FreeBSD 7 on this PC since its release and I always had problems From oberman at es.net Fri Aug 8 15:46:14 2008 From: oberman at es.net (Kevin Oberman) Date: Fri Aug 8 15:46:21 2008 Subject: Wpi keep disconnecting In-Reply-To: Your message of "Fri, 08 Aug 2008 17:12:31 +0200." <489C625F.3020605@fastmail.fm> Message-ID: <20080808154611.E5CF245010@ptavv.es.net> > Date: Fri, 08 Aug 2008 17:12:31 +0200 > From: Alberto Rizzi > Sender: owner-freebsd-mobile@freebsd.org > > I have a Thinkpad T61 (UZ25FIT) dual boot with Xp and FreeBSD and has an > Intel 3945ABG on board. > > #uname -a > FreeBSD yoda.endor 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Aug 8 13:51:42 > CEST 2008 root@yoda.endor:/usr/obj/usr/src/sys/YODA i386 > > I can load the wpi driver and configure the interface, then I can > connect to my wifi router (linksys wag54g 1v) with WPA and surf internet > but after a while the wpi disconnects. I think it is volume related and > not time related, maybe a counter overflow or something other. > > If I mount a NFS directory and start copying files from the server to > the notebook, after a minute the wpi disconnects. > In /var/log/messages I can read > wpi0: link state changed to DOWN > > and in wpa_cli I can read > <3>Michael MIC failure detected > <3>Michael MIC failure detected > <3>TKIP countermeasures started > <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys > > after a minute I read in /var/log/messages > wpi0: scan timeout > > and in wpa_cli > <2>WPA: TKIP countermeasures stopped > > with netstat -ibh I see I moved 12MBytes > > If I write "reassociate" in wpa_cli, after some seconds in var log > messages I read > wpi0: link state changed to UP > > and in wpa_cli > <2>Trying to associate ..... > <2>Associated with ..... > <2>WPA: Key negotiation completed ..... > <2>CTRL-EVENT-CONNECTED ..... > > If I restart the copying process I can see > <3>Michael MIC failure detected > but wpi doesn't disconnect. > > After a while wpi disconnects and I have the same messages in > /var/log/messages and wpa_cli > > There isn't a fixed amount of bytes I can transfer between two > disconnection, sometime 10MB, sometime 100MB, but the maximum was 140MB > > Please help me, I can give further info. > I have FreeBSD 7 on this PC since its release and I always had problems Try 'ifconfig wpi0 -bgscan'. I continue to see reports and to have problems with association being lost during "background" scans. This only seems to happen when there are multiple APs available and is very annoying. Please drop the list a note it turning off background scanning solves the problem. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-mobile/attachments/20080808/3f1afe87/attachment.pgp From greenant at fastmail.fm Fri Aug 8 16:03:07 2008 From: greenant at fastmail.fm (Alberto Rizzi) Date: Fri Aug 8 16:03:13 2008 Subject: Wpi keep disconnecting In-Reply-To: <20080808154611.E5CF245010@ptavv.es.net> References: <20080808154611.E5CF245010@ptavv.es.net> Message-ID: <489C6E36.9060603@fastmail.fm> Kevin Oberman ha scritto: >> Date: Fri, 08 Aug 2008 17:12:31 +0200 >> From: Alberto Rizzi >> Sender: owner-freebsd-mobile@freebsd.org >> >> I have a Thinkpad T61 (UZ25FIT) dual boot with Xp and FreeBSD and has an >> Intel 3945ABG on board. >> >> #uname -a >> FreeBSD yoda.endor 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Aug 8 13:51:42 >> CEST 2008 root@yoda.endor:/usr/obj/usr/src/sys/YODA i386 >> >> I can load the wpi driver and configure the interface, then I can >> connect to my wifi router (linksys wag54g 1v) with WPA and surf internet >> but after a while the wpi disconnects. I think it is volume related and >> not time related, maybe a counter overflow or something other. >> >> If I mount a NFS directory and start copying files from the server to >> the notebook, after a minute the wpi disconnects. >> In /var/log/messages I can read >> wpi0: link state changed to DOWN >> >> and in wpa_cli I can read >> <3>Michael MIC failure detected >> <3>Michael MIC failure detected >> <3>TKIP countermeasures started >> <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys >> >> after a minute I read in /var/log/messages >> wpi0: scan timeout >> >> and in wpa_cli >> <2>WPA: TKIP countermeasures stopped >> >> with netstat -ibh I see I moved 12MBytes >> >> If I write "reassociate" in wpa_cli, after some seconds in var log >> messages I read >> wpi0: link state changed to UP >> >> and in wpa_cli >> <2>Trying to associate ..... >> <2>Associated with ..... >> <2>WPA: Key negotiation completed ..... >> <2>CTRL-EVENT-CONNECTED ..... >> >> If I restart the copying process I can see >> <3>Michael MIC failure detected >> but wpi doesn't disconnect. >> >> After a while wpi disconnects and I have the same messages in >> /var/log/messages and wpa_cli >> >> There isn't a fixed amount of bytes I can transfer between two >> disconnection, sometime 10MB, sometime 100MB, but the maximum was 140MB >> >> Please help me, I can give further info. >> I have FreeBSD 7 on this PC since its release and I always had problems > > Try 'ifconfig wpi0 -bgscan'. I continue to see reports and to have > problems with association being lost during "background" scans. This > only seems to happen when there are multiple APs available and is very > annoying. > > Please drop the list a note it turning off background scanning solves > the problem. Same problem, no change. Scan_results in wpa_cli reveals 2 AP. The script used to activate wpi is this kldload if_wpi ifconfig wpi0 192.168.8.5/24 up route add default 192.168.8.254 wpa_supplicant -B -i wpi0 -c /etc/wpa_supplicant.conf #cat wpa_supplicant.conf ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel network={ ssid="Naboo" psk="***********" proto=WPA key_mgmt=WPA-PSK } From sam at freebsd.org Fri Aug 8 16:14:36 2008 From: sam at freebsd.org (Sam Leffler) Date: Fri Aug 8 16:14:42 2008 Subject: Wpi keep disconnecting In-Reply-To: <489C625F.3020605@fastmail.fm> References: <489C625F.3020605@fastmail.fm> Message-ID: <489C70E8.2080800@freebsd.org> Alberto Rizzi wrote: > I have a Thinkpad T61 (UZ25FIT) dual boot with Xp and FreeBSD and has > an Intel 3945ABG on board. > > #uname -a > FreeBSD yoda.endor 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Aug 8 > 13:51:42 CEST 2008 root@yoda.endor:/usr/obj/usr/src/sys/YODA i386 > > I can load the wpi driver and configure the interface, then I can > connect to my wifi router (linksys wag54g 1v) with WPA and surf > internet but after a while the wpi disconnects. I think it is volume > related and not time related, maybe a counter overflow or something > other. > > If I mount a NFS directory and start copying files from the server to > the notebook, after a minute the wpi disconnects. > In /var/log/messages I can read > wpi0: link state changed to DOWN > > and in wpa_cli I can read > <3>Michael MIC failure detected > <3>Michael MIC failure detected > <3>TKIP countermeasures started > <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys > > after a minute I read in /var/log/messages > wpi0: scan timeout > > and in wpa_cli > <2>WPA: TKIP countermeasures stopped > > with netstat -ibh I see I moved 12MBytes > > If I write "reassociate" in wpa_cli, after some seconds in var log > messages I read > wpi0: link state changed to UP > > and in wpa_cli > <2>Trying to associate ..... > <2>Associated with ..... > <2>WPA: Key negotiation completed ..... > <2>CTRL-EVENT-CONNECTED ..... > > If I restart the copying process I can see > <3>Michael MIC failure detected > but wpi doesn't disconnect. > > After a while wpi disconnects and I have the same messages in > /var/log/messages and wpa_cli > > There isn't a fixed amount of bytes I can transfer between two > disconnection, sometime 10MB, sometime 100MB, but the maximum was 140MB > > Please help me, I can give further info. > I have FreeBSD 7 on this PC since its release and I always had problems Check for a firmware update for your router. Sam From greenant at fastmail.fm Fri Aug 8 16:20:51 2008 From: greenant at fastmail.fm (Alberto Rizzi) Date: Fri Aug 8 16:21:01 2008 Subject: Wpi keep disconnecting In-Reply-To: <489C70E8.2080800@freebsd.org> References: <489C625F.3020605@fastmail.fm> <489C70E8.2080800@freebsd.org> Message-ID: <489C7263.1040209@fastmail.fm> Sam Leffler ha scritto: > Check for a firmware update for your router. > > Sam > It already has the latest firmware (maybe 4 years old). Unfortunately I don't have other routers to try with. From freebsd_user at guice.ath.cx Sun Aug 10 07:37:27 2008 From: freebsd_user at guice.ath.cx (freebsd_user@guice.ath.cx) Date: Sun Aug 10 07:37:34 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support Message-ID: <489E9531.2090200@guice.ath.cx> I've been through his before with an AMD setup (desktop) and now, here we go again using a Toshiba TECRA A9-S9017 laptop. The issue here is, is appears that FreeBSD is causing the motherboard and its chipset(s) and/or CPU's to work wide open (full throttle) --disregard for APM. I'm basing this on the amount of heat coming from this current laptop while the laptop is idling, The heat is to the point that you can't keep the laptop on your lap; in addition to the battery not lasting quite an hour while idling. When I remove/deinstall freebsd from the laptop and install another OS, the heat goes way down. Installing or returning to 7.0 the heat once again returns. Again, this was the case using an AMD smp setup back in the 4.x era. I'm asking for help in controlling this beast, the machine is just to damn hot while idling and gets even hotter doing minor task like a cvsup. Rather than paste/post non-relevant data/info here, please tell me what data is needed in order to address this/these issues intelligently. My goals are: 1) to control the cpu and associated hardware (heat) 2) get all the native/installed hardware supported. 3) support for a "sierra wireless compass 597" <--> usb wireless WAN. Should FreeBSD not support all of this machines hardware then we need not continue --unless people are actively working of support/drivers for the above. I've been trying to work with FreeBSD on this TECRA A9 for the better part of two weeks and there are too many outstanding issues to continue. From morganw at chemikals.org Mon Aug 11 02:28:27 2008 From: morganw at chemikals.org (Wes Morgan) Date: Mon Aug 11 02:28:33 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support In-Reply-To: <489E9531.2090200@guice.ath.cx> References: <489E9531.2090200@guice.ath.cx> Message-ID: On Sun, 10 Aug 2008, freebsd_user@guice.ath.cx wrote: > I've been through his before with an AMD setup (desktop) and now, > here we go again using a Toshiba TECRA A9-S9017 laptop. The issue here is, is > appears that FreeBSD is causing the motherboard and its chipset(s) > and/or CPU's to work wide open (full throttle) --disregard for APM. I'm > basing this on the amount of heat coming from this current laptop while > the laptop is idling, The heat is to the point that you can't keep the > laptop on your lap; in addition to the battery not lasting quite an hour > while idling. Try using powerd(8). > My goals are: 1) to control the cpu and associated hardware (heat) 2) get all > the native/installed hardware supported. 3) support for a "sierra wireless > compass 597" <--> usb wireless WAN. Should FreeBSD not support all of this > machines hardware then we need not continue --unless people are actively > working of support/drivers for the above. Judging by the factory specs, you will probably find that 90% of the hardware is supported or has a driver under development. Don't hold your breath for the fingerprint reader, though. The wireless modem is a crap shoot. > I've been trying to work with FreeBSD on this TECRA A9 for the better part of > two weeks and there are too many outstanding issues to continue. From ianglenn at gmail.com Tue Aug 12 19:54:32 2008 From: ianglenn at gmail.com (Ian) Date: Tue Aug 12 19:54:41 2008 Subject: ath: unable to attach hardware; HAL status 3; attach returned 6 Message-ID: Goal: to have Wireless Atheros based NIC run on my Sony Vaio Background: The computer in question is a Sony Vaio PCG R505-JL w/ slimdock. The CD-ROM is broken. I used a second computer and installed it on the second computer, then transfered the hard drive to the vaio. This problem is not present on the computer I installed it on. The card works Out-of box. dmesg output: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #3: Sun Aug 10 23:59:57 EDT 2008 root@:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (745.25-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383f9ff real memory = 401080320 (382 MB) avail memory = 378433536 (360 MB) kbd1 at kbdmux0 ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) acpi0: on motherboard acpi0: [ITHREAD] Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: mem 0xf8000000-0xfbffffff,0xf4000000-0xf407ffff irq 9 at device 2.0 on pci0 agp0: on vgapci0 pcib1: at device 30.0 on pci0 pci1: on pcib1 fwohci0: mem 0xf4105000-0xf41057ff,0xf4100000-0xf4103fff irq 9 at device 0.0 on pci1 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 08:00:46:03:00:c5:c2:17 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x17d1c000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 0a:00:46:c5:c2:17 fwe0: Ethernet address: 0a:00:46:c5:c2:17 fwip0: on firewire0 fwip0: Firewire address: 08:00:46:03:00:c5:c2:17 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode cbb0: at device 2.0 on pci1 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] fxp0: port 0x3000-0x303f mem 0xf4104000-0xf4104fff irq 9 at device 8.0 on pci1 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 08:00:46:41:96:8d fxp0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1800-0x180f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0x1820-0x183f irq 9 at device 31.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered pci0: at device 31.3 (no driver attached) uhci1: port 0x1840-0x185f irq 9 at device 31.4 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered pci0: at device 31.5 (no driver attached) pci0: at device 31.6 (no driver attached) cpu0: on acpi0 acpi_perf0: on cpu0 acpi_throttle0: on cpu0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff,0xd8000-0xdbfff,0xdc000-0xdffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 umass0: on uhub1 Timecounter "TSC" frequency 745245771 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 14403MB at ata0-master UDMA100 cardbus0: Expecting link target, got 0xff ath0: mem 0xf4110000-0xf411ffff irq 9 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: unable to attach hardware; HAL status 3 device_attach: ath0 attach returned 6 (probe7:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe7:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe7:umass-sim0:0:0:0): SCSI Status: Check Condition (probe7:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 (probe7:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred (probe7:umass-sim0:0:0:0): Retrying Command (per Sense Data) (probe7:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe7:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe7:umass-sim0:0:0:0): SCSI Status: Check Condition (probe7:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe7:umass-sim0:0:0:0): Medium not present (probe7:umass-sim0:0:0:0): Unretryable error Trying to mount root from ufs:/dev/ad0s1a umass1: on uhub0 da0 at umass-sim1 bus 1 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 7871MB (16119808 512 byte sectors: 255H 63S/T 1003C) pciconf -lv: hostb0@pci0:0:0:0: class=0x060000 card=0x80e0104d chip=0x11308086 rev=0x11 hdr=0x00 vendor = 'Intel Corporation' device = '82815/EM/EP/P 815/EM/EP/P (Solano) Host to I/O Hub Bridge' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x030000 card=0x80e0104d chip=0x11328086 rev=0x11 hdr=0x00 vendor = 'Intel Corporation' device = '82815/EM/EP/P 815/EM/EP/P (Solano) Interal GUI Accelerator' class = display subclass = VGA pcib1@pci0:0:30:0: class=0x060400 card=0x00000000 chip=0x24488086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x244c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801BAM (ICH2-M) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x010180 card=0x80e0104d chip=0x244a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801BAM (ICH2-M) UltraATA/100 IDE Controller' class = mass storage subclass = ATA uhci0@pci0:0:31:2: class=0x0c0300 card=0x80e0104d chip=0x24428086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA/BAM (ICH2/ICH2-M) USB Universal Host Controller' class = serial bus subclass = USB none0@pci0:0:31:3: class=0x0c0500 card=0x80e0104d chip=0x24438086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA/BAM (ICH2/ICH2-M) SMBus Controller' class = serial bus subclass = SMBus uhci1@pci0:0:31:4: class=0x0c0300 card=0x80e0104d chip=0x24448086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA/BAM (ICH2/ICH2-M) USB Universal Host Controller' class = serial bus subclass = USB none1@pci0:0:31:5: class=0x040100 card=0x80e0104d chip=0x24458086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA/BAM (ICH2/ICH2-M) AC'97 Audio Controller' class = multimedia subclass = audio none2@pci0:0:31:6: class=0x070300 card=0x80e0104d chip=0x24468086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA/BAM (ICH2/ICH2-M) AC'97 Modem Controller' class = simple comms subclass = generic modem fwohci0@pci0:1:0:0: class=0x0c0010 card=0x80e0104d chip=0x8021104c rev=0x02 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TSB43AA22xxx 1394a-2000 OHCI PHY/Link Layer Ctrlr xxx' class = serial bus subclass = FireWire cbb0@pci0:1:2:0: class=0x060700 card=0x80e0104d chip=0x04751180 rev=0x80 hdr=0x02 vendor = 'Ricoh Company, Ltd.' device = 'RL5c475 Cardbus Controller' class = bridge subclass = PCI-CardBus fxp0@pci0:1:8:0: class=0x020000 card=0x30138086 chip=0x24498086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82559ER 82559ER Integrated 10Base-T/100Base-TX Ethernet Controller' class = network subclass = ethernet ath0@pci0:2:0:0: class=0x000000 card=0x000817f9 chip=0x001a168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'Atheros AR5005G Atheros AR5005G 802.11abg NIC Chipset / TP-Link (TL-WN551G)' class = old subclass = non-VGA display device According to ah.h (line 84) HAL status 3 is "hardware didn't respond as expected. Any more output/logs that are needed can be provided. Thank you very much for your attention. Ian Glenn From a.j.werven at student.utwente.nl Tue Aug 12 21:14:03 2008 From: a.j.werven at student.utwente.nl (Alphons "Fonz" van Werven) Date: Tue Aug 12 21:14:10 2008 Subject: Status of wpi driver in 7.1-RELEASE Message-ID: <48A1FCFD.2040107@student.utwente.nl> Hiya, Just the other day I noticed on the Wpi Wiki (http://www.clearchain.com/wiki/Wpi) that the problems with the Intel 3945ABG and WPA are apparently fixed. Will these fixes be included in the version of wpi that will be shipped with FreeBSD 7.1-RELEASE? Alphons -- If riding in an airplane is flying, then riding in a boat is swimming. If you want to experience the element, get out of the vehicle. From wahjava.ml at gmail.com Wed Aug 13 09:51:48 2008 From: wahjava.ml at gmail.com (Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IA==?= =?utf-8?B?4KS24KWB4KSV4KWN4KSy?=) Date: Wed Aug 13 09:51:54 2008 Subject: ath: unable to attach hardware; HAL status 3; attach returned 6 In-Reply-To: (Ian's message of "Tue\, 12 Aug 2008 15\:26\:05 -0400") References: Message-ID: <8763q5b72c.fsf@chateau.d.lf> Ian writes: > Goal: > to have Wireless Atheros based NIC run on my Sony Vaio > Background: > The computer in question is a Sony Vaio PCG R505-JL w/ slimdock. The CD-ROM > is broken. > I used a second computer and installed it on the second computer, then > transfered the > hard drive to the vaio. > This problem is not present on the computer I installed it on. The card > works Out-of box. > dmesg output: [snip] > ath0: mem 0xf4110000-0xf411ffff irq 9 at device 0.0 on > cardbus0 > ath0: [ITHREAD] > ath0: unable to attach hardware; HAL status 3 > device_attach: ath0 attach returned 6 Above output indicates, wireless chip not accepting the HAL firmware. You can try the latest HAL available from following URL: http://people.freebsd.org/~sam/ath_hal-20080528.tgz HTH Ashish Shukla -- ?-- ?- ???? ?--- ?- ???- ?- ?--?-? --? -- ?- ?? ?-?? ?-?-?- -?-? --- -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-mobile/attachments/20080813/e0da22de/attachment.pgp From ianglenn at gmail.com Wed Aug 13 12:48:57 2008 From: ianglenn at gmail.com (Ian) Date: Wed Aug 13 12:49:03 2008 Subject: ath: unable to attach hardware; HAL status 3; attach returned 6 In-Reply-To: <8763q5b72c.fsf@chateau.d.lf> References: <8763q5b72c.fsf@chateau.d.lf> Message-ID: I am running the latest ath_hal from http://people.freebsd.org/~sam/ I likely should have mentioned that in the first place The wireless card is picked up fine when I move the harddrive to another laptop. Which would likely rule out the possibility that the issue is within the chipset (unless I am severely misguided, which I won't rule out). Also I am running a generic kernel of FreeBSD-7.0 STABLE (though the issue was still there when I had RELEASE running) On Wed, Aug 13, 2008 at 5:25 AM, Ashish Shukla ???? ????? wrote: > Ian writes: > > Goal: > > to have Wireless Atheros based NIC run on my Sony Vaio > > > Background: > > > The computer in question is a Sony Vaio PCG R505-JL w/ slimdock. The > CD-ROM > > is broken. > > I used a second computer and installed it on the second computer, then > > transfered the > > hard drive to the vaio. > > > This problem is not present on the computer I installed it on. The card > > works Out-of box. > > > dmesg output: > > [snip] > > > ath0: mem 0xf4110000-0xf411ffff irq 9 at device 0.0 on > > cardbus0 > > ath0: [ITHREAD] > > ath0: unable to attach hardware; HAL status 3 > > device_attach: ath0 attach returned 6 > > Above output indicates, wireless chip not accepting the HAL > firmware. You can try the latest HAL available from following URL: > > http://people.freebsd.org/~sam/ath_hal-20080528.tgz > > HTH > Ashish Shukla > -- > ?-- ?- ???? ?--- ?- ???- ?- ?--?-? --? -- ?- ?? ?-?? ?-?-?- -?-? --- -- > From sam at freebsd.org Wed Aug 13 15:54:55 2008 From: sam at freebsd.org (Sam Leffler) Date: Wed Aug 13 15:57:21 2008 Subject: ath: unable to attach hardware; HAL status 3; attach returned 6 In-Reply-To: References: <8763q5b72c.fsf@chateau.d.lf> Message-ID: <48A303CE.2020006@freebsd.org> This is likely a cardbus issue. The hal status code is: HAL_EIO = 3, /* Hardware didn't respond as expected */ (look in sys/contrib/dev/ath/ah.h) and it typically means the sanity check/self test done at startup failed. For fun you might check if the cardbus chip on the two laptops are different. Warner just recently fixed some cardbus issues in HEAD (w/ Ricoh bridge chips I believe) but the symptoms were different. Sam Ian wrote: > I am running the latest ath_hal from http://people.freebsd.org/~sam/ > > I likely should have mentioned that in the first place > > The wireless card is picked up fine when I move the harddrive to another > laptop. Which > would likely rule out the possibility that the issue is within the chipset > (unless I am > severely misguided, which I won't rule out). > > Also I am running a generic kernel of FreeBSD-7.0 STABLE (though the issue > was still there when > I had RELEASE running) > > > On Wed, Aug 13, 2008 at 5:25 AM, Ashish Shukla ???????????? ??????????????? gmail.com> wrote: > > >> Ian writes: >> >>> Goal: >>> to have Wireless Atheros based NIC run on my Sony Vaio >>> >>> Background: >>> >>> The computer in question is a Sony Vaio PCG R505-JL w/ slimdock. The >>> >> CD-ROM >> >>> is broken. >>> I used a second computer and installed it on the second computer, then >>> transfered the >>> hard drive to the vaio. >>> >>> This problem is not present on the computer I installed it on. The card >>> works Out-of box. >>> >>> dmesg output: >>> >> [snip] >> >> >>> ath0: mem 0xf4110000-0xf411ffff irq 9 at device 0.0 on >>> cardbus0 >>> ath0: [ITHREAD] >>> ath0: unable to attach hardware; HAL status 3 >>> device_attach: ath0 attach returned 6 >>> >> Above output indicates, wireless chip not accepting the HAL >> firmware. You can try the latest HAL available from following URL: >> >> http://people.freebsd.org/~sam/ath_hal-20080528.tgz >> >> HTH >> Ashish Shukla >> -- >> ??-- ??- ???????? ??--- ??- ??????- ??- ??--??-?? --?? -- ??- ???? ??-???? ??-??-??- -??-?? --- -- >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> freebsd-mobile@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile >> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" From strontium90 at gmail.com Thu Aug 14 01:07:36 2008 From: strontium90 at gmail.com (Razmig K) Date: Thu Aug 14 01:07:49 2008 Subject: Intel 802.11agn: Disabling n? Message-ID: <48A384DA.6080002@gmail.com> Hello, I intend to acquire a notebook with the mentioned wireless option, and I understand that its driver, iwn, is still in development stage. I spotted a mention to a "disabled n" in a recent thread: http://lists.freebsd.org/pipermail/freebsd-questions/2008-June/176638.html. Is there a handy way to do this so that it could be re-enabled once iwn becomes available in STABLE? The intention is of course being able to use the 802.11abg driver wpi. Thanks! //rk From ianglenn at gmail.com Thu Aug 14 02:15:34 2008 From: ianglenn at gmail.com (Ian) Date: Thu Aug 14 02:15:40 2008 Subject: ath: unable to attach hardware; HAL status 3; attach returned 6 In-Reply-To: <48A303CE.2020006@freebsd.org> References: <8763q5b72c.fsf@chateau.d.lf> <48A303CE.2020006@freebsd.org> Message-ID: That sounds like a fairly accurate assessment of the issue. The only thing that makes me hesitate is that based on a report I have read (http://mjoc.sig.lt/papers/freebsd/vaio/vaio_freebsd.html); There where no problems with the PCMCIA when he installed freeBSD 5.3. So I guess the questions after this point go in this order: 1. Could something have changed from 5.3 to 7.0 that would have stopped it from working? 2. The cardbus on the working system is a Micro, Inc. The vaio is a Ricoh Co chipset (both according to lspci). So this may indicate that the issue may lie in the cardbus. Where can I find the work being done on the support? 3. If this does not correct the issue, could it be from a physical breakage? Thank you for your attention. On Wed, Aug 13, 2008 at 11:54 AM, Sam Leffler wrote: > This is likely a cardbus issue. The hal status code is: > > HAL_EIO = 3, /* Hardware didn't respond as expected */ > > (look in sys/contrib/dev/ath/ah.h) and it typically means the sanity > check/self test done at startup failed. > > For fun you might check if the cardbus chip on the two laptops are > different. Warner just recently fixed some cardbus issues in HEAD (w/ Ricoh > bridge chips I believe) but the symptoms were different. > > Sam > > Ian wrote: > >> I am running the latest ath_hal from http://people.freebsd.org/~sam/ >> >> I likely should have mentioned that in the first place >> >> The wireless card is picked up fine when I move the harddrive to another >> laptop. Which >> would likely rule out the possibility that the issue is within the chipset >> (unless I am >> severely misguided, which I won't rule out). >> >> Also I am running a generic kernel of FreeBSD-7.0 STABLE (though the issue >> was still there when >> I had RELEASE running) >> >> >> On Wed, Aug 13, 2008 at 5:25 AM, Ashish Shukla ???????????? ????? ????? >> ??? > gmail.com> wrote: >> >> >> >>> Ian writes: >>> >>> >>>> Goal: >>>> to have Wireless Atheros based NIC run on my Sony Vaio >>>> Background: >>>> The computer in question is a Sony Vaio PCG R505-JL w/ slimdock. >>>> The >>>> >>>> >>> CD-ROM >>> >>> >>>> is broken. >>>> I used a second computer and installed it on the second computer, then >>>> transfered the >>>> hard drive to the vaio. >>>> This problem is not present on the computer I installed it on. The >>>> card >>>> works Out-of box. >>>> dmesg output: >>>> >>>> >>> [snip] >>> >>> >>> >>>> ath0: mem 0xf4110000-0xf411ffff irq 9 at device 0.0 on >>>> cardbus0 >>>> ath0: [ITHREAD] >>>> ath0: unable to attach hardware; HAL status 3 >>>> device_attach: ath0 attach returned 6 >>>> >>>> >>> Above output indicates, wireless chip not accepting the HAL >>> firmware. You can try the latest HAL available from following URL: >>> >>> http://people.freebsd.org/~sam/ath_hal-20080528.tgz >>> >>> >>> HTH >>> Ashish Shukla >>> -- >>> ??-- ??- ???????? ??--- ??- ??????- ??- ??--??-?? --?? -- ??- ???? >>> ??-???? ??-??-??- -??-?? --- -- >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> freebsd-mobile@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile >>> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org >>> " >>> >> > From zeuz_netraptor at hotmail.com Sun Aug 17 19:17:51 2008 From: zeuz_netraptor at hotmail.com (ZeuZ Diavolo Deimos) Date: Sun Aug 17 19:17:58 2008 Subject: HP Pavilion DV 2000 series and freeBSD 7.0-STABLE-200807 Message-ID: Hi everyone, let me start of describing the situation ;) As for 7.0-STABLE release, I wasnt able to even boot, not even setting various parameters at boot time. Once I got it to boot, it installed, then panicked all over. So I waited to a recent snapshot and it booted, installed, and worked, well, partially. ACPI/APM Are both not working compleately. Also, this Machine has a Turion 64X2 processor wich I'm using with i386 version since it has an nvidia card inside. I've followed some links and saw that there was a known idle_cpu patch because of the lack of performance, what I don't actually know, is if that patch is allready included in 7.0-STABLE-200807 snapshot, can someone confirm this? Also, seems like ndis/ndisgen is broken with Broadcom adapter now, it's the troublesome BCM43/B43/Dell Mini PCI-CARD 1390, is there any plan on something like the weird Linux module for it to become native on FreeBSD? Or is there some other BSD that supports it where I can look and try to export the driver to FreeBSD? Well, apart from that, my laptop has a lack of performance compared to Debian (wich is the distro wich I've been using for the last 4 years fulltime) wich I don't feel on my desktop where 7.0 release outblazes Debian for a good trunk (Running on a Intel Pentium Dual Core clocked at 3.66ghz each core) even Debian behing tunned up from filesystem, to kernel, from the out-of-the-box-state. Anyone else having the same laptop that can give me a hint on this? Also, for powersaving, the laptop display (trying to use xsetbacklight) responds like if the display could not be brighted down (in fBSD) with the misterious Output "No Outputs have backlight option" wich i've researched and seen Ubuntu users with the same problem over nvidia GeForce Go! 6150 cards. Appart from that, running freeBSD the disk seems to have problems spunning and there?s a weird noise that I beleave comes from the hard drive like if it wasnt behing recognized properly or dealt with properly. The disk status is correct, no failures detected whatsoever, also this seems to not be affecting the laptop when the power cord is not present. Any help or contribution is very appreciated. Thanks in advice. Anibal. Debian Style -.ZeuZ.- _________________________________________________________________ Ingres? ya a MSN Deportes y enterate de las ?ltimas novedades del mundo deportivo. http://msn.foxsports.com/fslasc/ From cddesjardins at gmail.com Tue Aug 19 03:01:20 2008 From: cddesjardins at gmail.com (Christopher Desjardins) Date: Tue Aug 19 03:01:56 2008 Subject: Suspend Lenovo 3000 N100 Message-ID: Hi, I am wondering what is the best way to go about suspending my laptop? I don't remember what I tried a while back but my laptop went to sleep but unfortunately it didn't resume. Could someone give me some tips for how to suspend my machine and troubleshoot if it doesn't work properly. Thanks, Chris From imp at bsdimp.com Tue Aug 19 03:25:32 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Aug 19 03:25:38 2008 Subject: ath: unable to attach hardware; HAL status 3; attach returned 6 In-Reply-To: <48A303CE.2020006@freebsd.org> References: <8763q5b72c.fsf@chateau.d.lf> <48A303CE.2020006@freebsd.org> Message-ID: <20080818.212401.1878032342.imp@bsdimp.com> In message: <48A303CE.2020006@freebsd.org> Sam Leffler writes: : This is likely a cardbus issue. The hal status code is: : : HAL_EIO = 3, /* Hardware didn't respond as expected */ : : (look in sys/contrib/dev/ath/ah.h) and it typically means the sanity : check/self test done at startup failed. : : For fun you might check if the cardbus chip on the two laptops are : different. Warner just recently fixed some cardbus issues in HEAD (w/ : Ricoh bridge chips I believe) but the symptoms were different. Yes. The problem would be that the card didn't show up at all, even when you enabled CardBus debugging... This was a power issue where we were accessing the card before it was powered up. That's not to say that there isn't another CardBus problem... Warner : Sam : : Ian wrote: : > I am running the latest ath_hal from http://people.freebsd.org/~sam/ : > : > I likely should have mentioned that in the first place : > : > The wireless card is picked up fine when I move the harddrive to another : > laptop. Which : > would likely rule out the possibility that the issue is within the chipset : > (unless I am : > severely misguided, which I won't rule out). : > : > Also I am running a generic kernel of FreeBSD-7.0 STABLE (though the issue : > was still there when : > I had RELEASE running) : > : > : > On Wed, Aug 13, 2008 at 5:25 AM, Ashish Shukla ???????????? ??????????????? gmail.com> wrote: : > : > : >> Ian writes: : >> : >>> Goal: : >>> to have Wireless Atheros based NIC run on my Sony Vaio : >>> : >>> Background: : >>> : >>> The computer in question is a Sony Vaio PCG R505-JL w/ slimdock. The : >>> : >> CD-ROM : >> : >>> is broken. : >>> I used a second computer and installed it on the second computer, then : >>> transfered the : >>> hard drive to the vaio. : >>> : >>> This problem is not present on the computer I installed it on. The card : >>> works Out-of box. : >>> : >>> dmesg output: : >>> : >> [snip] : >> : >> : >>> ath0: mem 0xf4110000-0xf411ffff irq 9 at device 0.0 on : >>> cardbus0 : >>> ath0: [ITHREAD] : >>> ath0: unable to attach hardware; HAL status 3 : >>> device_attach: ath0 attach returned 6 : >>> : >> Above output indicates, wireless chip not accepting the HAL : >> firmware. You can try the latest HAL available from following URL: : >> : >> http://people.freebsd.org/~sam/ath_hal-20080528.tgz : >> : >> HTH : >> Ashish Shukla : >> -- : >> ??-- ??- ???????? ??--- ??- ??????- ??- ??--??-?? --?? -- ??- ???? ??-???? ??-??-??- -??-?? --- -- : >> : >> : >> ------------------------------------------------------------------------ : >> : >> _______________________________________________ : >> freebsd-mobile@freebsd.org mailing list : >> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile : >> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" : : _______________________________________________ : freebsd-mobile@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-mobile : To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" : From imp at bsdimp.com Tue Aug 19 03:37:49 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Aug 19 03:37:57 2008 Subject: ath: unable to attach hardware; HAL status 3; attach returned 6 In-Reply-To: References: <48A303CE.2020006@freebsd.org> Message-ID: <20080818.213529.155332723.imp@bsdimp.com> In message: Ian writes: : That sounds like a fairly accurate assessment of the issue. : : The only thing that makes me hesitate is that based on a report I have read : (http://mjoc.sig.lt/papers/freebsd/vaio/vaio_freebsd.html); There where no : problems : with the PCMCIA when he installed freeBSD 5.3. : : So I guess the questions after this point go in this order: : 1. Could something have changed from 5.3 to 7.0 that would have : stopped it from working? : 2. The cardbus on the working system is a Micro, Inc. The vaio is a Ricoh : Co chipset (both according to lspci). So this may indicate that the issue : may : lie in the cardbus. Where can I find the work being done on the support? : 3. If this does not correct the issue, could it be from a physical breakage? Between 5.3 and 7.0 I improved the power code. In doing so for many cases, I also busted it for a few. I've recently fixed a number of cases to make it better. Try the following diff: Index: pccbb.c =================================================================== RCS file: /pe/ncvs/src/sys/dev/pccbb/pccbb.c,v retrieving revision 1.165 diff -u -r1.165 pccbb.c --- pccbb.c 30 Sep 2007 11:05:15 -0000 1.165 +++ pccbb.c 19 Aug 2008 03:32:25 -0000 @@ -936,7 +936,7 @@ * 20ms is necessary for most bridges. For some reason, the Ricoh * RF5C47x bridges need 400ms. */ - delay = sc->chipset == CB_RF5C47X ? 400 : 20; + delay = 1000; PCI_MASK_CONFIG(brdev, CBBR_BRIDGECTRL, |CBBM_BRIDGECTRL_RESET, 2); if it fixes it, then that's the bug. I have a more intelligent fix in -current, but this is a less risky fix (at the expense of delaying things an additional 980ms). Warner : Thank you for your attention. : : On Wed, Aug 13, 2008 at 11:54 AM, Sam Leffler wrote: : : > This is likely a cardbus issue. The hal status code is: : > : > HAL_EIO = 3, /* Hardware didn't respond as expected */ : > : > (look in sys/contrib/dev/ath/ah.h) and it typically means the sanity : > check/self test done at startup failed. : > : > For fun you might check if the cardbus chip on the two laptops are : > different. Warner just recently fixed some cardbus issues in HEAD (w/ Ricoh : > bridge chips I believe) but the symptoms were different. : > : > Sam : > : > Ian wrote: : > : >> I am running the latest ath_hal from http://people.freebsd.org/~sam/ : >> : >> I likely should have mentioned that in the first place : >> : >> The wireless card is picked up fine when I move the harddrive to another : >> laptop. Which : >> would likely rule out the possibility that the issue is within the chipset : >> (unless I am : >> severely misguided, which I won't rule out). : >> : >> Also I am running a generic kernel of FreeBSD-7.0 STABLE (though the issue : >> was still there when : >> I had RELEASE running) : >> : >> : >> On Wed, Aug 13, 2008 at 5:25 AM, Ashish Shukla ???????????? ????? ????? : >> ??? > gmail.com> wrote: : >> : >> : >> : >>> Ian writes: : >>> : >>> : >>>> Goal: : >>>> to have Wireless Atheros based NIC run on my Sony Vaio : >>>> Background: : >>>> The computer in question is a Sony Vaio PCG R505-JL w/ slimdock. : >>>> The : >>>> : >>>> : >>> CD-ROM : >>> : >>> : >>>> is broken. : >>>> I used a second computer and installed it on the second computer, then : >>>> transfered the : >>>> hard drive to the vaio. : >>>> This problem is not present on the computer I installed it on. The : >>>> card : >>>> works Out-of box. : >>>> dmesg output: : >>>> : >>>> : >>> [snip] : >>> : >>> : >>> : >>>> ath0: mem 0xf4110000-0xf411ffff irq 9 at device 0.0 on : >>>> cardbus0 : >>>> ath0: [ITHREAD] : >>>> ath0: unable to attach hardware; HAL status 3 : >>>> device_attach: ath0 attach returned 6 : >>>> : >>>> : >>> Above output indicates, wireless chip not accepting the HAL : >>> firmware. You can try the latest HAL available from following URL: : >>> : >>> http://people.freebsd.org/~sam/ath_hal-20080528.tgz : >>> : >>> : >>> HTH : >>> Ashish Shukla : >>> -- : >>> ??-- ??- ???????? ??--- ??- ??????- ??- ??--??-?? --?? -- ??- ???? : >>> ??-???? ??-??-??- -??-?? --- -- : >>> : >>> : >>> ------------------------------------------------------------------------ : >>> : >>> _______________________________________________ : >>> freebsd-mobile@freebsd.org mailing list : >>> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile : >>> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org : >>> " : >>> : >> : > : _______________________________________________ : freebsd-mobile@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-mobile : To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" : From wahjava.ml at gmail.com Sun Aug 24 05:45:50 2008 From: wahjava.ml at gmail.com (Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IA==?= =?utf-8?B?4KS24KWB4KSV4KWN4KSy?=) Date: Sun Aug 24 05:45:56 2008 Subject: Is 'ath' going to be updated for 7.1-RELEASE ? Message-ID: <87vdxr9d9y.fsf@chateau.d.lf> Hi, Just came across the release schedule of 7.1-RELEASE. I'm wondering if new version of 'ath' driver (for Athereos Wireless chipsets) is going to be included or not ? If yes, I'll be glad to try the betas :). TIA Ashish -- ?-- ?- ???? ?--- ?- ???- ?- ?--?-? --? -- ?- ?? ?-?? ?-?-?- -?-? --- -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-mobile/attachments/20080824/06d30289/attachment.pgp From freebsd_user at guice.ath.cx Mon Aug 25 03:15:55 2008 From: freebsd_user at guice.ath.cx (freebsd_user@guice.ath.cx) Date: Mon Aug 25 03:16:03 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support In-Reply-To: References: <489E9531.2090200@guice.ath.cx> Message-ID: <20080825025833.GB3301@WORKSTATION.guice.ath.cx> Continuing this thread. See below for annotations On Sun, Aug 10, 2008 at 09:28:19PM -0500, Wes Morgan wrote: > On Sun, 10 Aug 2008, freebsd_user@guice.ath.cx wrote: > > > I've been through his before with an AMD setup (desktop) and now, > >here we go again using a Toshiba TECRA A9-S9017 laptop. The issue here is, > >is > >appears that FreeBSD is causing the motherboard and its chipset(s) > >and/or CPU's to work wide open (full throttle) --disregard for APM. I'm > >basing this on the amount of heat coming from this current laptop while > >the laptop is idling, The heat is to the point that you can't keep the > >laptop on your lap; in addition to the battery not lasting quite an hour > >while idling. > > Try using powerd(8). > I have done so with little improvement as far as the heat goes. When we first requested help (this thread), the role of this machine was to be a freebsd desktop. Since then we lost a mail server and have been forced to use the 'subject' machine as a replacement --until whenever-- meaning it is plugged in 24/7. as stated above 'powerd' is being used and we do notice less heat after the machine hasn't been used for a period of hours. However, even though we consider the machine as idling, because we haven't used it in hours, other than the mail coming in; X.org is not running and the lid/LCD is closed and off, the machine is quite warm --not as hot as it was. Soon after we login remotely, the heat ramps up again to the point were you can't keep the 'subject:' machine on your lap; there are time we do need to use the machine directly which includes placing the machine on ones' lap. With that being said, 'man powerd' states the default is to run in "adaptive" mode but, the bug section of the same man page states: "If powerd is used with power_profile, they may override each other." -- How do I know, or find out, if the above (override) is taking place? -- How to tell what state/mode 'powerd' is in at any particular timestamp? This machine has never run this hot, prior to running 'powerd'-- or run this warm, while idling with 'powerd' in comparison to running under windows --not trying to start and OS confilict here, trying to learn, understand and control this beast of a machine if possible. FreeBSD is allowing me to handle my data in a more flexable, feature rich, secure and Free manner than windows. We would prefer to stay with FreeBSD, but not if its going to burn-up our hardware. We had to take our previous AMD/smp machine down because we couldn't keep the heat down without leaving the case open. We loved that machine but it kept freezing due to heat. There is another issue whereby 'APM' is enabled in /etc/rc.conf but while booting the machine the scrolling text is saying the 'APM' module, or something like that will not be loaded because of a missing kernel option/device. But the kernel notes say its no longer neccessary to build the 'APM' into the kernel. Can someone enlighten me as to what I should be doing with regards to bringing this heat down in addition to the 'APM' not actually being loaded when its enabled in the kernel. Thank you. TECRA_A9-S9017 > >My goals are: 1) to control the cpu and associated hardware (heat) 2) get > >all the native/installed hardware supported. 3) support for a "sierra > >wireless compass 597" <--> usb wireless WAN. Should FreeBSD not support > >all of this machines hardware then we need not continue --unless people > >are actively working of support/drivers for the above. > > Judging by the factory specs, you will probably find that 90% of the > hardware is supported or has a driver under development. Don't hold your > breath for the fingerprint reader, though. The wireless modem is a crap > shoot. > > >I've been trying to work with FreeBSD on this TECRA A9 for the better part > >of two weeks and there are too many outstanding issues to continue. > > > From remko at elvandar.org Mon Aug 25 11:30:03 2008 From: remko at elvandar.org (Remko Lodder) Date: Mon Aug 25 11:30:10 2008 Subject: Sad replacement laptop for server? (Was Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support) In-Reply-To: <20080825025833.GB3301@WORKSTATION.guice.ath.cx> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> Message-ID: <05247dceb3f4838de47cbf9873906bb6.squirrel@galain.elvandar.org> On Mon, August 25, 2008 4:58 am, freebsd_user@guice.ath.cx wrote: > Continuing this thread. See below for annotations > > On Sun, Aug 10, 2008 at 09:28:19PM -0500, Wes Morgan wrote: >> On Sun, 10 Aug 2008, freebsd_user@guice.ath.cx wrote: >> >> > I've been through his before with an AMD setup (desktop) and now, >> >here we go again using a Toshiba TECRA A9-S9017 laptop. The issue here >> is, >> >is >> >appears that FreeBSD is causing the motherboard and its chipset(s) >> >and/or CPU's to work wide open (full throttle) --disregard for APM. I'm >> >basing this on the amount of heat coming from this current laptop while >> >the laptop is idling, The heat is to the point that you can't keep the >> >laptop on your lap; in addition to the battery not lasting quite an >> hour >> >while idling. >> >> Try using powerd(8). >> > > I have done so with little improvement as far as the heat goes. When we > first requested help (this thread), the role of this machine was to be a > freebsd desktop. Since then we lost a mail server and have been forced to > use the 'subject' machine as a replacement --until whenever-- meaning it > is plugged in 24/7. > That is a really, really sad solution. He who offered this replacement should reconsider his options. A Laptop running as a mailserver? WTF that is asking for business problems. I hope your business is insured and that the one that offered the solution covered his *ss.. I would never ever offer a laptop as a replacement for any server related solution. I can get a simple cheapdesktop with better and more capabilities for less money if really needed. but a laptop? :-/ -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From freebsd_user at guice.ath.cx Mon Aug 25 11:49:20 2008 From: freebsd_user at guice.ath.cx (freebsd_user@guice.ath.cx) Date: Mon Aug 25 11:49:32 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support) In-Reply-To: <05247dceb3f4838de47cbf9873906bb6.squirrel@galain.elvandar.org> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <05247dceb3f4838de47cbf9873906bb6.squirrel@galain.elvandar.org> Message-ID: <20080825114838.GA5047@WORKSTATION.guice.ath.cx> Your relpy below was unwarranted and not helpful. Please stay away from this thread unless you are offering assistance to the issues we posted herein. To be sure the above is directed To: Remko Lodder Thank you. On Mon, Aug 25, 2008 at 01:13:18PM +0200, Remko Lodder wrote: > > On Mon, August 25, 2008 4:58 am, freebsd_user@guice.ath.cx wrote: > > Continuing this thread. See below for annotations > > > > On Sun, Aug 10, 2008 at 09:28:19PM -0500, Wes Morgan wrote: > >> On Sun, 10 Aug 2008, freebsd_user@guice.ath.cx wrote: > >> > >> > I've been through his before with an AMD setup (desktop) and now, > >> >here we go again using a Toshiba TECRA A9-S9017 laptop. The issue here > >> is, > >> >is > >> >appears that FreeBSD is causing the motherboard and its chipset(s) > >> >and/or CPU's to work wide open (full throttle) --disregard for APM. I'm > >> >basing this on the amount of heat coming from this current laptop while > >> >the laptop is idling, The heat is to the point that you can't keep the > >> >laptop on your lap; in addition to the battery not lasting quite an > >> hour > >> >while idling. > >> > >> Try using powerd(8). > >> > > > > I have done so with little improvement as far as the heat goes. When we > > first requested help (this thread), the role of this machine was to be a > > freebsd desktop. Since then we lost a mail server and have been forced to > > use the 'subject' machine as a replacement --until whenever-- meaning it > > is plugged in 24/7. > > > > That is a really, really sad solution. He who offered this replacement > should reconsider his options. A Laptop running as a mailserver? WTF that > is asking for business problems. I hope your business is insured and that > the one that offered the solution covered his *ss.. > > I would never ever offer a laptop as a replacement for any server related > solution. I can get a simple cheapdesktop with better and more > capabilities for less money if really needed. but a laptop? :-/ > > > > -- > /"\ Best regards, | remko@FreeBSD.org > \ / Remko Lodder | remko@EFnet > X http://www.evilcoder.org/ | > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" From smithi at nimnet.asn.au Mon Aug 25 15:44:06 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Mon Aug 25 15:44:13 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support In-Reply-To: <20080825025833.GB3301@WORKSTATION.guice.ath.cx> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> Message-ID: <20080826002657.B14827@sola.nimnet.asn.au> I'd cc Wes Morgan too, but his address doesn't appear here. On Sun, 24 Aug 2008, freebsd_user@guice.ath.cx wrote: > Continuing this thread. See below for annotations > > On Sun, Aug 10, 2008 at 09:28:19PM -0500, Wes Morgan wrote: > > On Sun, 10 Aug 2008, freebsd_user@guice.ath.cx wrote: > > > > > I've been through his before with an AMD setup (desktop) and now, > > >here we go again using a Toshiba TECRA A9-S9017 laptop. The issue here is, > > >is > > >appears that FreeBSD is causing the motherboard and its chipset(s) > > >and/or CPU's to work wide open (full throttle) --disregard for APM. I'm APM? I guess you mean ACPI on a modern laptop? See below .. > > >basing this on the amount of heat coming from this current laptop while > > >the laptop is idling, The heat is to the point that you can't keep the > > >laptop on your lap; in addition to the battery not lasting quite an hour > > >while idling. > > > > Try using powerd(8). > > > > I have done so with little improvement as far as the heat goes. When we > first requested help (this thread), the role of this machine was to be a > freebsd desktop. Since then we lost a mail server and have been forced to > use the 'subject' machine as a replacement --until whenever-- meaning it > is plugged in 24/7. While I take Remko's point in terms of the hardware levels he'd be used to, laptops can make quite good small servers, for small networks, like ours .. this mailserver runs on a 300MHZ 1999 Compaq Armada 1500c :) but yours sounds rather wasted on such a job. > as stated above 'powerd' is being used and we do notice less heat after > the machine hasn't been used for a period of hours. However, even though > we consider the machine as idling, because we haven't used it in hours, > other than the mail coming in; X.org is not running and the lid/LCD is > closed and off, the machine is quite warm --not as hot as it was. This review http://www.notebookreview.com/default.asp?newsID=4071 says that it doesn't run too hot (with Vasta) but the temperatures shown perhaps bely that. However we need some empirical data about what it's doing. Showing your /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > Soon after we login remotely, the heat ramps up again to the point were > you can't keep the 'subject:' machine on your lap; there are time we do > need to use the machine directly which includes placing the machine on > ones' lap. > > With that being said, 'man powerd' states the default is to run in > "adaptive" mode but, the bug section of the same man page states: > > "If powerd is used with power_profile, they may override each other." > > -- How do I know, or find out, if the above (override) is taking place? > -- How to tell what state/mode 'powerd' is in at any particular timestamp? Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop (if it's running) then run 'powerd -v' which runs in foreground and says exactly what it's doing re shifting CPU frequency under various loads. It's also useful to watch the temperature(s) directly over the time, see acpi_thermal(4) and try logging those sysctls periodically in a script. Firstly, yes that comment isn't too helpful .. power_profile only acts (so far) when you apply or remove AC power, using the following values from /etc/defaults/rc.conf unless you've set them otherwise: performance_cx_lowest="HIGH" # Online CPU idle state performance_cpu_freq="HIGH" # Online CPU frequency economy_cx_lowest="HIGH" # Offline CPU idle state economy_cpu_freq="HIGH" # Offline CPU frequency If you have a look at /etc/rc.d/power_profile you'll see that these are applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above variables to HIGH, LOW, a specific value, or NONE. Specify "NONE" to have power_profile make no changes. "C3" or at least "C2" can be useful CX values, in some machines helping with temperature. powerd will soon override the dev.cpu.0.freq setting anyway, so it's not a problem - again, watch powerd -v output - and I guess you'll rarely run on battery (you've got a nice 2-3 hour UPS, though :) > This machine has never run this hot, prior to running 'powerd'-- or run > this warm, while idling with 'powerd' in comparison to running under windows > --not trying to start and OS confilict here, trying to learn, understand > and control this beast of a machine if possible. Of course, and it's likely doable, though you might need to run 7-STABLE for the latest dual-core ACPI handling. Let's see how we go with some real information, before suggesting taking this to freebsd-acpi@. I don't see where you've mentioned what version of FreeBSD it's running? > FreeBSD is allowing me to handle my data in a more flexable, feature rich, > secure and Free manner than windows. We would prefer to stay with > FreeBSD, but not if its going to burn-up our hardware. We had to take our > previous AMD/smp machine down because we couldn't keep the heat down > without leaving the case open. We loved that machine but it kept freezing > due to heat. > > There is another issue whereby 'APM' is enabled in /etc/rc.conf but while > booting the machine the scrolling text is saying the 'APM' module, or > something like that will not be loaded because of a missing kernel > option/device. But the kernel notes say its no longer neccessary to build > the 'APM' into the kernel. Can someone enlighten me as to what I should > be doing with regards to bringing this heat down in addition to the 'APM' > not actually being loaded when its enabled in the kernel. You really don't want to run APM on modern hardware unless the ACPI on your machine is really, really broken, not even fixable by recompiling the AML code. And I'm fairly sure that ACPI is required to run SMP (ie to use both cores). Make sure that ACPI, not APM, is enabled in BIOS. Let's start from a dmesg, sysctl hw.acpi and some powerd -v output ? cheers, Ian > > Thank you. > > TECRA_A9-S9017 > > > > >My goals are: 1) to control the cpu and associated hardware (heat) 2) get > > >all the native/installed hardware supported. 3) support for a "sierra > > >wireless compass 597" <--> usb wireless WAN. Should FreeBSD not support > > >all of this machines hardware then we need not continue --unless people > > >are actively working of support/drivers for the above. > > > > Judging by the factory specs, you will probably find that 90% of the > > hardware is supported or has a driver under development. Don't hold your > > breath for the fingerprint reader, though. The wireless modem is a crap > > shoot. > > > > >I've been trying to work with FreeBSD on this TECRA A9 for the better part > > >of two weeks and there are too many outstanding issues to continue. From freebsd_user at guice.ath.cx Mon Aug 25 19:18:51 2008 From: freebsd_user at guice.ath.cx (freebsd_user@guice.ath.cx) Date: Mon Aug 25 19:18:59 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support In-Reply-To: <20080826002657.B14827@sola.nimnet.asn.au> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> Message-ID: <20080825191804.GA6846@WORKSTATION.guice.ath.cx> On Tue, Aug 26, 2008 at 01:30:22AM +1000, Ian Smith wrote: > I'd cc Wes Morgan too, but his address doesn't appear here. I tried to send Wes Morgan an email near the top of the thread, forgot what header field I used and I believe it bounced; perhaps because I wasn't subscribed at that time. I will include Wes Morgan in from this point onward. MORE annotations further down. > > On Sun, 24 Aug 2008, freebsd_user@guice.ath.cx wrote: > > Continuing this thread. See below for annotations > > > > On Sun, Aug 10, 2008 at 09:28:19PM -0500, Wes Morgan wrote: > > > On Sun, 10 Aug 2008, freebsd_user@guice.ath.cx wrote: > > > > > > > I've been through his before with an AMD setup (desktop) and now, > > > >here we go again using a Toshiba TECRA A9-S9017 laptop. The issue here is, > > > >is > > > >appears that FreeBSD is causing the motherboard and its chipset(s) > > > >and/or CPU's to work wide open (full throttle) --disregard for APM. I'm > > APM? I guess you mean ACPI on a modern laptop? See below .. At this point I was speaking of APM. While the machine is booting there was a time it printed something to the effect that 'APM' could/would not be loaded/enabled because of a missing device/optin in the kernerl. > > > > >basing this on the amount of heat coming from this current laptop while > > > >the laptop is idling, The heat is to the point that you can't keep the > > > >laptop on your lap; in addition to the battery not lasting quite an hour > > > >while idling. > > > > > > Try using powerd(8). > > > > > > > I have done so with little improvement as far as the heat goes. When we > > first requested help (this thread), the role of this machine was to be a > > freebsd desktop. Since then we lost a mail server and have been forced to > > use the 'subject' machine as a replacement --until whenever-- meaning it > > is plugged in 24/7. > > While I take Remko's point in terms of the hardware levels he'd be used > to, laptops can make quite good small servers, for small networks, like > ours .. this mailserver runs on a 300MHZ 1999 Compaq Armada 1500c :) but > yours sounds rather wasted on such a job. In short, this was an emergency, and I tried to spare the mailing list any of my woes that had nothing to do with the current discussion. In short, an upgrade on the mail-server went sideways, unable to boot multi-user. The laptop was the most immediate way to get up and running by restoring our level '0' and '9' dumps rather than try to fix the tower on a live system. Back to the here and now. :=) > > > as stated above 'powerd' is being used and we do notice less heat after > > the machine hasn't been used for a period of hours. However, even though > > we consider the machine as idling, because we haven't used it in hours, > > other than the mail coming in; X.org is not running and the lid/LCD is > > closed and off, the machine is quite warm --not as hot as it was. > > This review http://www.notebookreview.com/default.asp?newsID=4071 says > that it doesn't run too hot (with Vasta) but the temperatures shown > perhaps bely that. I'll have a look > > However we need some empirical data about what it's doing. Showing your > /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > Initially we didn't provide that data until someone asked for it to be sure that is in fact what was needed or if the was some other incorrect setting. /var/run/dmesg.boot ... Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-RELEASE-p3 #1: Mon Aug 4 23:37:02 EDT 2008 root@WORKSTATION.ath.cx:/usr/obj/usr/src/sys/WORKSTATION ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2113142784 (2015 MB) avail memory = 2058563584 (1963 MB) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Aug 4 2008 23:36:52) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 3.0 (no driver attached) em0: port 0xbfe0-0xbfff mem 0xffcc0000-0xffcdffff,0xffcfe000-0xffcfefff irq 20 at device 25.0 on pci0 em0: Ethernet address: 00:1c:7e:e3:2f:1f uhci0: port 0xbf80-0xbf9f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: at device 26.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xffcff800-0xffcffbff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered pcm0: at device 27.0 on pci0 pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) pcib3: irq 16 at device 28.1 on pci0 pci3: on pcib3 pcib4: irq 18 at device 28.2 on pci0 pci5: on pcib4 pci5: at device 0.0 (no driver attached) uhci2: port 0x8fe0-0x8fff irq 23 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] usb3: on uhci2 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered uhci3: port 0x8f80-0x8f9f irq 19 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] usb4: on uhci3 usb4: USB revision 1.0 uhub4: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x8f60-0x8f7f irq 18 at device 29.2 on pci0 uhci4: [GIANT-LOCKED] usb5: on uhci4 usb5: USB revision 1.0 uhub5: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xffcff400-0xffcff7ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub6: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pci6: on pcib5 cbb0: at device 11.0 on pci6 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: <1394 Open Host Controller Interface> at device 11.1 on pci6 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. [4~[4~dfwohci0: EUI64 00:00:39:00:00:7e:a7:c4 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:39:7e:a7:c4 fwe0: Ethernet address: 02:00:39:7e:a7:c4 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci6: at device 11.2 (no driver attached) pci6: at device 11.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8f30-0x8f3f irq 19 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x8f28-0x8f2f,0x8f24-0x8f27,0x8f18-0x8f1f,0x8f14-0x8f17,0x8ee0-0x8eff mem 0xffcfd800-0xffcfdfff irq 19 at device 31.2 on pci0 atapci1: AHCI Version 01.10 controller with 3 ports detected ata2: on atapci1 ata3: on atapci1 ata3: port not implemented ata4: on atapci1 ata4: port not implemented acpi_lid0: on acpi0 battery0: on acpi0 acpi_button0: on acpi0 acpi_acad0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd4000-0xd7fff,0xe8000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ugen0: STMicroelectronics Biometric Coprocessor, rev 1.00/0.01, addr 2 Timecounter "TSC" frequency 2194521241 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. acd0: DVDR at ata0-master UDMA33 ad4: 152627MB at ata2-master SATA150 pcm0: pcm0: Trying to mount root from ufs:/dev/ad4s1a em0: link state changed to UP Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 1 0 0 done All buffers synced. sysctl hw.acpi ... hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.battery.life: 100 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.acline: 1 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 63.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 102.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > Soon after we login remotely, the heat ramps up again to the point were > > you can't keep the 'subject:' machine on your lap; there are time we do > > need to use the machine directly which includes placing the machine on > > ones' lap. > > > > With that being said, 'man powerd' states the default is to run in > > "adaptive" mode but, the bug section of the same man page states: > > > > "If powerd is used with power_profile, they may override each other." > > > > -- How do I know, or find out, if the above (override) is taking place? > > -- How to tell what state/mode 'powerd' is in at any particular timestamp? > > Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop > (if it's running) then run 'powerd -v' which runs in foreground and says > exactly what it's doing re shifting CPU frequency under various loads. > > It's also useful to watch the temperature(s) directly over the time, see > acpi_thermal(4) and try logging those sysctls periodically in a script. > > Firstly, yes that comment isn't too helpful .. power_profile only acts > (so far) when you apply or remove AC power, using the following values > from /etc/defaults/rc.conf unless you've set them otherwise: > > performance_cx_lowest="HIGH" # Online CPU idle state > performance_cpu_freq="HIGH" # Online CPU frequency > economy_cx_lowest="HIGH" # Offline CPU idle state > economy_cpu_freq="HIGH" # Offline CPU frequency > > If you have a look at /etc/rc.d/power_profile you'll see that these are > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > variables to HIGH, LOW, a specific value, or NONE. > > Specify "NONE" to have power_profile make no changes. "C3" or at least > "C2" can be useful CX values, in some machines helping with temperature. > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > a problem - again, watch powerd -v output - and I guess you'll rarely > run on battery (you've got a nice 2-3 hour UPS, though :) This is another issue in addition to the heat. As you say, this battery should last any where from 2-3 hours, however as it is now; out-of-the-box so to speak, this machine will only stay powered up approximately 1-hour on using the oem battery. > > > This machine has never run this hot, prior to running 'powerd'-- or run > > this warm, while idling with 'powerd' in comparison to running under windows > > --not trying to start and OS confilict here, trying to learn, understand > > and control this beast of a machine if possible. > > Of course, and it's likely doable, though you might need to run 7-STABLE > for the latest dual-core ACPI handling. Let's see how we go with some > real information, before suggesting taking this to freebsd-acpi@. I > don't see where you've mentioned what version of FreeBSD it's running? I believe I did so at the outset of this thread. In any case dmesg has now provided that information. > > > FreeBSD is allowing me to handle my data in a more flexable, feature rich, > > secure and Free manner than windows. We would prefer to stay with > > FreeBSD, but not if its going to burn-up our hardware. We had to take our > > previous AMD/smp machine down because we couldn't keep the heat down > > without leaving the case open. We loved that machine but it kept freezing > > due to heat. > > > > There is another issue whereby 'APM' is enabled in /etc/rc.conf but while > > booting the machine the scrolling text is saying the 'APM' module, or > > something like that will not be loaded because of a missing kernel > > option/device. But the kernel notes say its no longer neccessary to build > > the 'APM' into the kernel. Can someone enlighten me as to what I should > > be doing with regards to bringing this heat down in addition to the 'APM' > > not actually being loaded when its enabled in the kernel. > > You really don't want to run APM on modern hardware unless the ACPI on > your machine is really, really broken, not even fixable by recompiling > the AML code. And I'm fairly sure that ACPI is required to run SMP (ie > to use both cores). Make sure that ACPI, not APM, is enabled in BIOS. I'll remove APM from /erc/rc.conf > > Let's start from a dmesg, sysctl hw.acpi and some powerd -v output ? > > cheers, Ian > > > > > Thank you. > > > > TECRA_A9-S9017 > > > > > > > >My goals are: 1) to control the cpu and associated hardware (heat) 2) get > > > >all the native/installed hardware supported. 3) support for a "sierra > > > >wireless compass 597" <--> usb wireless WAN. Should FreeBSD not support > > > >all of this machines hardware then we need not continue --unless people > > > >are actively working of support/drivers for the above. > > > > > > Judging by the factory specs, you will probably find that 90% of the > > > hardware is supported or has a driver under development. Don't hold your > > > breath for the fingerprint reader, though. The wireless modem is a crap > > > shoot. > > > > > > >I've been trying to work with FreeBSD on this TECRA A9 for the better part > > > >of two weeks and there are too many outstanding issues to continue. From freebsd_user at guice.ath.cx Tue Aug 26 08:41:15 2008 From: freebsd_user at guice.ath.cx (freebsd_user@guice.ath.cx) Date: Tue Aug 26 08:41:22 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support In-Reply-To: <20080826002657.B14827@sola.nimnet.asn.au> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> Message-ID: <20080826084027.GA8703@WORKSTATION.guice.ath.cx> For those just starting to follow this thread, you can somewhat start at the begining here: In-Reply-To: <489E9531.2090200@guice.ath.cx> - - Here's more data to append onto my last message; In-Reply-To: <20080826002657.B14827@sola.nimnet.asn.au> -- in response to your: > However we need some empirical data about what it's doing. Showing > your /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > With respects to 'powered' we ran in to a speed bump or two (2). IAN: > (if it's running) then run 'powerd -v' which runs in foreground and says > exactly what it's doing re shifting CPU frequency under various loads. > freebsd_user: Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd stop powerd not running? Tue Aug 26 03:30:40 EDT 2008 --> Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd -v /etc/rc.d/powerd: unknown directive '-v'. Usage: /etc/rc.d/powerd [fast|force|one](start|stop|restart|rcvar|status|poll) Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd start -v Starting powerd. powerd: lookup freq: No such file or directory Tue Aug 26 03:30:40 EDT 2008 --> ps auxww | grep -i powerd root 9190 0.0 0.0 372 208 p3 R+ 3:32AM 0:00.00 grep -i powerd Tue Aug 26 03:30:40 EDT 2008 --> ps auxww | grep -i powerd Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd start -v Starting powerd. powerd: lookup freq: No such file or directory Tue Aug 26 03:30:40 EDT 2008 --> ps auxww | grep -i powerd Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd start -v Starting powerd. powerd: lookup freq: No such file or directory Now I'm curious about the contents of /etc/rc.d/powerd ... powerd_poststop() { sysctl dev.cpu.0.freq=`sysctl -n dev.cpu.0.freq_levels | sed -e 's:/.*::'` > /dev/null } which prompts me to look at the following 'sysctl' ... Tue Aug 26 03:30:40 EDT 2008 --> sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.cx_supported: C1/157 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% Tue Aug 26 03:30:40 EDT 2008 --> sysctl -a |grep -i freq kern.acct_chkfreq: 15 debug.cpufreq.lowest: 0 debug.cpufreq.verbose: 0 machdep.tsc_freq: 2194521505 machdep.i8254_freq: 1193182 machdep.acpi_timer_freq: 3579545 Tue Aug 26 03:30:40 EDT 2008 --> Unless I've missed or mistyped something, the file /etc/rc.d/powerd is trying to set a variable (dev.cpu.0.freq=) using the value(s) of "sysctl dev.cpu.0.freq_levels". Once again unless I've missed or mistyped something, and please correct me if I'm wrong,"sysctl dev.cpu.0.freq_levels" doesn't seem to exist within the machine. If UPGRADING from 6.3-p3 to 7.X will save us all some time with the issues stated in this thread, then so be it. I don't mind trouble-shooting or customizing issues such as this, but it may be a bit much given my mobile nature. Time permiting I'll get to your next suggetion shown; just below this line: > It's also useful to watch the temperature(s) directly over the time, see ug > acpi_thermal(4) and try logging those sysctls periodically in a script. > > Firstly, yes that comment isn't too helpful .. power_profile only acts > (so far) when you apply or remove AC power, using the following values > from /etc/defaults/rc.conf unless you've set them otherwise: > > performance_cx_lowest="HIGH" # Online CPU idle state > performance_cpu_freq="HIGH" # Online CPU frequency > economy_cx_lowest="HIGH" # Offline CPU idle state > economy_cpu_freq="HIGH" # Offline CPU frequency > > If you have a look at /etc/rc.d/power_profile you'll see that these are > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > variables to HIGH, LOW, a specific value, or NONE. > > Specify "NONE" to have power_profile make no changes. "C3" or at least > "C2" can be useful CX values, in some machines helping with temperature. > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > a problem - again, watch powerd -v output - and I guess you'll rarely > run on battery (you've got a nice 2-3 hour UPS, though :) > Your thoughts? > cheers, Ian > > > > > Thank you. > > > > TECRA_A9-S9017 Wes Morgan, are you there? :=) From smithi at nimnet.asn.au Tue Aug 26 10:27:38 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue Aug 26 10:27:45 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support In-Reply-To: <20080825191804.GA6846@WORKSTATION.guice.ath.cx> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> <20080825191804.GA6846@WORKSTATION.guice.ath.cx> Message-ID: <20080826182124.O14827@sola.nimnet.asn.au> On Mon, 25 Aug 2008, freebsd_user@guice.ath.cx wrote: > On Tue, Aug 26, 2008 at 01:30:22AM +1000, Ian Smith wrote: [..] > > On Sun, 24 Aug 2008, freebsd_user@guice.ath.cx wrote: > > > Continuing this thread. See below for annotations > > > > > > On Sun, Aug 10, 2008 at 09:28:19PM -0500, Wes Morgan wrote: > > > > On Sun, 10 Aug 2008, freebsd_user@guice.ath.cx wrote: > > > > > > > > > I've been through his before with an AMD setup (desktop) and now, > > > > >here we go again using a Toshiba TECRA A9-S9017 laptop. The issue here is, > > > > >is > > > > >appears that FreeBSD is causing the motherboard and its chipset(s) > > > > >and/or CPU's to work wide open (full throttle) --disregard for APM. I'm > > > > APM? I guess you mean ACPI on a modern laptop? See below .. > At this point I was speaking of APM. While the machine is booting > there was a time it printed something to the effect that 'APM' > could/would not be loaded/enabled because of a missing device/optin > in the kernerl. Ok .. considering APM as n/a from here on. > > > > >basing this on the amount of heat coming from this current laptop while > > > > >the laptop is idling, The heat is to the point that you can't keep the > > > > >laptop on your lap; in addition to the battery not lasting quite an hour > > > > >while idling. > > > > > > > > Try using powerd(8). > > > > > > > > > > I have done so with little improvement as far as the heat goes. When we > > > first requested help (this thread), the role of this machine was to be a > > > freebsd desktop. Since then we lost a mail server and have been forced to [..] > Back to the here and now. :=) Yes, and cutting to the chase .. > > However we need some empirical data about what it's doing. Showing your > > /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > > > Initially we didn't provide that data until someone asked for it to be sure that is > in fact what was needed or if the was some other incorrect setting. > > /var/run/dmesg.boot ... I'm trimming this down to the likely relevant ACPI stuff .. > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 6.3-RELEASE-p3 #1: Mon Aug 4 23:37:02 EDT 2008 > root@WORKSTATION.ath.cx:/usr/obj/usr/src/sys/WORKSTATION > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > Features=0xbfebfbff > Features2=0xe3bd > AMD Features=0x20100000 > AMD Features2=0x1 > Cores per package: 2 > real memory = 2113142784 (2015 MB) > avail memory = 2058563584 (1963 MB) > ioapic0: Changing APIC ID to 1 > ioapic0 irqs 0-23 on motherboard [..] > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > cpu0: on acpi0 [..] > acpi_lid0: on acpi0 > battery0: on acpi0 > acpi_button0: on acpi0 > acpi_acad0: on acpi0 > acpi_tz0: on acpi0 [..] No cpufreq driver/s. cpufreq removed from your custom kernel? So no CPU frequency control. So, powerd is rendered powerless .. Try booting with the GENERIC kernel, you should see one or two of the supported drivers listed in cpufreq(4) loaded in dmesg.boot. Then see if powerd isn't doing the right thing (w/ powerd -v as discussed below) > sysctl hw.acpi ... > > hw.acpi.supported_sleep_state: S3 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S3 > hw.acpi.lid_switch_state: NONE > hw.acpi.standby_state: S1 > hw.acpi.suspend_state: S3 > hw.acpi.sleep_delay: 1 > hw.acpi.s4bios: 0 > hw.acpi.verbose: 0 > hw.acpi.disable_on_reboot: 0 > hw.acpi.handle_reboot: 0 > hw.acpi.reset_video: 0 > hw.acpi.cpu.cx_lowest: C1 > hw.acpi.battery.life: 100 > hw.acpi.battery.time: -1 > hw.acpi.battery.state: 0 > hw.acpi.battery.units: 1 > hw.acpi.battery.info_expire: 5 > hw.acpi.acline: 1 > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 63.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 102.0C > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 No passive cooling. See acpi_thermal(4) .. you may want to set some overrides .. but it might all just work with the GENERIC kernel anyway. Also, have you set anything in BIOS regarding power usage, speedstep or any other settings that might get reflected into your boot ACPI setup? And, are you loading acpi_toshiba(4)? Not sure if it would help with this, but may at least provide some useful info in its sysctls .. > > > Soon after we login remotely, the heat ramps up again to the point were > > > you can't keep the 'subject:' machine on your lap; there are time we do > > > need to use the machine directly which includes placing the machine on > > > ones' lap. > > > > > > With that being said, 'man powerd' states the default is to run in > > > "adaptive" mode but, the bug section of the same man page states: > > > > > > "If powerd is used with power_profile, they may override each other." > > > > > > -- How do I know, or find out, if the above (override) is taking place? > > > -- How to tell what state/mode 'powerd' is in at any particular timestamp? > > > > Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop > > (if it's running) then run 'powerd -v' which runs in foreground and says > > exactly what it's doing re shifting CPU frequency under various loads. > > > > It's also useful to watch the temperature(s) directly over the time, see > > acpi_thermal(4) and try logging those sysctls periodically in a script. > > > > Firstly, yes that comment isn't too helpful .. power_profile only acts > > (so far) when you apply or remove AC power, using the following values > > from /etc/defaults/rc.conf unless you've set them otherwise: > > > > performance_cx_lowest="HIGH" # Online CPU idle state > > performance_cpu_freq="HIGH" # Online CPU frequency > > economy_cx_lowest="HIGH" # Offline CPU idle state > > economy_cpu_freq="HIGH" # Offline CPU frequency > > > > If you have a look at /etc/rc.d/power_profile you'll see that these are > > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > > variables to HIGH, LOW, a specific value, or NONE. > > > > Specify "NONE" to have power_profile make no changes. "C3" or at least > > "C2" can be useful CX values, in some machines helping with temperature. > > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > > a problem - again, watch powerd -v output - and I guess you'll rarely > > run on battery (you've got a nice 2-3 hour UPS, though :) > > This is another issue in addition to the heat. As you say, this battery > should last any where from 2-3 hours, however as it is now; > out-of-the-box so to speak, this machine will only stay powered up > approximately 1-hour on using the oem battery. That's because it runs at (presumably) its maximum frequency all of the time; you're lucky to get an hour at that rate, and yes it'll run hot :) 'sysctl dev.cpu.0.freq hw.acpi.thermal.tz0.temperature' now and again. > > > This machine has never run this hot, prior to running 'powerd'-- or run > > > this warm, while idling with 'powerd' in comparison to running under windows > > > --not trying to start and OS confilict here, trying to learn, understand > > > and control this beast of a machine if possible. > > > > Of course, and it's likely doable, though you might need to run 7-STABLE > > for the latest dual-core ACPI handling. Let's see how we go with some > > real information, before suggesting taking this to freebsd-acpi@. I > > don't see where you've mentioned what version of FreeBSD it's running? > > I believe I did so at the outset of this thread. In any case dmesg has > now provided that information. ok, 6.3-R-p3. Frankly I've no idea whether your dual-core Toshiba is or is not subject to any of the dual-core issues solved or being actively worked on in freebsd-acpi and being applied mostly or at least firstly back into 7-STABLE. I'd suggest browsing the -acpi archives for the last few months, it's not that big .. that is, if using the GENERIC kernel and running powerd doesn't improve matters sufficiently. cheers, Ian From morganw at chemikals.org Tue Aug 26 11:00:42 2008 From: morganw at chemikals.org (Wes Morgan) Date: Tue Aug 26 11:00:50 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support In-Reply-To: <20080826084027.GA8703@WORKSTATION.guice.ath.cx> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> <20080826084027.GA8703@WORKSTATION.guice.ath.cx> Message-ID: On Tue, 26 Aug 2008, freebsd_user@guice.ath.cx wrote: > For those just starting to follow this thread, you can somewhat start at the > begining here: In-Reply-To: <489E9531.2090200@guice.ath.cx> > - > - > Here's more data to append onto my last message; In-Reply-To: > <20080826002657.B14827@sola.nimnet.asn.au> -- in response to your: > >> However we need some empirical data about what it's doing. Showing >> your /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. >> > > With respects to 'powered' we ran in to a speed bump or two (2). > > IAN: >> (if it's running) then run 'powerd -v' which runs in foreground and says >> exactly what it's doing re shifting CPU frequency under various loads. >> > > freebsd_user: > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd stop > powerd not running? > Tue Aug 26 03:30:40 EDT 2008 --> > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd -v > /etc/rc.d/powerd: unknown directive '-v'. > Usage: /etc/rc.d/powerd > [fast|force|one](start|stop|restart|rcvar|status|poll) > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd start -v > Starting powerd. > powerd: lookup freq: No such file or directory > Tue Aug 26 03:30:40 EDT 2008 --> ps auxww | grep -i powerd > root 9190 0.0 0.0 372 208 p3 R+ 3:32AM 0:00.00 grep -i > powerd > Tue Aug 26 03:30:40 EDT 2008 --> ps auxww | grep -i powerd > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd start -v > Starting powerd. > powerd: lookup freq: No such file or directory > Tue Aug 26 03:30:40 EDT 2008 --> ps auxww | grep -i powerd > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd start -v > Starting powerd. > powerd: lookup freq: No such file or directory By "powerd -v" he means not the rc.d script but /usr/sbin/powerd, ie: [root@catalyst:/usr/home/morganw#]: powerd -v powerd: using sysctl for AC line status powerd: using devd for AC line status > Tue Aug 26 03:30:40 EDT 2008 --> sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.cx_supported: C1/157 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% > Tue Aug 26 03:30:40 EDT 2008 --> sysctl -a |grep -i freq > kern.acct_chkfreq: 15 > debug.cpufreq.lowest: 0 > debug.cpufreq.verbose: 0 > machdep.tsc_freq: 2194521505 > machdep.i8254_freq: 1193182 > machdep.acpi_timer_freq: 3579545 > Tue Aug 26 03:30:40 EDT 2008 --> > > Unless I've missed or mistyped something, the file /etc/rc.d/powerd is > trying to set a variable (dev.cpu.0.freq=) using the value(s) of "sysctl dev.cpu.0.freq_levels". > Once again unless I've missed or mistyped something, and please correct me if I'm wrong,"sysctl > dev.cpu.0.freq_levels" doesn't seem to exist within the machine. > > If UPGRADING from 6.3-p3 to 7.X will save us all some time with the issues stated in this > thread, then so be it. I don't mind trouble-shooting or customizing issues such > as this, but it may be a bit much given my mobile nature. It looks like you don't have coretemp and/or cpufreq in your kernel. Load those modules or include them in your kernel configuration. I don't think powerd will be able to do anything without that. > Time permiting I'll get to your next suggetion shown; just below this > line: > >> It's also useful to watch the temperature(s) directly over the time, see ug >> acpi_thermal(4) and try logging those sysctls periodically in a script. >> >> Firstly, yes that comment isn't too helpful .. power_profile only acts >> (so far) when you apply or remove AC power, using the following values >> from /etc/defaults/rc.conf unless you've set them otherwise: >> >> performance_cx_lowest="HIGH" # Online CPU idle state >> performance_cpu_freq="HIGH" # Online CPU frequency >> economy_cx_lowest="HIGH" # Offline CPU idle state >> economy_cpu_freq="HIGH" # Offline CPU frequency >> >> If you have a look at /etc/rc.d/power_profile you'll see that these are >> applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) >> and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above >> variables to HIGH, LOW, a specific value, or NONE. >> >> Specify "NONE" to have power_profile make no changes. "C3" or at least >> "C2" can be useful CX values, in some machines helping with temperature. >> powerd will soon override the dev.cpu.0.freq setting anyway, so it's not >> a problem - again, watch powerd -v output - and I guess you'll rarely >> run on battery (you've got a nice 2-3 hour UPS, though :) >> > > Your thoughts? > >> cheers, Ian >> >> > >> > Thank you. >> > >> > TECRA_A9-S9017 > > Wes Morgan, are you there? :=) > From smithi at nimnet.asn.au Tue Aug 26 11:01:40 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue Aug 26 11:01:47 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support In-Reply-To: <20080826084027.GA8703@WORKSTATION.guice.ath.cx> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> <20080826084027.GA8703@WORKSTATION.guice.ath.cx> Message-ID: <20080826203021.W14827@sola.nimnet.asn.au> On Tue, 26 Aug 2008, freebsd_user@guice.ath.cx wrote: > For those just starting to follow this thread, you can somewhat start at the > begining here: In-Reply-To: <489E9531.2090200@guice.ath.cx> > - > - > Here's more data to append onto my last message; In-Reply-To: > <20080826002657.B14827@sola.nimnet.asn.au> -- in response to your: > > > However we need some empirical data about what it's doing. Showing > > your /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > > > > With respects to 'powered' we ran in to a speed bump or two (2). > > IAN: > > (if it's running) then run 'powerd -v' which runs in foreground and says > > exactly what it's doing re shifting CPU frequency under various loads. > > > > freebsd_user: > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd stop > powerd not running? Right, it wasn't running because cpufreq isn't loaded, as below. Check 'kldstat -v | grep cpufreq' > Tue Aug 26 03:30:40 EDT 2008 --> > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd -v > /etc/rc.d/powerd: unknown directive '-v'. > Usage: /etc/rc.d/powerd > [fast|force|one](start|stop|restart|rcvar|status|poll) No, I'd have said; not /etc/rc.d/powerd, but just 'powerd -v' % which powerd /usr/sbin/powerd The idea is to start powerd manually, with -v switch, in foreground in its own window or vty, as shown in powerd(4) > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd start -v > Starting powerd. > powerd: lookup freq: No such file or directory Yes; it won't even startup without finding the cpu freq sysctls. I'm surprised that powerd failing to start hasn't been logged in /var/log/messages every time you've tried .. ? > Tue Aug 26 03:30:40 EDT 2008 --> ps auxww | grep -i powerd > root 9190 0.0 0.0 372 208 p3 R+ 3:32AM 0:00.00 grep -i > powerd > Tue Aug 26 03:30:40 EDT 2008 --> ps auxww | grep -i powerd > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd start -v > Starting powerd. > powerd: lookup freq: No such file or directory > Tue Aug 26 03:30:40 EDT 2008 --> ps auxww | grep -i powerd > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd start -v > Starting powerd. > powerd: lookup freq: No such file or directory > > Now I'm curious about the contents of /etc/rc.d/powerd ... Curious is good :) > powerd_poststop() > { > sysctl dev.cpu.0.freq=`sysctl -n dev.cpu.0.freq_levels | > sed -e 's:/.*::'` > /dev/null > } That'll be to reset dev.cpu.0.freq to its highest speed after quitting. > which prompts me to look at the following 'sysctl' ... > > Tue Aug 26 03:30:40 EDT 2008 --> sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.cx_supported: C1/157 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% Yep, and all the freq stuff is missing. Refer previous message. > Tue Aug 26 03:30:40 EDT 2008 --> sysctl -a |grep -i freq > kern.acct_chkfreq: 15 > debug.cpufreq.lowest: 0 > debug.cpufreq.verbose: 0 > machdep.tsc_freq: 2194521505 > machdep.i8254_freq: 1193182 > machdep.acpi_timer_freq: 3579545 > Tue Aug 26 03:30:40 EDT 2008 --> > > Unless I've missed or mistyped something, the file /etc/rc.d/powerd is > trying to set a variable (dev.cpu.0.freq=) using the value(s) of "sysctl dev.cpu.0.freq_levels". Right. See /usr/src/usr.sbin/powerd/powerd.c to see what/how it does. > Once again unless I've missed or mistyped something, and please correct me if I'm wrong,"sysctl > dev.cpu.0.freq_levels" doesn't seem to exist within the machine. Yes, that's the (possibly but not necessarily whole) problem. > If UPGRADING from 6.3-p3 to 7.X will save us all some time with the issues stated in this > thread, then so be it. I don't mind trouble-shooting or customizing issues such > as this, but it may be a bit much given my mobile nature. I can't tell if upgrading would help. Try the GENERIC kernel first - or at least one having cpufreq, but perhaps you left out something else you didn't know was necessary? Unsure whether you can just kldload cpufreq in /boot/loader.conf with your current kernel, but it's an easy test. > Time permiting I'll get to your next suggetion shown; just below this > line: > > > It's also useful to watch the temperature(s) directly over the time, see ug > > acpi_thermal(4) and try logging those sysctls periodically in a script. All good for debugging, but with cpufreq, maybe it will just go? :) [..] cheers, Ian From sam at freebsd.org Tue Aug 26 15:55:36 2008 From: sam at freebsd.org (Sam Leffler) Date: Tue Aug 26 15:55:43 2008 Subject: Is 'ath' going to be updated for 7.1-RELEASE ? In-Reply-To: <87vdxr9d9y.fsf@chateau.d.lf> References: <87vdxr9d9y.fsf@chateau.d.lf> Message-ID: <48B42777.1050304@freebsd.org> Ashish Shukla ???? ????? wrote: > Hi, > > Just came across the release schedule of 7.1-RELEASE. I'm wondering if > new version of 'ath' driver (for Athereos Wireless chipsets) is going > to be included or not ? If yes, I'll be glad to try the betas :). > > Not sure what "new version" means. I'm unlikely to have any time to look at existing ath problems in RELENG_7 before the release. Sam From jmt at twilley.org Tue Aug 26 17:47:48 2008 From: jmt at twilley.org (Jack Twilley) Date: Tue Aug 26 17:47:55 2008 Subject: Is 'ath' going to be updated for 7.1-RELEASE ? In-Reply-To: <48B42777.1050304@freebsd.org> References: <87vdxr9d9y.fsf@chateau.d.lf> <48B42777.1050304@freebsd.org> Message-ID: <48B43D90.8090807@twilley.org> Sam Leffler wrote: > Ashish Shukla ???? ????? wrote: >> Hi, >> >> Just came across the release schedule of 7.1-RELEASE. I'm wondering if >> new version of 'ath' driver (for Athereos Wireless chipsets) is going >> to be included or not ? If yes, I'll be glad to try the betas :). >> >> > Not sure what "new version" means. I'm unlikely to have any time to > look at existing ath problems in RELENG_7 before the release. I am hoping against hope it means "whatever it takes to make the Asus Eee PC work without having to follow the steps on the EeeBSD page". I rebuilt kernel and world today and forgot *again* to do the madwifi dance. It's getting old. Jack. > > Sam > > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" From sam at freebsd.org Tue Aug 26 18:47:40 2008 From: sam at freebsd.org (Sam Leffler) Date: Tue Aug 26 18:47:46 2008 Subject: Is 'ath' going to be updated for 7.1-RELEASE ? In-Reply-To: <48B43D90.8090807@twilley.org> References: <87vdxr9d9y.fsf@chateau.d.lf> <48B42777.1050304@freebsd.org> <48B43D90.8090807@twilley.org> Message-ID: <48B44FCA.9070609@freebsd.org> Jack Twilley wrote: > Sam Leffler wrote: >> Ashish Shukla ???????????? ??????????????? wrote: >>> Hi, >>> >>> Just came across the release schedule of 7.1-RELEASE. I'm wondering if >>> new version of 'ath' driver (for Athereos Wireless chipsets) is going >>> to be included or not ? If yes, I'll be glad to try the betas :). >>> >>> >> Not sure what "new version" means. I'm unlikely to have any time to >> look at existing ath problems in RELENG_7 before the release. > > I am hoping against hope it means "whatever it takes to make the Asus > Eee PC work without having to follow the steps on the EeeBSD page". I > rebuilt kernel and world today and forgot *again* to do the madwifi > dance. It's getting old. The required hal is not even committed to HEAD yet; there's no way it's going to get into RELENG_7 w/o significant testing. As to "getting old" others are free to pitch in to make things happen. I have very little time for freebsd right now and what time I do have is focused on higher priority issues. Sam From jmt at twilley.org Tue Aug 26 18:58:55 2008 From: jmt at twilley.org (Jack Twilley) Date: Tue Aug 26 18:59:02 2008 Subject: Is 'ath' going to be updated for 7.1-RELEASE ? In-Reply-To: <48B44FCA.9070609@freebsd.org> References: <87vdxr9d9y.fsf@chateau.d.lf> <48B42777.1050304@freebsd.org> <48B43D90.8090807@twilley.org> <48B44FCA.9070609@freebsd.org> Message-ID: <48B4526E.8000802@twilley.org> Sam Leffler wrote: > Jack Twilley wrote: >> Sam Leffler wrote: >>> Ashish Shukla ???????????? ??????????????? wrote: >>>> Hi, >>>> >>>> Just came across the release schedule of 7.1-RELEASE. I'm wondering if >>>> new version of 'ath' driver (for Athereos Wireless chipsets) is going >>>> to be included or not ? If yes, I'll be glad to try the betas :). >>>> >>>> >>> Not sure what "new version" means. I'm unlikely to have any time to >>> look at existing ath problems in RELENG_7 before the release. >> I am hoping against hope it means "whatever it takes to make the Asus >> Eee PC work without having to follow the steps on the EeeBSD page". I >> rebuilt kernel and world today and forgot *again* to do the madwifi >> dance. It's getting old. > > The required hal is not even committed to HEAD yet; there's no way it's > going to get into RELENG_7 w/o significant testing. As to "getting old" > others are free to pitch in to make things happen. I have very little > time for freebsd right now and what time I do have is focused on higher > priority issues. All I can offer is the ability to test. I do not have the skill necessary to fix this or I would have written a fix and asked for it to be committed. It is amazingly frustrating to know that there is a workaround and to see that others consider this a low priority issue. If not you, then who should I ask about committing the new HAL to HEAD and helping me check out whatever I need to check out to test the fix so the rest of us can have wireless Ethernet working out of the box? Jack. > > Sam > > From sam at freebsd.org Tue Aug 26 19:39:24 2008 From: sam at freebsd.org (Sam Leffler) Date: Tue Aug 26 19:39:30 2008 Subject: Is 'ath' going to be updated for 7.1-RELEASE ? In-Reply-To: <48B4526E.8000802@twilley.org> References: <87vdxr9d9y.fsf@chateau.d.lf> <48B42777.1050304@freebsd.org> <48B43D90.8090807@twilley.org> <48B44FCA.9070609@freebsd.org> <48B4526E.8000802@twilley.org> Message-ID: <48B45BEB.2090502@freebsd.org> Jack Twilley wrote: > Sam Leffler wrote: >> Jack Twilley wrote: >>> Sam Leffler wrote: >>>> Ashish Shukla ? ???? ? ????? ?????? ???? >>>> ? ????? ????? ?????? ????? ???? wrote: >>>>> Hi, >>>>> >>>>> Just came across the release schedule of 7.1-RELEASE. I'm >>>>> wondering if >>>>> new version of 'ath' driver (for Athereos Wireless chipsets) is going >>>>> to be included or not ? If yes, I'll be glad to try the betas :). >>>>> >>>>> >>>> Not sure what "new version" means. I'm unlikely to have any time to >>>> look at existing ath problems in RELENG_7 before the release. >>> I am hoping against hope it means "whatever it takes to make the Asus >>> Eee PC work without having to follow the steps on the EeeBSD page". I >>> rebuilt kernel and world today and forgot *again* to do the madwifi >>> dance. It's getting old. >> >> The required hal is not even committed to HEAD yet; there's no way it's >> going to get into RELENG_7 w/o significant testing. As to "getting old" >> others are free to pitch in to make things happen. I have very little >> time for freebsd right now and what time I do have is focused on higher >> priority issues. > > All I can offer is the ability to test. I do not have the skill > necessary to fix this or I would have written a fix and asked for it > to be committed. It is amazingly frustrating to know that there is a > workaround and to see that others consider this a low priority issue. > > If not you, then who should I ask about committing the new HAL to HEAD > and helping me check out whatever I need to check out to test the fix > so the rest of us can have wireless Ethernet working out of the box? I have repeatedly asked for testing of the 0.10.5.6 hal sitting in http://www.freebsd.org/~sam on HEAD but not gotten enough results to commit to HEAD. I will not commit a hal to any tree that causes regressions. Atheros long ago yanked the testing resources I used to validate hal's for release so I am uncertain whether this hal will introduce regressions. If things go bad I simply don't have the time to deal with it so nothing has gone in. Past that a backport to RELENG_7 is straightforward but again nothing happens until code is in HEAD. I am asking around for someone else to deal with a commit to HEAD. Sam From gaijin.k at gmail.com Wed Aug 27 01:41:35 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Wed Aug 27 01:41:41 2008 Subject: Is 'ath' going to be updated for 7.1-RELEASE ? In-Reply-To: <48B45BEB.2090502@freebsd.org> References: <87vdxr9d9y.fsf@chateau.d.lf> <48B42777.1050304@freebsd.org> <48B43D90.8090807@twilley.org> <48B44FCA.9070609@freebsd.org> <48B4526E.8000802@twilley.org> <48B45BEB.2090502@freebsd.org> Message-ID: <1219801283.1118.26.camel@RabbitsDen> On Tue, 2008-08-26 at 12:39 -0700, Sam Leffler wrote: > Jack Twilley wrote: > > Sam Leffler wrote: > >> Jack Twilley wrote: > >>> Sam Leffler wrote: > >>>> Ashish Shukla ? ???? ? ????? ?????? ???? > >>>> ? ????? ????? ?????? ????? ???? wrote: > >>>>> Hi, > >>>>> > >>>>> Just came across the release schedule of 7.1-RELEASE. I'm > >>>>> wondering if > >>>>> new version of 'ath' driver (for Athereos Wireless chipsets) is going > >>>>> to be included or not ? If yes, I'll be glad to try the betas :). > >>>>> > >>>>> > >>>> Not sure what "new version" means. I'm unlikely to have any time to > >>>> look at existing ath problems in RELENG_7 before the release. > >>> I am hoping against hope it means "whatever it takes to make the Asus > >>> Eee PC work without having to follow the steps on the EeeBSD page". I > >>> rebuilt kernel and world today and forgot *again* to do the madwifi > >>> dance. It's getting old. > >> > >> The required hal is not even committed to HEAD yet; there's no way it's > >> going to get into RELENG_7 w/o significant testing. As to "getting old" > >> others are free to pitch in to make things happen. I have very little > >> time for freebsd right now and what time I do have is focused on higher > >> priority issues. > > > > All I can offer is the ability to test. I do not have the skill > > necessary to fix this or I would have written a fix and asked for it > > to be committed. It is amazingly frustrating to know that there is a > > workaround and to see that others consider this a low priority issue. > > > > If not you, then who should I ask about committing the new HAL to HEAD > > and helping me check out whatever I need to check out to test the fix > > so the rest of us can have wireless Ethernet working out of the box? > > I have repeatedly asked for testing of the 0.10.5.6 hal sitting in > http://www.freebsd.org/~sam on HEAD but not gotten enough results to > commit to HEAD. Since I am running RELENG_7 with 0.10.5.6 HAL anyway (to have ath and powerd happily coexisting) are there any specific scenarios, that you'd like tested? -- Alexandre "Sunny" Kovalenko (????????? ?????????) From wahjava.ml at gmail.com Wed Aug 27 03:38:59 2008 From: wahjava.ml at gmail.com (Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IA==?= =?utf-8?B?4KS24KWB4KSV4KWN4KSy?=) Date: Wed Aug 27 03:39:07 2008 Subject: Is 'ath' going to be updated for 7.1-RELEASE ? In-Reply-To: <48B42777.1050304@freebsd.org> (Sam Leffler's message of "Tue\, 26 Aug 2008 08\:55\:35 -0700") References: <87vdxr9d9y.fsf@chateau.d.lf> <48B42777.1050304@freebsd.org> Message-ID: <86prnvgm9b.fsf@chateau.d.lf> Sam Leffler writes: > Ashish Shukla ???? ????? wrote: >> Hi, >> >> Just came across the release schedule of 7.1-RELEASE. I'm wondering if >> new version of 'ath' driver (for Athereos Wireless chipsets) is going >> to be included or not ? If yes, I'll be glad to try the betas :). >> >> > Not sure what "new version" means. I'm unlikely to have any time to > look at existing ath problems in RELENG_7 before the release. By "new version" I meant, the new version of driver "ath" which works with HAL 0.10.5.6. No problem, if it is not going to be available in RELENG_7 soon :) . > Sam Ashish -- ?-- ?- ???? ?--- ?- ???- ?- ?--?-? --? -- ?- ?? ?-?? ?-?-?- -?-? --- -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-mobile/attachments/20080827/a32d9679/attachment.pgp From rpaulo at FreeBSD.org Thu Aug 28 01:00:50 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Thu Aug 28 01:00:57 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST Message-ID: <20080828002919.GA54169@alpha.local> Hi, We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of new chips, namely those on the Asus Eee PC, MacBooks and other laptops. If you have an Atheros or Atheros based card, I really wanted you to test it. We were unable to test this in several Atheros chipsets, so if you find a regression, please contact me or Sam Leffler (sam@freebsd.org) ASAP. So, please give it a try :-) Unfortuntely, this will only make 7.1 if the release date slips. So, don't expect this to be MFCed any time soon. Thanks, -- Rui Paulo From eculp at cloudmaster.info Thu Aug 28 01:13:06 2008 From: eculp at cloudmaster.info (eculp@cloudmaster.info) Date: Thu Aug 28 01:13:13 2008 Subject: Is 'ath' going to be updated for 7.1-RELEASE ? In-Reply-To: <48B45BEB.2090502@freebsd.org> References: <87vdxr9d9y.fsf@chateau.d.lf> <48B42777.1050304@freebsd.org> <48B43D90.8090807@twilley.org> <48B44FCA.9070609@freebsd.org> <48B4526E.8000802@twilley.org> <48B45BEB.2090502@freebsd.org> Message-ID: <20080827200258.96985hbhy2n5urs4@cloudmail.cloudmaster.info> Quoting Sam Leffler : > Jack Twilley wrote: >> Sam Leffler wrote: >>> Jack Twilley wrote: >>>> Sam Leffler wrote: >>>>> Ashish Shukla ? ???? ? ????? ?????? ???? ? ????? ????? ?????? >>>>> ????? ???? wrote: >>>>>> Hi, >>>>>> >>>>>> Just came across the release schedule of 7.1-RELEASE. I'm wondering if >>>>>> new version of 'ath' driver (for Athereos Wireless chipsets) is going >>>>>> to be included or not ? If yes, I'll be glad to try the betas :). >>>>>> >>>>>> >>>>> Not sure what "new version" means. I'm unlikely to have any time to >>>>> look at existing ath problems in RELENG_7 before the release. >>>> I am hoping against hope it means "whatever it takes to make the Asus >>>> Eee PC work without having to follow the steps on the EeeBSD page". I >>>> rebuilt kernel and world today and forgot *again* to do the madwifi >>>> dance. It's getting old. >>> >>> The required hal is not even committed to HEAD yet; there's no way it's >>> going to get into RELENG_7 w/o significant testing. As to "getting old" >>> others are free to pitch in to make things happen. I have very little >>> time for freebsd right now and what time I do have is focused on higher >>> priority issues. >> >> All I can offer is the ability to test. I do not have the skill >> necessary to fix this or I would have written a fix and asked for >> it to be committed. It is amazingly frustrating to know that there >> is a workaround and to see that others consider this a low priority >> issue. >> >> If not you, then who should I ask about committing the new HAL to >> HEAD and helping me check out whatever I need to check out to test >> the fix so the rest of us can have wireless Ethernet working out of >> the box? > > I have repeatedly asked for testing of the 0.10.5.6 hal sitting in > http://www.freebsd.org/~sam on HEAD but not gotten enough results to > commit to HEAD. I've been using ath_hal-20080528.tgz. with HEAD for quite some time and it works great on my AcerAspire 5520-5679. I'm automatically cvsuping, adding the contents of ath_hal-20080528.tgz and rebuilding world and kernel daily with no issues at all. It works perfectly for me. ed > I will not commit a hal to any tree that causes regressions. > Atheros long ago yanked the testing resources I used to validate > hal's for md5release so I am uncertain whether this hal will > introduce regressions. If things go bad I simply don't have the > time to deal with it so nothing has gone in. > > Past that a backport to RELENG_7 is straightforward but again > nothing happens until code is in HEAD. > > I am asking around for someone else to deal with a commit to HEAD. > > Sam > > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" > From eculp at cloudmaster.info Thu Aug 28 01:17:23 2008 From: eculp at cloudmaster.info (eculp@cloudmaster.info) Date: Thu Aug 28 01:17:29 2008 Subject: Is 'ath' going to be updated for 7.1-RELEASE ? In-Reply-To: <48B44FCA.9070609@freebsd.org> References: <87vdxr9d9y.fsf@chateau.d.lf> <48B42777.1050304@freebsd.org> <48B43D90.8090807@twilley.org> <48B44FCA.9070609@freebsd.org> Message-ID: <20080827201216.71255zt6zd2n0uww@cloudmail.cloudmaster.info> Quoting Sam Leffler : > Jack Twilley wrote: >> Sam Leffler wrote: >>> Ashish Shukla ???????????? ??????????????? wrote: >>>> Hi, >>>> >>>> Just came across the release schedule of 7.1-RELEASE. I'm wondering if >>>> new version of 'ath' driver (for Athereos Wireless chipsets) is going >>>> to be included or not ? If yes, I'll be glad to try the betas :). >>>> >>>> >>> Not sure what "new version" means. I'm unlikely to have any time to >>> look at existing ath problems in RELENG_7 before the release. >> >> I am hoping against hope it means "whatever it takes to make the Asus >> Eee PC work without having to follow the steps on the EeeBSD page". I >> rebuilt kernel and world today and forgot *again* to do the madwifi >> dance. It's getting old. > > The required hal is not even committed to HEAD yet; there's no way it's > going to get into RELENG_7 w/o significant testing. As to "getting old" > others are free to pitch in to make things happen. I have very little > time for freebsd right now and what time I do have is focused on higher > priority issues. Just saw the great news, Sam. Thanks for your work on this and for adding it to current. Checking my current@ email I found "HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST" which I'm completely confident will solve the problems without any more patching. I just changed my build script for tonight to not add the old patch the source. I'll comment tomorrow after booting the new kernel. Thanks again, Sam. ed. > > Sam > > > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" > From eculp at cloudmaster.info Thu Aug 28 14:37:30 2008 From: eculp at cloudmaster.info (eculp@cloudmaster.info) Date: Thu Aug 28 14:37:37 2008 Subject: Is 'ath' going to be updated for 7.1-RELEASE ? In-Reply-To: <20080827201216.71255zt6zd2n0uww@cloudmail.cloudmaster.info> References: <87vdxr9d9y.fsf@chateau.d.lf> <48B42777.1050304@freebsd.org> <48B43D90.8090807@twilley.org> <48B44FCA.9070609@freebsd.org> <20080827201216.71255zt6zd2n0uww@cloudmail.cloudmaster.info> Message-ID: <20080828093723.17542tn7hiadvpk4@cloudmail.cloudmaster.info> Quoting eculp@cloudmaster.info: > Quoting Sam Leffler : > >> Jack Twilley wrote: >>> Sam Leffler wrote: >>>> Ashish Shukla ???????????? ??????????????? wrote: >>>>> Hi, >>>>> >>>>> Just came across the release schedule of 7.1-RELEASE. I'm wondering if >>>>> new version of 'ath' driver (for Athereos Wireless chipsets) is going >>>>> to be included or not ? If yes, I'll be glad to try the betas :). >>>>> >>>>> >>>> Not sure what "new version" means. I'm unlikely to have any time to >>>> look at existing ath problems in RELENG_7 before the release. >>> >>> I am hoping against hope it means "whatever it takes to make the Asus >>> Eee PC work without having to follow the steps on the EeeBSD page". I >>> rebuilt kernel and world today and forgot *again* to do the madwifi >>> dance. It's getting old. >> >> The required hal is not even committed to HEAD yet; there's no way it's >> going to get into RELENG_7 w/o significant testing. As to "getting old" >> others are free to pitch in to make things happen. I have very little >> time for freebsd right now and what time I do have is focused on higher >> priority issues. > > Just saw the great news, Sam. Thanks for your work on this and for > adding it to current. Checking my current@ email I found "HEADS UP: > ath_hal updated to 0.10.5.10 -- PLEASE TEST" which I'm completely > confident will solve the problems without any more patching. I just > changed my build script for tonight to not add the old patch the > source. I'll comment tomorrow after booting the new kernel. > > Thanks again, Sam. > Results: Worked Perfectly for me in today's current without external patches. wlan0: flags=8843 metric 0 mtu 1500 ether 00:1d:d9:27:5c:e5 inet 172.16.0.7 netmask 0xffffff00 broadcast 172.16.0.255 media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g status: associated ssid virus channel 1 (2412 Mhz 11g) bssid 00:1d:7e:51:e1:4d regdomain 101 indoor ecm authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit txpower 16 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst # uname -a FreeBSD ed.local.net.mx 8.0-CURRENT FreeBSD 8.0-CURRENT #17: Thu Aug 28 05:50:27 CDT 2008 root@ed.local.net.mx:/usr/obj/usr/src/sys/ENCONTACTO i386 Thanks again to all who have made this happen. ed From josh at tcbug.org Sat Aug 30 15:12:32 2008 From: josh at tcbug.org (Josh Paetzel) Date: Sat Aug 30 15:12:39 2008 Subject: Heat issues on the IBM/Lenovo T60 resolved Message-ID: <200808300950.51698.josh@tcbug.org> I've been relatively happy with my T60, with the exception of the heat issues it's had since day one. The fan would run full out pretty much all the time, and it would frequently reach 99-100C when doing anything cpu intensive, regardless of OS. If there was any obstruction to the air vents it would shutdown due to overheating. It turns out this is not an uncommon problem with the T60/T61, people either complain of them being loud, or too hot, or sometimes both. After going down the road of OS tweaks and BIOS flashes I started burning up phone lines at Lenovo, and I was finally able to talk to someone who said they had some assembly problems that resulted in far too much thermal paste being applied to the cpu and heatsink. So, I disassembled my laptop, and sure enough, the thermal paste was applied much like a 3 year old applies grape jelly to a sandwich. I cleaned the heatsink, cpu, and gpu and applied some generic thermal paste I found at Best Buy. (caveat: The GPU uses a thermal pad that accomodates cooling the memory chips, which are at a different height. I cut out the area where the GPU makes contact and used thermal paste there, leaving the rest of the thermal pad in place to contact the ram) Upon reassembly I loaded up both cores with make buildworld and cpuburn, and initially feared I had damaged the fan speed sensor, as FreeBSD reported 0 rpm. The cpu temps very slowly climbed to 60C, where the fan spun up to a nearly inaudible 2000 rpm If I leave it at full CPU utilization the fan will eventually spin up to 3000rpm, and temps stabilize at 66-69C. Under normal use the fan rarely runs, a welcome change from it running full out all the time, especially on battery. I have a friend that was having similar problems with his T61, and has had similar success after reapplying the thermal paste. Fow what it's worth, Lenovo said the issue was covered under warranty, I just disn't feel like going through the hassle of shipping the laptop to them. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-mobile/attachments/20080830/0212d9a1/attachment.pgp From freebsd_user at guice.ath.cx Sat Aug 30 21:08:26 2008 From: freebsd_user at guice.ath.cx (freebsd_user@guice.ath.cx) Date: Sat Aug 30 21:08:33 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> <20080825191804.GA6846@WORKSTATION.guice.ath.cx> <20080826182124.O14827@sola.nimnet.asn.au> Message-ID: <20080830210736.GA4521@WORKSTATION.guice.ath.cx> On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx wrote: FROM THE LAST MESSAGE ... > > > > > However we need some empirical data about what it's doing. Showing your > > > > /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > > > > > > > Initially we didn't provide that data until someone asked for it to be sure that is > > > in fact what was needed or if the was some other incorrect setting. > > > > > > /var/run/dmesg.boot ... > > > > I'm trimming this down to the likely relevant ACPI stuff .. > > > > > Copyright (c) 1992-2008 The FreeBSD Project. > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > The Regents of the University of California. All rights reserved. > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > FreeBSD 6.3-RELEASE-p3 #1: Mon Aug 4 23:37:02 EDT 2008 > > > root@WORKSTATION.ath.cx:/usr/obj/usr/src/sys/WORKSTATION > > > ACPI APIC Table: > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) > > > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > > Features=0xbfebfbff > > > Features2=0xe3bd > > > AMD Features=0x20100000 > > > AMD Features2=0x1 > > > Cores per package: 2 > > > real memory = 2113142784 (2015 MB) > > > avail memory = 2058563584 (1963 MB) > > > ioapic0: Changing APIC ID to 1 > > > ioapic0 irqs 0-23 on motherboard > > [..] > > > acpi0: on motherboard > > > acpi0: Power Button (fixed) > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > cpu0: on acpi0 > > [..] > > > acpi_lid0: on acpi0 > > > battery0: on acpi0 > > > acpi_button0: on acpi0 > > > acpi_acad0: on acpi0 > > > acpi_tz0: on acpi0 > > [..] > > > > No cpufreq driver/s. cpufreq removed from your custom kernel? So no > > CPU frequency control. So, powerd is rendered powerless .. > > > 'powerd' is now operational: idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M ^Ctotal joules used: 41737.500^M > > Try booting with the GENERIC kernel, you should see one or two of the > > supported drivers listed in cpufreq(4) loaded in dmesg.boot. Then see > > if powerd isn't doing the right thing (w/ powerd -v as discussed below) > > > This has always been the /GENERIC kernel copied to a custome name. This was a 6.0-RELEASE UPGRADED TO -p3. Apparently cpufreq wasn't considered as a default entry in the /GENERIC. > > > > > sysctl hw.acpi ... > > > > > > hw.acpi.supported_sleep_state: S3 S4 S5 > > > hw.acpi.power_button_state: S5 > > > hw.acpi.sleep_button_state: S3 > > > hw.acpi.lid_switch_state: NONE > > > hw.acpi.standby_state: S1 > > > hw.acpi.suspend_state: S3 > > > hw.acpi.sleep_delay: 1 > > > hw.acpi.s4bios: 0 > > > hw.acpi.verbose: 0 > > > hw.acpi.disable_on_reboot: 0 > > > hw.acpi.handle_reboot: 0 > > > hw.acpi.reset_video: 0 > > > hw.acpi.cpu.cx_lowest: C1 > > > hw.acpi.battery.life: 100 > > > hw.acpi.battery.time: -1 > > > hw.acpi.battery.state: 0 > > > hw.acpi.battery.units: 1 > > > hw.acpi.battery.info_expire: 5 > > > hw.acpi.acline: 1 > > > hw.acpi.thermal.min_runtime: 0 > > > hw.acpi.thermal.polling_rate: 10 > > > hw.acpi.thermal.user_override: 0 > > > hw.acpi.thermal.tz0.temperature: 63.0C > > > hw.acpi.thermal.tz0.active: -1 > > > hw.acpi.thermal.tz0.passive_cooling: 0 > > > hw.acpi.thermal.tz0.thermal_flags: 0 > > > hw.acpi.thermal.tz0._PSV: -1 > > > hw.acpi.thermal.tz0._HOT: -1 > > > hw.acpi.thermal.tz0._CRT: 102.0C > > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > No passive cooling. See acpi_thermal(4) .. you may want to set some > > overrides .. but it might all just work with the GENERIC kernel anyway. > Attempting to: --> sysctl hw.acpi.thermal.user_override hw.acpi.thermal.user_override: 0 Attempting to: --> sysctl hw.acpi.thermal.user_override=1 hw.acpi.thermal.user_override: 0 -> 1 Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling hw.acpi.thermal.tz0.passive_cooling: 0 Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling=1 hw.acpi.thermal.tz0.passive_cooling: 0 sysctl: hw.acpi.thermal.tz0.passive_cooling: Operation not supported by device NOTE: While we are able to change the threshold for: hw.acpi.thermal.tz0._PSV: -1, we don't see the need to do so because the above passive_cooling is not enabled. Well, so much for passive_cooling. :=\ > > Also, have you set anything in BIOS regarding power usage, speedstep or > > any other settings that might get reflected into your boot ACPI setup? Initially we left the BIOS power settings the way the OEM set them (Vista). We are able to choose from one of Dynamic, High or low not much else to play with in the way of power settings (ACPI) with the exception of LCD and/or letting the OS control devices. Unable to directly set CPU steppings/freq settings within this BIOS. > > And, are you loading acpi_toshiba(4)? Not sure if it would help with > > this, but may at least provide some useful info in its sysctls .. > > > This is an issue revisited; take a deep breath. Better yet, here's the short version, in the kernel 'device acpi_toshiba' does not work for us on this machine unless we neglected to make an accompanying needed acpi entry. Aa we understand it, we were to only add 'device acpi_toshiba' to load the neccessary acpi toshiba extras. Using 'acpi_toshiba_load="YES"' in the /boot/loader.conf -and- using 'kldload acpi_toshiba' from the cli works like a charm but has no positive affect on the current discussion (heat). > > > > Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop > > > > (if it's running) then run 'powerd -v' which runs in foreground and says > > > > exactly what it's doing re shifting CPU frequency under various loads. idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M ^Ctotal joules used: 41737.500 > > > > > > > > It's also useful to watch the temperature(s) directly over the time, see > > > > acpi_thermal(4) and try logging those sysctls periodically in a script. The following data is the result of the concerns I have; running too hot. These figures are the lowest temperatures this machine idles while FreeBSD is installed and running. The temperatures shown herein only rise with use but never go lower than what we're showing here when the laptop returns to idle. Attempting to: --> sysctl hw.acpi.thermal.tz0. hw.acpi.thermal.tz0.temperature: 61.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 102.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > Firstly, yes that comment isn't too helpful .. power_profile only acts > > > > (so far) when you apply or remove AC power, using the following values > > > > from /etc/defaults/rc.conf unless you've set them otherwise: > > > > > > > > performance_cx_lowest="HIGH" # Online CPU idle state > > > > performance_cpu_freq="HIGH" # Online CPU frequency > > > > economy_cx_lowest="HIGH" # Offline CPU idle state > > > > economy_cpu_freq="HIGH" # Offline CPU frequency Our /etc/defaults/rc.conf performance_cx_lowest="HIGH" # Online CPU idle state performance_cpu_freq="NONE" # Online CPU frequency economy_cx_lowest="HIGH" # Offline CPU idle state economy_cpu_freq="NONE" # Offline CPU frequency > > > > If you have a look at /etc/rc.d/power_profile you'll see that these are > > > > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > > > > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > > > > variables to HIGH, LOW, a specific value, or NONE. Attempting to: --> sysctl hw.acpi.cpu.cx_supported sysctl: unknown oid 'hw.acpi.cpu.cx_supported' Attempting to: --> sysctl hw.acpi.cpu hw.acpi.cpu.cx_lowest: C1 Above, where is "hw.acpi.cpu.cx_supported"? Did FreeBSD 'not' probe something? Attempting to: --> sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2201/35000 2200/35000 1925/30625 1650/26250 1600/23000 1400/20125 1200/16000 1050/14000 900/12000 800/14300 700/12512 600/10725 500/8937 400/7150 300/5362 200/3575 100/1787 Following is grepped from /var/run/dmesg.boot: CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.54-MHz 686-class CPU) cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 > > > > Specify "NONE" to have power_profile make no changes. "C3" or at least > > > > "C2" can be useful CX values, in some machines helping with temperature. > > > > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > > > > a problem - again, watch powerd -v output - and I guess you'll rarely > > > > run on battery (you've got a nice 2-3 hour UPS, though :) > Our /etc/rc.conf performance_cx_lowest="C4" # Online CPU idle state #performance_cpu_freq="HIGH" # Online CPU frequency economy_cx_lowest="C5" # Offline CPU idle state #economy_cpu_freq="HIGH" # Offline CPU frequency This machine can afford to go to C4 and C5 unless needed otherwise. I'll try anything to lowwer this machines temp. > > > This is another issue in addition to the heat. As you say, this battery > > > should last any where from 2-3 hours, however as it is now; > > > out-of-the-box so to speak, this machine will only stay powered up > > > approximately 1-hour on using the oem battery. > > > > That's because it runs at (presumably) its maximum frequency all of the > > time; you're lucky to get an hour at that rate, and yes it'll run hot :) > > > > 'sysctl dev.cpu.0.freq hw.acpi.thermal.tz0.temperature' now and again. These numbers have not changed (lowwer) prior to or during this thread. Attempting to: --> sysctl dev.cpu.0.freq dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature hw.acpi.thermal.tz0.temperature: 61.0C > > > > This machine has never run this hot, prior to running 'powerd'-- or run > > > > > this warm, while idling with 'powerd' in comparison to running under windows > > > > > --not trying to start and OS confilict here, trying to learn, understand > > > > > and control this beast of a machine if possible. > > > > > > > > Of course, and it's likely doable, though you might need to run 7-STABLE > > > > for the latest dual-core ACPI handling. Let's see how we go with some > > > > real information, before suggesting taking this to freebsd-acpi@. I > > > > don't see where you've mentioned what version of FreeBSD it's running? > > > > > > I believe I did so at the outset of this thread. In any case dmesg has > > > now provided that information. > > > > ok, 6.3-R-p3. Frankly I've no idea whether your dual-core Toshiba is or > > is not subject to any of the dual-core issues solved or being actively > > worked on in freebsd-acpi and being applied mostly or at least firstly > > back into 7-STABLE. I'd suggest browsing the -acpi archives for the > > last few months, it's not that big .. that is, if using the GENERIC > > kernel and running powerd doesn't improve matters sufficiently. > > > > cheers, Ian > > > From morganw at chemikals.org Sun Aug 31 10:55:11 2008 From: morganw at chemikals.org (Wes Morgan) Date: Sun Aug 31 10:55:17 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support In-Reply-To: <20080830210736.GA4521@WORKSTATION.guice.ath.cx> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> <20080825191804.GA6846@WORKSTATION.guice.ath.cx> <20080826182124.O14827@sola.nimnet.asn.au> <20080830210736.GA4521@WORKSTATION.guice.ath.cx> Message-ID: On Sat, 30 Aug 2008, freebsd_user@guice.ath.cx wrote: > On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx wrote: > FROM THE LAST MESSAGE ... >> > Attempting to: --> sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. > Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature > hw.acpi.thermal.tz0.temperature: 61.0C 61C? My laptop is routinely that temperature or higher, even in XP. A laptop is going to be much hotter than a desktop. From smithi at nimnet.asn.au Sun Aug 31 16:45:58 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Aug 31 16:46:11 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support (fwd) Message-ID: <20080901020747.A1667@sola.nimnet.asn.au> Ok, I think we've finally obtained enough info to pin this issue down. I'm going to just forward your message to freebsd-acpi@ because your symptoms (two cpu frequencies only 1 unit apart (one bogus), powerd therefore not shifting to a real lower frequency, so running flat out all the time) came up there several times this year on some machines. While I can't recall the details, nor have access to my own archives currently, I'm pretty sure there was a patch - not sure if it covers or can be applied to 6.3 though. You could browse the -acpi archives for this, but hopefully someone will show mercy and provide a pointer or two, if not directly help out? As Wes since mentioned, 61C isn't hot at all (at that frequency anyway) but still it'd be better to get the mangled cpu freqs sorted out so that powerd can do its thing properly. [FWIW, I'm the OP in this ongoing conversation on -mobile below .. sorry I didn't pay a bit more attention back when this was a 'hot issue' ..] cheers, Ian ---------- Forwarded message ---------- Date: Sat, 30 Aug 2008 17:07:36 -0400 From: freebsd_user@guice.ath.cx To: freebsd-mobile@freebsd.org Cc: Ian Smith Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx wrote: FROM THE LAST MESSAGE ... > > > > > However we need some empirical data about what it's doing. Showing your > > > > /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > > > > > > > Initially we didn't provide that data until someone asked for it to be sure that is > > > in fact what was needed or if the was some other incorrect setting. > > > > > > /var/run/dmesg.boot ... > > > > I'm trimming this down to the likely relevant ACPI stuff .. > > > > > Copyright (c) 1992-2008 The FreeBSD Project. > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > The Regents of the University of California. All rights reserved. > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > FreeBSD 6.3-RELEASE-p3 #1: Mon Aug 4 23:37:02 EDT 2008 > > > root@WORKSTATION.ath.cx:/usr/obj/usr/src/sys/WORKSTATION > > > ACPI APIC Table: > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) > > > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > > Features=0xbfebfbff > > > Features2=0xe3bd > > > AMD Features=0x20100000 > > > AMD Features2=0x1 > > > Cores per package: 2 > > > real memory = 2113142784 (2015 MB) > > > avail memory = 2058563584 (1963 MB) > > > ioapic0: Changing APIC ID to 1 > > > ioapic0 irqs 0-23 on motherboard > > [..] > > > acpi0: on motherboard > > > acpi0: Power Button (fixed) > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > cpu0: on acpi0 > > [..] > > > acpi_lid0: on acpi0 > > > battery0: on acpi0 > > > acpi_button0: on acpi0 > > > acpi_acad0: on acpi0 > > > acpi_tz0: on acpi0 > > [..] > > > > No cpufreq driver/s. cpufreq removed from your custom kernel? So no > > CPU frequency control. So, powerd is rendered powerless .. > > > 'powerd' is now operational: idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M ^Ctotal joules used: 41737.500^M > > Try booting with the GENERIC kernel, you should see one or two of the > > supported drivers listed in cpufreq(4) loaded in dmesg.boot. Then see > > if powerd isn't doing the right thing (w/ powerd -v as discussed below) > > > This has always been the /GENERIC kernel copied to a custome name. This was a 6.0-RELEASE UPGRADED TO -p3. Apparently cpufreq wasn't considered as a default entry in the /GENERIC. > > > > > sysctl hw.acpi ... > > > > > > hw.acpi.supported_sleep_state: S3 S4 S5 > > > hw.acpi.power_button_state: S5 > > > hw.acpi.sleep_button_state: S3 > > > hw.acpi.lid_switch_state: NONE > > > hw.acpi.standby_state: S1 > > > hw.acpi.suspend_state: S3 > > > hw.acpi.sleep_delay: 1 > > > hw.acpi.s4bios: 0 > > > hw.acpi.verbose: 0 > > > hw.acpi.disable_on_reboot: 0 > > > hw.acpi.handle_reboot: 0 > > > hw.acpi.reset_video: 0 > > > hw.acpi.cpu.cx_lowest: C1 > > > hw.acpi.battery.life: 100 > > > hw.acpi.battery.time: -1 > > > hw.acpi.battery.state: 0 > > > hw.acpi.battery.units: 1 > > > hw.acpi.battery.info_expire: 5 > > > hw.acpi.acline: 1 > > > hw.acpi.thermal.min_runtime: 0 > > > hw.acpi.thermal.polling_rate: 10 > > > hw.acpi.thermal.user_override: 0 > > > hw.acpi.thermal.tz0.temperature: 63.0C > > > hw.acpi.thermal.tz0.active: -1 > > > hw.acpi.thermal.tz0.passive_cooling: 0 > > > hw.acpi.thermal.tz0.thermal_flags: 0 > > > hw.acpi.thermal.tz0._PSV: -1 > > > hw.acpi.thermal.tz0._HOT: -1 > > > hw.acpi.thermal.tz0._CRT: 102.0C > > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > No passive cooling. See acpi_thermal(4) .. you may want to set some > > overrides .. but it might all just work with the GENERIC kernel anyway. > Attempting to: --> sysctl hw.acpi.thermal.user_override hw.acpi.thermal.user_override: 0 Attempting to: --> sysctl hw.acpi.thermal.user_override=1 hw.acpi.thermal.user_override: 0 -> 1 Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling hw.acpi.thermal.tz0.passive_cooling: 0 Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling=1 hw.acpi.thermal.tz0.passive_cooling: 0 sysctl: hw.acpi.thermal.tz0.passive_cooling: Operation not supported by device NOTE: While we are able to change the threshold for: hw.acpi.thermal.tz0._PSV: -1, we don't see the need to do so because the above passive_cooling is not enabled. Well, so much for passive_cooling. :=\ > > Also, have you set anything in BIOS regarding power usage, speedstep or > > any other settings that might get reflected into your boot ACPI setup? Initially we left the BIOS power settings the way the OEM set them (Vista). We are able to choose from one of Dynamic, High or low not much else to play with in the way of power settings (ACPI) with the exception of LCD and/or letting the OS control devices. Unable to directly set CPU steppings/freq settings within this BIOS. > > And, are you loading acpi_toshiba(4)? Not sure if it would help with > > this, but may at least provide some useful info in its sysctls .. > > > This is an issue revisited; take a deep breath. Better yet, here's the short version, in the kernel 'device acpi_toshiba' does not work for us on this machine unless we neglected to make an accompanying needed acpi entry. Aa we understand it, we were to only add 'device acpi_toshiba' to load the neccessary acpi toshiba extras. Using 'acpi_toshiba_load="YES"' in the /boot/loader.conf -and- using 'kldload acpi_toshiba' from the cli works like a charm but has no positive affect on the current discussion (heat). > > > > Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop > > > > (if it's running) then run 'powerd -v' which runs in foreground and says > > > > exactly what it's doing re shifting CPU frequency under various loads. idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M ^Ctotal joules used: 41737.500 > > > > > > > > It's also useful to watch the temperature(s) directly over the time, see > > > > acpi_thermal(4) and try logging those sysctls periodically in a script. The following data is the result of the concerns I have; running too hot. These figures are the lowest temperatures this machine idles while FreeBSD is installed and running. The temperatures shown herein only rise with use but never go lower than what we're showing here when the laptop returns to idle. Attempting to: --> sysctl hw.acpi.thermal.tz0. hw.acpi.thermal.tz0.temperature: 61.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 102.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > Firstly, yes that comment isn't too helpful .. power_profile only acts > > > > (so far) when you apply or remove AC power, using the following values > > > > from /etc/defaults/rc.conf unless you've set them otherwise: > > > > > > > > performance_cx_lowest="HIGH" # Online CPU idle state > > > > performance_cpu_freq="HIGH" # Online CPU frequency > > > > economy_cx_lowest="HIGH" # Offline CPU idle state > > > > economy_cpu_freq="HIGH" # Offline CPU frequency Our /etc/defaults/rc.conf performance_cx_lowest="HIGH" # Online CPU idle state performance_cpu_freq="NONE" # Online CPU frequency economy_cx_lowest="HIGH" # Offline CPU idle state economy_cpu_freq="NONE" # Offline CPU frequency > > > > If you have a look at /etc/rc.d/power_profile you'll see that these are > > > > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > > > > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > > > > variables to HIGH, LOW, a specific value, or NONE. Attempting to: --> sysctl hw.acpi.cpu.cx_supported sysctl: unknown oid 'hw.acpi.cpu.cx_supported' Attempting to: --> sysctl hw.acpi.cpu hw.acpi.cpu.cx_lowest: C1 Above, where is "hw.acpi.cpu.cx_supported"? Did FreeBSD 'not' probe something? Attempting to: --> sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2201/35000 2200/35000 1925/30625 1650/26250 1600/23000 1400/20125 1200/16000 1050/14000 900/12000 800/14300 700/12512 600/10725 500/8937 400/7150 300/5362 200/3575 100/1787 Following is grepped from /var/run/dmesg.boot: CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.54-MHz 686-class CPU) cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 > > > > Specify "NONE" to have power_profile make no changes. "C3" or at least > > > > "C2" can be useful CX values, in some machines helping with temperature. > > > > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > > > > a problem - again, watch powerd -v output - and I guess you'll rarely > > > > run on battery (you've got a nice 2-3 hour UPS, though :) > Our /etc/rc.conf performance_cx_lowest="C4" # Online CPU idle state #performance_cpu_freq="HIGH" # Online CPU frequency economy_cx_lowest="C5" # Offline CPU idle state #economy_cpu_freq="HIGH" # Offline CPU frequency This machine can afford to go to C4 and C5 unless needed otherwise. I'll try anything to lowwer this machines temp. > > > This is another issue in addition to the heat. As you say, this battery > > > should last any where from 2-3 hours, however as it is now; > > > out-of-the-box so to speak, this machine will only stay powered up > > > approximately 1-hour on using the oem battery. > > > > That's because it runs at (presumably) its maximum frequency all of the > > time; you're lucky to get an hour at that rate, and yes it'll run hot :) > > > > 'sysctl dev.cpu.0.freq hw.acpi.thermal.tz0.temperature' now and again. These numbers have not changed (lowwer) prior to or during this thread. Attempting to: --> sysctl dev.cpu.0.freq dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature hw.acpi.thermal.tz0.temperature: 61.0C > > > > This machine has never run this hot, prior to running 'powerd'-- or run > > > > > this warm, while idling with 'powerd' in comparison to running under windows > > > > > --not trying to start and OS confilict here, trying to learn, understand > > > > > and control this beast of a machine if possible. > > > > > > > > Of course, and it's likely doable, though you might need to run 7-STABLE > > > > for the latest dual-core ACPI handling. Let's see how we go with some > > > > real information, before suggesting taking this to freebsd-acpi@. I > > > > don't see where you've mentioned what version of FreeBSD it's running? > > > > > > I believe I did so at the outset of this thread. In any case dmesg has > > > now provided that information. > > > > ok, 6.3-R-p3. Frankly I've no idea whether your dual-core Toshiba is or > > is not subject to any of the dual-core issues solved or being actively > > worked on in freebsd-acpi and being applied mostly or at least firstly > > back into 7-STABLE. I'd suggest browsing the -acpi archives for the > > last few months, it's not that big .. that is, if using the GENERIC > > kernel and running powerd doesn't improve matters sufficiently. > > > > cheers, Ian From freebsd_user at guice.ath.cx Sun Aug 31 18:26:14 2008 From: freebsd_user at guice.ath.cx (freebsd_user@guice.ath.cx) Date: Sun Aug 31 18:26:21 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support In-Reply-To: References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> <20080825191804.GA6846@WORKSTATION.guice.ath.cx> <20080826182124.O14827@sola.nimnet.asn.au> <20080830210736.GA4521@WORKSTATION.guice.ath.cx> Message-ID: <20080831182522.GA2191@WORKSTATION.guice.ath.cx> On Sun, Aug 31, 2008 at 05:55:05AM -0500, Wes Morgan wrote: > On Sat, 30 Aug 2008, freebsd_user@guice.ath.cx wrote: > > >On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx > >wrote: > > FROM THE LAST MESSAGE ... > >> > >Attempting to: --> sysctl dev.cpu.0.freq > >dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. > >Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature > >hw.acpi.thermal.tz0.temperature: 61.0C > > 61C? My laptop is routinely that temperature or higher, even in XP. A > laptop is going to be much hotter than a desktop. While I am inclined to agree with you on that specific temperature issue, 61.0C not that hot, our concern is that the temp is 61.0C while doing absolutly nothing (idling), for hours on end. We have come upon some new data/findings which we're sorting out and will be responding to and/or addressing in the next msg to this thread. > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" From freebsd_user at guice.ath.cx Sun Aug 31 20:30:29 2008 From: freebsd_user at guice.ath.cx (freebsd_user@guice.ath.cx) Date: Sun Aug 31 20:30:36 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support In-Reply-To: <20080901020747.A1667@sola.nimnet.asn.au> References: <20080901020747.A1667@sola.nimnet.asn.au> Message-ID: <20080831202938.GB2191@WORKSTATION.guice.ath.cx> On Mon, Sep 01, 2008 at 02:45:44AM +1000, Ian Smith wrote: > Ok, I think we've finally obtained enough info to pin this issue down. > > I'm going to just forward your message to freebsd-acpi@ because your > symptoms (two cpu frequencies only 1 unit apart (one bogus), powerd > therefore not shifting to a real lower frequency, so running flat out > all the time) came up there several times this year on some machines. > > While I can't recall the details, nor have access to my own archives > currently, I'm pretty sure there was a patch - not sure if it covers or > can be applied to 6.3 though. I was recently introduced to this URL: http://lists.freebsd.org/pipermail/cvs-src/2007-August/081246.html. > > You could browse the -acpi archives for this, but hopefully someone will > show mercy and provide a pointer or two, if not directly help out? > > As Wes since mentioned, 61C isn't hot at all (at that frequency anyway) > but still it'd be better to get the mangled cpu freqs sorted out so that > powerd can do its thing properly. In addition to the above URL, other findings: hw.acpi.toshiba.cpu_speed=7 hw.acpi.toshiba.force_fan=1 hw.acpi.thermal.min_runtime=30 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override=1 hw.acpi.thermal.tz0.temperature: 61.0C # On 6.3-RELEASE -p3 - # this value is bogus hw.acpi.thermal.tz0.active: -1 # Can not change hw.acpi.thermal.tz0.passive_cooling: 0 # Can not change hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV=10.0C # passive_cooling will- # activate @ this temp. # Above, passive_cooling # currently N/A. Since Sat Aug 30 06:20:00 EDT 2008, with the above sysctl variables set, we have logged the following results at 20-min intervals: Sat Aug 30 21:20:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 2201 hw.acpi.thermal.tz0.temperature: 61.0C The frquencies during the above time frame have not gone above 2201 and not fallen below 2200. During which time the hw.acpi.thermal.tz0.temperature: 61.0C has remained static. Moving forward ... It has been suggested that we try the following: Attempting to: --> sysctl dev.cpu.0.freq=900 dev.cpu.0.freq: 2201 -> 900 Here in lies 'a' rub, so to speak; after setting the above dev.cpu.0.freq: 2201 -> 900, the machine appeared to be running cooler --as in placing a finger near the output of the fan, the machine wasn't breathing fire. However, the reading of hw.acpi.thermal.tz0.temperature: 61.0C remained the same --how could this be? Sat Aug 30 21:40:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C - Sat Aug 30 23:40:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C If you'll notice the time stamps, I've allowed time for the temperatures both actual and ambient to adjust, yet hw.acpi.thermal.tz0.temperature: 61.0C remains constant. Another suggestion/recommendation, 'kldload coretemp', no 'man page' within 6.3. After doing so, we began to log the following data: ... Notice and compare the time stamp(s)... Sun Aug 31 00:00:01 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C - Sun Aug 31 00:40:01 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C hw.acpi.thermal.tz0.temperature: 61.0C <--> remains unchanged. Here's the entry to drive my point home: Sun Aug 31 01:00:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C dev.cpu.0.temperature: 44 - Sun Aug 31 01:20:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko Sun Aug 31 01:20:00 EDT 2008 -- dev.cpu.0.freq: 900 Sun Aug 31 01:20:00 EDT 2008 -- hw.acpi.thermal.tz0.temperature: 61.0C Sun Aug 31 01:20:00 EDT 2008 -- dev.cpu.0.temperature: 45 - Sun Aug 31 15:40:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko Sun Aug 31 15:40:00 EDT 2008 -- dev.cpu.0.freq: 900 Sun Aug 31 15:40:00 EDT 2008 -- hw.acpi.thermal.tz0.temperature: 61.0C Sun Aug 31 15:40:00 EDT 2008 -- dev.cpu.0.temperature: 44 It is now thought, to say the least, that hw.acpi.thermal.tz0.temperature: 61.0C are not correct in comparison to the output of dev.cpu.0.temperature: 45. If I hadn't of experienced this back in 3.x to 4.x I may have dismissed it as a first time occurrance, but this heat issue has now haunted me using i386 AMD on a Tiger MPX as well as the TECRA_A9-S9017 laptops. Now we find out that there are numerous issues causing this, powerd, incorrect temp/sensor readings and perhaps an OEM ACPI implementation issue. With that being said, please allow me this one (1) rhetorical question; how is a common end-user supposed to keep his machine running and maintain her/his sanity chasing after issues such as we've discussed here? I'd like to extend my continued thanks to: FreeBSD-mobile FreeBSD-questions FreeBSDhelp @ EFnet > > [FWIW, I'm the OP in this ongoing conversation on -mobile below .. sorry > I didn't pay a bit more attention back when this was a 'hot issue' ..] > > cheers, Ian > > ---------- Forwarded message ---------- > Date: Sat, 30 Aug 2008 17:07:36 -0400 > From: freebsd_user@guice.ath.cx > To: freebsd-mobile@freebsd.org > Cc: Ian Smith > Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support > > On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx wrote: > FROM THE LAST MESSAGE ... > > > > > > > However we need some empirical data about what it's doing. Showing your > > > > > /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > > > > > > > > > Initially we didn't provide that data until someone asked for it to be sure that is > > > > in fact what was needed or if the was some other incorrect setting. > > > > > > > > /var/run/dmesg.boot ... > > > > > > I'm trimming this down to the likely relevant ACPI stuff .. > > > > > > > Copyright (c) 1992-2008 The FreeBSD Project. > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > > The Regents of the University of California. All rights reserved. > > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > > FreeBSD 6.3-RELEASE-p3 #1: Mon Aug 4 23:37:02 EDT 2008 > > > > root@WORKSTATION.ath.cx:/usr/obj/usr/src/sys/WORKSTATION > > > > ACPI APIC Table: > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) > > > > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > > > Features=0xbfebfbff > > > > Features2=0xe3bd > > > > AMD Features=0x20100000 > > > > AMD Features2=0x1 > > > > Cores per package: 2 > > > > real memory = 2113142784 (2015 MB) > > > > avail memory = 2058563584 (1963 MB) > > > > ioapic0: Changing APIC ID to 1 > > > > ioapic0 irqs 0-23 on motherboard > > > [..] > > > > acpi0: on motherboard > > > > acpi0: Power Button (fixed) > > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 > > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > > cpu0: on acpi0 > > > [..] > > > > acpi_lid0: on acpi0 > > > > battery0: on acpi0 > > > > acpi_button0: on acpi0 > > > > acpi_acad0: on acpi0 > > > > acpi_tz0: on acpi0 > > > [..] > > > > > > No cpufreq driver/s. cpufreq removed from your custom kernel? So no > > > CPU frequency control. So, powerd is rendered powerless .. > > > > > > 'powerd' is now operational: > > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > ^Ctotal joules used: 41737.500^M > > > > Try booting with the GENERIC kernel, you should see one or two of the > > > supported drivers listed in cpufreq(4) loaded in dmesg.boot. Then see > > > if powerd isn't doing the right thing (w/ powerd -v as discussed below) > > > > > > This has always been the /GENERIC kernel copied to a custome name. > This was a 6.0-RELEASE UPGRADED TO -p3. Apparently cpufreq wasn't > considered as a default entry in the /GENERIC. > > > > > > > > sysctl hw.acpi ... > > > > > > > > hw.acpi.supported_sleep_state: S3 S4 S5 > > > > hw.acpi.power_button_state: S5 > > > > hw.acpi.sleep_button_state: S3 > > > > hw.acpi.lid_switch_state: NONE > > > > hw.acpi.standby_state: S1 > > > > hw.acpi.suspend_state: S3 > > > > hw.acpi.sleep_delay: 1 > > > > hw.acpi.s4bios: 0 > > > > hw.acpi.verbose: 0 > > > > hw.acpi.disable_on_reboot: 0 > > > > hw.acpi.handle_reboot: 0 > > > > hw.acpi.reset_video: 0 > > > > hw.acpi.cpu.cx_lowest: C1 > > > > hw.acpi.battery.life: 100 > > > > hw.acpi.battery.time: -1 > > > > hw.acpi.battery.state: 0 > > > > hw.acpi.battery.units: 1 > > > > hw.acpi.battery.info_expire: 5 > > > > hw.acpi.acline: 1 > > > > hw.acpi.thermal.min_runtime: 0 > > > > hw.acpi.thermal.polling_rate: 10 > > > > hw.acpi.thermal.user_override: 0 > > > > hw.acpi.thermal.tz0.temperature: 63.0C > > > > hw.acpi.thermal.tz0.active: -1 > > > > hw.acpi.thermal.tz0.passive_cooling: 0 > > > > hw.acpi.thermal.tz0.thermal_flags: 0 > > > > hw.acpi.thermal.tz0._PSV: -1 > > > > hw.acpi.thermal.tz0._HOT: -1 > > > > hw.acpi.thermal.tz0._CRT: 102.0C > > > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > > > No passive cooling. See acpi_thermal(4) .. you may want to set some > > > overrides .. but it might all just work with the GENERIC kernel anyway. > > > Attempting to: --> sysctl hw.acpi.thermal.user_override > hw.acpi.thermal.user_override: 0 > Attempting to: --> sysctl hw.acpi.thermal.user_override=1 > hw.acpi.thermal.user_override: 0 -> 1 > > Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling > hw.acpi.thermal.tz0.passive_cooling: 0 > Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling=1 > hw.acpi.thermal.tz0.passive_cooling: 0 > sysctl: hw.acpi.thermal.tz0.passive_cooling: Operation not supported > by device > > NOTE: While we are able to change the threshold for: > hw.acpi.thermal.tz0._PSV: -1, we don't see the need to do so because > the above passive_cooling is not enabled. > > Well, so much for passive_cooling. :=\ > > > > Also, have you set anything in BIOS regarding power usage, speedstep or > > > any other settings that might get reflected into your boot ACPI setup? > > Initially we left the BIOS power settings the way the OEM set them > (Vista). We are able to choose from one of Dynamic, High or low > not much else to play with in the way of power settings (ACPI) > with the exception of LCD and/or letting the OS control devices. > Unable to directly set CPU steppings/freq settings within this BIOS. > > > > > And, are you loading acpi_toshiba(4)? Not sure if it would help with > > > this, but may at least provide some useful info in its sysctls .. > > > > > > This is an issue revisited; take a deep breath. Better yet, here's > the short version, in the kernel 'device acpi_toshiba' does not work > for us on this machine unless we neglected to make an accompanying > needed acpi entry. Aa we understand it, we were to only add 'device > acpi_toshiba' to load the neccessary acpi toshiba extras. > > Using 'acpi_toshiba_load="YES"' in the /boot/loader.conf -and- using > 'kldload acpi_toshiba' from the cli works like a charm but has no > positive affect on the current discussion (heat). > > > > > > Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop > > > > > (if it's running) then run 'powerd -v' which runs in foreground and says > > > > > exactly what it's doing re shifting CPU frequency under various loads. > > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > ^Ctotal joules used: 41737.500 > > > > > > > > > > > It's also useful to watch the temperature(s) directly over the time, see > > > > > acpi_thermal(4) and try logging those sysctls periodically in a script. > > The following data is the result of the concerns I have; running too > hot. These figures are the lowest temperatures this machine idles > while FreeBSD is installed and running. The temperatures shown > herein only rise with use but never go lower than what we're showing > here when the laptop returns to idle. > > Attempting to: --> sysctl hw.acpi.thermal.tz0. > hw.acpi.thermal.tz0.temperature: 61.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 102.0C > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > > > Firstly, yes that comment isn't too helpful .. power_profile only acts > > > > > (so far) when you apply or remove AC power, using the following values > > > > > from /etc/defaults/rc.conf unless you've set them otherwise: > > > > > > > > > > performance_cx_lowest="HIGH" # Online CPU idle state > > > > > performance_cpu_freq="HIGH" # Online CPU frequency > > > > > economy_cx_lowest="HIGH" # Offline CPU idle state > > > > > economy_cpu_freq="HIGH" # Offline CPU frequency > > Our /etc/defaults/rc.conf > > performance_cx_lowest="HIGH" # Online CPU idle state > performance_cpu_freq="NONE" # Online CPU frequency > economy_cx_lowest="HIGH" # Offline CPU idle state > economy_cpu_freq="NONE" # Offline CPU frequency > > > > > > If you have a look at /etc/rc.d/power_profile you'll see that these are > > > > > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > > > > > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > > > > > variables to HIGH, LOW, a specific value, or NONE. > > Attempting to: --> sysctl hw.acpi.cpu.cx_supported > sysctl: unknown oid 'hw.acpi.cpu.cx_supported' > Attempting to: --> sysctl hw.acpi.cpu > hw.acpi.cpu.cx_lowest: C1 > > Above, where is "hw.acpi.cpu.cx_supported"? Did FreeBSD 'not' > probe something? > > Attempting to: --> sysctl dev.cpu.0.freq_levels > dev.cpu.0.freq_levels: 2201/35000 2200/35000 1925/30625 1650/26250 > 1600/23000 1400/20125 1200/16000 1050/14000 900/12000 800/14300 > 700/12512 600/10725 500/8937 400/7150 300/5362 200/3575 100/1787 > > Following is grepped from /var/run/dmesg.boot: > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.54-MHz > 686-class CPU) > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > > > > > > Specify "NONE" to have power_profile make no changes. "C3" or at least > > > > > "C2" can be useful CX values, in some machines helping with temperature. > > > > > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > > > > > a problem - again, watch powerd -v output - and I guess you'll rarely > > > > > run on battery (you've got a nice 2-3 hour UPS, though :) > > > Our /etc/rc.conf > > performance_cx_lowest="C4" # Online CPU idle state > #performance_cpu_freq="HIGH" # Online CPU frequency > economy_cx_lowest="C5" # Offline CPU idle state > #economy_cpu_freq="HIGH" # Offline CPU frequency > > This machine can afford to go to C4 and C5 unless needed otherwise. > I'll try anything to lowwer this machines temp. > > > > > This is another issue in addition to the heat. As you say, this battery > > > > should last any where from 2-3 hours, however as it is now; > > > > out-of-the-box so to speak, this machine will only stay powered up > > > > approximately 1-hour on using the oem battery. > > > > > > That's because it runs at (presumably) its maximum frequency all of the > > > time; you're lucky to get an hour at that rate, and yes it'll run hot :) > > > > > > 'sysctl dev.cpu.0.freq hw.acpi.thermal.tz0.temperature' now and again. > > These numbers have not changed (lowwer) prior to or during this thread. > > Attempting to: --> sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. > Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature > hw.acpi.thermal.tz0.temperature: 61.0C > > > > > > This machine has never run this hot, prior to running 'powerd'-- or run > > > > > > this warm, while idling with 'powerd' in comparison to running under windows > > > > > > --not trying to start and OS confilict here, trying to learn, understand > > > > > > and control this beast of a machine if possible. > > > > > > > > > > Of course, and it's likely doable, though you might need to run 7-STABLE > > > > > for the latest dual-core ACPI handling. Let's see how we go with some > > > > > real information, before suggesting taking this to freebsd-acpi@. I > > > > > don't see where you've mentioned what version of FreeBSD it's running? > > > > > > > > I believe I did so at the outset of this thread. In any case dmesg has > > > > now provided that information. > > > > > > ok, 6.3-R-p3. Frankly I've no idea whether your dual-core Toshiba is or > > > is not subject to any of the dual-core issues solved or being actively > > > worked on in freebsd-acpi and being applied mostly or at least firstly > > > back into 7-STABLE. I'd suggest browsing the -acpi archives for the > > > last few months, it's not that big .. that is, if using the GENERIC > > > kernel and running powerd doesn't improve matters sufficiently. > > > > > > cheers, Ian > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" From bh at izb.knu.ac.kr Sun Aug 31 20:55:58 2008 From: bh at izb.knu.ac.kr (Byung-Hee HWANG) Date: Sun Aug 31 20:56:04 2008 Subject: Anycall SPH-B8250 Message-ID: <1220216154.4029.2.camel@phyll.izb.knu.ac.kr> Recently i'm interested in a mobile data synchronization with desktop (Windows XP). Especially, i'm using Anycall SPH-B8250 released in 2007-12-21 from SAMSUNG. Q: Is there anyone to use things like this on FreeBSD? Or can you please give me other related information? byunghee -- "Do what you want." -- Vito Corleone, "Chapter 1", page 37 From freebsd_user at guice.ath.cx Sun Aug 31 22:38:11 2008 From: freebsd_user at guice.ath.cx (freebsd_user@guice.ath.cx) Date: Sun Aug 31 22:38:18 2008 Subject: TECRA A9-S9017 -- Idles too hot -- Hardware Support In-Reply-To: <20080830210736.GA4521@WORKSTATION.guice.ath.cx> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> <20080825191804.GA6846@WORKSTATION.guice.ath.cx> <20080826182124.O14827@sola.nimnet.asn.au> <20080830210736.GA4521@WORKSTATION.guice.ath.cx> Message-ID: <20080831223722.GC2191@WORKSTATION.guice.ath.cx> In an effort to keep this thread *as a thread*, it appears to have branched off in to a totally different entity due to edits to the subject, I'm duplicating this message as part of this original thread to better help other with the same issue and/or machine keep up with what has taken place with this TECRA_A9-S9017. Errors-To: owner-freebsd-mobile@freebsd.org On Mon, Sep 01, 2008 at 02:45:44AM +1000, Ian Smith wrote: > Ok, I think we've finally obtained enough info to pin this issue down. > > I'm going to just forward your message to freebsd-acpi@ because your > symptoms (two cpu frequencies only 1 unit apart (one bogus), powerd > therefore not shifting to a real lower frequency, so running flat out > all the time) came up there several times this year on some machines. > > While I can't recall the details, nor have access to my own archives > currently, I'm pretty sure there was a patch - not sure if it covers or > can be applied to 6.3 though. I was recently introduced to this URL: http://lists.freebsd.org/pipermail/cvs-src/2007-August/081246.html. > > You could browse the -acpi archives for this, but hopefully someone will > show mercy and provide a pointer or two, if not directly help out? > > As Wes since mentioned, 61C isn't hot at all (at that frequency anyway) > but still it'd be better to get the mangled cpu freqs sorted out so that > powerd can do its thing properly. In addition to the above URL, other findings: hw.acpi.toshiba.cpu_speed=7 hw.acpi.toshiba.force_fan=1 hw.acpi.thermal.min_runtime=30 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override=1 hw.acpi.thermal.tz0.temperature: 61.0C # On 6.3-RELEASE -p3 - # this value is bogus hw.acpi.thermal.tz0.active: -1 # Can not change hw.acpi.thermal.tz0.passive_cooling: 0 # Can not change hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV=10.0C # passive_cooling will- # activate @ this temp. # Above, passive_cooling # currently N/A. Since Sat Aug 30 06:20:00 EDT 2008, with the above sysctl variables set, we have logged the following results at 20-min intervals: Sat Aug 30 21:20:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 2201 hw.acpi.thermal.tz0.temperature: 61.0C The frquencies during the above time frame have not gone above 2201 and not fallen below 2200. During which time the hw.acpi.thermal.tz0.temperature: 61.0C has remained static. Moving forward ... It has been suggested that we try the following: Attempting to: --> sysctl dev.cpu.0.freq=900 dev.cpu.0.freq: 2201 -> 900 Here in lies 'a' rub, so to speak; after setting the above dev.cpu.0.freq: 2201 -> 900, the machine appeared to be running cooler --as in placing a finger near the output of the fan, the machine wasn't breathing fire. However, the reading of hw.acpi.thermal.tz0.temperature: 61.0C remained the same --how could this be? Sat Aug 30 21:40:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C - Sat Aug 30 23:40:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C If you'll notice the time stamps, I've allowed time for the temperatures both actual and ambient to adjust, yet hw.acpi.thermal.tz0.temperature: 61.0C remains constant. Another suggestion/recommendation, 'kldload coretemp', no 'man page' within 6.3. After doing so, we began to log the following data: ... Notice and compare the time stamp(s)... Sun Aug 31 00:00:01 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C - Sun Aug 31 00:40:01 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C hw.acpi.thermal.tz0.temperature: 61.0C <--> remains unchanged. Here's the entry to drive my point home: Sun Aug 31 01:00:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C dev.cpu.0.temperature: 44 - Sun Aug 31 01:20:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko Sun Aug 31 01:20:00 EDT 2008 -- dev.cpu.0.freq: 900 Sun Aug 31 01:20:00 EDT 2008 -- hw.acpi.thermal.tz0.temperature: 61.0C Sun Aug 31 01:20:00 EDT 2008 -- dev.cpu.0.temperature: 45 - Sun Aug 31 15:40:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko Sun Aug 31 15:40:00 EDT 2008 -- dev.cpu.0.freq: 900 Sun Aug 31 15:40:00 EDT 2008 -- hw.acpi.thermal.tz0.temperature: 61.0C Sun Aug 31 15:40:00 EDT 2008 -- dev.cpu.0.temperature: 44 It is now thought, to say the least, that hw.acpi.thermal.tz0.temperature: 61.0C are not correct in comparison to the output of dev.cpu.0.temperature: 45. If I hadn't of experienced this back in 3.x to 4.x I may have dismissed it as a first time occurrance, but this heat issue has now haunted me using i386 AMD on a Tiger MPX as well as the TECRA_A9-S9017 laptops. Now we find out that there are numerous issues causing this, powerd, incorrect temp/sensor readings and perhaps an OEM ACPI implementation issue. With that being said, please allow me this one (1) rhetorical question; how is a common end-user supposed to keep his machine running and maintain her/his sanity chasing after issues such as we've discussed here? I'd like to extend my continued thanks to: FreeBSD-mobile FreeBSD-questions FreeBSDhelp @ EFnet > > [FWIW, I'm the OP in this ongoing conversation on -mobile below .. sorry > I didn't pay a bit more attention back when this was a 'hot issue' ..] > > cheers, Ian > > ---------- Forwarded message ---------- > Date: Sat, 30 Aug 2008 17:07:36 -0400 > From: freebsd_user@guice.ath.cx > To: freebsd-mobile@freebsd.org > Cc: Ian Smith > Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support > > On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx wrote: > FROM THE LAST MESSAGE ... > > > > > > > However we need some empirical data about what it's doing. Showing your > > > > > /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > > > > > > > > > Initially we didn't provide that data until someone asked for it to be sure that is > > > > in fact what was needed or if the was some other incorrect setting. > > > > > > > > /var/run/dmesg.boot ... > > > > > > I'm trimming this down to the likely relevant ACPI stuff .. > > > > > > > Copyright (c) 1992-2008 The FreeBSD Project. > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > > The Regents of the University of California. All rights reserved. > > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > > FreeBSD 6.3-RELEASE-p3 #1: Mon Aug 4 23:37:02 EDT 2008 > > > > root@WORKSTATION.ath.cx:/usr/obj/usr/src/sys/WORKSTATION > > > > ACPI APIC Table: > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) > > > > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > > > Features=0xbfebfbff > > > > Features2=0xe3bd > > > > AMD Features=0x20100000 > > > > AMD Features2=0x1 > > > > Cores per package: 2 > > > > real memory = 2113142784 (2015 MB) > > > > avail memory = 2058563584 (1963 MB) > > > > ioapic0: Changing APIC ID to 1 > > > > ioapic0 irqs 0-23 on motherboard > > > [..] > > > > acpi0: on motherboard > > > > acpi0: Power Button (fixed) > > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 > > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > > cpu0: on acpi0 > > > [..] > > > > acpi_lid0: on acpi0 > > > > battery0: on acpi0 > > > > acpi_button0: on acpi0 > > > > acpi_acad0: on acpi0 > > > > acpi_tz0: on acpi0 > > > [..] > > > > > > No cpufreq driver/s. cpufreq removed from your custom kernel? So no > > > CPU frequency control. So, powerd is rendered powerless .. > > > > > > 'powerd' is now operational: > > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > ^Ctotal joules used: 41737.500^M > > > > Try booting with the GENERIC kernel, you should see one or two of the > > > supported drivers listed in cpufreq(4) loaded in dmesg.boot. Then see > > > if powerd isn't doing the right thing (w/ powerd -v as discussed below) > > > > > > This has always been the /GENERIC kernel copied to a custome name. > This was a 6.0-RELEASE UPGRADED TO -p3. Apparently cpufreq wasn't > considered as a default entry in the /GENERIC. > > > > > > > > sysctl hw.acpi ... > > > > > > > > hw.acpi.supported_sleep_state: S3 S4 S5 > > > > hw.acpi.power_button_state: S5 > > > > hw.acpi.sleep_button_state: S3 > > > > hw.acpi.lid_switch_state: NONE > > > > hw.acpi.standby_state: S1 > > > > hw.acpi.suspend_state: S3 > > > > hw.acpi.sleep_delay: 1 > > > > hw.acpi.s4bios: 0 > > > > hw.acpi.verbose: 0 > > > > hw.acpi.disable_on_reboot: 0 > > > > hw.acpi.handle_reboot: 0 > > > > hw.acpi.reset_video: 0 > > > > hw.acpi.cpu.cx_lowest: C1 > > > > hw.acpi.battery.life: 100 > > > > hw.acpi.battery.time: -1 > > > > hw.acpi.battery.state: 0 > > > > hw.acpi.battery.units: 1 > > > > hw.acpi.battery.info_expire: 5 > > > > hw.acpi.acline: 1 > > > > hw.acpi.thermal.min_runtime: 0 > > > > hw.acpi.thermal.polling_rate: 10 > > > > hw.acpi.thermal.user_override: 0 > > > > hw.acpi.thermal.tz0.temperature: 63.0C > > > > hw.acpi.thermal.tz0.active: -1 > > > > hw.acpi.thermal.tz0.passive_cooling: 0 > > > > hw.acpi.thermal.tz0.thermal_flags: 0 > > > > hw.acpi.thermal.tz0._PSV: -1 > > > > hw.acpi.thermal.tz0._HOT: -1 > > > > hw.acpi.thermal.tz0._CRT: 102.0C > > > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > > > No passive cooling. See acpi_thermal(4) .. you may want to set some > > > overrides .. but it might all just work with the GENERIC kernel anyway. > > > Attempting to: --> sysctl hw.acpi.thermal.user_override > hw.acpi.thermal.user_override: 0 > Attempting to: --> sysctl hw.acpi.thermal.user_override=1 > hw.acpi.thermal.user_override: 0 -> 1 > > Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling > hw.acpi.thermal.tz0.passive_cooling: 0 > Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling=1 > hw.acpi.thermal.tz0.passive_cooling: 0 > sysctl: hw.acpi.thermal.tz0.passive_cooling: Operation not supported > by device > > NOTE: While we are able to change the threshold for: > hw.acpi.thermal.tz0._PSV: -1, we don't see the need to do so because > the above passive_cooling is not enabled. > > Well, so much for passive_cooling. :=\ > > > > Also, have you set anything in BIOS regarding power usage, speedstep or > > > any other settings that might get reflected into your boot ACPI setup? > > Initially we left the BIOS power settings the way the OEM set them > (Vista). We are able to choose from one of Dynamic, High or low > not much else to play with in the way of power settings (ACPI) > with the exception of LCD and/or letting the OS control devices. > Unable to directly set CPU steppings/freq settings within this BIOS. > > > > > And, are you loading acpi_toshiba(4)? Not sure if it would help with > > > this, but may at least provide some useful info in its sysctls .. > > > > > > This is an issue revisited; take a deep breath. Better yet, here's > the short version, in the kernel 'device acpi_toshiba' does not work > for us on this machine unless we neglected to make an accompanying > needed acpi entry. Aa we understand it, we were to only add 'device > acpi_toshiba' to load the neccessary acpi toshiba extras. > > Using 'acpi_toshiba_load="YES"' in the /boot/loader.conf -and- using > 'kldload acpi_toshiba' from the cli works like a charm but has no > positive affect on the current discussion (heat). > > > > > > Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop > > > > > (if it's running) then run 'powerd -v' which runs in foreground and says > > > > > exactly what it's doing re shifting CPU frequency under various loads. > > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > ^Ctotal joules used: 41737.500 > > > > > > > > > > > It's also useful to watch the temperature(s) directly over the time, see > > > > > acpi_thermal(4) and try logging those sysctls periodically in a script. > > The following data is the result of the concerns I have; running too > hot. These figures are the lowest temperatures this machine idles > while FreeBSD is installed and running. The temperatures shown > herein only rise with use but never go lower than what we're showing > here when the laptop returns to idle. > > Attempting to: --> sysctl hw.acpi.thermal.tz0. > hw.acpi.thermal.tz0.temperature: 61.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 102.0C > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > > > Firstly, yes that comment isn't too helpful .. power_profile only acts > > > > > (so far) when you apply or remove AC power, using the following values > > > > > from /etc/defaults/rc.conf unless you've set them otherwise: > > > > > > > > > > performance_cx_lowest="HIGH" # Online CPU idle state > > > > > performance_cpu_freq="HIGH" # Online CPU frequency > > > > > economy_cx_lowest="HIGH" # Offline CPU idle state > > > > > economy_cpu_freq="HIGH" # Offline CPU frequency > > Our /etc/defaults/rc.conf > > performance_cx_lowest="HIGH" # Online CPU idle state > performance_cpu_freq="NONE" # Online CPU frequency > economy_cx_lowest="HIGH" # Offline CPU idle state > economy_cpu_freq="NONE" # Offline CPU frequency > > > > > > If you have a look at /etc/rc.d/power_profile you'll see that these are > > > > > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > > > > > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > > > > > variables to HIGH, LOW, a specific value, or NONE. > > Attempting to: --> sysctl hw.acpi.cpu.cx_supported > sysctl: unknown oid 'hw.acpi.cpu.cx_supported' > Attempting to: --> sysctl hw.acpi.cpu > hw.acpi.cpu.cx_lowest: C1 > > Above, where is "hw.acpi.cpu.cx_supported"? Did FreeBSD 'not' > probe something? > > Attempting to: --> sysctl dev.cpu.0.freq_levels > dev.cpu.0.freq_levels: 2201/35000 2200/35000 1925/30625 1650/26250 > 1600/23000 1400/20125 1200/16000 1050/14000 900/12000 800/14300 > 700/12512 600/10725 500/8937 400/7150 300/5362 200/3575 100/1787 > > Following is grepped from /var/run/dmesg.boot: > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.54-MHz > 686-class CPU) > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > > > > > > Specify "NONE" to have power_profile make no changes. "C3" or at least > > > > > "C2" can be useful CX values, in some machines helping with temperature. > > > > > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > > > > > a problem - again, watch powerd -v output - and I guess you'll rarely > > > > > run on battery (you've got a nice 2-3 hour UPS, though :) > > > Our /etc/rc.conf > > performance_cx_lowest="C4" # Online CPU idle state > #performance_cpu_freq="HIGH" # Online CPU frequency > economy_cx_lowest="C5" # Offline CPU idle state > #economy_cpu_freq="HIGH" # Offline CPU frequency > > This machine can afford to go to C4 and C5 unless needed otherwise. > I'll try anything to lowwer this machines temp. > > > > > This is another issue in addition to the heat. As you say, this battery > > > > should last any where from 2-3 hours, however as it is now; > > > > out-of-the-box so to speak, this machine will only stay powered up > > > > approximately 1-hour on using the oem battery. > > > > > > That's because it runs at (presumably) its maximum frequency all of the > > > time; you're lucky to get an hour at that rate, and yes it'll run hot :) > > > > > > 'sysctl dev.cpu.0.freq hw.acpi.thermal.tz0.temperature' now and again. > > These numbers have not changed (lowwer) prior to or during this thread. > > Attempting to: --> sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. > Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature > hw.acpi.thermal.tz0.temperature: 61.0C > > > > > > This machine has never run this hot, prior to running 'powerd'-- or run > > > > > > this warm, while idling with 'powerd' in comparison to running under windows > > > > > > --not trying to start and OS confilict here, trying to learn, understand > > > > > > and control this beast of a machine if possible. > > > > > > > > > > Of course, and it's likely doable, though you might need to run 7-STABLE > > > > > for the latest dual-core ACPI handling. Let's see how we go with some > > > > > real information, before suggesting taking this to freebsd-acpi@. I > > > > > don't see where you've mentioned what version of FreeBSD it's running? > > > > > > > > I believe I did so at the outset of this thread. In any case dmesg has > > > > now provided that information. > > > > > > ok, 6.3-R-p3. Frankly I've no idea whether your dual-core Toshiba is or > > > is not subject to any of the dual-core issues solved or being actively > > > worked on in freebsd-acpi and being applied mostly or at least firstly > > > back into 7-STABLE. I'd suggest browsing the -acpi archives for the > > > last few months, it's not that big .. that is, if using the GENERIC > > > kernel and running powerd doesn't improve matters sufficiently. > > > > > > cheers, Ian > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" On Sat, Aug 30, 2008 at 05:07:36PM -0400, freebsd_user@guice.ath.cx wrote: > On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx wrote: > FROM THE LAST MESSAGE ... > > > > > > > However we need some empirical data about what it's doing. Showing your > > > > > /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > > > > > > > > > Initially we didn't provide that data until someone asked for it to be sure that is > > > > in fact what was needed or if the was some other incorrect setting. > > > > > > > > /var/run/dmesg.boot ... > > > > > > I'm trimming this down to the likely relevant ACPI stuff .. > > > > > > > Copyright (c) 1992-2008 The FreeBSD Project. > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > > The Regents of the University of California. All rights reserved. > > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > > FreeBSD 6.3-RELEASE-p3 #1: Mon Aug 4 23:37:02 EDT 2008 > > > > root@WORKSTATION.ath.cx:/usr/obj/usr/src/sys/WORKSTATION > > > > ACPI APIC Table: > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) > > > > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > > > Features=0xbfebfbff > > > > Features2=0xe3bd > > > > AMD Features=0x20100000 > > > > AMD Features2=0x1 > > > > Cores per package: 2 > > > > real memory = 2113142784 (2015 MB) > > > > avail memory = 2058563584 (1963 MB) > > > > ioapic0: Changing APIC ID to 1 > > > > ioapic0 irqs 0-23 on motherboard > > > [..] > > > > acpi0: on motherboard > > > > acpi0: Power Button (fixed) > > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 > > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > > cpu0: on acpi0 > > > [..] > > > > acpi_lid0: on acpi0 > > > > battery0: on acpi0 > > > > acpi_button0: on acpi0 > > > > acpi_acad0: on acpi0 > > > > acpi_tz0: on acpi0 > > > [..] > > > > > > No cpufreq driver/s. cpufreq removed from your custom kernel? So no > > > CPU frequency control. So, powerd is rendered powerless .. > > > > > > 'powerd' is now operational: > > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > ^Ctotal joules used: 41737.500^M > > > > Try booting with the GENERIC kernel, you should see one or two of the > > > supported drivers listed in cpufreq(4) loaded in dmesg.boot. Then see > > > if powerd isn't doing the right thing (w/ powerd -v as discussed below) > > > > > > This has always been the /GENERIC kernel copied to a custome name. > This was a 6.0-RELEASE UPGRADED TO -p3. Apparently cpufreq wasn't > considered as a default entry in the /GENERIC. > > > > > > > > sysctl hw.acpi ... > > > > > > > > hw.acpi.supported_sleep_state: S3 S4 S5 > > > > hw.acpi.power_button_state: S5 > > > > hw.acpi.sleep_button_state: S3 > > > > hw.acpi.lid_switch_state: NONE > > > > hw.acpi.standby_state: S1 > > > > hw.acpi.suspend_state: S3 > > > > hw.acpi.sleep_delay: 1 > > > > hw.acpi.s4bios: 0 > > > > hw.acpi.verbose: 0 > > > > hw.acpi.disable_on_reboot: 0 > > > > hw.acpi.handle_reboot: 0 > > > > hw.acpi.reset_video: 0 > > > > hw.acpi.cpu.cx_lowest: C1 > > > > hw.acpi.battery.life: 100 > > > > hw.acpi.battery.time: -1 > > > > hw.acpi.battery.state: 0 > > > > hw.acpi.battery.units: 1 > > > > hw.acpi.battery.info_expire: 5 > > > > hw.acpi.acline: 1 > > > > hw.acpi.thermal.min_runtime: 0 > > > > hw.acpi.thermal.polling_rate: 10 > > > > hw.acpi.thermal.user_override: 0 > > > > hw.acpi.thermal.tz0.temperature: 63.0C > > > > hw.acpi.thermal.tz0.active: -1 > > > > hw.acpi.thermal.tz0.passive_cooling: 0 > > > > hw.acpi.thermal.tz0.thermal_flags: 0 > > > > hw.acpi.thermal.tz0._PSV: -1 > > > > hw.acpi.thermal.tz0._HOT: -1 > > > > hw.acpi.thermal.tz0._CRT: 102.0C > > > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > > > No passive cooling. See acpi_thermal(4) .. you may want to set some > > > overrides .. but it might all just work with the GENERIC kernel anyway. > > > Attempting to: --> sysctl hw.acpi.thermal.user_override > hw.acpi.thermal.user_override: 0 > Attempting to: --> sysctl hw.acpi.thermal.user_override=1 > hw.acpi.thermal.user_override: 0 -> 1 > > Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling > hw.acpi.thermal.tz0.passive_cooling: 0 > Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling=1 > hw.acpi.thermal.tz0.passive_cooling: 0 > sysctl: hw.acpi.thermal.tz0.passive_cooling: Operation not supported > by device > > NOTE: While we are able to change the threshold for: > hw.acpi.thermal.tz0._PSV: -1, we don't see the need to do so because > the above passive_cooling is not enabled. > > Well, so much for passive_cooling. :=\ > > > > Also, have you set anything in BIOS regarding power usage, speedstep or > > > any other settings that might get reflected into your boot ACPI setup? > > Initially we left the BIOS power settings the way the OEM set them > (Vista). We are able to choose from one of Dynamic, High or low > not much else to play with in the way of power settings (ACPI) > with the exception of LCD and/or letting the OS control devices. > Unable to directly set CPU steppings/freq settings within this BIOS. > > > > > And, are you loading acpi_toshiba(4)? Not sure if it would help with > > > this, but may at least provide some useful info in its sysctls .. > > > > > > This is an issue revisited; take a deep breath. Better yet, here's > the short version, in the kernel 'device acpi_toshiba' does not work > for us on this machine unless we neglected to make an accompanying > needed acpi entry. Aa we understand it, we were to only add 'device > acpi_toshiba' to load the neccessary acpi toshiba extras. > > Using 'acpi_toshiba_load="YES"' in the /boot/loader.conf -and- using > 'kldload acpi_toshiba' from the cli works like a charm but has no > positive affect on the current discussion (heat). > > > > > > Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop > > > > > (if it's running) then run 'powerd -v' which runs in foreground and says > > > > > exactly what it's doing re shifting CPU frequency under various loads. > > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > ^Ctotal joules used: 41737.500 > > > > > > > > > > > It's also useful to watch the temperature(s) directly over the time, see > > > > > acpi_thermal(4) and try logging those sysctls periodically in a script. > > The following data is the result of the concerns I have; running too > hot. These figures are the lowest temperatures this machine idles > while FreeBSD is installed and running. The temperatures shown > herein only rise with use but never go lower than what we're showing > here when the laptop returns to idle. > > Attempting to: --> sysctl hw.acpi.thermal.tz0. > hw.acpi.thermal.tz0.temperature: 61.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 102.0C > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > > > Firstly, yes that comment isn't too helpful .. power_profile only acts > > > > > (so far) when you apply or remove AC power, using the following values > > > > > from /etc/defaults/rc.conf unless you've set them otherwise: > > > > > > > > > > performance_cx_lowest="HIGH" # Online CPU idle state > > > > > performance_cpu_freq="HIGH" # Online CPU frequency > > > > > economy_cx_lowest="HIGH" # Offline CPU idle state > > > > > economy_cpu_freq="HIGH" # Offline CPU frequency > > Our /etc/defaults/rc.conf > > performance_cx_lowest="HIGH" # Online CPU idle state > performance_cpu_freq="NONE" # Online CPU frequency > economy_cx_lowest="HIGH" # Offline CPU idle state > economy_cpu_freq="NONE" # Offline CPU frequency > > > > > > If you have a look at /etc/rc.d/power_profile you'll see that these are > > > > > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > > > > > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > > > > > variables to HIGH, LOW, a specific value, or NONE. > > Attempting to: --> sysctl hw.acpi.cpu.cx_supported > sysctl: unknown oid 'hw.acpi.cpu.cx_supported' > Attempting to: --> sysctl hw.acpi.cpu > hw.acpi.cpu.cx_lowest: C1 > > Above, where is "hw.acpi.cpu.cx_supported"? Did FreeBSD 'not' > probe something? > > Attempting to: --> sysctl dev.cpu.0.freq_levels > dev.cpu.0.freq_levels: 2201/35000 2200/35000 1925/30625 1650/26250 > 1600/23000 1400/20125 1200/16000 1050/14000 900/12000 800/14300 > 700/12512 600/10725 500/8937 400/7150 300/5362 200/3575 100/1787 > > Following is grepped from /var/run/dmesg.boot: > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.54-MHz > 686-class CPU) > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > > > > > > Specify "NONE" to have power_profile make no changes. "C3" or at least > > > > > "C2" can be useful CX values, in some machines helping with temperature. > > > > > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > > > > > a problem - again, watch powerd -v output - and I guess you'll rarely > > > > > run on battery (you've got a nice 2-3 hour UPS, though :) > > > Our /etc/rc.conf > > performance_cx_lowest="C4" # Online CPU idle state > #performance_cpu_freq="HIGH" # Online CPU frequency > economy_cx_lowest="C5" # Offline CPU idle state > #economy_cpu_freq="HIGH" # Offline CPU frequency > > This machine can afford to go to C4 and C5 unless needed otherwise. > I'll try anything to lowwer this machines temp. > > > > > This is another issue in addition to the heat. As you say, this battery > > > > should last any where from 2-3 hours, however as it is now; > > > > out-of-the-box so to speak, this machine will only stay powered up > > > > approximately 1-hour on using the oem battery. > > > > > > That's because it runs at (presumably) its maximum frequency all of the > > > time; you're lucky to get an hour at that rate, and yes it'll run hot :) > > > > > > 'sysctl dev.cpu.0.freq hw.acpi.thermal.tz0.temperature' now and again. > > These numbers have not changed (lowwer) prior to or during this thread. > > Attempting to: --> sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. > Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature > hw.acpi.thermal.tz0.temperature: 61.0C > > > > > > This machine has never run this hot, prior to running 'powerd'-- or run > > > > > > this warm, while idling with 'powerd' in comparison to running under windows > > > > > > --not trying to start and OS confilict here, trying to learn, understand > > > > > > and control this beast of a machine if possible. > > > > > > > > > > Of course, and it's likely doable, though you might need to run 7-STABLE > > > > > for the latest dual-core ACPI handling. Let's see how we go with some > > > > > real information, before suggesting taking this to freebsd-acpi@. I > > > > > don't see where you've mentioned what version of FreeBSD it's running? > > > > > > > > I believe I did so at the outset of this thread. In any case dmesg has > > > > now provided that information. > > > > > > ok, 6.3-R-p3. Frankly I've no idea whether your dual-core Toshiba is or > > > is not subject to any of the dual-core issues solved or being actively > > > worked on in freebsd-acpi and being applied mostly or at least firstly > > > back into 7-STABLE. I'd suggest browsing the -acpi archives for the > > > last few months, it's not that big .. that is, if using the GENERIC > > > kernel and running powerd doesn't improve matters sufficiently. > > > > > > cheers, Ian > > > > > > > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org"