ksh.1: Add a missing Ns
Index: ksh.1 === RCS file: /cvs/src/bin/ksh/ksh.1,v retrieving revision 1.217 diff -u -p -r1.217 ksh.1 --- ksh.1 13 Sep 2022 20:26:26 - 1.217 +++ ksh.1 24 Dec 2022 17:22:08 - @@ -3454,9 +3454,7 @@ option is used, input is saved to the hi .It Xo .Ic readonly .Op Fl p -.Oo Ar parameter -.Op Ns = Ns Ar value -.Ar ... Oc +.Op Ar parameter Ns Oo = Ns Ar value Oc Ar ... .Xc Sets the read-only attribute of the named parameters. If values are given,
Re: LLVM 15: mismatched bound errors
On Sat, 24 Dec 2022 12:52:59 +0100, Patrick Wildt wrote: > Right, sorry for derailing the thread with a different discussion. > Here's a diff only for the array/ptr changes. OK millert@ After some testing this seems to only affect code where the prototype and the function declaration use a mix of [] and [SIZE] array syntax. Using [] for both seems fine as does mixing [] and normal pointer syntax. - todd
Re: futex(2): change FUTEX_WAIT wmesg: "fsleep" -> "ftxwait"
On Fri, Dec 23, 2022 at 05:20:54PM +0100, Mark Kettenis wrote: > > Date: Fri, 23 Dec 2022 08:37:43 -0600 > > From: Scott Cheloha > > > > The blocking futex operation is called FUTEX_WAIT. I think "ftxwait" > > is literally the perfect wmesg. > > > > "fsleep" is a lot less obvious. > > > > ok? > > Well, I know what "fsleep" is since it has been around for a while. > I'd have to re-learn "ftxwait". But see, you have already relearned it. That's why it's the *perfect* wmesg for this particular blocking operation. Look: FUTEX_WAIT -> futex_wait -> ftx_wait -> ftxwait :)
Re: LLVM 15: mismatched bound errors
On Sat, Dec 24, 2022 at 12:52:59PM +0100, Patrick Wildt wrote: > On Thu, Dec 22, 2022 at 01:14:57AM +0100, Patrick Wildt wrote: > > On Tue, Dec 20, 2022 at 05:48:41PM -0700, Todd C. Miller wrote: > > > On Tue, 20 Dec 2022 23:44:08 +0100, Patrick Wildt wrote: > > > > > > > clang complains when the function is declared with a fixed array size in > > > > a parameter while the prototype is unbounded, like this: > > > > > > > > /usr/src/sys/net/pf.c:4353:54: error: argument 'sns' of type 'struct > > > > pf_src_n > > > > ode *[4]' with mismatched bound [-Werror,-Warray-parameter] > > > > struct pf_rule_actions *act, struct pf_src_node *sns[PF_SN_MAX]) > > > > ^ > > > > /usr/src/sys/net/pf.c:203:28: note: previously declared as 'struct > > > > pf_src_nod > > > > e *[]' here > > > > struct pf_src_node *[]); > > > > ^ > > > > 1 error generated. > > > > > > > > We have a few of that, and was wondering what the better solution is. > > > > clang apparently accepts using * instead of []. The alternative would > > > > be to hardcode the size in the prototype as well. Here's a diff for > > > > a three files for the first version, as example. > > > > > > Using * instead of [] is the saner approach. Hard-coding the sizes > > > into the prototype seems like a bad idea, even if clang is now smart > > > enough to complain about a mismatch. > > > > > > - todd > > > > So, here's the full diff that allows me to compile arm64 GENERIC.MP, > > with radeondrm and amdgpu disabled. > > Right, sorry for derailing the thread with a different discussion. > Here's a diff only for the array/ptr changes. > > ok? ok tb
Re: LLVM 15: mismatched bound errors
On Thu, Dec 22, 2022 at 01:14:57AM +0100, Patrick Wildt wrote:
> On Tue, Dec 20, 2022 at 05:48:41PM -0700, Todd C. Miller wrote:
> > On Tue, 20 Dec 2022 23:44:08 +0100, Patrick Wildt wrote:
> >
> > > clang complains when the function is declared with a fixed array size in
> > > a parameter while the prototype is unbounded, like this:
> > >
> > > /usr/src/sys/net/pf.c:4353:54: error: argument 'sns' of type 'struct
> > > pf_src_n
> > > ode *[4]' with mismatched bound [-Werror,-Warray-parameter]
> > > struct pf_rule_actions *act, struct pf_src_node *sns[PF_SN_MAX])
> > > ^
> > > /usr/src/sys/net/pf.c:203:28: note: previously declared as 'struct
> > > pf_src_nod
> > > e *[]' here
> > > struct pf_src_node *[]);
> > > ^
> > > 1 error generated.
> > >
> > > We have a few of that, and was wondering what the better solution is.
> > > clang apparently accepts using * instead of []. The alternative would
> > > be to hardcode the size in the prototype as well. Here's a diff for
> > > a three files for the first version, as example.
> >
> > Using * instead of [] is the saner approach. Hard-coding the sizes
> > into the prototype seems like a bad idea, even if clang is now smart
> > enough to complain about a mismatch.
> >
> > - todd
>
> So, here's the full diff that allows me to compile arm64 GENERIC.MP,
> with radeondrm and amdgpu disabled.
Right, sorry for derailing the thread with a different discussion.
Here's a diff only for the array/ptr changes.
ok?
Patrick
diff --git a/sys/crypto/sha2.c b/sys/crypto/sha2.c
index f789ef3f55b..b2b79f286f3 100644
--- a/sys/crypto/sha2.c
+++ b/sys/crypto/sha2.c
@@ -470,7 +470,7 @@ SHA256Update(SHA2_CTX *context, const void *dataptr, size_t
len)
}
void
-SHA256Final(u_int8_t digest[], SHA2_CTX *context)
+SHA256Final(u_int8_t *digest, SHA2_CTX *context)
{
unsigned intusedspace;
@@ -795,7 +795,7 @@ SHA512Last(SHA2_CTX *context)
}
void
-SHA512Final(u_int8_t digest[], SHA2_CTX *context)
+SHA512Final(u_int8_t *digest, SHA2_CTX *context)
{
SHA512Last(context);
@@ -834,7 +834,7 @@ SHA384Update(SHA2_CTX *context, const void *data, size_t
len)
}
void
-SHA384Final(u_int8_t digest[], SHA2_CTX *context)
+SHA384Final(u_int8_t *digest, SHA2_CTX *context)
{
SHA512Last(context);
diff --git a/sys/dev/ic/ar5008.c b/sys/dev/ic/ar5008.c
index cad0f142210..4c0126fd6d6 100644
--- a/sys/dev/ic/ar5008.c
+++ b/sys/dev/ic/ar5008.c
@@ -111,7 +111,7 @@ voidar5008_next_calib(struct athn_softc *);
void ar5008_calib_iq(struct athn_softc *);
void ar5008_calib_adc_gain(struct athn_softc *);
void ar5008_calib_adc_dc_off(struct athn_softc *);
-void ar5008_write_txpower(struct athn_softc *, int16_t power[]);
+void ar5008_write_txpower(struct athn_softc *, int16_t *);
void ar5008_set_viterbi_mask(struct athn_softc *, int);
void ar5008_hw_init(struct athn_softc *, struct ieee80211_channel *,
struct ieee80211_channel *);
@@ -119,9 +119,9 @@ uint8_t ar5008_get_vpd(uint8_t, const uint8_t *, const
uint8_t *, int);
void ar5008_get_pdadcs(struct athn_softc *, uint8_t, struct athn_pier *,
struct athn_pier *, int, int, uint8_t, uint8_t *, uint8_t *);
void ar5008_get_lg_tpow(struct athn_softc *, struct ieee80211_channel *,
- uint8_t, const struct ar_cal_target_power_leg *, int, uint8_t[]);
+ uint8_t, const struct ar_cal_target_power_leg *, int, uint8_t *);
void ar5008_get_ht_tpow(struct athn_softc *, struct ieee80211_channel *,
- uint8_t, const struct ar_cal_target_power_ht *, int, uint8_t[]);
+ uint8_t, const struct ar_cal_target_power_ht *, int, uint8_t *);
void ar5008_set_noise_immunity_level(struct athn_softc *, int);
void ar5008_enable_ofdm_weak_signal(struct athn_softc *);
void ar5008_disable_ofdm_weak_signal(struct athn_softc *);
diff --git a/sys/dev/ic/ar9003.c b/sys/dev/ic/ar9003.c
index 565ea27c701..7ec3131f86b 100644
--- a/sys/dev/ic/ar9003.c
+++ b/sys/dev/ic/ar9003.c
@@ -114,7 +114,7 @@ int ar9003_init_calib(struct athn_softc *);
void ar9003_do_calib(struct athn_softc *);
void ar9003_next_calib(struct athn_softc *);
void ar9003_calib_iq(struct athn_softc *);
-intar9003_get_iq_corr(struct athn_softc *, int32_t[], int32_t[]);
+intar9003_get_iq_corr(struct athn_softc *, int32_t *, int32_t *);
intar9003_calib_tx_iq(struct athn_softc *);
void ar9003_paprd_calib(struct athn_softc *, struct ieee80211_channel *);
intar9003_get_desired_txgain(struct athn_softc *, int, int);
@@ -126,17 +126,17 @@ int ar9003_compute_predistortion(struct athn_softc
*, const uint32_t *,
void ar9003_enable_predistorter(struct athn_softc *, int);
void ar9003_paprd_enable(struct athn_softc *);
void ar9003_paprd_tx_tone_done(struct athn_softc *);
-void ar9003_write_txpower(struct athn_softc *,
Re: units(1): support personal library
On Sat, Dec 24, 2022 at 11:56:37AM +0100, Florian Obser wrote: > This is at least supported by FreeBSD's units(1) as well as by > systemd/Linux. Looks good, just one typo noted below: > > diff --git units.1 units.1 > index d7a45f729b3..916d1b03d32 100644 > --- units.1 > +++ units.1 > @@ -79,6 +79,11 @@ The options are as follows: > .Bl -tag -width Ds > .It Fl f Ar filename > Specifies the name of the units data file to load. > +This options may be specified multiple times. s/options/option/
units(1): support personal library
This is at least supported by FreeBSD's units(1) as well as by
systemd/Linux.
With a personal library like this:
$ cat ~/units.lib
assload 8 stone
butt2 hogshead
buttload6 seams
solarmass 1.98847e30 kg
I can convert my mass into more convenient units:
$ units -f '' -f ~/units.lib
622 units, 67 prefixes
You have: 93 kg
You want: assloads
* 1.8306241
/ 0.54626178
You have: 93 kg
You want: solarmasses
* 4.6769627e-29
/ 2.1381398e+28
Note that the imperial buttload is a unit of volume while the assload is a unit
of mass:
You have: buttload
You want: assload
conformability error
1.6914754 m^3
50.802345 kg
On the other hand, you need about 4^28 standard donkeys to lug the sun
around:
You have: solarmass
You want: assload
* 3.9141303e+28
/ 2.554846e-29
OK?
diff --git units.1 units.1
index d7a45f729b3..916d1b03d32 100644
--- units.1
+++ units.1
@@ -79,6 +79,11 @@ The options are as follows:
.Bl -tag -width Ds
.It Fl f Ar filename
Specifies the name of the units data file to load.
+This options may be specified multiple times.
+The standard units library is read if
+.Ar filename
+is the empty string.
+This allows extending the standard units library with a personal library.
.It Fl q
Suppresses prompting of the user for units and the display of statistics
about the number of units loaded.
diff --git units.c units.c
index 98af5031fb1..488795c78cb 100644
--- units.c
+++ units.c
@@ -100,7 +100,6 @@ readunits(char *userfile)
int len, linenum, i;
FILE *unitfile;
- unitcount = 0;
linenum = 0;
if (userfile) {
@@ -626,8 +625,7 @@ main(int argc, char **argv)
struct unittype have, want;
char havestr[81], wantstr[81];
int optchar;
- char *userfile = 0;
- int quiet = 0;
+ int quiet = 0, units_read = 0;
extern char *optarg;
extern int optind;
@@ -638,7 +636,8 @@ main(int argc, char **argv)
while ((optchar = getopt(argc, argv, "vqf:")) != -1) {
switch (optchar) {
case 'f':
- userfile = optarg;
+ units_read = 1;
+ readunits(*optarg == '\0' ? NULL : optarg);
break;
case 'q':
quiet = 1;
@@ -662,7 +661,8 @@ main(int argc, char **argv)
if (argc != 3 && argc != 2 && argc != 0)
usage();
- readunits(userfile);
+ if (!units_read)
+ readunits(NULL);
if (pledge("stdio", NULL) == -1)
err(1, "pledge");
--
I'm not entirely sure you are real.
Re: sparc64: pull retry logic out of tickcmpr_set(), sys_tickcmr_set()
> Date: Thu, 22 Dec 2022 17:08:12 -0600
> From: Scott Cheloha
>
> To keep the %TICK and %SYS_TICK code aligned with the Hummingbird
> %STICK code, let's pull the retry logic out of tickcmpr_set() and
> sys_tickcmpr_set() into tick_rearm() and sys_tick_rearm(),
> respectively.
>
> As far as I know, the retry logic in these assembly routines is not
> defective, but keeping equivalent code similar is good and it doesn't
> hurt to have less assembly code where it isn't strictly necessary.
>
> With this complete, we can then rebase and retry the clockintr switch
> patch for sparc64.
>
> ok?
ok kettenis@ (provided this has been lightly tested)
> Index: clock.c
> ===
> RCS file: /cvs/src/sys/arch/sparc64/sparc64/clock.c,v
> retrieving revision 1.73
> diff -u -p -r1.73 clock.c
> --- clock.c 22 Dec 2022 19:51:11 - 1.73
> +++ clock.c 22 Dec 2022 23:04:49 -
> @@ -150,6 +150,8 @@ void tick_start(void);
> void sys_tick_start(void);
> void stick_start(void);
>
> +void tick_rearm(uint64_t);
> +void sys_tick_rearm(uint64_t);
> void stick_rearm(uint64_t);
>
> int tickintr(void *);
> @@ -766,7 +768,7 @@ tickintr(void *cap)
>
> /* Reset the interrupt. */
> s = intr_disable();
> - tickcmpr_set(ci->ci_tick);
> + tick_rearm(ci->ci_tick);
> intr_restore(s);
>
> return (1);
> @@ -789,7 +791,7 @@ sys_tickintr(void *cap)
>
> /* Reset the interrupt. */
> s = intr_disable();
> - sys_tickcmpr_set(ci->ci_tick);
> + sys_tick_rearm(ci->ci_tick);
> intr_restore(s);
>
> return (1);
> @@ -875,18 +877,28 @@ tick_start(void)
>
> tick_enable();
>
> - /*
> - * Try to make the tick interrupts as synchronously as possible on
> - * all CPUs to avoid inaccuracies for migrating processes.
> - */
> -
> s = intr_disable();
> - ci->ci_tick = roundup(tick(), tick_increment);
> - tickcmpr_set(ci->ci_tick);
> + ci->ci_tick = tick();
> + tick_rearm(ci->ci_tick);
> intr_restore(s);
> }
>
> void
> +tick_rearm(uint64_t cmp)
> +{
> + uint64_t now, off = 8;
> +
> + tickcmpr_set(cmp);
> + now = tick();
> + while (cmp <= now) {
> + cmp += off;
> + tickcmpr_set(cmp);
> + now = tick();
> + off *= 2;
> + }
> +}
> +
> +void
> sys_tick_start(void)
> {
> struct cpu_info *ci = curcpu();
> @@ -897,29 +909,34 @@ sys_tick_start(void)
> sys_tick_enable();
> }
>
> - /*
> - * Try to make the tick interrupts as synchronously as possible on
> - * all CPUs to avoid inaccuracies for migrating processes.
> - */
> -
> s = intr_disable();
> - ci->ci_tick = roundup(sys_tick(), tick_increment);
> - sys_tickcmpr_set(ci->ci_tick);
> + ci->ci_tick = sys_tick();
> + sys_tick_rearm(ci->ci_tick);
> intr_restore(s);
> }
>
> void
> +sys_tick_rearm(uint64_t cmp)
> +{
> + uint64_t now, off = 8;
> +
> + sys_tickcmpr_set(cmp);
> + now = sys_tick();
> + while (cmp <= now) {
> + cmp += off;
> + sys_tickcmpr_set(cmp);
> + now = sys_tick();
> + off *= 2;
> + }
> +}
> +
> +void
> stick_start(void)
> {
> struct cpu_info *ci = curcpu();
> u_int64_t s;
>
> tick_enable();
> -
> - /*
> - * Try to make the tick interrupts as synchronously as possible on
> - * all CPUs to avoid inaccuracies for migrating processes.
> - */
>
> s = intr_disable();
> ci->ci_tick = stick();
> Index: locore.s
> ===
> RCS file: /cvs/src/sys/arch/sparc64/sparc64/locore.s,v
> retrieving revision 1.195
> diff -u -p -r1.195 locore.s
> --- locore.s 22 Dec 2022 19:51:11 - 1.195
> +++ locore.s 22 Dec 2022 23:04:51 -
> @@ -7477,22 +7477,9 @@ END(tick_enable)
> * sure those two instructions are in the same cache line.
> */
> ENTRY(tickcmpr_set)
> - ba 1f
> - mov8, %o2 ! Initial step size
> .align 64
> -1: wr %o0, 0, %tick_cmpr
> + wr %o0, 0, %tick_cmpr
> rd %tick_cmpr, %g0
> -
> - rd %tick, %o1 ! Read current %tick
> - sllx%o1, 1, %o1
> - srlx%o1, 1, %o1
> -
> - cmp %o0, %o1! Make sure the value we wrote to
> - bg,pt %xcc, 2f! %tick_cmpr was in the future.
> - add%o0, %o2, %o0 ! If not, add the step size, double
> - ba,pt %xcc, 1b! the step size and try again.
> - sllx %o2, 1, %o2
> -2:
> retl
>nop
> END(tickcmpr_set)
> @@ -7518,22 +7505,9 @@ ENTRY(sys_tick_enable)
> END(sys_tick_enable)
>
> ENTRY(sys_tickcmpr_set)
> - ba 1f
> - mov8, %o2 ! Initial step size
> .align 64
> -1: wr %o0, 0,
Re: sxitimer(4): switch to clockintr
> Date: Wed, 14 Dec 2022 17:57:10 -0600
> From: Scott Cheloha
>
> On Wed, Dec 14, 2022 at 11:45:31PM +0100, Mark Kettenis wrote:
> > > Date: Fri, 9 Dec 2022 11:28:43 -0600
> > > From: Scott Cheloha
> > >
> > > sxitimer(4) is the fourth and final armv7 clock interrupt driver that
> > > needs to switch to clockintr.
> > >
> > > - Remove everything related to STATTIMER. We can multiplex TICKTIMER
> > > to handle all clock interrupt events.
> > > - Remove sxitimer-specific clock interrupt scheduling bits and randomized
> > > statclock bits.
> > > - Wire up sxitimer_intrclock.
> > >
> > > This is not compile-tested. When we get it to compile, it ought to
> > > survive a release build if that's practical for machines sporting
> > > sxitimer(4).
> > >
> > > What sort of machine has one of these?
> >
> > This diff builds and seems to work. I only managed to do some limited
> > testing by building some kernels. But it keeps time like it should
> > even under load. What I did notice that I get ~230 "tick" interrupts
> > per second. Wheras on the agtimer(4) box I only got ~200. Is that
> > because you still set stathz to 128? It seems weird to keep that
> > number now that you don't use separate counters anymore and have
> > statclock randomization.
>
> You're right, I just didn't want to change anything that wasn't
> absolutely necessary until we knew it worked.
>
> Here is a patch that uses (stathz = hz) and (profhz = stathz * 10).
>
> I can commit it together with the clockintr switch or do it
> separately, whatever you prefer.
Also works. I prefer this version.
> > Otherwise, the diff looks reasonable to me. Unfortunately my uSD card
> > managed to make itself read-only while checking out a tree. I was
> > running a kernel without your diff at the time, so this has nothing to
> > do with your diff. But it means that further testing will be delayed.
>
> No worries, thanks for testing.
>
> Index: sys/arch/armv7/sunxi/sxitimer.c
> ===
> RCS file: /cvs/src/sys/arch/armv7/sunxi/sxitimer.c,v
> retrieving revision 1.18
> diff -u -p -r1.18 sxitimer.c
> --- sys/arch/armv7/sunxi/sxitimer.c 24 Oct 2021 17:52:28 - 1.18
> +++ sys/arch/armv7/sunxi/sxitimer.c 14 Dec 2022 23:55:45 -
> @@ -20,7 +20,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
>
> #include
> @@ -94,6 +96,17 @@ static struct timecounter sxitimer_timec
> .tc_user = 0,
> };
>
> +uint64_t sxitimer_nsec_cycle_ratio;
> +uint64_t sxitimer_nsec_max;
> +
> +void sxitimer_rearm(void *, uint64_t);
> +void sxitimer_trigger(void *);
> +
> +const struct intrclock sxitimer_intrclock = {
> + .ic_rearm = sxitimer_rearm,
> + .ic_trigger = sxitimer_trigger
> +};
> +
> bus_space_tag_t sxitimer_iot;
> bus_space_handle_t sxitimer_ioh;
>
> @@ -111,11 +124,6 @@ uint32_t sxitimer_irq[] = {
> 0
> };
>
> -uint32_t sxitimer_stat_tpi, sxitimer_tick_tpi;
> -uint32_t sxitimer_statvar, sxitimer_statmin;
> -uint32_t sxitimer_tick_nextevt, sxitimer_stat_nextevt;
> -uint32_t sxitimer_ticks_err_cnt, sxitimer_ticks_err_sum;
> -
> struct sxitimer_softc {
> struct device sc_dev;
> };
> @@ -147,7 +155,6 @@ void
> sxitimer_attach(struct device *parent, struct device *self, void *aux)
> {
> struct fdt_attach_args *faa = aux;
> - uint32_t freq, ival, now;
>
> KASSERT(faa->fa_nreg > 0);
>
> @@ -163,61 +170,31 @@ sxitimer_attach(struct device *parent, s
> & CNT64_CLR_EN)
> continue;
>
> - /* timers are down-counters, from interval to 0 */
> - now = 0x; /* known big value */
> - freq = sxitimer_freq[TICKTIMER];
> -
> /* stop timer, and set clk src */
> bus_space_write_4(sxitimer_iot, sxitimer_ioh,
> TIMER_CTRL(TICKTIMER), TIMER_OSC24M);
>
> - ival = sxitimer_tick_tpi = freq / hz;
> - sxitimer_tick_nextevt = now - ival;
> -
> - sxitimer_ticks_err_cnt = freq % hz;
> - sxitimer_ticks_err_sum = 0;
> -
> - bus_space_write_4(sxitimer_iot, sxitimer_ioh,
> - TIMER_INTV(TICKTIMER), ival);
> -
> - /* timers are down-counters, from interval to 0 */
> - now = 0x; /* known big value */
> - freq = sxitimer_freq[STATTIMER];
> -
> - /* stop timer, and set clk src */
> - bus_space_write_4(sxitimer_iot, sxitimer_ioh,
> - TIMER_CTRL(STATTIMER), TIMER_OSC24M);
> -
> - /* 100/1000 or 128/1024 ? */
> - stathz = 128;
> - profhz = 1024;
> - sxitimer_setstatclockrate(stathz);
> -
> - ival = sxitimer_stat_tpi = freq / stathz;
> - sxitimer_stat_nextevt = now - ival;
> -
> - bus_space_write_4(sxitimer_iot, sxitimer_ioh,
> - TIMER_INTV(STATTIMER), ival);
> -
> - /* timers are down-counters, from interval to 0 */
> - now = 0x; /* known big value */
> - freq = sxitimer_freq[CNTRTIMER];
> +
Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen
> From: Abel Abraham Camarillo Ojeda > Date: Sat, 24 Dec 2022 04:09:42 -0600 > > Notice it only fails *sometimes*, sometimes after the first unhibernate I > cannot get to hibernate/suspend again. > Sometimes I can get several hibernate/unhibernate cycles where everything > works... > > Will try to reproduce and check apmd debug. > > I know almost nothing about unhibernate, one should expect different > dmesgs from it than from cold boot? > will try to compare them, in case its useful Probably the acpi thread gets stuck.
Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen
Notice it only fails *sometimes*, sometimes after the first unhibernate I cannot get to hibernate/suspend again. Sometimes I can get several hibernate/unhibernate cycles where everything works... Will try to reproduce and check apmd debug. I know almost nothing about unhibernate, one should expect different dmesgs from it than from cold boot? will try to compare them, in case its useful Thanks
Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen
On Fri Dec 23, 2022 at 10:13 PM CET, Abel Abraham Camarillo Ojeda wrote: > On Fri, Dec 23, 2022 at 2:46 PM Abel Abraham Camarillo Ojeda < > acam...@verlet.org> wrote: > > > Forgot to mention I don't think this is a regression, just started to use > > hibernate/unhibernate more often lately. > > But I think I can reproduce this at least since 6.8 (the first that I > > installed to this machine) > > > >> > >> > >> But still this apply https://www.openbsd.org/report.html (point 2) > >> > > > > By doesn't work I mean: > > > > $ zzz > > Suspending system... > > $ (nothing happened) > > > > > real mem = 17021566976 (16233MB) > >> > avail mem = 16488275968 (15724MB) > >> > random: good seed from bootblocks > >> > mpath0 at root > >> > scsibus0 at mpath0: 256 targets > >> > mainbus0 at root > >> > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xb9908000 (58 entries) > >> > bios0: vendor LENOVO version "R0GET56W (1.56 )" date 08/31/2017 > >> > >> You should try > >> https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-l-series-laptops/thinkpad-l470/downloads/ds120327 > >> and see if problem is still present (of course good to have backup :-)) > >> > > > > yes, forgot about that. Will update bios and retry > > > > machine now with bios updated, can reproduce issue after 1 unhibernate, > dmesg right now at "zzz does nothing stage": > Did you try with apmd in debug mode (-d) to see if anything is received over socket? > OpenBSD 7.2-current (GENERIC.MP) #840: Thu Nov 17 08:21:23 MST 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17021566976 (16233MB) > avail mem = 16488275968 (15724MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xb9908000 (58 entries) > bios0: vendor LENOVO version "R0GET79W (1.79 )" date 07/28/2022 > bios0: LENOVO 20JVS17D00 > efi0 at bios0: UEFI 2.5 > efi0: Lenovo rev 0x1790 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 S3 state which is sleep is here > acpi0: tables DSDT FACP UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT BOOT BATB > SLIC SSDT SSDT WSMT SSDT SSDT DBGP DBG2 MSDM DMAR ASF! FPDT UEFI > acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) RP02(S4) but wake up is supported only from XHC_ (not sure if that is USB-C which is not supported on OpenBSD yet if I am correct. Regular xhci(4) would be here as XHCI(S3)) > RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) RP09(S4) RP10(S4) RP11(S4) > RP12(S4) RP13(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 2399 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2959.28 MHz, 06-4e-03 > 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,SMX,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 4-way L2 cache, 3MB 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 24MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2860.64 MHz, 06-4e-03 > 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,SMX,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 4-way L2 cache, 3MB 64b/line 12-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 1 (application processor) > cpu2: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2860.64 MHz, 06-4e-03 > cpu2: >
