From owner-freebsd-mobile@FreeBSD.ORG Sat Feb 2 07:32:32 2013 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C5A39501; Sat, 2 Feb 2013 07:32:32 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC3A2ED; Sat, 2 Feb 2013 07:32:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r127WNoC068110; Sat, 2 Feb 2013 18:32:23 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 2 Feb 2013 18:32:23 +1100 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: Notes; Lenovo T400 In-Reply-To: Message-ID: <20130202161405.F87033@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-mobile@freebsd.org X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 07:32:32 -0000 On Wed, 30 Jan 2013 21:35:36 -0800, Adrian Chadd wrote: > Hi, > > It turns out my Lenovo T400 issue? It was because in /etc/sysctl.conf > I had this: > > # hw.acpi.reset_video=1 > > .. don't do that. Took some hunting to find your original Nov 27 post, boiled down to: > The resume results in a blank screen - whatever happens causes the > video to not fully recover.. So may we assume your T400 now resumes properly? Reason I'm interested is having last week stripped a friend's T500 almost completely down to replace its snapped left LCD hinge - not an uncommonly reported problem with T500s, not so much T400s, on various fora including Lenovo and Thinkwiki - and I might get to inherit this one when she upgrades. A few observations from two long nights in the bowels of the beast: Construction quality, compared with my several IBM T23s, is crap. The broken hinge problem exemplifies that; I loosened the tension on the supposedly genuine but even tinnier-looking replacement hinge to hopefully mitigate a repeat, but even so I've advised her to open and close it gingerly and then as infrequently as is practical. The service manual still looks and smells like an IBM manual, but is inaccurate in several respects. All of the supposedly nylon-covered screws were in fact standard screws with a dab of Loctite; I only bothered with a very light grade of Loctite on significant screws like the heatpipe to CPU/GPU/fan attachment and the hinge-to-frame screws. The old remedy of blowing out heatsinks with a can of compressed air only works after removing the heatpipes to the fan and heatsink, which is a very finely-spaced grill on the fan output side, which was almost 100% clogged after 2 years, and blowing air INTO it from outside would only have distributed the muck around inside, ready to re-clog the outlet. No obvious air inlets, either. Yes, the heatsink compound was solidified and not well done originally. The heatpipe to the video chips (one Nvidia, one Intel) was different to the manual, but I may have googled up an older version. I used what should be a good grade of silver HS compound and it now runs SO much cooler, but these things are expected to be running hot anyway!: hw.acpi.thermal.tz0._PSV: 105.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 110.0C My friend is a fast touch typist, and has managed to wear the markings off half a dozen keycaps in just over two years, unlike old Thinkpads. This doesn't bother her, but a hunt-n-pecker like me has to think :) Care to comment on what works on yours, and what doesn't? I have to assume you've got wireless going :) What card? Are there any issues with BIOS blacklists for wireless cards? This one came with: iwn0: mem 0xfd6fe000-0xfd6fffff irq 17 at device 0.0 on pci3 I booted it from an i386 9.1-RELEASE disc1 and have a normal and verbose dmesg and sysctls dev.cpu and hw.acpi if anyone's interested, though of course all the HDA logging has chopped off the head of the verbose dmesg with its standard 64K buffersize (61753 bytes recorded) - grrr! cheers, Ian