Re: suspend/resume regression
On Saturday, July 25, 2015 03:54:40 PM Kevin Oberman wrote: > John, > > I'm concerned that two issues may be getting conflated. > > The issue I thought we were looking at was the failure of some systems > (T520, X220, T430) to resume after a number of PCI enhancements were MFCed. > This is completely unrelated to the USB issue I was experiencing when > trying to test the problem on HEAD. The more I think about it, the more I > think that the USB "issue" is just how things need to work. Well, the USB thing could be smarter, but it's a bit of a PITA. What if you take the USB stick out, mess with it on another system, then plug it back in before resume? All the cached file data in the RAM of the resumed system would need to be invalidated, etc. However, I ended up copying a HEAD kernel onto my USB stick and seeing that I at least got the console back before it panic'd. This was sufficient to let me test the reversion patch via the USB stick (and would be sufficient for seeing if we can merge it again for 10.3). > The real issue is just resuming the system after r281874 was MFCed as a > part of 284034. No USB connected file systems are involved. I m happy to > see that it has been reverted for 10.2, but clearly, these changes are > needed down the line and I hope the issue can be resolved well before 11.0. > (This assumes a 10.3 before 11.0 happens next year.) So it works fine in 11.0 on my x220, and as other folks reported in the PR, so 11.0 is fine. It is also needed for PCI-e hotplug to work after resume (using out-of-tree patches for PCI-e hotplug that jmg@ has). If I merge it to 10.3 it won't be until I've verified that whatever I merge works on my x220 as well as the T440. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
On Wed, Jul 29, 2015 at 3:47 PM, Claude Buisson wrote: > On 07/29/2015 23:53, Kevin Oberman wrote: > >> On Wed, Jul 29, 2015 at 5:58 AM, Claude Buisson >> wrote: >> >> On 07/26/2015 00:54, Kevin Oberman wrote: >>> >>> John, I'm concerned that two issues may be getting conflated. The issue I thought we were looking at was the failure of some systems (T520, X220, T430) to resume after a number of PCI enhancements were MFCed. This is completely unrelated to the USB issue I was experiencing when trying to test the problem on HEAD. The more I think about it, the more I think that the USB "issue" is just how things need to work. Specifically, if you are booting a full, multi-user system from a USB connected drive, suspending and resuming will leave the system in an untenable condition that will force a panic. At least I don't see how the OS can determine that the disk present on resume is unchanged from that present when the system was suspended. Modern disk IDs greatly improve the situation, but I am unaware of any way to be sure that a removable drive (such as a USB) has not been removed and plugged into some other system that might have written to it. My knowledge of such things is very dated, going back to my days doing kernel programming about 25-30 year ago on VMS, so someone may have resolved the issue, but I don't understand exactly how. I guess that the risk might be low enough to just go ahead and pray that nobody did something really, really stupid like unplugging the drive, plugging it in elsewhere, and writing to it. The real issue is just resuming the system after r281874 was MFCed as a part of 284034. No USB connected file systems are involved. I m happy to see that it has been reverted for 10.2, but clearly, these changes are needed down the line and I hope the issue can be resolved well before 11.0. (This assumes a 10.3 before 11.0 happens next year.) I have done some tests on my T530 at r285668 and had some (good and >>> bad) >>> surprises: >>> >>> 0) historically i915kms+drm2 could not be loaded by loader.conf without >>> locking the machine, but needed to be loaded by rc.conf (kld_list). Now >>> these modules can be loaded by loader.conf. >>> >>> 1) resume does not work with a non patched kernel, but works when the >>> MFC of r281874 is reverted (i.e. r285863 applied) - in console mode (vt) >>> and X.org. >>> >>> 2) and now is my bad surprise: when i915kms+drm2+iic*+kbdmux are not >>> loaded at all, suspend works (in console mode of course), but not >>> resume, both with the nonpatched and the patched kernel. After resume >>> the screen keeps being black, but the system can be logged to with ssh, >>> but cannot be powered off nor rebooted from another system. Furthermore >>> the log shows unidentified _USB_ devices at resume (which never appeared >>> in any log before): >>> >>> Jul 29 12:28:12 watson devd: Executing '/etc/rc.suspend acpi 0x03' >>> Jul 29 12:28:12 watson acpi: suspend at 20150729 12:28:12 >>> Jul 29 12:28:37 watson kernel: uhub0: at usbus0, port 1, addr 1 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: uhub1: at usbus1, port 1, addr 1 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: ugen1.2: at usbus1 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: uhub4: at uhub1, port 1, addr 2 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: ugen1.3: >>> at usbus1 (disconnected) >>> Jul 29 12:28:37 watson kernel: uhub2: at usbus2, port 1, addr 1 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: ugen2.2: at usbus2 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: uhub3: at uhub2, port 1, addr 2 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: ugen2.3: at usbus2 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: ums0: at uhub3, port 5, addr 3 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: acpi0: cleared fixed power button status >>> Jul 29 12:28:37 watson kernel: em0: link state changed to DOWN >>> Jul 29 12:28:37 watson kernel: xhci0: Port routing mask set to 0x >>> Jul 29 12:28:37 watson kernel: uhub0: <0x8086 XHCI root HUB, class 9/0, >>> rev 3.00/1.00, addr 1> on usbus0 >>> Jul 29 12:28:37 watson kernel: uhub1: >> rev 2.00/1.00, addr 1> on usbus2 >>> Jul 29 12:28:37 watson kernel: uhub2: >> rev 2.00/1.00, addr 1> on usbus1 >>> Jul 29 12:28:38 watson kernel: uhub0: 8 ports with 8 removable, self >>> powered >>> Jul 29 12:28:37 watson devd: Executing '/etc/rc.resume acpi 0x03' >>> Jul 29 12:28:38 watson acpi: resumed at 20150729 12:28:38 >>> Jul 29 12:28:38 watson kernel: uhub2: 3 ports with 3 removable, self >>> powered >>> Jul 29 12:28:38 watson kernel: uhub1: 3 ports with 3 removable, self >>> powered >>> Jul 29 12:28:38 watson kernel: em0: link state changed to UP >>> Jul 29 12:28:38 watson devd: Executing '/etc/rc.d/dhclient quiets
Re: suspend/resume regression
On 07/29/2015 23:53, Kevin Oberman wrote: On Wed, Jul 29, 2015 at 5:58 AM, Claude Buisson wrote: On 07/26/2015 00:54, Kevin Oberman wrote: John, I'm concerned that two issues may be getting conflated. The issue I thought we were looking at was the failure of some systems (T520, X220, T430) to resume after a number of PCI enhancements were MFCed. This is completely unrelated to the USB issue I was experiencing when trying to test the problem on HEAD. The more I think about it, the more I think that the USB "issue" is just how things need to work. Specifically, if you are booting a full, multi-user system from a USB connected drive, suspending and resuming will leave the system in an untenable condition that will force a panic. At least I don't see how the OS can determine that the disk present on resume is unchanged from that present when the system was suspended. Modern disk IDs greatly improve the situation, but I am unaware of any way to be sure that a removable drive (such as a USB) has not been removed and plugged into some other system that might have written to it. My knowledge of such things is very dated, going back to my days doing kernel programming about 25-30 year ago on VMS, so someone may have resolved the issue, but I don't understand exactly how. I guess that the risk might be low enough to just go ahead and pray that nobody did something really, really stupid like unplugging the drive, plugging it in elsewhere, and writing to it. The real issue is just resuming the system after r281874 was MFCed as a part of 284034. No USB connected file systems are involved. I m happy to see that it has been reverted for 10.2, but clearly, these changes are needed down the line and I hope the issue can be resolved well before 11.0. (This assumes a 10.3 before 11.0 happens next year.) I have done some tests on my T530 at r285668 and had some (good and bad) surprises: 0) historically i915kms+drm2 could not be loaded by loader.conf without locking the machine, but needed to be loaded by rc.conf (kld_list). Now these modules can be loaded by loader.conf. 1) resume does not work with a non patched kernel, but works when the MFC of r281874 is reverted (i.e. r285863 applied) - in console mode (vt) and X.org. 2) and now is my bad surprise: when i915kms+drm2+iic*+kbdmux are not loaded at all, suspend works (in console mode of course), but not resume, both with the nonpatched and the patched kernel. After resume the screen keeps being black, but the system can be logged to with ssh, but cannot be powered off nor rebooted from another system. Furthermore the log shows unidentified _USB_ devices at resume (which never appeared in any log before): Jul 29 12:28:12 watson devd: Executing '/etc/rc.suspend acpi 0x03' Jul 29 12:28:12 watson acpi: suspend at 20150729 12:28:12 Jul 29 12:28:37 watson kernel: uhub0: at usbus0, port 1, addr 1 (disconnected) Jul 29 12:28:37 watson kernel: uhub1: at usbus1, port 1, addr 1 (disconnected) Jul 29 12:28:37 watson kernel: ugen1.2: at usbus1 (disconnected) Jul 29 12:28:37 watson kernel: uhub4: at uhub1, port 1, addr 2 (disconnected) Jul 29 12:28:37 watson kernel: ugen1.3: at usbus1 (disconnected) Jul 29 12:28:37 watson kernel: uhub2: at usbus2, port 1, addr 1 (disconnected) Jul 29 12:28:37 watson kernel: ugen2.2: at usbus2 (disconnected) Jul 29 12:28:37 watson kernel: uhub3: at uhub2, port 1, addr 2 (disconnected) Jul 29 12:28:37 watson kernel: ugen2.3: at usbus2 (disconnected) Jul 29 12:28:37 watson kernel: ums0: at uhub3, port 5, addr 3 (disconnected) Jul 29 12:28:37 watson kernel: acpi0: cleared fixed power button status Jul 29 12:28:37 watson kernel: em0: link state changed to DOWN Jul 29 12:28:37 watson kernel: xhci0: Port routing mask set to 0x Jul 29 12:28:37 watson kernel: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 Jul 29 12:28:37 watson kernel: uhub1: on usbus2 Jul 29 12:28:37 watson kernel: uhub2: on usbus1 Jul 29 12:28:38 watson kernel: uhub0: 8 ports with 8 removable, self powered Jul 29 12:28:37 watson devd: Executing '/etc/rc.resume acpi 0x03' Jul 29 12:28:38 watson acpi: resumed at 20150729 12:28:38 Jul 29 12:28:38 watson kernel: uhub2: 3 ports with 3 removable, self powered Jul 29 12:28:38 watson kernel: uhub1: 3 ports with 3 removable, self powered Jul 29 12:28:38 watson kernel: em0: link state changed to UP Jul 29 12:28:38 watson devd: Executing '/etc/rc.d/dhclient quietstart em0' Jul 29 12:28:39 watson kernel: ugen2.2: at usbus2 Jul 29 12:28:39 watson kernel: uhub3: on usbus2 Jul 29 12:28:39 watson kernel: ugen1.2: at usbus1 Jul 29 12:28:39 watson kernel: uhub4: on usbus1 Jul 29 12:28:40 watson kernel: uhub4: 6 ports with 6 removable, self powered Jul 29 12:28:41 watson kernel: uhub3: 8 ports with 8 removable, self powered Jul 29 12:28:41 watson kernel: ugen1.3: at usbus1 Jul 29 12:28:41 watson devd: Executing 'logger Unknown USB device: vendor 0x04f2 product 0xb2ea bus uhub4' Jul 29 12:28:41 watson
Re: suspend/resume regression
On Wed, Jul 29, 2015 at 5:58 AM, Claude Buisson wrote: > On 07/26/2015 00:54, Kevin Oberman wrote: > >> John, >> >> I'm concerned that two issues may be getting conflated. >> >> The issue I thought we were looking at was the failure of some systems >> (T520, X220, T430) to resume after a number of PCI enhancements were >> MFCed. >> This is completely unrelated to the USB issue I was experiencing when >> trying to test the problem on HEAD. The more I think about it, the more I >> think that the USB "issue" is just how things need to work. >> >> Specifically, if you are booting a full, multi-user system from a USB >> connected drive, suspending and resuming will leave the system in an >> untenable condition that will force a panic. At least I don't see how the >> OS can determine that the disk present on resume is unchanged from that >> present when the system was suspended. Modern disk IDs greatly improve the >> situation, but I am unaware of any way to be sure that a removable drive >> (such as a USB) has not been removed and plugged into some other system >> that might have written to it. My knowledge of such things is very dated, >> going back to my days doing kernel programming about 25-30 year ago on >> VMS, >> so someone may have resolved the issue, but I don't understand exactly >> how. >> I guess that the risk might be low enough to just go ahead and pray that >> nobody did something really, really stupid like unplugging the drive, >> plugging it in elsewhere, and writing to it. >> >> The real issue is just resuming the system after r281874 was MFCed as a >> part of 284034. No USB connected file systems are involved. I m happy to >> see that it has been reverted for 10.2, but clearly, these changes are >> needed down the line and I hope the issue can be resolved well before >> 11.0. >> (This assumes a 10.3 before 11.0 happens next year.) >> >> > I have done some tests on my T530 at r285668 and had some (good and bad) > surprises: > > 0) historically i915kms+drm2 could not be loaded by loader.conf without > locking the machine, but needed to be loaded by rc.conf (kld_list). Now > these modules can be loaded by loader.conf. > > 1) resume does not work with a non patched kernel, but works when the > MFC of r281874 is reverted (i.e. r285863 applied) - in console mode (vt) > and X.org. > > 2) and now is my bad surprise: when i915kms+drm2+iic*+kbdmux are not > loaded at all, suspend works (in console mode of course), but not > resume, both with the nonpatched and the patched kernel. After resume > the screen keeps being black, but the system can be logged to with ssh, > but cannot be powered off nor rebooted from another system. Furthermore > the log shows unidentified _USB_ devices at resume (which never appeared > in any log before): > > Jul 29 12:28:12 watson devd: Executing '/etc/rc.suspend acpi 0x03' > Jul 29 12:28:12 watson acpi: suspend at 20150729 12:28:12 > Jul 29 12:28:37 watson kernel: uhub0: at usbus0, port 1, addr 1 > (disconnected) > Jul 29 12:28:37 watson kernel: uhub1: at usbus1, port 1, addr 1 > (disconnected) > Jul 29 12:28:37 watson kernel: ugen1.2: at usbus1 > (disconnected) > Jul 29 12:28:37 watson kernel: uhub4: at uhub1, port 1, addr 2 > (disconnected) > Jul 29 12:28:37 watson kernel: ugen1.3: > at usbus1 (disconnected) > Jul 29 12:28:37 watson kernel: uhub2: at usbus2, port 1, addr 1 > (disconnected) > Jul 29 12:28:37 watson kernel: ugen2.2: at usbus2 > (disconnected) > Jul 29 12:28:37 watson kernel: uhub3: at uhub2, port 1, addr 2 > (disconnected) > Jul 29 12:28:37 watson kernel: ugen2.3: at usbus2 (disconnected) > Jul 29 12:28:37 watson kernel: ums0: at uhub3, port 5, addr 3 > (disconnected) > Jul 29 12:28:37 watson kernel: acpi0: cleared fixed power button status > Jul 29 12:28:37 watson kernel: em0: link state changed to DOWN > Jul 29 12:28:37 watson kernel: xhci0: Port routing mask set to 0x > Jul 29 12:28:37 watson kernel: uhub0: <0x8086 XHCI root HUB, class 9/0, > rev 3.00/1.00, addr 1> on usbus0 > Jul 29 12:28:37 watson kernel: uhub1: rev 2.00/1.00, addr 1> on usbus2 > Jul 29 12:28:37 watson kernel: uhub2: rev 2.00/1.00, addr 1> on usbus1 > Jul 29 12:28:38 watson kernel: uhub0: 8 ports with 8 removable, self > powered > Jul 29 12:28:37 watson devd: Executing '/etc/rc.resume acpi 0x03' > Jul 29 12:28:38 watson acpi: resumed at 20150729 12:28:38 > Jul 29 12:28:38 watson kernel: uhub2: 3 ports with 3 removable, self > powered > Jul 29 12:28:38 watson kernel: uhub1: 3 ports with 3 removable, self > powered > Jul 29 12:28:38 watson kernel: em0: link state changed to UP > Jul 29 12:28:38 watson devd: Executing '/etc/rc.d/dhclient quietstart em0' > Jul 29 12:28:39 watson kernel: ugen2.2: at usbus2 > Jul 29 12:28:39 watson kernel: uhub3: class 9/0, rev 2.00/0.00, addr 2> on usbus2 > Jul 29 12:28:39 watson kernel: ugen1.2: at usbus1 > Jul 29 12:28:39 watson kernel: uhub4: class 9/0, rev 2.00/0.00, addr 2> on usbus1 > Jul 29 12:28:40 watson kernel: uhub4: 6 ports
Re: suspend/resume regression
On 07/26/2015 00:54, Kevin Oberman wrote: John, I'm concerned that two issues may be getting conflated. The issue I thought we were looking at was the failure of some systems (T520, X220, T430) to resume after a number of PCI enhancements were MFCed. This is completely unrelated to the USB issue I was experiencing when trying to test the problem on HEAD. The more I think about it, the more I think that the USB "issue" is just how things need to work. Specifically, if you are booting a full, multi-user system from a USB connected drive, suspending and resuming will leave the system in an untenable condition that will force a panic. At least I don't see how the OS can determine that the disk present on resume is unchanged from that present when the system was suspended. Modern disk IDs greatly improve the situation, but I am unaware of any way to be sure that a removable drive (such as a USB) has not been removed and plugged into some other system that might have written to it. My knowledge of such things is very dated, going back to my days doing kernel programming about 25-30 year ago on VMS, so someone may have resolved the issue, but I don't understand exactly how. I guess that the risk might be low enough to just go ahead and pray that nobody did something really, really stupid like unplugging the drive, plugging it in elsewhere, and writing to it. The real issue is just resuming the system after r281874 was MFCed as a part of 284034. No USB connected file systems are involved. I m happy to see that it has been reverted for 10.2, but clearly, these changes are needed down the line and I hope the issue can be resolved well before 11.0. (This assumes a 10.3 before 11.0 happens next year.) I have done some tests on my T530 at r285668 and had some (good and bad) surprises: 0) historically i915kms+drm2 could not be loaded by loader.conf without locking the machine, but needed to be loaded by rc.conf (kld_list). Now these modules can be loaded by loader.conf. 1) resume does not work with a non patched kernel, but works when the MFC of r281874 is reverted (i.e. r285863 applied) - in console mode (vt) and X.org. 2) and now is my bad surprise: when i915kms+drm2+iic*+kbdmux are not loaded at all, suspend works (in console mode of course), but not resume, both with the nonpatched and the patched kernel. After resume the screen keeps being black, but the system can be logged to with ssh, but cannot be powered off nor rebooted from another system. Furthermore the log shows unidentified _USB_ devices at resume (which never appeared in any log before): Jul 29 12:28:12 watson devd: Executing '/etc/rc.suspend acpi 0x03' Jul 29 12:28:12 watson acpi: suspend at 20150729 12:28:12 Jul 29 12:28:37 watson kernel: uhub0: at usbus0, port 1, addr 1 (disconnected) Jul 29 12:28:37 watson kernel: uhub1: at usbus1, port 1, addr 1 (disconnected) Jul 29 12:28:37 watson kernel: ugen1.2: at usbus1 (disconnected) Jul 29 12:28:37 watson kernel: uhub4: at uhub1, port 1, addr 2 (disconnected) Jul 29 12:28:37 watson kernel: ugen1.3: at usbus1 (disconnected) Jul 29 12:28:37 watson kernel: uhub2: at usbus2, port 1, addr 1 (disconnected) Jul 29 12:28:37 watson kernel: ugen2.2: at usbus2 (disconnected) Jul 29 12:28:37 watson kernel: uhub3: at uhub2, port 1, addr 2 (disconnected) Jul 29 12:28:37 watson kernel: ugen2.3: at usbus2 (disconnected) Jul 29 12:28:37 watson kernel: ums0: at uhub3, port 5, addr 3 (disconnected) Jul 29 12:28:37 watson kernel: acpi0: cleared fixed power button status Jul 29 12:28:37 watson kernel: em0: link state changed to DOWN Jul 29 12:28:37 watson kernel: xhci0: Port routing mask set to 0x Jul 29 12:28:37 watson kernel: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 Jul 29 12:28:37 watson kernel: uhub1: on usbus2 Jul 29 12:28:37 watson kernel: uhub2: on usbus1 Jul 29 12:28:38 watson kernel: uhub0: 8 ports with 8 removable, self powered Jul 29 12:28:37 watson devd: Executing '/etc/rc.resume acpi 0x03' Jul 29 12:28:38 watson acpi: resumed at 20150729 12:28:38 Jul 29 12:28:38 watson kernel: uhub2: 3 ports with 3 removable, self powered Jul 29 12:28:38 watson kernel: uhub1: 3 ports with 3 removable, self powered Jul 29 12:28:38 watson kernel: em0: link state changed to UP Jul 29 12:28:38 watson devd: Executing '/etc/rc.d/dhclient quietstart em0' Jul 29 12:28:39 watson kernel: ugen2.2: at usbus2 Jul 29 12:28:39 watson kernel: uhub3: on usbus2 Jul 29 12:28:39 watson kernel: ugen1.2: at usbus1 Jul 29 12:28:39 watson kernel: uhub4: on usbus1 Jul 29 12:28:40 watson kernel: uhub4: 6 ports with 6 removable, self powered Jul 29 12:28:41 watson kernel: uhub3: 8 ports with 8 removable, self powered Jul 29 12:28:41 watson kernel: ugen1.3: at usbus1 Jul 29 12:28:41 watson devd: Executing 'logger Unknown USB device: vendor 0x04f2 product 0xb2ea bus uhub4' Jul 29 12:28:41 watson root: Unknown USB device: vendor 0x04f2 product 0xb2ea bus uhub4 Jul 29 12:28:41 watson devd: Executi
Re: suspend/resume regression
Hi, Yes, the USB device suspend/resume thing is a more generic suspend/resume problem. Warner has some ideas - eg, registering a "is this a new device?" method; the device driver will check if the device has changed upon resume and optionally go through a detach/reattach process. So for USB it could be something about the serial or FS label; for wifi drivers it could be the MAC / serial number of the NIC, etc. -adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
John,
I'm concerned that two issues may be getting conflated.
The issue I thought we were looking at was the failure of some systems
(T520, X220, T430) to resume after a number of PCI enhancements were MFCed.
This is completely unrelated to the USB issue I was experiencing when
trying to test the problem on HEAD. The more I think about it, the more I
think that the USB "issue" is just how things need to work.
Specifically, if you are booting a full, multi-user system from a USB
connected drive, suspending and resuming will leave the system in an
untenable condition that will force a panic. At least I don't see how the
OS can determine that the disk present on resume is unchanged from that
present when the system was suspended. Modern disk IDs greatly improve the
situation, but I am unaware of any way to be sure that a removable drive
(such as a USB) has not been removed and plugged into some other system
that might have written to it. My knowledge of such things is very dated,
going back to my days doing kernel programming about 25-30 year ago on VMS,
so someone may have resolved the issue, but I don't understand exactly how.
I guess that the risk might be low enough to just go ahead and pray that
nobody did something really, really stupid like unplugging the drive,
plugging it in elsewhere, and writing to it.
The real issue is just resuming the system after r281874 was MFCed as a
part of 284034. No USB connected file systems are involved. I m happy to
see that it has been reverted for 10.2, but clearly, these changes are
needed down the line and I hope the issue can be resolved well before 11.0.
(This assumes a 10.3 before 11.0 happens next year.)
Thanks for the time you have spent on this and I'll be happy to help out
with testing in the future. Things will be easier now that I have a disk
with head on it. I wasted way too much time trying to get HEAD to work in a
USB drive and with related issues.
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
On Wed, Jul 22, 2015 at 10:46 PM, Kevin Oberman wrote:
> On Tue, Jul 21, 2015 at 3:56 PM, John Baldwin wrote:
>
>> On Saturday, July 18, 2015 10:22:33 PM Kevin Oberman wrote:
>> > I just confirmed that my system resumes on HEAD of July 16 but fails on
>> > 10.2-BETA2. So the problem limited to 10. I'm guessing that some other
>> > change made to pci that has not been MFCed is the cause, but it is only
>> > causing a problem on some hardware. I have seen no reports about systems
>> > other than Lenovo systems.
>>
>> So my x220 does fail with a USB disk on 10, but I also get a weird
>> behavior
>> where it seems to wake up (disk lights up) and then goes back to sleep and
>> never resumes again. I'm not sure if this is due to using a USB disk or
>> not. I get the same result when I disable power management during suspend
>> which was reported to fix other laptops IIRC.
>>
>> Please try this:
>>
>> Index: sys/dev/acpica/acpi.c
>> ===
>> --- sys/dev/acpica/acpi.c (revision 285761)
>> +++ sys/dev/acpica/acpi.c (working copy)
>> @@ -691,7 +691,7 @@
>> static void
>> acpi_set_power_children(device_t dev, int state)
>> {
>> - device_t child, parent;
>> + device_t child;
>> device_t *devlist;
>> struct pci_devinfo *dinfo;
>> int dstate, i, numdevs;
>> @@ -703,13 +703,12 @@
>> * Retrieve and set D-state for the sleep state if _SxD is
>> present.
>> * Skip children who aren't attached since they are handled
>> separately.
>> */
>> - parent = device_get_parent(dev);
>> for (i = 0; i < numdevs; i++) {
>> child = devlist[i];
>> dinfo = device_get_ivars(child);
>> dstate = state;
>> if (device_is_attached(child) &&
>> - acpi_device_pwr_for_sleep(parent, dev, &dstate) == 0)
>> + acpi_device_pwr_for_sleep(dev, child, &dstate) == 0)
>> acpi_set_powerstate(child, dstate);
>> }
>> free(devlist, M_TEMP);
>> Index: sys/dev/pci/pci.c
>> ===
>> --- sys/dev/pci/pci.c (revision 285761)
>> +++ sys/dev/pci/pci.c (working copy)
>> @@ -3671,7 +3671,7 @@
>> child = devlist[i];
>> dstate = state;
>> if (device_is_attached(child) &&
>> - PCIB_POWER_FOR_SLEEP(pcib, dev, &dstate) == 0)
>> + PCIB_POWER_FOR_SLEEP(pcib, child, &dstate) == 0)
>> pci_set_powerstate(child, dstate);
>> }
>> }
>> Index: .
>> ===
>> --- . (revision 285761)
>> +++ . (working copy)
>>
>> Property changes on: .
>> ___
>> Modified: svn:
Re: suspend/resume regression
On Tue, Jul 21, 2015 at 3:56 PM, John Baldwin wrote:
> On Saturday, July 18, 2015 10:22:33 PM Kevin Oberman wrote:
> > I just confirmed that my system resumes on HEAD of July 16 but fails on
> > 10.2-BETA2. So the problem limited to 10. I'm guessing that some other
> > change made to pci that has not been MFCed is the cause, but it is only
> > causing a problem on some hardware. I have seen no reports about systems
> > other than Lenovo systems.
>
> So my x220 does fail with a USB disk on 10, but I also get a weird behavior
> where it seems to wake up (disk lights up) and then goes back to sleep and
> never resumes again. I'm not sure if this is due to using a USB disk or
> not. I get the same result when I disable power management during suspend
> which was reported to fix other laptops IIRC.
>
> Please try this:
>
> Index: sys/dev/acpica/acpi.c
> ===
> --- sys/dev/acpica/acpi.c (revision 285761)
> +++ sys/dev/acpica/acpi.c (working copy)
> @@ -691,7 +691,7 @@
> static void
> acpi_set_power_children(device_t dev, int state)
> {
> - device_t child, parent;
> + device_t child;
> device_t *devlist;
> struct pci_devinfo *dinfo;
> int dstate, i, numdevs;
> @@ -703,13 +703,12 @@
> * Retrieve and set D-state for the sleep state if _SxD is present.
> * Skip children who aren't attached since they are handled
> separately.
> */
> - parent = device_get_parent(dev);
> for (i = 0; i < numdevs; i++) {
> child = devlist[i];
> dinfo = device_get_ivars(child);
> dstate = state;
> if (device_is_attached(child) &&
> - acpi_device_pwr_for_sleep(parent, dev, &dstate) == 0)
> + acpi_device_pwr_for_sleep(dev, child, &dstate) == 0)
> acpi_set_powerstate(child, dstate);
> }
> free(devlist, M_TEMP);
> Index: sys/dev/pci/pci.c
> ===
> --- sys/dev/pci/pci.c (revision 285761)
> +++ sys/dev/pci/pci.c (working copy)
> @@ -3671,7 +3671,7 @@
> child = devlist[i];
> dstate = state;
> if (device_is_attached(child) &&
> - PCIB_POWER_FOR_SLEEP(pcib, dev, &dstate) == 0)
> + PCIB_POWER_FOR_SLEEP(pcib, child, &dstate) == 0)
> pci_set_powerstate(child, dstate);
> }
> }
> Index: .
> ===
> --- . (revision 285761)
> +++ . (working copy)
>
> Property changes on: .
> ___
> Modified: svn:mergeinfo
>Merged /head:r274386,274397
>
>
> --
> John Baldwin
>
Tried both sysctls and the patch. Nothing worked. Ticket updated with the
information.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
On Saturday, July 18, 2015 10:22:33 PM Kevin Oberman wrote:
> I just confirmed that my system resumes on HEAD of July 16 but fails on
> 10.2-BETA2. So the problem limited to 10. I'm guessing that some other
> change made to pci that has not been MFCed is the cause, but it is only
> causing a problem on some hardware. I have seen no reports about systems
> other than Lenovo systems.
So my x220 does fail with a USB disk on 10, but I also get a weird behavior
where it seems to wake up (disk lights up) and then goes back to sleep and
never resumes again. I'm not sure if this is due to using a USB disk or
not. I get the same result when I disable power management during suspend
which was reported to fix other laptops IIRC.
Please try this:
Index: sys/dev/acpica/acpi.c
===
--- sys/dev/acpica/acpi.c (revision 285761)
+++ sys/dev/acpica/acpi.c (working copy)
@@ -691,7 +691,7 @@
static void
acpi_set_power_children(device_t dev, int state)
{
- device_t child, parent;
+ device_t child;
device_t *devlist;
struct pci_devinfo *dinfo;
int dstate, i, numdevs;
@@ -703,13 +703,12 @@
* Retrieve and set D-state for the sleep state if _SxD is present.
* Skip children who aren't attached since they are handled separately.
*/
- parent = device_get_parent(dev);
for (i = 0; i < numdevs; i++) {
child = devlist[i];
dinfo = device_get_ivars(child);
dstate = state;
if (device_is_attached(child) &&
- acpi_device_pwr_for_sleep(parent, dev, &dstate) == 0)
+ acpi_device_pwr_for_sleep(dev, child, &dstate) == 0)
acpi_set_powerstate(child, dstate);
}
free(devlist, M_TEMP);
Index: sys/dev/pci/pci.c
===
--- sys/dev/pci/pci.c (revision 285761)
+++ sys/dev/pci/pci.c (working copy)
@@ -3671,7 +3671,7 @@
child = devlist[i];
dstate = state;
if (device_is_attached(child) &&
- PCIB_POWER_FOR_SLEEP(pcib, dev, &dstate) == 0)
+ PCIB_POWER_FOR_SLEEP(pcib, child, &dstate) == 0)
pci_set_powerstate(child, dstate);
}
}
Index: .
===
--- . (revision 285761)
+++ . (working copy)
Property changes on: .
___
Modified: svn:mergeinfo
Merged /head:r274386,274397
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
I just confirmed that my system resumes on HEAD of July 16 but fails on 10.2-BETA2. So the problem limited to 10. I'm guessing that some other change made to pci that has not been MFCed is the cause, but it is only causing a problem on some hardware. I have seen no reports about systems other than Lenovo systems. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Sat, Jul 18, 2015 at 5:04 PM, Joseph Mingrone wrote: > Head worked for me. > > Joseph Mingrone writes: > > On head, resume worked, but the fn-f4 keybinding didn't suspend. I > > had to use zzz. > > Joseph Mingrone writes: > > No problem with -head on the X220 as well. > > Joseph > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
Head worked for me. Joseph Mingrone writes: > On head, resume worked, but the fn-f4 keybinding didn't suspend. I > had to use zzz. Joseph Mingrone writes: > No problem with -head on the X220 as well. Joseph signature.asc Description: PGP signature
Re: suspend/resume regression
Hold the phone! Just found a SATA drive. I will be installing HEAD on it shortly. I won't update the ticket until I get that tested. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Sat, Jul 18, 2015 at 4:34 PM, Kevin Oberman wrote: > I think it works on HEAD. I suspended OK and tried to resume. The resume > initiated and my screen came on... only to tell me that da0p2 was not > available. I seem to recall that this was a known issue when running on a > USB attached disk. The failure came much further along than on stable where > it failed immediately with fans turning on, but nothing else happening, > and, if I could connect the disk directly, I suspect it would work. > Unfortunately, I don't have a spare SATA disk... only old PATA drives and > the T520 only takes SATA drives. > > Bottom line is that the issue I saw with 10.1-STABLE and 10.1-BETA1 is not > present on HEAD, so this is entirely a regression in STABLE. > > I will be updating to BETA2 shortly and I'll report how it works there. > > Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > On Wed, Jul 15, 2015 at 10:52 PM, Kevin Oberman > wrote: > >> On Wed, Jul 15, 2015 at 12:07 PM, John Baldwin wrote: >> >>> On Tuesday, July 14, 2015 03:10:59 PM Brandon J. Wandersee wrote: >>> > >>> > Please forgive me if this seems impudent, but has there been any >>> progress on >>> > this? The status of the bug report hasn't changed since it was opened. >>> I >>> > don't mean to be rude, and I certainly appreciate the effort that's >>> gone >>> > into this already (especially Kevin's detective work), but support for >>> > suspend-to-RAM and my laptop's hotkeys were essentially the only >>> reasons >>> > I started tracking 10-STABLE to begin with. Since both features were >>> > resolved many months ago, I was hoping to switch from -STABLE to >>> 10.2-RELEASE >>> > when it came out, but I'm starting to get the feeling that won't happen >>> > because of a single errant commit. Having to continue following -STABLE >>> > would not be terrible, but it would be disappointing. >>> >>> As noted previously, I have been moving house and generally offline since >>> mid-June (and I'm not really fully online yet). My last request was if >>> Kevin (or someone else with an affected laptop) could test HEAD to see if >>> there is a missing bugfix on HEAD that needs to be merged. This specific >>> change was tested on HEAD on both a T440 and X220 and on 10 to test the >>> MFC on the T440. >>> >>> -- >>> John Baldwin >>> >> >> John, >> >> I am back from my vacation and hope to try HEAD soon, hopefully this >> weekend. Since HEAD has been a bit fragile of late, I do plan on testing >> and switching back to STABLE. I will probably install HEAD on a spare >> drive. With luck (meaning nothing crops up that fills the available time), >> I should have an answer on Monday. >> >> Hope the move was not too chaotic and life gets back to normal quickly. >> (I hate moving, but I do so twice a year. Practice makes something >> approaching perfect.) >> -- >> Kevin Oberman, Network Engineer, Retired >> E-mail: rkober...@gmail.com >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >> > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
I think it works on HEAD. I suspended OK and tried to resume. The resume initiated and my screen came on... only to tell me that da0p2 was not available. I seem to recall that this was a known issue when running on a USB attached disk. The failure came much further along than on stable where it failed immediately with fans turning on, but nothing else happening, and, if I could connect the disk directly, I suspect it would work. Unfortunately, I don't have a spare SATA disk... only old PATA drives and the T520 only takes SATA drives. Bottom line is that the issue I saw with 10.1-STABLE and 10.1-BETA1 is not present on HEAD, so this is entirely a regression in STABLE. I will be updating to BETA2 shortly and I'll report how it works there. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Wed, Jul 15, 2015 at 10:52 PM, Kevin Oberman wrote: > On Wed, Jul 15, 2015 at 12:07 PM, John Baldwin wrote: > >> On Tuesday, July 14, 2015 03:10:59 PM Brandon J. Wandersee wrote: >> > >> > Please forgive me if this seems impudent, but has there been any >> progress on >> > this? The status of the bug report hasn't changed since it was opened. I >> > don't mean to be rude, and I certainly appreciate the effort that's gone >> > into this already (especially Kevin's detective work), but support for >> > suspend-to-RAM and my laptop's hotkeys were essentially the only reasons >> > I started tracking 10-STABLE to begin with. Since both features were >> > resolved many months ago, I was hoping to switch from -STABLE to >> 10.2-RELEASE >> > when it came out, but I'm starting to get the feeling that won't happen >> > because of a single errant commit. Having to continue following -STABLE >> > would not be terrible, but it would be disappointing. >> >> As noted previously, I have been moving house and generally offline since >> mid-June (and I'm not really fully online yet). My last request was if >> Kevin (or someone else with an affected laptop) could test HEAD to see if >> there is a missing bugfix on HEAD that needs to be merged. This specific >> change was tested on HEAD on both a T440 and X220 and on 10 to test the >> MFC on the T440. >> >> -- >> John Baldwin >> > > John, > > I am back from my vacation and hope to try HEAD soon, hopefully this > weekend. Since HEAD has been a bit fragile of late, I do plan on testing > and switching back to STABLE. I will probably install HEAD on a spare > drive. With luck (meaning nothing crops up that fills the available time), > I should have an answer on Monday. > > Hope the move was not too chaotic and life gets back to normal quickly. (I > hate moving, but I do so twice a year. Practice makes something approaching > perfect.) > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
On Wed, Jul 15, 2015 at 12:07 PM, John Baldwin wrote: > On Tuesday, July 14, 2015 03:10:59 PM Brandon J. Wandersee wrote: > > > > Please forgive me if this seems impudent, but has there been any > progress on > > this? The status of the bug report hasn't changed since it was opened. I > > don't mean to be rude, and I certainly appreciate the effort that's gone > > into this already (especially Kevin's detective work), but support for > > suspend-to-RAM and my laptop's hotkeys were essentially the only reasons > > I started tracking 10-STABLE to begin with. Since both features were > > resolved many months ago, I was hoping to switch from -STABLE to > 10.2-RELEASE > > when it came out, but I'm starting to get the feeling that won't happen > > because of a single errant commit. Having to continue following -STABLE > > would not be terrible, but it would be disappointing. > > As noted previously, I have been moving house and generally offline since > mid-June (and I'm not really fully online yet). My last request was if > Kevin (or someone else with an affected laptop) could test HEAD to see if > there is a missing bugfix on HEAD that needs to be merged. This specific > change was tested on HEAD on both a T440 and X220 and on 10 to test the > MFC on the T440. > > -- > John Baldwin > John, I am back from my vacation and hope to try HEAD soon, hopefully this weekend. Since HEAD has been a bit fragile of late, I do plan on testing and switching back to STABLE. I will probably install HEAD on a spare drive. With luck (meaning nothing crops up that fills the available time), I should have an answer on Monday. Hope the move was not too chaotic and life gets back to normal quickly. (I hate moving, but I do so twice a year. Practice makes something approaching perfect.) -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
On Tuesday, July 14, 2015 03:10:59 PM Brandon J. Wandersee wrote: > > Please forgive me if this seems impudent, but has there been any progress on > this? The status of the bug report hasn't changed since it was opened. I > don't mean to be rude, and I certainly appreciate the effort that's gone > into this already (especially Kevin's detective work), but support for > suspend-to-RAM and my laptop's hotkeys were essentially the only reasons > I started tracking 10-STABLE to begin with. Since both features were > resolved many months ago, I was hoping to switch from -STABLE to 10.2-RELEASE > when it came out, but I'm starting to get the feeling that won't happen > because of a single errant commit. Having to continue following -STABLE > would not be terrible, but it would be disappointing. As noted previously, I have been moving house and generally offline since mid-June (and I'm not really fully online yet). My last request was if Kevin (or someone else with an affected laptop) could test HEAD to see if there is a missing bugfix on HEAD that needs to be merged. This specific change was tested on HEAD on both a T440 and X220 and on 10 to test the MFC on the T440. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
Please forgive me if this seems impudent, but has there been any progress on this? The status of the bug report hasn't changed since it was opened. I don't mean to be rude, and I certainly appreciate the effort that's gone into this already (especially Kevin's detective work), but support for suspend-to-RAM and my laptop's hotkeys were essentially the only reasons I started tracking 10-STABLE to begin with. Since both features were resolved many months ago, I was hoping to switch from -STABLE to 10.2-RELEASE when it came out, but I'm starting to get the feeling that won't happen because of a single errant commit. Having to continue following -STABLE would not be terrible, but it would be disappointing. -- = :: Brandon Wandersee :: :: brandon.wander...@gmail.com :: == 'A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.' - Douglas Adams == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
On Tue, Jun 30, 2015 at 8:45 AM, John Baldwin wrote: > I'm traveling and AFK for a week or so more, but I did test this MFC > including suspend/resume with CardBus, etc. on a T440 before committing > it. It would be good to know if HEAD works for you. If it does then > there's likely another fix from HEAD that you need merged. > > -- > John Baldwin > > John, I have opened bug # 201239 for the problem. Unfortunately I will be traveling and need a functioning laptop, so I can't test with HEAD right now. I will be back on the 9th and, if no one else has had a chance to test by then, I'll give it a try. It's about time I gave it a shot as I have not run HEAD since 10 was branched. Thanks for looking at this. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > On Jun 29, 2015, at 00:54, Kevin Oberman wrote: > > On Sun, Jun 28, 2015 at 11:07 PM, Adrian Chadd > wrote: > >> Ok, so which subset of changes is the culprit? >> >> (sorry, I'm tired.. :( ) >> >> >> The merge of 281874 broke it. Unfortunately, this is a fairly large and > important change that touches five files, mainly dev/pci/pci.c and > dev/pci/pci_pci.c with a less significant update to dev/pccbb/pccbb_pci.c. > > Get some rest. This is an annoying regression, but not disastrous. Systems > still run and it sounds like many still resume. Unfortunately my T520 and > some contemporary ThinkPads don't. > > I now have enough data to open a fairly coherent ticket. I'll try to open > it tomorrow. (I'm tired, too.) > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > >> -a >> >> >> On 28 June 2015 at 22:45, Kevin Oberman wrote: >> > On Sun, Jun 28, 2015 at 4:54 PM, Kevin Oberman >> wrote: >> >> >> >> On Sun, Jun 28, 2015 at 10:38 AM, Joseph Mingrone wrote: >> >>> >> >>> Adrian Chadd writes: >> >>> > ok. I've updated my x230 to the latest -head and it is okay at >> >>> > suspend/resume. >> >>> >> >>> No problem with -head on the X220 as well. >> >>> >> >>> > I can go acquire an x220 (now that they're cheap) to have as another >> >>> > reference laptop. >> >>> >> >>> You might ping Allan Jude. If I'm not mistaken he had at least two >> >>> X220s at BSDCan. Maybe he'd be willing to part with one. >> >> >> >> >> >> I have now merged all of the parts of 284034 except for 281874 and >> resume >> >> works correctly. As i suspected, something in that rather large commit >> is >> >> the problem and it is probably something that is tied to some other >> change >> >> in HEAD as Adrian has reported that it works fine in HEAD. >> >> >> >> I'll have to admit that have no idea how to approach figuring this out. >> >> I'm not sure how I can even revert a part of the commit to get >> >> 10.2-PRERELEASE working for me. I really wish that a commit as large >> as this >> >> one had been MFCed separately. :-( So far there has been only a single >> >> commit to pci and none to pccbb since 284034, so I built stable with >> the >> >> files modified in 281874 manually reverted. >> > >> > >> > I now have r284916M running and it seems to be working fine. All of >> 284034 >> > committed except for the MFC from 281874. That left three files >> conflicting >> > with STABLE: >> > /usr/src/sys/dev/pci/pci.c >> > /usr/src/sys/dev/pci/pci_pci.c >> > /usr/src/sys/dev/pccbb/pccbb_pci.c >> > -- >> > Kevin Oberman, Network Engineer, Retired >> > E-mail: rkober...@gmail.com >> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >> > >> > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
I'm traveling and AFK for a week or so more, but I did test this MFC including suspend/resume with CardBus, etc. on a T440 before committing it. It would be good to know if HEAD works for you. If it does then there's likely another fix from HEAD that you need merged. -- John Baldwin > On Jun 29, 2015, at 00:54, Kevin Oberman wrote: > >> On Sun, Jun 28, 2015 at 11:07 PM, Adrian Chadd >> wrote: >> Ok, so which subset of changes is the culprit? >> >> (sorry, I'm tired.. :( ) > The merge of 281874 broke it. Unfortunately, this is a fairly large and > important change that touches five files, mainly dev/pci/pci.c and > dev/pci/pci_pci.c with a less significant update to dev/pccbb/pccbb_pci.c. > > Get some rest. This is an annoying regression, but not disastrous. Systems > still run and it sounds like many still resume. Unfortunately my T520 and > some contemporary ThinkPads don't. > > I now have enough data to open a fairly coherent ticket. I'll try to open it > tomorrow. (I'm tired, too.) > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > >> >> -a >> >> >> On 28 June 2015 at 22:45, Kevin Oberman wrote: >> > On Sun, Jun 28, 2015 at 4:54 PM, Kevin Oberman wrote: >> >> >> >> On Sun, Jun 28, 2015 at 10:38 AM, Joseph Mingrone wrote: >> >>> >> >>> Adrian Chadd writes: >> >>> > ok. I've updated my x230 to the latest -head and it is okay at >> >>> > suspend/resume. >> >>> >> >>> No problem with -head on the X220 as well. >> >>> >> >>> > I can go acquire an x220 (now that they're cheap) to have as another >> >>> > reference laptop. >> >>> >> >>> You might ping Allan Jude. If I'm not mistaken he had at least two >> >>> X220s at BSDCan. Maybe he'd be willing to part with one. >> >> >> >> >> >> I have now merged all of the parts of 284034 except for 281874 and resume >> >> works correctly. As i suspected, something in that rather large commit is >> >> the problem and it is probably something that is tied to some other change >> >> in HEAD as Adrian has reported that it works fine in HEAD. >> >> >> >> I'll have to admit that have no idea how to approach figuring this out. >> >> I'm not sure how I can even revert a part of the commit to get >> >> 10.2-PRERELEASE working for me. I really wish that a commit as large as >> >> this >> >> one had been MFCed separately. :-( So far there has been only a single >> >> commit to pci and none to pccbb since 284034, so I built stable with the >> >> files modified in 281874 manually reverted. >> > >> > >> > I now have r284916M running and it seems to be working fine. All of 284034 >> > committed except for the MFC from 281874. That left three files conflicting >> > with STABLE: >> > /usr/src/sys/dev/pci/pci.c >> > /usr/src/sys/dev/pci/pci_pci.c >> > /usr/src/sys/dev/pccbb/pccbb_pci.c >> > -- >> > Kevin Oberman, Network Engineer, Retired >> > E-mail: rkober...@gmail.com >> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >> > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
On Sun, Jun 28, 2015 at 11:07 PM, Adrian Chadd wrote: > Ok, so which subset of changes is the culprit? > > (sorry, I'm tired.. :( ) > > > The merge of 281874 broke it. Unfortunately, this is a fairly large and important change that touches five files, mainly dev/pci/pci.c and dev/pci/pci_pci.c with a less significant update to dev/pccbb/pccbb_pci.c. Get some rest. This is an annoying regression, but not disastrous. Systems still run and it sounds like many still resume. Unfortunately my T520 and some contemporary ThinkPads don't. I now have enough data to open a fairly coherent ticket. I'll try to open it tomorrow. (I'm tired, too.) -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > -a > > > On 28 June 2015 at 22:45, Kevin Oberman wrote: > > On Sun, Jun 28, 2015 at 4:54 PM, Kevin Oberman > wrote: > >> > >> On Sun, Jun 28, 2015 at 10:38 AM, Joseph Mingrone wrote: > >>> > >>> Adrian Chadd writes: > >>> > ok. I've updated my x230 to the latest -head and it is okay at > >>> > suspend/resume. > >>> > >>> No problem with -head on the X220 as well. > >>> > >>> > I can go acquire an x220 (now that they're cheap) to have as another > >>> > reference laptop. > >>> > >>> You might ping Allan Jude. If I'm not mistaken he had at least two > >>> X220s at BSDCan. Maybe he'd be willing to part with one. > >> > >> > >> I have now merged all of the parts of 284034 except for 281874 and > resume > >> works correctly. As i suspected, something in that rather large commit > is > >> the problem and it is probably something that is tied to some other > change > >> in HEAD as Adrian has reported that it works fine in HEAD. > >> > >> I'll have to admit that have no idea how to approach figuring this out. > >> I'm not sure how I can even revert a part of the commit to get > >> 10.2-PRERELEASE working for me. I really wish that a commit as large as > this > >> one had been MFCed separately. :-( So far there has been only a single > >> commit to pci and none to pccbb since 284034, so I built stable with the > >> files modified in 281874 manually reverted. > > > > > > I now have r284916M running and it seems to be working fine. All of > 284034 > > committed except for the MFC from 281874. That left three files > conflicting > > with STABLE: > > /usr/src/sys/dev/pci/pci.c > > /usr/src/sys/dev/pci/pci_pci.c > > /usr/src/sys/dev/pccbb/pccbb_pci.c > > -- > > Kevin Oberman, Network Engineer, Retired > > E-mail: rkober...@gmail.com > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
Ok, so which subset of changes is the culprit? (sorry, I'm tired.. :( ) -a On 28 June 2015 at 22:45, Kevin Oberman wrote: > On Sun, Jun 28, 2015 at 4:54 PM, Kevin Oberman wrote: >> >> On Sun, Jun 28, 2015 at 10:38 AM, Joseph Mingrone wrote: >>> >>> Adrian Chadd writes: >>> > ok. I've updated my x230 to the latest -head and it is okay at >>> > suspend/resume. >>> >>> No problem with -head on the X220 as well. >>> >>> > I can go acquire an x220 (now that they're cheap) to have as another >>> > reference laptop. >>> >>> You might ping Allan Jude. If I'm not mistaken he had at least two >>> X220s at BSDCan. Maybe he'd be willing to part with one. >> >> >> I have now merged all of the parts of 284034 except for 281874 and resume >> works correctly. As i suspected, something in that rather large commit is >> the problem and it is probably something that is tied to some other change >> in HEAD as Adrian has reported that it works fine in HEAD. >> >> I'll have to admit that have no idea how to approach figuring this out. >> I'm not sure how I can even revert a part of the commit to get >> 10.2-PRERELEASE working for me. I really wish that a commit as large as this >> one had been MFCed separately. :-( So far there has been only a single >> commit to pci and none to pccbb since 284034, so I built stable with the >> files modified in 281874 manually reverted. > > > I now have r284916M running and it seems to be working fine. All of 284034 > committed except for the MFC from 281874. That left three files conflicting > with STABLE: > /usr/src/sys/dev/pci/pci.c > /usr/src/sys/dev/pci/pci_pci.c > /usr/src/sys/dev/pccbb/pccbb_pci.c > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
On Sun, Jun 28, 2015 at 4:54 PM, Kevin Oberman wrote: > On Sun, Jun 28, 2015 at 10:38 AM, Joseph Mingrone wrote: > >> Adrian Chadd writes: >> > ok. I've updated my x230 to the latest -head and it is okay at >> > suspend/resume. >> >> No problem with -head on the X220 as well. >> >> > I can go acquire an x220 (now that they're cheap) to have as another >> > reference laptop. >> >> You might ping Allan Jude. If I'm not mistaken he had at least two >> X220s at BSDCan. Maybe he'd be willing to part with one. >> > > I have now merged all of the parts of 284034 except for 281874 and resume > works correctly. As i suspected, something in that rather large commit is > the problem and it is probably something that is tied to some other change > in HEAD as Adrian has reported that it works fine in HEAD. > > I'll have to admit that have no idea how to approach figuring this out. > I'm not sure how I can even revert a part of the commit to get > 10.2-PRERELEASE working for me. I really wish that a commit as large as > this one had been MFCed separately. :-( So far there has been only a > single commit to pci and none to pccbb since 284034, so I built stable with > the files modified in 281874 manually reverted. > I now have r284916M running and it seems to be working fine. All of 284034 committed except for the MFC from 281874. That left three files conflicting with STABLE: /usr/src/sys/dev/pci/pci.c /usr/src/sys/dev/pci/pci_pci.c /usr/src/sys/dev/pccbb/pccbb_pci.c -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
Thanks for digging into this! (two laptops are now running -head from today, all iswell. I'll update the t400 tomorrow.) -a On 28 June 2015 at 16:54, Kevin Oberman wrote: > On Sun, Jun 28, 2015 at 10:38 AM, Joseph Mingrone wrote: >> >> Adrian Chadd writes: >> > ok. I've updated my x230 to the latest -head and it is okay at >> > suspend/resume. >> >> No problem with -head on the X220 as well. >> >> > I can go acquire an x220 (now that they're cheap) to have as another >> > reference laptop. >> >> You might ping Allan Jude. If I'm not mistaken he had at least two >> X220s at BSDCan. Maybe he'd be willing to part with one. > > > I have now merged all of the parts of 284034 except for 281874 and resumes > work fine. As i suspected, something in that rather large commit is the > problem and it is probably something that depends on some other change in > HEAD as Adrian has reported that it works fine in HEAD. > > I'll have to admit that have no idea how to approach figuring this out. I'm > not sure how I can even revert a part of the commit to get 10.2-PRERELEASE > working for me. I really wish that a commit as large as this one had been > MFCed separately. :-( So far there has been only a single commit to pci and > none to pccbb since 284034, so I guess I'll build stable with the files > modified in 281874 manually reverted and see how that goes. > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > . ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
On Sun, Jun 28, 2015 at 10:38 AM, Joseph Mingrone wrote: > Adrian Chadd writes: > > ok. I've updated my x230 to the latest -head and it is okay at > > suspend/resume. > > No problem with -head on the X220 as well. > > > I can go acquire an x220 (now that they're cheap) to have as another > > reference laptop. > > You might ping Allan Jude. If I'm not mistaken he had at least two > X220s at BSDCan. Maybe he'd be willing to part with one. > I have now merged all of the parts of 284034 except for 281874 and resumes work fine. As i suspected, something in that rather large commit is the problem and it is probably something that depends on some other change in HEAD as Adrian has reported that it works fine in HEAD. I'll have to admit that have no idea how to approach figuring this out. I'm not sure how I can even revert a part of the commit to get 10.2-PRERELEASE working for me. I really wish that a commit as large as this one had been MFCed separately. :-( So far there has been only a single commit to pci and none to pccbb since 284034, so I guess I'll build stable with the files modified in 281874 manually reverted and see how that goes. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 . ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
Adrian Chadd writes: > ok. I've updated my x230 to the latest -head and itis okay at > suspend/resume. No problem with -head on the X220 as well. > I can go acquire an x220 (now that they're cheap) to have as another > reference laptop. You might ping Allan Jude. If I'm not mistaken he had at least two X220s at BSDCan. Maybe he'd be willing to part with one. signature.asc Description: PGP signature
Re: suspend/resume regression
Hi, ok. I've updated my x230 to the latest -head and itis okay at suspend/resume. I can go acquire an x220 (now that they're cheap) to have as another reference laptop. I don't run stable/10 on anything, so it may be something odd with what he MFCed and what's in stable/10. I'll update the other laptops I have this evening and see if any of them regressed. -adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
On Sun, Jun 28, 2015 at 9:29 AM, Kevin Oberman wrote: > On Sun, Jun 28, 2015 at 3:27 AM, Joseph Mingrone wrote: > >> Kevin Oberman writes: >> > I have narrowed it to between 283990 and 284074. Have to crash, so maybe >> > someone else will track it down by tomorrow. I only see a handfull (<10) >> > commits in there that look like possible causes. 280434 is compiling >> right >> > now as the prime candidate. >> >> Cool. I think you mean 284034 and not 280434. It certainly looks >> suspicious. I'm trying 284028, but it'll be awhile. It wouldn't boot >> with just the kernel, so I'll try building world as well. >> > > Yes, I did. > > I can now confirm that 284034 is the culprit. Unfortunately, that single > commit MFCed 10 updates of which 6 may be the problem. I tend to suspect > the PCI changes rather than the CardBus patch, but I will spend a little > time looking at the individual commits in HEAD to see which, if any, touch > both PCI and CBB. > > Adrian, I don't have the ability to test on head ATM, so, if you have a > chance, go for it. Most if this is way beyond my ken, so I am extremely > unlikely to spot it. > > I am adding jhb@ to the CC as 284034 was his commit. > On Sun, Jun 28, 2015 at 9:38 AM, Kevin Oberman wrote: OK. This time I'm REALLY adding jhb@ to the CC. Guess my first cup of tea had not kicked in. Adding imp@ and jmg@ to CC. I really suspect 281874, a large update that touches both PCI and CBB. If anyone can test on head, I'd start with 281873 (which I suspect will work) and then 281874, which I suspect will fail. I have to so some other stuff right now, but I will try to revert just the changes in 281874 from 284034 later today and see what happens if I get the time. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
OK. This time I'm REALLY adding jhb@ to the CC. Guess my first cup of tea had not kicked in. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Sun, Jun 28, 2015 at 9:29 AM, Kevin Oberman wrote: > On Sun, Jun 28, 2015 at 3:27 AM, Joseph Mingrone wrote: > >> Kevin Oberman writes: >> > I have narrowed it to between 283990 and 284074. Have to crash, so maybe >> > someone else will track it down by tomorrow. I only see a handfull (<10) >> > commits in there that look like possible causes. 280434 is compiling >> right >> > now as the prime candidate. >> >> Cool. I think you mean 284034 and not 280434. It certainly looks >> suspicious. I'm trying 284028, but it'll be awhile. It wouldn't boot >> with just the kernel, so I'll try building world as well. >> > > Yes, I did. > > I can now confirm that 284034 is the culprit. Unfortunately, that single > commit MFCed 10 updates of which 6 may be the problem. I tend to suspect > the PCI changes rather than the CardBus patch, but I will spend a little > time looking at the individual commits in HEAD to see which, if any, touch > both PCI and CBB. > > Adrian, I don't have the ability to test on head ATM, so, if you have a > chance, go for it. Most if this is way beyond my ken, so I am extremely > unlikely to spot it. > > I am adding jhb@ to the CC as 284034 was his commit. > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
On Sun, Jun 28, 2015 at 3:27 AM, Joseph Mingrone wrote: > Kevin Oberman writes: > > I have narrowed it to between 283990 and 284074. Have to crash, so maybe > > someone else will track it down by tomorrow. I only see a handfull (<10) > > commits in there that look like possible causes. 280434 is compiling > right > > now as the prime candidate. > > Cool. I think you mean 284034 and not 280434. It certainly looks > suspicious. I'm trying 284028, but it'll be awhile. It wouldn't boot > with just the kernel, so I'll try building world as well. > Yes, I did. I can now confirm that 284034 is the culprit. Unfortunately, that single commit MFCed 10 updates of which 6 may be the problem. I tend to suspect the PCI changes rather than the CardBus patch, but I will spend a little time looking at the individual commits in HEAD to see which, if any, touch both PCI and CBB. Adrian, I don't have the ability to test on head ATM, so, if you have a chance, go for it. Most if this is way beyond my ken, so I am extremely unlikely to spot it. I am adding jhb@ to the CC as 284034 was his commit. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
Kevin Oberman writes: > I have narrowed it to between 283990 and 284074. Have to crash, so maybe > someone else will track it down by tomorrow. I only see a handfull (<10) > commits in there that look like possible causes. 280434 is compiling right > now as the prime candidate. Cool. I think you mean 284034 and not 280434. It certainly looks suspicious. I'm trying 284028, but it'll be awhile. It wouldn't boot with just the kernel, so I'll try building world as well. signature.asc Description: PGP signature
Re: suspend/resume regression
On 06/28/2015 09:12, Kevin Oberman wrote: On Sat, Jun 27, 2015 at 8:03 PM, Brandon J. Wandersee < brandon.wander...@gmail.com> wrote: Kevin Oberman writes: On Sat, Jun 27, 2015 at 3:13 PM, Joseph Mingrone wrote: Adrian Chadd writes: does it always fail now? Yes. The behaviour I described is, so far with 15-20 tries, consistent. I confirm that I see the similar behavior on my T520 ThinkPad, Sandy Bridge system. FreeBSD rogue 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #1 r284698: Mon Jun 22 09:25:11 PDT 2015 root@rogue:/usr/obj/usr/src/sys/GENERIC amd64 It has been working flawlessly since Adrian's ACPI update. As of now, it suspends fine, but it won't resume. I get a fan spin-up, but the power LED continues to pulse, indicating it is suspended and the logs show nothing after the suspend. Just updated my T520 yesterday, and I get the same behavior with the same machine here. Suspend is fine; resume fails. It seems to get a bit farther along in the resume process if i915kms isn't loaded, though I've got no way to really measure that. I've tried a GENERIC kernel, clean source tree and empty src.conf, to no avail. Several MFCs in r280434 from a couple weeks ago touched a whole bunch of suspend/resume stuff. That might be a good place to start digging. I have narrowed it to between 283990 and 284074. Have to crash, so maybe someone else will track it down by tomorrow. I only see a handfull (<10) commits in there that look like possible causes. 280434 is compiling right now as the prime candidate. FWIW, the only supend/resume problem with my T530 at 280455 (i915kms loaded by rc.conf) is that the keyboard lights are not restored on resume.. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" Claude Buisson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
On Sat, Jun 27, 2015 at 8:03 PM, Brandon J. Wandersee < brandon.wander...@gmail.com> wrote: > > Kevin Oberman writes: > > > On Sat, Jun 27, 2015 at 3:13 PM, Joseph Mingrone wrote: > > > >> Adrian Chadd writes: > >> > does it always fail now? > >> > >> Yes. The behaviour I described is, so far with 15-20 tries, consistent. > >> > > > > I confirm that I see the similar behavior on my T520 ThinkPad, Sandy > Bridge > > system. > > FreeBSD rogue 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #1 r284698: Mon Jun > > 22 09:25:11 PDT 2015 root@rogue:/usr/obj/usr/src/sys/GENERIC amd64 > > > > It has been working flawlessly since Adrian's ACPI update. As of now, it > > suspends fine, but it won't resume. I get a fan spin-up, but the power > LED > > continues to pulse, indicating it is suspended and the logs show nothing > > after the suspend. > > Just updated my T520 yesterday, and I get the same behavior with the > same machine here. Suspend is fine; resume fails. It seems to get a bit > farther along in the resume process if i915kms isn't loaded, though I've > got no way to really measure that. I've tried a GENERIC kernel, clean > source tree and empty src.conf, to no avail. > > Several MFCs in r280434 from a couple weeks ago touched a whole bunch of > suspend/resume stuff. That might be a good place to start digging. > > I have narrowed it to between 283990 and 284074. Have to crash, so maybe someone else will track it down by tomorrow. I only see a handfull (<10) commits in there that look like possible causes. 280434 is compiling right now as the prime candidate. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
Kevin Oberman writes: > On Sat, Jun 27, 2015 at 3:13 PM, Joseph Mingrone wrote: > >> Adrian Chadd writes: >> > does it always fail now? >> >> Yes. The behaviour I described is, so far with 15-20 tries, consistent. >> > > I confirm that I see the similar behavior on my T520 ThinkPad, Sandy Bridge > system. > FreeBSD rogue 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #1 r284698: Mon Jun > 22 09:25:11 PDT 2015 root@rogue:/usr/obj/usr/src/sys/GENERIC amd64 > > It has been working flawlessly since Adrian's ACPI update. As of now, it > suspends fine, but it won't resume. I get a fan spin-up, but the power LED > continues to pulse, indicating it is suspended and the logs show nothing > after the suspend. Just updated my T520 yesterday, and I get the same behavior with the same machine here. Suspend is fine; resume fails. It seems to get a bit farther along in the resume process if i915kms isn't loaded, though I've got no way to really measure that. I've tried a GENERIC kernel, clean source tree and empty src.conf, to no avail. Several MFCs in r280434 from a couple weeks ago touched a whole bunch of suspend/resume stuff. That might be a good place to start digging. -- = :: Brandon Wandersee :: :: brandon.wander...@gmail.com :: == 'A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.' - Douglas Adams == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
Adrian Chadd writes: > please start binary searching. > I'll update my x230 tonight when I get home and see if -head is > broken. On head, resume worked, but the fn-f4 keybinding didn't suspend. I had to use zzz. I'm trying different different revisions and I'll report back when I find something interesting. signature.asc Description: PGP signature
Re: suspend/resume regression
Hi, please start binary searching. I'll update my x230 tonight when I get home and see if -head is broken. -adrian On 27 June 2015 at 15:48, Kevin Oberman wrote: > On Sat, Jun 27, 2015 at 3:13 PM, Joseph Mingrone wrote: >> >> Adrian Chadd writes: >> > does it always fail now? >> >> Yes. The behaviour I described is, so far with 15-20 tries, consistent. > > > I confirm that I see the similar behavior on my T520 ThinkPad, Sandy Bridge > system. > FreeBSD rogue 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #1 r284698: Mon Jun 22 > 09:25:11 PDT 2015 root@rogue:/usr/obj/usr/src/sys/GENERIC amd64 > > It has been working flawlessly since Adrian's ACPI update. As of now, it > suspends fine, but it won't resume. I get a fan spin-up, but the power LED > continues to pulse, indicating it is suspended and the logs show nothing > after the suspend. > > Shall I start a binary hunt for the culprit? It will likely take a few > kernel builds as my last known working kernel was in late May. > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
Kevin Oberman writes: > On Sat, Jun 27, 2015 at 3:13 PM, Joseph Mingrone wrote: >> Adrian Chadd writes: >> > does it always fail now? >> Yes. The behaviour I described is, so far with 15-20 tries, consistent. > I confirm that I see the similar behavior on my T520 ThinkPad, Sandy Bridge > system. > FreeBSD rogue 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #1 r284698: Mon Jun > 22 09:25:11 PDT 2015 root@rogue:/usr/obj/usr/src/sys/GENERIC amd64 > It has been working flawlessly since Adrian's ACPI update. As of now, it > suspends fine, but it won't resume. I get a fan spin-up, but the power LED > continues to pulse, indicating it is suspended and the logs show nothing > after the suspend. > Shall I start a binary hunt for the culprit? It will likely take a few > kernel builds as my last known working kernel was in late May. > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 That sounds about right (when i915kms is loaded). Thanks for the update. I was trying r282199 from the end of April when a lot of stuff under /stable/10/sys/dev/drm2 got touched, but since you say it's working I'll move ahead to about two weeks ago. signature.asc Description: PGP signature
Re: suspend/resume regression
On Sat, Jun 27, 2015 at 3:13 PM, Joseph Mingrone wrote: > Adrian Chadd writes: > > does it always fail now? > > Yes. The behaviour I described is, so far with 15-20 tries, consistent. > I confirm that I see the similar behavior on my T520 ThinkPad, Sandy Bridge system. FreeBSD rogue 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #1 r284698: Mon Jun 22 09:25:11 PDT 2015 root@rogue:/usr/obj/usr/src/sys/GENERIC amd64 It has been working flawlessly since Adrian's ACPI update. As of now, it suspends fine, but it won't resume. I get a fan spin-up, but the power LED continues to pulse, indicating it is suspended and the logs show nothing after the suspend. Shall I start a binary hunt for the culprit? It will likely take a few kernel builds as my last known working kernel was in late May. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume regression
Adrian Chadd writes: > does it always fail now? Yes. The behaviour I described is, so far with 15-20 tries, consistent. signature.asc Description: PGP signature
Re: suspend/resume regression
does it always fail now? -a On 26 June 2015 at 14:06, Joseph Mingrone wrote: > This is on a Lenovo X220. Suspend/resume was working until some time > between late April and last week's STABLE snapshot. > > Suspend always seems to work, but there are two issues with resume. > > 1) When i915kms isn't loaded, then resuming works, but the screen > doesn't come back on. I'm able to ssh in to verify all is well. > kern.vty=vt is set in /boot/loader.conf. I'm not positive that this > wasn't a problem in the past since I always started the system up with > xdm. > > 2) When i915kms is loaded, then resuming doesn't work and the system > needs a hard restart. This definitely used to worked. > > For case 1), after the system has resumed and i915kms is then loaded > the message below appears in /var/log/messages: > > Jun 26 17:42:22 phe kernel: error: [drm:pid0:intel_lvds_enable] *ERROR* > timed out waiting for panel to power off > > If there is anything I can test or any useful information I left out, > just let me know. > > Joseph ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
