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 min...@obiit.org 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 920 Total16828512 753 OpenBSD 5.7-current
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.
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 tomas.bod...@gmail.com wrote: On Wed, May 7, 2014 at 1:23 PM, Manuel Pages amarr.industr...@gmail.comwrote: 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
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
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
Rebuilding kernel helped. Now I run -current MP kernel and everything works like a charm. Much love and gratefulness to you, Tomash.
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: Updating sets
Errata: ``snapshot pigs'' should read ``snapshot pkgs''. Please blame automatic completion. On May 7, 2014 6:51 PM, Manuel Pages amarr.industr...@gmail.com 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.
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.
