Re: M1 Macmini lost hw.cpuspeed
On 24/10/22 14:49 +0200, Theo Buehler wrote: > On Mon, Oct 24, 2022 at 09:24:14AM +0200, Otto Moerbeek wrote: > > Hello, > > > > after updating my M1 macmini after my vacatiuon to the latest snap it > > seems to have lost a few sysctl nodes, making apm(8) fail: > > > > [otto@macmini:4]$ ktrace apm > > Battery state: unknown, 0% remaining, unknown life estimate > > AC adapter state: not known > > Performance adjustment mode: invalid (0 MHz) > > > > ... > > 88255 apm CALL sysctl(6.12,0x7f10d4,0x7f10c8,0,0) > > 88255 apm RET sysctl -1 errno 45 Operation not supported > > ... > > > > > > Beforre I spend time on this, does anybody have a clue? > > > > -Otto > > > > I'm seeing the same on my m1 mini. Reverting the commit below fixes it > for me. Maybe you need a new u-boot that has the new tree?
Re: apldckbd(4): add fn key combose for Page Up/Down
On 16/09/22 13:20 +, Miod Vallat wrote:
> > I've also removed the hidkbd_apple_mba_iso_munge() function as it is
> > the same as hidkbd_apple_iso_munge() so this also cleans up the switch
> > in ukbd.c
>
> Oh no, it isn't.
>
> See, you are in a maze of twisty little functions, all alike.
>
> The current state of ukbd has four apple munge routines:
>
> - "apple": invoke hid_get_data to get extra keys, then applies table
> - "apple_mba": invoke hid_get_data to get extra keys, then applies a
> different table
> - "apple_iso": applies small iso table, then invokes "apple" munge
> - "apple_iso_mba": applies small iso table, then invokes "apple_mba"
> munge.
>
> Because the tables used by "apple" and "apple_mba" differ, their iso
> flavours need to be kept separate.
ahh good catch, i completely missed applying the 2nd tables in the iso
case ...
rev unlimited:
Index: arch/arm64/dev/apldc.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/apldc.c,v
retrieving revision 1.3
diff -u -p -u -r1.3 apldc.c
--- arch/arm64/dev/apldc.c 15 Sep 2022 14:45:49 - 1.3
+++ arch/arm64/dev/apldc.c 16 Sep 2022 14:06:01 -
@@ -1066,22 +1066,6 @@ struct apldckbd_softc {
struct apldchidev_softc *sc_hidev;
struct hidkbd sc_kbd;
int sc_spl;
- struct hid_location sc_fn;
- int sc_has_fn;
-};
-
-struct apldckbd_translation {
- uint8_t original;
- uint8_t translation;
-};
-
-static const struct apldckbd_translation apldckbd_trans_table[] = {
- { 40, 73 }, /* return -> insert */
- { 42, 76 }, /* backspace -> delete */
- { 79, 77 }, /* right -> end */
- { 80, 74 }, /* left -> home */
- { 81, 78 }, /* down -> page down */
- { 82, 75 } /* up -> page up */
};
void apldckbd_cngetc(void *, u_int *, int *);
@@ -1138,8 +1122,9 @@ apldckbd_attach(struct device *parent, s
printf("\n");
- sc->sc_has_fn = hid_locate(aa->aa_desc, aa->aa_desclen,
- HID_USAGE2(HUP_APPLE, HUG_FN_KEY), 1, hid_input, &sc->sc_fn, NULL);
+ if (hid_locate(aa->aa_desc, aa->aa_desclen, HID_USAGE2(HUP_APPLE,
HUG_FN_KEY),
+ 1, hid_input, &kbd->sc_fn, NULL))
+ kbd->sc_munge = hidkbd_apple_munge;
if (kbd->sc_console_keyboard) {
extern struct wskbd_mapdata ukbd_keymapdata;
@@ -1153,40 +1138,13 @@ apldckbd_attach(struct device *parent, s
}
void
-apldckbd_munge(void *v, uint8_t *ibuf, size_t ilen)
-{
- struct apldckbd_softc *sc = v;
- struct hidkbd *kbd = &sc->sc_kbd;
- uint8_t *pos, *spos, *epos;
- const struct apldckbd_translation *tbl;
- size_t tsize;
-
- if (!hid_get_data(ibuf, ilen, &sc->sc_fn))
- return;
-
- spos = ibuf + kbd->sc_keycodeloc.pos / 8;
- epos = spos + kbd->sc_nkeycode;
-
- for (pos = spos; pos != epos; pos++) {
- tbl = apldckbd_trans_table;
- tsize = nitems(apldckbd_trans_table);
- for (; tsize != 0; tbl++, tsize--)
- if (tbl->original == *pos)
- *pos = tbl->translation;
- }
-}
-
-void
apldckbd_intr(struct device *self, uint8_t *packet, size_t packetlen)
{
struct apldckbd_softc *sc = (struct apldckbd_softc *)self;
struct hidkbd *kbd = &sc->sc_kbd;
- if (kbd->sc_enabled) {
- if (sc->sc_has_fn)
- apldckbd_munge(sc, &packet[1], packetlen - 1);
+ if (kbd->sc_enabled)
hidkbd_input(kbd, &packet[1], packetlen - 1);
- }
}
int
Index: arch/arm64/dev/aplhidev.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/aplhidev.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 aplhidev.c
--- arch/arm64/dev/aplhidev.c 6 Apr 2022 18:59:26 - 1.6
+++ arch/arm64/dev/aplhidev.c 16 Sep 2022 14:06:01 -
@@ -459,6 +459,10 @@ aplkbd_attach(struct device *parent, str
printf("\n");
+ if (hid_locate(aa->aa_desc, aa->aa_desclen, HID_USAGE2(HUP_APPLE,
HUG_FN_KEY),
+ 1, hid_input, &kbd->sc_fn, NULL))
+ kbd->sc_munge = hidkbd_apple_munge;
+
if (kbd->sc_console_keyboard) {
extern struct wskbd_mapdata ukbd_keymapdata;
Index: dev/hid/hidkbd.c
===
RCS file: /cvs/src/sys/dev/hid/hidkbd.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 hidkbd.c
--- dev/hid/hidkbd.c2 Nov 2020 19:45:18 - 1.6
+++ dev/hid/hidkbd.c16 Sep 2022 14:06:01 -
@@ -108,6 +108,67 @@ const u_int8_t hidkbd_trtab[256] = {
};
#endif /* defined(WSDISPLAY_COMPAT_RAWKBD) */
+static const struct hidkbd_translation apple_fn_trans[] = {
+ { 40, 73 }, /* return -> insert */
+ { 42, 76 }, /* backspace -> del
Re: apldckbd(4): add fn key combose for Page Up/Down
On 16/09/22 13:03 +, Miod Vallat wrote:
> > rev3:
>
> Almost there! Minor nits below, then ok.
>
> > Index: dev/hid/hidkbd.c
>
> > +static const struct hidkbd_translation apple_iso_trans[] = {
> > + { 53, 100 },/* less -> grave */
> > + { 100, 53 }
> > +};
> > +
> > +static const struct hidkbd_translation apple_iso_mba_trans[] = {
> > + { 53, 100 },/* less -> grave */
> > + { 100, 53 }
> > +};
>
> No need for two copies of that table. Keep the first one (shortest
> name) and update hidkbd_apple_mba_munge() accordingly.
I've also removed the hidkbd_apple_mba_iso_munge() function as it is
the same as hidkbd_apple_iso_munge() so this also cleans up the switch
in ukbd.c
i would love some ukbd tests before this gets in though
Index: arch/arm64/dev/apldc.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/apldc.c,v
retrieving revision 1.3
diff -u -p -u -r1.3 apldc.c
--- arch/arm64/dev/apldc.c 15 Sep 2022 14:45:49 - 1.3
+++ arch/arm64/dev/apldc.c 16 Sep 2022 13:11:45 -
@@ -1066,22 +1066,6 @@ struct apldckbd_softc {
struct apldchidev_softc *sc_hidev;
struct hidkbd sc_kbd;
int sc_spl;
- struct hid_location sc_fn;
- int sc_has_fn;
-};
-
-struct apldckbd_translation {
- uint8_t original;
- uint8_t translation;
-};
-
-static const struct apldckbd_translation apldckbd_trans_table[] = {
- { 40, 73 }, /* return -> insert */
- { 42, 76 }, /* backspace -> delete */
- { 79, 77 }, /* right -> end */
- { 80, 74 }, /* left -> home */
- { 81, 78 }, /* down -> page down */
- { 82, 75 } /* up -> page up */
};
void apldckbd_cngetc(void *, u_int *, int *);
@@ -1138,8 +1122,9 @@ apldckbd_attach(struct device *parent, s
printf("\n");
- sc->sc_has_fn = hid_locate(aa->aa_desc, aa->aa_desclen,
- HID_USAGE2(HUP_APPLE, HUG_FN_KEY), 1, hid_input, &sc->sc_fn, NULL);
+ if (hid_locate(aa->aa_desc, aa->aa_desclen, HID_USAGE2(HUP_APPLE,
HUG_FN_KEY),
+ 1, hid_input, &kbd->sc_fn, NULL))
+ kbd->sc_munge = hidkbd_apple_munge;
if (kbd->sc_console_keyboard) {
extern struct wskbd_mapdata ukbd_keymapdata;
@@ -1153,40 +1138,13 @@ apldckbd_attach(struct device *parent, s
}
void
-apldckbd_munge(void *v, uint8_t *ibuf, size_t ilen)
-{
- struct apldckbd_softc *sc = v;
- struct hidkbd *kbd = &sc->sc_kbd;
- uint8_t *pos, *spos, *epos;
- const struct apldckbd_translation *tbl;
- size_t tsize;
-
- if (!hid_get_data(ibuf, ilen, &sc->sc_fn))
- return;
-
- spos = ibuf + kbd->sc_keycodeloc.pos / 8;
- epos = spos + kbd->sc_nkeycode;
-
- for (pos = spos; pos != epos; pos++) {
- tbl = apldckbd_trans_table;
- tsize = nitems(apldckbd_trans_table);
- for (; tsize != 0; tbl++, tsize--)
- if (tbl->original == *pos)
- *pos = tbl->translation;
- }
-}
-
-void
apldckbd_intr(struct device *self, uint8_t *packet, size_t packetlen)
{
struct apldckbd_softc *sc = (struct apldckbd_softc *)self;
struct hidkbd *kbd = &sc->sc_kbd;
- if (kbd->sc_enabled) {
- if (sc->sc_has_fn)
- apldckbd_munge(sc, &packet[1], packetlen - 1);
+ if (kbd->sc_enabled)
hidkbd_input(kbd, &packet[1], packetlen - 1);
- }
}
int
Index: arch/arm64/dev/aplhidev.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/aplhidev.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 aplhidev.c
--- arch/arm64/dev/aplhidev.c 6 Apr 2022 18:59:26 - 1.6
+++ arch/arm64/dev/aplhidev.c 16 Sep 2022 13:11:45 -
@@ -459,6 +459,10 @@ aplkbd_attach(struct device *parent, str
printf("\n");
+ if (hid_locate(aa->aa_desc, aa->aa_desclen, HID_USAGE2(HUP_APPLE,
HUG_FN_KEY),
+ 1, hid_input, &kbd->sc_fn, NULL))
+ kbd->sc_munge = hidkbd_apple_munge;
+
if (kbd->sc_console_keyboard) {
extern struct wskbd_mapdata ukbd_keymapdata;
Index: dev/hid/hidkbd.c
===
RCS file: /cvs/src/sys/dev/hid/hidkbd.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 hidkbd.c
--- dev/hid/hidkbd.c2 Nov 2020 19:45:18 - 1.6
+++ dev/hid/hidkbd.c16 Sep 2022 13:11:45 -
@@ -108,6 +108,67 @@ const u_int8_t hidkbd_trtab[256] = {
};
#endif /* defined(WSDISPLAY_COMPAT_RAWKBD) */
+static const struct hidkbd_translation apple_fn_trans[] = {
+ { 40, 73 }, /* return -> insert */
+ { 42, 76 }, /* backspace -> delete */
+#ifdef notyet
+ { 58, 0 }, /* F1 -> screen brightness down */
+ { 59, 0 }, /* F2 -> screen bri
Re: apldckbd(4): add fn key combose for Page Up/Down
On 16/09/22 12:43 +, Miod Vallat wrote:
> > On 16/09/22 12:20 +, Miod Vallat wrote:
> > > > Index: dev/hid/hidkbdtrans.h
> > >
> > > > +static const struct hidkbd_translation apple_fn_trans[] = {
> > >
> > > No effing way. Every file including this header will embed its own copy
> > > of these tables.
> > >
> > > Better keep the tables in their original locations. The munge interfaces
> > > already take a pointer to a table and its number of elements, there is
> > > no need to gather all these tables in one particular location.
> >
> > yeah was quiet stupid of me.. new diff here. i've also put the whole
> > thing inside !SMALL_KERNEL
>
> That's better.
>
> However:
> - I see no reason for this to be wrapped within !SMALL_KERNEL, having a
> working keyboard within the installer is always a good thing.
> - there is also no reason to move the Gdium-specific (loongson) bits
> away from ukbd.c. They will never appear on any other kind of
> keyboard. As long as there is a prototype for hidkbd_translate()
> somewhere, it will keep working.
rev3:
Index: arch/arm64/dev/apldc.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/apldc.c,v
retrieving revision 1.3
diff -u -p -u -r1.3 apldc.c
--- arch/arm64/dev/apldc.c 15 Sep 2022 14:45:49 - 1.3
+++ arch/arm64/dev/apldc.c 16 Sep 2022 12:55:54 -
@@ -1066,22 +1066,6 @@ struct apldckbd_softc {
struct apldchidev_softc *sc_hidev;
struct hidkbd sc_kbd;
int sc_spl;
- struct hid_location sc_fn;
- int sc_has_fn;
-};
-
-struct apldckbd_translation {
- uint8_t original;
- uint8_t translation;
-};
-
-static const struct apldckbd_translation apldckbd_trans_table[] = {
- { 40, 73 }, /* return -> insert */
- { 42, 76 }, /* backspace -> delete */
- { 79, 77 }, /* right -> end */
- { 80, 74 }, /* left -> home */
- { 81, 78 }, /* down -> page down */
- { 82, 75 } /* up -> page up */
};
void apldckbd_cngetc(void *, u_int *, int *);
@@ -1138,8 +1122,9 @@ apldckbd_attach(struct device *parent, s
printf("\n");
- sc->sc_has_fn = hid_locate(aa->aa_desc, aa->aa_desclen,
- HID_USAGE2(HUP_APPLE, HUG_FN_KEY), 1, hid_input, &sc->sc_fn, NULL);
+ if (hid_locate(aa->aa_desc, aa->aa_desclen, HID_USAGE2(HUP_APPLE,
HUG_FN_KEY),
+ 1, hid_input, &kbd->sc_fn, NULL))
+ kbd->sc_munge = hidkbd_apple_munge;
if (kbd->sc_console_keyboard) {
extern struct wskbd_mapdata ukbd_keymapdata;
@@ -1153,40 +1138,13 @@ apldckbd_attach(struct device *parent, s
}
void
-apldckbd_munge(void *v, uint8_t *ibuf, size_t ilen)
-{
- struct apldckbd_softc *sc = v;
- struct hidkbd *kbd = &sc->sc_kbd;
- uint8_t *pos, *spos, *epos;
- const struct apldckbd_translation *tbl;
- size_t tsize;
-
- if (!hid_get_data(ibuf, ilen, &sc->sc_fn))
- return;
-
- spos = ibuf + kbd->sc_keycodeloc.pos / 8;
- epos = spos + kbd->sc_nkeycode;
-
- for (pos = spos; pos != epos; pos++) {
- tbl = apldckbd_trans_table;
- tsize = nitems(apldckbd_trans_table);
- for (; tsize != 0; tbl++, tsize--)
- if (tbl->original == *pos)
- *pos = tbl->translation;
- }
-}
-
-void
apldckbd_intr(struct device *self, uint8_t *packet, size_t packetlen)
{
struct apldckbd_softc *sc = (struct apldckbd_softc *)self;
struct hidkbd *kbd = &sc->sc_kbd;
- if (kbd->sc_enabled) {
- if (sc->sc_has_fn)
- apldckbd_munge(sc, &packet[1], packetlen - 1);
+ if (kbd->sc_enabled)
hidkbd_input(kbd, &packet[1], packetlen - 1);
- }
}
int
Index: arch/arm64/dev/aplhidev.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/aplhidev.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 aplhidev.c
--- arch/arm64/dev/aplhidev.c 6 Apr 2022 18:59:26 - 1.6
+++ arch/arm64/dev/aplhidev.c 16 Sep 2022 12:55:54 -
@@ -459,6 +459,10 @@ aplkbd_attach(struct device *parent, str
printf("\n");
+ if (hid_locate(aa->aa_desc, aa->aa_desclen, HID_USAGE2(HUP_APPLE,
HUG_FN_KEY),
+ 1, hid_input, &kbd->sc_fn, NULL))
+ kbd->sc_munge = hidkbd_apple_munge;
+
if (kbd->sc_console_keyboard) {
extern struct wskbd_mapdata ukbd_keymapdata;
Index: dev/hid/hidkbd.c
===
RCS file: /cvs/src/sys/dev/hid/hidkbd.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 hidkbd.c
--- dev/hid/hidkbd.c2 Nov 2020 19:45:18 - 1.6
+++ dev/hid/hidkbd.c16 Sep 2022 12:55:54 -
@@ -108,6 +108,72 @@ const u_int8_t hidkbd_trtab[256] = {
};
#e
Re: apldckbd(4): add fn key combose for Page Up/Down
On 16/09/22 12:45 +, Klemens Nanni wrote:
> > Index: dev/hid/hidkbd.c
>
> > +static const struct hidkbd_translation apple_mba_trans[] = {
>
> These *_apple_* structs could be under #ifdef __arm64__ as only arm64
> has a driver using them, no?
no. ukbd(4)
Re: apldckbd(4): add fn key combose for Page Up/Down
On 16/09/22 06:40 -0600, Theo de Raadt wrote: > > thing inside !SMALL_KERNEL > > Is that neccessary? > > Because arm64 has no limitation on bsd.rd size but hidkbd is not arm64 only
Re: apldckbd(4): add fn key combose for Page Up/Down
On 16/09/22 12:20 +, Miod Vallat wrote:
> > Index: dev/hid/hidkbdtrans.h
>
> > +static const struct hidkbd_translation apple_fn_trans[] = {
>
> No effing way. Every file including this header will embed its own copy
> of these tables.
>
> Better keep the tables in their original locations. The munge interfaces
> already take a pointer to a table and its number of elements, there is
> no need to gather all these tables in one particular location.
yeah was quiet stupid of me.. new diff here. i've also put the whole
thing inside !SMALL_KERNEL
Index: arch/arm64/dev/apldc.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/apldc.c,v
retrieving revision 1.3
diff -u -p -u -r1.3 apldc.c
--- arch/arm64/dev/apldc.c 15 Sep 2022 14:45:49 - 1.3
+++ arch/arm64/dev/apldc.c 16 Sep 2022 12:33:38 -
@@ -1066,22 +1066,6 @@ struct apldckbd_softc {
struct apldchidev_softc *sc_hidev;
struct hidkbd sc_kbd;
int sc_spl;
- struct hid_location sc_fn;
- int sc_has_fn;
-};
-
-struct apldckbd_translation {
- uint8_t original;
- uint8_t translation;
-};
-
-static const struct apldckbd_translation apldckbd_trans_table[] = {
- { 40, 73 }, /* return -> insert */
- { 42, 76 }, /* backspace -> delete */
- { 79, 77 }, /* right -> end */
- { 80, 74 }, /* left -> home */
- { 81, 78 }, /* down -> page down */
- { 82, 75 } /* up -> page up */
};
void apldckbd_cngetc(void *, u_int *, int *);
@@ -1138,8 +1122,11 @@ apldckbd_attach(struct device *parent, s
printf("\n");
- sc->sc_has_fn = hid_locate(aa->aa_desc, aa->aa_desclen,
- HID_USAGE2(HUP_APPLE, HUG_FN_KEY), 1, hid_input, &sc->sc_fn, NULL);
+#if !defined(SMALL_KERNEL)
+ if (hid_locate(aa->aa_desc, aa->aa_desclen, HID_USAGE2(HUP_APPLE,
HUG_FN_KEY),
+ 1, hid_input, &kbd->sc_fn, NULL))
+ kbd->sc_munge = hidkbd_apple_munge;
+#endif
if (kbd->sc_console_keyboard) {
extern struct wskbd_mapdata ukbd_keymapdata;
@@ -1153,40 +1140,13 @@ apldckbd_attach(struct device *parent, s
}
void
-apldckbd_munge(void *v, uint8_t *ibuf, size_t ilen)
-{
- struct apldckbd_softc *sc = v;
- struct hidkbd *kbd = &sc->sc_kbd;
- uint8_t *pos, *spos, *epos;
- const struct apldckbd_translation *tbl;
- size_t tsize;
-
- if (!hid_get_data(ibuf, ilen, &sc->sc_fn))
- return;
-
- spos = ibuf + kbd->sc_keycodeloc.pos / 8;
- epos = spos + kbd->sc_nkeycode;
-
- for (pos = spos; pos != epos; pos++) {
- tbl = apldckbd_trans_table;
- tsize = nitems(apldckbd_trans_table);
- for (; tsize != 0; tbl++, tsize--)
- if (tbl->original == *pos)
- *pos = tbl->translation;
- }
-}
-
-void
apldckbd_intr(struct device *self, uint8_t *packet, size_t packetlen)
{
struct apldckbd_softc *sc = (struct apldckbd_softc *)self;
struct hidkbd *kbd = &sc->sc_kbd;
- if (kbd->sc_enabled) {
- if (sc->sc_has_fn)
- apldckbd_munge(sc, &packet[1], packetlen - 1);
+ if (kbd->sc_enabled)
hidkbd_input(kbd, &packet[1], packetlen - 1);
- }
}
int
Index: arch/arm64/dev/aplhidev.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/aplhidev.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 aplhidev.c
--- arch/arm64/dev/aplhidev.c 6 Apr 2022 18:59:26 - 1.6
+++ arch/arm64/dev/aplhidev.c 16 Sep 2022 12:33:38 -
@@ -459,6 +459,12 @@ aplkbd_attach(struct device *parent, str
printf("\n");
+#if !defined(SMALL_KERNEL)
+ if (hid_locate(aa->aa_desc, aa->aa_desclen, HID_USAGE2(HUP_APPLE,
HUG_FN_KEY),
+ 1, hid_input, &kbd->sc_fn, NULL))
+ kbd->sc_munge = hidkbd_apple_munge;
+#endif
+
if (kbd->sc_console_keyboard) {
extern struct wskbd_mapdata ukbd_keymapdata;
Index: dev/hid/hidkbd.c
===
RCS file: /cvs/src/sys/dev/hid/hidkbd.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 hidkbd.c
--- dev/hid/hidkbd.c2 Nov 2020 19:45:18 - 1.6
+++ dev/hid/hidkbd.c16 Sep 2022 12:33:38 -
@@ -108,6 +108,103 @@ const u_int8_t hidkbd_trtab[256] = {
};
#endif /* defined(WSDISPLAY_COMPAT_RAWKBD) */
+#if !defined(SMALL_KERNEL)
+static const struct hidkbd_translation apple_fn_trans[] = {
+ { 40, 73 }, /* return -> insert */
+ { 42, 76 }, /* backspace -> delete */
+#ifdef notyet
+ { 58, 0 }, /* F1 -> screen brightness down */
+ { 59, 0 }, /* F2 -> screen brightness up */
+ { 60, 0 }, /* F3 */
+ { 61, 0 }, /* F4 */
+ { 62, 0 },
Re: apldckbd(4): add fn key combose for Page Up/Down
On 16/09/22 14:01 +0200, Robert Nagy wrote:
> On 14/09/22 17:21 +0200, Tobias Heider wrote:
> > On Wed, Sep 14, 2022 at 11:56:48AM +, Miod Vallat wrote:
> > > > Hey,
> > > >
> > > > the diff below adds FN key combos for Page Up, Page Down and some more
> > > > on the M2 keyboard. Most of the logic was copied from ukbd.
> > >
> > > This means most of the munging logic should move from ukbd into hidkbd,
> > > but that can be done later.
> >
> > Right, that was also my idea. For now I'd be happy to have them working
> > at all.
>
> I've also had a look because I wanted this on the M1 macbook as well
> and decided to move things out to hidkbd as miod suggested.
> Works fine for me.
Oops. Please use this diff, as it has more cleanup:
Index: arch/arm64/dev/apldc.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/apldc.c,v
retrieving revision 1.3
diff -u -p -u -r1.3 apldc.c
--- arch/arm64/dev/apldc.c 15 Sep 2022 14:45:49 - 1.3
+++ arch/arm64/dev/apldc.c 16 Sep 2022 12:07:08 -
@@ -37,6 +37,7 @@
#include
#include
+#include
#include
#include
@@ -1066,22 +1067,6 @@ struct apldckbd_softc {
struct apldchidev_softc *sc_hidev;
struct hidkbd sc_kbd;
int sc_spl;
- struct hid_location sc_fn;
- int sc_has_fn;
-};
-
-struct apldckbd_translation {
- uint8_t original;
- uint8_t translation;
-};
-
-static const struct apldckbd_translation apldckbd_trans_table[] = {
- { 40, 73 }, /* return -> insert */
- { 42, 76 }, /* backspace -> delete */
- { 79, 77 }, /* right -> end */
- { 80, 74 }, /* left -> home */
- { 81, 78 }, /* down -> page down */
- { 82, 75 } /* up -> page up */
};
void apldckbd_cngetc(void *, u_int *, int *);
@@ -1138,8 +1123,9 @@ apldckbd_attach(struct device *parent, s
printf("\n");
- sc->sc_has_fn = hid_locate(aa->aa_desc, aa->aa_desclen,
- HID_USAGE2(HUP_APPLE, HUG_FN_KEY), 1, hid_input, &sc->sc_fn, NULL);
+ if (hid_locate(aa->aa_desc, aa->aa_desclen, HID_USAGE2(HUP_APPLE,
HUG_FN_KEY),
+ 1, hid_input, &kbd->sc_fn, NULL))
+ kbd->sc_munge = hidkbd_apple_munge;
if (kbd->sc_console_keyboard) {
extern struct wskbd_mapdata ukbd_keymapdata;
@@ -1153,40 +1139,13 @@ apldckbd_attach(struct device *parent, s
}
void
-apldckbd_munge(void *v, uint8_t *ibuf, size_t ilen)
-{
- struct apldckbd_softc *sc = v;
- struct hidkbd *kbd = &sc->sc_kbd;
- uint8_t *pos, *spos, *epos;
- const struct apldckbd_translation *tbl;
- size_t tsize;
-
- if (!hid_get_data(ibuf, ilen, &sc->sc_fn))
- return;
-
- spos = ibuf + kbd->sc_keycodeloc.pos / 8;
- epos = spos + kbd->sc_nkeycode;
-
- for (pos = spos; pos != epos; pos++) {
- tbl = apldckbd_trans_table;
- tsize = nitems(apldckbd_trans_table);
- for (; tsize != 0; tbl++, tsize--)
- if (tbl->original == *pos)
- *pos = tbl->translation;
- }
-}
-
-void
apldckbd_intr(struct device *self, uint8_t *packet, size_t packetlen)
{
struct apldckbd_softc *sc = (struct apldckbd_softc *)self;
struct hidkbd *kbd = &sc->sc_kbd;
- if (kbd->sc_enabled) {
- if (sc->sc_has_fn)
- apldckbd_munge(sc, &packet[1], packetlen - 1);
+ if (kbd->sc_enabled)
hidkbd_input(kbd, &packet[1], packetlen - 1);
- }
}
int
Index: arch/arm64/dev/aplhidev.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/aplhidev.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 aplhidev.c
--- arch/arm64/dev/aplhidev.c 6 Apr 2022 18:59:26 - 1.6
+++ arch/arm64/dev/aplhidev.c 16 Sep 2022 12:07:08 -
@@ -40,6 +40,7 @@
#include
#include
+#include
#include
#include "aplhidev.h"
@@ -458,6 +459,10 @@ aplkbd_attach(struct device *parent, str
return;
printf("\n");
+
+ if (hid_locate(aa->aa_desc, aa->aa_desclen, HID_USAGE2(HUP_APPLE,
HUG_FN_KEY),
+ 1, hid_input, &kbd->sc_fn, NULL))
+ kbd->sc_munge = hidkbd_apple_munge;
if (kbd->sc_console_keyboard) {
extern struct wskbd_mapdata ukbd_keymapdata;
Index: dev/hid/hidkbd.c
===
RCS file: /cvs/src/sys/dev/hid/hidkbd.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 hidkbd.c
--- dev/hid/hidkbd.c2 Nov 2020 19:4
Re: apldckbd(4): add fn key combose for Page Up/Down
do { if (hidkbddebug) printf x; } while (0)
@@ -236,11 +237,119 @@ hidkbd_detach(struct hidkbd *kbd, int fl
return (rv);
}
+uint8_t
+hidkbd_translate(const struct hidkbd_translation *table, size_t tsize,
+uint8_t keycode)
+{
+ for (; tsize != 0; table++, tsize--)
+ if (table->original == keycode)
+ return table->translation;
+ return 0;
+}
+
+void
+hidkbd_apple_translate(void *vsc, uint8_t *ibuf, u_int ilen,
+const struct hidkbd_translation* trans, u_int tlen)
+{
+ struct hidkbd *kbd = vsc;
+ uint8_t *pos, *spos, *epos, xlat;
+
+ spos = ibuf + kbd->sc_keycodeloc.pos / 8;
+ epos = spos + kbd->sc_nkeycode;
+
+ for (pos = spos; pos != epos; pos++) {
+ xlat = hidkbd_translate(trans, tlen, *pos);
+ if (xlat != 0)
+ *pos = xlat;
+ }
+}
+
+void
+hidkbd_apple_munge(void *vsc, uint8_t *ibuf, u_int ilen)
+{
+ struct hidkbd *kbd = vsc;
+
+ if (!hid_get_data(ibuf, ilen, &kbd->sc_fn))
+ return;
+
+ hidkbd_apple_translate(vsc, ibuf, ilen, apple_fn_trans,
+ nitems(apple_fn_trans));
+}
+
+void
+hidkbd_apple_iso_munge(void *vsc, uint8_t *ibuf, u_int ilen)
+{
+ hidkbd_apple_translate(vsc, ibuf, ilen, apple_iso_trans,
+ nitems(apple_iso_trans));
+}
+
+void
+hidkbd_apple_mba_munge(void *vsc, uint8_t *ibuf, u_int ilen)
+{
+ struct hidkbd *kbd = vsc;
+
+ if (!hid_get_data(ibuf, ilen, &kbd->sc_fn))
+ return;
+
+ hidkbd_apple_translate(vsc, ibuf, ilen, apple_mba_trans,
+ nitems(apple_mba_trans));
+}
+
+void
+hidkbd_apple_iso_mba_munge(void *vsc, uint8_t *ibuf, u_int ilen)
+{
+ hidkbd_apple_translate(vsc, ibuf, ilen, apple_iso_mba_trans,
+ nitems(apple_iso_mba_trans));
+}
+
+#ifdef __loongson__
+#defineGDIUM_FN_CODE 0x82
+void
+hidkbd_gdium_munge(void *vsc, uint8_t *ibuf, u_int ilen)
+{
+ struct hidkbd *kbd = vsc;
+ uint8_t *pos, *spos, *epos, xlat;
+ int fn;
+
+ spos = ibuf + kbd->sc_keycodeloc.pos / 8;
+ epos = spos + kbd->sc_nkeycode;
+
+ /*
+* Check for Fn key being down and remove it from the report.
+*/
+
+ fn = 0;
+ for (pos = spos; pos != epos; pos++)
+ if (*pos == GDIUM_FN_CODE) {
+ fn = 1;
+ *pos = 0;
+ break;
+ }
+
+ /*
+* Rewrite keycodes on the fly to perform Fn-key translation.
+* Keycodes without a translation are passed unaffected.
+*/
+
+ if (fn != 0)
+ for (pos = spos; pos != epos; pos++) {
+ xlat = hidkbd_translate(gdium_fn_trans,
+ nitems(gdium_fn_trans), *pos);
+ if (xlat != 0)
+ *pos = xlat;
+ }
+
+}
+#endif
+
void
hidkbd_input(struct hidkbd *kbd, uint8_t *data, u_int len)
{
struct hidkbd_data *ud = &kbd->sc_ndata;
int i;
+
+ if (kbd->sc_munge != NULL)
+ (*kbd->sc_munge)(kbd, (uint8_t *)data, len);
#ifdef HIDKBD_DEBUG
if (hidkbddebug > 5) {
Index: dev/hid/hidkbdsc.h
===
RCS file: /cvs/src/sys/dev/hid/hidkbdsc.h,v
retrieving revision 1.1
diff -u -p -u -r1.1 hidkbdsc.h
--- dev/hid/hidkbdsc.h 8 Jan 2016 15:54:13 - 1.1
+++ dev/hid/hidkbdsc.h 16 Sep 2022 11:58:42 -
@@ -67,6 +67,7 @@ struct hidkbd {
struct hid_location sc_capsloc;
struct hid_location sc_scroloc;
struct hid_location sc_compose;
+ struct hid_location sc_fn;
int sc_leds;
/* state information */
@@ -88,6 +89,13 @@ struct hidkbd {
int sc_polling;
int sc_npollchar;
u_int16_t sc_pollchars[MAXKEYS];
+
+ void (*sc_munge)(void *, uint8_t *, u_int);
+};
+
+struct hidkbd_translation {
+ uint8_t original;
+ uint8_t translation;
};
inthidkbd_attach(struct device *, struct hidkbd *, int, uint32_t,
@@ -98,6 +106,7 @@ void hidkbd_bell(u_int, u_int, u_int, in
void hidkbd_cngetc(struct hidkbd *, u_int *, int *);
inthidkbd_detach(struct hidkbd *, int);
inthidkbd_enable(struct hidkbd *, int);
+void hidkbd_munge(void *, uint8_t *, u_int);
void hidkbd_input(struct hidkbd *, uint8_t *, u_int);
inthidkbd_ioctl(struct hidkbd *, u_long, caddr_t, int, struct proc *);
inthidkbd_set_leds(struct hidkbd *, int, uint8_t *);
Index: dev/hid/hidkbdtrans.h
=======
RCS file: dev/hid/hidkbdtrans.h
diff -N dev/hid/hidkbdtrans.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/hid/hidkbdtrans.h 16 Sep 2022 11:58:42 -
@@ -0,0 +1,123 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2022 Robert Nagy
+ *
+ * Permission to use, copy, mod
Re: unlock mmap(2) for anonymous mappings
On 11/01/22 09:57 +0100, Claudio Jeker wrote:
> On Tue, Jan 11, 2022 at 08:15:13AM +, Klemens Nanni wrote:
> > On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> > > On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > > > The uvm_wxabort path within uvm_wxcheck() looks not MP-safe.
> > >
> > > Right, I did not pay enough attention to W^X handling.
> >
> > New diff, either alone or on top of the mmap unlocking.
> >
> > > I'm not entirely sure about the sigexit() path.
> >
> > We can't dump core without the kernel lock, assertions do make sure...
> >
> > > There's `ps_wxcounter' as u_int64_t which needs a lock or atomic
> > > operations.
> >
> > This could look like this. `ps_wxcounter' is not used anywhere else in
> > the tree; it has been like this since import in 2016.
> >
> > > The kernel lock could be pushed into uvm_wxabort() but there it'd still
> > > be grabbed for every mmap(2) call.
> >
> > This means we're only grabbing the kernel lock if `kern.wxabort=1' is
> > set *and* there's a W^X violation -- much better.
> >
> >
> > Index: sys/proc.h
> > ===
> > RCS file: /cvs/src/sys/sys/proc.h,v
> > retrieving revision 1.323
> > diff -u -p -r1.323 proc.h
> > --- sys/proc.h 10 Dec 2021 05:34:42 - 1.323
> > +++ sys/proc.h 9 Jan 2022 13:42:45 -
> > @@ -197,7 +197,7 @@ struct process {
> > time_t ps_nextxcpu;/* when to send next SIGXCPU, */
> > /* in seconds of process runtime */
> >
> > - u_int64_t ps_wxcounter;
> > + u_int64_t ps_wxcounter; /* [a] number of W^X violations */
>
> This can't be right. We don't have 64bit atomic instructions on all archs.
> Either this needs to be unsigned long or unsigned int.
> Since this is only used to limit the number of reports per process I would
> suggest to mover this to an unsigned int. You can't have that many threads
> to overflow that count.
> Or another option is to move the ps_wxcounter into the KERNEL_LOCK block
> which is also trivial and will fix this for as long as sigexit requires
> the KERNEL_LOCK.
I think moving the KERNEL_LOCK block is good enough.
Re: allow KARL with config(8)'d kernels
On 07/09/21 19:31 +0200, Paul de Weerd wrote: > Hi all, > > On Tue, Sep 07, 2021 at 02:30:43PM +0200, Robert Nagy wrote: > | /etc/reorder_kernel.conf > > Thank you for your suggest Robert! In the mean time, I've had a few > more off-list comments about this proposal - generally favorable, but > no better suggestions have come along. After some more off-list > discussion, I'm now proposing the below diff. It uses Theo's original > suggestion of /etc/bsd.re-config. Hi I would prefer to have -f in both tests, because install.sub is using -e now. .
Re: allow KARL with config(8)'d kernels
On 29/08/21 08:10 -0600, Theo de Raadt wrote: > Ingo Schwarze wrote: > > > One - admittedly completely unUNIXy - way would be to invent a long, > > descriptive name like /etc/kernel.config.commands or even /bsd.config.cmd > > in the root rather than the /etc directory, which is more discoverable > > because it is right next to the kernel itself. The UNIXy way > > is not necessarily better: Ken would have invented a very short, > > pronouncable name that is not an English word but similar to one, > > like /etc/sycoc (for SYstem COnfiguration Commands). > > I have no idea why you talk about Ken, how obscure > > back in those days it wasn't called /kernel, either. > > the pathname "kernel.something" which is supposed to be somewhat > related to a non-existant pathname "kernel", is what I object to. > > perhaps /etc/bsd.re-config > > but certainly the sub-phrase "kernel" is not discoverable. > /etc/reorder_kernel.conf
Re: allow KARL with config(8)'d kernels
I am happy to see this. All for it. Did you check all the error cases
to make sure that reorder_kernel will report what needs to be reported?
On 24/08/21 13:53 +0200, Paul de Weerd wrote:
> I have a new machine where I'd like to use IPMI. Of course, doing
> `config -e -f /bsd` will break KARL, so I tried to find a minimal way
> of supporting this. Done by introducing a new config file,
> /etc/kernel.conf, which gets applied to the kernel reorder_kernel
> builds and installs.
>
> Paul 'WEiRD' de Weerd
>
> Index: reorder_kernel.sh
> ===
> RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/reorder_kernel.sh,v
> retrieving revision 1.9
> diff -u -p -r1.9 reorder_kernel.sh
> --- reorder_kernel.sh 28 Sep 2019 17:30:07 - 1.9
> +++ reorder_kernel.sh 24 Aug 2021 07:01:10 -
> @@ -63,6 +63,7 @@ fi
>
> cd $KERNEL_DIR/$KERNEL
> make newbsd
> +[ -f /etc/kernel.conf ] && config -e -c /etc/kernel.conf -f bsd
> make newinstall
> sync
>
> Index: Makefile
> ===
> RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/Makefile,v
> retrieving revision 1.1
> diff -u -p -r1.1 Makefile
> --- Makefile 21 Aug 2017 21:24:11 - 1.1
> +++ Makefile 24 Aug 2021 07:23:38 -
> @@ -1,6 +1,7 @@
> #$OpenBSD: Makefile,v 1.1 2017/08/21 21:24:11 rpe Exp $
>
> SCRIPT= reorder_kernel.sh
> +MAN= kernel.conf.5
>
> realinstall:
> ${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
> Index: kernel.conf.5
> ===
> RCS file: kernel.conf.5
> diff -N kernel.conf.5
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ kernel.conf.5 24 Aug 2021 07:23:07 -
> @@ -0,0 +1,46 @@
> +.\" $OpenBSD$
> +.\"
> +.\" Copyright (c) 2021 Paul de Weerd
> +.\"
> +.\" Permission to use, copy, modify, and distribute this software for any
> +.\" purpose with or without fee is hereby granted, provided that the above
> +.\" copyright notice and this permission notice appear in all copies.
> +.\"
> +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> +.\"
> +.Dd $Mdocdate: August 24 2021 $
> +.Dt KERNEL.CONF 5
> +.Os
> +.Sh NAME
> +.Nm kernel.conf
> +.Nd kernel configuration file
> +.Sh DESCRIPTION
> +The
> +.Nm
> +file contains configuration information for the kernel.
> +If present, it is used during system startup to configure the kernel
> +that will be running at the next boot.
> +It can be used to enable or disable specific devices in the kernel.
> +.Sh EXAMPLES
> +To enable the
> +.Xr ipmi 4
> +driver, add the following line to
> +.Nm :
> +.Pp
> +.Dl enable ipmi
> +.Pp
> +See
> +.Xr config 8
> +for more details on how to configure the kernel.
> +.Sh FILES
> +.Bl -tag -width /etc/kernel.conf -compact
> +.It Pa /etc/kernel.conf
> +Kernel configuration file.
> +.Sh SEE ALSO
> +.Xr config 8
>
> --
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
> http://www.weirdnet.nl/
>
--
Regards,
Robert Nagy
Re: Add if_mreqn support to IP_MULTICAST_IF
On 15/01/21 14:53 +0100, Claudio Jeker wrote: > I forgot to add ip_mreqn support to IP_MULTICAST_IF and so the > IP_ADD_MEMBERSHIP change is not fixing all the issues I have. > > Linux supports calling IP_MULTICAST_IF with a struct in_addr, a struct > ip_mreq, or a struct ip_mreqn. FreeBSD only does the first and last. > I followed the Linux way because doing that was not that hard. In the end > only the imr_ifindex field and the imr_address field need to be checked > and if the imr_ifindex is 0 then just use the old code. If the imr_ifindex > is set then use this for interface index and break early. > > Any opinions about this? Following the linux way is the way to go because most of the 3rd party software will expect that. As I said already, this fixed an issue in chromium already, so I am okay with it.
Re: behaviour of openssl s_server and certificate chains on 6.8
On 14/01/21 14:50 +0100, Theo Buehler wrote: > On Thu, Jan 14, 2021 at 02:37:20PM +0100, Robert Nagy wrote: > > On 14/01/21 14:27 +0100, Robert Nagy wrote: > > > On 14/01/21 14:20 +0100, Theo Buehler wrote: > > > > On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matthieu Herrb wrote: > > > > > Hi, > > > > > > > > > > I'm trying to debug strange beahaviour changes with certificates on a > > > > > systemc after upgrading it from 6.7 to 6.8... > > > > > > > > > > On 6.7, If I run : > > > > > > > > > > openssl s_server -cert mycert.pem -key mykey.pem -CAfile CA.pem > > > > > > > > > > then openssl s_client -showcerts -connect localhost:4433 > > > > > > > > > > returns the full certificate chain mycert->CA > > > > > > > > > > With the same commands on 6.8, I don't get the CA certificate. > > > > > > > > > > Is this a known issue, and how can I get the chain with 6.8 ? > > > > > > > > > > (my real application is sendmail...) > > > > > > > > In short: Yes, this is known. You can't get the chain in 6.8. > > > > > > > > This is the reason why ajacoutot switched sendmail to link against > > > > eopenssl11 as a workaround in -stable. As your thread on ports shows, > > > > this workaround doesn't work if you add something that links against > > > > LibreSSL to the mix. > > > > > > > > There are several layers of unexpected things/bugs involved. The two > > > > main points are: > > > > > > > > 1. The TLSv1.3 server in 6.8 does not do auto chain since we hoped to > > > >be able to avoid it. This was addressed post release when people > > > >using OpenLDAP ran into it. > > > >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.62 > > > > > > > > 2. The new verifier doesn't behave as it should when auto chain is > > > >enabled. As a workaround -current switches to the legacy verifier in > > > >this situation for about a week now. The proper fix in the new > > > >verifier is under discussion. > > > >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.65 > > > > > > > > I don't know whether/when there will be backports of some fixes to 6.8. > > > > As sthen said in the thread on ports, right now the simplest fix is to > > > > run -current. > > > > > > > > > > i think this should be an errata for 6.8 > > Not exactly sure what you mean by "this," but I emphatically agree, > errata are long overdue. It would be desirable to avoid an outright > switch back to the legacy verifier if that's what you mean by the below. > > > I am also getting this problem with bacula using TLS < 1.3, reported to Bob > > already, and I am currently running with the legacy verifier. > > FWIW this is a different issue that was also adressed in -current. > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/x509/x509_verify.c#rev1.26 Well we either do a big errata consisting of all these fixes or switch back to the legacy one in 6.8 with one small errata. People rely on stable, so we should act accordingly.
Re: behaviour of openssl s_server and certificate chains on 6.8
On 14/01/21 14:27 +0100, Robert Nagy wrote: > On 14/01/21 14:20 +0100, Theo Buehler wrote: > > On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matthieu Herrb wrote: > > > Hi, > > > > > > I'm trying to debug strange beahaviour changes with certificates on a > > > systemc after upgrading it from 6.7 to 6.8... > > > > > > On 6.7, If I run : > > > > > > openssl s_server -cert mycert.pem -key mykey.pem -CAfile CA.pem > > > > > > then openssl s_client -showcerts -connect localhost:4433 > > > > > > returns the full certificate chain mycert->CA > > > > > > With the same commands on 6.8, I don't get the CA certificate. > > > > > > Is this a known issue, and how can I get the chain with 6.8 ? > > > > > > (my real application is sendmail...) > > > > In short: Yes, this is known. You can't get the chain in 6.8. > > > > This is the reason why ajacoutot switched sendmail to link against > > eopenssl11 as a workaround in -stable. As your thread on ports shows, > > this workaround doesn't work if you add something that links against > > LibreSSL to the mix. > > > > There are several layers of unexpected things/bugs involved. The two > > main points are: > > > > 1. The TLSv1.3 server in 6.8 does not do auto chain since we hoped to > >be able to avoid it. This was addressed post release when people > >using OpenLDAP ran into it. > >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.62 > > > > 2. The new verifier doesn't behave as it should when auto chain is > >enabled. As a workaround -current switches to the legacy verifier in > >this situation for about a week now. The proper fix in the new > >verifier is under discussion. > >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.65 > > > > I don't know whether/when there will be backports of some fixes to 6.8. > > As sthen said in the thread on ports, right now the simplest fix is to > > run -current. > > > > i think this should be an errata for 6.8 > I am also getting this problem with bacula using TLS < 1.3, reported to Bob already, and I am currently running with the legacy verifier.
Re: behaviour of openssl s_server and certificate chains on 6.8
On 14/01/21 14:20 +0100, Theo Buehler wrote: > On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matthieu Herrb wrote: > > Hi, > > > > I'm trying to debug strange beahaviour changes with certificates on a > > systemc after upgrading it from 6.7 to 6.8... > > > > On 6.7, If I run : > > > > openssl s_server -cert mycert.pem -key mykey.pem -CAfile CA.pem > > > > then openssl s_client -showcerts -connect localhost:4433 > > > > returns the full certificate chain mycert->CA > > > > With the same commands on 6.8, I don't get the CA certificate. > > > > Is this a known issue, and how can I get the chain with 6.8 ? > > > > (my real application is sendmail...) > > In short: Yes, this is known. You can't get the chain in 6.8. > > This is the reason why ajacoutot switched sendmail to link against > eopenssl11 as a workaround in -stable. As your thread on ports shows, > this workaround doesn't work if you add something that links against > LibreSSL to the mix. > > There are several layers of unexpected things/bugs involved. The two > main points are: > > 1. The TLSv1.3 server in 6.8 does not do auto chain since we hoped to >be able to avoid it. This was addressed post release when people >using OpenLDAP ran into it. >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.62 > > 2. The new verifier doesn't behave as it should when auto chain is >enabled. As a workaround -current switches to the legacy verifier in >this situation for about a week now. The proper fix in the new >verifier is under discussion. >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.65 > > I don't know whether/when there will be backports of some fixes to 6.8. > As sthen said in the thread on ports, right now the simplest fix is to > run -current. > i think this should be an errata for 6.8
Re: add support for AMD 17h/3xh HD Audio
On 23/10/20 10:24 +1100, Jonathan Gray wrote: > On Thu, Oct 22, 2020 at 04:34:11PM +0200, Robert Nagy wrote: > > The diff below makes azalia(4) work on my new shiny chromium build box: > > You have a 17-31-00 epyc or threadripper? > > This id also shows up on > B550, Ryzen 9 3900X 17-71-00 > X570, Ryzen 5 3600 17-71-00 > > The other two 17h/3xh ids also show up on 17-71-00 machines. > > It seems they are shared between 17-3x epyc/threadripper and > 17-7x ryzen. I am not aware of any public documents from AMD which > list these devices. > > It is surprising your diff would change anything more than dmesg > text. The codec change was needed to make azalia work, without that all audio playback just hangs. The rest is indeed just dmesg text. OpenBSD 6.8-current (GENERIC.MP) #10: Thu Oct 22 16:30:18 CEST 2020 rob...@nerd.hu:/sys/arch/amd64/compile/GENERIC.MP real mem = 17077854208 (16286MB) avail mem = 16545206272 (15778MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe6b60 (63 entries) bios0: vendor American Megatrends Inc. version "0310" date 09/01/2020 bios0: ASUS PRIME B450M-A II acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT SSDT SSDT MCFG HPET UEFI WPBT IVRS PCCT SSDT CRAT CDIT SSDT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GPP7(S4) GPP8(S4) X161(S4) GPP9(S4) X162(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 7 3800XT 8-Core Processor, 3893.24 MHz, 17-71-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 32MB 64b/line disabled L3 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: AMD Ryzen 7 3800XT 8-Core Processor, 3892.70 MHz, 17-71-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 32MB 64b/line disabled L3 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: AMD Ryzen 7 3800XT 8-Core Processor, 3892.70 MHz, 17-71-00 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 32MB 64b/line disabled L3 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: AMD Ryzen 7 3800XT 8-Core Processor, 3892.70 MHz, 17-71-00 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,A
add support for AMD 17h/3xh HD Audio
The diff below makes azalia(4) work on my new shiny chromium build box:
Index: dev/pci/azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.178
diff -u -p -u -r1.178 azalia_codec.c
--- dev/pci/azalia_codec.c 14 Oct 2019 02:04:35 - 1.178
+++ dev/pci/azalia_codec.c 22 Oct 2020 14:32:55 -
@@ -222,6 +222,10 @@ azalia_codec_init_vtbl(codec_t *this)
this->subid == 0x00a0106b)
this->qrks |= AZ_QRK_WID_OVREF50;
break;
+ case 0x10ec0887:
+ this->name = "Realtek ALC887";
+ this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
+ break;
case 0x10ec0888:
this->name = "Realtek ALC888";
this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
Index: dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1939
diff -u -p -u -r1.1939 pcidevs
--- dev/pci/pcidevs 7 Oct 2020 11:14:59 - 1.1939
+++ dev/pci/pcidevs 22 Oct 2020 14:32:56 -
@@ -751,6 +751,7 @@ product AMD 17_PCIE_4 0x1470 17h PCIE
product AMD 17_PCIE_5 0x1471 17h PCIE
product AMD 17_3X_RC 0x1480 17h/3xh Root Complex
product AMD 17_3X_CCP 0x1486 17h/3xh Crypto
+product AMD 17_3X_HDA 0x1487 17h/3xh HD Audio
product AMD 14_HB 0x1510 14h Host
product AMD 14_PCIE_1 0x1512 14h PCIE
product AMD 14_PCIE_2 0x1513 14h PCIE
Index: dev/pci/pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1932
diff -u -p -u -r1.1932 pcidevs.h
--- dev/pci/pcidevs.h 7 Oct 2020 11:15:31 - 1.1932
+++ dev/pci/pcidevs.h 22 Oct 2020 14:32:58 -
@@ -756,6 +756,7 @@
#definePCI_PRODUCT_AMD_17_PCIE_5 0x1471 /* 17h PCIE */
#definePCI_PRODUCT_AMD_17_3X_RC0x1480 /* 17h/3xh Root
Complex */
#definePCI_PRODUCT_AMD_17_3X_CCP 0x1486 /* 17h/3xh
Crypto */
+#definePCI_PRODUCT_AMD_17_3X_HDA 0x1487 /* 17h/3xh HD
Audio */
#definePCI_PRODUCT_AMD_14_HB 0x1510 /* 14h Host */
#definePCI_PRODUCT_AMD_14_PCIE_1 0x1512 /* 14h PCIE */
#definePCI_PRODUCT_AMD_14_PCIE_2 0x1513 /* 14h PCIE */
Index: dev/pci/pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1927
diff -u -p -u -r1.1927 pcidevs_data.h
--- dev/pci/pcidevs_data.h 7 Oct 2020 11:15:31 - 1.1927
+++ dev/pci/pcidevs_data.h 22 Oct 2020 14:32:59 -
@@ -1328,6 +1328,10 @@ static const struct pci_known_product pc
"17h/3xh Crypto",
},
{
+ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_17_3X_HDA,
+ "17h/3xh HD Audio",
+ },
+ {
PCI_VENDOR_AMD, PCI_PRODUCT_AMD_14_HB,
"14h Host",
},
Re: userland clock_gettime proof of concept
On 02/07/20 00:31 +0100, Stuart Henderson wrote: > running on 38 of these, btw. been running with this on all my workstations and laptops and on 3 build servers as well
Re: userland clock_gettime proof of concept
On 22/06/20 19:12 +0300, Paul Irofti wrote: > New iteration: > > - ps_timekeep should not coredump, pointed by deraadt@ > - set ps_timekeep to 0 before user uvm_map for randomization > - map timekeep before fixup. confirmed by naddy@ that it fixes NULL init > - initialize va. clarified by kettenis@ > > How's the magical max skew value research going? Do we have a value yet? > > Paul I think we should pick 100 for now and then we can adjust it later if needed. Of course this depends on kettenis' lfence diff so that amd ryzen tsc is sane.
Re: lfence for rdtsc
it definitely got better: cpu0: TSC skew=0 observed drift=0 cpu0: TSC skew=0 observed drift=0 cpu1: TSC skew=51 observed drift=0 cpu2: TSC skew=68 observed drift=0 cpu3: TSC skew=68 observed drift=0 cpu4: TSC skew=0 observed drift=0 cpu5: TSC skew=0 observed drift=0 cpu6: TSC skew=85 observed drift=0 cpu7: TSC skew=51 observed drift=0 cpu8: TSC skew=17 observed drift=0 cpu9: TSC skew=34 observed drift=0 cpu10: TSC skew=0 observed drift=0 cpu11: TSC skew=17 observed drift=0 cpu12: TSC skew=0 observed drift=0 cpu13: TSC skew=-51 observed drift=0 cpu14: TSC skew=-17 observed drift=0 cpu15: TSC skew=-17 observed drift=0
Re: userland clock_gettime proof of concept
On 11/06/20 20:10 +0200, Mark Kettenis wrote: > > Date: Thu, 11 Jun 2020 19:38:48 +0200 > > From: Christian Weisgerber > > > > Theo de Raadt: > > > > > The diff is growing complexity to support a future which wouldn't > > > exist if attempts at *supporting all* architectures received priority. > > > > Adding support for more archs is very simple, since you just need > > to copy the corresponding get_timecounter function from the kernel. > > > > Here's arm64. I'm running a kernel and libc with this. > > > > I can also provide alpha, powerpc, and sparc64, but I don't have > > such machines. > > Hope you didn't spend too much time on that, because I already > mentioned that I had arm64 working earlier in the thread. > > I've just fired up one of my sparc64 machines such that I can check > how well the approach works for an architecture with two exported > timecounters. Then please share the patches so that it can be integrated into the main diff so that when the time comes it can go in at one shot. Also it would help to avoid duplicate work.
Re: userland clock_gettime proof of concept
On 30/05/20 10:40 +0200, Mark Kettenis wrote:
> > Date: Sat, 30 May 2020 10:32:15 +0200
> > From: Robert Nagy
> >
> > On 29/05/20 17:51 +0300, Paul Irofti wrote:
> > > On Fri, May 29, 2020 at 03:00:50PM +0200, Mark Kettenis wrote:
> > > > > Date: Fri, 29 May 2020 13:45:37 +0100
> > > > > From: Stuart Henderson
> > > > >
> > > > > On 2020/05/29 13:50, Paul Irofti wrote:
> > > > > > +struct __timekeep {
> > > > > > + uint32_t major; /* version major number */
> > > > > > + uint32_t minor; /* version minor number */
> > > > > > +
> > > > > > + u_int64_t th_scale;
> > > > > > + unsigned intth_offset_count;
> > > > > > + struct bintime th_offset;
> > > > > > + struct bintime th_naptime;
> > > > > > + struct bintime th_boottime;
> > > > > > + volatile unsigned int th_generation;
> > > > > > +
> > > > > > + unsigned inttc_user;
> > > > > > + unsigned inttc_counter_mask;
> > > > > > +};
> > > > >
> > > > > Ah good, you got rid of u_int, that was causing problems with port
> > > > > builds.
> > > >
> > > > That in itself is a problem. This means is the wrong place
> > > > for this struct. We need to find a better place for this.
> > > >
> > > > Since this is now closely linked to the timecounter stuff
> > > > would be an obvious place. Now that file has:
> > > >
> > > > #ifndef _KERNEL
> > > > #error "no user-serviceable parts inside"
> > > > #endif
> > > >
> > > > you could change that into
> > > >
> > > > #if !defined(_KERNEL) && !defined(_LIBC)
> > > > #error "no user-serviceable parts inside"
> > > > #endif
> > > >
> > > > and make sure you #define _LIBC brefore uncluding this file where it
> > > > is needed. As few places as possible obviously.
> > >
> > > Done. Also includes claudio@'s observation.
> >
> > I think if there are no more header changes, this should be commited to
> > have wider testing. We are also just after tree unlock so it feels like
> > the right time, and since there is no library bump we can easily revert
> > if there is a need for that.
>
> Not ready yet.
>
> I also would like to see at least one non-amd64 platform supported
> before we settle on this approach.
Which one would you prefer? arm64?
Re: userland clock_gettime proof of concept
On 29/05/20 17:51 +0300, Paul Irofti wrote:
> On Fri, May 29, 2020 at 03:00:50PM +0200, Mark Kettenis wrote:
> > > Date: Fri, 29 May 2020 13:45:37 +0100
> > > From: Stuart Henderson
> > >
> > > On 2020/05/29 13:50, Paul Irofti wrote:
> > > > +struct __timekeep {
> > > > + uint32_t major; /* version major number */
> > > > + uint32_t minor; /* version minor number */
> > > > +
> > > > + u_int64_t th_scale;
> > > > + unsigned intth_offset_count;
> > > > + struct bintime th_offset;
> > > > + struct bintime th_naptime;
> > > > + struct bintime th_boottime;
> > > > + volatile unsigned int th_generation;
> > > > +
> > > > + unsigned inttc_user;
> > > > + unsigned inttc_counter_mask;
> > > > +};
> > >
> > > Ah good, you got rid of u_int, that was causing problems with port builds.
> >
> > That in itself is a problem. This means is the wrong place
> > for this struct. We need to find a better place for this.
> >
> > Since this is now closely linked to the timecounter stuff
> > would be an obvious place. Now that file has:
> >
> > #ifndef _KERNEL
> > #error "no user-serviceable parts inside"
> > #endif
> >
> > you could change that into
> >
> > #if !defined(_KERNEL) && !defined(_LIBC)
> > #error "no user-serviceable parts inside"
> > #endif
> >
> > and make sure you #define _LIBC brefore uncluding this file where it
> > is needed. As few places as possible obviously.
>
> Done. Also includes claudio@'s observation.
I think if there are no more header changes, this should be commited to
have wider testing. We are also just after tree unlock so it feels like
the right time, and since there is no library bump we can easily revert
if there is a need for that.
Re: userland clock_gettime proof of concept
On 16/05/20 20:14 +0300, Paul Irofti wrote: > Make sure you clean your /usr/share/relink directory before compiling > and installing this! Robert's machine was picking up old objects and > creating a broken library on every reboot becuase his directory was not > clean. It was actually an old .so inside libc obj dir. So better clean everything and just do a make build :)
Re: userland clock_gettime proof of concept
On 13/05/20 17:05 +0200, Mark Kettenis wrote: > > The update currently does the work of clock_gettime(), but it can > > probably be changed to only update the timehands and move the logic > > elsewhere. Note that if we expose only the timehands to userland, most > > of the bintime functionality has to also be made available there. Or so > > I think. > > Unfortunately what you're doing here isn't good enough. You're only > exporting low-resolution versions of the clocks. The equivalent of > what Linux class CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE. > And I'm fairly certain that isn't what the applications want. Why > else would they be calling clock_gettime() a gazillion times per > second... Most of the big programs use CLOCK_MONOTONIC.
Re: userland clock_gettime proof of concept
On 13/05/20 17:03 +0300, Paul Irofti wrote: > Hi, > > By far one of the most popular and frequently used system calls is > clock_gettime(2). As a result the cost of kernel-userland transitions > out weight the actual work, thus I am proposing we make the data > available directly from userland without passing through a system call. > > This has been a subject of discussion multiple times across the years > and last I heard from it was at the p2k19 hackthon that I hosted in > Bucharest where espie@ sent me a diff from one of his students(?). Being > busy with organization I have not had the time to look at it and > I am thus getting back to it just now due to robert@ prodding me again > on the subject. The proposed diff is mine, not the student's. > > > The technical bits. > > Please keep in mind that this is only proof of concept. I am looking for > ways to improve the current diff. As it is, it requires a flag day > because it makes use of ELF aux vectors to export the data from the > kernel. > > I have also played with exposing the data via separate ELF sections and > with kbind-mmap alternatives. The frist also involves a flag day and is > more intrusive in my opinion, and the second I could not get to work. I > think that would be the less intrusive way of doing it, possibly without > a flag day, so if anyone knows how, please let me know. > > The supported clocks are just those that do not require process specific > data. Those can also be handled later if this diff is decided to be a > good thing. > > Clock update inside the kernel is done at the end of tc_windup(). There > might be better places to do it. Let me know where. > > The update currently does the work of clock_gettime(), but it can > probably be changed to only update the timehands and move the logic > elsewhere. Note that if we expose only the timehands to userland, most > of the bintime functionality has to also be made available there. Or so > I think. > > In userland, I wrapped the clock_gettime(2) syscall in libc. There, I > search for the auxiliary vector and fetch the timespec data from it. > As you can see in the diff, parts from the elf_exec header will have to > be exposed to userland if we do it this way. > > > Results. > > To test this diff you need to do a full release(8). I have tested this > with multiple programs. Test programs, base programs and packages. None > the less, this diff touches many important areas of our tree and is > very fragile. I also probably missed changing some parts that required > change due to libc or elf changes. > > If you see regressions, which you probably will, please let me know. > > Here is a stress test from robert@: > > robert@x202:/home/robert> time ./t && time ./t2 > 0m00.11s real 0m00.12s user 0m00.00s system > 0m09.99s real 0m02.64s user 0m03.36s system > t is clock_gettime() and t2 is SYS_clock_gettime() I am in the middle of rebuilding the packages that should gain significant speedup right now. That small test does 5 million calls to clock_gettime, so it is a bit over-reaching but still it shows the difference.
Re: ld.so speedup (part 2)
On 28/04/19 12:01 +0200, Matthieu Herrb wrote: > On Sun, Apr 28, 2019 at 08:55:16AM +0100, Stuart Henderson wrote: > > > >> > On Sat, Apr 27, 2019 at 09:55:33PM +0800, Nathanael Rensen wrote: > > > >> > > The diff below speeds up ld.so library intialisation where the > > > >>dependency > > > >> > > tree is broad and deep, such as samba's smbd which links over 100 > > > >>libraries. > > > > Past experience with ld.so changes suggests it would be good to have > > test reports from multiple arches, *especially* hppa. > > The regress test seem to pass here on hppa. > > -- > Matthieu Herrb > This also fixes the component FLAVOR of chromium which uses a gazillion shared objects. Awesome work!
Re: libunwind: fix register numbering on OpenBSD/i386 (again)
On 31/10/18 09:54 +0100, Patrick Wildt wrote:
> Hi,
>
> during the libunwind update to 6.0 we lost a particular patchset that
> fixes register numbering for OpenBSD/i386, thus breaking exception
> handling on that platform. Looks like no one noticed until now.
>
> ok?
>
> Patrick
>
> diff --git a/lib/libunwind/include/libunwind.h
> b/lib/libunwind/include/libunwind.h
> index 29cf62e4335..4ff0c01b4e2 100644
> --- a/lib/libunwind/include/libunwind.h
> +++ b/lib/libunwind/include/libunwind.h
> @@ -164,8 +164,13 @@ enum {
>UNW_X86_ECX = 1,
>UNW_X86_EDX = 2,
>UNW_X86_EBX = 3,
> +#ifdef __OpenBSD__
> + UNW_X86_ESP = 4,
> + UNW_X86_EBP = 5,
> +#else
>UNW_X86_EBP = 4,
>UNW_X86_ESP = 5,
> +#endif
>UNW_X86_ESI = 6,
>UNW_X86_EDI = 7
> };
>
I think kettenis told me to remove this because they fixed it elsewhere.
Re: unveil(2) for spamlogd(8)
Hi
I think you should call unveil before pledge, so that you don't
need to pledge unveil.
This will prevent futher calls to unveil.
On 18/07/18 12:59 +0100, Ricardo Mestre wrote:
> Hi,
>
> Are there any brave souls out there with unveil(2) enabled already?
>
> If yes please test this diff for spamlogd(8) which seems to only need rw
> access to the file PATH_SPAMD_DB and nothing else.
>
> Not asking for OKs yet, but if the code pattern is correct can I start looking
> at other programs?
>
> Sorry for my earlier email, my clock was WAY off.
>
> Index: spamlogd.c
> ===
> RCS file: /cvs/src/libexec/spamlogd/spamlogd.c,v
> retrieving revision 1.27
> diff -u -p -u -r1.27 spamlogd.c
> --- spamlogd.c16 Mar 2016 14:47:04 - 1.27
> +++ spamlogd.c18 Jul 2018 11:46:59 -
> @@ -376,12 +376,15 @@ main(int argc, char **argv)
> }
>
> if (syncsend) {
> - if (pledge("stdio rpath wpath inet flock", NULL) == -1)
> + if (pledge("stdio rpath wpath inet flock unveil", NULL) == -1)
> err(1, "pledge");
> } else {
> - if (pledge("stdio rpath wpath flock", NULL) == -1)
> + if (pledge("stdio rpath wpath flock unveil", NULL) == -1)
> err(1, "pledge");
> }
> +
> + if (unveil(PATH_SPAMD_DB, "rw") == -1)
> + err(1, "unveil");
>
> pcap_loop(hpcap, -1, phandler, NULL);
>
>
Re: mpii support for sas3.5 controllers
Hi
Obviously I am ok with this since it makes my controller work ;)
mpii0 at pci6 dev 0 function 0 "Symbios Logic MegaRAID SAS3408" rev 0x01: msi
scsibus3 at mpii0: 640 targets
st0 at scsibus3 targ 5 lun 0: SCSI4 1/sequential
removable naa.5000e111c457f001
ch0 at scsibus3 targ 5 lun 1: SCSI3 8/changer
removable t10.BDT_FlexStor_II_00DE64104018_LL0
ses0 at scsibus3 targ 8 lun 0: SCSI4 13/enclosure
services fixed naa.510600b00dbc1490
On 17/06/18 08:06 +1000, Jonathan Matthew wrote:
> This adds support for SAS3.5 controllers in mpii(4).
>
> To get these working, I had to rearrange the initialisation code a bit.
> The new controllers don't like being hard reset, which means we have to call
> mpii_iocfacts() to determine whether soft reset is supported before calling
> mpii_init().
>
> The changes look pretty innocuous but could break older controllers (though
> this is how the linux driver works), so it'd help if people could test those.
> I found a SAS3008 (Dell HBA330) on my desk and that still works.
>
> These controllers also support nvme devices, but that will have to remain
> unimplemented for now.
>
>
> Index: mpiireg.h
> ===
> RCS file: /cvs/src/sys/dev/pci/mpiireg.h,v
> retrieving revision 1.12
> diff -u -p -u -p -r1.12 mpiireg.h
> --- mpiireg.h 16 Jan 2017 18:09:35 - 1.12
> +++ mpiireg.h 16 Jun 2018 21:55:19 -
> @@ -524,6 +524,7 @@ struct mpii_msg_portfacts_reply {
> #define MPII_PORTFACTS_PORTTYPE_ISCSI(0x20)
> #define MPII_PORTFACTS_PORTTYPE_SAS_PHYSICAL (0x30)
> #define MPII_PORTFACTS_PORTTYPE_SAS_VIRTUAL (0x31)
> +#define MPII_PORTFACTS_PORTTYPE_TRI_MODE (0x40)
> u_int16_t reserved6;
>
> u_int16_t max_posted_cmd_buffers;
> Index: mpii.c
> ===
> RCS file: /cvs/src/sys/dev/pci/mpii.c,v
> retrieving revision 1.113
> diff -u -p -u -p -r1.113 mpii.c
> --- mpii.c12 Dec 2017 11:18:32 - 1.113
> +++ mpii.c16 Jun 2018 21:55:20 -
> @@ -431,7 +431,13 @@ static const struct pci_matchid mpii_dev
> { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_SAS3108_1 },
> { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_SAS3108_2 },
> { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_SAS3108_3 },
> - { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_SAS3108_4 }
> + { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_SAS3108_4 },
> + { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_SAS3408 },
> + { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_SAS3416 },
> + { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_SAS3508 },
> + { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_SAS3508_1 },
> + { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_SAS3516 },
> + { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_SAS3516_1 }
> };
>
> int
> @@ -492,13 +498,13 @@ mpii_attach(struct device *parent, struc
> }
> printf(": %s\n", pci_intr_string(sc->sc_pc, ih));
>
> - if (mpii_init(sc) != 0) {
> - printf("%s: unable to initialize ioc\n", DEVNAME(sc));
> + if (mpii_iocfacts(sc) != 0) {
> + printf("%s: unable to get iocfacts\n", DEVNAME(sc));
> goto unmap;
> }
>
> - if (mpii_iocfacts(sc) != 0) {
> - printf("%s: unable to get iocfacts\n", DEVNAME(sc));
> + if (mpii_init(sc) != 0) {
> + printf("%s: unable to initialize ioc\n", DEVNAME(sc));
> goto unmap;
> }
>
> @@ -556,7 +562,8 @@ mpii_attach(struct device *parent, struc
>
> /* XXX bail on unsupported porttype? */
> if ((sc->sc_porttype == MPII_PORTFACTS_PORTTYPE_SAS_PHYSICAL) ||
> - (sc->sc_porttype == MPII_PORTFACTS_PORTTYPE_SAS_VIRTUAL)) {
> + (sc->sc_porttype == MPII_PORTFACTS_PORTTYPE_SAS_VIRTUAL) ||
> + (sc->sc_porttype == MPII_PORTFACTS_PORTTYPE_TRI_MODE)) {
> if (mpii_eventnotify(sc) != 0) {
> printf("%s: unable to enable events\n", DEVNAME(sc));
> goto free_queues;
> @@ -876,7 +883,8 @@ mpii_scsi_probe(struct scsi_link *link)
> int flags;
>
> if ((sc->sc_porttype != MPII_PORTFACTS_PORTTYPE_SAS_PHYSICAL) &&
> - (sc->sc_porttype != MPII_PORTFACTS_PORTTYPE_SAS_VIRTUAL))
> + (sc->sc_porttype != MPII_PORTFACTS_PORTTYPE_SAS_VIRTUAL) &&
> + (sc->sc_porttype != MPII_PORTFACTS_PORTTYPE_TRI_MODE))
> return (ENXIO);
>
> dev = sc->sc_devs[link->target];
> @@ -1261,12 +1269,16 @@ mpii_iocfacts(struct mpii_softc *sc)
> if (ISSET(lemtoh32(&ifp.ioc_capabilities),
> MPII_IOCFACTS_CAPABILITY_INTEGRATED_RAID))
> SET(sc->sc_flags, MPII_F_RAID);
> + if (ISSET(lemtoh32(&ifp.ioc_capabilities),
> + MPII_IOCFACTS_CAPABILITY_EVENT_REPLAY))
> + sc->sc_ioc_event_replay = 1;
>
> sc->sc_max_cmds = MIN(lemtoh16(&ifp.reques
Re: [patch] config(8) and KARL usage
On 17/01/18 11:40 +0100, Martin Pieuchot wrote: > Hello Sebastien, > > On 17/01/18(Wed) 10:19, Sebastien Marie wrote: > > [...] > > kernel modification is desirable in some cases, at least for disabling > > ulpt(4) when using cups with USB printer. > > Sorry to hijack your thread, but if somebody wants to fix this ulpt(4) > problem permanently here's the plan: > > - Add the USBD_EXCLUSIVE_USE to usbd_open_pipe() in ulptopen(). >Actually this flag should be the default everywhere. This should >prevent open(2) on /dev/ulpt? to work if a userland driver is using >your printer. > > - Do some plumbing between libusb/ugen(4)/usb(4) to make it possible >to submit bulk transfer via /dev/usb?. The logic in ugenopen() >should also have the USBD_EXCLUSIVE_USE flag such that it will fail >if the corresponding /dev/ultp? has already been opened. > > That should be enough to have CUPS work with GENERIC kernels without > having to disable anything. I'm here to help/review diffs but since > I don't have a printer myself, I can't do the work. > Oh yes please.
Re: preliminary kabylake support for inteldrm
Hi
This is an updated diff for preliminary kabylake support for 6.2,
this needs extensive testing on all inteldrm variants.
This diff is also in snapshots now so please, test, test test!
Thank you
Index: sys/dev/pci/drm/i915_pciids.h
===
RCS file: /cvs/src/sys/dev/pci/drm/i915_pciids.h,v
retrieving revision 1.3
diff -u -p -u -r1.3 i915_pciids.h
--- sys/dev/pci/drm/i915_pciids.h 1 Jul 2017 16:14:10 - 1.3
+++ sys/dev/pci/drm/i915_pciids.h 26 Sep 2017 14:57:52 -
@@ -295,4 +295,40 @@
INTEL_VGA_DEVICE(0x5A84, info), /* APL HD Graphics 505 */ \
INTEL_VGA_DEVICE(0x5A85, info) /* APL HD Graphics 500 */
+#define INTEL_KBL_GT1_IDS(info)\
+ INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
+ INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
+ INTEL_VGA_DEVICE(0x5917, info), /* DT GT1.5 */ \
+ INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
+ INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
+ INTEL_VGA_DEVICE(0x5902, info), /* DT GT1 */ \
+ INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
+ INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
+
+#define INTEL_KBL_GT2_IDS(info)\
+ INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
+ INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \
+ INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
+ INTEL_VGA_DEVICE(0x5912, info), /* DT GT2 */ \
+ INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \
+ INTEL_VGA_DEVICE(0x591A, info), /* SRV GT2 */ \
+ INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
+
+#define INTEL_KBL_GT3_IDS(info)\
+ INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
+ INTEL_VGA_DEVICE(0x592B, info), /* Halo GT3 */ \
+ INTEL_VGA_DEVICE(0x592A, info) /* SRV GT3 */
+
+#define INTEL_KBL_GT4_IDS(info)\
+ INTEL_VGA_DEVICE(0x5932, info), /* DT GT4 */ \
+ INTEL_VGA_DEVICE(0x593B, info), /* Halo GT4 */ \
+ INTEL_VGA_DEVICE(0x593A, info), /* SRV GT4 */ \
+ INTEL_VGA_DEVICE(0x593D, info) /* WKS GT4 */
+
+#define INTEL_KBL_IDS(info) \
+ INTEL_KBL_GT1_IDS(info), \
+ INTEL_KBL_GT2_IDS(info), \
+ INTEL_KBL_GT3_IDS(info), \
+ INTEL_KBL_GT4_IDS(info)
+
#endif /* _I915_PCIIDS_H */
Index: sys/dev/pci/drm/i915/i915_devlist.h
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_devlist.h,v
retrieving revision 1.6
diff -u -p -u -r1.6 i915_devlist.h
--- sys/dev/pci/drm/i915/i915_devlist.h 6 Jul 2017 10:09:26 - 1.6
+++ sys/dev/pci/drm/i915/i915_devlist.h 26 Sep 2017 14:57:52 -
@@ -154,4 +154,26 @@ static const struct pci_matchid i915_dev
{ 0x8086, 0x1a85 },
{ 0x8086, 0x5a84 },
{ 0x8086, 0x5a85 },
+ { 0x8086, 0x5913 },
+ { 0x8086, 0x5915 },
+ { 0x8086, 0x5917 },
+ { 0x8086, 0x5906 },
+ { 0x8086, 0x590e },
+ { 0x8086, 0x5902 },
+ { 0x8086, 0x590b },
+ { 0x8086, 0x590a },
+ { 0x8086, 0x5916 },
+ { 0x8086, 0x5921 },
+ { 0x8086, 0x591e },
+ { 0x8086, 0x5912 },
+ { 0x8086, 0x591b },
+ { 0x8086, 0x591a },
+ { 0x8086, 0x591d },
+ { 0x8086, 0x5926 },
+ { 0x8086, 0x592b },
+ { 0x8086, 0x592a },
+ { 0x8086, 0x5932 },
+ { 0x8086, 0x593b },
+ { 0x8086, 0x593a },
+ { 0x8086, 0x593d },
};
Index: sys/dev/pci/drm/i915/i915_dma.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_dma.c,v
retrieving revision 1.25
diff -u -p -u -r1.25 i915_dma.c
--- sys/dev/pci/drm/i915/i915_dma.c 1 Jul 2017 16:14:10 - 1.25
+++ sys/dev/pci/drm/i915/i915_dma.c 26 Sep 2017 14:57:52 -
@@ -712,7 +712,8 @@ static void gen9_sseu_info_init(struct d
* supports EU power gating on devices with more than one EU
* pair per subslice.
*/
- info->has_slice_pg = (IS_SKYLAKE(dev) && (info->slice_total > 1));
+ info->has_slice_pg = ((IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) &&
+ (info->slice_total > 1));
info->has_subslice_pg = (IS_BROXTON(dev) && (info->subslice_total > 1));
info->has_eu_pg = (info->eu_per_subslice > 2);
}
@@ -858,6 +859,37 @@ static void intel_device_info_runtime_in
DRM_INFO("Display fused off, disabling\n");
info->num_pipes = 0;
}
+ } else if (info->num_pipes > 0 && INTEL_INFO(dev)->gen == 9) {
+ u32 dfsm = I915_READ(SKL_DFSM);
+ u8 disabled_mask = 0;
+ bool invalid;
+ int num_bits;
+
+ if (dfsm & SKL_DFSM_PIPE_A_DISABLE)
+ disabled_mask |= BIT(PIPE_A);
+ if (dfsm & SKL_DFSM_PIPE_B_DISABLE)
+ disabled_mask |= BIT(PIPE_B);
+
preliminary kabylake support for inteldrm
Hi!
It turns out that the changes to get kabylake to work are quiet minimal so I
took a
stab at it and backported all the relevant kabylake commits from linux-4.8.y to
our drm tree. I did not touch anything outside of dev/pci/drm/i915 on purprose,
so that the update work of kettenis@ is only touched minimally.
There are some not really needed changes but at least that syncs some code with
linux for the future as well.
I am sending this diff to tech@ so that we can get more tests. You can run this
with !kabylake as well to see if there is any regression.
Index: sys/dev/pci/drm/i915_pciids.h
===
RCS file: /cvs/src/sys/dev/pci/drm/i915_pciids.h,v
retrieving revision 1.3
diff -u -p -u -r1.3 i915_pciids.h
--- sys/dev/pci/drm/i915_pciids.h 1 Jul 2017 16:14:10 - 1.3
+++ sys/dev/pci/drm/i915_pciids.h 5 Sep 2017 22:50:05 -
@@ -295,4 +295,40 @@
INTEL_VGA_DEVICE(0x5A84, info), /* APL HD Graphics 505 */ \
INTEL_VGA_DEVICE(0x5A85, info) /* APL HD Graphics 500 */
+#define INTEL_KBL_GT1_IDS(info)\
+ INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
+ INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
+ INTEL_VGA_DEVICE(0x5917, info), /* DT GT1.5 */ \
+ INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
+ INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
+ INTEL_VGA_DEVICE(0x5902, info), /* DT GT1 */ \
+ INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
+ INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
+
+#define INTEL_KBL_GT2_IDS(info)\
+ INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
+ INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \
+ INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
+ INTEL_VGA_DEVICE(0x5912, info), /* DT GT2 */ \
+ INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \
+ INTEL_VGA_DEVICE(0x591A, info), /* SRV GT2 */ \
+ INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
+
+#define INTEL_KBL_GT3_IDS(info)\
+ INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
+ INTEL_VGA_DEVICE(0x592B, info), /* Halo GT3 */ \
+ INTEL_VGA_DEVICE(0x592A, info) /* SRV GT3 */
+
+#define INTEL_KBL_GT4_IDS(info)\
+ INTEL_VGA_DEVICE(0x5932, info), /* DT GT4 */ \
+ INTEL_VGA_DEVICE(0x593B, info), /* Halo GT4 */ \
+ INTEL_VGA_DEVICE(0x593A, info), /* SRV GT4 */ \
+ INTEL_VGA_DEVICE(0x593D, info) /* WKS GT4 */
+
+#define INTEL_KBL_IDS(info) \
+ INTEL_KBL_GT1_IDS(info), \
+ INTEL_KBL_GT2_IDS(info), \
+ INTEL_KBL_GT3_IDS(info), \
+ INTEL_KBL_GT4_IDS(info)
+
#endif /* _I915_PCIIDS_H */
Index: sys/dev/pci/drm/i915/i915_dma.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_dma.c,v
retrieving revision 1.25
diff -u -p -u -r1.25 i915_dma.c
--- sys/dev/pci/drm/i915/i915_dma.c 1 Jul 2017 16:14:10 - 1.25
+++ sys/dev/pci/drm/i915/i915_dma.c 5 Sep 2017 22:50:06 -
@@ -712,7 +712,8 @@ static void gen9_sseu_info_init(struct d
* supports EU power gating on devices with more than one EU
* pair per subslice.
*/
- info->has_slice_pg = (IS_SKYLAKE(dev) && (info->slice_total > 1));
+ info->has_slice_pg = ((IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) &&
+ (info->slice_total > 1));
info->has_subslice_pg = (IS_BROXTON(dev) && (info->subslice_total > 1));
info->has_eu_pg = (info->eu_per_subslice > 2);
}
@@ -858,6 +859,37 @@ static void intel_device_info_runtime_in
DRM_INFO("Display fused off, disabling\n");
info->num_pipes = 0;
}
+ } else if (info->num_pipes > 0 && INTEL_INFO(dev)->gen == 9) {
+ u32 dfsm = I915_READ(SKL_DFSM);
+ u8 disabled_mask = 0;
+ bool invalid;
+ int num_bits;
+
+ if (dfsm & SKL_DFSM_PIPE_A_DISABLE)
+ disabled_mask |= BIT(PIPE_A);
+ if (dfsm & SKL_DFSM_PIPE_B_DISABLE)
+ disabled_mask |= BIT(PIPE_B);
+ if (dfsm & SKL_DFSM_PIPE_C_DISABLE)
+ disabled_mask |= BIT(PIPE_C);
+
+ num_bits = hweight8(disabled_mask);
+
+ switch (disabled_mask) {
+ case BIT(PIPE_A):
+ case BIT(PIPE_B):
+ case BIT(PIPE_A) | BIT(PIPE_B):
+ case BIT(PIPE_A) | BIT(PIPE_C):
+ invalid = true;
+ break;
+ default:
+ invalid = false;
+ }
+
+ if (num_bits > info->num_pipes || invalid)
+ DRM_ERROR("invalid pipe fuse configuration: 0x%x\n",
+ disabled_mask);
+ else
+ info->num_pipes -= num_bits;
Re: mountd is immortal
On (2011-07-28 11:17), Mark Kettenis wrote: > > Date: Thu, 28 Jul 2011 10:16:00 +0200 > > From: David Coppa > > > > On Thu, 28 Jul 2011, Robert Nagy wrote: > > > > > It seems that SIGTERM is not enough for mountd, according to the code > > > SIGTERM only sends a RPCMNT_UMNTALL broadcast to the clients. > > > So I think what we should do in this case is to first send a SIGTERM to > > > mountd, > > > and then SIGKILL it in rc_stop(). > > > > Something like this? the sleep is just paranoia, don't know if it's > > useful... > > Well, that sleep makes some sense at least; you want to give the > daemon some time to clean up. The question is whether a single second > is enough for that... Well mountd actually dies about 1.5-2 minutes after sending it a SIGTERM...
Re: mountd is immortal
On (2011-07-28 10:30), Ingo Schwarze wrote:
> Hi Antoine,
>
> Antoine Jacoutot wrote on Thu, Jul 28, 2011 at 10:22:56AM +0200:
> > On Thu, 28 Jul 2011, David Coppa wrote:
> >> On Thu, 28 Jul 2011, Robert Nagy wrote:
>
> >>> It seems that SIGTERM is not enough for mountd, according to the code
> >>> SIGTERM only sends a RPCMNT_UMNTALL broadcast to the clients.
> >>> So I think what we should do in this case is to first send a SIGTERM
> >>> to mountd, and then SIGKILL it in rc_stop().
>
> >> Something like this? the sleep is just paranoia, don't know
> >> if it's useful...
>
> > Why not use rc_post for SIGKILL?
>
> Because
>
> rc_do rc_wait stop || rc_exit failed
>
> is called before rc_post.
>
> When the daemon refuses to die, the post-mortem action will not
> even be attempted.
>
> >> Index: mountd
> >> ===
> >> RCS file: /cvs/src/etc/rc.d/mountd,v
> >> retrieving revision 1.1
> >> diff -u -p -r1.1 mountd
> >> --- mountd 8 Jul 2011 00:54:04 - 1.1
> >> +++ mountd 28 Jul 2011 08:15:37 -
> >> @@ -6,4 +6,10 @@ daemon="/sbin/mountd"
> >>
> >> . /etc/rc.d/rc.subr
> >>
> >> +rc_stop() {
> >> + pkill -f "^${pexp}"
> >> + sleep 1
> >> + pkill -9 -f "^${pexp}"
> >> +}
> >> +
> >> rc_cmd $1
>
> I worry more that fixed-time sleeps often prove to short,
> not so much that it might be useless, but i don't see a better
> option right now. Sorry, I can't test or look in more detail
> right now.
>
> Yours,
> Ingo
>
I am not sure that we want to sleep or not. Theo what do you think?
Re: mountd is immortal
On (2011-07-28 10:22), Antoine Jacoutot wrote: > On Thu, 28 Jul 2011, David Coppa wrote: > > > On Thu, 28 Jul 2011, Robert Nagy wrote: > > > > > It seems that SIGTERM is not enough for mountd, according to the code > > > SIGTERM only sends a RPCMNT_UMNTALL broadcast to the clients. > > > So I think what we should do in this case is to first send a SIGTERM to > > > mountd, > > > and then SIGKILL it in rc_stop(). > > > > Something like this? the sleep is just paranoia, don't know if it's > > useful... > > Why not use rc_post for SIGKILL? Because rc_post() does not get called if rc_stop() fails and it does because mountd does not die after the SIGTERM.
Re: mountd is immortal
It seems that SIGTERM is not enough for mountd, according to the code SIGTERM only sends a RPCMNT_UMNTALL broadcast to the clients. So I think what we should do in this case is to first send a SIGTERM to mountd, and then SIGKILL it in rc_stop(). On (2011-07-28 09:46), David Coppa wrote: > It doesn't want to die... > > Do you see this problem or is it just mine? > Any clue? > > # /etc/rc.d/mountd start > mountd(ok) > # ps akuwwx|grep -v grep|grep mountd > root 15715 0.0 0.0 616 368 ?? Ss 9:39AM0:00.00 /sbin/mountd > # /etc/rc.d/nfsd start > nfsd(ok) > # ps akuwwx|grep -v grep|grep nfs > root 11051 0.0 0.0 120 156 ?? S 9:39AM0:00.00 nfsd: > server (nfsd) > root 9270 0.0 0.0 120 156 ?? S 9:39AM0:00.00 nfsd: > server (nfsd) > root 10254 0.0 0.0 120 156 ?? S 9:39AM0:00.00 nfsd: > server (nfsd) > root 20969 0.0 0.0 156 228 ?? Ss 9:39AM0:00.00 /sbin/nfsd > -tun 4 > root 17010 0.0 0.0 120 156 ?? S 9:39AM0:00.00 nfsd: > server (nfsd) > # /etc/rc.d/nfsd stop > nfsd(ok) > # ps akuwwx|grep -v grep|grep nfs > # time /etc/rc.d/mountd stop > mountd(failed) > 0m30.32s real 0m0.00s user 0m0.01s system > # ps akuwwx|grep -v grep|grep mountd > root 15715 0.0 0.0 616 388 ?? Ss 9:39AM0:00.00 /sbin/mountd > # pkill -f /sbin/mountd > # ps akuwwx|grep -v grep|grep mountd > root 15715 0.0 0.0 616 388 ?? Ss 9:39AM0:00.00 /sbin/mountd > # pkill -9 -f /sbin/mountd > # ps akuwwx|grep -v grep|grep mountd > #
Re: Incorrect startup order of local/package daemons
Yes, i think that's right. Theo do you aggree?
On (2011-07-18 09:39), David Coppa wrote:
> Hi all,
>
> Found this yesterday, after installing mpd on my box:
>
>
> starting package daemons: aiccu dbus_daemon mpd.
> starting local daemons: apmd hotplugd cron aucat(failed).
>
>
> I think the startup order should be inverted...
>
> cheers,
> david
>
> Index: rc
> ===
> RCS file: /cvs/src/etc/rc,v
> retrieving revision 1.385
> diff -u -p -r1.385 rc
> --- rc11 Jul 2011 17:20:09 - 1.385
> +++ rc18 Jul 2011 07:29:40 -
> @@ -538,15 +538,6 @@ if [ -f /etc/rc.firsttime ]; then
> fi
> rm -f /etc/rc.firsttime.run
>
> -# Run rc.d(8) scripts from packages
> -if [ -n "${pkg_scripts}" ]; then
> - echo -n 'starting package daemons:'
> - for _r in $pkg_scripts; do
> - [ -x /etc/rc.d/${_r} ] && start_daemon ${_r}
> - done
> - echo '.'
> -fi
> -
> [ -f /etc/rc.local ] && . /etc/rc.local
>
> ifconfig -g carp -carpdemote 128 # disable carp interlock
> @@ -555,6 +546,15 @@ mixerctl_conf
> echo -n 'starting local daemons:'
> start_daemon apmd sensorsd hotplugd watchdogd cron aucat wsmoused xdm
> echo '.'
> +
> +# Run rc.d(8) scripts from packages
> +if [ -n "${pkg_scripts}" ]; then
> + echo -n 'starting package daemons:'
> + for _r in $pkg_scripts; do
> + [ -x /etc/rc.d/${_r} ] && start_daemon ${_r}
> + done
> + echo '.'
> +fi
>
> date
> exit 0
Important bge(4) diff to test!
Hello,
The following diff is really important because on some machines
bge(4) gets detached because of ASPM. The following diff is also
in the latest snapshots but you can also compile a kernel with it.
So if you have a bge(4) please update/compile a kernel and get
back to me if it works or fails in some way.
Thank you!
Index: if_bge.c
===
RCS file: /cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.303
diff -u -r1.303 if_bge.c
--- if_bge.c20 Sep 2010 07:40:38 - 1.303
+++ if_bge.c15 Feb 2011 09:02:07 -
@@ -1794,7 +1794,7 @@
struct pci_attach_args *pa = aux;
pci_chipset_tag_t pc = pa->pa_pc;
const struct bge_revision *br;
- pcireg_tpm_ctl, memtype, subid;
+ pcireg_tpm_ctl, memtype, subid, reg;
pci_intr_handle_t ih;
const char *intrstr = NULL;
bus_size_t size;
@@ -1885,7 +1885,13 @@
* PCI Express or PCI-X controller check.
*/
if (pci_get_capability(pa->pa_pc, pa->pa_tag, PCI_CAP_PCIEXPRESS,
- NULL, NULL) != 0) {
+ &sc->bge_aspm_off, NULL) != 0) {
+ /* Disable PCIe Active State Power Management (ASPM). */
+ reg = pci_conf_read(pa->pa_pc, pa->pa_tag,
+ sc->bge_aspm_off + PCI_PCIE_LCSR);
+ reg &= ~(PCI_PCIE_LCSR_ASPM_L0S | PCI_PCIE_LCSR_ASPM_L1);
+ pci_conf_write(pa->pa_pc, pa->pa_tag,
+ sc->bge_aspm_off + PCI_PCIE_LCSR, reg);
sc->bge_flags |= BGE_PCIE;
} else {
if ((pci_conf_read(pa->pa_pc, pa->pa_tag, BGE_PCI_PCISTATE) &
Index: if_bgereg.h
===
RCS file: /cvs/src/sys/dev/pci/if_bgereg.h,v
retrieving revision 1.103
diff -u -r1.103 if_bgereg.h
--- if_bgereg.h 20 Sep 2010 07:40:38 - 1.103
+++ if_bgereg.h 15 Feb 2011 09:02:07 -
@@ -2610,6 +2610,7 @@
#define BGE_5714_FAMILY0x0100
#define BGE_5700_FAMILY0x0200
+ int bge_aspm_off;
bus_dma_tag_t bge_dmatag;
u_int32_t bge_chipid;
struct bge_ring_data*bge_rdata; /* rings */
Thank you for making p2k9 possible!
Hello p2k9 (the ports hackathon in Budapest) is on since Friday. People are working on different things like GNOME, GCC4, BluRay support or even ACPI. I would like to thank everyone who donated money to the project because the individual donors made it possible to organize this event. So ... BIG THANKS GOES TO OUR USERS, to people supporting the project even at these times. I'd also like to thank NIIF and Sun Microsystems Hungary for lending us a nice hackroom and hardware for the hackathon.
