Re: uhidev: claim multiple report ids [3/N]
Le 12/11/2021 à 09:11, Anton Lindqvist a écrit :
On Thu, Nov 11, 2021 at 05:09:35PM -0800, Greg Steuck wrote:
Anton Lindqvist writes:
On Thu, Nov 11, 2021 at 03:29:15PM +0100, Anton Lindqvist wrote:
Hi,
The second attempt to solve the uhidev claim multiple report ids
conflict didn't work out either as it broke fido(4). Signalling claim
multiple report ids to the match routines using the report id does not
work as all 256 values already have semantic meaning. I instead want to
use `uha->claimed != NULL' to signal that multiple report ids can be
claimed. Before doing so, refactor in order to make an upcoming diff
with the actual fix significantly smaller.
No intended^W functional change.
Comments? OK?
... and here's the actual fix applied on top of the previous diff.
The pair of diffs seems to work for me (fido remains operational unlike
the previous iteration). There's a minor change in dmesg output which is
not otherwise consequential:
Thanks, some drivers (ums and ukbd for instance) are still missing a
UHIDEV_CLAIM_MULTIPLE_REPORTID conditional. That can be fixed later on.
For now, keep using 255 as the report id when claiming multiple report
ids.
Here's a new iteration of the second diff. Another round of testing
would be much appreciated.
diff --git sys/dev/usb/uhidev.h sys/dev/usb/uhidev.h
index 86217fb8880..b8daf014662 100644
--- sys/dev/usb/uhidev.h
+++ sys/dev/usb/uhidev.h
@@ -75,12 +75,11 @@ struct uhidev_attach_arg {
struct usb_attach_arg *uaa;
struct uhidev_softc *parent;
uint8_t reportid;
- uint8_t nreports;
+ u_intnreports;
uint8_t *claimed;
};
-#define UHIDEV_CLAIM_MULTIPLE_REPORTID(u) \
- ((u)->reportid == __UHIDEV_CLAIM_MULTIPLE_REPORTID)
+#define UHIDEV_CLAIM_MULTIPLE_REPORTID(u) ((u)->claimed != NULL)
#define __UHIDEV_CLAIM_MULTIPLE_REPORTID255 /* XXX */
int uhidev_report_type_conv(int);
Hi,
It works great for me, upd is not crashing with my UPS and unplugging is
fine too in -current and -stable.
Thanks,
Damien
Re: uhidev: plug memory leak
Le 03/11/2021 à 07:45, Anton Lindqvist a écrit : Hi, Upon uhidev detach, free the list of sub devices. Comments? OK? diff --git sys/dev/usb/uhidev.c sys/dev/usb/uhidev.c index 014dc052c1c..5fe2f702e21 100644 --- sys/dev/usb/uhidev.c +++ sys/dev/usb/uhidev.c @@ -451,6 +451,7 @@ uhidev_detach(struct device *self, int flags) sc->sc_subdevs[i] = NULL; } + free(sc->sc_subdevs, M_USBDEV, sc->sc_nrepid * sizeof(struct uhidev *)); return (rv); } Hi, No regression for me. Have a nice day, Damien
Re: uhidev: claim multiple report ids
Le 03/11/2021 à 07:44, Anton Lindqvist a écrit :
Hi,
In an attempt to fix a bug related to upd(4) I discovered that the
pseudo report id UHIDEV_CLAIM_MULTIPLE_REPORTID is conflicting with an
actual report id. The previous fix, reverted by now, avoided the
conflict by incrementing the pseudo report id was not a good idea
since a report id is expected to be represented using a single unsigned
byte elsewhere in the usb stack.
Here's a second attempt. Report id zero is according to the USB HID
specification reserved and should not be used. We can define
UHIDEV_CLAIM_MULTIPLE_REPORTID as zero removing the need to use a larger
integer type than the existing uint8_t for the report id. Another
correction is also needed. Some descriptors only supports a single
report and the report id is in this case optional. Internally, uhidev
uses report id zero for such devices. It's therefore of importance to
not perform a claim multiple report ids attachment on such devices as
there's only one report id to claim.
Testing would be much appreciated.
Comments? OK?
diff --git sys/dev/usb/uhidev.c sys/dev/usb/uhidev.c
index 5fe2f702e21..f5cc5984b59 100644
--- sys/dev/usb/uhidev.c
+++ sys/dev/usb/uhidev.c
@@ -247,29 +247,36 @@ uhidev_attach(struct device *parent, struct device *self,
void *aux)
sc->sc_isize += (nrepid != 1); /* one byte for the report ID */
DPRINTF(("uhidev_attach: isize=%d\n", sc->sc_isize));
+ memset(&uha, 0, sizeof(uha));
uha.uaa = uaa;
uha.parent = sc;
- uha.reportid = UHIDEV_CLAIM_MULTIPLE_REPORTID;
- uha.nreports = nrepid;
- uha.claimed = malloc(nrepid, M_TEMP, M_WAITOK|M_ZERO);
/* Look for a driver claiming multiple report IDs first. */
- dev = config_found_sm(self, &uha, NULL, uhidevsubmatch);
- if (dev != NULL) {
- for (repid = 0; repid < nrepid; repid++) {
- /*
-* Could already be assigned by uhidev_set_report_dev().
-*/
- if (sc->sc_subdevs[repid] != NULL)
- continue;
-
- if (uha.claimed[repid])
+ if (nrepid > 1) {
+ uha.reportid = UHIDEV_CLAIM_MULTIPLE_REPORTID;
+ uha.nreports = nrepid;
+ uha.claimed = malloc(nrepid, M_TEMP, M_WAITOK|M_ZERO);
+
+ dev = config_found_sm(self, &uha, NULL, uhidevsubmatch);
+ if (dev != NULL) {
+ for (repid = 0; repid < nrepid; repid++) {
+ /*
+* Could already be assigned by
+* uhidev_set_report_dev().
+*/
+ if (sc->sc_subdevs[repid] != NULL)
+ continue;
+
+ if (!uha.claimed[repid])
+ continue;
sc->sc_subdevs[repid] = (struct uhidev *)dev;
+ }
}
- }
- free(uha.claimed, M_TEMP, nrepid);
- uha.claimed = NULL;
+ free(uha.claimed, M_TEMP, nrepid);
+ uha.nreports = 0;
+ uha.claimed = NULL;
+ }
for (repid = 0; repid < nrepid; repid++) {
DPRINTF(("%s: try repid=%d\n", __func__, repid));
diff --git sys/dev/usb/uhidev.h sys/dev/usb/uhidev.h
index 6ce75b1f49d..9ae85e1ab9f 100644
--- sys/dev/usb/uhidev.h
+++ sys/dev/usb/uhidev.h
@@ -81,8 +81,8 @@ struct uhidev_attach_arg {
struct usb_attach_arg *uaa;
struct uhidev_softc *parent;
uint8_t reportid;
-#defineUHIDEV_CLAIM_MULTIPLE_REPORTID 255
- uint8_t nreports;
+#defineUHIDEV_CLAIM_MULTIPLE_REPORTID 0
+ u_intnreports;
uint8_t *claimed;
};
Hi,
It works flawlessly for me and unplugging is fine too.
OpenBSD 7.0-stable (UPD.MP) #0: Wed Nov 3 08:37:45 CET 2021
damien@phoenix.petrolan:/usr/src/sys/arch/amd64/compile/UPD.MP
real mem = 6283997184 (5992MB)
avail mem = 6077505536 (5795MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xc8889000 (57 entries)
bios0: vendor LENOVO version "R19ET36W (1.20 )" date 07/12/2021
bios0: LENOVO 20U70003FR
acpi0 at bios0: ACPI 6.3
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT IVRS SSDT MSDM BATB HPET APIC MCFG SBST WSMT
SSDT SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI SSDT SSDT
acpi0: wakeup devices GPP0(S4) GPP3(S4) GPP4(S4) GPP5(S4) GP17(S4) XHC0(S3)
XHC1(S3) GP19(S4) LID_(S4) SLPB(S3)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 5 4500U with Radeon Graphics, 2370.85 MHz, 17
Re: upd(4) page fault since 7.0
Le 28/10/2021 à 21:09, Anton Lindqvist a écrit : Hi Anton, It works great! See below the resulting dmesg with option UPD_DEBUG. Any chance this fix will come through syspatch? OpenBSD 7.0-stable (UPD.MP) #20: Fri Oct 29 08:41:57 CEST 2021 damien@gageac.petrolan:/usr/src/sys/arch/amd64/compile/UPD.MP real mem = 6283997184 (5992MB) avail mem = 6077521920 (5795MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xc8889000 (57 entries) bios0: vendor LENOVO version "R19ET36W (1.20 )" date 07/12/2021 bios0: LENOVO 20U70003FR acpi0 at bios0: ACPI 6.3 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT IVRS SSDT MSDM BATB HPET APIC MCFG SBST WSMT SSDT SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI SSDT SSDT acpi0: wakeup devices GPP0(S4) GPP3(S4) GPP4(S4) GPP5(S4) GP17(S4) XHC0(S3) XHC1(S3) GP19(S4) LID_(S4) SLPB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 5 4500U with Radeon Graphics, 2370.90 MHz, 17-60-01 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,IBRS,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 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 1 (application processor) cpu1: AMD Ryzen 5 4500U with Radeon Graphics, 2370.55 MHz, 17-60-01 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,IBRS,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 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 2 (application processor) cpu2: AMD Ryzen 5 4500U with Radeon Graphics, 2370.55 MHz, 17-60-01 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,IBRS,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 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 4 (application processor) cpu3: AMD Ryzen 5 4500U with Radeon Graphics, 2370.55 MHz, 17-60-01 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,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu3: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: disabling user TSC (skew=226) cpu3: smt 0, core 4, package 0 cpu4 at mainbus0: apid 5 (application processor) cpu4: AMD Ryzen 5 4500U with Radeon Graphics, 2370.55 MHz, 17-60-01 cpu4: 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,NX
Re: upd(4) page fault since 7.0
Le 26/10/2021 à 19:03, Anton Lindqvist a écrit :
On Tue, Oct 26, 2021 at 05:58:12PM +0200, Damien Couderc wrote:
Le 26/10/2021 à 16:11, Anton Lindqvist a écrit :
On Tue, Oct 26, 2021 at 09:50:41AM +0200, Damien Couderc wrote:
Le 24/10/2021 à 21:45, Anton Lindqvist a écrit :
On Sun, Oct 24, 2021 at 03:03:01PM +0200, Damien Couderc wrote:
Hi,
I got a page fault with upd(4) since 7.0.
The problem began with the last revision of upd.c (1.30):
===
RCS file: /cvs/src/sys/dev/usb/upd.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- src/sys/dev/usb/upd.c 2021/03/08 14:35:57 1.29
+++ src/sys/dev/usb/upd.c 2021/08/06 17:46:45 1.30
@@ -1,4 +1,4 @@
-/* $OpenBSD: upd.c,v 1.29 2021/03/08 14:35:57 jcs Exp $ */
+/* $OpenBSD: upd.c,v 1.30 2021/08/06 17:46:45 abieber Exp $ */
/*
* Copyright (c) 2015 David Higgs
@@ -167,7 +167,7 @@
if (upd_lookup_usage_entry(desc, size,
upd_usage_roots + i, &item)) {
ret = UMATCH_VENDOR_PRODUCT;
- break;
+ uha->claimed[item.report_ID] = 1;
}
return (ret);
===
The uha.claimed array is allocated using uha.nreports as its size while
upd_match() is looping through the number of items of upd_usage_roots.
In my case uha.nreports is equal to zero so uha.claimed is null, hence
setting uha->claimed[n] is failing.
As I'm not familiar with the HID code I did not yet understood the
relation between upd_usage_roots and the claimed array but as we're
talking about UPS attached computers I though the issue would sensible
enough to make a quick reporting.
You'll find a dmesg with options UPD_DEBUG and UHIDEV_DEBUG set and the
following patch applied to circumvent the page fault and provide some debug:
Could you try the following diff, looks like an unsigned wrap around.
Index: dev/usb/uhidev.h
===
RCS file: /cvs/src/sys/dev/usb/uhidev.h,v
retrieving revision 1.32
diff -u -p -r1.32 uhidev.h
--- dev/usb/uhidev.h12 Sep 2021 06:58:08 - 1.32
+++ dev/usb/uhidev.h24 Oct 2021 19:44:52 -
@@ -82,7 +82,7 @@ struct uhidev_attach_arg {
struct uhidev_softc *parent;
uint8_t reportid;
#define UHIDEV_CLAIM_MULTIPLE_REPORTID 255
- uint8_t nreports;
+ u_intnreports;
uint8_t *claimed;
};
Hello Anton,
I made a quick test and nreports is now set with 256 but I still get the
page fault.
I'll check the details ASAP.
Do you have a backtrace?
I only have screenshots of ddb.
With the default kernel :
http://cromagnon.petrocore.eu/ss_upd_ddb_default.jpg
With a custom kernel for a bit more data :
http://cromagnon.petrocore.eu/ss_upd_ddb_custom.jpg
Looks like a NULL deref. My guess would be item.report_ID going out of
bounds on uha->claimed. Inspecting item.report_ID could provide some
hints. This in turn could be caused by uhidev_maxrepid() looking for
hid_none items whereas upd_lookup_usage_entry() uses hid_feature.
Also, it would be interesting to see the descriptor of this device. If
you make upd_match() unconditionally return 0 it should hopefully^W
attach as uhid device; making it possible to extract the report using
usbhidctl replacing X with the attached device:
# usbhidctl -R -f /dev/uhidX
Hi !
I set uhidevdebug to enable more debug messages and it gets more
interesting as we can see that we enter twice in upd_match() but the
second time uha.claimed is not allocated.
I'll dig for more ASAP.
Which uhid device would you want to get the report for ?
Below the diff of the changes I made yet and the corresponding dmesg.
Index: uhidev.c
===
RCS file: /home/cvs/src/sys/dev/usb/uhidev.c,v
retrieving revision 1.95
diff -u -p -r1.95 uhidev.c
--- uhidev.c12 Sep 2021 06:58:08 - 1.95
+++ uhidev.c28 Oct 2021 17:53:55 -
@@ -72,7 +72,7 @@ int uhidev_use_rdesc(struct uhidev_softc
#ifdef UHIDEV_DEBUG
#define DPRINTF(x) do { if (uhidevdebug) printf x; } while (0)
#define DPRINTFN(n,x) do { if (uhidevdebug>(n)) printf x; } while (0)
-intuhidevdebug = 0;
+intuhidevdebug = 1;
#else
#define DPRINTF(x)
#define DPRINTFN(n,x)
@@ -252,6 +252,7 @@ uhidev_attach(struct device *parent, str
uha.reportid = UHIDEV_CLAIM_MULTIPLE_REPORTID;
uha.nreports = nrepid;
uha.claimed = malloc(nrepid, M_TEMP, M_WAITOK|M_ZERO);
+DPRINTF(("uhidev_attach: uha.claimed allocated\n"));
/* Look for a driver claiming multiple report IDs first. */
dev = config_found_sm(self, &uha, NULL, uhidevsubmatch);
@@ -2
Re: upd(4) page fault since 7.0
Le 26/10/2021 à 16:11, Anton Lindqvist a écrit :
On Tue, Oct 26, 2021 at 09:50:41AM +0200, Damien Couderc wrote:
Le 24/10/2021 à 21:45, Anton Lindqvist a écrit :
On Sun, Oct 24, 2021 at 03:03:01PM +0200, Damien Couderc wrote:
Hi,
I got a page fault with upd(4) since 7.0.
The problem began with the last revision of upd.c (1.30):
===
RCS file: /cvs/src/sys/dev/usb/upd.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- src/sys/dev/usb/upd.c 2021/03/08 14:35:57 1.29
+++ src/sys/dev/usb/upd.c 2021/08/06 17:46:45 1.30
@@ -1,4 +1,4 @@
-/* $OpenBSD: upd.c,v 1.29 2021/03/08 14:35:57 jcs Exp $ */
+/* $OpenBSD: upd.c,v 1.30 2021/08/06 17:46:45 abieber Exp $ */
/*
* Copyright (c) 2015 David Higgs
@@ -167,7 +167,7 @@
if (upd_lookup_usage_entry(desc, size,
upd_usage_roots + i, &item)) {
ret = UMATCH_VENDOR_PRODUCT;
- break;
+ uha->claimed[item.report_ID] = 1;
}
return (ret);
===
The uha.claimed array is allocated using uha.nreports as its size while
upd_match() is looping through the number of items of upd_usage_roots.
In my case uha.nreports is equal to zero so uha.claimed is null, hence
setting uha->claimed[n] is failing.
As I'm not familiar with the HID code I did not yet understood the
relation between upd_usage_roots and the claimed array but as we're
talking about UPS attached computers I though the issue would sensible
enough to make a quick reporting.
You'll find a dmesg with options UPD_DEBUG and UHIDEV_DEBUG set and the
following patch applied to circumvent the page fault and provide some debug:
Could you try the following diff, looks like an unsigned wrap around.
Index: dev/usb/uhidev.h
===
RCS file: /cvs/src/sys/dev/usb/uhidev.h,v
retrieving revision 1.32
diff -u -p -r1.32 uhidev.h
--- dev/usb/uhidev.h12 Sep 2021 06:58:08 - 1.32
+++ dev/usb/uhidev.h24 Oct 2021 19:44:52 -
@@ -82,7 +82,7 @@ struct uhidev_attach_arg {
struct uhidev_softc *parent;
uint8_t reportid;
#define UHIDEV_CLAIM_MULTIPLE_REPORTID 255
- uint8_t nreports;
+ u_intnreports;
uint8_t *claimed;
};
Hello Anton,
I made a quick test and nreports is now set with 256 but I still get the
page fault.
I'll check the details ASAP.
Do you have a backtrace?
I only have screenshots of ddb.
With the default kernel :
http://cromagnon.petrocore.eu/ss_upd_ddb_default.jpg
With a custom kernel for a bit more data :
http://cromagnon.petrocore.eu/ss_upd_ddb_custom.jpg
With luck I'll have some time to go deeper this evening.
Thanks,
Damien
Re: upd(4) page fault since 7.0
Le 24/10/2021 à 21:45, Anton Lindqvist a écrit :
On Sun, Oct 24, 2021 at 03:03:01PM +0200, Damien Couderc wrote:
Hi,
I got a page fault with upd(4) since 7.0.
The problem began with the last revision of upd.c (1.30):
===
RCS file: /cvs/src/sys/dev/usb/upd.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- src/sys/dev/usb/upd.c 2021/03/08 14:35:57 1.29
+++ src/sys/dev/usb/upd.c 2021/08/06 17:46:45 1.30
@@ -1,4 +1,4 @@
-/* $OpenBSD: upd.c,v 1.29 2021/03/08 14:35:57 jcs Exp $ */
+/* $OpenBSD: upd.c,v 1.30 2021/08/06 17:46:45 abieber Exp $ */
/*
* Copyright (c) 2015 David Higgs
@@ -167,7 +167,7 @@
if (upd_lookup_usage_entry(desc, size,
upd_usage_roots + i, &item)) {
ret = UMATCH_VENDOR_PRODUCT;
- break;
+ uha->claimed[item.report_ID] = 1;
}
return (ret);
===
The uha.claimed array is allocated using uha.nreports as its size while
upd_match() is looping through the number of items of upd_usage_roots.
In my case uha.nreports is equal to zero so uha.claimed is null, hence
setting uha->claimed[n] is failing.
As I'm not familiar with the HID code I did not yet understood the
relation between upd_usage_roots and the claimed array but as we're
talking about UPS attached computers I though the issue would sensible
enough to make a quick reporting.
You'll find a dmesg with options UPD_DEBUG and UHIDEV_DEBUG set and the
following patch applied to circumvent the page fault and provide some debug:
Could you try the following diff, looks like an unsigned wrap around.
Index: dev/usb/uhidev.h
===
RCS file: /cvs/src/sys/dev/usb/uhidev.h,v
retrieving revision 1.32
diff -u -p -r1.32 uhidev.h
--- dev/usb/uhidev.h12 Sep 2021 06:58:08 - 1.32
+++ dev/usb/uhidev.h24 Oct 2021 19:44:52 -
@@ -82,7 +82,7 @@ struct uhidev_attach_arg {
struct uhidev_softc *parent;
uint8_t reportid;
#define UHIDEV_CLAIM_MULTIPLE_REPORTID 255
- uint8_t nreports;
+ u_intnreports;
uint8_t *claimed;
};
Hello Anton,
I made a quick test and nreports is now set with 256 but I still get the
page fault.
I'll check the details ASAP.
Thank you,
Damien
upd(4) page fault since 7.0
Hi,
I got a page fault with upd(4) since 7.0.
The problem began with the last revision of upd.c (1.30):
===
RCS file: /cvs/src/sys/dev/usb/upd.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- src/sys/dev/usb/upd.c 2021/03/08 14:35:57 1.29
+++ src/sys/dev/usb/upd.c 2021/08/06 17:46:45 1.30
@@ -1,4 +1,4 @@
-/* $OpenBSD: upd.c,v 1.29 2021/03/08 14:35:57 jcs Exp $ */
+/* $OpenBSD: upd.c,v 1.30 2021/08/06 17:46:45 abieber Exp $ */
/*
* Copyright (c) 2015 David Higgs
@@ -167,7 +167,7 @@
if (upd_lookup_usage_entry(desc, size,
upd_usage_roots + i, &item)) {
ret = UMATCH_VENDOR_PRODUCT;
- break;
+ uha->claimed[item.report_ID] = 1;
}
return (ret);
===
The uha.claimed array is allocated using uha.nreports as its size while
upd_match() is looping through the number of items of upd_usage_roots.
In my case uha.nreports is equal to zero so uha.claimed is null, hence
setting uha->claimed[n] is failing.
As I'm not familiar with the HID code I did not yet understood the
relation between upd_usage_roots and the claimed array but as we're
talking about UPS attached computers I though the issue would sensible
enough to make a quick reporting.
You'll find a dmesg with options UPD_DEBUG and UHIDEV_DEBUG set and the
following patch applied to circumvent the page fault and provide some debug:
===
RCS file: /home/cvs/src/sys/dev/usb/upd.c,v
retrieving revision 1.30
diff -u -p -r1.30 upd.c
--- upd.c 6 Aug 2021 17:46:45 - 1.30
+++ upd.c 24 Oct 2021 11:43:59 -
@@ -163,11 +163,18 @@ upd_match(struct device *parent, void *m
/* need at least one sensor from root of tree */
uhidev_get_report_desc(uha->parent, &desc, &size);
+
+ DPRINTF(("upd: nitems=%zu\n", nitems(upd_usage_roots)));
+ DPRINTF(("upd: nreports=%i\n", uha->nreports));
+
for (i = 0; i < nitems(upd_usage_roots); i++)
if (upd_lookup_usage_entry(desc, size,
upd_usage_roots + i, &item)) {
ret = UMATCH_VENDOR_PRODUCT;
- uha->claimed[item.report_ID] = 1;
+ DPRINTF(("upd: item.report_ID=%i\n", item.report_ID));
+ if (item.report_ID < uha->nreports) {
+ uha->claimed[item.report_ID] = 1;
+ }
}
return (ret);
===
OpenBSD 7.0-stable (UPD.MP) #5: Sun Oct 24 13:44:04 CEST 2021
damien@gageac.petrolan:/usr/src/sys/arch/amd64/compile/UPD.MP
real mem = 6283997184 (5992MB)
avail mem = 6077521920 (5795MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xc8889000 (57 entries)
bios0: vendor LENOVO version "R19ET36W (1.20 )" date 07/12/2021
bios0: LENOVO 20U70003FR
acpi0 at bios0: ACPI 6.3
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT IVRS SSDT MSDM BATB HPET APIC MCFG SBST WSMT
SSDT SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI SSDT SSDT
acpi0: wakeup devices GPP0(S4) GPP3(S4) GPP4(S4) GPP5(S4) GP17(S4) XHC0(S3)
XHC1(S3) GP19(S4) LID_(S4) SLPB(S3)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 5 4500U with Radeon Graphics, 2370.89 MHz, 17-60-01
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,IBRS,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
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 1 (application processor)
cpu1: AMD Ryzen 5 4500U with Radeon Graphics, 2370.55 MHz, 17-60-01
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,PAGE1G
Re: new option for rcctl ls
Le 22/10/2021 à 13:56, Stuart Henderson a écrit :
On 2021/10/22 12:20, Antoine Jacoutot wrote:
On Thu, Oct 21, 2021 at 04:45:47PM +0100, Stuart Henderson wrote:
Sometimes I find it useful to list daemons which are set to 'disabled'
but are actually running. Either those where I have started them by hand
forgotten to enable in rc.conf.local, or to check for services which
shouldn't be running but which are anyway. Any comments on this diff
to add it to rcctl? It's pretty much the opposite of "rcctl ls failed".
Hi.
I have never had a use for this, so I don't really have an opinion...
I am not super fan of the "off-but-started" option name though.
I hate the name but every other idea I had was worse :)
Hi!
Does "unattended" would fit ?
Index: rcctl.8
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
retrieving revision 1.37
diff -u -p -r1.37 rcctl.8
--- rcctl.8 26 Jun 2021 18:02:48 - 1.37
+++ rcctl.8 21 Oct 2021 15:42:13 -
@@ -36,7 +36,7 @@
.Nm rcctl
.Cm ls
.Sm off
-.Cm all | failed | on | off | started | stopped
+.Cm all | failed | on | off | started | stopped | off-but-started
.Sm on
.Sh DESCRIPTION
The
@@ -119,6 +119,8 @@ which can be one of:
all services and daemons
.It Cm failed
enabled but stopped daemons
+.It Cm off-but-started
+services and daemons which are disabled but currently running
.It Cm off
disabled services and daemons
.It Cm on
Index: rcctl.sh
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
retrieving revision 1.110
diff -u -p -r1.110 rcctl.sh
--- rcctl.sh27 Feb 2021 09:28:04 - 1.110
+++ rcctl.sh21 Oct 2021 15:42:13 -
@@ -35,7 +35,7 @@ usage()
"usage:rcctl get|getdef|set service | daemon [variable [arguments]]
rcctl [-df] ${_a} daemon ...
rcctl disable|enable|order [daemon ...]
- rcctl ls all|failed|off|on|started|stopped"
+ rcctl ls all|failed|off|on|started|stopped|off-but-started"
}
needs_root()
@@ -212,6 +212,13 @@ svc_ls()
echo ${_special_svcs} | tr "[:blank:]" "\n"
) | sort
;;
+ off-but-started)
+ for _svc in $(svc_ls off); do
+ ! svc_is_special ${_svc} && \
+ /etc/rc.d/${_svc} check >/dev/null && \
+ echo ${_svc} && _ret=1
+ done
+ ;;
failed)
for _svc in $(svc_ls on); do
! svc_is_special ${_svc} && \
@@ -502,7 +509,7 @@ ret=0
case ${action} in
ls)
lsarg=$2
- [[ ${lsarg} == @(all|failed|off|on|started|stopped) ]] || usage
+ [[ ${lsarg} ==
@(all|failed|off|on|started|stopped|off-but-started) ]] || usage
;;
order)
shift 1
--
Antoine
Re: use /dev/dri/ in xenocara
Le 18/02/2021 à 13:11, Jonathan Gray a écrit : On Thu, Feb 18, 2021 at 11:34:19AM +, Stuart Henderson wrote: On 2021/02/18 22:24, Jonathan Gray wrote: On Thu, Feb 18, 2021 at 12:01:28PM +0100, Mark Kettenis wrote: Date: Thu, 18 Feb 2021 21:18:51 +1100 From: Jonathan Gray I suspect that there are some ports that need to get their unveils updated if we do this. firefox ports were updated. Not aware of anything else in ports that unveils /dev/drm. unveils: not afaik others: gdm already handled it, some other ports will need patches changing: graphics/clutter/cogl/patches/patch-cogl_winsys_cogl-winsys-egl-kms_c graphics/waffle/patches/patch-src_waffle_gbm_wgbm_display_c x11/compton/patches/patch-src_compton_c x11/slim/patches/patch-slim_conf This is a display manager like xdm/gdm. The last upstream release was in 2013. I can patch it after the xenocara changes go in or perhaps we remove it as landry suggested in I am using slim on my children computers since many years now and it works very well. This could explain why there is nothing done upstream: no bug, no fix and features are already there. revision 1.55 date: 2020/07/24 05:41:37; author: landry; state: Exp; lines: +2 -3; commitid: yb1SZfwKZuXceEq0; Drop maintainership, i havent used slim in ages. Anyway it's more or less dead upstream since 7 years, which doesnt look good for a login manager.. candidate for removal ? xenodm works ootb, and is customizable once you grok X properties.. x11/picom/patches/patch-src_vsync_c /dev/drm will stay for now so the others can be updated later.
Re: Destructive Install Process (fdisk)
Le 25/06/2020 à 22:41, David Blevins a écrit : List, Apologies, I left HTML mode enabled on my web client. I understand that a Linux dmesg is probably not very useful. I can provide a different set of system information (or an OpenBSD dmesg from an MBR boot) but I'm not sure what set of information would be most useful in determining my issue regarding GPT boot on this particular system. Hi David, In order to use GPT you need a BIOS that supports it. In most of the cases, this means an UEFI BIOS. Concerning multiboot: - Using MBR, you have a plethora of boot managers that will work. You just need to select "edit" in the installer instead of "whole" to keep existing partitions. - Using GPT/EFI, there is less options but I'd recommend rEFInd. You also have to edit partition table if you want to keep the existing partitions. In both cases, a system upgrade of one of the OS present on the disk could result in a modified boot sequence (OpenBSD will overwrite UEFI boot loaders at each upgrade, Windows is well known to set itself as default boot at install, ..). If you setup a multiboot don't expect any help from OpenBSD, you are on your own. Regards, Damien
Re: Marvell 88SE9215 controller
Le 24/04/2020 à 11:31, Damien Couderc a écrit : Hi guys, The following diff is adding the Marvell 88SE9215 SATA controller to the PCI devices. Hi, Nobody to look at this? === --- pcidevs.orig Thu Apr 23 11:44:53 2020 +++ pcidevs Thu Apr 23 14:15:18 2020 @@ -5922,6 +5922,7 @@ product MARVELL2 88SE9125 0x9125 88SE9125 SATA product MARVELL2 88SE9128 0x9128 88SE9128 AHCI product MARVELL2 88SE9172 0x9172 88SE9172 SATA +product MARVELL2 88SE9215 0x9215 88SE9215 AHCI product MARVELL2 88SE9230 0x9230 88SE9230 AHCI /* Matrox products */ === Resulting dmesg is following. Both files can also be found attached to this mail. OpenBSD 6.7-beta (GENERIC.MP) #1: Fri Apr 24 11:17:17 CEST 2020 damien@current.petrolan:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34271739904 (32684MB) avail mem = 33220456448 (31681MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe94f0 (31 entries) bios0: vendor American Megatrends Inc. version "P1.80" date 12/18/2018 bios0: ASRock B450 Gaming K4 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT CRAT CDIT SSDT MCFG AAFT HPET SSDT UEFI IVRS SSDT SSDT WSMT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) GPPF(S4) GP17(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 2700 Eight-Core Processor, 3194.62 MHz, 17-08-02 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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way 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 1 (application processor) cpu1: AMD Ryzen 7 2700 Eight-Core Processor, 3194.00 MHz, 17-08-02 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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way 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 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 7 2700 Eight-Core Processor, 3194.00 MHz, 17-08-02 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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way 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 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 7 2700 Eight-Core Processor, 3194.00 MHz, 17-08-02 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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
Re: Audio over hdmi
Le 01/05/2020 à 17:30, Stuart Henderson a écrit : On 2020/05/01 17:16, Damien Couderc wrote: Le 01/05/2020 à 15:01, Mark Kettenis a écrit : Date: Fri, 1 May 2020 14:17:56 +0200 From: Alexandre Ratchov On Fri, May 01, 2020 at 01:11:16PM +0200, Damien Couderc wrote: Speaking of the hdmi-only devices that were disabled in 2009: does the project still stand on this position in 2020? I made a quick search and it seems that more than half of the screens are audio capable now. I understand the defaults back in 2009, but now is it still true? There's nothing wrong with hdmi-only devices. As long as audio works by default with no tweaks, nobody will object to re-enabling them. AFAIK, this was the only reason to disable them. Right. The main issue was that by default we only send output to audio0. On many machines the audio device associated with the HDMI port appears before the audio device that is associated with the speakers and/or headphone jack on our laptops. Therefore by default audio would go to an unconnected HDMI. Just enabling digital-only devices would not work. There are a couple things we could do here. 1. Make sndiod(8) responsible for picking a default output device. I thought it was the case with the -f and -F options: -F device Specify an alternate device to use. If it doesn't work, the one given with the last -f or -F options will be used. For instance, specifying a USB device following a PCI device allows sndiod to use the USB one preferably when it's connected and to fall back to the PCI one when it's disconnected. -f device Add this sndio(7) audio device to devices used for playing and/or recording. Preceding per-device options (-aberwz) apply to this device. Sub-devices (-s) that are applied after will be attached to this device. Device mode and parameters are determined from sub-devices attached to it. So if I'm not wrong it could be possible to set the -f option with the analog device and the -F option with the digital-only one. These flags are to cope with a new audio device connected at runtime, for example so you can set it to use audio1 if the device is available, otherwise use audio0. The problem with HDMI audio is that the device *is* available but the output often doesn't go anywhere. This mechanism doesn't help that case. It's possible to sense it the HDMI is connected or not like what you can see with mixerctl: outputs.digital-out_sou=dac-0:1 outputs.digital-out2_so=dac-2:3 outputs.digital-out3_so=dac-4:5 outputs.digital-out4_so=dac-6:7 outputs.digital-out5_so=dac-8:9 outputs.digital-out6_so=dac-10:11 outputs.digital-out_sen=plugged outputs.digital-out2_se=unplugged outputs.digital-out3_se=unplugged outputs.digital-out4_se=unplugged outputs.digital-out5_se=unplugged outputs.digital-out6_se=unplugged record.enable=sysctl In this case, the digital-out sensor is plugged. That said, I tried my proposition and it's not working. I suspect it's related to the fact that the digital-out sensor is not checked or something related. Regards, Damien
Re: patch: Enable dock audio on Thinkpad dock (Thinkpad L460)
Le 01/05/2020 à 18:04, Damien Couderc a écrit : Le 01/05/2020 à 17:42, Abel Abraham Camarillo Ojeda a écrit : On Friday, May 1, 2020, Damien Couderc <mailto:open...@petrocore.eu>> wrote: On 27/04/2020 15:19, Abel Abraham Camarillo Ojeda wrote: The following enables audio via the dock station port in my thinkpad L460. But, anyone knows if its possible to automatically disable the laptop speaker when I plug in the audio port in the dock? it doesn't appear to have a *_sense, ideas? this also enables the annoying beep (echo -e "\a"; in console) patch inline and attached: Hi, comments, oks? Anyone? Hi, any ok, comments? Hi Abel, Thanks for your diff. Please add an applicable diff inline in your mail next time and don't attach it. Thanks Jan, I attached and inlined the diff because gmail and diff mangling ... Thanks for review Tested OK after adding support for my T560. Here is the resulting diff : --- azalia_codec.c.orig Fri May 1 11:54:57 2020 +++ azalia_codec.c Fri May 1 12:45:17 2020 @@ -159,6 +159,19 @@ this->subid == 0x503c17aa) this->qrks |= AZ_QRK_WID_TPDOCK2; break; + case 0x10ec0293: + this->name = "Realtek ALC293"; + this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D; + + /* + * Enable dock audio on Thinkpad docks + * 0x17aa : 0x2231 = Thinkpad T560 + * 0x17aa : 0x5051 = Thinkpad L460 + */ + if (this->subid == 0X223117aa || + this->subid == 0x505117aa) + this->qrks |= AZ_QRK_WID_TPDOCK2; + break; case 0x10ec0298: this->name = "Realtek ALC298"; if (this->subid == 0x320019e5 || That said, I suspect that other Thinkpad models like the 560p (0x5050) should also be added to the list. Thanks for review, looking at those files history it seems like new models are only added if some developer can try the hardware (which seems reasonable). But it would be nice if we can also add more models, I have also a thinkpad L470 From what I have seen, the T470 is using ALC296 instead of ALC283. I'm afraid it's the same for L470. I meant ACL293 instead of 283. But T460 (0x5053) and T560p (0x5050) are ALC293. Regards, Damien
Re: patch: Enable dock audio on Thinkpad dock (Thinkpad L460)
Le 01/05/2020 à 17:42, Abel Abraham Camarillo Ojeda a écrit : On Friday, May 1, 2020, Damien Couderc <mailto:open...@petrocore.eu>> wrote: On 27/04/2020 15:19, Abel Abraham Camarillo Ojeda wrote: The following enables audio via the dock station port in my thinkpad L460. But, anyone knows if its possible to automatically disable the laptop speaker when I plug in the audio port in the dock? it doesn't appear to have a *_sense, ideas? this also enables the annoying beep (echo -e "\a"; in console) patch inline and attached: Hi, comments, oks? Anyone? Hi, any ok, comments? Hi Abel, Thanks for your diff. Please add an applicable diff inline in your mail next time and don't attach it. Thanks Jan, I attached and inlined the diff because gmail and diff mangling ... Thanks for review Tested OK after adding support for my T560. Here is the resulting diff : --- azalia_codec.c.orig Fri May 1 11:54:57 2020 +++ azalia_codec.c Fri May 1 12:45:17 2020 @@ -159,6 +159,19 @@ this->subid == 0x503c17aa) this->qrks |= AZ_QRK_WID_TPDOCK2; break; + case 0x10ec0293: + this->name = "Realtek ALC293"; + this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D; + + /* + * Enable dock audio on Thinkpad docks + * 0x17aa : 0x2231 = Thinkpad T560 + * 0x17aa : 0x5051 = Thinkpad L460 + */ + if (this->subid == 0X223117aa || + this->subid == 0x505117aa) + this->qrks |= AZ_QRK_WID_TPDOCK2; + break; case 0x10ec0298: this->name = "Realtek ALC298"; if (this->subid == 0x320019e5 || That said, I suspect that other Thinkpad models like the 560p (0x5050) should also be added to the list. Thanks for review, looking at those files history it seems like new models are only added if some developer can try the hardware (which seems reasonable). But it would be nice if we can also add more models, I have also a thinkpad L470 From what I have seen, the T470 is using ALC296 instead of ALC283. I'm afraid it's the same for L470. But T460 (0x5053) and T560p (0x5050) are ALC293. Regards, Damien
Re: Audio over hdmi
Le 01/05/2020 à 15:01, Mark Kettenis a écrit : Date: Fri, 1 May 2020 14:17:56 +0200 From: Alexandre Ratchov On Fri, May 01, 2020 at 01:11:16PM +0200, Damien Couderc wrote: Speaking of the hdmi-only devices that were disabled in 2009: does the project still stand on this position in 2020? I made a quick search and it seems that more than half of the screens are audio capable now. I understand the defaults back in 2009, but now is it still true? There's nothing wrong with hdmi-only devices. As long as audio works by default with no tweaks, nobody will object to re-enabling them. AFAIK, this was the only reason to disable them. Right. The main issue was that by default we only send output to audio0. On many machines the audio device associated with the HDMI port appears before the audio device that is associated with the speakers and/or headphone jack on our laptops. Therefore by default audio would go to an unconnected HDMI. Just enabling digital-only devices would not work. There are a couple things we could do here. 1. Make sndiod(8) responsible for picking a default output device. I thought it was the case with the -f and -F options: -F device Specify an alternate device to use. If it doesn't work, the one given with the last -f or -F options will be used. For instance, specifying a USB device following a PCI device allows sndiod to use the USB one preferably when it's connected and to fall back to the PCI one when it's disconnected. -f device Add this sndio(7) audio device to devices used for playing and/or recording. Preceding per-device options (-aberwz) apply to this device. Sub-devices (-s) that are applied after will be attached to this device. Device mode and parameters are determined from sub-devices attached to it. So if I'm not wrong it could be possible to set the -f option with the analog device and the -F option with the digital-only one. That said, it would work only if you have two audio device (e.g. HDMI from video card as audio0 and analog from soundcard as audio1). This is not true on Thinkpad laptops for example because they have two output codecs on the same device for both analog and digital (and only one is kept actually). Maybe we could make first analog and first digital codec available on each audio device. Then sndiod would take the first analog and the first digital from the devices in the given order. Does it sound sane? 2. Use locators (like I did for drm(4) and wsdisplay(4)) such that audio0 is always the non-HDMI audio device. Option #2 has the downside that if your HDMI audio device is the only supported audio device in the system, it will still be audio1 and therefore not the default device. On the other hand that has the benefit that if you later plug something like uaudio(4) into your system it will become the default device. Option #1 would give us more flexibility, but I'm not sure if the current audio(4) ioctls allow us to implement the proper heuristics. About the multi-codec devices, how do you see it ? Keeping all the codecs and adding a knob to switch between analog and digital to select the codec > This seems to make sense. It's never entirely clear to me what exactly a "codec" is. But if it is possible to use both codecs simultaniously and indipendently, it would make sense to provide audio(4) devices for both.
Re: Default device in audioctl and mixerctl
Le 01/05/2020 à 14:51, Alexandre Ratchov a écrit :
On Fri, May 01, 2020 at 01:34:54PM +0200, Damien Couderc wrote:
Hi,
I noticed that audioctl and mixerctl both use /dev/audioctl0 as a default
since the reimplementation of the new api.
Shouldn't it use the /dev/audioctl link instead to permit choosing which
device we want as the default?
There's no audioctl symlink anymore, it was removed few years ago.
Oops! I missed that one.
The default device is the one set with sndiod_flags, this way the same
device is used to play, record and volume control.
{audio,mixerctl}ctl are lower layer tools which are no longer for
everyday use and don't participate to the default device logic
Ok I got it, sorry for the noise.
Regards,
Damien
Default device in audioctl and mixerctl
Hi,
I noticed that audioctl and mixerctl both use /dev/audioctl0 as a
default since the reimplementation of the new api.
Shouldn't it use the /dev/audioctl link instead to permit choosing which
device we want as the default?
--- audioctl.c.orig Fri May 1 13:29:01 2020
+++ audioctl.c Fri May 1 13:29:30 2020
@@ -260,7 +260,7 @@
int
main(int argc, char **argv)
{
- char *path = "/dev/audioctl0";
+ char *path = "/dev/audioctl";
int c;
while ((c = getopt(argc, argv, "anf:q")) != -1) {
--- mixerctl.c.orig Sat Apr 25 14:17:30 2020
+++ mixerctl.c Fri May 1 13:20:33 2020
@@ -249,7 +249,7 @@
int ndev;
if ((file = getenv("MIXERDEVICE")) == 0 || *file == '\0')
- file = "/dev/audioctl0";
+ file = "/dev/audioctl";
while ((ch = getopt(argc, argv, "af:nqtvw")) != -1) {
switch (ch) {
Regards,
Damien
Re: patch: Enable dock audio on Thinkpad dock (Thinkpad L460)
On 27/04/2020 15:19, Abel Abraham Camarillo Ojeda wrote: The following enables audio via the dock station port in my thinkpad L460. But, anyone knows if its possible to automatically disable the laptop speaker when I plug in the audio port in the dock? it doesn't appear to have a *_sense, ideas? this also enables the annoying beep (echo -e "\a"; in console) patch inline and attached: Hi, comments, oks? Anyone? Hi, any ok, comments? Hi Abel, Thanks for your diff. Please add an applicable diff inline in your mail next time and don't attach it. Thanks Jan, I attached and inlined the diff because gmail and diff mangling ... Thanks for review Tested OK after adding support for my T560. Here is the resulting diff : --- azalia_codec.c.orig Fri May 1 11:54:57 2020 +++ azalia_codec.c Fri May 1 12:45:17 2020 @@ -159,6 +159,19 @@ this->subid == 0x503c17aa) this->qrks |= AZ_QRK_WID_TPDOCK2; break; + case 0x10ec0293: + this->name = "Realtek ALC293"; + this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D; + + /* + * Enable dock audio on Thinkpad docks + * 0x17aa : 0x2231 = Thinkpad T560 + * 0x17aa : 0x5051 = Thinkpad L460 + */ + if (this->subid == 0X223117aa || + this->subid == 0x505117aa) + this->qrks |= AZ_QRK_WID_TPDOCK2; + break; case 0x10ec0298: this->name = "Realtek ALC298"; if (this->subid == 0x320019e5 || That said, I suspect that other Thinkpad models like the 560p (0x5050) should also be added to the list. I can't test the diff with the right hardware. But, the patch applies, builds and doesn't break audio on my ThinkPad X1C6. The diff also looks fine for me. bye, Jan Index: azalia_codec.c === RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v retrieving revision 1.178 diff -u -p -r1.178 azalia_codec.c --- azalia_codec.c 14 Oct 2019 02:04:35 - 1.178 +++ azalia_codec.c 27 Apr 2020 07:42:45 - @@ -159,6 +159,17 @@ azalia_codec_init_vtbl(codec_t *this) this->subid == 0x503c17aa) this->qrks |= AZ_QRK_WID_TPDOCK2; break; + case 0x10ec0293: + this->name = "Realtek ALC293"; + this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D; + + /* + * Enable dock audio on Thinkpad docks + * 0x17aa : 0x5051 = Thinkpad L460 + */ + if (this->subid == 0x505117aa) + this->qrks |= AZ_QRK_WID_TPDOCK2; + break; case 0x10ec0298: this->name = "Realtek ALC298"; if (this->subid == 0x320019e5 ||
Re: Audio over hdmi
On 26/04/2020 06:58, Alexandre Ratchov wrote: On Sat, Apr 25, 2020 at 05:16:03PM +0200, Damien Couderc wrote: I can see in the full dmesg that there are two different FTYPE results provided during azalia_codec_init and only the first one seems to be displayed in the mixerctl output. I think that maybe mixerctl does not recurse all the audio functions or that some bits aren't recorded. I'll take a look. Ok, I did a bit of reading and from what I understood there are 2 detected codecs (0 and 2) for the same instance of azalia but the latest is deleted in azalia_init_codecs() because there is only one that can be enabled. Alexandre could maybe tell us what is possible to do here. I think it's maybe possible to keep all detected codecs but to change which one is enabled. Hi, Sorry couldn't test your diff, my machines have one codec only. The azalia driver can handle only one codec at a time. Multiple codecs can't be presented as different devices because they can't be used at the same time. Quickly adding support for multiple codecs would need to expose "mixer" controls of all the codecs and the ability to switch between them. This may look difficult but in most (all?) real-world cases there is at most 1 analog and 1 digital codec and the latter has very few controls, if any. Independenty, support for the hdmi-only devices, present on certain graphics cards was removed as they were not useful, but used to attach as audio0, i.e. they took the place of the default audio device, which made audio not work by default. But this is not related to your patch. HTH Thank you Alexandre. Speaking of the hdmi-only devices that were disabled in 2009: does the project still stand on this position in 2020? I made a quick search and it seems that more than half of the screens are audio capable now. I understand the defaults back in 2009, but now is it still true? About the multi-codec devices, how do you see it ? Keeping all the codecs and adding a knob to switch between analog and digital to select the codec ? Regards, Damien
Re: Audio over hdmi
Le 25/04/2020 à 13:33, Damien Couderc a écrit :
Le 25/04/2020 à 12:33, Damien Couderc a écrit :
Le 25/04/2020 à 12:13, Solene Rapenne a écrit :
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc a écrit :
Hi,
I decided to take a look at what was missing to make audio over hdmi
working on OpenBSD.
After enabling AZALIA_DEBUG in the kernel config I commented the code
that disables HDMI codecs like the following :
--- azalia.c.orig Thu Apr 23 11:44:52 2020
+++ azalia.c Fri Apr 24 12:53:15 2020
@@ -926,9 +926,11 @@
c = -1;
for (i = 0; i < az->ncodecs; i++) {
codec = &az->codecs[i];
+/*
if ((codec->audiofunc < 0) ||
(codec->codec_type == AZ_CODEC_TYPE_HDMI))
continue;
+*/
if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
if (c < 0)
c = i;
And after rebooting with the modified kernel audio over HDMI was
working out of the box (see the following diff).
I suspect that it is pure luck, what could I miss ?
Could someone test it on Intel based computers ?
hello,
I tried your diff but I'm not sure how to play sound on the screen.
From the FAQ i changed sndiod default output device
# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod
but if I run aucat I get the error "default: couldn't open audio device"
Hi solene,
I don't think you need to change sndiod's settings as your device is
already audio0.
That said, I think the Intel audio chip has at least 3 outputs on your
laptop: headphones, speakers and HDMI. And the trick must be to set
the HDMI as default.
Could you show me your mixerctl output ?
Ok so I upgraded my laptop to current and connected it to the same audio
capable screen.
I can see in the dmesg the following (full dmesg provided at the end):
azalia0: unknown03
wcap=40778d
cap=994
[01/00] color=unknown device=digital-out conn=jack conntype=digital
location=spec1 chassis=internal special=hdmi
outamp: mute=1 size=0 steps=0 offset=0
connections=0x2; selected=0x2
azalia_codec_sort_pins: analog out pins:
azalia_codec_sort_pins: digital out pins: 0x03->0x02
azalia_codec_sort_pins: analog in pins:
azalia_codec_sort_pins: digital in pins:
azalia0: dacgroup[0]: 02
azalia0: codecs: Realtek/0x0293, Intel/0x2809, using Realtek/0x0293
audio0 at azalia0
The problem is that outputs.digital-out is not displayed by mixerctl :
inputs.dac-2:3=126,126
inputs.dac-0:1=126,126
record.adc-0:1_mute=off
record.adc-0:1=124,124
record.adc-2:3_mute=off
record.adc-2:3=124,124
record.adc-4:5_mute=off
record.adc-4:5=124,124
inputs.mix_source=mic2
inputs.mix_mic2=120,120
inputs.mix2_source=dac-2:3,mix
inputs.mix3_source=dac-0:1,mix
inputs.mic=85,85
outputs.spkr_source=mix2
outputs.spkr_mute=off
outputs.spkr_eapd=on
outputs.hp_source=mix3
outputs.hp_mute=off
outputs.hp_boost=off
outputs.hp_eapd=on
inputs.mic2=85,85
outputs.mic2_dir=input-vr80
record.adc-4:5_source=mic2
record.adc-2:3_source=mic2
record.adc-0:1_source=mic
outputs.hp_sense=unplugged
outputs.mic2_sense=unplugged
outputs.spkr_muters=hp
outputs.master=126,126
outputs.master.mute=off
outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp
record.volume=124,124
record.volume.mute=off
record.volume.slaves=adc-0:1,adc-2:3,adc-4:5
record.enable=sysctl
I can see in the full dmesg that there are two different FTYPE results
provided during azalia_codec_init and only the first one seems to be
displayed in the mixerctl output.
I think that maybe mixerctl does not recurse all the audio functions or
that some bits aren't recorded. I'll take a look.
Ok, I did a bit of reading and from what I understood there are 2
detected codecs (0 and 2) for the same instance of azalia but the latest
is deleted in azalia_init_codecs() because there is only one that can be
enabled.
Alexandre could maybe tell us what is possible to do here. I think it's
maybe possible to keep all detected codecs but to change which one is
enabled.
Re: Audio over hdmi
Le 25/04/2020 à 12:33, Damien Couderc a écrit :
Le 25/04/2020 à 12:13, Solene Rapenne a écrit :
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc a écrit :
Hi,
I decided to take a look at what was missing to make audio over hdmi
working on OpenBSD.
After enabling AZALIA_DEBUG in the kernel config I commented the code
that disables HDMI codecs like the following :
--- azalia.c.orig Thu Apr 23 11:44:52 2020
+++ azalia.c Fri Apr 24 12:53:15 2020
@@ -926,9 +926,11 @@
c = -1;
for (i = 0; i < az->ncodecs; i++) {
codec = &az->codecs[i];
+/*
if ((codec->audiofunc < 0) ||
(codec->codec_type == AZ_CODEC_TYPE_HDMI))
continue;
+*/
if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
if (c < 0)
c = i;
And after rebooting with the modified kernel audio over HDMI was
working out of the box (see the following diff).
I suspect that it is pure luck, what could I miss ?
Could someone test it on Intel based computers ?
hello,
I tried your diff but I'm not sure how to play sound on the screen.
From the FAQ i changed sndiod default output device
# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod
but if I run aucat I get the error "default: couldn't open audio device"
Hi solene,
I don't think you need to change sndiod's settings as your device is
already audio0.
That said, I think the Intel audio chip has at least 3 outputs on your
laptop: headphones, speakers and HDMI. And the trick must be to set the
HDMI as default.
Could you show me your mixerctl output ?
Ok so I upgraded my laptop to current and connected it to the same audio
capable screen.
I can see in the dmesg the following (full dmesg provided at the end):
azalia0: unknown03
wcap=40778d
cap=994
[01/00] color=unknown device=digital-out conn=jack conntype=digital
location=spec1 chassis=internal special=hdmi
outamp: mute=1 size=0 steps=0 offset=0
connections=0x2; selected=0x2
azalia_codec_sort_pins: analog out pins:
azalia_codec_sort_pins: digital out pins: 0x03->0x02
azalia_codec_sort_pins: analog in pins:
azalia_codec_sort_pins: digital in pins:
azalia0: dacgroup[0]: 02
azalia0: codecs: Realtek/0x0293, Intel/0x2809, using Realtek/0x0293
audio0 at azalia0
The problem is that outputs.digital-out is not displayed by mixerctl :
inputs.dac-2:3=126,126
inputs.dac-0:1=126,126
record.adc-0:1_mute=off
record.adc-0:1=124,124
record.adc-2:3_mute=off
record.adc-2:3=124,124
record.adc-4:5_mute=off
record.adc-4:5=124,124
inputs.mix_source=mic2
inputs.mix_mic2=120,120
inputs.mix2_source=dac-2:3,mix
inputs.mix3_source=dac-0:1,mix
inputs.mic=85,85
outputs.spkr_source=mix2
outputs.spkr_mute=off
outputs.spkr_eapd=on
outputs.hp_source=mix3
outputs.hp_mute=off
outputs.hp_boost=off
outputs.hp_eapd=on
inputs.mic2=85,85
outputs.mic2_dir=input-vr80
record.adc-4:5_source=mic2
record.adc-2:3_source=mic2
record.adc-0:1_source=mic
outputs.hp_sense=unplugged
outputs.mic2_sense=unplugged
outputs.spkr_muters=hp
outputs.master=126,126
outputs.master.mute=off
outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp
record.volume=124,124
record.volume.mute=off
record.volume.slaves=adc-0:1,adc-2:3,adc-4:5
record.enable=sysctl
I can see in the full dmesg that there are two different FTYPE results
provided during azalia_codec_init and only the first one seems to be
displayed in the mixerctl output.
I think that maybe mixerctl does not recurse all the audio functions or
that some bits aren't recorded. I'll take a look.
Here is the full dmesg:
OpenBSD 6.7-beta (GENERIC.MP) #3: Fri Apr 24 12:53:39 CEST 2020
damien@current.petrolan:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17012170752 (16224MB)
avail mem = 16483958784 (15720MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xd7082000 (65 entries)
bios0: vendor LENOVO version "N1KET41W (1.28 )" date 09/12/2018
bios0: LENOVO 20FH001FFR
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA SSDT UEFI SSDT SSDT ECDT HPET APIC MCFG
SSDT DBGP DBG2 BOOT BATB SLIC SSDT SSDT MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2195.76 MHz, 06-4e-03
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,I
Re: Audio over hdmi
Le 25/04/2020 à 12:13, Solene Rapenne a écrit :
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc a écrit :
Hi,
I decided to take a look at what was missing to make audio over hdmi
working on OpenBSD.
After enabling AZALIA_DEBUG in the kernel config I commented the code
that disables HDMI codecs like the following :
--- azalia.c.orig Thu Apr 23 11:44:52 2020
+++ azalia.cFri Apr 24 12:53:15 2020
@@ -926,9 +926,11 @@
c = -1;
for (i = 0; i < az->ncodecs; i++) {
codec = &az->codecs[i];
+/*
if ((codec->audiofunc < 0) ||
(codec->codec_type == AZ_CODEC_TYPE_HDMI))
continue;
+*/
if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
if (c < 0)
c = i;
And after rebooting with the modified kernel audio over HDMI was
working out of the box (see the following diff).
I suspect that it is pure luck, what could I miss ?
Could someone test it on Intel based computers ?
hello,
I tried your diff but I'm not sure how to play sound on the screen.
From the FAQ i changed sndiod default output device
# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod
but if I run aucat I get the error "default: couldn't open audio device"
Hi solene,
I don't think you need to change sndiod's settings as your device is
already audio0.
That said, I think the Intel audio chip has at least 3 outputs on your
laptop: headphones, speakers and HDMI. And the trick must be to set the
HDMI as default.
Could you show me your mixerctl output ?
Regards,
Damien
dmesg
OpenBSD 6.7-beta (GENERIC.MP) #0: Sat Apr 25 12:02:14 CEST 2020
solene@solene.perso.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8323534848 (7937MB)
avail mem = 8058654720 (7685MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xaf07e000 (63 entries)
bios0: vendor LENOVO version "N24ET51W (1.26 )" date 08/30/2019
bios0: LENOVO 20L5CTO1WW
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT
SSDT SSDT BOOT BATB SLIC SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM
DMAR ASF! FPDT UEFI BGRT
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4)
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4)
RP06(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.82 MHz, 06-8e-0a
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz,
Audio over hdmi
Hi,
I decided to take a look at what was missing to make audio over hdmi
working on OpenBSD.
After enabling AZALIA_DEBUG in the kernel config I commented the code
that disables HDMI codecs like the following :
--- azalia.c.orig Thu Apr 23 11:44:52 2020
+++ azalia.cFri Apr 24 12:53:15 2020
@@ -926,9 +926,11 @@
c = -1;
for (i = 0; i < az->ncodecs; i++) {
codec = &az->codecs[i];
+/*
if ((codec->audiofunc < 0) ||
(codec->codec_type == AZ_CODEC_TYPE_HDMI))
continue;
+*/
if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
if (c < 0)
c = i;
And after rebooting with the modified kernel audio over HDMI was working
out of the box (see the following diff).
I suspect that it is pure luck, what could I miss ?
Could someone test it on Intel based computers ?
Here is the promised dmesg :
OpenBSD 6.7-beta (GENERIC.MP) #3: Fri Apr 24 12:53:39 CEST 2020
damien@current.petrolan:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34271739904 (32684MB)
avail mem = 33220448256 (31681MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe94f0 (31 entries)
bios0: vendor American Megatrends Inc. version "P1.80" date 12/18/2018
bios0: ASRock B450 Gaming K4
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT CRAT CDIT SSDT MCFG
AAFT HPET SSDT UEFI IVRS SSDT SSDT WSMT
acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4)
GPP6(S4) GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4)
GPPE(S4) GPPF(S4) GP17(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 2700 Eight-Core Processor, 3194.61 MHz, 17-08-02
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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way 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 1 (application processor)
cpu1: AMD Ryzen 7 2700 Eight-Core Processor, 3194.00 MHz, 17-08-02
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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way 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 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Ryzen 7 2700 Eight-Core Processor, 3194.01 MHz, 17-08-02
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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way 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 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Ryzen 7 2700 Eight-Core Processor, 3194.00 MHz, 17-08-02
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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAI
Marvell 88SE9215 controller
Hi guys, The following diff is adding the Marvell 88SE9215 SATA controller to the PCI devices. === --- pcidevs.origThu Apr 23 11:44:53 2020 +++ pcidevs Thu Apr 23 14:15:18 2020 @@ -5922,6 +5922,7 @@ product MARVELL2 88SE9125 0x9125 88SE9125 SATA product MARVELL2 88SE9128 0x9128 88SE9128 AHCI product MARVELL2 88SE9172 0x9172 88SE9172 SATA +product MARVELL2 88SE9215 0x9215 88SE9215 AHCI product MARVELL2 88SE9230 0x9230 88SE9230 AHCI /* Matrox products */ === Resulting dmesg is following. Both files can also be found attached to this mail. OpenBSD 6.7-beta (GENERIC.MP) #1: Fri Apr 24 11:17:17 CEST 2020 damien@current.petrolan:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34271739904 (32684MB) avail mem = 33220456448 (31681MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe94f0 (31 entries) bios0: vendor American Megatrends Inc. version "P1.80" date 12/18/2018 bios0: ASRock B450 Gaming K4 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT CRAT CDIT SSDT MCFG AAFT HPET SSDT UEFI IVRS SSDT SSDT WSMT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) GPPF(S4) GP17(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 2700 Eight-Core Processor, 3194.62 MHz, 17-08-02 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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way 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 1 (application processor) cpu1: AMD Ryzen 7 2700 Eight-Core Processor, 3194.00 MHz, 17-08-02 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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way 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 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 7 2700 Eight-Core Processor, 3194.00 MHz, 17-08-02 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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way 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 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 7 2700 Eight-Core Processor, 3194.00 MHz, 17-08-02 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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu3: ITLB 64 4KB entries fully as
