Turn simple sysctl_rdint into cpuctl_vars entries
Tested with the usual diff of sysctl machdep.
OK?
>From 0d628f5c7eb69f7964beca7945f634d26af34834 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Wed, 18 Nov 2020 20:33:37 -0800
Subject: [PATCH] Turn simple sysctl_rdint into cpuctl_vars entries
---
sys/arch/amd64/amd64/machdep.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git sys/arch/amd64/amd64/machdep.c sys/arch/amd64/amd64/machdep.c
index e12700c1576..b6a050f4da7 100644
--- sys/arch/amd64/amd64/machdep.c
+++ sys/arch/amd64/amd64/machdep.c
@@ -469,9 +469,16 @@ bios_sysctl(int *name, u_int namelen, void *oldp, size_t
*oldlenp, void *newp,
/* NOTREACHED */
}
+extern int tsc_is_invariant;
+extern int amd64_has_xcrypt;
+
const struct sysctl_bounded_args cpuctl_vars[] = {
{ CPU_LIDACTION, _action, 0, 2 },
{ CPU_PWRACTION, _action, 0, 2 },
+ { CPU_CPUID, _id, 1, 0 },
+ { CPU_CPUFEATURE, _feature, 1, 0 },
+ { CPU_XCRYPT, _has_xcrypt, 1, 0 },
+ { CPU_INVARIANTTSC, _is_invariant, 1, 0 },
};
/*
@@ -482,8 +489,6 @@ cpu_sysctl(int *name, u_int namelen, void *oldp, size_t
*oldlenp, void *newp,
size_t newlen, struct proc *p)
{
extern uint64_t tsc_frequency;
- extern int tsc_is_invariant;
- extern int amd64_has_xcrypt;
dev_t consdev;
dev_t dev;
@@ -507,10 +512,6 @@ cpu_sysctl(int *name, u_int namelen, void *oldp, size_t
*oldlenp, void *newp,
newp, newlen, p);
case CPU_CPUVENDOR:
return (sysctl_rdstring(oldp, oldlenp, newp, cpu_vendor));
- case CPU_CPUID:
- return (sysctl_rdint(oldp, oldlenp, newp, cpu_id));
- case CPU_CPUFEATURE:
- return (sysctl_rdint(oldp, oldlenp, newp, cpu_feature));
case CPU_KBDRESET:
if (securelevel > 0)
return (sysctl_rdint(oldp, oldlenp, newp,
@@ -531,8 +532,6 @@ cpu_sysctl(int *name, u_int namelen, void *oldp, size_t
*oldlenp, void *newp,
#else
return (sysctl_rdint(oldp, oldlenp, newp, 0));
#endif
- case CPU_XCRYPT:
- return (sysctl_rdint(oldp, oldlenp, newp, amd64_has_xcrypt));
#if NPCKBC > 0 && NUKBD > 0
case CPU_FORCEUKBD:
{
@@ -549,8 +548,6 @@ cpu_sysctl(int *name, u_int namelen, void *oldp, size_t
*oldlenp, void *newp,
#endif
case CPU_TSCFREQ:
return (sysctl_rdquad(oldp, oldlenp, newp, tsc_frequency));
- case CPU_INVARIANTTSC:
- return (sysctl_rdint(oldp, oldlenp, newp, tsc_is_invariant));
default:
return (sysctl_bounded_arr(cpuctl_vars, nitems(cpuctl_vars),
name, namelen, oldp, oldlenp, newp, newlen));
--
2.29.2
Re: smtpd: relax ORCPT check again
November 18, 2020 10:17 PM, "Joerg Jung" wrote:
> On Wed, Nov 18, 2020 at 08:57:48PM +, gil...@poolp.org wrote:
>
>> November 18, 2020 9:54 PM, "Joerg Jung" wrote:
>>
>> Hi,
>>
>> in my opinion revision 1.423 of smtp_session.c went a bit too far.
>> Enforcing that ORCPT has to have domain results in breakage in real
>> world usage. For example, sending from root user cron jobs mails
>> via Postfix aliased to an address handled by OpenSMTPD will fail.
>>
>> RFC leaves some room for interpretation here, but interoperability
>> may be considered important as well. GitHub issue #1084 [1] has
>> some more elaborations and examples, but was opened for the same
>> reason.
>>
>> Therefore, I propose the following diff below to slightly relax
>> the ORCPT check again by skipping the domain part check.
>>
>> Comments, OK?
>>
>> maybe just skip the check ONLY if domain part is empty ?
>
> Like in the diff below and assuming that domain part is always
> nul terminated after text_to_mailaddr()?
>
This reads better IMO yes
> OK?
>
> Index: smtp_session.c
> ===
> RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
> retrieving revision 1.426
> diff -u -p -r1.426 smtp_session.c
> --- smtp_session.c 24 Apr 2020 11:34:07 - 1.426
> +++ smtp_session.c 18 Nov 2020 21:10:36 -
> @@ -2583,7 +2583,8 @@ smtp_tx_rcpt_to(struct smtp_tx *tx, cons
>
> if (!text_to_mailaddr(>evp.dsn_orcpt, opt) ||
> !valid_localpart(tx->evp.dsn_orcpt.user) ||
> - !valid_domainpart(tx->evp.dsn_orcpt.domain)) {
> + (strlen(tx->evp.dsn_orcpt.domain) != 0 &&
> + !valid_domainpart(tx->evp.dsn_orcpt.domain))) {
> smtp_reply(tx->session,
> "553 ORCPT address syntax error");
> return;
Re: Fewer uvmexp
On Wed, Nov 18 2020, Martin Pieuchot wrote:
> While auditing the various uses of the uvmexp fields I came across
> those under #ifdet notyet. May I delete them so I don't have to give
> them some MP love? Ok?
ok jca@, but while here shouldn't the rest of cpu_vm_init() go too?
Unless I'm missing something it doesn't have side effects except
computing ncolors, and ncolors is meant to be used by the code you're
removing.
> Index: arch/amd64//amd64/cpu.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
> retrieving revision 1.150
> diff -u -p -r1.150 cpu.c
> --- arch/amd64//amd64/cpu.c 13 Sep 2020 11:53:16 - 1.150
> +++ arch/amd64//amd64/cpu.c 18 Nov 2020 13:11:17 -
> @@ -443,17 +443,6 @@ cpu_vm_init(struct cpu_info *ci)
> }
> ncolors = max(ncolors, tcolors);
> }
> -
> -#ifdef notyet
> - /*
> - * Knowing the size of the largest cache on this CPU, re-color
> - * our pages.
> - */
> - if (ncolors <= uvmexp.ncolors)
> - return;
> - printf("%s: %d page colors\n", ci->ci_dev->dv_xname, ncolors);
> - uvm_page_recolor(ncolors);
> -#endif
> }
>
>
> Index: arch/luna88k/luna88k/isr.c
> ===
> RCS file: /cvs/src/sys/arch/luna88k/luna88k/isr.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 isr.c
> --- arch/luna88k/luna88k/isr.c28 Jun 2017 10:31:48 - 1.11
> +++ arch/luna88k/luna88k/isr.c18 Nov 2020 13:11:27 -
> @@ -151,10 +151,6 @@ isrdispatch_autovec(int ipl)
> panic("isrdispatch_autovec: bad ipl %d", ipl);
> #endif
>
> -#if 0/* XXX: already counted in machdep.c */
> - uvmexp.intrs++;
> -#endif
> -
> list = _autovec[ipl];
> if (LIST_EMPTY(list)) {
> printf("isrdispatch_autovec: ipl %d unexpected\n", ipl);
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Dell XPS 9310 succesful install but bootloader can't read disk label
Hi, I've got a brand new Dell XPS 9310 and I've tried to get 6.7, 6.8 and the latest snapshot on it. Installation works fine but neither the 3.50, 3.54 or 3.55 UEFI bootloaders can read the disk label so it's unbootable. I of course disactivated Secure Boot and anything in the BIOS that looked like it might be an obstacle. I've got two pictures of the bsd.rd dmesg for the latest snapshot for you here: http://casper.nineinchnetworks.ch/images/dmesg1.jpg http://casper.nineinchnetworks.ch/images/dmesg2.jpg I have no idea what to do next, hope this is of use to you. Cheers, Noth P.S.: I'm not subscribed to this mailing list, please CC me when answering.
Locking of uvm_pageclean()
I found another race related to some missing locking, this time around
uvm_pageclean().
Diff below fixes the two places in /sys/uvm where the page queue lock
should be taken. To prevent further corruption I added some assertions
and documented some global data structures that are currently protected
by this lock.
Note that uvm_pagefree() is called by many pmaps most of the time
without the lock held. The diff below doesn't fix them and that's why
some assertions are commented out.
ok?
Index: uvm/uvm.h
===
RCS file: /cvs/src/sys/uvm/uvm.h,v
retrieving revision 1.67
diff -u -p -r1.67 uvm.h
--- uvm/uvm.h 6 Dec 2019 08:33:25 - 1.67
+++ uvm/uvm.h 18 Nov 2020 23:22:15 -
@@ -44,18 +44,20 @@
/*
* uvm structure (vm global state: collected in one structure for ease
* of reference...)
+ *
+ * Locks used to protect struct members in this file:
+ * Q uvm.pageqlock
*/
-
struct uvm {
/* vm_page related parameters */
/* vm_page queues */
- struct pglist page_active; /* allocated pages, in use */
- struct pglist page_inactive_swp;/* pages inactive (reclaim or free) */
- struct pglist page_inactive_obj;/* pages inactive (reclaim or free) */
+ struct pglist page_active; /* [Q] allocated pages, in use */
+ struct pglist page_inactive_swp;/* [Q] pages inactive (reclaim/free) */
+ struct pglist page_inactive_obj;/* [Q] pages inactive (reclaim/free) */
/* Lock order: pageqlock, then fpageqlock. */
- struct mutex pageqlock; /* lock for active/inactive page q */
- struct mutex fpageqlock;/* lock for free page q + pdaemon */
+ struct mutex pageqlock; /* [] lock for active/inactive page q */
+ struct mutex fpageqlock;/* [] lock for free page q + pdaemon */
boolean_t page_init_done; /* TRUE if uvm_page_init() finished */
struct uvm_pmr_control pmr_control; /* pmemrange data */
Index: uvm/uvm_anon.c
===
RCS file: /cvs/src/sys/uvm/uvm_anon.c,v
retrieving revision 1.49
diff -u -p -r1.49 uvm_anon.c
--- uvm/uvm_anon.c 4 Jan 2020 16:17:29 - 1.49
+++ uvm/uvm_anon.c 18 Nov 2020 23:22:15 -
@@ -106,7 +106,9 @@ uvm_anfree_list(struct vm_anon *anon, st
* clean page, and put on on pglist
* for later freeing.
*/
+ uvm_lock_pageq();
uvm_pageclean(pg);
+ uvm_unlock_pageq();
TAILQ_INSERT_HEAD(pgl, pg, pageq);
} else {
uvm_lock_pageq(); /* lock out pagedaemon */
Index: uvm/uvm_object.c
===
RCS file: /cvs/src/sys/uvm/uvm_object.c,v
retrieving revision 1.17
diff -u -p -r1.17 uvm_object.c
--- uvm/uvm_object.c21 Oct 2020 09:08:14 - 1.17
+++ uvm/uvm_object.c18 Nov 2020 23:22:15 -
@@ -172,7 +172,9 @@ uvm_objfree(struct uvm_object *uobj)
* this pg from the uobj we are throwing away
*/
atomic_clearbits_int(>pg_flags, PG_TABLED);
+ uvm_lock_pageq();
uvm_pageclean(pg);
+ uvm_unlock_pageq();
TAILQ_INSERT_TAIL(, pg, pageq);
}
uvm_pmr_freepageq();
Index: uvm/uvm_page.c
===
RCS file: /cvs/src/sys/uvm/uvm_page.c,v
retrieving revision 1.150
diff -u -p -r1.150 uvm_page.c
--- uvm/uvm_page.c 22 Sep 2020 14:31:08 - 1.150
+++ uvm/uvm_page.c 18 Nov 2020 23:22:15 -
@@ -973,6 +973,10 @@ uvm_pageclean(struct vm_page *pg)
{
u_int flags_to_clear = 0;
+#if all_pmap_are_fixed
+ MUTEX_ASSERT_LOCKED();
+#endif
+
#ifdef DEBUG
if (pg->uobject == (void *)0xdeadbeef &&
pg->uanon == (void *)0xdeadbeef) {
@@ -1037,6 +1041,10 @@ uvm_pageclean(struct vm_page *pg)
void
uvm_pagefree(struct vm_page *pg)
{
+#if all_pmap_are_fixed
+ MUTEX_ASSERT_LOCKED();
+#endif
+
uvm_pageclean(pg);
uvm_pmr_freepages(pg, 1);
}
@@ -1229,6 +1237,8 @@ uvm_pagelookup(struct uvm_object *obj, v
void
uvm_pagewire(struct vm_page *pg)
{
+ MUTEX_ASSERT_LOCKED();
+
if (pg->wire_count == 0) {
if (pg->pg_flags & PQ_ACTIVE) {
TAILQ_REMOVE(_active, pg, pageq);
@@ -1257,6 +1267,8 @@ uvm_pagewire(struct vm_page *pg)
void
uvm_pageunwire(struct vm_page *pg)
{
+ MUTEX_ASSERT_LOCKED();
+
pg->wire_count--;
if (pg->wire_count == 0) {
TAILQ_INSERT_TAIL(_active, pg, pageq);
@@ -1276,6 +1288,8 @@ uvm_pageunwire(struct vm_page *pg)
void
uvm_pagedeactivate(struct vm_page *pg)
{
+ MUTEX_ASSERT_LOCKED();
+
if
Re: [patch] httpd remove unused struct
On Sat, May 23, 2020 at 07:47:20PM -0500, Edgar Pettijohn wrote:
> Remove an unused struct from parse.y.
Yes, this seems correct. Updated diff against -current below.
OK?
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/httpd/parse.y,v
retrieving revision 1.120
diff -u -p -r1.120 parse.y
--- parse.y 29 Oct 2020 12:30:52 - 1.120
+++ parse.y 18 Nov 2020 21:42:16 -
@@ -127,10 +127,6 @@ typedef struct {
struct timeval tv;
struct portrange port;
struct auth auth;
- struct {
- struct sockaddr_storage ss;
- char name[HOST_NAME_MAX+1];
- }addr;
} v;
int lineno;
} YYSTYPE;
Re: smtpd: relax ORCPT check again
On Wed, Nov 18, 2020 at 08:57:48PM +, gil...@poolp.org wrote:
> November 18, 2020 9:54 PM, "Joerg Jung" wrote:
>
> > Hi,
> >
> > in my opinion revision 1.423 of smtp_session.c went a bit too far.
> > Enforcing that ORCPT has to have domain results in breakage in real
> > world usage. For example, sending from root user cron jobs mails
> > via Postfix aliased to an address handled by OpenSMTPD will fail.
> >
> > RFC leaves some room for interpretation here, but interoperability
> > may be considered important as well. GitHub issue #1084 [1] has
> > some more elaborations and examples, but was opened for the same
> > reason.
> >
> > Therefore, I propose the following diff below to slightly relax
> > the ORCPT check again by skipping the domain part check.
> >
> > Comments, OK?
> >
>
> maybe just skip the check ONLY if domain part is empty ?
>
Like in the diff below and assuming that domain part is always
nul terminated after text_to_mailaddr()?
OK?
Index: smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.426
diff -u -p -r1.426 smtp_session.c
--- smtp_session.c 24 Apr 2020 11:34:07 - 1.426
+++ smtp_session.c 18 Nov 2020 21:10:36 -
@@ -2583,7 +2583,8 @@ smtp_tx_rcpt_to(struct smtp_tx *tx, cons
if (!text_to_mailaddr(>evp.dsn_orcpt, opt) ||
!valid_localpart(tx->evp.dsn_orcpt.user) ||
- !valid_domainpart(tx->evp.dsn_orcpt.domain)) {
+ (strlen(tx->evp.dsn_orcpt.domain) != 0 &&
+!valid_domainpart(tx->evp.dsn_orcpt.domain))) {
smtp_reply(tx->session,
"553 ORCPT address syntax error");
return;
smtpd: relax ORCPT check again
Hi,
in my opinion revision 1.423 of smtp_session.c went a bit too far.
Enforcing that ORCPT has to have domain results in breakage in real
world usage. For example, sending from root user cron jobs mails
via Postfix aliased to an address handled by OpenSMTPD will fail.
RFC leaves some room for interpretation here, but interoperability
may be considered important as well. GitHub issue #1084 [1] has
some more elaborations and examples, but was opened for the same
reason.
Therefore, I propose the following diff below to slightly relax
the ORCPT check again by skipping the domain part check.
Comments, OK?
Thanks,
Regards,
Joerg
[1] https://github.com/OpenSMTPD/OpenSMTPD/issues/1084
Index: smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.426
diff -u -p -r1.426 smtp_session.c
--- smtp_session.c 24 Apr 2020 11:34:07 - 1.426
+++ smtp_session.c 18 Nov 2020 20:24:28 -
@@ -2582,8 +2582,7 @@ smtp_tx_rcpt_to(struct smtp_tx *tx, cons
opt += 7;
if (!text_to_mailaddr(>evp.dsn_orcpt, opt) ||
- !valid_localpart(tx->evp.dsn_orcpt.user) ||
- !valid_domainpart(tx->evp.dsn_orcpt.domain)) {
+ !valid_localpart(tx->evp.dsn_orcpt.user)) {
smtp_reply(tx->session,
"553 ORCPT address syntax error");
return;
Re: uvm_fault: refactoring for case 2 faults
> Date: Tue, 17 Nov 2020 09:25:10 -0300
> From: Martin Pieuchot
>
> Here's another refactoring that moves the remaining logic of uvm_fault()
> handling lower faults, case 2, to its own function. This logic shouldn't
> be modified in the first step of unlocking amap & anon and will still be
> executed under KERNEL_LOCK(). Having a separate function will however
> help to turn the 'ReFault' goto into a more readable loop. This will be
> the next step.
>
> ok?
ok kettenis@
> Index: uvm/uvm_fault.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_fault.c,v
> retrieving revision 1.107
> diff -u -p -r1.107 uvm_fault.c
> --- uvm/uvm_fault.c 16 Nov 2020 12:30:16 - 1.107
> +++ uvm/uvm_fault.c 16 Nov 2020 13:27:32 -
> @@ -484,6 +484,9 @@ struct uvm_faultctx {
> paddr_t pa_flags;
> };
>
> +int uvm_fault_lower(struct uvm_faultinfo *, struct uvm_faultctx *,
> + struct vm_page **, vm_fault_t, vm_prot_t);
> +
> /*
> * uvm_fault_check: check prot, handle needs-copy, etc.
> *
> @@ -901,19 +904,11 @@ uvm_fault(vm_map_t orig_map, vaddr_t vad
> {
> struct uvm_faultinfo ufi;
> struct uvm_faultctx flt;
> - boolean_t promote, locked, shadowed;
> - int result, lcv, gotpages;
> - vaddr_t currva;
> - voff_t uoff;
> - struct vm_amap *amap;
> - struct uvm_object *uobj;
> - struct vm_anon *anons_store[UVM_MAXRANGE], **anons, *anon;
> - struct vm_page *pages[UVM_MAXRANGE], *pg, *uobjpage;
> + boolean_t shadowed;
> + struct vm_anon *anons_store[UVM_MAXRANGE], **anons;
> + struct vm_page *pages[UVM_MAXRANGE];
> int error;
>
> - anon = NULL;
> - pg = NULL;
> -
> uvmexp.faults++;/* XXX: locking? */
> TRACEPOINT(uvm, fault, vaddr, fault_type, access_type, NULL);
>
> @@ -957,8 +952,28 @@ ReFault:
> }
> }
>
> - amap = ufi.entry->aref.ar_amap;
> - uobj = ufi.entry->object.uvm_obj;
> + /* handle case 2: faulting on backing object or zero fill */
> + error = uvm_fault_lower(, , pages, fault_type, access_type);
> + switch (error) {
> + case ERESTART:
> + goto ReFault;
> + default:
> + return error;
> + }
> +}
> +
> +int
> +uvm_fault_lower(struct uvm_faultinfo *ufi, struct uvm_faultctx *flt,
> + struct vm_page **pages, vm_fault_t fault_type, vm_prot_t access_type)
> +{
> + struct vm_amap *amap = ufi->entry->aref.ar_amap;
> + struct uvm_object *uobj = ufi->entry->object.uvm_obj;
> + boolean_t promote, locked;
> + int result, lcv, gotpages;
> + struct vm_page *uobjpage, *pg = NULL;
> + struct vm_anon *anon = NULL;
> + vaddr_t currva;
> + voff_t uoff;
>
> /*
>* if the desired page is not shadowed by the amap and we have a
> @@ -967,15 +982,15 @@ ReFault:
>* with the usual pgo_get hook). the backing object signals this by
>* providing a pgo_fault routine.
>*/
> - if (uobj && shadowed == FALSE && uobj->pgops->pgo_fault != NULL) {
> - result = uobj->pgops->pgo_fault(, flt.startva, pages,
> - flt.npages, flt.centeridx, fault_type, access_type,
> + if (uobj != NULL && uobj->pgops->pgo_fault != NULL) {
> + result = uobj->pgops->pgo_fault(ufi, flt->startva, pages,
> + flt->npages, flt->centeridx, fault_type, access_type,
> PGO_LOCKED);
>
> if (result == VM_PAGER_OK)
> return (0); /* pgo_fault did pmap enter */
> else if (result == VM_PAGER_REFAULT)
> - goto ReFault; /* try again! */
> + return ERESTART;/* try again! */
> else
> return (EACCES);
> }
> @@ -989,20 +1004,20 @@ ReFault:
>*
>* ("get" has the option of doing a pmap_enter for us)
>*/
> - if (uobj && shadowed == FALSE) {
> + if (uobj != NULL) {
> uvmexp.fltlget++;
> - gotpages = flt.npages;
> - (void) uobj->pgops->pgo_get(uobj, ufi.entry->offset +
> - (flt.startva - ufi.entry->start),
> - pages, , flt.centeridx,
> - access_type & MASK(ufi.entry),
> - ufi.entry->advice, PGO_LOCKED);
> + gotpages = flt->npages;
> + (void) uobj->pgops->pgo_get(uobj, ufi->entry->offset +
> + (flt->startva - ufi->entry->start),
> + pages, , flt->centeridx,
> + access_type & MASK(ufi->entry),
> + ufi->entry->advice, PGO_LOCKED);
>
> /* check for pages to map, if we got any */
> uobjpage = NULL;
> if (gotpages) {
> - currva = flt.startva;
> -
Re: AUDIORECDEVICE environment variable in sndio lib
Sorry I apologize, I had my kern.audio.record set to 0. It works for me.
*red faced*
-peter
On Wed, Nov 18, 2020 at 04:12:25PM +0100, Peter J. Philipp wrote:
> On Wed, Nov 18, 2020 at 11:00:17AM +0100, Alexandre Ratchov wrote:
> > Thanks; semarie suggested a similar diff, so below is an attempt to
> > take into account all the suggestions:
> >
> > - add AUDIOPLAYDEVICE, to handle play-only devices as well. We've the
> > very same problem for them.
> >
> > - use AUDIODEVICE if play-only (rec-only) mode is used but the
> > corresponding AUDIOPLAYDEVICE (AUDIORECDEVICE) var is not defined
> >
> > - minimal update for AUDIO{PLAY,REC}DEVICE in the man page
> >
> > OK?
>
> This stopped working for me today when I tested it. My box saw a reboot
> though.
>
> :-(
>
> I used AUDIOPLAYDEVICE=snd/0 AUDIORECDEVICE=snd/1 audacity
>
> also
> AUDIODEVICE=snd/0 AUDIORECDEVICE=snd/1 audacity
>
> I'm looking over the code a little, but I can't guarantee I'll find what's
> wrong.
>
> Best Regards,
>
> -peter
>
>
>
> > Index: sio.c
> > ===
> > RCS file: /cvs/src/lib/libsndio/sio.c,v
> > retrieving revision 1.24
> > diff -u -p -r1.24 sio.c
> > --- sio.c 29 Jun 2019 06:05:26 - 1.24
> > +++ sio.c 18 Nov 2020 09:49:24 -
> > @@ -52,7 +52,12 @@ sio_open(const char *str, unsigned int m
> > if (str == NULL) /* backward compat */
> > str = devany;
> > if (strcmp(str, devany) == 0 && !issetugid()) {
> > - str = getenv("AUDIODEVICE");
> > + if ((mode & SIO_PLAY) == 0)
> > + str = getenv("AUDIORECDEVICE");
> > + if ((mode & SIO_REC) == 0)
> > + str = getenv("AUDIOPLAYDEVICE");
> > + if (mode == (SIO_PLAY | SIO_REC) || str == NULL)
> > + str = getenv("AUDIODEVICE");
> > if (str == NULL)
> > str = devany;
> > }
> > Index: sndio.7
> > ===
> > RCS file: /cvs/src/lib/libsndio/sndio.7,v
> > retrieving revision 1.24
> > diff -u -p -r1.24 sndio.7
> > --- sndio.7 18 Jul 2020 05:01:14 - 1.24
> > +++ sndio.7 18 Nov 2020 09:49:24 -
> > @@ -151,9 +151,11 @@ If
> > .Cm default
> > is used as the audio device, the program will use the
> > one specified in the
> > -.Ev AUDIODEVICE
> > -environment variable.
> > -If it is not set, the program first tries to connect to
> > +.Ev AUDIODEVICE , AUDIOPLAYDEVICE
> > +and/or
> > +.Ev AUDIORECDEVICE
> > +environment variables.
> > +If they are not set, the program first tries to connect to
> > .Li snd/0 .
> > If that fails, it then tries to use
> > .Li rsnd/0 .
> > @@ -190,10 +192,20 @@ and contains 128 bits of raw random data
> > If a session needs to be shared between multiple users, they
> > can connect to the server using the same cookie.
> > .Sh ENVIRONMENT
> > -.Bl -tag -width "AUDIODEVICEXXX" -compact
> > +.Bl -tag -width "AUDIOPLAYDEVICE" -compact
> > .It Ev AUDIODEVICE
> > Audio device descriptor to use
> > when no descriptor is explicitly specified to a program.
> > +.It Ev AUDIOPLAYDEVICE
> > +Audio device descriptor to use for play-only mode
> > +when no descriptor is explicitly specified to a program.
> > +Overrides
> > +.Ev AUDIODEVICE .
> > +.It Ev AUDIORECDEVICE
> > +Audio device descriptor to use for record-only mode
> > +when no descriptor is explicitly specified to a program.
> > +Overrides
> > +.Ev AUDIODEVICE .
> > .It Ev MIDIDEVICE
> > MIDI port descriptor to use
> > when no descriptor is explicitly specified to a program.
>
Re: AUDIORECDEVICE environment variable in sndio lib
On Wed, Nov 18, 2020 at 11:00:17AM +0100, Alexandre Ratchov wrote:
> Thanks; semarie suggested a similar diff, so below is an attempt to
> take into account all the suggestions:
>
> - add AUDIOPLAYDEVICE, to handle play-only devices as well. We've the
> very same problem for them.
>
> - use AUDIODEVICE if play-only (rec-only) mode is used but the
> corresponding AUDIOPLAYDEVICE (AUDIORECDEVICE) var is not defined
>
> - minimal update for AUDIO{PLAY,REC}DEVICE in the man page
>
> OK?
This stopped working for me today when I tested it. My box saw a reboot
though.
:-(
I used AUDIOPLAYDEVICE=snd/0 AUDIORECDEVICE=snd/1 audacity
also
AUDIODEVICE=snd/0 AUDIORECDEVICE=snd/1 audacity
I'm looking over the code a little, but I can't guarantee I'll find what's
wrong.
Best Regards,
-peter
> Index: sio.c
> ===
> RCS file: /cvs/src/lib/libsndio/sio.c,v
> retrieving revision 1.24
> diff -u -p -r1.24 sio.c
> --- sio.c 29 Jun 2019 06:05:26 - 1.24
> +++ sio.c 18 Nov 2020 09:49:24 -
> @@ -52,7 +52,12 @@ sio_open(const char *str, unsigned int m
> if (str == NULL) /* backward compat */
> str = devany;
> if (strcmp(str, devany) == 0 && !issetugid()) {
> - str = getenv("AUDIODEVICE");
> + if ((mode & SIO_PLAY) == 0)
> + str = getenv("AUDIORECDEVICE");
> + if ((mode & SIO_REC) == 0)
> + str = getenv("AUDIOPLAYDEVICE");
> + if (mode == (SIO_PLAY | SIO_REC) || str == NULL)
> + str = getenv("AUDIODEVICE");
> if (str == NULL)
> str = devany;
> }
> Index: sndio.7
> ===
> RCS file: /cvs/src/lib/libsndio/sndio.7,v
> retrieving revision 1.24
> diff -u -p -r1.24 sndio.7
> --- sndio.7 18 Jul 2020 05:01:14 - 1.24
> +++ sndio.7 18 Nov 2020 09:49:24 -
> @@ -151,9 +151,11 @@ If
> .Cm default
> is used as the audio device, the program will use the
> one specified in the
> -.Ev AUDIODEVICE
> -environment variable.
> -If it is not set, the program first tries to connect to
> +.Ev AUDIODEVICE , AUDIOPLAYDEVICE
> +and/or
> +.Ev AUDIORECDEVICE
> +environment variables.
> +If they are not set, the program first tries to connect to
> .Li snd/0 .
> If that fails, it then tries to use
> .Li rsnd/0 .
> @@ -190,10 +192,20 @@ and contains 128 bits of raw random data
> If a session needs to be shared between multiple users, they
> can connect to the server using the same cookie.
> .Sh ENVIRONMENT
> -.Bl -tag -width "AUDIODEVICEXXX" -compact
> +.Bl -tag -width "AUDIOPLAYDEVICE" -compact
> .It Ev AUDIODEVICE
> Audio device descriptor to use
> when no descriptor is explicitly specified to a program.
> +.It Ev AUDIOPLAYDEVICE
> +Audio device descriptor to use for play-only mode
> +when no descriptor is explicitly specified to a program.
> +Overrides
> +.Ev AUDIODEVICE .
> +.It Ev AUDIORECDEVICE
> +Audio device descriptor to use for record-only mode
> +when no descriptor is explicitly specified to a program.
> +Overrides
> +.Ev AUDIODEVICE .
> .It Ev MIDIDEVICE
> MIDI port descriptor to use
> when no descriptor is explicitly specified to a program.
Re: Screen flickering on ThinkPad X270
On 18/11/2020 07:05, Jonathan Gray wrote: > On Wed, Nov 18, 2020 at 01:51:39AM +, Sine Astris wrote: >> Hi, >> >> I was suffering from a subtle (yet annoying once noticed) problem with >> screen flickering whilst using xenocara on my ThinkPad X270. >> >> It was only distinctly apparent with certain colours/images being >> displayed, generally a darker (but not black) static background with >> small bright regions changing. For example I could see a subtle >> flicker/brightening of the entire background on each character typed in >> an xterm. It also occasionally manifested (apparently randomly) as a >> subtle flicker which looked like a quick change of brightness. >> >> After excluding any possible xorg.conf device options, a bit of googling >> turned up some people experiencing a similar issue on windows and linux, >> and they pointed to a feature of newer Intel GPUs called "PSR" / "Panel >> Self Refresh". These issues were resolved via the settings application >> on windows, and on linux machines by setting a linux kernel parameter: >> i915.enable_psr=0 >> >> OpenBSD doesn't appear to expose a mechanism for setting i915 >> parameters, so I changed the value from use hardware default to >> disabled within: sys/dev/pci/drm/i915/i915_params.h. >> >> This resolved the problem completely (which is a great relief, as it's >> frequently apparent once you've noticed it), and doesn't appear to have >> resulted in any other issues. >> >> Below are a diff to i915_params.h, my xorg.conf, and dmesg. When I get >> time I may see if I'm able to make the required changes to expose this >> as a flag. > > Why have you opted into the intel xorg driver instead of using > the modesetting driver which should be the default for this hardware? I experience significant screen tearing on the modesetting driver, using the intel xorg driver with the "TearFree" option is the best solution I've found so far. > Do you see the same behaviour with the modesetting driver? Yes, the flickering behaviour is indentical with both the intel xorg driver and the modesetting driver. I've included my Xorg.0.log when using the modesetting driver at the bottom of the mail in case it's useful. > > The params aren't something we'd make controllable from userspace. > Ideally the problem with PSR would be tracked down so people do not have > to change anything. Ah righto, fixing the problem in PSR would be ideal, barring finding a solution within PSR, would adding some form of quirk be sensible? I'm not sure what the actual power savings of PSR are, if mostly insignificant I might be tempted to just disable it by default. > >> >> >> --- /usr/src/sys/dev/pci/drm/i915/i915_params.h Tue Nov 17 09:50:23 2020 >> +++ /usr/src/sys/dev/pci/drm/i915/i915_params.h.new Tue Nov 17 09:30:24 2020 >> @@ -52,7 +52,7 @@ >> param(int, vbt_sdvo_panel_type, -1, 0400) \ >> param(int, enable_dc, -1, 0400) \ >> param(int, enable_fbc, -1, 0600) \ >> -param(int, enable_psr, -1, 0600) \ >> +param(int, enable_psr, 0, 0600) \ >> param(int, disable_power_well, -1, 0400) \ >> param(int, enable_ips, 1, 0600) \ >> param(int, invert_brightness, 0, 0600) \ >> >> >> [61.711] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem >> (Operation not permitted) >> Check that you have set 'machdep.allowaperture=1' >> in /etc/sysctl.conf and reboot your machine >> refer to xf86(4) for details >> [61.711] linear framebuffer access unavailable >> [61.732] (--) Using wscons driver on /dev/ttyC4 >> [61.739] >> X.Org X Server 1.20.8 >> X Protocol Version 11, Revision 0 >> [61.739] Build Operating System: OpenBSD 6.8 amd64 >> [61.739] Current Operating System: OpenBSD heliospan.home 6.8 >> GENERIC.MP#1 amd64 >> [61.739] Build Date: 17 November 2020 08:48:50PM >> [61.739] >> [61.739] Current version of pixman: 0.38.4 >> [61.739] Before reporting problems, check http://wiki.x.org >> to make sure that you have the latest version. >> [61.739] Markers: (--) probed, (**) from config file, (==) default >> setting, >> (++) from command line, (!!) notice, (II) informational, >> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. >> [61.739] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Nov 17 22:33:05 >> 2020 >> [61.741] (==) Using config directory: "/etc/X11/xorg.conf.d" >> [61.741] (==) Using system config directory >> "/usr/X11R6/share/X11/xorg.conf.d" >> [61.743] (==) No Layout section. Using the first Screen section. >> [61.743] (==) No screen section available. Using defaults. >> [61.743] (**) |-->Screen "Default Screen Section" (0) >> [61.743] (**) | |-->Monitor "" >> [61.744] (==) No device specified for screen "Default Screen Section". >> Using the first device section listed. >> [61.744] (**) | |-->Device "drm" >> [61.744] (==) No monitor specified for screen "Default
Fewer uvmexp
While auditing the various uses of the uvmexp fields I came across
those under #ifdet notyet. May I delete them so I don't have to give
them some MP love? Ok?
Index: arch/amd64//amd64/cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.150
diff -u -p -r1.150 cpu.c
--- arch/amd64//amd64/cpu.c 13 Sep 2020 11:53:16 - 1.150
+++ arch/amd64//amd64/cpu.c 18 Nov 2020 13:11:17 -
@@ -443,17 +443,6 @@ cpu_vm_init(struct cpu_info *ci)
}
ncolors = max(ncolors, tcolors);
}
-
-#ifdef notyet
- /*
-* Knowing the size of the largest cache on this CPU, re-color
-* our pages.
-*/
- if (ncolors <= uvmexp.ncolors)
- return;
- printf("%s: %d page colors\n", ci->ci_dev->dv_xname, ncolors);
- uvm_page_recolor(ncolors);
-#endif
}
Index: arch/luna88k/luna88k/isr.c
===
RCS file: /cvs/src/sys/arch/luna88k/luna88k/isr.c,v
retrieving revision 1.11
diff -u -p -r1.11 isr.c
--- arch/luna88k/luna88k/isr.c 28 Jun 2017 10:31:48 - 1.11
+++ arch/luna88k/luna88k/isr.c 18 Nov 2020 13:11:27 -
@@ -151,10 +151,6 @@ isrdispatch_autovec(int ipl)
panic("isrdispatch_autovec: bad ipl %d", ipl);
#endif
-#if 0 /* XXX: already counted in machdep.c */
- uvmexp.intrs++;
-#endif
-
list = _autovec[ipl];
if (LIST_EMPTY(list)) {
printf("isrdispatch_autovec: ipl %d unexpected\n", ipl);
Re: Unable to adjust beep volume on ThinkPad X270
Enabling for all Realtek codecs sounds like a good idea to me. I was overcautious when applying it to only my vendor/product ID. On 18/11/2020 03:50, Jonathan Gray wrote: > On Wed, Nov 18, 2020 at 01:41:49AM +, Sine Astris wrote: >> Hi, >> >> I wasn't able to adjust the volume of the keyboard bell via >> wsconsctl(8), or the volume of /dev/speaker on my ThinkPad X270. >> >> Additionally, the default spkr_source (mix3) doesn't output the beep. >> Changing to mix2, sounds the beep and my existing audio seems fine. >> >> # mixerctl outputs.spkr_source=mix2 >> >> I applied the AZ_QRK_WID_BEEP_1D quirk to the Realtek ALC298 codec for >> my devices vendor/product ID, and this seems to have resolved the issue. >> Keyboard bell and /dev/speaker volume adjusts via wsconsctl(8) / >> mixerctl(8)'s inputs.mix_beep=x,x >> >> Below are diff to azalia_codec.c, pcidump for my audio device, final >> mixerctl output, and dmesg. > > There is no cd audio input so I don't see a need for that quirk. > > I see no reason to limit enabling beep as it will be in the same > place for everything with that codec. Perhaps we should just > enable it for all Realtek codecs. > > Index: azalia_codec.c > === > RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v > retrieving revision 1.182 > diff -u -p -r1.182 azalia_codec.c > --- azalia_codec.c25 Oct 2020 02:54:38 - 1.182 > +++ azalia_codec.c18 Nov 2020 03:43:10 - > @@ -208,6 +208,7 @@ azalia_codec_init_vtbl(codec_t *this) > this->name = "Realtek ALC295"; > break; > case 0x10ec0298: > + this->qrks |= AZ_QRK_WID_BEEP_1D; > this->name = "Realtek ALC298"; > if (this->subid == 0x320019e5 || > this->subid == 0x320119e5) /* Huawei Matebook X */ > OpenPGP_0x4383C362B5F65EF4.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: AUDIORECDEVICE environment variable in sndio lib
On Tue, Nov 17, 2020 at 05:09:28PM +, Stuart Henderson wrote:
> On 2020/11/17 17:13, Peter J. Philipp wrote:
> > Hi,
> >
> > I have a mic on snd/1 and speakers on snd/0. I had tried a lot of different
> > settings with audacity port but couldn't get this to work, so I chose the
> > method of last resort. Below is a patch to allow an AUDIORECDEVICE
> > environment
> > variable specifying the wanted microphone.
>
> This seems a worthwhile addition.
>
> > Index: sio.c
> > ===
> > RCS file: /cvs/src/lib/libsndio/sio.c,v
> > retrieving revision 1.24
> > diff -u -p -u -r1.24 sio.c
> > --- sio.c 29 Jun 2019 06:05:26 - 1.24
> > +++ sio.c 17 Nov 2020 16:13:04 -
> > @@ -43,6 +43,7 @@ sio_open(const char *str, unsigned int m
> > {
> > static char devany[] = SIO_DEVANY;
> > struct sio_hdl *hdl;
> > + char *rec = NULL;
> >
> > #ifdef DEBUG
> > _sndio_debug_init();
> > @@ -55,6 +56,12 @@ sio_open(const char *str, unsigned int m
> > str = getenv("AUDIODEVICE");
> > if (str == NULL)
> > str = devany;
> > + rec = getenv("AUDIORECDEVICE");
> > + if (rec == NULL)
> > + rec = devany;
> > +
> > + if (rec && mode == SIO_REC)
> > + str = rec;
>
> If AUDIORECDEVICE is unset, it would be better to fallback to
> AUDIODEVICE rather than directly to devany.
>
Thanks; semarie suggested a similar diff, so below is an attempt to
take into account all the suggestions:
- add AUDIOPLAYDEVICE, to handle play-only devices as well. We've the
very same problem for them.
- use AUDIODEVICE if play-only (rec-only) mode is used but the
corresponding AUDIOPLAYDEVICE (AUDIORECDEVICE) var is not defined
- minimal update for AUDIO{PLAY,REC}DEVICE in the man page
OK?
Index: sio.c
===
RCS file: /cvs/src/lib/libsndio/sio.c,v
retrieving revision 1.24
diff -u -p -r1.24 sio.c
--- sio.c 29 Jun 2019 06:05:26 - 1.24
+++ sio.c 18 Nov 2020 09:49:24 -
@@ -52,7 +52,12 @@ sio_open(const char *str, unsigned int m
if (str == NULL) /* backward compat */
str = devany;
if (strcmp(str, devany) == 0 && !issetugid()) {
- str = getenv("AUDIODEVICE");
+ if ((mode & SIO_PLAY) == 0)
+ str = getenv("AUDIORECDEVICE");
+ if ((mode & SIO_REC) == 0)
+ str = getenv("AUDIOPLAYDEVICE");
+ if (mode == (SIO_PLAY | SIO_REC) || str == NULL)
+ str = getenv("AUDIODEVICE");
if (str == NULL)
str = devany;
}
Index: sndio.7
===
RCS file: /cvs/src/lib/libsndio/sndio.7,v
retrieving revision 1.24
diff -u -p -r1.24 sndio.7
--- sndio.7 18 Jul 2020 05:01:14 - 1.24
+++ sndio.7 18 Nov 2020 09:49:24 -
@@ -151,9 +151,11 @@ If
.Cm default
is used as the audio device, the program will use the
one specified in the
-.Ev AUDIODEVICE
-environment variable.
-If it is not set, the program first tries to connect to
+.Ev AUDIODEVICE , AUDIOPLAYDEVICE
+and/or
+.Ev AUDIORECDEVICE
+environment variables.
+If they are not set, the program first tries to connect to
.Li snd/0 .
If that fails, it then tries to use
.Li rsnd/0 .
@@ -190,10 +192,20 @@ and contains 128 bits of raw random data
If a session needs to be shared between multiple users, they
can connect to the server using the same cookie.
.Sh ENVIRONMENT
-.Bl -tag -width "AUDIODEVICEXXX" -compact
+.Bl -tag -width "AUDIOPLAYDEVICE" -compact
.It Ev AUDIODEVICE
Audio device descriptor to use
when no descriptor is explicitly specified to a program.
+.It Ev AUDIOPLAYDEVICE
+Audio device descriptor to use for play-only mode
+when no descriptor is explicitly specified to a program.
+Overrides
+.Ev AUDIODEVICE .
+.It Ev AUDIORECDEVICE
+Audio device descriptor to use for record-only mode
+when no descriptor is explicitly specified to a program.
+Overrides
+.Ev AUDIODEVICE .
.It Ev MIDIDEVICE
MIDI port descriptor to use
when no descriptor is explicitly specified to a program.
