Re: bsd.rd: autoinstall: make device: group is invalid: _sndiop
On Sat, Apr 18, 2020 at 10:10:41PM +0200, Olivier Antoine wrote:
> Hi,
>
> During the installation process with the latest available bsd.rd, at
> the step 'Making all devices nodes' I noticed the following error
> message twice:
> chgrp : group is invalid: _sndiop
>
> Saw that on bsd.rd amd64 17 Apr 2020 during a fresh install.
>
> Didn't notice any problem after.
It breaks sound. Until you get a new snap, you could fix it with:
doas chgrp _sndiop /dev/{audio,rmidi}*
thanks for the notice.
Re: bsd.rd: autoinstall: make device: group is invalid: _sndiop
On 2020/04/18 22:10, Olivier Antoine wrote: > Hi, > > During the installation process with the latest available bsd.rd, at > the step 'Making all devices nodes' I noticed the following error > message twice: > chgrp : group is invalid: _sndiop > > Saw that on bsd.rd amd64 17 Apr 2020 during a fresh install. > > Didn't notice any problem after. > > Cheers, > > -- > Olivier Fixed in newer snapshots.
bsd.rd: autoinstall: make device: group is invalid: _sndiop
Hi, During the installation process with the latest available bsd.rd, at the step 'Making all devices nodes' I noticed the following error message twice: chgrp : group is invalid: _sndiop Saw that on bsd.rd amd64 17 Apr 2020 during a fresh install. Didn't notice any problem after. Cheers, -- Olivier dmesg.boot Description: Binary data
Re: gzopen in src/lib/libz and empty files
Salut Olivier,
Olivier Taibi wrote on Wed, Apr 15, 2020 at 07:52:21PM +0200:
> I believe there is a bug in gzopen(3) when opening an empty file. It
> can read both gzipped and uncompressed files, and obviously an empty
> file falls in the second category, but in this case the first read gives
> a buffer error (Z_BUF_ERROR in zlib.h) instead of EOF (Z_STREAM_END in
> zlib.h) because the stream is incorrectly identified as gzipped. The
> following diff fixes this issue for me.
Thanks for noticing, analyzing, reporting, and fixing the bug.
I just committed your patch.
Yours,
Ingo
> Index: gzio.c
> ===
> RCS file: /cvs/src/lib/libz/gzio.c,v
> retrieving revision 1.14
> diff -u -p -u -p -r1.14 gzio.c
> --- gzio.c20 Jul 2005 15:56:41 - 1.14
> +++ gzio.c15 Apr 2020 12:54:37 -
> @@ -307,7 +307,7 @@ local void check_header(s)
> s->stream.avail_in += len;
> s->stream.next_in = s->inbuf;
> if (s->stream.avail_in < 2) {
> -s->transparent = s->stream.avail_in;
> +s->transparent = 1;
> return;
> }
> }
panic: kernel diagnostic assertion "!ISSET(rt->rt_flags, RTF_LOCAL)" failed
Hi,
I encountered a reproducible kernel panic during an accidental IPv6
misconfiguration. In order to reproduce, the OpenBSD machine must be in
the same subnet as a router that has fe80::1/64 configured and sends
IPv6 route advertisements, for example with radvd using this config:
interface eth0 {
AdvSendAdvert on;
MinRtrAdvInterval 10;
MaxRtrAdvInterval 30;
prefix 2001:db8::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};
With this setup, I was able to to reliably trigger the assertion using
the following steps:
- Install Openbsd using 6.6/amd64 install66.iso
- IPv4: none
- IPv6: autoconf
- Reboot into system, log in
- echo inet6 alias fe80::1 64 >> /etc/hostname.vio0
# The file now contains the following:
# inet6 autoconf
# inet6 alias fe80::1 64
- Reboot and log in again
- ping6 2001::
# The exact address doesn't seem to matter, it also doesn't have to
# respond or anything. Sometimes this step isn't even necessary as the
# panic occurs by itself after the login prompt.
- Wait a bit (less than a minute in my case) and observe the panic
These steps ignore installing updates, however, this can also be
reproduced after using syspatch. The boot and panic log below was
created using the latest kernel available on 6.6. In case it's relevant,
I observed this in a QEMU VM running on Debian sid using libvirt.
Julian
>> OpenBSD/amd64 BOOT 3.45
boot>
booting hd0a:/bsd: 12670280+2937872+333136+0+704512
[992525+128+1010520+739210]=0x127fc78
entry point at 0x81001000
[ using 2743416 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2019 OpenBSD. All rights reserved.
https://www.OpenBSD.org
OpenBSD 6.6 (GENERIC) #8: Fri Apr 17 13:49:18 MDT 2020
r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1056800768 (1007MB)
avail mem = 1012199424 (965MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5ad0 (9 entries)
bios0: vendor SeaBIOS version "1.13.0-1" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel Xeon E3-12xx v2 (Ivy Bridge, IBRS), 2295.05 MHz, 06-3a-09
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,VMX,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,HV,NXE,RDTSCP,LONG,LAHF,FSGSBASE,TSC_ADJUST,SMEP,ERMS,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,XSAVEOPT,MELTDOWN
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 999MHz
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
"ACPI0006" at acpi0 not configured
acpipci0 at acpi0 PCI0: _OSC failed
acpicmos0 at acpi0
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"QEMU0002" at acpi0 not configured
"ACPI0010" at acpi0 not configured
cpu0: using VERW MDS workaround
pvbus0 at mainbus0: KVM
pvclock0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: removable
cd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 disabled (no drives)
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0
int 9
iic0 at piixpm0
vga1 at pci0 dev 2 function 0 "Red Hat QXL Video" rev 0x04
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio0: address 52:54:00:f6:d7:f8
virtio0: msix shared
azalia0 at pci0 dev 4 function 0 "Intel 82801FB HD Audio" rev 0x01: apic
0 int 11
azalia0: No codecs found
uhci0 at pci0 dev 5 function 0 "Intel 82801I USB" rev 0x03: apic 0 int 10
uhci1 at pci0 dev 5 function 1 "Intel 82801I USB" rev 0x03: apic 0 int 10
uhci2 at pci0 dev 5 function 2 "Intel 82801I USB" rev 0x03: apic 0 int 11
ehci0 at pci0 dev 5 function 7 "Intel 82801I USB" rev 0x03: apic 0 int 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0
Re: OpenBSD 6.7-beta on arm64 with urtwn(4) gets panic: _dmamap_sync: ran off map!
On Tue, Apr 14, 2020 at 06:42:53PM +, Mikolaj Kucharski wrote:
> On Tue, Apr 14, 2020 at 11:06:00AM +0200, Patrick Wildt wrote:
> > On Mon, Apr 13, 2020 at 09:36:04PM +0200, Mark Kettenis wrote:
> > > Can you print the status (full 32 bits) of that particular QTD?
> >
> > Yeah, I wish I could see the status field for each sqtd in that
> > chain.
>
> XXX #1# ehci_idone: len=4 actlen=4294951308, xf_actlen=0, status=0x8d00,
> sqtd_count=3
> XXX #2# ehci_idone: x_actlen=4294951304, sqtd_len=8, ehci_qtd_len=16000,
> status=0xbe808d00, qtd_status=0xbe808d00, sqtd_count=1
> XXX #2# ehci_idone: x_actlen=4294951308, sqtd_len=4, ehci_qtd_len=0,
> status=0xc00, qtd_status=0xc00, sqtd_count=2
> XXX #2# ehci_idone: x_actlen=4294951308, sqtd_len=0, ehci_qtd_len=0,
> status=0x8d00, qtd_status=0x8d00, sqtd_count=3
> panic: _dmamap_sync: ran off map!
Thanks for the information! I'll try and see if I can find what's
happening. But yeah, that's good information. This is a control
transfers, which has 3 transfer descriptors.
The three TDs should be: SETUP, DATA (because of len=4), and STATUS.
As you can see, the middle one, DATA, has a len of 4, and the BYTES
field in the status is 0, indicating that the transfer completed.
Then we have STATUS, which has no len, looks just fine as well.
But the first one, the SETUP, is weird. The len is fine, 8 bytes,
but ehci_qtd_len looks completely off, the BYTES field also says
"lots of bytes remaining". This is where we fuck up, I suppose.
What's weird is that we actually account it, because we have this
check:
if (EHCI_QTD_GET_PID(status) != EHCI_QTD_PID_SETUP)
actlen += sqtd->len - EHCI_QTD_GET_BYTES(status);
But it looks like the status field on the SETUP descriptor does
not say PID_SETUP, but PID_IN. Did the DMA controller change the
bit? Or did someone else overwrite it?
Patrick
> Above are my debug lines in dmesg generated just before panic.
>
> The code which prints those lines is below. It's similar for-loop to
> what is currently in CVS in ehci_idone() function. I'm doing this
> for-loop twice. First version of for-loop is executed as is in CVS
> and record condition that panic will happen, then below for-loop is
> executed again with more debug output, otherwise printf() will slow
> the code path so mutch that I will not be able to trigger error
> condition.
>
> With below code (lines from 1 to 29) I already know panic condition is
> met and I'm executing code with printf()s added.
>
> sqtd_count=3 means that for-loop from line 6 to 28 was executed 3 times.
>
> XXX #1# ehci_idone: len=4 actlen=4294951308, xf_actlen=0, status=0x8d00,
> sqtd_count=3
>
> Above message is from line 2 of the code listed below.
>
> Then we enter the for-loop at line 6, which iterates 3 times. Each
> iteration gives following results:
>
> XXX #2# ehci_idone: x_actlen=4294951304, sqtd_len=8, ehci_qtd_len=16000,
> status=0xbe808d00, qtd_status=0xbe808d00, sqtd_count=1
> XXX #2# ehci_idone: x_actlen=4294951308, sqtd_len=4, ehci_qtd_len=0,
> status=0xc00, qtd_status=0xc00, sqtd_count=2
> XXX #2# ehci_idone: x_actlen=4294951308, sqtd_len=0, ehci_qtd_len=0,
> status=0x8d00, qtd_status=0x8d00, sqtd_count=3
>
> then code proceeds and triggers panic.
>
> 1if (xfer->length < actlen) {
> 2printf("XXX #1# ehci_idone: len=%u, actlen=%u,
> xf_actlen=%u, "
> 3"status=0x%x, sqtd_count=%d\n", xfer->length,
> actlen, xfer->actlen, status, sqtd_count);
> 4x_actlen = 0;
> 5sqtd_count = 0;
> 6for (sqtd = ex->sqtdstart; sqtd != NULL; sqtd = sqtd->nextqtd) {
> 7sqtd_count++;
> 8usb_syncmem(>dma, sqtd->offs, sizeof(sqtd->qtd),
> 9BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD);
> 10nstatus = letoh32(sqtd->qtd.qtd_status);
> 11qtd_status = nstatus;
> 12if (nstatus & EHCI_QTD_ACTIVE)
> 13break;
> 14
> 15status = nstatus;
> 16/* halt is ok if descriptor is last, and complete */
> 17if (sqtd->qtd.qtd_next == htole32(EHCI_LINK_TERMINATE)
> &&
> 18EHCI_QTD_GET_BYTES(status) == 0)
> 19status &= ~EHCI_QTD_HALTED;
> 20if (EHCI_QTD_GET_PID(status) != EHCI_QTD_PID_SETUP) {
> 21sqtd_len = sqtd->len;
> 22ehci_qtd_len = EHCI_QTD_GET_BYTES(status);
> 23x_actlen += sqtd_len - ehci_qtd_len;
> 24printf("XXX #2# ehci_idone: x_actlen=%u,
> sqtd_len=%u, ehci_qtd_len=%u, "
> 25"status=0x%x, qtd_status=0x%x,
> sqtd_count=%d\n",
> 26x_actlen, sqtd_len, ehci_qtd_len,
> status, qtd_status, sqtd_count);
> 27}
> 28
