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: <vendor 0x8087> 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: <Chicony Electronics Co., Ltd.>
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: <vendor 0x8087> 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: <Logitech> 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 0xffffffff
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: <Intel EHCI root HUB, class 9/0,
rev 2.00/1.00, addr 1> on usbus2
Jul 29 12:28:37 watson kernel: uhub2: <Intel EHCI root HUB, class 9/0,
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: <vendor 0x8087> at usbus2
Jul 29 12:28:39 watson kernel: uhub3: <vendor 0x8087 product 0x0024,
class 9/0, rev 2.00/0.00, addr 2> on usbus2
Jul 29 12:28:39 watson kernel: ugen1.2: <vendor 0x8087> at usbus1
Jul 29 12:28:39 watson kernel: uhub4: <vendor 0x8087 product 0x0024,
class 9/0, rev 2.00/0.00, addr 2> 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: <Chicony Electronics Co., Ltd.>
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: 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 kernel: ugen2.3: <Logitech> at usbus2
Jul 29 12:28:41 watson devd: Executing 'logger Unknown USB device:
vendor 0x046d product 0xc52b bus uhub3'
Jul 29 12:28:41 watson root: Unknown USB device: vendor 0x046d product
0xc52b bus uhub3
Jul 29 12:28:41 watson kernel: ums0: <Logitech USB Receiver, class 0/0,
rev 2.00/24.00, addr 3> on usbus2
Jul 29 12:28:41 watson kernel: ums0: 16 buttons and [XYZT] coordinates ID=2
Jul 29 12:28:41 watson devd: Executing 'logger Unknown USB device:
vendor 0x046d product 0xc52b bus uhub3'
Jul 29 12:28:41 watson root: Unknown USB device: vendor 0x046d product
0xc52b bus uhub3
I dare say that there is some mess somewhere..
4) last minute tests: I get the same resume problem as 3) supra when
booting from a USB stick with a 11-CURRENT snapshot, both
20150330-r28086 and 20150722-r285794 (and cannot obtain anything useful
from /var/log/messages)
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"
