Re: Thinkpad T410: resume broken
On 17.05.2014 01:39, Adrian Chadd wrote: Hm, okay. i wonder how we can diagnose this further. Do you have a video monitor? Can you try doing a suspend/resume with an external VGA screen attached? I booted with VGA as primary (and only) monitor. No real changes. The external monitor also remains blank when I resume on virtual console. Or connect it via ethernet and do a suspend/resume whilst logged in? I can do that. Any specific data you expect from that? Some more infos from today's testing: I also had one or two hangs during resume from Xorg with vt (similar to the sc hangs). If I restart Xorg, I get rid of the garbled X fonts/graphics (when resume is working) There are just too many options right now: sc/vt, X11/console, nvidia driver, internal display/external monitor, etc.. Are there any specific tests that could be useful? dmesg excerpts of a mostly working suspend/resume, don't know if related: When I start Xorg (9x) ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) During suspend/resume: pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP4: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: AE_BAD_PARAMETER ... NVRM: GPU at :01:00: GPU-bc3d36af-d7e7-bb30-dd7a-84afb0d14d75 NVRM: Xid (:01:00): 6, PE0001 ... NVRM: Xid (:01:00): 56, CMDre 0080 0005 0008 -- Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
r266298: make buildworld fail: fatal error: 'llvm/ADT/APFloat.h' file not found #include llvm/ADT/APFloat.h
With 11.0-CURRENT's sources (r266298) buildworld fails: [...] /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15:10: fatal error: 'llvm/ADT/APFloat.h' file not found #include llvm/ADT/APFloat.h ^ 1 error generated. /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cpp:16:10: fatal error: 'llvm/ADT/APInt.h' file not found #include llvm/ADT/APInt.h oh signature.asc Description: PGP signature
ARM i.MX6 based Utilitie-Pro board supported?
I'm looking for a smart FreeBSD Router/Gateway solution based upon the ARM architecture. One of the necessities ist the existence of two GBit NICs which are hard to find on most experimental ARM platforms today combinded with at least two CPU cores. I found the Utilities Pro board [1], four cores, two GBit NICs and WiFi along with 2GB RAM and I was wondering whether this board is supported by FreeBSD. I couldn't find anything useful since I'm a novice with ARM CPU naming and Utilities Pro is not mentioned in the list of compatible and supported ARM based equipment in [2]. Well, not being mentioned doesn't mean not supported since the components have to be supported anyway, but as I said, I do not know what Utilities Pro equipt to their solution. maybe someon of the FreeBSd users already made some experiences with this board/solution. Thanks in advance, Oliver [1] http://utilite-computer.com/web/utilite-pro-specifications [2] https://wiki.freebsd.org/FreeBSD/arm signature.asc Description: PGP signature
Re: ARM i.MX6 based Utilitie-Pro board supported?
Hi! I'm looking for a smart FreeBSD Router/Gateway solution based upon the ARM architecture. Why arm ? Have a look at the new APU boards. 3x GigE, low power, 4 GB RAM, very nice case. amd64 architecture. http://www.pcengines.ch/apu.htm We tested it on 10.0, very nice! http://blog.hackathon.de/installing-freebsd-10-on-an-alix-apu1c4.html -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ARM i.MX6 based Utilitie-Pro board supported?
17.05.2014 12:50, O. Hartmann пишет: I'm looking for a smart FreeBSD Router/Gateway solution based upon the ARM architecture. I'd wonder why it's ARM. I'd think that a MIPS arch is more appropriate for a router. One of the necessities ist the existence of two GBit NICs which are hard to find on most experimental ARM platforms today combinded with at least two CPU cores. I have a IMX6 based wandboard-quad with 1Gb NIC. It's theoretical maximum speed is 40 MB/sec., while current driver achieves about 20 MB/sec. I found the Utilities Pro board [1], four cores, two GBit NICs and WiFi along with 2GB RAM and I was wondering whether this board is supported by FreeBSD. I couldn't find anything useful since I'm a novice with ARM CPU naming and Utilities Pro is not mentioned in the list of compatible and supported ARM based equipment in [2]. Well, not being mentioned doesn't mean not supported since the components have to be supported anyway, but as I said, I do not know what Utilities Pro equipt to their solution. maybe someon of the FreeBSd users already made some experiences with this board/solution. You may find and get more info at the arm@ ML. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r266298: make buildworld fail: fatal error: 'llvm/ADT/APFloat.h' file not found #include llvm/ADT/APFloat.h
On 17 May 2014, at 10:11, O. Hartmann ohart...@zedat.fu-berlin.de wrote: With 11.0-CURRENT's sources (r266298) buildworld fails: [...] /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15:10: fatal error: 'llvm/ADT/APFloat.h' file not found #include llvm/ADT/APFloat.h ^ 1 error generated. /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cpp:16:10: fatal error: 'llvm/ADT/APInt.h' file not found #include llvm/ADT/APInt.h Can you please post your make.conf and src.conf? -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Leaving the Desktop Market
On 5/12/14, 1:35 PM, Allan Jude wrote: I have this system: hw.model: Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz hw.ncpu: 4 http://ark.intel.com/products/75052 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.freq: 3100 dev.cpu.0.freq_levels: 3101/8 3100/8 2900/72713 2800/69558 2600/62669 2400/56794 2300/53935 2100/47673 1900/42370 1800/39795 1600/34136 1500/31729 1300/26432 1137/23128 1100/21994 1000/19851 875/17369 800/15113 700/13223 600/11334 500/9445 400/7556 300/5667 200/3778 100/1889 dev.cpu.0.cx_supported: C1/1/1 C2/2/148 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 9.01% 90.98% last 807us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1/1 C2/2/148 dev.cpu.1.cx_lowest: C8 dev.cpu.1.cx_usage: 11.70% 88.29% last 21303us dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=\_PR_.CPU2 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%parent: acpi0 dev.cpu.2.cx_supported: C1/1/1 C2/2/148 dev.cpu.2.cx_lowest: C8 dev.cpu.2.cx_usage: 15.17% 84.82% last 22987us dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=\_PR_.CPU3 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%parent: acpi0 dev.cpu.3.cx_supported: C1/1/1 C2/2/148 dev.cpu.3.cx_lowest: C8 dev.cpu.3.cx_usage: 11.74% 88.25% last 6073us According to the Intel specs (Page 11), this processor supports C1, C1E, C3, C6 and C7 The above sysctl dump shows only C1 and C2. I wonder if the C2 is actually C3 Yes, ACPI C states != CPU C states. Often C6/C7 map to C3. You might have a BIOS option to control C6/C7. I've seen several BIOSes that default to only exporting Intel C3 as C2, but do not advertise Intel C6/C7 as C3 until you enable that in the BIOS. http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e3-1200v3-vol-1-datasheet.pdf How is our support for the newer Cx States introduced in Haswell, which can apparently go as high as C10 For idling, any Intel Cx state should work as long as the BIOS is configured to export it as an ACPI Cx state. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Leaving the Desktop Market
On 2014-05-17 08:07, John Baldwin wrote: On 5/12/14, 1:35 PM, Allan Jude wrote: I have this system: hw.model: Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz hw.ncpu: 4 http://ark.intel.com/products/75052 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.freq: 3100 dev.cpu.0.freq_levels: 3101/8 3100/8 2900/72713 2800/69558 2600/62669 2400/56794 2300/53935 2100/47673 1900/42370 1800/39795 1600/34136 1500/31729 1300/26432 1137/23128 1100/21994 1000/19851 875/17369 800/15113 700/13223 600/11334 500/9445 400/7556 300/5667 200/3778 100/1889 dev.cpu.0.cx_supported: C1/1/1 C2/2/148 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 9.01% 90.98% last 807us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1/1 C2/2/148 dev.cpu.1.cx_lowest: C8 dev.cpu.1.cx_usage: 11.70% 88.29% last 21303us dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=\_PR_.CPU2 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%parent: acpi0 dev.cpu.2.cx_supported: C1/1/1 C2/2/148 dev.cpu.2.cx_lowest: C8 dev.cpu.2.cx_usage: 15.17% 84.82% last 22987us dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=\_PR_.CPU3 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%parent: acpi0 dev.cpu.3.cx_supported: C1/1/1 C2/2/148 dev.cpu.3.cx_lowest: C8 dev.cpu.3.cx_usage: 11.74% 88.25% last 6073us According to the Intel specs (Page 11), this processor supports C1, C1E, C3, C6 and C7 The above sysctl dump shows only C1 and C2. I wonder if the C2 is actually C3 Yes, ACPI C states != CPU C states. Often C6/C7 map to C3. You might have a BIOS option to control C6/C7. I've seen several BIOSes that default to only exporting Intel C3 as C2, but do not advertise Intel C6/C7 as C3 until you enable that in the BIOS. http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e3-1200v3-vol-1-datasheet.pdf How is our support for the newer Cx States introduced in Haswell, which can apparently go as high as C10 For idling, any Intel Cx state should work as long as the BIOS is configured to export it as an ACPI Cx state. Yes, using the intel-pcm tool from ports that Adrian suggested allowed me to check and confirm that when ACPI C3 is being used, the CPU is going to C7 on cores and C6 for the entire package, as well as giving detailed statistics The only thing that I noticed is that the cx_usage stats do not get updated under 100% cpu load (when the CPU never leaves C0) This can be confusing when it suggests that the core is spending 50% of its time in C3 when it is in fact not, but I am not familiar with this part of the system to know if that is something that i sour fault or ACPIs, and if it is fixable. Just reporting my observations ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: resource_list_add: resource entry is busy
On 5/16/14, 12:21 PM, Hans Petter Selasky wrote: Hi, I see the following panic: panic: resource_list_add: resource entry is busy When trying to kldload an older pccard driver. The call comes from the driver_added bus method somewhere down the tree. Loading the module before the kernel boots fixes the problem temporarily. Any bells ringing or patch suggestions? Seeing this on 9-stable, also believed that the same issue exists with 10-current. Something is doing a duplicate resource_list_add() for the same RID. The trace will tell you where the second resource_list_add() is occurring. Some tracing should let you see where the first one occurs. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thinkpad T410: resume broken
On 5/16/14, 2:10 PM, Kevin Oberman wrote: On Fri, May 16, 2014 at 10:44 AM, Adrian Chadd adr...@freebsd.org wrote: Hi! I wonder what changed between 9.2-RELEASE and 10.0-RELEASE. Please poke me about this next week. I'm busy this week with work and maker faire but I will try to help you later. (It's possible something like ACPI updates or a driver update has broken things.) -a Does your kernel include VESA? My T320 behaved as you describe until I removed VESA from my kernel. I think using vt may also fix this without the need to remove VESA, bug I have not gotten around to confirming this. To be clear, vt does not fix resume. Using i915kms is what actually fixes resume when using Intel GPUs on the Thinkpad as i915kms is what actually turns the LCD backlight on during resume. You just have to use vt to have a useable console when you use i915kms. You can suspend/resume fine in X with syscons + i915kms, you just can't use your console if you do. If you are using the Nvidia GPU, then i915kms can't help you with turning the LCD backlight back on (and using vt shouldn't make any difference). VESA needs to be removed for i915kms, but I've no idea if it needs to be removed for Nvidia. The video reset code was reworked in 10 so that having VESA is supposed to be like using 'hw.acpi.reset_video=1' on 9, but in theory it works more often. The ACPI_PM setting to the kernel module along with removing VESA would seem like your best bet, but I see in follow-ups that that wasn't completely reliable. However, you can try using ACPI_PM with syscons, no need to use vt. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ARM i.MX6 based Utilitie-Pro board supported?
On Sat, 2014-05-17 at 10:50 +0200, O. Hartmann wrote: I'm looking for a smart FreeBSD Router/Gateway solution based upon the ARM architecture. One of the necessities ist the existence of two GBit NICs which are hard to find on most experimental ARM platforms today combinded with at least two CPU cores. I found the Utilities Pro board [1], four cores, two GBit NICs and WiFi along with 2GB RAM and I was wondering whether this board is supported by FreeBSD. I couldn't find anything useful since I'm a novice with ARM CPU naming and Utilities Pro is not mentioned in the list of compatible and supported ARM based equipment in [2]. Well, not being mentioned doesn't mean not supported since the components have to be supported anyway, but as I said, I do not know what Utilities Pro equipt to their solution. maybe someon of the FreeBSd users already made some experiences with this board/solution. Thanks in advance, Oliver [1] http://utilite-computer.com/web/utilite-pro-specifications [2] https://wiki.freebsd.org/FreeBSD/arm It is partially supported, in that freebsd should be able to boot and run on the Utilite box (I'm not sure anyone has done it yet). But for your needs, we don't have all the support yet -- there is no driver for the wifi chip, and nobody has worked on PCIe yet so the second nic won't work right now. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
zdb -m : Assertion failed: (tq-tq_freelist != NULL)
zdb -m crashed for me today, here's some details in case its a new problem. The errors on disk4 were fixed during the last scrub but I guess that could be related and I'll retry after that drive is replaced. % uname -a FreeBSD darkstor 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r265941: Mon May 12 22:57:13 CDT 2014 root@darkstor:/usr/obj/usr/src/sys/GENERIC amd64 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 7 cache gpt/larc5ONLINE 0 0 0 root@darkstor:~ # zdb -m tank Metaslabs: vdev 0 metaslabs 187 offsetspacemap free --- --- --- - metaslab 0 offset0 spacemap 36 free4.78G metaslab 1 offset8 spacemap136 free12.3G metaslab 2 offset 10 spacemap138 free1.59G metaslab 3 offset 18 spacemap145 free1.25G metaslab 4 offset 20 spacemap147 free7.54G metaslab 5 offset 28 spacemap149 free5.59G metaslab 6 offset 30 spacemap157 free1.33G metaslab 7 offset 38 spacemap158 free1.31G metaslab 8 offset 40 spacemap161 free1.19G metaslab 9 offset 48 spacemap200 free1.40G metaslab 10 offset 50 spacemap203 free7.89G metaslab 11 offset 58 spacemap214 free11.0G metaslab 12 offset 60 spacemap 93606 free7.18G metaslab 13 offset 68 spacemap 4128 free3.38G metaslab 14 offset 70 spacemap 4337 free1.43G metaslab 15 offset 78 spacemap 4992 free7.58G metaslab 16 offset 80 spacemap 5102 free7.38G metaslab 17 offset 88 spacemap 8520 free1.20G metaslab 18 offset 90 spacemap 102401 free5.75G metaslab 19 offset 98 spacemap 90113 free1.29G metaslab 20 offset a0 spacemap 20483 free1.53G metaslab 21 offset a8 spacemap 20591 free1.32G metaslab 22 offset b0 spacemap 28996 free1.29G metaslab 23 offset b8 spacemap 37284 free1.57G metaslab 24 offset c0 spacemap 37286 free 9.6G metaslab 25 offset c8 spacemap 37361 free6.96G metaslab 26 offset d0 spacemap 41470 free1.33G metaslab 27 offset d8 spacemap 41473 free1.14G metaslab 28 offset e0 spacemap 41475 free1.26G metaslab 29 offset e8 spacemap 41477 free 953M metaslab 30 offset f0 spacemap 41491 free1.16G metaslab 31 offset f8 spacemap 41494 free1.22G metaslab 32 offset 100 spacemap 41497 free 955M metaslab 33 offset 108 spacemap 41499 free1.06G metaslab 34 offset 110 spacemap 41502 free1.27G metaslab 35 offset 118 spacemap 41505 free1.27G metaslab 36 offset 120 spacemap 35 free13.1G metaslab 37 offset 128 spacemap135 free1.57G metaslab 38 offset 130 spacemap137 free13.1G metaslab 39 offset 138 spacemap139 free1.34G metaslab 40 offset 140 spacemap146 free1.13G metaslab 41 offset 148 spacemap159 free7.70G metaslab 42 offset 150 spacemap160 free8.37G metaslab 43 offset 158 spacemap181 free12.3G metaslab 44 offset 160 spacemap179 free6.54G metaslab 45 offset 168 spacemap 4098 free 987M metaslab 46 offset 170 spacemap 4126 free1.10G metaslab 47 offset 178 spacemap 4336 free1.27G metaslab 48 offset 180 spacemap 4127 free12.6G metaslab
Re: r266298: make buildworld fail: fatal error: 'llvm/ADT/APFloat.h' file not found #include llvm/ADT/APFloat.h
On 17 May 2014, at 13:35, Dimitry Andric d...@freebsd.org wrote: On 17 May 2014, at 10:11, O. Hartmann ohart...@zedat.fu-berlin.de wrote: With 11.0-CURRENT's sources (r266298) buildworld fails: [...] /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15:10: fatal error: 'llvm/ADT/APFloat.h' file not found #include llvm/ADT/APFloat.h ^ 1 error generated. /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cpp:16:10: fatal error: 'llvm/ADT/APInt.h' file not found #include llvm/ADT/APInt.h Can you please post your make.conf and src.conf? Actually, this is caused by r266278, but I'm not sure why, yet. Investigating... -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: newcons and beeping X
Hello, as of FreeBSD 10.0-STABLE #0 r266216 I still have a mute console in X (which isn't surprising, as there was no MFC) -- View this message in context: http://freebsd.1045724.n5.nabble.com/newcons-and-beeping-X-tp5906883p5913086.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Booting from ZFS root on MBR layout fails on ThinkPad X61s
On 2 May 2014 12:14, Sevan / Venture37 ventur...@gmail.com wrote: On 23 April 2014 21:54, Allan Jude free...@allanjude.com wrote: If anyone who is having trouble getting ZFS booting on one of these Lenovos is going to be at BSDCan, and has a spare disk they are willing to let me hack on, I would be interested in trying to get it booting for you so we can develop a solution to this issue if there is one. I am under the impression the issue is the way gpart does the MBR (or pMBR) with respect to the 'active' flag, but there are a number of different things i'd like to try. It all works flawlessly on my T530 I'll be at BSDCan with the laptop, you can see what's up for yourself. :) For archaeological reasons, the X61s was able to boot using ZFS on a BSD partition scheme (Thanks to Allen), the system can also boot from a ZFS volume with a MBR partition scheme if you *do not* use the stock FreeBSD boot loader switch to GRUB, this was tested by doing a stock install of PCBSD 10.0-RELEASE. Sevan / Venture37 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thinkpad T410: resume broken
On 17.05.2014 14:20, John Baldwin wrote: On 5/16/14, 2:10 PM, Kevin Oberman wrote: On Fri, May 16, 2014 at 10:44 AM, Adrian Chadd adr...@freebsd.org wrote: Hi! I wonder what changed between 9.2-RELEASE and 10.0-RELEASE. Please poke me about this next week. I'm busy this week with work and maker faire but I will try to help you later. (It's possible something like ACPI updates or a driver update has broken things.) -a Does your kernel include VESA? My T320 behaved as you describe until I removed VESA from my kernel. I think using vt may also fix this without the need to remove VESA, bug I have not gotten around to confirming this. To be clear, vt does not fix resume. Using i915kms is what actually fixes resume when using Intel GPUs on the Thinkpad as i915kms is what actually turns the LCD backlight on during resume. You just have to use vt to have a useable console when you use i915kms. You can suspend/resume fine in X with syscons + i915kms, you just can't use your console if you do. If you are using the Nvidia GPU, then i915kms can't help you with turning the LCD backlight back on (and using vt shouldn't make any difference). VESA needs to be removed for i915kms, but I've no idea if it needs to be removed for Nvidia. The video reset code was reworked in 10 so that having VESA is supposed to be like using 'hw.acpi.reset_video=1' on 9, but in theory it works more often. The ACPI_PM setting to the kernel module along with removing VESA would seem like your best bet, but I see in follow-ups that that wasn't completely reliable. However, you can try using ACPI_PM with syscons, no need to use vt. I'm using nvidia graphics. Removing VESA with syscons actually worked today. ACPI_PM for the module isn't necessary, but doesn't seem to hurt either. Now it seems to work like in 9.2-RELEASE. Also, no hangs so far. I'm pretty sure I tested that setup yesterday without success. So either there was something wrong in yesterday's test or I changed something else in the meantime. Suspending when Xorg is not running still results in a black monitor after resume. But I'm not really sure if I've tried that in 9.2-RELEASE. -- Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
