Re: overheating thinkpad after resume
I'm really sorry to provide a generic overheating response (I don't have a particular piece of hardware to test against), but make sure that you have latest BIOS. I had similar with E530 (?) and it was the middleware problem, not software. OpenBSD is known for being pedantic in complying to all sorts of standards while Lenovo developers are known to be slacking on it, hoping driver authors to figure out solutions for special cases themselves. Again, sorry for generic response, hopefully people with this hardware will respond soon enough. :) On Tue, Apr 14, 2015 at 11:41 PM, frantisek holop wrote: > hello, > > i have hinted about this issue before, but it is > becoming something that quite bothers me, so i > thought i might ask for help. > > i have a thinkpad x60s. after resuming from lidsuspend, > for no apparent reason the temperature keeps hanging > around 70-71. if i make a reboot, it will go back to 55. > > not all resumings result in this higher temperature, > but once it happens, it seems to keep this "state" > after multiple lidsuspends, again, until reboot. > > any ideas how to track this down? > no rogue interrupts, no high cpu usage... > > > 2 usersLoad 1.25 1.16 1.14 (1-25 of 31)Tue Apr 14 22:32:59 > 2015 > > SENSOR VALUE STATUS DESCRIPTION > acpitz0.temp0 54.00 degC zone > temperature > acpitz1.temp0 72.00 degC zone > temperature > acpibtn0.indicator0On lid open > acpibat0.volt0 14.40 V DC voltage > acpibat0.volt1 16.43 V DC current > voltage > acpibat0.power00.00 W rate > acpibat0.watthour0 21.75 Wh last full > capacity > acpibat0.watthour11.09 Wh warning > capacity > acpibat0.watthour20.20 Wh low capacity > acpibat0.watthour3 20.91 WhOKremaining > capacity > acpibat0.watthour4 28.80 Wh design > capacity > acpibat0.raw0 0 rawOKbattery idle > acpiac0.indicator0 On power supply > acpithinkpad0.temp054.00 degC > acpithinkpad0.temp144.00 degC > acpithinkpad0.temp351.00 degC > acpithinkpad0.temp432.00 degC > acpithinkpad0.temp631.00 degC > acpithinkpad0.fan0 3090 RPM > acpidock0.indicator0 Off unknown not docked > cpu0.temp0 72.00 degC > aps0.temp0 44.00 degC > aps0.temp1 44.00 degC > aps0.indicator0 Off Keyboard > Active > aps0.indicator1 Off Mouse Active > aps0.indicator2On Lid Open > aps0.raw0 465 raw X_ACCEL > aps0.raw1 512 raw Y_ACCEL > aps0.raw2 465 raw X_VAR > aps0.raw3 512 raw Y_VAR > softraid0.drive0 onlineOKsd1 > > > load averages: 1.51, 1.27, 1.18 > 61 processes: 1 running, 58 idle, 2 on processor > CPU0 states: 0.0% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.8% > idle > CPU1 states: 3.8% user, 0.0% nice, 2.2% system, 0.0% interrupt, 94.0% > idle > Memory: Real: 341M/865M act/tot Free: 1129M Cache: 365M Swap: 0K/2252M > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND > 29231 _x11 20 15M 25M sleep select5:30 4.64% Xorg > 22368 f 20 246M 263M run poll 10:48 0.78% firefox > 13203 f 20 2488K 3556K sleep kqread1:41 0.63% tmux > 24019 _sndio 2 -20 440K 956K idle poll 2:33 0.00% sndiod > 10611 f 20 3620K 13M sleep poll 1:16 0.00% gkrellm > ... > > > $ vmstat -i > interrupt total rate > irq0/clock4465583 199 > irq0/ipi 8587915 384 > irq130/acpi0 44740 > irq81/inteldrm0 18890 > irq160/azalia01437612 64 > irq85/ppb0 10 > irq83/uhci2 10 > irq84/uhci3460 > irq84/ehci0911663 40 > irq80/ahci0 1419214 63 > irq129/pckbc0 220 > irq131/pckbc0 92
Re: Updating sets
Alright, thanks for being ever-so-helpful. I'll do my best to compile my understanding of the system taking into account the response that is accumulated here. As Mr. Grosse points out (and I was originally aware of it), using snapshot userspace provides only an approximation of current userspace without any guarantees that snapshots are "up to date enough". That being said, it's a common practice to use -current with binary packages. This is supported by experience of several BSD users and isn't considered to be bad practice. Which measures should one take while using -current kernel with snapshot userspace? 1. Know your mirror: A person who wants to do that should find out the policies of making snapshots for a particular mirror. 2. Always keep bsd.rd in / System running -current kernel with snapshots are even less stable than one running -current and using fully compiled userspace from ports source tree. 3. Shake, don't mix If one commits to usage of -current kernel with snapshot ports, best effort should be put in avoiding port compilation. 4. pkg_add -U shouldn't be used Partial update of the system is dangerous and as we don't have control over the source of snapshots, an upgrade followed by full update should be done as a part of installation of new package. 5. Sets should be updated from a fresh bsd.rd Ditto. Reference reading material: man sysmerge man dpb Now that I think about it, I realize that it's unlikely that I'll keep using this weird "build kernel, download pkgs" combination and will simply do snapshot hopping by means of upgrade/sysmerge. Thank you all, response was astonishing.
Re: Updating sets
Errata: ``"snapshot" pigs'' should read ``"snapshot" pkgs''. Please blame automatic completion. On May 7, 2014 6:51 PM, "Manuel Pages" wrote: > Dear list, > Using manuals I have figured out how to follow > -current by means of buliding kernel and rebuilding > userspace. Also I can see that with a known amount > of caution it's possiblle to use snapshots with -current > and update userspace with pkg_add -u. > What escapes my mind though is how do sets get > updated. Can you please link me to manuals covering > the topics of keeping base of the system up to date > and in sync with kernel and binary "snapshot" pigs? > Thanks for being super-helpful as a community! > Cheers.
Updating sets
Dear list, Using manuals I have figured out how to follow -current by means of buliding kernel and rebuilding userspace. Also I can see that with a known amount of caution it's possiblle to use snapshots with -current and update userspace with pkg_add -u. What escapes my mind though is how do sets get updated. Can you please link me to manuals covering the topics of keeping base of the system up to date and in sync with kernel and binary "snapshot" pigs? Thanks for being super-helpful as a community! Cheers.
Re: Intel driver doesn't get automatically selected by Xorg
Rebuilding kernel helped. Now I run -current MP kernel and everything works like a charm. Much love and gratefulness to you, Tomash.
Re: Intel driver doesn't get automatically selected by Xorg
Dear Tomaš, thank you so much for your support, thanks to you I felt encouraged to finally update my BIOS. It solved the driver problem (and by the looks of it, improved fan performance, but it's handwaving); however as far as I can tell from dmesg and system performance, only one core is used still. If you have any great hints or suggestions about how to proceed, please share those. New Xorg.0.log (initial issue resolved): http://f.nn.lv/n5/7h/yq/Xorg.0.log New dmesg output (still only one CPU found): http://f.nn.lv/n5/7h/zi/dmesg.full
Re: Intel driver doesn't get automatically selected by Xorg
Wow, I didn't catch it. It's kinda shocking. Is there any data bank regarding Thinkpads, it's BIOS and OpenBSD?
Re: Intel driver doesn't get automatically selected by Xorg
I'm so sorry! http://f.nn.lv/n5/7c/ii/dmesg.full On Wed, May 7, 2014 at 2:36 PM, Tomas Bodzar wrote: > > > > On Wed, May 7, 2014 at 1:23 PM, Manuel Pages > wrote: > >> Hello list, first post here \o/ >> >> The question is about drivers for "Intel HD Graphics 3000" rev 0x09 >> (not a hybrid with some nVIDIA nonsense). >> >> When I run X, I get the following result (from Xorg.0.log): >> >> ``` >> [ 42880.697] (II) LoadModule: "intel" >> [ 42880.698] (II) Loading /usr/X11R6/lib/modules/drivers/intel_drv.so >> [ 42880.702] (II) Module intel: vendor="X.Org Foundation" >> [ 42880.702]compiled for 1.14.5, module version = 2.99.910 >> [ 42880.702]Module class: X.Org Video Driver >> [ 42880.702]ABI class: X.Org Video Driver, version 14.1 >> [ 42880.702] (II) LoadModule: "vesa" >> [ 42880.704] (II) Loading /usr/X11R6/lib/modules/drivers/vesa_drv.so >> [ 42880.712] (II) Module vesa: vendor="X.Org Foundation" >> [ 42880.712]compiled for 1.14.5, module version = 2.3.3 >> [ 42880.712]Module class: X.Org Video Driver >> [ 42880.712]ABI class: X.Org Video Driver, version 14.1 >> [ 42880.712] (II) intel: Driver for Intel(R) Integrated Graphics >> Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, >> 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, >> Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, >> GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 >> [ 42880.713] (II) intel: Driver for Intel(R) HD Graphics: 2000-5000 >> [ 42880.713] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100 >> [ 42880.713] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200 >> [ 42880.713] (II) VESA: driver for VESA chipsets: vesa >> [ 42880.714] (WW) Falling back to old probe method for vesa >> [ 42880.716] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD >> Graphics 3000 >> ``` >> >> As we can see, it correctly selected candidate i915 then reported that >> it supports chips from 2000 to 5000 and still it falls back to vesa. >> >> Is that a configuration issue? Is that a known issue? >> Any help is appreciated. >> >> > We are missing your dmesg output > > -- Fly safe, Sloz
Intel driver doesn't get automatically selected by Xorg
Hello list, first post here \o/ The question is about drivers for "Intel HD Graphics 3000" rev 0x09 (not a hybrid with some nVIDIA nonsense). When I run X, I get the following result (from Xorg.0.log): ``` [ 42880.697] (II) LoadModule: "intel" [ 42880.698] (II) Loading /usr/X11R6/lib/modules/drivers/intel_drv.so [ 42880.702] (II) Module intel: vendor="X.Org Foundation" [ 42880.702]compiled for 1.14.5, module version = 2.99.910 [ 42880.702]Module class: X.Org Video Driver [ 42880.702]ABI class: X.Org Video Driver, version 14.1 [ 42880.702] (II) LoadModule: "vesa" [ 42880.704] (II) Loading /usr/X11R6/lib/modules/drivers/vesa_drv.so [ 42880.712] (II) Module vesa: vendor="X.Org Foundation" [ 42880.712]compiled for 1.14.5, module version = 2.3.3 [ 42880.712]Module class: X.Org Video Driver [ 42880.712]ABI class: X.Org Video Driver, version 14.1 [ 42880.712] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 [ 42880.713] (II) intel: Driver for Intel(R) HD Graphics: 2000-5000 [ 42880.713] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100 [ 42880.713] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200 [ 42880.713] (II) VESA: driver for VESA chipsets: vesa [ 42880.714] (WW) Falling back to old probe method for vesa [ 42880.716] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000 ``` As we can see, it correctly selected candidate i915 then reported that it supports chips from 2000 to 5000 and still it falls back to vesa. Is that a configuration issue? Is that a known issue? Any help is appreciated.
