Re: uvm_meter: remove wakeup of proc0

2023-08-01 Thread Claudio Jeker
On Mon, Jul 31, 2023 at 08:31:41PM -0500, Scott Cheloha wrote:
> On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > > This is the culprit:
> > > > 
> > > > schedule_timeout_uninterruptible(long timeout)
> > > > {
> > > > tsleep(curproc, PWAIT, "schtou", timeout);
> > > > return 0;
> > > > }
> > > > 
> > > 
> > > Please give this a try. I think on initialization
> > > intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> > > set and this results in a 10min timeout because our jiffies are set to
> > > ULONG_MAX - (10 * 60 * HZ);
> > 
> > After talking with kettenis@ I think the following diff is better.
> > Starting with 0 jiffies should fix this issue.
> > Unless we want to do the linux madness and set it to
> > ((unsigned long)(unsigned int) (-300*HZ))
> > 
> > -- 
> > :wq Claudio
> > 
> > Index: kern_clock.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_clock.c,v
> > retrieving revision 1.109
> > diff -u -p -r1.109 kern_clock.c
> > --- kern_clock.c25 Jul 2023 18:16:19 -  1.109
> > +++ kern_clock.c31 Jul 2023 20:01:57 -
> > @@ -84,7 +84,7 @@ int   profhz;
> >  intprofprocs;
> >  intticks = INT_MAX - (15 * 60 * HZ);
> >  
> > -volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
> > +volatile unsigned long jiffies;
> >  
> >  /*
> >   * Initialize clock frequencies and start both clocks running.
> > 
> 
> I think this is backwards.
> 
> Why are we changing the initial value of jiffies (wide) to resolve a
> problem with the initialization of one struct (narrow)?  Changing the
> initial value of jiffies just masks the root cause.
> 
> Isn't the right thing here to initialize the last-write timestamp when
> the struct is allocated?

This is all in code that is regularly synced with linux and so any local
change there is less then ideal. So it is better to alter the way jiffies
is initalized. jiffies is only there for drm so I don't think it is that
wide of a change.
Btw. on linux jiffies is initalized to:
#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))
and so the behaviour is different on 32 vs 64bit systems (which is the
worst possible default they could choose). So on the more common 64bit
systems the wrap around no longer happens early and bugs are introduced
because of this without anyone noticing.

Somebody could report this upstream since it is a bug in the intel drm
codebase.
-- 
:wq Claudio



Re: uvm_meter: remove wakeup of proc0

2023-07-31 Thread Scott Cheloha
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > > 
> > > schedule_timeout_uninterruptible(long timeout)
> > > {
> > > tsleep(curproc, PWAIT, "schtou", timeout);
> > > return 0;
> > > }
> > > 
> > 
> > Please give this a try. I think on initialization
> > intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> > set and this results in a 10min timeout because our jiffies are set to
> > ULONG_MAX - (10 * 60 * HZ);
> 
> After talking with kettenis@ I think the following diff is better.
> Starting with 0 jiffies should fix this issue.
> Unless we want to do the linux madness and set it to
>   ((unsigned long)(unsigned int) (-300*HZ))
> 
> -- 
> :wq Claudio
> 
> Index: kern_clock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.109
> diff -u -p -r1.109 kern_clock.c
> --- kern_clock.c  25 Jul 2023 18:16:19 -  1.109
> +++ kern_clock.c  31 Jul 2023 20:01:57 -
> @@ -84,7 +84,7 @@ int profhz;
>  int  profprocs;
>  int  ticks = INT_MAX - (15 * 60 * HZ);
>  
> -volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
> +volatile unsigned long jiffies;
>  
>  /*
>   * Initialize clock frequencies and start both clocks running.
> 

I think this is backwards.

Why are we changing the initial value of jiffies (wide) to resolve a
problem with the initialization of one struct (narrow)?  Changing the
initial value of jiffies just masks the root cause.

Isn't the right thing here to initialize the last-write timestamp when
the struct is allocated?



Re: uvm_meter: remove wakeup of proc0

2023-07-31 Thread Vitaliy Makkoveev
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > > 
> > > schedule_timeout_uninterruptible(long timeout)
> > > {
> > > tsleep(curproc, PWAIT, "schtou", timeout);
> > > return 0;
> > > }
> > > 
> > 
> > Please give this a try. I think on initialization
> > intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> > set and this results in a 10min timeout because our jiffies are set to
> > ULONG_MAX - (10 * 60 * HZ);
> 
> After talking with kettenis@ I think the following diff is better.
> Starting with 0 jiffies should fix this issue.
> Unless we want to do the linux madness and set it to
>   ((unsigned long)(unsigned int) (-300*HZ))
> 
> -- 
> :wq Claudio
> 
> Index: kern_clock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.109
> diff -u -p -r1.109 kern_clock.c
> --- kern_clock.c  25 Jul 2023 18:16:19 -  1.109
> +++ kern_clock.c  31 Jul 2023 20:01:57 -
> @@ -84,7 +84,7 @@ int profhz;
>  int  profprocs;
>  int  ticks = INT_MAX - (15 * 60 * HZ);
>  
> -volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
> +volatile unsigned long jiffies;
>  
>  /*
>   * Initialize clock frequencies and start both clocks running.
> 

This diff contains all of diffs you posted to this thread. Works fine
with hunks 1 and 2 together as with any of them separately.

Index: sys/dev/pci/drm/i915/display/intel_dp.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/display/intel_dp.c,v
retrieving revision 1.14
diff -u -p -r1.14 intel_dp.c
--- sys/dev/pci/drm/i915/display/intel_dp.c 28 Jul 2023 06:56:32 -  
1.14
+++ sys/dev/pci/drm/i915/display/intel_dp.c 31 Jul 2023 20:38:05 -
@@ -2228,6 +2228,8 @@ void intel_dp_wait_source_oui(struct int
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 
drm_dbg_kms(>drm, "Performing OUI wait\n");
+   if (intel_dp->last_oui_write == 0)
+   intel_dp->last_oui_write = jiffies;
wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
 }
 
Index: sys/kern/kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.109
diff -u -p -r1.109 kern_clock.c
--- sys/kern/kern_clock.c   25 Jul 2023 18:16:19 -  1.109
+++ sys/kern/kern_clock.c   31 Jul 2023 20:38:05 -
@@ -84,7 +84,7 @@ int   profhz;
 intprofprocs;
 intticks = INT_MAX - (15 * 60 * HZ);
 
-volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
+volatile unsigned long jiffies;
 
 /*
  * Initialize clock frequencies and start both clocks running.
Index: sys/uvm/uvm_meter.c
===
RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
retrieving revision 1.44
diff -u -p -r1.44 uvm_meter.c
--- sys/uvm/uvm_meter.c 21 Jun 2023 21:16:21 -  1.44
+++ sys/uvm/uvm_meter.c 31 Jul 2023 20:38:05 -
@@ -89,8 +89,6 @@ uvm_meter(void)
 {
if ((gettime() % 5) == 0)
uvm_loadav();
-   if (proc0.p_slptime > (maxslp / 2))
-   wakeup();
 }
 
 /*



Re: uvm_meter: remove wakeup of proc0

2023-07-31 Thread Vitaliy Makkoveev
On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > This is the culprit:
> > 
> > schedule_timeout_uninterruptible(long timeout)
> > {
> > tsleep(curproc, PWAIT, "schtou", timeout);
> > return 0;
> > }
> > 
> 
> Please give this a try. I think on initialization
> intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> set and this results in a 10min timeout because our jiffies are set to
> ULONG_MAX - (10 * 60 * HZ);
> 
> -- 
> :wq Claudio
> 
> Index: intel_dp.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/display/intel_dp.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 intel_dp.c
> --- intel_dp.c28 Jul 2023 06:56:32 -  1.14
> +++ intel_dp.c31 Jul 2023 19:39:37 -
> @@ -2228,6 +2228,8 @@ void intel_dp_wait_source_oui(struct int
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>  
>   drm_dbg_kms(>drm, "Performing OUI wait\n");
> + if (intel_dp->last_oui_write == 0)
> + intel_dp->last_oui_write = jiffies;
>   wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
>  }
>  

I tested this on top of initial uvm_meter() diff. Your third jiffies
diff was not applied. Works fine on affected gen 12 ALDERLAKE_P and
unaffected gen 4 core2quad. Also the inteldrm delay is shorter on
ALDERLAKE_P.

Will do separate test for jiffies diff.



Re: uvm_meter: remove wakeup of proc0

2023-07-31 Thread Chris Waddey
The jiffies patch plus the patch in uvm_meter worked for me. It even booted a
little faster than normal.

On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > > 
> > > schedule_timeout_uninterruptible(long timeout)
> > > {
> > > tsleep(curproc, PWAIT, "schtou", timeout);
> > > return 0;
> > > }
> > > 
> > 
> > Please give this a try. I think on initialization
> > intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> > set and this results in a 10min timeout because our jiffies are set to
> > ULONG_MAX - (10 * 60 * HZ);
> 
> After talking with kettenis@ I think the following diff is better.
> Starting with 0 jiffies should fix this issue.
> Unless we want to do the linux madness and set it to
>   ((unsigned long)(unsigned int) (-300*HZ))
> 
> -- 
> :wq Claudio
> 
> Index: kern_clock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.109
> diff -u -p -r1.109 kern_clock.c
> --- kern_clock.c  25 Jul 2023 18:16:19 -  1.109
> +++ kern_clock.c  31 Jul 2023 20:01:57 -
> @@ -84,7 +84,7 @@ int profhz;
>  int  profprocs;
>  int  ticks = INT_MAX - (15 * 60 * HZ);
>  
> -volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
> +volatile unsigned long jiffies;
>  
>  /*
>   * Initialize clock frequencies and start both clocks running.
> 



Re: uvm_meter: remove wakeup of proc0

2023-07-31 Thread Mikhail
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > > 
> > > schedule_timeout_uninterruptible(long timeout)
> > > {
> > > tsleep(curproc, PWAIT, "schtou", timeout);
> > > return 0;
> > > }
> > > 
> > 
> > Please give this a try. I think on initialization
> > intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> > set and this results in a 10min timeout because our jiffies are set to
> > ULONG_MAX - (10 * 60 * HZ);
> 
> After talking with kettenis@ I think the following diff is better.
> Starting with 0 jiffies should fix this issue.
> Unless we want to do the linux madness and set it to
>   ((unsigned long)(unsigned int) (-300*HZ))

This patch on top of the original one doesn't hang my machine anymore.



Re: uvm_meter: remove wakeup of proc0

2023-07-31 Thread Claudio Jeker
On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > This is the culprit:
> > 
> > schedule_timeout_uninterruptible(long timeout)
> > {
> > tsleep(curproc, PWAIT, "schtou", timeout);
> > return 0;
> > }
> > 
> 
> Please give this a try. I think on initialization
> intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> set and this results in a 10min timeout because our jiffies are set to
> ULONG_MAX - (10 * 60 * HZ);

After talking with kettenis@ I think the following diff is better.
Starting with 0 jiffies should fix this issue.
Unless we want to do the linux madness and set it to
((unsigned long)(unsigned int) (-300*HZ))

-- 
:wq Claudio

Index: kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.109
diff -u -p -r1.109 kern_clock.c
--- kern_clock.c25 Jul 2023 18:16:19 -  1.109
+++ kern_clock.c31 Jul 2023 20:01:57 -
@@ -84,7 +84,7 @@ int   profhz;
 intprofprocs;
 intticks = INT_MAX - (15 * 60 * HZ);
 
-volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
+volatile unsigned long jiffies;
 
 /*
  * Initialize clock frequencies and start both clocks running.



Re: uvm_meter: remove wakeup of proc0

2023-07-31 Thread Claudio Jeker
On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> This is the culprit:
> 
> schedule_timeout_uninterruptible(long timeout)
> {
> tsleep(curproc, PWAIT, "schtou", timeout);
> return 0;
> }
> 

Please give this a try. I think on initialization
intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
set and this results in a 10min timeout because our jiffies are set to
ULONG_MAX - (10 * 60 * HZ);

-- 
:wq Claudio

Index: intel_dp.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/display/intel_dp.c,v
retrieving revision 1.14
diff -u -p -r1.14 intel_dp.c
--- intel_dp.c  28 Jul 2023 06:56:32 -  1.14
+++ intel_dp.c  31 Jul 2023 19:39:37 -
@@ -2228,6 +2228,8 @@ void intel_dp_wait_source_oui(struct int
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 
drm_dbg_kms(>drm, "Performing OUI wait\n");
+   if (intel_dp->last_oui_write == 0)
+   intel_dp->last_oui_write = jiffies;
wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
 }
 



Re: uvm_meter: remove wakeup of proc0

2023-07-31 Thread Claudio Jeker
On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> This is the culprit:
> 
> schedule_timeout_uninterruptible(long timeout)
> {
> tsleep(curproc, PWAIT, "schtou", timeout);
> return 0;
> }

Not really. The problem is lower in intel_dp_wait_source_oui().
Which either missed the wakeup and still hit the
schedule_timeout_uninterruptible() codepath or the wakeup() was issued
before the tsleep(). In anycase something is not quite correct in that
codepath. Will look into it.

-- 
:wq Claudio



Re: uvm_meter: remove wakeup of proc0

2023-07-31 Thread Vitaliy Makkoveev
This is the culprit:

schedule_timeout_uninterruptible(long timeout)
{
tsleep(curproc, PWAIT, "schtou", timeout);
return 0;
}



Re: uvm_meter: remove wakeup of proc0

2023-07-31 Thread Claudio Jeker
On Sat, Jul 29, 2023 at 03:00:59PM +0300, Vitaliy Makkoveev wrote:
> On Sat, Jul 29, 2023 at 11:16:14AM +0200, Claudio Jeker wrote:
> > proc0 aka the swapper does not do anything. So there is no need to wake it
> > up. Now the problem is that last time this was tried some inteldrm systems
> > did hang during bootup because the drm code unexpectedly depended on this
> > wakeup.
> > 
> > I think I fixed all possible cases of this in the drm stack and so it is
> > time to retry this. People with affected machines please give this a try.
> > 
> 
> Hi,
> 
> With this diff "inteldrm0: msi, ALDERLAKE_P, gen 12" sticks after "root
> on ...", "inteldrm0: apic 4 int 16, G45, gen 4" works fine.

Would it be possible to get a backtrace of proc0 from the system that
hangs?

I think the simplest way is to:
1. boot -d
2. in ddb:
w db_console 1
c
3. once you hang on "root on" line. Hit ctrl-alt-esc
4. in ddb:
tr /t 0

Thanks.
-- 
:wq Claudio
 
> > -- 
> > :wq Claudio
> > 
> > Index: uvm/uvm_meter.c
> > ===
> > RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
> > retrieving revision 1.44
> > diff -u -p -r1.44 uvm_meter.c
> > --- uvm/uvm_meter.c 21 Jun 2023 21:16:21 -  1.44
> > +++ uvm/uvm_meter.c 29 Jul 2023 07:48:44 -
> > @@ -89,8 +89,6 @@ uvm_meter(void)
> >  {
> > if ((gettime() % 5) == 0)
> > uvm_loadav();
> > -   if (proc0.p_slptime > (maxslp / 2))
> > -   wakeup();
> >  }
> >  
> >  /*
> > 
> 



Re: uvm_meter: remove wakeup of proc0

2023-07-31 Thread Chris Waddey
On Sat, Jul 29, 2023 at 11:16:14AM +0200, Claudio Jeker wrote:
> proc0 aka the swapper does not do anything. So there is no need to wake it
> up. Now the problem is that last time this was tried some inteldrm systems
> did hang during bootup because the drm code unexpectedly depended on this
> wakeup.
> 
> I think I fixed all possible cases of this in the drm stack and so it is
> time to retry this. People with affected machines please give this a try.
> 
> -- 
> :wq Claudio
> 
> Index: uvm/uvm_meter.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 uvm_meter.c
> --- uvm/uvm_meter.c   21 Jun 2023 21:16:21 -  1.44
> +++ uvm/uvm_meter.c   29 Jul 2023 07:48:44 -
> @@ -89,8 +89,6 @@ uvm_meter(void)
>  {
>   if ((gettime() % 5) == 0)
>   uvm_loadav();
> - if (proc0.p_slptime > (maxslp / 2))
> - wakeup();
>  }
>  
>  /*
> 

I tried this again, but bootup still hung at "root on "

I do have some kernel customizations normally, but this patch, applied to my
custom kernel and to a generic one, causes boot to hang.

Here's the dmesg of my machine:

OpenBSD 7.3-current (NOAMDGPU.MP) #45: Mon Jul 31 08:59:16 MDT 2023
me@sonofthief.private:/home/me/src/sys/arch/amd64/compile/NOAMDGPU.MP
real mem = 8346333184 (7959MB)
avail mem = 8087310336 (7712MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x439de000 (69 entries)
bios0: vendor LENOVO version "FHCN54WW" date 07/05/2021
bios0: LENOVO 82FG
efi0 at bios0: UEFI 2.7
efi0: INSYDE Corp. rev 0x59474054
acpi0 at bios0: ACPI 6.1Undefined scope: \\_SB_.PCI0

acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT MSDM NHLT SSDT LPIT WSMT 
SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT SSDT FPDT PTDT BGRT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGA(S4) PEGP(S4) PEGP(S4) XHCI(S4) 
XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) 
RP04(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0: not present
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 4190.34 MHz, 06-8c-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,DOITM,FBSDP_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 8MB 64b/line 8-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 4190.35 MHz, 06-8c-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,DOITM,FBSDP_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 8MB 64b/line 8-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 3791.27 MHz, 06-8c-01
cpu2: 

Re: uvm_meter: remove wakeup of proc0

2023-07-29 Thread Mikhail
On Sat, Jul 29, 2023 at 11:16:14AM +0200, Claudio Jeker wrote:
> proc0 aka the swapper does not do anything. So there is no need to wake it
> up. Now the problem is that last time this was tried some inteldrm systems
> did hang during bootup because the drm code unexpectedly depended on this
> wakeup.
> 
> I think I fixed all possible cases of this in the drm stack and so it is
> time to retry this. People with affected machines please give this a try.

With this patch my machine hangs on "root on sd0a...", the patch was
applied on top of 7b0c383483702d9a26856c2b4754abb44950ed82, dmesg of the
last successful boot: 

OpenBSD 7.3-current (GENERIC.MP) #1320: Fri Jul 28 11:14:52 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8363110400 (7975MB)
avail mem = 8089972736 (7715MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x439de000 (70 entries)
bios0: vendor LENOVO version "GCCN32WW" date 11/18/2022
bios0: LENOVO 81X7
efi0 at bios0: UEFI 2.7
efi0: INSYDE Corp. rev 0x59474032
acpi0 at bios0: ACPI 6.1Undefined scope: \\_SB_.PCI0

acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT 
LPIT WSMT SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT 
BGRT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4) XDCI(S4) 
HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,DOITM,FBSDP_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.58 MHz, 06-8c-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,DOITM,FBSDP_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,DOITM,FBSDP_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
cpu3: 

Re: uvm_meter: remove wakeup of proc0

2023-07-29 Thread Vitaliy Makkoveev
On Sat, Jul 29, 2023 at 11:16:14AM +0200, Claudio Jeker wrote:
> proc0 aka the swapper does not do anything. So there is no need to wake it
> up. Now the problem is that last time this was tried some inteldrm systems
> did hang during bootup because the drm code unexpectedly depended on this
> wakeup.
> 
> I think I fixed all possible cases of this in the drm stack and so it is
> time to retry this. People with affected machines please give this a try.
> 

Hi,

With this diff "inteldrm0: msi, ALDERLAKE_P, gen 12" sticks after "root
on ...", "inteldrm0: apic 4 int 16, G45, gen 4" works fine.

> -- 
> :wq Claudio
> 
> Index: uvm/uvm_meter.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_meter.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 uvm_meter.c
> --- uvm/uvm_meter.c   21 Jun 2023 21:16:21 -  1.44
> +++ uvm/uvm_meter.c   29 Jul 2023 07:48:44 -
> @@ -89,8 +89,6 @@ uvm_meter(void)
>  {
>   if ((gettime() % 5) == 0)
>   uvm_loadav();
> - if (proc0.p_slptime > (maxslp / 2))
> - wakeup();
>  }
>  
>  /*
>