Re: Microcode Updater Changes

[Sean Bruno]

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 currently using microcode updates, please give this a spin
> and report back if you see a different version of microcode being loaded
> on the new package vs the old package.
> 
> sean
> 
> bcc emaste
> 


Ports svn 470255 updates the microcode package devcpu-data to process
the same files that linux (and the only ones Intel releases now).

If you are a consumer of this package, you should see *no* difference in
the version update to your CPU.  If you do, please respond to this thread.

sean



signature.asc
Description: OpenPGP digital signature

Re: suspend/resume regression

[Andriy Gapon]

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 technically resume has 
>> stopped
>> working.  i've tested a couple configurations and none have allowed my system
>> to resume successfully:
>>
>> - drm-next installed with DMC firmware loaded
>> - drm-next installed without DMC firmware loaded (worked previously)
>> - drm-stable with DMC
>> - drm-stable without DMC
>> - no drm modules loaded.
>>
>> I've also tested these configs with the following sysctl set to 0 and 1:
>> hw.acpi.reset_video
>>
>> at this point i'd like to help find what the regression i'm running into is,
>> so any pointers on how i can help? the system seems to boot and i'm pretty
>> sure i can ssh into it most times, just not sure what info i should grab to
>> help.  nothing of interest in messages or dmesg buffer either.
>>
> 
> Closing the loop on this thread.  Git commit
> 4e99d4e797ba9cea01897b6909b061db841f855a fixes this issue on my end.  For more
> info there is a thread on this list named "Lag after resume culprit found" 
> that
> has details.

Thank you for confirming that it was the same issue and that (or, rather,
because) it's fixed now.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Pete Wright]

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 couple configurations and 
none have allowed my system to resume successfully:


- drm-next installed with DMC firmware loaded
- drm-next installed without DMC firmware loaded (worked previously)
- drm-stable with DMC
- drm-stable without DMC
- no drm modules loaded.

I've also tested these configs with the following sysctl set to 0 and 1:
hw.acpi.reset_video

at this point i'd like to help find what the regression i'm running 
into is, so any pointers on how i can help? the system seems to boot 
and i'm pretty sure i can ssh into it most times, just not sure what 
info i should grab to help.  nothing of interest in messages or dmesg 
buffer either.




Closing the loop on this thread.  Git commit 
4e99d4e797ba9cea01897b6909b061db841f855a fixes this issue on my end.  
For more info there is a thread on this list named "Lag after resume 
culprit found" that has details.


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: serial console vs suspend

[Warner Losh]

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 terminal, or the interface to wifi or bluetooth
> > chip?
>
> I think that for those things a normal device resume should do.
> console gets used very early, so it may require a special resume.
>

We should re-init both places (maybe with a flag to prevent double if
that's harmful). The console is needed very early after the resume, often
earlier than the accidental location in the device tree the console
device_t node lives. That way we don't lose output. The console layer gives
us a convenient hook early in resume to cope.  It's yet another reason,
though, it should be restricted to true console devices, but that's another
conversation.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: serial console vs suspend

[Andriy Gapon]

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 a normal device resume should do.
console gets used very early, so it may require a special resume.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: serial console vs suspend

[Ian Lepore]

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
> some experimenting with cu (and without the console) and the UART seems to be 
> in
> some weird state, it echoes back the input and does not send anything on the
> wire.  I guess that trying to print to the serial console while the UART is in
> that state results in a hang.
> 
> To test the theory I made this hack and it does help:
> Index: sys/dev/uart/uart_tty.c
> ===
> --- sys/dev/uart/uart_tty.c   (revision 333667)
> +++ sys/dev/uart/uart_tty.c   (working copy)
> @@ -114,6 +114,13 @@ uart_cninit(struct consdev *cp)
>   uart_init(di);
>  }
> 
> +void uart_resume(void);
> +void
> +uart_resume(void)
> +{
> + uart_init(_console);
> +}
> +
>  static void
>  uart_cnterm(struct consdev *cp)
>  {
> Index: sys/x86/acpica/acpi_wakeup.c
> ===
> --- sys/x86/acpica/acpi_wakeup.c  (revision 333667)
> +++ sys/x86/acpica/acpi_wakeup.c  (working copy)
> @@ -204,6 +205,8 @@ acpi_wakeup_cpus(struct acpi_softc *sc)
>  }
>  #endif
> 
> +extern void uart_resume(void);
> +
>  int
>  acpi_sleep_machdep(struct acpi_softc *sc, int state)
>  {
> @@ -300,6 +303,7 @@ acpi_sleep_machdep(struct acpi_softc *sc, int stat
>  #else
>   npxresume(susppcbs[0]->sp_fpususpend);
>  #endif
> + uart_resume();
>   }
> 
>   return (1); /* wakeup successfully */
> 
> 
> ===
> 
> This is quick and dirty, of course.
> I think that this should go through the console layer.
> And, obviously, not all consoles actually need such a reinit.
> 
> So, maybe:
> cnresume()
> {
>   for each console {
>   if cn->cn_ops->cn_resume != NULL
>   cn->cn_ops->cn_resume(cn)
>   }
> }
> 
> uart_resume(struct consdev *cp)
> {
>   uart_init(cp->cn_arg);
> }
> 
> What do you think?
> 
> Hmm, it looks like CONSOLE_DRIVER() does not allow to omit a console method.
> So, will I have to add a dummy resume to all console drivers?

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?

-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[David Wolfskill]

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 12.0-CURRENT FreeBSD 12.0-CURRENT #192  
r333710M/333710:1200063: Thu May 17 05:23:56 PDT 2018 
r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64

Thanks! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Mr. Trump: Just how does reneging on the Iran nuclear deal make the US "safer?"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Resume without drm driver results in black screen

[Johannes Lundberg]

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
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lag after resume culprit found

[Konstantin Belousov]

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 Gapon  > > wrote:
> > 
> > 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 suspend, it 
> > should not
> > have
> > any effect on the system state after resume.
> > 
> > Does anyone have a theory of what could be wrong?
> > 
> > 
> > Nope but moving
> >         CPU_CLR_ATOMIC(cpu, _cpus);
> > back to the end of that scope fixes it.
> >  
> > 
> > 
> > I did some further testing.
> > Calling
> > CPU_CLR_ATOMIC(cpu, _cpus);
> > before
> > pmap_init_pat();
> >  is what "breaks" resume.
> > 
> > Is this Intel only or this it happen on AMD as well (which this patch was
> > intended for)?
> 
> Not sure about the PAT part, but fpuresume/npxresume would affect all 
> platforms.
> It's a bit puzzling that doing PAT manipulations on one AP while another AP is
> being brought up is problematic.  Probably there is something that I am 
> missing.

Manipulating PAT might affect the cache consistency, since contradicting
caching attributes are applied to the line of the suspended_cpus variable
which is already cached.  It might be not the variable itself that causes
the final mis-operation, but some other data sharing the line.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lag after resume culprit found

[Andriy Gapon]

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 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 suspend, it should 
> not
> have
> any effect on the system state after resume.
> 
> Does anyone have a theory of what could be wrong?
> 
> 
> Nope but moving
>         CPU_CLR_ATOMIC(cpu, _cpus);
> back to the end of that scope fixes it.
>  
> 
> 
> I did some further testing.
> Calling
> CPU_CLR_ATOMIC(cpu, _cpus);
> before
> pmap_init_pat();
>  is what "breaks" resume.
> 
> Is this Intel only or this it happen on AMD as well (which this patch was
> intended for)?

Not sure about the PAT part, but fpuresume/npxresume would affect all platforms.
It's a bit puzzling that doing PAT manipulations on one AP while another AP is
being brought up is problematic.  Probably there is something that I am missing.

Thank you very much again for zeroing in on it.

> > How to test (i915kms)
> > 
> > Start X with glxgears
> > Confirm running stable at 60 fps
> > suspend/resume (S3)
> > glxgears is now fluctuating between 10-40 fps.


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lag after resume culprit found

[Andriy Gapon]

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:
>> > 
>> 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 suspend, it should not 
>> have
>> any effect on the system state after resume.
>>
>> Does anyone have a theory of what could be wrong?
>>
>> Nope but moving
>>         CPU_CLR_ATOMIC(cpu, _cpus);
>> back to the end of that scope fixes it.
> 
> That's interesting.
> Thank you for testing it!
> And let me think about it.

Oh, I am stupid.
I intended that operation to be right after the CPU is done with restoring its
saved context.  Which means that it has to be after fpuresume/npxresume block.
Could you please re-test with CPU_CLR_ATOMIC(cpu, _cpus) at that 
position?
And my apologies.

>> > How to test (i915kms)
>> >
>> > Start X with glxgears
>> > Confirm running stable at 60 fps
>> > suspend/resume (S3)
>> > glxgears is now fluctuating between 10-40 fps.
> 


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lag after resume culprit found

[Andriy Gapon]

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
> 
> 
> > x86 cpususpend_handler: call wbinvd after setting suspend state bits
> 
> That's very interesting and surprising.
> That commit changes something that happens before suspend, it should not 
> have
> any effect on the system state after resume.
> 
> Does anyone have a theory of what could be wrong?
> 
> Nope but moving
>         CPU_CLR_ATOMIC(cpu, _cpus);
> back to the end of that scope fixes it.

That's interesting.
Thank you for testing it!
And let me think about it.

> > How to test (i915kms)
> >
> > Start X with glxgears
> > Confirm running stable at 60 fps
> > suspend/resume (S3)
> > glxgears is now fluctuating between 10-40 fps.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lag after resume culprit found

[Johannes Lundberg]

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
>> 8aeab9f933171eaa6e1cfa
>> > x86 cpususpend_handler: call wbinvd after setting suspend state bits
>>
>> That's very interesting and surprising.
>> That commit changes something that happens before suspend, it should not
>> have
>> any effect on the system state after resume.
>>
>> Does anyone have a theory of what could be wrong?
>>
>
> Nope but moving
> CPU_CLR_ATOMIC(cpu, _cpus);
> back to the end of that scope fixes it.
>
>

I did some further testing.
Calling
CPU_CLR_ATOMIC(cpu, _cpus);
before
pmap_init_pat();
 is what "breaks" resume.

Is this Intel only or this it happen on AMD as well (which this patch was
intended for)?



>> > How to test (i915kms)
>> >
>> > Start X with glxgears
>> > Confirm running stable at 60 fps
>> > suspend/resume (S3)
>> > glxgears is now fluctuating between 10-40 fps.
>>
>>
>>
>> --
>> Andriy Gapon
>>
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

serial console vs suspend

[Andriy Gapon]

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 UART seems to be in
some weird state, it echoes back the input and does not send anything on the
wire.  I guess that trying to print to the serial console while the UART is in
that state results in a hang.

To test the theory I made this hack and it does help:
Index: sys/dev/uart/uart_tty.c
===
--- sys/dev/uart/uart_tty.c (revision 333667)
+++ sys/dev/uart/uart_tty.c (working copy)
@@ -114,6 +114,13 @@ uart_cninit(struct consdev *cp)
uart_init(di);
 }

+void uart_resume(void);
+void
+uart_resume(void)
+{
+   uart_init(_console);
+}
+
 static void
 uart_cnterm(struct consdev *cp)
 {
Index: sys/x86/acpica/acpi_wakeup.c
===
--- sys/x86/acpica/acpi_wakeup.c(revision 333667)
+++ sys/x86/acpica/acpi_wakeup.c(working copy)
@@ -204,6 +205,8 @@ acpi_wakeup_cpus(struct acpi_softc *sc)
 }
 #endif

+extern void uart_resume(void);
+
 int
 acpi_sleep_machdep(struct acpi_softc *sc, int state)
 {
@@ -300,6 +303,7 @@ acpi_sleep_machdep(struct acpi_softc *sc, int stat
 #else
npxresume(susppcbs[0]->sp_fpususpend);
 #endif
+   uart_resume();
}

return (1); /* wakeup successfully */


===

This is quick and dirty, of course.
I think that this should go through the console layer.
And, obviously, not all consoles actually need such a reinit.

So, maybe:
cnresume()
{
for each console {
if cn->cn_ops->cn_resume != NULL
cn->cn_ops->cn_resume(cn)
}
}

uart_resume(struct consdev *cp)
{
uart_init(cp->cn_arg);
}

What do you think?

Hmm, it looks like CONSOLE_DRIVER() does not allow to omit a console method.
So, will I have to add a dummy resume to all console drivers?


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lag after resume culprit found

[Johannes Lundberg]

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 very interesting and surprising.
> That commit changes something that happens before suspend, it should not
> have
> any effect on the system state after resume.
>
> Does anyone have a theory of what could be wrong?
>

Nope but moving
CPU_CLR_ATOMIC(cpu, _cpus);
back to the end of that scope fixes it.


>
> > How to test (i915kms)
> >
> > Start X with glxgears
> > Confirm running stable at 60 fps
> > suspend/resume (S3)
> > glxgears is now fluctuating between 10-40 fps.
>
>
>
> --
> Andriy Gapon
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Jean-Sébastien Pédron]

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"' via /boot/loader.conf
> no later than 23 August 2017 (mtime of the file)

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.

[1] https://svnweb.freebsd.org/changeset/base/333683

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: Lag after resume culprit found

[Andriy Gapon]

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 suspend, it should not have
any effect on the system state after resume.

Does anyone have a theory of what could be wrong?

> How to test (i915kms)
> 
> Start X with glxgears
> Confirm running stable at 60 fps
> suspend/resume (S3)
> glxgears is now fluctuating between 10-40 fps.



-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"