Re: ttycreate from FreeBSD equivalent
Ok well I have been using puc_cardbus as a starting point and in fact in the beginning I was hoping to just the interrupt handler and so on to it, but I belive com(4) cannot be used for the serial ports this card presents. I'm confused as to how things interact with the device tree: I see for example that cz(4) should come up at /dev/cuaZ* yet there is a cdev_decl(cztty) in dev/pci/cz.c. Will I also have to add an entry in sys/conf or e.g. arch/macppc/macppc/conf.c ? Thank you for taking interest
[Diff] Keyboard backlight support for late powerbooks, plus keybindings
Hello. Following up on my previous post
https://marc.info/?l=openbsd-ppc=166150553627054=2
I actually implemented support for fn-keys controls of the keyboard
backlight as outlined there, seems to work fairly ok, would appreciate
any feedback
Index: arch/macppc/dev/adb.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/adb.c,v
retrieving revision 1.49
diff -u -p -r1.49 adb.c
--- arch/macppc/dev/adb.c 26 Dec 2022 19:17:00 - 1.49
+++ arch/macppc/dev/adb.c 28 Feb 2023 03:56:11 -
@@ -102,6 +102,8 @@
#include
#include
+#include
+
#include "apm.h"
#define printf_intr printf
@@ -242,6 +244,12 @@ void setsoftadb(void);
intadb_intr(void *arg);
void adb_cuda_autopoll(void);
void adb_cuda_fileserver_mode(void);
+uint8_t pmu_backlight; /* keyboard backlight value */
+intpmu_get_backlight(struct wskbd_backlight *);
+intpmu_set_backlight(struct wskbd_backlight *);
+extern int (*wskbd_get_backlight)(struct wskbd_backlight *);
+extern int (*wskbd_set_backlight)(struct wskbd_backlight *);
+
#ifndef SMALL_KERNEL
void adb_shutdown(void *);
@@ -1730,8 +1738,11 @@ adbattach(struct device *parent, struct
if (adbHardware == ADB_HW_CUDA)
adb_cuda_fileserver_mode();
- if (adbHardware == ADB_HW_PMU)
+ if (adbHardware == ADB_HW_PMU) {
+ wskbd_get_backlight = pmu_get_backlight;
+ wskbd_set_backlight = pmu_set_backlight;
pmu_fileserver_mode(1);
+ }
/*
* XXX If the machine doesn't have an ADB bus (PowerBook5,6+)
@@ -1757,4 +1768,20 @@ adbattach(struct device *parent, struct
if (adbHardware == ADB_HW_CUDA)
adb_cuda_autopoll();
adb_polling = 0;
+}
+
+int
+pmu_get_backlight(struct wskbd_backlight *kbl)
+{
+ kbl->min = 0;
+ kbl->max = 0xff;
+ kbl->curval = pmu_backlight;
+ return 0;
+}
+
+int
+pmu_set_backlight(struct wskbd_backlight *kbl)
+{
+ pmu_backlight = kbl->curval;
+ return pmu_set_kbl(pmu_backlight);
}
Index: arch/macppc/dev/pm_direct.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/pm_direct.c,v
retrieving revision 1.34
diff -u -p -r1.34 pm_direct.c
--- arch/macppc/dev/pm_direct.c 28 Dec 2022 07:40:23 - 1.34
+++ arch/macppc/dev/pm_direct.c 28 Feb 2023 03:56:12 -
@@ -853,3 +853,22 @@ pmu_fileserver_mode(int on)
}
pmgrop();
}
+
+int
+pmu_set_kbl(unsigned int level)
+{
+ if (level > 0xff)
+ return (EINVAL);
+
+ PMData p;
+
+ p.command = 0x4F;
+ p.num_data = 3;
+ p.s_buf = p.r_buf = p.data;
+ p.data[0] = 0;
+ p.data[1] = 0;
+ p.data[2] = level;
+ pmgrop();
+ return (0);
+}
+
Index: arch/macppc/dev/pm_direct.h
===
RCS file: /cvs/src/sys/arch/macppc/dev/pm_direct.h,v
retrieving revision 1.15
diff -u -p -r1.15 pm_direct.h
--- arch/macppc/dev/pm_direct.h 21 Oct 2022 22:42:36 - 1.15
+++ arch/macppc/dev/pm_direct.h 28 Feb 2023 03:56:12 -
@@ -67,6 +67,7 @@ struct pmu_battery_info
};
int pm_battery_info(int, struct pmu_battery_info *);
+int pmu_set_kbl(unsigned int);
void pm_eject_pcmcia(int);
void pmu_fileserver_mode(int);
Index: dev/hid/hidkbd.c
===
RCS file: /cvs/src/sys/dev/hid/hidkbd.c,v
retrieving revision 1.8
diff -u -p -r1.8 hidkbd.c
--- dev/hid/hidkbd.c9 Nov 2022 10:05:18 - 1.8
+++ dev/hid/hidkbd.c28 Feb 2023 03:56:13 -
@@ -143,6 +143,10 @@ static const struct hidkbd_translation a
{ 60, 127 },/* F3 -> audio mute */
{ 61, 129 },/* F4 -> audio lower */
{ 62, 128 },/* F5 -> audio raise */
+ { 63, 83 }, /* F6 -> num lock */
+ { 65, 234 },/* F8 -> backlight toggle*/
+ { 66, 236 },/* F9 -> backlight lower */
+ { 67, 235 },/* F10 -> backlight raise*/
#else
{ 67, 127 },/* F10 -> audio mute */
{ 68, 129 },/* F11 -> audio lower */
@@ -567,6 +571,9 @@ hidkbd_decode(struct hidkbd *kbd, struct
case 129:
case 232:
case 233:
+ case 234:
+ case 235:
+ case 236:
wskbd_input(kbd->sc_wskbddev,
key & RELEASE ? WSCONS_EVENT_KEY_UP :
WSCONS_EVENT_KEY_DOWN, key & CODEMASK);
Index: dev/usb/makemap.awk
===
RCS file: /cvs/src/sys/dev/usb/makemap.awk,v
retrieving revision 1.15
diff -u -p -r1.15 makemap.awk
--- dev/usb/makemap.awk 2 Nov 2020 19:45:18 - 1.15
+++ dev/usb/makemap.awk 28 Feb 2023 03:56:15 -
@@
Re: kernel: don't jump ticks, jiffies during boot
On Tue, Feb 28, 2023 at 01:01:32PM +1100, Jonathan Gray wrote:
> On Mon, Feb 27, 2023 at 06:26:00PM -0600, Scott Cheloha wrote:
> > On Tue, Feb 28, 2023 at 10:18:16AM +1100, Jonathan Gray wrote:
> > > On Mon, Feb 27, 2023 at 04:57:04PM -0600, Scott Cheloha wrote:
> > > > ticks and jiffies start at zero. During boot in initclocks(), we
> > > > reset them:
> > > >
> > > > /* sys/kern/kern_clock.c */
> > > >
> > > > 89 int ticks;
> > > > 90 static int psdiv, pscnt;/* prof => stat divider
> > > > */
> > > > 91 int psratio;/* ratio: prof / stat */
> > > > 92
> > > > 93 volatile unsigned long jiffies; /* XXX Linux API for
> > > > drm(4) */
> > > > 94
> > > > 95 /*
> > > > 96 * Initialize clock frequencies and start both clocks running.
> > > > 97 */
> > > > 98 void
> > > > 99 initclocks(void)
> > > >100 {
> > > >101 ticks = INT_MAX - (15 * 60 * hz);
> > > >102 jiffies = ULONG_MAX - (10 * 60 * hz);
> > > >103
> > > >104 /* [... ] */
> > > >
> > > > The idea here (committed by dlg@) is sound. We reset ticks and
> > > > jiffies to near-rollover values to catch buggy code misusing them.
> > > >
> > > > But! That jump from zero to whatever violates valid assumptions made
> > > > by correct code, too.
> > >
> > > Assumptions made by what code? Does it exist in the tree?
> >
> > First, even if the code did not exist, wouldn't it be simpler to not
> > do the jump? No?
>
> There are enough problems to fix without chasing ones that
> don't exist.
>
> > Second, with rare exception, all kernel code using ticks/jiffies
> > assumes ticks/jiffies does not advance more than once every 1/hz
> > seconds on average.
> >
> > In timeout_add(9), we assign an absolute expiration time relative
> > to the current value of ticks. Code calling timeout_add(9) before
> > initclocks() cannot account for the jump in initclocks().
>
> What code calling timeout_add() before initclocks()?
I count 8 calls on my laptop:
#0 timeout_add+0x43
#1 random_start+0xb7
#2 main+0x96
#3 longmode_hi+0x9c
#0 timeout_add+0x43
#1 thinkpad_attach+0x1f9
#2 config_attach+0x1f4
#3 acpi_foundhid+0x326
#4 aml_find_node+0x74
#5 aml_find_node+0xa1
#6 aml_find_node+0xa1
#7 aml_find_node+0xa1
#8 aml_find_node+0xa1
#9 aml_find_node+0xa1
#10 acpi_attach_common+0x6f4
#11 config_attach+0x1f4
#12 bios_attach+0x74f
#13 config_attach+0x1f4
#14 mainbus_attach+0x7b
#15 config_attach+0x1f4
#16 config_rootfound+0xd2
#17 cpu_configure+0x2a
#18 main+0x3a8
#0 timeout_add+0x43
#1 acpibat_attach+0x171
#2 config_attach+0x1f4
#3 acpi_foundhid+0x326
#4 aml_find_node+0x74
#5 aml_find_node+0xa1
#6 aml_find_node+0xa1
#7 aml_find_node+0xa1
#8 aml_find_node+0xa1
#9 aml_find_node+0xa1
#10 acpi_attach_common+0x6f4
#11 config_attach+0x1f4
#12 bios_attach+0x74f
#13 config_attach+0x1f4
#14 mainbus_attach+0x7b
#15 config_attach+0x1f4
#16 config_rootfound+0xd2
#17 cpu_configure+0x2a
#18 main+0x3a8
#0 timeout_add+0x43
#1 acpitz_attach+0x559
#2 config_attach+0x1f4
#3 acpi_add_device+0x147
#4 aml_walknodes+0x3b
#5 aml_walknodes+0x61
#6 aml_walknodes+0x61
#7 acpi_attach_common+0x712
#8 config_attach+0x1f4
#9 bios_attach+0x74f
#10 config_attach+0x1f4
#11 mainbus_attach+0x7b
#12 config_attach+0x1f4
#13 config_rootfound+0xd2
#14 cpu_configure+0x2a
#15 main+0x3a8
#0 timeout_add+0x43
#1 if_attachsetup+0x102
#2 if_attach+0x4e
#3 iwm_attach+0xe5a
#4 config_attach+0x1f4
#5 pci_probe_device+0x515
#6 pci_enumerate_bus+0x189
#7 config_attach+0x1f4
#8 ppbattach+0x790
#9 config_attach+0x1f4
#10 pci_probe_device+0x515
#11 pci_enumerate_bus+0x189
#12 config_attach+0x1f4
#13 acpipci_attach_bus+0x1b3
#14 acpipci_attach_busses+0x4d
#15 mainbus_attach+0x1c6
#16 config_attach+0x1f4
#17 config_rootfound+0xd2
#18 cpu_configure+0x2a
#0 timeout_add+0x43
#1 if_attachsetup+0x102
#2 if_attach+0x4e
#3 em_setup_interface+0x1c6
#4 em_attach+0x401
#5 config_attach+0x1f4
#6 pci_probe_device+0x515
#7 pci_enumerate_bus+0x189
#8 config_attach+0x1f4
#9 acpipci_attach_bus+0x1b3
#10 acpipci_attach_busses+0x4d
#11 mainbus_attach+0x1c6
#12 config_attach+0x1f4
#13 config_rootfound+0xd2
#14 cpu_configure+0x2a
#15 main+0x3a8
#0 timeout_add+0x43
#1 pckbdattach+0x172
#2 config_attach+0x1f4
#3 pckbc_attach+0x239
#4 pckbc_isa_attach+0x17c
#5 config_attach+0x1f4
#6 isascan+0x309
#7 config_scan+0xab
#8 config_attach+0x1f4
#9 pcib_callback+0x62
#10 config_process_deferred_children+0x83
#11 config_attach+0x1fc
#12 acpipci_attach_bus+0x1b3
#13 acpipci_attach_busses+0x4d
#14 mainbus_attach+0x1c6
#15 config_attach+0x1f4
#16 config_rootfound+0xd2
#17 cpu_configure+0x2a
#18 main+0x3a8
#0 timeout_add+0x43
#1 azalia_rirb_intr+0x67
#2 azalia_intr+0xe1
#3 intr_handler+0x67
#4 Xintr_ioapic_edge22_untramp+0x18f
#5 Xspllower+0x17
#6 cpu_configure+0x76
#7 main+0x3a8
#0 timeout_add+0x43
#1
Re: kernel: don't jump ticks, jiffies during boot
On Mon, Feb 27, 2023 at 06:26:00PM -0600, Scott Cheloha wrote:
> On Tue, Feb 28, 2023 at 10:18:16AM +1100, Jonathan Gray wrote:
> > On Mon, Feb 27, 2023 at 04:57:04PM -0600, Scott Cheloha wrote:
> > > ticks and jiffies start at zero. During boot in initclocks(), we
> > > reset them:
> > >
> > > /* sys/kern/kern_clock.c */
> > >
> > > 89int ticks;
> > > 90static int psdiv, pscnt;/* prof => stat divider
> > > */
> > > 91int psratio;/* ratio: prof / stat */
> > > 92
> > > 93volatile unsigned long jiffies; /* XXX Linux API for
> > > drm(4) */
> > > 94
> > > 95/*
> > > 96 * Initialize clock frequencies and start both clocks running.
> > > 97 */
> > > 98void
> > > 99initclocks(void)
> > >100{
> > >101ticks = INT_MAX - (15 * 60 * hz);
> > >102jiffies = ULONG_MAX - (10 * 60 * hz);
> > >103
> > >104/* [... ] */
> > >
> > > The idea here (committed by dlg@) is sound. We reset ticks and
> > > jiffies to near-rollover values to catch buggy code misusing them.
> > >
> > > But! That jump from zero to whatever violates valid assumptions made
> > > by correct code, too.
> >
> > Assumptions made by what code? Does it exist in the tree?
>
> First, even if the code did not exist, wouldn't it be simpler to not
> do the jump? No?
There are enough problems to fix without chasing ones that
don't exist.
>
> Second, with rare exception, all kernel code using ticks/jiffies
> assumes ticks/jiffies does not advance more than once every 1/hz
> seconds on average.
>
> In timeout_add(9), we assign an absolute expiration time relative
> to the current value of ticks. Code calling timeout_add(9) before
> initclocks() cannot account for the jump in initclocks().
What code calling timeout_add() before initclocks()?
>
> There is probably equivalent code in drm(4) making the same
> assumption.
The vast majority of drm runs after root is mounted.
>
> Relatedly, in cpu_relax() we increment jiffies if the kernel is
> cold:
>
> sys/dev/pci/drm/include/linux/processor.h
>
> 12 static inline void
> 13 cpu_relax(void)
> 14 {
> 15 CPU_BUSY_CYCLE();
> 16 if (cold) {
> 17 delay(tick);
> 18 jiffies++;
> 19 }
> 20 }
>
Re: kernel: don't jump ticks, jiffies during boot
On Tue, Feb 28, 2023 at 10:18:16AM +1100, Jonathan Gray wrote:
> On Mon, Feb 27, 2023 at 04:57:04PM -0600, Scott Cheloha wrote:
> > ticks and jiffies start at zero. During boot in initclocks(), we
> > reset them:
> >
> > /* sys/kern/kern_clock.c */
> >
> > 89 int ticks;
> > 90 static int psdiv, pscnt;/* prof => stat divider
> > */
> > 91 int psratio;/* ratio: prof / stat */
> > 92
> > 93 volatile unsigned long jiffies; /* XXX Linux API for
> > drm(4) */
> > 94
> > 95 /*
> > 96 * Initialize clock frequencies and start both clocks running.
> > 97 */
> > 98 void
> > 99 initclocks(void)
> >100 {
> >101 ticks = INT_MAX - (15 * 60 * hz);
> >102 jiffies = ULONG_MAX - (10 * 60 * hz);
> >103
> >104 /* [... ] */
> >
> > The idea here (committed by dlg@) is sound. We reset ticks and
> > jiffies to near-rollover values to catch buggy code misusing them.
> >
> > But! That jump from zero to whatever violates valid assumptions made
> > by correct code, too.
>
> Assumptions made by what code? Does it exist in the tree?
First, even if the code did not exist, wouldn't it be simpler to not
do the jump? No?
Second, with rare exception, all kernel code using ticks/jiffies
assumes ticks/jiffies does not advance more than once every 1/hz
seconds on average.
In timeout_add(9), we assign an absolute expiration time relative
to the current value of ticks. Code calling timeout_add(9) before
initclocks() cannot account for the jump in initclocks().
There is probably equivalent code in drm(4) making the same
assumption.
Relatedly, in cpu_relax() we increment jiffies if the kernel is
cold:
sys/dev/pci/drm/include/linux/processor.h
12 static inline void
13 cpu_relax(void)
14 {
15 CPU_BUSY_CYCLE();
16 if (cold) {
17 delay(tick);
18 jiffies++;
19 }
20 }
Re: kernel: don't jump ticks, jiffies during boot
On Mon, Feb 27, 2023 at 04:57:04PM -0600, Scott Cheloha wrote:
> ticks and jiffies start at zero. During boot in initclocks(), we
> reset them:
>
> /* sys/kern/kern_clock.c */
>
> 89int ticks;
> 90static int psdiv, pscnt;/* prof => stat divider
> */
> 91int psratio;/* ratio: prof / stat */
> 92
> 93volatile unsigned long jiffies; /* XXX Linux API for
> drm(4) */
> 94
> 95/*
> 96 * Initialize clock frequencies and start both clocks running.
> 97 */
> 98void
> 99initclocks(void)
>100{
>101ticks = INT_MAX - (15 * 60 * hz);
>102jiffies = ULONG_MAX - (10 * 60 * hz);
>103
>104/* [... ] */
>
> The idea here (committed by dlg@) is sound. We reset ticks and
> jiffies to near-rollover values to catch buggy code misusing them.
>
> But! That jump from zero to whatever violates valid assumptions made
> by correct code, too.
Assumptions made by what code? Does it exist in the tree?
>
> It would be better to just initialize ticks and jiffies to the
> near-rollover values when we declare them. To do this we need to
> move their declarations from sys/kern/kern_clock.c to sys/conf/param.c
> where HZ is visible.
>
> ok?
>
> Index: kern/kern_clock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.106
> diff -u -p -r1.106 kern_clock.c
> --- kern/kern_clock.c 4 Feb 2023 19:33:03 - 1.106
> +++ kern/kern_clock.c 27 Feb 2023 22:55:24 -
> @@ -86,21 +86,15 @@ int stathz;
> int schedhz;
> int profhz;
> int profprocs;
> -int ticks;
> static int psdiv, pscnt; /* prof => stat divider */
> int psratio;/* ratio: prof / stat */
>
> -volatile unsigned long jiffies; /* XXX Linux API for drm(4) */
> -
> /*
> * Initialize clock frequencies and start both clocks running.
> */
> void
> initclocks(void)
> {
> - ticks = INT_MAX - (15 * 60 * hz);
> - jiffies = ULONG_MAX - (10 * 60 * hz);
> -
> /*
>* Set divisors to 1 (normal case) and let the machine-specific
>* code do its bit.
> @@ -171,7 +165,8 @@ hardclock(struct clockframe *frame)
>
> tc_ticktock();
> ticks++;
> - jiffies++;
> + extern volatile unsigned long jiffies;
> + jiffies++; /* XXX drm(4) */
>
> /*
>* Update the timeout wheel.
> Index: conf/param.c
> ===
> RCS file: /cvs/src/sys/conf/param.c,v
> retrieving revision 1.47
> diff -u -p -r1.47 param.c
> --- conf/param.c 13 Apr 2022 10:08:10 - 1.47
> +++ conf/param.c 27 Feb 2023 22:55:24 -
> @@ -73,6 +73,8 @@
> #define HZ 100
> #endif
> int hz = HZ;
> +int ticks = INT_MAX - (15 * 60 * HZ);
> +volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ); /* drm(4) */
> int tick = 100 / HZ;
> int tick_nsec = 10 / HZ;
> int utc_offset = 0;
>
kernel: don't jump ticks, jiffies during boot
ticks and jiffies start at zero. During boot in initclocks(), we
reset them:
/* sys/kern/kern_clock.c */
89 int ticks;
90 static int psdiv, pscnt;/* prof => stat divider */
91 int psratio;/* ratio: prof / stat */
92
93 volatile unsigned long jiffies; /* XXX Linux API for drm(4) */
94
95 /*
96 * Initialize clock frequencies and start both clocks running.
97 */
98 void
99 initclocks(void)
100 {
101 ticks = INT_MAX - (15 * 60 * hz);
102 jiffies = ULONG_MAX - (10 * 60 * hz);
103
104 /* [... ] */
The idea here (committed by dlg@) is sound. We reset ticks and
jiffies to near-rollover values to catch buggy code misusing them.
But! That jump from zero to whatever violates valid assumptions made
by correct code, too.
It would be better to just initialize ticks and jiffies to the
near-rollover values when we declare them. To do this we need to
move their declarations from sys/kern/kern_clock.c to sys/conf/param.c
where HZ is visible.
ok?
Index: kern/kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.106
diff -u -p -r1.106 kern_clock.c
--- kern/kern_clock.c 4 Feb 2023 19:33:03 - 1.106
+++ kern/kern_clock.c 27 Feb 2023 22:55:24 -
@@ -86,21 +86,15 @@ int stathz;
intschedhz;
intprofhz;
intprofprocs;
-intticks;
static int psdiv, pscnt; /* prof => stat divider */
intpsratio;/* ratio: prof / stat */
-volatile unsigned long jiffies;/* XXX Linux API for drm(4) */
-
/*
* Initialize clock frequencies and start both clocks running.
*/
void
initclocks(void)
{
- ticks = INT_MAX - (15 * 60 * hz);
- jiffies = ULONG_MAX - (10 * 60 * hz);
-
/*
* Set divisors to 1 (normal case) and let the machine-specific
* code do its bit.
@@ -171,7 +165,8 @@ hardclock(struct clockframe *frame)
tc_ticktock();
ticks++;
- jiffies++;
+ extern volatile unsigned long jiffies;
+ jiffies++; /* XXX drm(4) */
/*
* Update the timeout wheel.
Index: conf/param.c
===
RCS file: /cvs/src/sys/conf/param.c,v
retrieving revision 1.47
diff -u -p -r1.47 param.c
--- conf/param.c13 Apr 2022 10:08:10 - 1.47
+++ conf/param.c27 Feb 2023 22:55:24 -
@@ -73,6 +73,8 @@
#defineHZ 100
#endif
inthz = HZ;
+intticks = INT_MAX - (15 * 60 * HZ);
+volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ); /* drm(4) */
inttick = 100 / HZ;
inttick_nsec = 10 / HZ;
intutc_offset = 0;
update: xf86-video-amdgpu 23.0.0
Hi,
the patch below update the amdgpu(4) X.Org driver to version 23.0.0
To test (on machines with an AMD / Radeon GPU)
# cd /usr/xenocara/driver/xf86-video-amdgpu
# patch -p0 -E < /path/to/this/file
# make -f Makefile.bsd-wrapper obj
# make -f Makefile.bsd-wrapper build
and restart xenodm(1)
Tests and oks welcome...
Index: ChangeLog
===
RCS file: /local/cvs/xenocara/driver/xf86-video-amdgpu/ChangeLog,v
retrieving revision 1.3
diff -u -p -u -r1.3 ChangeLog
--- ChangeLog 8 Mar 2022 03:56:50 - 1.3
+++ ChangeLog 27 Feb 2023 20:09:46 -
@@ -1,3 +1,170 @@
+commit 7025aefcdf9673665588cf291c5d71beb39cce89
+Author: Shashank Sharma
+Date: Wed Feb 22 18:00:23 2023 +0100
+
+Bump version for the 23.0.0 release
+
+This release includes some bug fixes.
+
+Signed-off-by: Shashank Sharma
+
+commit 6ee320917093ad0f7d68e516d3224d3c04ca13ee
+Author: Shashank Sharma
+Date: Mon Nov 28 13:08:36 2022 +0100
+
+config: Add hotplug driver name
+
+This patch adds the PCI-hotplug handler driver name in the
+DDX config file with respect to Xorg commit:82bf391c
+
+Cc: Alexander Deucher
+Signed-off-by: Shashank Sharma
+
+commit 2ec854d48e0e44fc60c3955663f700cbefea3553
+Author: Mario Kleiner
+Date: Fri Nov 11 02:18:07 2022 +0100
+
+Fix primary output handling in amdgpu_crtc_covering_box().
+
+Commit e39a3ee07c9dea73b0452b71b1ef633b6cd6f389
+tries to reintroduce the RandR primary output as a tie breaker
+in amdgpu_crtc_covering_box(), but that function wrongly
+assigns a void* devPrivate, which is actually a xf86CrtcPtr,
+to the RRCrtcPtr primary_crtc, a pointer target type mismatch!
+
+This causes a later pointer comparison of primary_crtc with
+RRCrtcPtr crtc to always fail, so that the user selected
+primary output can not ever successfully act as a tie-breaker
+when multiple candidate crtcs cover the same box area,
+defeating the whole purpose of that commit! Not sure how
+this failure could have ever evaded any basic testing.
+
+Fix this trivially by assigning the right variable.
+
+Successfully tested on a multi-display setup, verifying
+that the primary output now works as tie breaker as
+intended.
+
+Signed-off-by: Mario Kleiner
+Fixes: e39a3ee07c9d ("Prefer crtc of primary output for synchronization
when screen has to crtcs with the same coverage")
+
+commit 9c959fac3af28d191105f63236096ad456dca614
+Author: Pierre-Eric Pelloux-Prayer
+Date: Thu Sep 29 16:42:09 2022 +0200
+
+Use DRM_CAP_CURSOR_WIDTH/HEIGHT if possible
+
+There's no need to hardcode the cursor size if the kernel can
+report the value it wants.
+
+commit 4e011b91fa3ef58b85327d3429889efd934b3531
+Author: Alan Coopersmith
+Date: Tue Aug 2 15:03:19 2022 -0700
+
+gitlab CI: enable gitlab's builtin static analysis
+
+Signed-off-by: Alan Coopersmith
+
+commit dc81177ef342bf8c2aa5a6fd6687c7a09b4f9709
+Author: tiancyin
+Date: Wed Aug 10 16:46:15 2022 +0800
+
+Fix screen corruption on secondary GPU
+
+[why]
+On RHEL9+, xorg-server.pc shows that the Xorg no longer depends on dri,
+and dri.pc provides "/opt/amdgpu/include" path for pkg-config, this
+cause pkg-config no longer output "-I/opt/amdgpu/include", consequently
+the configure can't find gbm.h and HAVE_GBM_BO_USE_LINEAR is not
+declared, that cause the corruption.
+
+[how]
+Since the gbm.pc also provides the "/opt/amdgpu/include" path, in module
+dependence checking, GBM_CFLAGS get this path, so just explicitly add
+GBM_CFLAGS into CPPFLAGS can fix this issue.
+
+Signed-off-by: tiancyin
+
+commit a3a012b649eb9b3066abefe163a72854514792fa
+Author: Kai-Heng Feng
+Date: Mon Aug 8 10:49:11 2022 +0800
+
+Initialize present extension for GPU screen
+
+Some laptops have the external outputs routed to dGPU, when the external
+output over dGPU is the only display in reverse prime mode, we need
+present extension so fake CRTC won't be used.
+
+commit f3f57a58342c286808220bdbe6dc6bb7098763b9
+Author: Lukasz Spintzyk
+Date: Fri Jun 11 14:54:35 2021 +0200
+
+Do not consider disabled crtc anymore when looking for xf86crtc covering
drawable.
+
+This is commit is removing obsolete switch done in
+
+xf86-video-ati at sha 61d0aec40e2521488c2fe43e7a6823e5c87d94d7: video:
add option to include disabled CRTCs in best CRTC search
+This is not required anymore as with commit done in
+xorg-server at sha 5c5c1b77982a9af7279a90bc3c2be48adaa9c778: present:
Add Present extension
+That in case of lack of crtc is using fake_crtc with render 1Hz frequency
+
+When consider_disabled is removed then amdgpu_pick_best_crtc is doing the
same what rr_crtc_covering_box is doing
+so it can be reimplemented to reuse that function.
+
+
Re: running UDP input in parallel
On 22.8.2022. 15:07, Alexander Bluhm wrote:
> On Sun, Aug 21, 2022 at 07:07:29PM +0200, Alexander Bluhm wrote:
>> On Fri, Aug 19, 2022 at 10:54:42PM +0200, Alexander Bluhm wrote:
>>> This diff allows to run udp_input() in parallel.
>
> Diff rebased to -current.
Hi,
is this diff still active? I was running this diff in prod with
wireguard, remote syslog, dhcp server, ntp client for 2 months and all
seems good.
>
> Index: kern/uipc_socket.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/kern/uipc_socket.c,v
> retrieving revision 1.284
> diff -u -p -r1.284 uipc_socket.c
> --- kern/uipc_socket.c21 Aug 2022 16:22:17 - 1.284
> +++ kern/uipc_socket.c22 Aug 2022 12:01:58 -
> @@ -822,10 +822,10 @@ bad:
> if (mp)
> *mp = NULL;
>
> - solock(so);
> + solock_shared(so);
> restart:
> if ((error = sblock(so, >so_rcv, SBLOCKWAIT(flags))) != 0) {
> - sounlock(so);
> + sounlock_shared(so);
> return (error);
> }
>
> @@ -893,7 +893,7 @@ restart:
> sbunlock(so, >so_rcv);
> error = sbwait(so, >so_rcv);
> if (error) {
> - sounlock(so);
> + sounlock_shared(so);
> return (error);
> }
> goto restart;
> @@ -962,11 +962,11 @@ dontblock:
> sbsync(>so_rcv, nextrecord);
> if (controlp) {
> if (pr->pr_domain->dom_externalize) {
> - sounlock(so);
> + sounlock_shared(so);
> error =
> (*pr->pr_domain->dom_externalize)
> (cm, controllen, flags);
> - solock(so);
> + solock_shared(so);
> }
> *controlp = cm;
> } else {
> @@ -1040,9 +1040,9 @@ dontblock:
> SBLASTRECORDCHK(>so_rcv, "soreceive uiomove");
> SBLASTMBUFCHK(>so_rcv, "soreceive uiomove");
> resid = uio->uio_resid;
> - sounlock(so);
> + sounlock_shared(so);
> uio_error = uiomove(mtod(m, caddr_t) + moff, len, uio);
> - solock(so);
> + solock_shared(so);
> if (uio_error)
> uio->uio_resid = resid - len;
> } else
> @@ -1126,7 +1126,7 @@ dontblock:
> error = sbwait(so, >so_rcv);
> if (error) {
> sbunlock(so, >so_rcv);
> - sounlock(so);
> + sounlock_shared(so);
> return (0);
> }
> if ((m = so->so_rcv.sb_mb) != NULL)
> @@ -1171,7 +1171,7 @@ dontblock:
> *flagsp |= flags;
> release:
> sbunlock(so, >so_rcv);
> - sounlock(so);
> + sounlock_shared(so);
> return (error);
> }
>
> Index: kern/uipc_socket2.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/kern/uipc_socket2.c,v
> retrieving revision 1.127
> diff -u -p -r1.127 uipc_socket2.c
> --- kern/uipc_socket2.c 13 Aug 2022 21:01:46 - 1.127
> +++ kern/uipc_socket2.c 22 Aug 2022 12:01:58 -
> @@ -360,6 +360,24 @@ solock(struct socket *so)
> }
> }
>
> +void
> +solock_shared(struct socket *so)
> +{
> + switch (so->so_proto->pr_domain->dom_family) {
> + case PF_INET:
> + case PF_INET6:
> + if (so->so_proto->pr_usrreqs->pru_lock != NULL) {
> + NET_LOCK_SHARED();
> + pru_lock(so);
> + } else
> + NET_LOCK();
> + break;
> + default:
> + rw_enter_write(>so_lock);
> + break;
> + }
> +}
> +
> int
> solock_persocket(struct socket *so)
> {
> @@ -403,6 +421,24 @@ sounlock(struct socket *so)
> }
>
> void
> +sounlock_shared(struct socket *so)
> +{
> + switch (so->so_proto->pr_domain->dom_family) {
> + case PF_INET:
> + case PF_INET6:
> + if (so->so_proto->pr_usrreqs->pru_unlock != NULL) {
> + pru_unlock(so);
> + NET_UNLOCK_SHARED();
> + } else
> + NET_UNLOCK();
> + break;
> + default:
> + rw_exit_write(>so_lock);
> + break;
> + }
> +}
> +
> +void
> soassertlocked(struct socket *so)
> {
> switch (so->so_proto->pr_domain->dom_family) {
> @@ -425,7 +461,15 @@ sosleep_nsec(struct
Fix sndiod(8) dropping randomly connections
Sometimes sndiod closes the device sponteneously and, unless -F is
used, programs need to be restarted. If -F is used, sndiod will switch
to another device (ex. from usb headphones to internal speakers),
which might be a privacy problem.
The cause is that libsndio uses the kernel underrun counters to
compensate for the silence the audio(4) driver inserts when userland
provides no samples to play. This hack is to keeps underruns short in
order to be less unnoticeable. Kernel counters must be accurate,
otherwise the code trying to compensate for the underruns may create a
deadlock making sndiod enter an infinite loop. sndiod detects such
loops and closes the device.
Unfortunately the kernel counters are not reliable, their logic is
fragile, device-dependent and after 10+ years of attemps to use them
we still get the deadlocks. The diff below makes libsndio simply
restart the device if the program underruns. For restarting to be
invisible to the program, libsndio saves and restores the program
state. Doing so, requires to play additional silence after the
underrun, which makes it *more noticeable*.
Please test and report regressions like sndiod crashes, unexpected
connection drops, etc.
OK?
Index: sio_sun.c
===
RCS file: /cvs/src/lib/libsndio/sio_sun.c,v
retrieving revision 1.30
diff -u -p -r1.30 sio_sun.c
--- sio_sun.c 27 Dec 2022 17:10:07 - 1.30
+++ sio_sun.c 27 Feb 2023 15:07:00 -
@@ -42,8 +42,7 @@ struct sio_sun_hdl {
int filling;
unsigned int ibpf, obpf;/* bytes per frame */
unsigned int ibytes, obytes;/* bytes the hw transferred */
- unsigned int ierr, oerr;/* frames the hw dropped */
- int idelta, odelta; /* position reported to client */
+ int idelta, odelta; /* position not reported yet */
};
static void sio_sun_close(struct sio_hdl *);
@@ -370,8 +369,6 @@ sio_sun_start(struct sio_hdl *sh)
hdl->ibpf = hdl->sio.par.rchan * hdl->sio.par.bps;
hdl->ibytes = 0;
hdl->obytes = 0;
- hdl->ierr = 0;
- hdl->oerr = 0;
hdl->idelta = 0;
hdl->odelta = 0;
@@ -516,6 +513,62 @@ sio_sun_write(struct sio_hdl *sh, const
}
static int
+sio_sun_xrun(struct sio_sun_hdl *hdl)
+{
+ int clk;
+ int wsil, rdrop, cmove;
+ int rbpf, rround;
+ int wbpf;
+
+ DPRINTFN(2, "%s: 1: sil = %d, rdrop = %d, odelta = %d, idelta = %d\n",
+ __func__, hdl->sio.wsil, hdl->sio.rdrop, hdl->odelta, hdl->idelta);
+#ifdef DEBUG
+ if (_sndio_debug >= 2)
+ _sio_printpos(>sio);
+#endif
+
+ /*
+* we assume rused/wused are zero if rec/play modes are not
+* selected. This allows us to keep the same formula for all
+* modes, provided we set rbpf/wbpf to 1 to avoid division by
+* zero.
+*
+* to understand the formula, draw a picture :)
+*/
+ rbpf = (hdl->sio.mode & SIO_REC) ? hdl->ibpf : 1;
+ wbpf = (hdl->sio.mode & SIO_PLAY) ? hdl->obpf : 1;
+ rround = hdl->sio.par.round * rbpf;
+
+ clk = hdl->sio.cpos % hdl->sio.par.round;
+ rdrop = (clk * rbpf - hdl->sio.rused) % rround;
+ if (rdrop < 0)
+ rdrop += rround;
+ cmove = (rdrop + hdl->sio.rused) / rbpf;
+ wsil = cmove * wbpf + hdl->sio.wused;
+
+ DPRINTFN(2, "%s: wsil = %d, cmove = %d, rdrop = %d\n",
+ __func__, wsil, cmove, rdrop);
+
+ if (!sio_sun_flush(>sio))
+ return 0;
+ if (!sio_sun_start(>sio))
+ return 0;
+ if (hdl->sio.mode & SIO_PLAY) {
+ hdl->odelta -= cmove;
+ hdl->sio.wsil = wsil;
+ }
+ if (hdl->sio.mode & SIO_REC) {
+ hdl->idelta -= cmove;
+ hdl->sio.rdrop = rdrop;
+ }
+
+ DPRINTFN(2, "%s: 2: wsil = %d, rdrop = %d, odelta = %d, idelta = %d\n",
+ __func__, hdl->sio.wsil, hdl->sio.rdrop, hdl->odelta, hdl->idelta);
+
+ return 1;
+}
+
+static int
sio_sun_nfds(struct sio_hdl *hdl)
{
return 1;
@@ -536,6 +589,7 @@ sio_sun_pollfd(struct sio_hdl *sh, struc
hdl->sio.eof = 1;
return 0;
}
+ DPRINTFN(2, "sio_sun_pollfd: started\n");
_sio_onmove_cb(>sio, 0);
}
return 1;
@@ -546,67 +600,56 @@ sio_sun_revents(struct sio_hdl *sh, stru
{
struct sio_sun_hdl *hdl = (struct sio_sun_hdl *)sh;
struct audio_pos ap;
- int dierr = 0, doerr = 0, offset, delta;
+ int delta;
int revents = pfd->revents;
if ((pfd->revents & POLLHUP) ||
(pfd->revents & (POLLIN | POLLOUT)) == 0)
return pfd->revents;
+
if (ioctl(hdl->fd, AUDIO_GETPOS, ) == -1) {
DPERROR("sio_sun_revents: GETPOS");
hdl->sio.eof = 1;
return POLLHUP;
Re: freeradius denies to authentocate with eap-tls
(moving to ports#, reply-to is set, although this is unlikely to be OpenBSD-specific) On 2023/02/25 02:18, Mikhael Lialin wrote: > Trying to setup witi with radius eap-tls authentication. > > And getting time out while authenticated. > > Tried with custome setup, and default setup with generated > certificates within installation. > > in ktrace of rediusd something waiting: > > 28664 radiusd RET wait4 -1 errno 10 No child processes > > all configuration of freeradius are default after > installation, nothing were modified. > > Please help. > > Debug ant ktrace session attached. ktrace is too low-level to be useful here. freeradius won't work directly with default setup, you at least need to configure shared secrets between the APs and freeradius (in clients.conf and on the AP), and tell freeradius how to decide whether a user is allowed to authenticate. You say EAP-TLS, this uses certificates for authentication on bith the server *and* the client, so for that you'll also need to figure out how to get client certificates signed, etc. I strongly recommend ignoring this until you have the basics working with password based auth. Follow https://wiki.freeradius.org/guide/Basic-configuration-HOWTO first and make sure it works with radtest on the local machine. (Note if running it manually in debug mode as suggested in that guide, you will need the full path /usr/local/sbin/radiusd, there is a minimal radius daemon from the base OS in /usr/sbin/radiusd which does not support EAP/PEAP). If that fails, it needs fixing first before moving onto one of the EAP methods that you need for WPA-Enterprise (either on an AP directly or you can try eapol_test running on the freeradius server as shown in http://deployingradius.com/scripts/eapol_test/ - skip the "building eapol_test" section and pkg_add wpa_supplicant instead).
nd6_resolve: sync some bits with arpresolve
Three things to make comparison easier:
- hoist duplicate addr[] declaration
- defer failure into `bad' label
These seem sensible on their own.
- set/use getuptime() identically
This is purely for sync; nd6_resolve() uses getuptime() just once,
while arpresolve() has multiple `uptime' usages.
OK?
Index: nd6.c
===
RCS file: /cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.265
diff -u -p -r1.265 nd6.c
--- nd6.c 24 Jan 2023 20:06:16 - 1.265
+++ nd6.c 27 Feb 2023 08:19:57 -
@@ -1247,16 +1247,19 @@ nd6_resolve(struct ifnet *ifp, struct rt
struct sockaddr_dl *sdl;
struct rtentry *rt;
struct llinfo_nd6 *ln = NULL;
+ char addr[INET6_ADDRSTRLEN];
+ time_t uptime;
if (m->m_flags & M_MCAST) {
ETHER_MAP_IPV6_MULTICAST((dst)->sin6_addr, desten);
return (0);
}
+ uptime = getuptime();
rt = rt_getll(rt0);
if (ISSET(rt->rt_flags, RTF_REJECT) &&
- (rt->rt_expire == 0 || getuptime() < rt->rt_expire)) {
+ (rt->rt_expire == 0 || rt->rt_expire > uptime)) {
m_freem(m);
return (rt == rt0 ? EHOSTDOWN : EHOSTUNREACH);
}
@@ -1268,18 +1271,15 @@ nd6_resolve(struct ifnet *ifp, struct rt
* or an anycast address(i.e. not a multicast).
*/
if (!ISSET(rt->rt_flags, RTF_LLINFO)) {
- char addr[INET6_ADDRSTRLEN];
log(LOG_DEBUG, "%s: %s: route contains no ND information\n",
__func__, inet_ntop(AF_INET6,
(rt_key(rt))->sin6_addr, addr, sizeof(addr)));
- m_freem(m);
- return (EINVAL);
+ goto bad;
}
if (rt->rt_gateway->sa_family != AF_LINK) {
printf("%s: something odd happens\n", __func__);
- m_freem(m);
- return (EINVAL);
+ goto bad;
}
ln = (struct llinfo_nd6 *)rt->rt_llinfo;
@@ -1314,13 +1314,11 @@ nd6_resolve(struct ifnet *ifp, struct rt
if (ln->ln_state > ND6_LLINFO_INCOMPLETE) {
sdl = satosdl(rt->rt_gateway);
if (sdl->sdl_alen != ETHER_ADDR_LEN) {
- char addr[INET6_ADDRSTRLEN];
log(LOG_DEBUG, "%s: %s: incorrect nd6 information\n",
__func__,
inet_ntop(AF_INET6, (dst)->sin6_addr,
addr, sizeof(addr)));
- m_freem(m);
- return (EINVAL);
+ goto bad;
}
bcopy(LLADDR(sdl), desten, sdl->sdl_alen);
@@ -1347,6 +1345,10 @@ nd6_resolve(struct ifnet *ifp, struct rt
nd6_ns_output(ifp, NULL, (dst)->sin6_addr, ln, 0);
}
return (EAGAIN);
+
+bad:
+ m_freem(m);
+ return (EINVAL);
}
int
