Re: sdmmc(4): sdmmc_io_function_enable(): don't sleep on lbolt

> On Dec 16, 2020, at 18:40, Martin Pieuchot wrote: > > On 16/12/20(Wed) 23:23, Claudio Jeker wrote: >>> On Wed, Dec 16, 2020 at 04:50:42PM -0300, Martin Pieuchot wrote: >>> [...] >>> Why did we choose to use a variable over NULL? Any technical reason? >> >> The sleep subsytem requires a non-

WITNESS panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) kmmaplk

I just hit this while booting an i386-current in vmd. The source tree is synced to "Remove the assertion in uvm_km_pgremove()." I enabled WITNESS on top of GENERIC. Naturally, GENERIC-Dec15 snap works. Anybody else see this so I know it's worth a bisect? OpenBSD 6.8-current (WITNESS) #0: Tue Dec

Re: sdmmc(4): sdmmc_io_function_enable(): don't sleep on lbolt

On 16/12/20(Wed) 23:23, Claudio Jeker wrote: > On Wed, Dec 16, 2020 at 04:50:42PM -0300, Martin Pieuchot wrote: > > [...] > > Why did we choose to use a variable over NULL? Any technical reason? > > The sleep subsytem requires a non-NULL value for ident. Changing this > seems not trivial. I'd s

Re: tht(4): more tsleep(9) -> tsleep_nsec(9) conversions

ok > On 17 Dec 2020, at 04:22, Scott Cheloha wrote: > > On Thu, Dec 03, 2020 at 09:59:11PM -0600, Scott Cheloha wrote: >> Hi, >> >> tht(4) is another driver still using tsleep(9). >> >> It uses it to spin while it waits for the card to load the firmware. >> Then it uses it to spin for up to 2

Re: nosuid more partitions that no longer have suid executables

On Wed, Dec 16, 2020 at 03:40:41PM -0700, Theo de Raadt wrote: > the term "suid" includes setgid executables... so your conclusions > are way wrong. > > Heck, you should give it a try. Good luck logging in afterwards. Indeed, please disregard.

Re: bgpd send side hold timer

On Tue, Dec 15, 2020 at 05:02:19PM +0100, Claudio Jeker wrote: > On Mon, Dec 14, 2020 at 06:22:09PM +, Job Snijders wrote: > > This patch appears to be a very elegant solution to a thorny subtle > > problem: what to do when a peer is not accepting new routing > > information from you? > > One

Re: nosuid more partitions that no longer have suid executables

the term "suid" includes setgid executables... so your conclusions are way wrong. Heck, you should give it a try. Good luck logging in afterwards. Josh Rickmar wrote: > Playing around with find ${dir} -type f -perm -04000, I see that there > are no longer any more suid executables placed in /u

Re: sdmmc(4): sdmmc_io_function_enable(): don't sleep on lbolt

On Wed, Dec 16, 2020 at 04:50:42PM -0300, Martin Pieuchot wrote: > On 16/12/20(Wed) 12:50, Scott Cheloha wrote: > > On Tue, Dec 15, 2020 at 01:47:24PM +0100, Mark Kettenis wrote: > > > > Date: Tue, 15 Dec 2020 13:32:22 +0100 > > > > From: Claudio Jeker > > > > > > > > On Fri, Dec 11, 2020 at 07:0

nosuid more partitions that no longer have suid executables

Playing around with find ${dir} -type f -perm -04000, I see that there are no longer any more suid executables placed in /usr/libexec or /usr/X11R6, so I believe these can be removed from install.sub. Based on the comments, this hasn't been touched in a long while. diff bfe4739adb21458b6ca3fc690d

Re: sdmmc(4): sdmmc_io_function_enable(): don't sleep on lbolt

> Date: Wed, 16 Dec 2020 12:50:46 -0600 > From: Scott Cheloha > > On Tue, Dec 15, 2020 at 01:47:24PM +0100, Mark Kettenis wrote: > > > Date: Tue, 15 Dec 2020 13:32:22 +0100 > > > From: Claudio Jeker > > > > > > On Fri, Dec 11, 2020 at 07:07:56PM -0600, Scott Cheloha wrote: > > > > Hi, > > > >

Re: sdmmc(4): sdmmc_io_function_enable(): don't sleep on lbolt

On 16/12/20(Wed) 12:50, Scott Cheloha wrote: > On Tue, Dec 15, 2020 at 01:47:24PM +0100, Mark Kettenis wrote: > > > Date: Tue, 15 Dec 2020 13:32:22 +0100 > > > From: Claudio Jeker > > > > > > On Fri, Dec 11, 2020 at 07:07:56PM -0600, Scott Cheloha wrote: > > > > Hi, > > > > > > > > I'd like to r

Re: sdmmc(4): sdmmc_io_function_enable(): don't sleep on lbolt

On Tue, Dec 15, 2020 at 01:47:24PM +0100, Mark Kettenis wrote: > > Date: Tue, 15 Dec 2020 13:32:22 +0100 > > From: Claudio Jeker > > > > On Fri, Dec 11, 2020 at 07:07:56PM -0600, Scott Cheloha wrote: > > > Hi, > > > > > > I'd like to remove lbolt from the kernel. I think having it in the > > >

Re: tht(4): more tsleep(9) -> tsleep_nsec(9) conversions

On Thu, Dec 03, 2020 at 09:59:11PM -0600, Scott Cheloha wrote: > Hi, > > tht(4) is another driver still using tsleep(9). > > It uses it to spin while it waits for the card to load the firmware. > Then it uses it to spin for up to 2 seconds while waiting for > THT_REG_INIT_STATUS. > > In the firm

Re: Switch select(2) to kqueue-based implementation

On Tue, Dec 15, 2020 at 05:23:45PM +, Visa Hankala wrote: > On Tue, Dec 15, 2020 at 07:46:01AM -0300, Martin Pieuchot wrote: > > @@ -636,43 +651,59 @@ dopselect(struct proc *p, int nd, fd_set > > if (sigmask) > > dosigsuspend(p, *sigmask &~ sigcantmask); > > > > -retry: > > -

Re: regress print target name

On Wed, Dec 16, 2020 at 05:01:18PM +0100, Theo Buehler wrote: > On Wed, Dec 16, 2020 at 04:42:59PM +0100, Alexander Bluhm wrote: > > When debugging tests, it is useful to see the target name and which > > output belongs to it. A lot of my tests have echo lines, but I > > think this is better done

Re: netstat - proto ip record

On Wed, Dec 16, 2020 at 03:54:04PM +, Stuart Henderson wrote: > On 2020/12/16 16:43, Salvatore Cuzzilla wrote: > > Hi folks, > > > > is there any process associated with this netstat record? > > btw, what's the meaning of the state field with value '17'? > > > > ToTo@obsd ~ $ doas netstat -an

Re: regress print target name

On Wed, Dec 16, 2020 at 04:42:59PM +0100, Alexander Bluhm wrote: > When debugging tests, it is useful to see the target name and which > output belongs to it. A lot of my tests have echo lines, but I > think this is better done in the framework. Then all tests behave > simmilar. I would remove t

Re: kern.video.record - part 2

On Wed, Dec 16, 2020 at 03:50:54PM +0100, Marcus Glocker wrote: Hello Marcus, > I reviewed this again, and I think this implementation should be consistent > on a video(4) level now. I've just tried this, and it works, and works better than my original (and uvideo-only) patch. I've been flipping

Re: netstat - proto ip record

On 2020/12/16 16:43, Salvatore Cuzzilla wrote: > Hi folks, > > is there any process associated with this netstat record? > btw, what's the meaning of the state field with value '17'? > > ToTo@obsd ~ $ doas netstat -an -f inet > Active Internet connections (including servers) > Proto Recv-Q Send

netstat - proto ip record

Hi folks, is there any process associated with this netstat record? btw, what's the meaning of the state field with value '17'? ToTo@obsd ~ $ doas netstat -an -f inet Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address(state) ip

regress print target name

Hi, When debugging tests, it is useful to see the target name and which output belongs to it. A lot of my tests have echo lines, but I think this is better done in the framework. Then all tests behave simmilar. I would remove the echos from the Makefiles afterwards. ok? bluhm Index: share/mk

kern.video.record - part 2

Hi, In September Laurence Tratt came up with a diff to implement an kern.video.record switch for sysctl(8). The implementation was only for uvideo(4), and hence we wanted to lift that up to the video(4) level, but we were not able to get a good implementation together back then. I reviewed this

Re: acme-client(1) make -F flag use more obvious

On 12/16/20 11:13 AM, Janne Johansson wrote: Den ons 16 dec. 2020 kl 10:42 skrev Renaud Allard >: > While there, I propose to change the proposed crontab to once a day > instead of every hour. The certificates can be renewed 1 full month > before expirac

Re: acme-client(1) make -F flag use more obvious

On 12/16/20 9:44 AM, Solene Rapenne wrote: On Tue, 15 Dec 2020 10:18:41 +0100 Solene Rapenne : This is a small change to acme-client(1) because I find the explanation of -F flag not being obvious that you need it when you add/remove an alternative name in your domain config. Maybe wording co

amd64 pamp panic messages

Hi, during all my pmap crashes, I sometimes get this strange address. panic: pmap_remove_pte: unmanaged page marked PG_PVLIST, va = 0x5d155753000, pa = 0xfdfdfdfdfd000 I think we should not clear bits in a panic messages. Debugging with the full picture is easier. While there make the panics

Re: acme-client(1) make -F flag use more obvious

On Tue, 15 Dec 2020 10:18:41 +0100 Solene Rapenne : > This is a small change to acme-client(1) because I find > the explanation of -F flag not being obvious that you > need it when you add/remove an alternative name in your > domain config. > > Maybe wording could be better, if a native English >

Re: Switch select(2) to kqueue-based implementation

On 15/12/20(Tue) 17:23, Visa Hankala wrote: > On Tue, Dec 15, 2020 at 07:46:01AM -0300, Martin Pieuchot wrote: > > @@ -636,43 +651,59 @@ dopselect(struct proc *p, int nd, fd_set > > if (sigmask) > > dosigsuspend(p, *sigmask &~ sigcantmask); > > > > -retry: > > - ncoll = nselcoll

Re: acme-client(1) make -F flag use more obvious

On 2020/12/16 11:47, Renaud Allard wrote: > On 12/16/20 11:13 AM, Janne Johansson wrote: > > > > But it is a local check for the local date vs the date in the > > certificate, and perhaps your box is not on at 03:00 on Saturdays as you > > thought 3 months ago. > > > > If your clock is 3 months

Re: acme-client(1) make -F flag use more obvious

Den ons 16 dec. 2020 kl 10:42 skrev Renaud Allard : > > While there, I propose to change the proposed crontab to once a day > > instead of every hour. The certificates can be renewed 1 full month > > before expiracy, I think trying to renew every hour is too much. > > I think that, while waiting f