Re: Thinkpad T410: resume broken
On Friday, February 19, 2016 06:38:27 PM Alexey Dokuchaev wrote:
> On Thu, Feb 18, 2016 at 09:51:08AM -0800, John Baldwin wrote:
> > On Thursday, February 18, 2016 10:56:29 PM Alexey Dokuchaev wrote:
> > > # pciconf -lc pci0:0:0
> > > hostb0@pci0:0:0:0: class=0x06 card=0x83191033 chip=0x25908086
> > > rev=0x04 hdr=0x00
> > > cap 09[e0] = vendor (length 9) Intel cap 2 version 1
> >
> > Humm, perhaps PCI0 is not at 0:0. Can you find the _ADR method for
> > _SB_.PCI0? That contains the "slot" and "function" as two words, e.g.
> > 0x10002 would correspond to the 'pci0:1:2' device (or possibly pci0:2:1,
> > don't recall the order off the top of my head).
>
> Seems it's all zeros:
>
> Device (PCI0)
> {
> ...
> Name (_ADR, 0x00) // _ADR: Address
>
> I've uploaded the dump on freefall [1], perhaps I've missed something so
> you can have a better/sharper look.
Ok, so your BIOS is just odd / broken. It's asked us to power that device
down to D2, but it doesn't support any power management at all, so we whine.
In practice it should be harmless and something you can ignore.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thinkpad T410: resume broken
On 18/02/2016 16:47, Alexey Dokuchaev wrote: > On a related note, how does one configure sc(4) with old drm (vs. > drm2) shall I need to try that? Hi! xf86-video-intel and xf86-video-ati do not handle modesetting for a long time now (almost three years), so they can't be used with the old "drm" (only "drm2"). We don't have xf86-video-nouveau for the same reason. You can't use older versions of those xf86-video-* (ie. those doing user modesetting) because they are not supported anymore by the X.Org server. That was the whole WITH_NEW_XORG drama. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Thinkpad T410: resume broken
On Thu, Feb 18, 2016 at 09:51:08AM -0800, John Baldwin wrote:
> On Thursday, February 18, 2016 10:56:29 PM Alexey Dokuchaev wrote:
> > # pciconf -lc pci0:0:0
> > hostb0@pci0:0:0:0: class=0x06 card=0x83191033 chip=0x25908086
> > rev=0x04 hdr=0x00
> > cap 09[e0] = vendor (length 9) Intel cap 2 version 1
>
> Humm, perhaps PCI0 is not at 0:0. Can you find the _ADR method for
> _SB_.PCI0? That contains the "slot" and "function" as two words, e.g.
> 0x10002 would correspond to the 'pci0:1:2' device (or possibly pci0:2:1,
> don't recall the order off the top of my head).
Seems it's all zeros:
Device (PCI0)
{
...
Name (_ADR, 0x00) // _ADR: Address
I've uploaded the dump on freefall [1], perhaps I've missed something so
you can have a better/sharper look.
./danfe
[1] http://people.freebsd.org/~danfe/nec_versa_s950.asl
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thinkpad T410: resume broken
On Thu, Feb 18, 2016 at 10:02:17AM -0800, Adrian Chadd wrote: > [snip] > > Someone should sit me down with pizza and "help" me just modularise > the vesa/fb code so we can use it in vt. > > It isn't /that/ hard, I've just been preoccupied. And before it happens, someone(tm) could write a few paragraphs of current state of affairs and codependencies between sc(4), vt(4), and VESA. :-) Hopefully this would lower the degree of "black magic" surrounding this code and help with some [1] related PRs. ./danfe [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174504 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thinkpad T410: resume broken
On Thu, Feb 18, 2016 at 09:48:40AM -0800, John Baldwin wrote: > On Thursday, February 18, 2016 09:47:12 PM Alexey Dokuchaev wrote: > > On Thu, Feb 18, 2016 at 06:50:34AM -0800, John Baldwin wrote: > > > On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote: > > > vesa.ko shouldn't be working with KMS. KMS turns off the legacy VGA > > > emulation in the hardware when it starts which prevents VESA from > > > working (VESA requires the legacy VGA interface). > > > > Hmm, could this explain why vesa.ko can be loaded from loader.conf, but > > not via kldload(8)? OTOH, kldload'ing it later does not seem to work > > (ir)regardless of whether i915kms.ko is loaded or not... > > You might load it from loader.conf but it might then fail with an error > about failing to register in dmesg. In that case it is effectively > ignored. By "can be loaded from loader.conf" I mean that it's reported in kldstat(8) output. I'm still unsure if I understand all implications of having or not having VESA kernel option or vesa.ko loaded in vt(4)+KMS world. E.g., do I understand correctly that vesa.ko is not needed (or might even cause certain problems) with vt(4)+KMS, and "options VESA" is left in GENERIC as part of syscons(4) support, and will likely go south together with syscons(4) some day? > > I'm about to try fresh -CURRENT on some HP AMD APU-based laptops, hence > > I'll ask: do [Intel or Radeon graphics] laptops suspend/resume without > > issues in X11 or on the naked console as well? (In a shop, I could only > > quickly test our X11-less memstick image.) > > Once KMS is loaded they resume fine. They require the KMS driver to turn > the LCD panel back on. Without KMS they also "resume" but the screen is off > so you can't see anything. However, you can type blind and run commands. > If the network is up you can ssh into the laptop, etc. after resume. > [...] > On HEAD you need to set kern.vty=sc to use sc(4) instead of vt(4). For > suspend/resume without X that should be sufficient. You would only need > the old drm drivers for X. > [...] > Note that for the HP netbook, resume in console with vt(4) does not work > without KMS (due to vt(4) not supporting VESA). OK I see, makes sense. So my best bet would be to try suspend/resume with vt(4)+KMS, then if it fails try with kern.vty=sc (in the context of GENERIC kernel and pure console). ./danfe ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thinkpad T410: resume broken
[snip] Someone should sit me down with pizza and "help" me just modularise the vesa/fb code so we can use it in vt. It isn't /that/ hard, I've just been preoccupied. -a ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thinkpad T410: resume broken
On Thursday, February 18, 2016 10:56:29 PM Alexey Dokuchaev wrote:
> On Thu, Feb 18, 2016 at 06:55:03AM -0800, John Baldwin wrote:
> > On Thursday, February 18, 2016 08:37:38 PM Alexey Dokuchaev wrote:
> > > I've started to observe similar lines in the logs after updating to
> > > fresh -CURRENT, upon resume (on a different laptop though, not T410):
> > >
> > > pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER
> > > acpi0: cleared fixed power button status
> > >
> > > If these messages are legit, I'm wondering why I didn't see them on 8.4,
> > > and if it might affect suspend/resume sequence (broken right now)?
> >
> > [...] Your BIOS said "please put this device in D2 during suspend" and your
> > device's capabilities said "I don't support D2". You can confirm this by
> > looking up the _S3 method of your _SB_.PCIO device to find out what state is
> > requested during suspend and then looking at 'pciconf -lc pci0:0:0' to see
> > what D states are listed as supported.
>
> This?:
>
> Scope (\_SB)
> {
> Name (ECOK, 0x00)
> Device (PCI0)
> {
> Method (_S3D, 0, NotSerialized) // _S3D: S3 Device State
> {
> Return (0x02)
> }
> ...
Yes, this says "please use D2 when going to S3".
> # pciconf -lc pci0:0:0
> hostb0@pci0:0:0:0: class=0x06 card=0x83191033 chip=0x25908086
> rev=0x04 hdr=0x00
> cap 09[e0] = vendor (length 9) Intel cap 2 version 1
Humm, perhaps PCI0 is not at 0:0. Can you find the _ADR method for _SB_.PCI0?
That contains the "slot" and "function" as two words, e.g. 0x10002 would
correspond to the 'pci0:1:2' device (or possibly pci0:2:1, don't recall the
order off the top of my head).
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thinkpad T410: resume broken
On Thursday, February 18, 2016 09:47:12 PM Alexey Dokuchaev wrote: > On Thu, Feb 18, 2016 at 06:50:34AM -0800, John Baldwin wrote: > > On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote: > > vesa.ko shouldn't be working with KMS. KMS turns off the legacy VGA > > emulation in the hardware when it starts which prevents VESA from working > > (VESA requires the legacy VGA interface). > > Hmm, could this explain why vesa.ko can be loaded from loader.conf, but > not via kldload(8)? OTOH, kldload'ing it later does not seem to work > (ir)regardless of whether i915kms.ko is loaded or not... You might load it from loader.conf but it might then fail with an error about failing to register in dmesg. In that case it is effectively ignored. > > I never have to hit the power button more than once to resume on a laptop > > where resume works though. > > > > (True on my X220 and on a T440 both with Intel or Radeon graphics (all > > using KMS). > > I'm about to try fresh -CURRENT on some HP AMD APU-based laptops, hence > I'll ask: do aforementioned laptops suspend/resume without issues in X11 > or on the naked console as well? (In a shop, I could only quickly test > our X11-less memstick image.) Once KMS is loaded they resume fine. They require the KMS driver to turn the LCD panel back on. Without KMS they also "resume" but the screen is off so you can't see anything. However, you can type blind and run commands. If the network is up you can ssh into the laptop, etc. after resume. > > > Needless to say, suspend/resume worked nearly flawlessly under stable/8 > > > and stable/7 FWIW. > > > > If it worked here, then this means you could try using sc(4) + the old drm > > (not drm2). This means your laptop is old enough to still turn the LCD > > panel > > back on in its BIOS during resume like my HP netbook. However, I don't know > > for how much longer Xorg will support the older drm (if it even does now). > > Well, technically, my laptop *does* resume with vt(4) + i915kms, just it > takes a lot of power button hits and quite some time (up to several minutes), > unless it dies somewhere during the process. I'll retest it against > GENERIC and report in a separate email. On a related note, how does one > configure sc(4) with old drm (vs. drm2) shall I need to try that? On HEAD you need to set kern.vty=sc to use sc(4) instead of vt(4). For suspend/resume without X that should be sufficient. You would only need the old drm drivers for X. > > FWIW, the HP netbook resumes fine with KMS as well for me. One caveat > > though is that if you are using vt(4) and haven't yet loaded KMS it won't > > resume (due to vt(4) not having the equivalent of VESA). With sc(4) the > > netbook was always able to resume. > > Right. So far, I've been booting, kldloading i915kms.ko, zzz(8), resume. > No X.Org was involved -- given how fragile suspend/resume is ATM, I'd like > to iron out the issues with the pure console first. Note that for the HP netbook, resume in console with vt(4) does not work without KMS (due to vt(4) not supporting VESA). -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thinkpad T410: resume broken
On Thu, Feb 18, 2016 at 06:55:03AM -0800, John Baldwin wrote:
> On Thursday, February 18, 2016 08:37:38 PM Alexey Dokuchaev wrote:
> > I've started to observe similar lines in the logs after updating to
> > fresh -CURRENT, upon resume (on a different laptop though, not T410):
> >
> > pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER
> > acpi0: cleared fixed power button status
> >
> > If these messages are legit, I'm wondering why I didn't see them on 8.4,
> > and if it might affect suspend/resume sequence (broken right now)?
>
> [...] Your BIOS said "please put this device in D2 during suspend" and your
> device's capabilities said "I don't support D2". You can confirm this by
> looking up the _S3 method of your _SB_.PCIO device to find out what state is
> requested during suspend and then looking at 'pciconf -lc pci0:0:0' to see
> what D states are listed as supported.
This?:
Scope (\_SB)
{
Name (ECOK, 0x00)
Device (PCI0)
{
Method (_S3D, 0, NotSerialized) // _S3D: S3 Device State
{
Return (0x02)
}
...
# pciconf -lc pci0:0:0
hostb0@pci0:0:0:0: class=0x06 card=0x83191033 chip=0x25908086 rev=0x04
hdr=0x00
cap 09[e0] = vendor (length 9) Intel cap 2 version 1
# pciconf -rb pci0:0:0 0xe0:0xff
09 00 09 21 02 a2 8b 90 0a 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 05 00 10 00 00 00
> There's not much we can do if your BIOS lies to us.
As long as we can patch ACPI tables, lying BIOS should not be a problem, no?
./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thinkpad T410: resume broken
On Thu, Feb 18, 2016 at 06:50:34AM -0800, John Baldwin wrote: > On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote: > > On Sat, May 17, 2014 at 08:20:03AM -0400, John Baldwin wrote: > > > 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. > > > > This (VESA needs to be removed for i915kms) is news to me: I don't see it > > mentioned in UPDATING, and "options VESA" presents in -CURRENT's (post-KMS > > era) GENERIC kernel config. So what's the real deal here? :-) > > This is an old mail you are responding to. You no longer need to remove > VESA for kms. Ah OK, that would explain it, thanks. > vesa.ko shouldn't be working with KMS. KMS turns off the legacy VGA > emulation in the hardware when it starts which prevents VESA from working > (VESA requires the legacy VGA interface). Hmm, could this explain why vesa.ko can be loaded from loader.conf, but not via kldload(8)? OTOH, kldload'ing it later does not seem to work (ir)regardless of whether i915kms.ko is loaded or not... > I never have to hit the power button more than once to resume on a laptop > where resume works though. > > (True on my X220 and on a T440 both with Intel or Radeon graphics (all > using KMS). I'm about to try fresh -CURRENT on some HP AMD APU-based laptops, hence I'll ask: do aforementioned laptops suspend/resume without issues in X11 or on the naked console as well? (In a shop, I could only quickly test our X11-less memstick image.) > > Needless to say, suspend/resume worked nearly flawlessly under stable/8 > > and stable/7 FWIW. > > If it worked here, then this means you could try using sc(4) + the old drm > (not drm2). This means your laptop is old enough to still turn the LCD panel > back on in its BIOS during resume like my HP netbook. However, I don't know > for how much longer Xorg will support the older drm (if it even does now). Well, technically, my laptop *does* resume with vt(4) + i915kms, just it takes a lot of power button hits and quite some time (up to several minutes), unless it dies somewhere during the process. I'll retest it against GENERIC and report in a separate email. On a related note, how does one configure sc(4) with old drm (vs. drm2) shall I need to try that? > FWIW, the HP netbook resumes fine with KMS as well for me. One caveat > though is that if you are using vt(4) and haven't yet loaded KMS it won't > resume (due to vt(4) not having the equivalent of VESA). With sc(4) the > netbook was always able to resume. Right. So far, I've been booting, kldloading i915kms.ko, zzz(8), resume. No X.Org was involved -- given how fragile suspend/resume is ATM, I'd like to iron out the issues with the pure console first. ./danfe ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thinkpad T410: resume broken
On Fri, May 23, 2014 at 10:00:30AM -0400, John Baldwin wrote: > On Wednesday, May 21, 2014 3:43:49 pm Jan Henrik Sylvester wrote: > > Looking through dmesg, it seems that other USB devices (build-in) are > > reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after > > resume, just not the mouse. > > > > Are these lines likely related? > > > > 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 > > These are probably not related. These man that your BIOS explicitly told > the OS to power down these devices (PEG_ is probably your GPU, and EXP[1-5] > are probably PCI-PCI bridges that represent the downstream ports of your > PCI-e root complex) in the D2 state when suspending, but the devices don't > actually support D2 (most PCI devices only support D0 (full on) and D3 > (full off)). I've started to observe similar lines in the logs after updating to fresh -CURRENT, upon resume (on a different laptop though, not T410): pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER acpi0: cleared fixed power button status If these messages are legit, I'm wondering why I didn't see them on 8.4, and if it might affect suspend/resume sequence (broken right now)? Thanks, ./danfe ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thinkpad T410: resume broken
On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote: > On Sat, May 17, 2014 at 08:20:03AM -0400, John Baldwin wrote: > > 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. > > This (VESA needs to be removed for i915kms) is news to me: I don't see it > mentioned in UPDATING, and "options VESA" presents in -CURRENT's (post-KMS > era) GENERIC kernel config. So what's the real deal here? :-) This is an old mail you are responding to. You no longer need to remove VESA for kms. > If "having VESA is supposed to be like using 'hw.acpi.reset_video=1' on > 9", it should not hurt (I recall having to hw.acpi.reset_video=1 in early > stable/[67] days, but no longer for quite a long time with stable/8). > > Admittedly, the whole situation with i915kms, vesa.ko, et al. looks quite > confusing, while suspend/resume works *worse* than with stable/8 and pre- > KMS. Table of known laptops on wiki page [1] is hardly helpful unless it > has your laptop of interest; IMHO it would benefit a lot more from listing > common symptoms and mitigation/fixes for them (including VESA, sysctl vars, > kernel options, etc). The value of "worse" depends on your laptop. I have an older i386 HP netbook for which resume works fine using sc(4) and the older DRM drivers because the video BIOS turns the LCD back on during resume without requiring the OS to do so. However, the recent GPU chipsets from Intel do not do that and the only bit of code in the tree that knows how to turn the LCD panel back on is the KMS driver. However, note that KMS is not related to NVidia GPUs. If your laptop is using one of those then the nvidia driver is what has to turn the LCD panel back on. > > 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. > > What are indications for use of ACPI_PM option? As for removing VESA, > I've found that my laptop resumes more willingly with i915kms.ko *and* > vesa.ko than without vesa.ko (could only? be loaded from loader.conf): > with both modules loaded it takes only three presses of power button to > get back from suspend, while without vesa.ko it's a lottery, and often > power-cycling is required to get things back to working -- any ideas on > why would that be? vesa.ko shouldn't be working with KMS. KMS turns off the legacy VGA emulation in the hardware when it starts which prevents VESA from working (VESA requires the legacy VGA interface). I never have to hit the power button more than once to resume on a laptop where resume works though. (True on my X220 and on a T440 both with Intel or Radeon graphics (all using KMS). > Needless to say, suspend/resume worked nearly flawlessly under stable/8 > and stable/7 FWIW. If it worked here, then this means you could try using sc(4) + the old drm (not drm2). This means your laptop is old enough to still turn the LCD panel back on in its BIOS during resume like my HP netbook. However, I don't know for how much longer Xorg will support the older drm (if it even does now). FWIW, the HP netbook resumes fine with KMS as well for me. One caveat though is that if you are using vt(4) and haven't yet loaded KMS it won't resume (due to vt(4) not having the equivalent of VESA). With sc(4) the netbook was always able to resume. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thinkpad T410: resume broken
On Thursday, February 18, 2016 08:37:38 PM Alexey Dokuchaev wrote: > On Fri, May 23, 2014 at 10:00:30AM -0400, John Baldwin wrote: > > On Wednesday, May 21, 2014 3:43:49 pm Jan Henrik Sylvester wrote: > > > Looking through dmesg, it seems that other USB devices (build-in) are > > > reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after > > > resume, just not the mouse. > > > > > > Are these lines likely related? > > > > > > 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 > > > > These are probably not related. These man that your BIOS explicitly told > > the OS to power down these devices (PEG_ is probably your GPU, and EXP[1-5] > > are probably PCI-PCI bridges that represent the downstream ports of your > > PCI-e root complex) in the D2 state when suspending, but the devices don't > > actually support D2 (most PCI devices only support D0 (full on) and D3 > > (full off)). > > I've started to observe similar lines in the logs after updating to fresh > -CURRENT, upon resume (on a different laptop though, not T410): > > pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER > acpi0: cleared fixed power button status > > If these messages are legit, I'm wondering why I didn't see them on 8.4, > and if it might affect suspend/resume sequence (broken right now)? Thanks, 8.4 has a bug fixed only in HEAD where we tried to power down the wrong devices during suspend (or used the _Sx hint from the wrong device to decide which Dx state to use when powering down, I can't recall which). For this reason, 11 is going to use different Dx states on different devices. The reason for the message remains the same (though it should now be correct on 11). Your BIOS said "please put this device in D2 during suspend" and your device's capabilites said "I don't support D2". You can confirm this by looking up the _S3 method of your _SB_.PCIO device to find out what state is requested during suspend and then looking at 'pciconf -lc pci0:0:0' to see what D states are listed as supported. There's not much we can do if your BIOS lies to us. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Thinkpad T410: resume broken
On 21.05.2014 21:43, Jan Henrik Sylvester wrote: On 05/21/2014 21:22, Hans Petter Selasky wrote: On 05/21/14 21:16, Jan Henrik Sylvester wrote: Unfortunately, my USB mouse does not work anymore: After the first resume, it took a few seconds until it worked again (the build in touchpad was back immediately). After the second resume, it would not work anymore at all, even after reconnecting it to a different EHCI port. It does work at a XHCI, though, until the next resume. Anyhow, this is obviously not related to the original problem. Hi, USB controller are being reset at resume, so I think this indicates a more fundamental PCI/BUS problem. Looking through dmesg, it seems that other USB devices (build-in) are reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after resume, just not the mouse. I can confirm this behavior. It already happened on 9.x. Devices plugged into the USB ports are not even powered. It's not just mouse, also USB hard disks for instance. Are these lines likely related? 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 I don't remember seeing these lines in 9.x. That doesn't necessarily mean they are not related. -- 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
Re: Thinkpad T410: resume broken
On Wednesday, May 21, 2014 3:43:49 pm Jan Henrik Sylvester wrote: On 05/21/2014 21:22, Hans Petter Selasky wrote: On 05/21/14 21:16, Jan Henrik Sylvester wrote: Unfortunately, my USB mouse does not work anymore: After the first resume, it took a few seconds until it worked again (the build in touchpad was back immediately). After the second resume, it would not work anymore at all, even after reconnecting it to a different EHCI port. It does work at a XHCI, though, until the next resume. Anyhow, this is obviously not related to the original problem. Hi, USB controller are being reset at resume, so I think this indicates a more fundamental PCI/BUS problem. Looking through dmesg, it seems that other USB devices (build-in) are reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after resume, just not the mouse. Are these lines likely related? 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 These are probably not related. These man that your BIOS explicitly told the OS to power down these devices (PEG_ is probably your GPU, and EXP[1-5] are probably PCI-PCI bridges that represent the downstream ports of your PCI-e root complex) in the D2 state when suspending, but the devices don't actually support D2 (most PCI devices only support D0 (full on) and D3 (full off)). -- 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 Wed, May 21, 2014 at 12:43 PM, Jan Henrik Sylvester m...@janh.de wrote: On 05/21/2014 21:22, Hans Petter Selasky wrote: On 05/21/14 21:16, Jan Henrik Sylvester wrote: Unfortunately, my USB mouse does not work anymore: After the first resume, it took a few seconds until it worked again (the build in touchpad was back immediately). After the second resume, it would not work anymore at all, even after reconnecting it to a different EHCI port. It does work at a XHCI, though, until the next resume. Anyhow, this is obviously not related to the original problem. Hi, USB controller are being reset at resume, so I think this indicates a more fundamental PCI/BUS problem. Looking through dmesg, it seems that other USB devices (build-in) are reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after resume, just not the mouse. Are these lines likely related? 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 Thanks, Jan Henrik Could this be another face of the problems that requires kbdmux to keep the USB keyboard working correctly with vt(4)? -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.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: Re: Thinkpad T410: resume broken
On 05/17/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. Yes, without VESA, resume seems much more reliable on 10.0-RELEASE/amd64 with Nvidia: With a generic kernel, I put vesa_load=YES in /boot/loader.conf to be able to kldunload vesa later. With that, I just had four successful suspend-and-resume cycles. Unfortunately, my USB mouse does not work anymore: After the first resume, it took a few seconds until it worked again (the build in touchpad was back immediately). After the second resume, it would not work anymore at all, even after reconnecting it to a different EHCI port. It does work at a XHCI, though, until the next resume. Anyhow, this is obviously not related to the original problem. Cheers, Jan Henrik ___ 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 05/21/14 21:16, Jan Henrik Sylvester wrote: Unfortunately, my USB mouse does not work anymore: After the first resume, it took a few seconds until it worked again (the build in touchpad was back immediately). After the second resume, it would not work anymore at all, even after reconnecting it to a different EHCI port. It does work at a XHCI, though, until the next resume. Anyhow, this is obviously not related to the original problem. Hi, USB controller are being reset at resume, so I think this indicates a more fundamental PCI/BUS problem. --HPS ___ 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 05/21/2014 21:22, Hans Petter Selasky wrote: On 05/21/14 21:16, Jan Henrik Sylvester wrote: Unfortunately, my USB mouse does not work anymore: After the first resume, it took a few seconds until it worked again (the build in touchpad was back immediately). After the second resume, it would not work anymore at all, even after reconnecting it to a different EHCI port. It does work at a XHCI, though, until the next resume. Anyhow, this is obviously not related to the original problem. Hi, USB controller are being reset at resume, so I think this indicates a more fundamental PCI/BUS problem. Looking through dmesg, it seems that other USB devices (build-in) are reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after resume, just not the mouse. Are these lines likely related? 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 Thanks, Jan Henrik ___ 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 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
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: 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
Thinkpad T410: resume broken
Suspend/Resume is broken on my T410 using CURRENT from today. Resume was working fine on 9.2-RELEASE. 10.0-RELEASE and 10-STABLE don't work either. Symptoms: acpiconf -s3 sends it into sleep mode as expected In single user mode, it wakes up correctly, but the screen remains black. I tried with/without nvidia module loaded. It also happens with debug.acpi.suspend_bounce=1. I've tried all tips from https://wiki.freebsd.org/SuspendResume to no avail. In multi-user mode (especially when X is running) it doesn't wake up correctly most of the time: It powers up and the fan starts, but keyboard is not responding. Also, the power led pulsates, as if still in sleep mode. -- 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
Re: Thinkpad T410: resume broken
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 On 16 May 2014 07:35, Stefan Ehmann shoes...@gmx.net wrote: Suspend/Resume is broken on my T410 using CURRENT from today. Resume was working fine on 9.2-RELEASE. 10.0-RELEASE and 10-STABLE don't work either. Symptoms: acpiconf -s3 sends it into sleep mode as expected In single user mode, it wakes up correctly, but the screen remains black. I tried with/without nvidia module loaded. It also happens with debug.acpi.suspend_bounce=1. I've tried all tips from https://wiki.freebsd.org/SuspendResume to no avail. In multi-user mode (especially when X is running) it doesn't wake up correctly most of the time: It powers up and the fan starts, but keyboard is not responding. Also, the power led pulsates, as if still in sleep mode. -- 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 ___ 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 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. On 16 May 2014 07:35, Stefan Ehmann shoes...@gmx.net wrote: Suspend/Resume is broken on my T410 using CURRENT from today. Resume was working fine on 9.2-RELEASE. 10.0-RELEASE and 10-STABLE don't work either. Symptoms: acpiconf -s3 sends it into sleep mode as expected In single user mode, it wakes up correctly, but the screen remains black. I tried with/without nvidia module loaded. It also happens with debug.acpi.suspend_bounce=1. I've tried all tips from https://wiki.freebsd.org/SuspendResume to no avail. In multi-user mode (especially when X is running) it doesn't wake up correctly most of the time: It powers up and the fan starts, but keyboard is not responding. Also, the power led pulsates, as if still in sleep mode. -- 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 ___ 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 -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.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: Thinkpad T410: resume broken
On 05/16/2014 20:10, 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. (Sorry, this is more or less a lengthy me, too:) I am observing exactly the same on my T510 (not surprisingly, as it is basically the same with a different screen size) using Nvidia (in contract to most other recent mailing list reports, which are using Intel). From 8.1-RELEASE to 9.2-RELEASE, suspend and resume used to work with a generic kernel (I like generic release kernels and freebsd-update) -- except for a short time, which was due to the Xorg port. Especially 9.X-RELEASE were really stable with all the hardware working after resume (maybe except firewire). After going to 10.0-RELEASE, resuming would briefly turn the screen on, but it would go back to black with the power LED continuing to blink (as it does while sleeping). After a while, I realized that I lost the non-default option ACPI_PM for x11/nvidia-driver installing 10.0. With ACPI_PM for x11/nvidia-driver, I had at least one resume with most of the hardware working: The screen was still unusable being static with colorful lines, but I could ssh into the machine over wireless. I have not had time to try 10-STABLE with vt, but from reading various reports on the lists, that is probably the only way. I hope there will be a vt enabled kernel on the 10.1-RELEAS media, if vt is going to be required even for configurations that would work just fine on 9.X (WITH_NEW_XORG=yes is very usable with x11/nvidia-driver even without vt). From what you said, you already have ACPI_PM for x11/nvidia-driver as it is listed on the wiki. Have you? Cheers, Jan Henrik ___ 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
Hi, Yeah. I'd really suggest trying with stable/10 or -HEAD with vt enabled and no VESA. -a On 16 May 2014 13:31, Jan Henrik Sylvester m...@janh.de wrote: On 05/16/2014 20:10, 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. (Sorry, this is more or less a lengthy me, too:) I am observing exactly the same on my T510 (not surprisingly, as it is basically the same with a different screen size) using Nvidia (in contract to most other recent mailing list reports, which are using Intel). From 8.1-RELEASE to 9.2-RELEASE, suspend and resume used to work with a generic kernel (I like generic release kernels and freebsd-update) -- except for a short time, which was due to the Xorg port. Especially 9.X-RELEASE were really stable with all the hardware working after resume (maybe except firewire). After going to 10.0-RELEASE, resuming would briefly turn the screen on, but it would go back to black with the power LED continuing to blink (as it does while sleeping). After a while, I realized that I lost the non-default option ACPI_PM for x11/nvidia-driver installing 10.0. With ACPI_PM for x11/nvidia-driver, I had at least one resume with most of the hardware working: The screen was still unusable being static with colorful lines, but I could ssh into the machine over wireless. I have not had time to try 10-STABLE with vt, but from reading various reports on the lists, that is probably the only way. I hope there will be a vt enabled kernel on the 10.1-RELEAS media, if vt is going to be required even for configurations that would work just fine on 9.X (WITH_NEW_XORG=yes is very usable with x11/nvidia-driver even without vt). From what you said, you already have ACPI_PM for x11/nvidia-driver as it is listed on the wiki. Have you? Cheers, Jan Henrik ___ 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 16.05.2014 22:51, Adrian Chadd wrote: Hi, Yeah. I'd really suggest trying with stable/10 or -HEAD with vt enabled and no VESA. Thanks for all replies. Using vt is definitely an improvement, but not perfect. (I've set hw.vga.textmode=1 because graphics mode is very slow. Don't know if that matters.) The text console still remains black if I try to resume from there. But there's some success suspending from X: Resume puts me back on the text console in a strange state, e.g., no text visible and a cursor blinking. After some time I can bring X back via CTRL-ALT-F9. Some of the graphics/fonts in X are garbled after resume. But it's still usuable. After that, also the virtual consoles work via CTRL-ALT-F1. But after a second resume, X was even more garbled and virtual consoles no longer worked. Setting ACPI_PM for x11/nvidia-driver doesn't seem to have any effects. -- 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
Re: Thinkpad T410: resume broken
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? Or connect it via ethernet and do a suspend/resume whilst logged in? -a On 16 May 2014 14:31, Stefan Ehmann shoes...@gmx.net wrote: On 16.05.2014 22:51, Adrian Chadd wrote: Hi, Yeah. I'd really suggest trying with stable/10 or -HEAD with vt enabled and no VESA. Thanks for all replies. Using vt is definitely an improvement, but not perfect. (I've set hw.vga.textmode=1 because graphics mode is very slow. Don't know if that matters.) The text console still remains black if I try to resume from there. But there's some success suspending from X: Resume puts me back on the text console in a strange state, e.g., no text visible and a cursor blinking. After some time I can bring X back via CTRL-ALT-F9. Some of the graphics/fonts in X are garbled after resume. But it's still usuable. After that, also the virtual consoles work via CTRL-ALT-F1. But after a second resume, X was even more garbled and virtual consoles no longer worked. Setting ACPI_PM for x11/nvidia-driver doesn't seem to have any effects. -- 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
