Re: iwm: unhandled firmware response
I did use kern.bufcachepercent=90 before. I think I copied it blindly from some blog post about OpenBSD on a laptop. No problems observed for now with "iwm" since 20% value in use. -- Krystian
Re: dangling SEE ALSO references and some peculiarities in man pages
Hi Jason, Jason McIntyre wrote on Sun, Apr 28, 2019 at 10:51:05PM +0100: > better still, run any changes you make to man pages like this: > > $ mandoc -Tlint page.1 That's good advice. > it will report trailing Xr Only in mdoc(7) pages, not in man(7) pages. Identifying cross references in man(7) code is hard. Many different forms are used in practice for writing such references, so having mandoc -T lint inspect them would cause significant effort. We don't even generate elements from cross-references in man(7) documents for HTML output yet, even though that would no doubt be useful. Also, man(7) pages are always legacy documents, so checking them is low-priority in the first place. > and a whole host of other things. Indeed, though again, checks are intentionally *much* stricter for mdoc(7) input than for man(7) input, also regarding other things. Yours, Ingo
Re: panic: Stopped at kqueue_scan
On 23/04/19(Tue) 12:16, Olivier Antoine wrote:
> >Synopsis:panic: Stopped at kqueue_scan
> >Category:kernel i386
> >Environment:
> System : OpenBSD 6.5
> Details : OpenBSD 6.5-current (GENERIC.MP) #1368: Sun Apr 21
> 19:50:46 MDT 2019
>
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
>
> Architecture: OpenBSD.i386
> Machine : i386
> >Description:
> Hi, since my last update I have regular panic crashes. 4 in two days.
> At least 3 of them, with certainty, occurred while I was accessing the
> Internet via my smartphone connected to my OpenBSD WiFi access point
> through my Allways-on VPN isakmp/ipsec/nppp relaying traffic in Tor.
> This setup works for years.
>
> The machine then displays something like:
> uvm_fault(0xd34e5f3c, 0x0, 0, 2) -> e
> kernel: page fault trap, code=0
> Stopped at kqueue_scan+0x246: movl %eax,0(%ecx)
> ddb{1}>
So this indicates that the `kqueue' is empty. It should not happen
because the caller, in your case npppd, always places a marker in the
list.
Since the caller is not threaded and the syscall is executed with the
KERNEL_LOCK() held, we can supposed that another part of the kernel is
removing the marker. That would imply that the other part isn't running
with the KERNEL_LOCK() and requires a MP kernel.
Could you try *very hard* to reproduce the problem with a kernel built
with the diff below? Hopefully you'll make it crash and we'll find the
bug. Otherwise we'll look for another possible cause of the marker
removal.
Index: kern/kern_event.c
===
RCS file: /cvs/src/sys/kern/kern_event.c,v
retrieving revision 1.101
diff -u -p -r1.101 kern_event.c
--- kern/kern_event.c 27 Nov 2018 15:52:50 - 1.101
+++ kern/kern_event.c 28 Apr 2019 21:47:25 -
@@ -1052,6 +1052,8 @@ knote_drop(struct knote *kn, struct proc
struct kqueue *kq = kn->kn_kq;
struct klist *list;
+ KERNEL_ASSERT_LOCKED();
+
if (kn->kn_fop->f_isfd)
list = &kq->kq_knlist[kn->kn_id];
else
Re: dangling SEE ALSO references and some peculiarities in man pages
On Sun, Apr 28, 2019 at 02:16:23PM -0500, Tim Chase wrote: > Digging through cross-references in man-pages, I encountered a couple > dangling references and some other peculiarities. > hi. because we sometimes install 3rd party pages, there is a small amount of Xr that doesn;t match up. the effort to clean it up is probably not worth it. > > Dangling SEE ALSO references to man-pages that don't exist: > > dig(1) references missing named(8) and dnssec-keygen(8) > host(1) references missing named(8) > nslookup(1) references missing named(8) that's all from bind > info(5) references missing emacs(1) > info(5) references missing tex(1) > texinfo(5) references missing emacs(1) > texinfo(5) references missing tex(1) boy do i wish we could kill the info crap. > default_colors(3) references missing ded(1) > curs_inopts(3) references missing termio(7) curses > readline(3) references missing bash(1) > gnu readline (check the "ouput" typo) basically, upstream will not see these as issues, and maintaing local changes are often more pain that gain. > Peculiarities: > > The man pages for form(3) and menu(3) have multiple SEE ALSO sections > which struck me as a bit odd/confusing. > > i've never noticed that. you could check if the latest curses still has this - if they do, they are quite receptive to diffs. if not, we could ask someone like nicm about fixing this locally. > It all started with looking at texinfo(5) and noticing that tex(1) > didn't exist in the man-pages, so I tossed together a dirty little > Python script to attempt to check for other missing cross-references. > The script still produces a little bit of noise in the output that I > cleaned up for this email, but it made pretty quick work of finding > some missing links. If anybody wants the .py file, you're welcome to > it. > better still, run any changes you make to man pages like this: $ mandoc -Tlint page.1 it will report trailing Xr and a whole host of other things. you can sit back and have a cuppa! jmc
dangling SEE ALSO references and some peculiarities in man pages
Digging through cross-references in man-pages, I encountered a couple dangling references and some other peculiarities. Dangling SEE ALSO references to man-pages that don't exist: dig(1) references missing named(8) and dnssec-keygen(8) host(1) references missing named(8) nslookup(1) references missing named(8) info(5) references missing emacs(1) info(5) references missing tex(1) texinfo(5) references missing emacs(1) texinfo(5) references missing tex(1) default_colors(3) references missing ded(1) curs_inopts(3) references missing termio(7) readline(3) references missing bash(1) Peculiarities: The man pages for form(3) and menu(3) have multiple SEE ALSO sections which struck me as a bit odd/confusing. It all started with looking at texinfo(5) and noticing that tex(1) didn't exist in the man-pages, so I tossed together a dirty little Python script to attempt to check for other missing cross-references. The script still produces a little bit of noise in the output that I cleaned up for this email, but it made pretty quick work of finding some missing links. If anybody wants the .py file, you're welcome to it. -tkc (@gumnos)
Re: panic: Stopped at kqueue_scan
With bsd.mp, net.pipex.enable=0 I just browse the web with my
LineageOS 7.1.2 throught L2TP/IPSec PSK VPN.
It doesn't seems to bug with bsd.sp
My npppd.conf :
# $OpenBSD: npppd.conf,v 1.2 2014/03/22 04:32:39 yasuoka Exp $
# sample npppd configuration file. see npppd.conf(5)
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
tunnel L2TP protocol l2tp {
listen on 0.0.0.0
# pipex yes
lcp-keepalive yes
lcp-keepalive-interval 60
}
ipcp IPCP {
pool-address 10.0.0.2-10.0.0.14
dns-servers 8.8.8.8
}
# use tun(4) interface. multiple ppp sessions concentrate one interface.
interface tun0 address 10.0.0.1 ipcp IPCP
bind tunnel from L2TP authenticated by LOCAL to tun0
On Sun, Apr 28, 2019 at 8:02 PM Martin Pieuchot wrote:
>
> On 26/04/19(Fri) 11:23, Olivier Antoine wrote:
> > Hi, could it be that the problem is related to pipex?
> > My npppd.conf rely on the default pipex settings (on)
> > But net.pipex.enable is 0 since I have no explicit settings in my
> > /etc/sysctl.conf
> > Under these conditions, I have no difficulty to crash the machine.
> > With net.pipex.enable=1 I have not yet noticed any problem.
>
> This might help trigger the bug. Do you have a receipt to reproduce it
> at 100%? Does it only happens with a MP kernel? Or can you reproduce
> it in vmm(4) for example?
Re: panic: Stopped at kqueue_scan
On 26/04/19(Fri) 11:23, Olivier Antoine wrote: > Hi, could it be that the problem is related to pipex? > My npppd.conf rely on the default pipex settings (on) > But net.pipex.enable is 0 since I have no explicit settings in my > /etc/sysctl.conf > Under these conditions, I have no difficulty to crash the machine. > With net.pipex.enable=1 I have not yet noticed any problem. This might help trigger the bug. Do you have a receipt to reproduce it at 100%? Does it only happens with a MP kernel? Or can you reproduce it in vmm(4) for example?
6.5-stable - Video output on openchrome causes xenodm to crash
When attempting to play a MPEG2-SP video file with mplayer, X11 or xine (no
options so xv is the default acceleration), the screen flashes briefly and
after a few seconds, xenodm resets to the login screen. On 6.3 video playback
worked fine under same conditions. Both systems use the defaults for the xf86
driver. The logs below are as follows: dmesg Xorg.0.log.old xenodm.log
mplayer.log. EXA+composite acceleration is enabled by default which conflicts
with the man page for openchrome.
OpenBSD 6.5 (GENERIC) #1338: Sat Apr 13 15:07:04 MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
RTC BIOS diagnostic error 2
real mem = 1877164032 (1790MB)
avail mem = 1827692544 (1743MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 11/11/08, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @
0xfc590 (19 entries)
bios0: vendor Hewlett-Packard version "68VGU Ver. F.06" date 11/11/2008
bios0: Hewlett-Packard HP 2133
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC WDRT OEMB HPET SSDT
acpi0: wakeup devices BLAN(S5) SLPB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: VIA C7-M Processor 1200MHz ("CentaurHauls" 686-class) 1.27 GHz, 06-0d-00
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,SSE3,EST,TM2,xTPR,NXE
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: RNG AES AES-CTR SHA1 SHA256 RSA
cpu0: apic clock running at 199MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 3, 24 pins
ioapic1 at mainbus0: apid 2 pa 0xfecc, version 3, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpiprt2 at acpi0: bus 2 (NBPG)
acpiprt3 at acpi0: bus -1 (P0P9)
acpiprt4 at acpi0: bus 7 (P0PA)
acpiprt5 at acpi0: bus 5 (NBP0)
acpiprt6 at acpi0: bus 128 (PCI1)
acpiec0 at acpi0
acpicpu0 at acpi0: !C3(@800 io@0x815), !C2(@80 io@0x814), C1(@1 halt!), PSS
acpipwrres0 at acpi0: APMF, resource for HDAC
acpitz0 at acpi0: critical temperature is 105 degC
"PNP0A03" at acpi0 not configured
acpicmos0 at acpi0
"SYN013D" at acpi0 not configured
"HPQ0004" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "Primary" serial 10 type LiOn oem
"Hewlett-Packard"
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibtn2 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
"HPQ0006" at acpi0 not configured
"PNP0A08" at acpi0 not configured
acpivideo0 at acpi0: VGA_
acpivout0 at acpivideo0: LCD_
bios0: ROM list: 0xc/0xcc00 0xcd000/0x1600
cpu0: Enhanced SpeedStep 1269 MHz: speeds: 1200, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "VIA P4M900 Host" rev 0x00
viaagp0 at pchb0: v3
agp0 at viaagp0: aperture at 0xf000, size 0x1000
pchb1 at pci0 dev 0 function 1 "VIA P4M900 Host" rev 0x00
pchb2 at pci0 dev 0 function 2 "VIA P4M900 Host" rev 0x00
pchb3 at pci0 dev 0 function 3 "VIA P4M900 Host" rev 0x00
pchb4 at pci0 dev 0 function 4 "VIA P4M900 Host" rev 0x00
"VIA P4M900 IOAPIC" rev 0x00 at pci0 dev 0 function 5 not configured
pchb5 at pci0 dev 0 function 6 "VIA P4M900 Security" rev 0x00
pchb6 at pci0 dev 0 function 7 "VIA P4M900 Host" rev 0x00
ppb0 at pci0 dev 1 function 0 "VIA VT8377 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "VIA Chrome9 HC IGP" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb1 at pci0 dev 2 function 0 "VIA P4M900" rev 0x80: apic 2 int 3
pci2 at ppb1 bus 2
"Broadcom BCM4312" rev 0x02 at pci2 dev 0 function 0 not configured
ppb2 at pci0 dev 3 function 0 "VIA P4M900" rev 0x80: apic 2 int 7
pci3 at ppb2 bus 5
pciide0 at pci0 dev 15 function 0 "VIA VT8237S SATA" rev 0x00: DMA
pciide0: using apic 1 int 21 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA48, 114473MB, 234441648 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0xb0: apic 1 int 20
uhci1 at pci0 dev 16 function 2 "VIA VT83C572 USB" rev 0xb0: apic 1 int 21
uhci2 at pci0 dev 16 function 3 "VIA VT83C572 USB" rev 0xb0: apic 1 int 23
ehci0 at pci0 dev 16 function 4 "VIA VT6202 USB" rev 0x90: apic 1 int 21
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "VIA EHCI root hub" rev 2.00/1.00
addr 1
viapm0 at pci0 dev 17 function 0 "VIA VT8237S ISA" rev 0x00: SMI
iic0 at viapm0
lisa0 at iic0 addr 0x1d: lis331dl
spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM
pchb7 at pci0 dev 17 function 7 "VIA VT8251 VLINK" rev 0x00
pchb8 at pci0 dev 19 function 0 "VIA VT8237A" rev 0x00
ppb3 at pci0 dev 19 function 1 "VIA VT8237A" rev 0x00
pci4 at ppb3 bus 7
bge0 at pci4 dev 3 function 0 "Broadco
