Re: new USB audio class v2.0 driver
On 31-12-18 16:58, Alexandre Ratchov wrote: Hi, Here's a new driver for both USB audio class (UAC) v1.0 and v2.0 devices, it would replace the current one. It focuses on reliability and proper synchronization, including in low-latency configurations. Our current USB sub-system has limitations that currently allow only the following combinations: - USB v2 devices on ehci(4) only - USB v1 devices on uhci(4), ohci(4) or ehci(4) root hub only If you have an audio device that is class compliant (aka vendor claims it's "driverless" on MacOS) *and* one of the above host/hub/device combinations then I'd be very interested in test reports. Especially I'd like to know about possible regressions. To test, apply this diff, rebuild the kernel and set: sndiod_flags=-f rsnd/1 in /etc/rc.conf.local (assuming your uaudio device shows as uaudio1 in dmesg). Then do your regular audio work, let me know how it works and send me output of: dmesg mixerctl -v -f /dev/mixer1 If something is broken, please check if this is a regression. Hi Alexandre, Sorry for being late to the party. With this patch audio playback with my Schiit Bifrost DAC works, however I get an error with the output of mixerctl. This DAC didn't work before. Please see dmesg and mixerctl output below. Kind regards, Martijn Rijkeboer dmesg = OpenBSD 6.4-current (GENERIC.MP) #0: Sat Jan 5 17:39:01 CET 2019 r...@jukebox.bunix.org:/sys/arch/amd64/compile/GENERIC.MP real mem = 1987788800 (1895MB) avail mem = 1918291968 (1829MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe0010 (44 entries) bios0: vendor LENOVO version "6JET65WW (1.23 )" date 10/19/2009 bios0: LENOVO 28477LG acpi0 at bios0: rev 4 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET MCFG APIC BOOT SLIC SSDT SSDT SSDT acpi0: wakeup devices P0P2(S4) P0P1(S4) USB0(S3) USB1(S3) USB2(S3) USBR(S3) EHC1(S3) USB3(S3) USB4(S3) USB5(S3) EHC2(S3) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz, 2095.05 MHz, 06-17-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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 2MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 241MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz, 2534.66 MHz, 06-17-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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 2MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P2) acpiprt2 at acpi0: bus 9 (P0P1) acpiprt3 at acpi0: bus 2 (RP01) acpiprt4 at acpi0: bus 3 (RP02) acpiprt5 at acpi0: bus 4 (RP03) acpiprt6 at acpi0: bus 5 (RP04) acpiprt7 at acpi0: bus 6 (RP05) acpiprt8 at acpi0: bus 8 (RP06) acpiec0 at acpi0 acpicpu0 at acpi0: !C2(100@57 mwait.3@0x30), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C2(100@57 mwait.3@0x30), C1(1000@1 mwait.1), PSS acpitz0 at acpi0: critical temperature is 105 degC acpipci0 at acpi0 PCI0: _OSC failed acpicmos0 at acpi0 acpithinkpad0 at acpi0 acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT1 model "42T4763" serial 5901 type LION oem "SANYO" acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PWRB acpibtn2 at acpi0: SLPB "PNP0C14" at acpi0 not configured acpivideo0 at acpi0: VGA_ acpivideo1 at acpi0: GFX0 acpivout0 at acpivideo1: DD03 cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2101, 2100, 1600, 1200 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07 inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0: msi inteldrm0: 1366x768, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 2 int 16 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 2 int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" re
Re: Implement VFS read clustering for MSDOSFS, third try
On 08/15/17 17:20, Stefan Fritsch wrote: > Hi, > > this is another try at making read clustering work for msdosfs. > > Last year, mpi@ implemented VFS read clustering for MSDOSFS in > > sys/msdosfs/denode.h 1.28 > sys/msdosfs/msdosfs_vnops.c 1.105 > > This caused regressions when doing seeks past the end of the file and had. > to be reverted. Then I tried to fix that in > > denode.h,v 1.31 > msdosfs_vnops.c,v 1.114 > > But that caused different problems and had to be reverted, too. I have > another test for that that I will commit soon. > > It seems that while netbsd uses DEV_BSIZE as base for the logical block > numbers even in files, openbsd is more like freebsd and uses > mnt_stat.f_iosize in that case. However, if the file system does accesses > for metadata on the disk, it has to use DEV_BSIZE for accesses. So the > fixes in 1.31/1.114 were wrong and the following diff is again based on > 1.28/1.105 with some fixes in extendfile() to make seeks past the end of > the file work. > > > Testers/reviews/OKs welcome. Especially people who need msdosfs for > booting via uefi. In any case, I won't commit until I get home again in a > week. > > If my analysis with the block sizes is correct, I will add some > clarifications to the bread/bwrite man page later. Since I was the one who raised the second problem [0], I tried this patch and everything seems to work fine. When I copy a binary file on a msdos (uefi) partition (running the kernel with the patch) the checksum remains the same: # cp refind_x64.efi bootx64.efi # ls -l refind_x64.efi bootx64.efi -rw-r--r-- 1 root wheel 230856 Aug 15 19:49 bootx64.efi -rw-r--r-- 1 root wheel 230856 Mar 9 11:09 refind_x64.efi # sha256 refind_x64.efi bootx64.efi SHA256 (refind_x64.efi) = 968596f40353ab8140867e71928fcd4c0bc2f39397aba8324f7255bcd57f0913 SHA256 (bootx64.efi) = 968596f40353ab8140867e71928fcd4c0bc2f39397aba8324f7255bcd57f0913 Kind regards, Martijn Rijkeboer [0] http://marc.info/?l=openbsd-tech=149725838018944=2
Re: Copying a file on msdos FS (fat32) changes content
On 06/12/17 21:41, Stefan Fritsch wrote:
> On Mon, 12 Jun 2017, Martijn Rijkeboer wrote:
>> After upgrading to the latest snapshot there seems to be something wrong
>> with the msdos filesystem driver. When I copy a binary file on a msdos
>> (fat32)
>> mounted partition the content changes e.g.:
>>
>> # cp refind_x64.efi bootx64.efi
>> # ls -l refind_x64.efi bootx64.efi
>> -rw-r--r-- 1 root wheel 230856 Jun 12 10:47 bootx64.efi
>> -rw-r--r-- 1 root wheel 230856 Mar 9 11:09 refind_x64.efi
>> # sha256 refind_x64.efi bootx64.efi
>> SHA256 (refind_x64.efi) =
>> 9c9a38f168fed270c158ff5a68d3fa5172eb15bcb41662abf69faa13d2abc418
>> SHA256 (bootx64.efi) =
>> 26f7350143cc897d53b0257dbf5d9f1d84eace4746cbd9f2ff95a033ee0c577f
>
> Sigh.
>
> Please try if the attached patch fixes the problem. It reverts a likely
> culprit.
Yes, this patch fixes the problem.
Kind regards,
Martijn Rijkeboer
>
> Cheers,
> Stefan
>
> diff --git sys/msdosfs/denode.h sys/msdosfs/denode.h
> index efa8192a06d..cdca90500ab 100644
> --- sys/msdosfs/denode.h
> +++ sys/msdosfs/denode.h
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: denode.h,v 1.31 2017/05/29 13:48:12 sf Exp $ */
> +/* $OpenBSD: denode.h,v 1.30 2016/08/30 19:47:23 sf Exp $ */
> /* $NetBSD: denode.h,v 1.24 1997/10/17 11:23:39 ws Exp $ */
>
> /*-
> @@ -142,6 +142,7 @@ struct denode {
> struct vnode *de_devvp; /* vnode of blk dev we live on */
> uint32_t de_flag; /* flag bits */
> dev_t de_dev; /* device where direntry lives */
> + daddr_t de_lastr;
> uint32_t de_dirclust; /* cluster of the directory file containing
> this entry */
> uint32_t de_diroffset; /* offset of this entry in the directory
> cluster */
> uint32_t de_fndoffset; /* offset of found dir entry */
> diff --git sys/msdosfs/msdosfs_vnops.c sys/msdosfs/msdosfs_vnops.c
> index 61b45af6185..39c60044df5 100644
> --- sys/msdosfs/msdosfs_vnops.c
> +++ sys/msdosfs/msdosfs_vnops.c
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: msdosfs_vnops.c,v 1.114 2017/05/29 13:48:12 sf Exp $ */
> +/* $OpenBSD: msdosfs_vnops.c,v 1.113 2016/08/30 19:47:23 sf Exp $ */
> /* $NetBSD: msdosfs_vnops.c,v 1.63 1997/10/17 11:24:19 ws Exp $*/
>
> /*-
> @@ -77,13 +77,13 @@
>
> static uint32_t fileidhash(uint64_t);
>
> -int msdosfs_bmaparray(struct vnode *, daddr_t, daddr_t *, int *);
> int msdosfs_kqfilter(void *);
> int filt_msdosfsread(struct knote *, long);
> int filt_msdosfswrite(struct knote *, long);
> int filt_msdosfsvnode(struct knote *, long);
> void filt_msdosfsdetach(struct knote *);
>
> +
> /*
> * Some general notes:
> *
> @@ -509,14 +509,18 @@ int
> msdosfs_read(void *v)
> {
> struct vop_read_args *ap = v;
> + int error = 0;
> + uint32_t diff;
> + int blsize;
> + int isadir;
> + uint32_t n;
> + long on;
> + daddr_t lbn, rablock, rablkno;
> + struct buf *bp;
> struct vnode *vp = ap->a_vp;
> struct denode *dep = VTODE(vp);
> struct msdosfsmount *pmp = dep->de_pmp;
> struct uio *uio = ap->a_uio;
> - int isadir, error = 0;
> - uint32_t n, diff, size, on;
> - struct buf *bp;
> - daddr_t cn, bn;
>
> /*
>* If they didn't ask for any data, then we are done.
> @@ -531,8 +535,7 @@ msdosfs_read(void *v)
> if (uio->uio_offset >= dep->de_FileSize)
> return (0);
>
> - cn = de_cluster(pmp, uio->uio_offset);
> - size = pmp->pm_bpcluster;
> + lbn = de_cluster(pmp, uio->uio_offset);
> on = uio->uio_offset & pmp->pm_crbomask;
> n = ulmin(pmp->pm_bpcluster - on, uio->uio_resid);
>
> @@ -545,22 +548,31 @@ msdosfs_read(void *v)
> if (diff < n)
> n = diff;
>
> + /* convert cluster # to block # if a directory */
> + if (isadir) {
> + error = pcbmap(dep, lbn, , 0, );
> + if (error)
> + return (error);
> + }
> /*
>* If we are operating on a directory file then be sure to
>* do i/o with the vnode for the filesystem instead of the
>* vnode for the directory.
>*/
> if (isadir) {
> - error = pcbmap(dep, cn, , 0, );
> - if (error)
> - return (error);
> - error = bread(pmp-
Copying a file on msdos FS (fat32) changes content
Hi, After upgrading to the latest snapshot there seems to be something wrong with the msdos filesystem driver. When I copy a binary file on a msdos (fat32) mounted partition the content changes e.g.: # cp refind_x64.efi bootx64.efi # ls -l refind_x64.efi bootx64.efi -rw-r--r-- 1 root wheel 230856 Jun 12 10:47 bootx64.efi -rw-r--r-- 1 root wheel 230856 Mar 9 11:09 refind_x64.efi # sha256 refind_x64.efi bootx64.efi SHA256 (refind_x64.efi) = 9c9a38f168fed270c158ff5a68d3fa5172eb15bcb41662abf69faa13d2abc418 SHA256 (bootx64.efi) = 26f7350143cc897d53b0257dbf5d9f1d84eace4746cbd9f2ff95a033ee0c577f Since this is my EFI boot partition my system won't boot afterwards. It gives a "X64 Exception Type - 0006" error. Kind regards, Martijn Rijkeboer # sysctl kern.version kern.version=OpenBSD 6.1-current (GENERIC.MP) #2: Sun Jun 11 22:26:32 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP # mount | grep /mnt /dev/sd0i on /mnt type msdos (local) # dmesg OpenBSD 6.1-current (GENERIC.MP) #2: Sun Jun 11 22:26:32 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8548429824 (8152MB) avail mem = 8283561984 (7899MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xcfb6c020 (59 entries) bios0: vendor Award Software International, Inc. version "F7" date 10/22/2012 bios0: Gigabyte Technology Co., Ltd. GA-970A-UD3 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP MSDM HPET MCFG EUDS MATS TAMG APIC MATS SSDT acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) SBAZ(S4) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) P2P_(S5) PCE2(S4) PCE3(S4) PCE4(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD FX(tm)-4100 Quad-Core Processor, 3624.71 MHz 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,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,ITSC cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative cpu0: TSC frequency 3624706430 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 201MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD FX(tm)-4100 Quad-Core Processor, 3624.31 MHz 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,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,ITSC cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD FX(tm)-4100 Quad-Core Processor, 3624.31 MHz 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,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,ITSC cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu2: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative cpu2: smt 0, core 3, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD FX(tm)-4100 Quad-Core Processor, 3624.31 MHz 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,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,ITSC cpu3: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu3: DTLB 32 4KB entries fully associative, 32 4MB entries fully asso
Re: changelist: rm unbound/db/root.key
> This file changes twice a day if you're validating dnssec and > it's pretty pointless to warn about in security(8). I'm not a developer, but I totally agree. A few months ago I was asking[1] how to silence these warnings. I'm currently commenting out that line on my DNS resolvers. Kind regards, Martijn Rijkeboer [1] http://marc.info/?l=openbsd-misc=144611060708039=2
