Re: Microcode Updater Changes

On 05/16/18 10:42, Sean Bruno wrote: > https://reviews.freebsd.org/D15443 > > The FreeBSD Foundation has collaborated with a few folks so that we can > continue to process and update microcode on FreeBSD. > > This review represents the first step in updating our infrastructure. > If you are

Re: suspend/resume regression

On 17/05/2018 21:14, Pete Wright wrote: > > > On 05/12/2018 19:25, Pete Wright wrote: >> hi there - i have an amd64 laptop that's been running CURRENT for a while >> using both drm-next and drm-stable for graphics. during the past week or so >> i've run into issues with suspend resume...well

Re: suspend/resume regression

On 05/12/2018 19:25, Pete Wright wrote: hi there - i have an amd64 laptop that's been running CURRENT for a while using both drm-next and drm-stable for graphics. during the past week or so i've run into issues with suspend resume...well technically resume has stopped working.  i've tested a

Re: serial console vs suspend

On Thu, May 17, 2018 at 7:28 AM, Andriy Gapon wrote: > On 17/05/2018 16:25, Ian Lepore wrote: > > Why should it go through the console layer? If the uart hardware needs > > some re-init on resume, won't that be true whether the uart is serving > > as a console, a dial-in

Re: serial console vs suspend

On 17/05/2018 16:25, Ian Lepore wrote: > Why should it go through the console layer? If the uart hardware needs > some re-init on resume, won't that be true whether the uart is serving > as a console, a dial-in terminal, or the interface to wifi or bluetooth > chip? I think that for those things

Re: serial console vs suspend

On Thu, 2018-05-17 at 10:54 +0300, Andriy Gapon wrote: > > It seems that the serial console, or rather a UART used by it, may require > re-initialization after waking up (from suspend to RAM).  At least one of my > systems fails to wake up properly if I configure the serial console.  I've > done

Re: Something between r333623 - r333670 locks up at start of boot

On Thu, May 17, 2018 at 09:34:03AM +0200, Jean-Sébastien Pédron wrote: > ... > I broke syscons(4) yesterday and bde@ provided a patch which cem@ > committed in r333683 [1]. > > It should work again for you now. Sorry for the breakage. > Aye, all better now: FreeBSD g1-215.catwhisker.org

Resume without drm driver results in black screen

Hi I revived this old bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213501 Considering this also affects all X users using scfb driver it's worth investigating. ___ freebsd-current@freebsd.org mailing list

Re: Lag after resume culprit found

On Thu, May 17, 2018 at 11:06:42AM +0300, Andriy Gapon wrote: > On 17/05/2018 10:56, Johannes Lundberg wrote: > > > > > > On Thu, May 17, 2018 at 8:46 AM, Johannes Lundberg > > wrote: > > > > > > > > On Thu, May 17, 2018 at 7:43 AM, Andriy

Re: Lag after resume culprit found

On 17/05/2018 10:56, Johannes Lundberg wrote: > > > On Thu, May 17, 2018 at 8:46 AM, Johannes Lundberg > wrote: > > > > On Thu, May 17, 2018 at 7:43 AM, Andriy Gapon > wrote: > > On

Re: Lag after resume culprit found

On 17/05/2018 10:56, Andriy Gapon wrote: > On 17/05/2018 10:46, Johannes Lundberg wrote: >> On Thu, May 17, 2018 at 7:43 AM, Andriy Gapon > > wrote: >> >> On 17/05/2018 02:07, Johannes Lundberg wrote: >> > >>

Re: Lag after resume culprit found

On 17/05/2018 10:46, Johannes Lundberg wrote: > On Thu, May 17, 2018 at 7:43 AM, Andriy Gapon > wrote: > > On 17/05/2018 02:07, Johannes Lundberg wrote: > > > https://github.com/freebsd/freebsd/commit/66f063557f257baa9c8aeab9f933171eaa6e1cfa >

Re: Lag after resume culprit found

On Thu, May 17, 2018 at 8:46 AM, Johannes Lundberg wrote: > > > On Thu, May 17, 2018 at 7:43 AM, Andriy Gapon wrote: > >> On 17/05/2018 02:07, Johannes Lundberg wrote: >> > https://github.com/freebsd/freebsd/commit/66f063557f257baa9c >>

serial console vs suspend

It seems that the serial console, or rather a UART used by it, may require re-initialization after waking up (from suspend to RAM). At least one of my systems fails to wake up properly if I configure the serial console. I've done some experimenting with cu (and without the console) and the

Re: Lag after resume culprit found

On Thu, May 17, 2018 at 7:43 AM, Andriy Gapon wrote: > On 17/05/2018 02:07, Johannes Lundberg wrote: > > https://github.com/freebsd/freebsd/commit/66f063557f257baa9c8aeab9f93317 > 1eaa6e1cfa > > x86 cpususpend_handler: call wbinvd after setting suspend state bits > > That's

Re: Something between r333623 - r333670 locks up at start of boot

On 16.05.2018 14:42, David Wolfskill wrote: > After updating sources to r333670, build was OK; smoke-test came to a > screeching halt at: > > Booting... > / > > (...) > > One possibly-salient item: while the build machine uses the default > vt(4), I had switched the laptop to 'kern.vty="sc"'

Re: Lag after resume culprit found

On 17/05/2018 02:07, Johannes Lundberg wrote: > https://github.com/freebsd/freebsd/commit/66f063557f257baa9c8aeab9f933171eaa6e1cfa > x86 cpususpend_handler: call wbinvd after setting suspend state bits That's very interesting and surprising. That commit changes something that happens before