Re: Unable to wake ThinkPad x250 from sleep when TPM mode set to 1.2

2018-07-18 Thread Kurt Mosiejczuk
On Tue, Jul 17, 2018 at 05:45:13PM -0500, joshua stein wrote: > > So this bug seems to be specific to TPM 1.2 mode. > > I'm happy to twiddle more BIOS settings if you come up with a patch > > for TPM 1.2 on the x250. > Did the 'tpm at acpi' device attach when in that mode? Not. Doing "dmesg | g

Kernel crash on i386 -current

2018-07-18 Thread Eivind Eide
Over several snapshots after 6.3 I get reliable system crash after a few minutes uptime on this old i386 machine of mine. I have no explanation other than the documentation I provide. As gmail mangles all text I try to give the system information as provided by sendbug as textfile attachment to thi

Re: Kernel crash on i386 -current

2018-07-18 Thread Alexander Bluhm
On Wed, Jul 18, 2018 at 08:39:17PM +0200, Eivind Eide wrote: > Over several snapshots after 6.3 I get reliable system crash after a > few minutes uptime on this old i386 machine of mine. It would be helpful to know when this started. Does it happen with 6.3? Since 6.3 we have commited i386 Meltd

Re: Kernel Panic 6.3 on HP DL360p Gen8

2018-07-18 Thread Alexander Bluhm
On Wed, Jul 18, 2018 at 07:13:15AM +, Daniel Stocker wrote: > ddb{0}> trace > export_sa(10,800022368520) at export_sa+0x5c > pfkeyv2_expire(81409800,81409800) at pfkeyv2_expire+0x14e > tdb_timeout(8000223686d0) at tdb_timeout+0x39 > softclock_thread(0) at softclock_threa

Re: Kernel crash on i386 -current

2018-07-18 Thread Eivind Eide
2018-07-18 23:04 GMT+02:00 Alexander Bluhm : > On Wed, Jul 18, 2018 at 08:39:17PM +0200, Eivind Eide wrote: >> Over several snapshots after 6.3 I get reliable system crash after a >> few minutes uptime on this old i386 machine of mine. > > It would be helpful to know when this started. Does it hap

Re: Kernel panic: "kernel page fault", "uvm_fault(...)", "x86_ipi_db(...)"

2018-07-18 Thread Romain
> I'm wondering if this is due to the fact that we detach usb(4) devices on > suspend. Looks like this may be trying to process a timeout that corresponds > to a device that is no longer attached. Maybe the urtwn(4)? > > Just guessing, though. Can you reproduce this by zzz'ing, pulling the > u