support new

[Duncan Hart]

0
C Australia
P Victoria
T Melbourne
Z 3000
O Applied OpenBSD
I Duncan Hart
M dun...@appliedopenbsd.com
U https://www.AppliedOpenBSD.com/
N Applied OpenBSD research and development

Re: Problems installing 6.5 on Supermicro X11SDV-8C-TP8 motherboard - can't see/find network interfaces

[Don Jackson]

On 2019-05-19 04:33, Hrvoje Popovski wrote:
> On 19.5.2019. 3:08, Don Jackson wrote:
>> I recently acquired a Supermicro 1019D-FRN8TP server with a X11SDV-8C-TP8 
>> motherboard.
> 
> try to install latest snapshot. After installation execute
> sendbug -P > 1019D-FRN8TP.txt and send that output to b...@openbsd.org
> with hardware description and links to that motherboard.

Excellent advice!

I installed OpenBSD 6.5-current (GENERIC.MP) #35: Sat May 18 11:40:36 MDT 2019,
and it found all 8 interfaces, and the NVMe drive as well, complete victory!

I sent the resulting dmesg to that mailing list.

Thank you for suggesting I try current…

Re: USB sound card not playing

[Tuyosi T]

Hi, Alexandre Ratchov

this PC is old(about 10 yeas old)  hitachi server (HA-8000) .


the full dmesg is

# dmesg
OpenBSD 6.5-current (GENERIC.MP) #17: Sun May 12 00:53:38 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8564375552 (8167MB)
avail mem = 8294731776 (7910MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf0d90 (25 entries)
bios0: vendor Phoenix Technologies LTD version "F4" date 10/18/2010
bios0: HITACHI HA8000/TS10
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP TCPA SSDT DMAR APIC SLIC MCFG HPET SPCR EINJ
HEST BERT SSDT ERST
acpi0: wakeup devices PEG_(S4) PEG2(S4) P0P3(S4) P0P5(S4) PEX1(S4)
PEX3(S4) PEX4(S4) PEX5(S4) EHI1(S1) EHI2(S1) LAN_(S5) PCIB(S1)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2527.37 MHz, 06-1e-05
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2526.99 MHz, 06-1e-05
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,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) Xeon(R) CPU X3430 @ 2.40GHz, 2526.99 MHz, 06-1e-05
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,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) Xeon(R) CPU X3430 @ 2.40GHz, 2526.99 MHz, 06-1e-05
cpu3: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-16
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus -1 (PEG_)
acpiprt1 at acpi0: bus -1 (PEG2)
acpiprt2 at acpi0: bus 1 (P0P3)
acpiprt3 at acpi0: bus 2 (P0P5)
acpiprt4 at acpi0: bus 0 (PCI0)
acpiprt5 at acpi0: bus 5 (PEX1)
acpiprt6 at acpi0: bus 9 (PEX3)
acpiprt7 at acpi0: bus 11 (PEX4)
acpiprt8 at acpi0: bus 13 (PEX5)
acpicpu0 at acpi0: !C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: !C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: !C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
"PNP0A05" at acpi0 not configured
acpibtn0 at acpi0: PWRB
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 2527 MHz: speeds: 2395, 2394, 2261, 2128,
1995, 1862, 1729, 1596, 1463, 1330, 1197 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core DMI" rev 0x11
ppb0 at pci0 dev 3 function 0 "Intel Core PCIE" rev 0x11: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 5 function 0 "Intel Core PCIE" rev 0x11: msi
pci2 at ppb1 bus 2
mfi0 at pci2 dev 0 function 0 "Symbios Logic MegaRAID SAS2108 GEN2"
rev 0x03: apic 1 int 16
mfi0: "LSI MegaRAID SAS 9261-8i", firmware 12.11.0-0025, 512MB cache
scsibus1 at mfi0: 64 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct
fixed naa.600605b0017435e02467bacc093ad921
sd0: 557952MB, 512 bytes/sector, 1142685696 sectors
"Intel Core Management" rev 0x11 at pci0 dev 8 function 0 not configured
"Intel Core Control" rev 0x11 at pci0 dev 8 function 2 not configured
"Intel Core Misc" rev 0x11 at pci0 dev 8 function 3 not configured
"Intel Core QPI Link" rev 0x11 at pci0 dev 16 function 0 not configured
"Intel Core QPI Routing" rev 0x11 at pci0 dev 16 function 1 not configured
em0 at pci0 dev 25 function 0 "Intel 82578DM" rev 0x05: msi, address
1c:6f:65:3c:7c:15
ehci0 at pci0 dev 26 function 0 "Intel 3400 USB" rev 0x05: apic 1

dhclient unhappy on GCE (was: arpresolve: 10.128.0.1: route contains no arp information)

[Greg Steuck]

One would hope that https://marc.info/?l=openbsd-cvs&m=155812577615112
should fix my issue. Unfortunately while no longer looping, dhclient is
still not functioning on GCE. Here's what I see from the latest dhclient
vs. the one two revisions back which is working:

Broken (https://marc.info/?l=openbsd-cvs&m=155812577615112):
# ./dhclient.e8bab990985b2fbc3ce2b20fb1a70e38a89b1aa4 -d vio0
vio0: link up -> down
vio0: link down -> up
vio0: DHCPREQUEST to 255.255.255.255
vio0: DHCPACK from 169.254.169.254 (42:01:0a:80:00:01)
vio0: bound to 10.128.15.235 from 169.254.169.254 (42:01:0a:80:00:01)
vio0: DHCPREQUEST to 255.255.255.255
vio0 [priv]: add route 10.128.0.1/255.255.255.255 via 10.128.15.235: File
exists
vio0: DHCPACK from 169.254.169.254 (42:01:0a:80:00:01)
vio0: bound to 10.128.15.235 from 169.254.169.254 (42:01:0a:80:00:01)
vio0 [priv]: add route 10.128.0.1/255.255.255.255 via 10.128.15.235: File
exists
vio0 [priv]: add route 0.0.0.0/0.0.0.0 via 10.128.0.1: File exists

Working (https://marc.info/?l=openbsd-cvs&m=155750708324326)
# ./dhclient.c3ddc4b5b42eaa55a0d45cd2e871fadb439824f4 -d vio0
vio0: link up -> down
vio0: link down -> up
vio0: DHCPREQUEST to 255.255.255.255
vio0: DHCPACK from 169.254.169.254 (42:01:0a:80:00:01)
vio0: bound to 10.128.15.235 from 169.254.169.254 (42:01:0a:80:00:01)
vio0 [priv]: add route 10.128.0.1/255.255.255.255 via 10.128.15.235: File
exists


On Wed, May 15, 2019 at 12:07 PM Greg Steuck  wrote:

> Looks like I'm on a roll with finding snapshot bugs today. May 15 snapshot
> (unlike May 11) experiences arp problems on Google Compute. Full dmesg way
> below, but in general it appears dhclient is not getting what it wants and
> keeps on asking.
> # arp -an
> Host Ethernet AddressNetif Expire
> Flags
> 10.128.0.1   (incomplete) vio0 expired
> 10.128.15.23542:01:0a:80:0f:ebvio0 permanent l
> # tcpdump -i vio0 -n -nnXSs 1000
> tcpdump: listening on vio0, link-type EN10MB
> 12:02:30.438513 10.128.15.235.68 > 255.255.255.255.67:  xid:0x6e483c2c
> vend-rfc1048 DHCP:REQUEST RQ:10.128.15.235
> PR:SM+BR+TZ+121+DG+DN+119+NS+HN+BF+TFTP CID:1.66.1.10.128.15.235 [tos 0x10]
>   : 4510 0148   8011 1f2b 0a80 0feb  E..H...+
>   0010:   0044 0043 0134 d219 0101 0600  .D.C.4..
>   0020: 6e48 3c2c        nH<,
>   0030:     4201 0a80 0feb   B...
>   0040:          
>   0050:          
>   0060:          
>   0070:          
>   0080:          
>   0090:          
>   00a0:          
>   00b0:          
>   00c0:          
>   00d0:          
>   00e0:          
>   00f0:          
>   0100:     6382 5363 3501 0332  c.Sc5..2
>   0110: 040a 800f eb37 0b01 1c02 7903 0f77 060c  .7y..w..
>   0120: 4342 3d07 0142 010a 800f ebff    CB=..B..
>   0130:          
>   0140:      
>
> 12:02:30.438647 169.254.169.254.67 > 10.128.15.235.68:  xid:0x6e483c2c
> Y:10.128.15.235 S:10.128.0.1 G:10.128.0.1 vend-rfc1048 DHCP:ACK
> SID:169.254.169.254 NS:169.254.169.254 LT:86400 DN:"c.syzkaller.internal"
> T119:1.99.9.115.121.122.107.97.108.108.101.114.8.105.110.116.101.114.110.97.108.0.6.103.111.111.103.108.101.8.105.110.116.101.114.110.97.108.0
> SM:255.255.255.255 DG:10.128.0.1 T121:8202,32768,256,0,0,2688,1 MTU:1460
> HN:"ci-openbsd.c.syzkaller.internal" NTP:169.254.169.254 [ttl 1]
>   : 4500 01a8   0111 49de a9fe a9fe  E.I.
>   0010: 0a80 0feb 0043 0044 0194 6746 0201 0600  .C.D..gF
>   0020: 6e48 3c2c     0a80 0feb  nH<,
>   0030: 0a80 0001 0a80 0001 4201 0a80 0feb   B...
>   0040:          
>   0050:          
>   0060:          
>   0070:          
>   0080:          
>   0090:          
>   00a0:          
>   00b0:          
>   00c0:      0

Re: athn: device timeout

[Stefan Sperling]

On Sun, May 19, 2019 at 07:09:00PM +, Lévai, Dániel wrote:
> On Sunday, 19 May 2019 20:42, Stefan Sperling  wrote:
> > On Sun, May 19, 2019 at 05:38:03PM +, Lévai, Dániel wrote:
> > 
> 
> > > And for some reason -- and this is really strange, I know --, sometimes 
> > > it gets into a state where no client can connect/auth to the AP, and 
> > > nothing seems to be able to fix it other than a hard reset of the AP. On 
> > > a Linux client machine with wpa_supplicant(8) these are the log messages 
> > > when this latter happens:
> > > May 19 19:08:38 serenity kernel: wlan0: authenticate with 
> > > May 19 19:08:38 serenity kernel: wlan0: send auth to  (try 1/3)
> > > May 19 19:08:38 serenity kernel: wlan0: authenticated
> > > May 19 19:08:38 serenity kernel: wlan0: associate with  (try 1/3)
> > > May 19 19:08:38 serenity kernel: wlan0: RX AssocResp from  
> > > (capab=0x411 status=0 aid=2)
> > > May 19 19:08:38 serenity kernel: wlan0: associated
> > > May 19 19:08:39 serenity kernel: wlan0: deauthenticated from  
> > > (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)
> > > This just goes on and on and on.
> > 
> 
> > And what do you see with 'ifconfig athn0 debug' on the AP?
> 
> I get a lot of these:
> May 19 21:03:02 firefly /bsd: athn0: station  purged from node cache
> May 19 21:03:02 firefly /bsd: athn0: station  purged from node cache
> May 19 21:03:02 firefly /bsd: athn0: station  purged from node cache
> May 19 21:03:13 firefly /bsd: athn0: sending auth to  on channel 
> 36 mode 11n
> May 19 21:03:13 firefly /bsd: athn0: station  already 
> authenticated (open)
> May 19 21:03:13 firefly /bsd: athn0: sending assoc_resp to  on 
> channel 36 mode 11n
> May 19 21:03:13 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake 
> to 
> May 19 21:03:13 firefly last message repeated 2 times
> May 19 21:03:13 firefly /bsd: athn0: station  deauthenticate 
> (reason 15)
> May 19 21:03:13 firefly /bsd: athn0: sending deauth to  on 
> channel 36 mode 11n
> May 19 21:03:14 firefly /bsd: athn0: sending auth to  on channel 
> 36 mode 11n
> May 19 21:03:14 firefly /bsd: athn0: station  already 
> authenticated (open)
> May 19 21:03:14 firefly /bsd: athn0: sending assoc_resp to  on 
> channel 36 mode 11n
> May 19 21:03:14 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake 
> to 
> May 19 21:03:14 firefly last message repeated 2 times
> May 19 21:03:14 firefly /bsd: athn0: station  deauthenticate 
> (reason 15)
> May 19 21:03:14 firefly /bsd: athn0: sending deauth to  on 
> channel 36 mode 11n
> May 19 21:03:15 firefly /bsd: athn0: sending auth to  on channel 
> 36 mode 11n
> May 19 21:03:15 firefly /bsd: athn0: station  already 
> authenticated (open)
> May 19 21:03:15 firefly /bsd: athn0: sending assoc_resp to  on 
> channel 36 mode 11n
> May 19 21:03:15 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake 
> to 
> May 19 21:03:16 firefly last message repeated 2 times
> May 19 21:03:16 firefly /bsd: athn0: station  deauthenticate 
> (reason 15)
> May 19 21:03:16 firefly /bsd: athn0: sending deauth to  on 
> channel 36 mode 11n
> May 19 21:03:17 firefly /bsd: athn0: sending auth to  on channel 
> 36 mode 11n
> May 19 21:03:17 firefly /bsd: athn0: station  already 
> authenticated (open)
> May 19 21:03:17 firefly /bsd: athn0: sending assoc_resp to  on 
> channel 36 mode 11n
> May 19 21:03:17 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake 
> to 
> May 19 21:03:17 firefly last message repeated 2 times
> May 19 21:03:17 firefly /bsd: athn0: station  deauthenticate 
> (reason 15)
> May 19 21:03:17 firefly /bsd: athn0: sending deauth to  on 
> channel 36 mode 11n
> May 19 21:03:18 firefly /bsd: athn0: sending auth to  on channel 
> 36 mode 11n
> May 19 21:03:18 firefly /bsd: athn0: station  already 
> authenticated (open)
> May 19 21:03:18 firefly /bsd: athn0: sending assoc_resp to  on 
> channel 36 mode 11n
> May 19 21:03:18 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake 
> to 
> May 19 21:03:18 firefly last message repeated 2 times
> May 19 21:03:18 firefly /bsd: athn0: station  deauthenticate 
> (reason 15)
> May 19 21:03:18 firefly /bsd: athn0: sending deauth to  on 
> channel 36 mode 11n
> May 19 21:03:20 firefly /bsd: athn0: sending auth to  on channel 
> 36 mode 11n
> May 19 21:03:20 firefly /bsd: athn0: station  already 
> authenticated (open)
> May 19 21:03:20 firefly /bsd: athn0: sending assoc_resp to  on 
> channel 36 mode 11n
> May 19 21:03:20 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake 
> to 
> May 19 21:03:20 firefly last message repeated 2 times
> 
> Both with and Android phone and a Linux (wpa_supplicant) client.

This looks like your client devices were not responding to
the WPA handshake. I can't explain why. The client side log
says nothing about WPA -- is that expected?

Re: Haskell compilation issues

[Jordan Geoghegan]

On 5/19/19 1:24 PM, Matthias Kilian wrote:

On Sun, May 19, 2019 at 12:18:44AM -0500, Joe Nelson wrote:

Matthias Kilian wrote:

ps: please note that I'm not subscribed to misc@ with my 'real'
mail account, only with a crappy gmail account I'm only reading on
my tablet (from which I forwarded your mail to my real address). So
better cc' me if you've any other questions ;-)

FYI, the way you replied to the original message broke the reply chain
in my mail reader (Mutt). You should include an "In-Reply-To" message
header that references the Message-ID of the mail to which you are
replying. I know it might be a little tricky from your tablet setup, but
wanted to bring it to your attention if you weren't aware.

I'm very well aware of it, and I've a really smart solution for the
problem: I'll never ever even try to give some helpful answer to
any of the mails on misc@



No need to get all triggered, the guy is just giving you a heads up.

Re: Haskell compilation issues

[Matthias Kilian]

On Sun, May 19, 2019 at 12:18:44AM -0500, Joe Nelson wrote:
> Matthias Kilian wrote:
> > ps: please note that I'm not subscribed to misc@ with my 'real'
> > mail account, only with a crappy gmail account I'm only reading on
> > my tablet (from which I forwarded your mail to my real address). So
> > better cc' me if you've any other questions ;-)
> 
> FYI, the way you replied to the original message broke the reply chain
> in my mail reader (Mutt). You should include an "In-Reply-To" message
> header that references the Message-ID of the mail to which you are
> replying. I know it might be a little tricky from your tablet setup, but
> wanted to bring it to your attention if you weren't aware.

I'm very well aware of it, and I've a really smart solution for the
problem: I'll never ever even try to give some helpful answer to
any of the mails on misc@

Re: malloc_conf J j

[Jan Stary]

On May 19 16:46:44, schwa...@usta.de wrote:
> >> The current "increase/decrease" wording in malloc(3)
> >> can suggest it has a memory. For example, setting
> >> 
> >>vm.malloc_conf=J
> >> 
> >> "increases" junk level to two;
> >> does setting
> >> 
> >>vm.malloc_conf=C
> >> 
> >> later retain a junk level of two,
> >> as there is no 'j' to "decrease" it,
> >> or is the junk level the defult of one now?
> 
> Your question makes no sense whatsoever.
> 
> First, the word "later" makes no sense.

I should have worded more clearly. I meant programs that start later,
after vm.malloc_conf is set to something else.

It makes perfect sense now, thanks.

Jan

> Malloc initialization is
> only done once during a run of any given program.


> contains J during startup, that is what governs program behaviour.
> Changing the sysctl later no longer has any effect on the running
> program.

> Index: malloc.3
> ===
> RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
> retrieving revision 1.124
> diff -u -r1.124 malloc.3
> --- malloc.3  13 May 2019 06:04:55 -  1.124
> +++ malloc.3  19 May 2019 14:39:30 -
> @@ -270,6 +270,8 @@
>  in the program.
>  Each is scanned for the flags documented below.
>  Unless otherwise noted uppercase means on, lowercase means off.
> +During initialization, flags occurring later modify the behaviour
> +that was requested by flags processed earlier.
>  .Bl -tag -width indent
>  .It Cm C
>  .Dq Canaries .
> 

Re: Haskell compilation issues

[Joe Nelson]

Matthias Kilian wrote:
> I've a really smart solution for the problem: I'll never ever even try
> to give some helpful answer to any of the mails on misc@

Sorry, my message must have sounded snarky. I didn't intend it that
way. Honestly just wanted to help you with your email setup. It can be
complicated, and I've only recently learned about some of this stuff
myself.

Maybe I should have replied off-list originally, but thought the mail
header tip might be useful for other people as well.

Re: athn: device timeout

[Lévai , Dániel]

On Sunday, 19 May 2019 20:42, Stefan Sperling  wrote:
> On Sun, May 19, 2019 at 05:38:03PM +, Lévai, Dániel wrote:
>
> > And for some reason -- and this is really strange, I know --, sometimes it 
> > gets into a state where no client can connect/auth to the AP, and nothing 
> > seems to be able to fix it other than a hard reset of the AP. On a Linux 
> > client machine with wpa_supplicant(8) these are the log messages when this 
> > latter happens:
> > May 19 19:08:38 serenity kernel: wlan0: authenticate with 
> > May 19 19:08:38 serenity kernel: wlan0: send auth to  (try 1/3)
> > May 19 19:08:38 serenity kernel: wlan0: authenticated
> > May 19 19:08:38 serenity kernel: wlan0: associate with  (try 1/3)
> > May 19 19:08:38 serenity kernel: wlan0: RX AssocResp from  (capab=0x411 
> > status=0 aid=2)
> > May 19 19:08:38 serenity kernel: wlan0: associated
> > May 19 19:08:39 serenity kernel: wlan0: deauthenticated from  (Reason: 
> > 15=4WAY_HANDSHAKE_TIMEOUT)
> > This just goes on and on and on.
>
> And what do you see with 'ifconfig athn0 debug' on the AP?

I get a lot of these:
May 19 21:03:02 firefly /bsd: athn0: station  purged from node cache
May 19 21:03:02 firefly /bsd: athn0: station  purged from node cache
May 19 21:03:02 firefly /bsd: athn0: station  purged from node cache
May 19 21:03:13 firefly /bsd: athn0: sending auth to  on channel 
36 mode 11n
May 19 21:03:13 firefly /bsd: athn0: station  already 
authenticated (open)
May 19 21:03:13 firefly /bsd: athn0: sending assoc_resp to  on 
channel 36 mode 11n
May 19 21:03:13 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake to 

May 19 21:03:13 firefly last message repeated 2 times
May 19 21:03:13 firefly /bsd: athn0: station  deauthenticate 
(reason 15)
May 19 21:03:13 firefly /bsd: athn0: sending deauth to  on channel 
36 mode 11n
May 19 21:03:14 firefly /bsd: athn0: sending auth to  on channel 
36 mode 11n
May 19 21:03:14 firefly /bsd: athn0: station  already 
authenticated (open)
May 19 21:03:14 firefly /bsd: athn0: sending assoc_resp to  on 
channel 36 mode 11n
May 19 21:03:14 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake to 

May 19 21:03:14 firefly last message repeated 2 times
May 19 21:03:14 firefly /bsd: athn0: station  deauthenticate 
(reason 15)
May 19 21:03:14 firefly /bsd: athn0: sending deauth to  on channel 
36 mode 11n
May 19 21:03:15 firefly /bsd: athn0: sending auth to  on channel 
36 mode 11n
May 19 21:03:15 firefly /bsd: athn0: station  already 
authenticated (open)
May 19 21:03:15 firefly /bsd: athn0: sending assoc_resp to  on 
channel 36 mode 11n
May 19 21:03:15 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake to 

May 19 21:03:16 firefly last message repeated 2 times
May 19 21:03:16 firefly /bsd: athn0: station  deauthenticate 
(reason 15)
May 19 21:03:16 firefly /bsd: athn0: sending deauth to  on channel 
36 mode 11n
May 19 21:03:17 firefly /bsd: athn0: sending auth to  on channel 
36 mode 11n
May 19 21:03:17 firefly /bsd: athn0: station  already 
authenticated (open)
May 19 21:03:17 firefly /bsd: athn0: sending assoc_resp to  on 
channel 36 mode 11n
May 19 21:03:17 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake to 

May 19 21:03:17 firefly last message repeated 2 times
May 19 21:03:17 firefly /bsd: athn0: station  deauthenticate 
(reason 15)
May 19 21:03:17 firefly /bsd: athn0: sending deauth to  on channel 
36 mode 11n
May 19 21:03:18 firefly /bsd: athn0: sending auth to  on channel 
36 mode 11n
May 19 21:03:18 firefly /bsd: athn0: station  already 
authenticated (open)
May 19 21:03:18 firefly /bsd: athn0: sending assoc_resp to  on 
channel 36 mode 11n
May 19 21:03:18 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake to 

May 19 21:03:18 firefly last message repeated 2 times
May 19 21:03:18 firefly /bsd: athn0: station  deauthenticate 
(reason 15)
May 19 21:03:18 firefly /bsd: athn0: sending deauth to  on channel 
36 mode 11n
May 19 21:03:20 firefly /bsd: athn0: sending auth to  on channel 
36 mode 11n
May 19 21:03:20 firefly /bsd: athn0: station  already 
authenticated (open)
May 19 21:03:20 firefly /bsd: athn0: sending assoc_resp to  on 
channel 36 mode 11n
May 19 21:03:20 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake to 

May 19 21:03:20 firefly last message repeated 2 times

Both with and Android phone and a Linux (wpa_supplicant) client.


Dani


publickey - leva@ecentrum.hu - 0x66E1F716.asc
Description: application/pgp-keys

Re: athn: device timeout

[Stefan Sperling]

On Sun, May 19, 2019 at 05:38:03PM +, Lévai, Dániel wrote:
> And for some reason -- and this is really strange, I know --, sometimes it 
> gets into a state where no client can connect/auth to the AP, and nothing 
> seems to be able to fix it other than a hard reset of the AP. On a Linux 
> client machine with wpa_supplicant(8) these are the log messages when this 
> latter happens:
> 
> May 19 19:08:38 serenity kernel: wlan0: authenticate with 
> May 19 19:08:38 serenity kernel: wlan0: send auth to  (try 1/3)
> May 19 19:08:38 serenity kernel: wlan0: authenticated
> May 19 19:08:38 serenity kernel: wlan0: associate with  (try 1/3)
> May 19 19:08:38 serenity kernel: wlan0: RX AssocResp from  (capab=0x411 
> status=0 aid=2)
> May 19 19:08:38 serenity kernel: wlan0: associated
> May 19 19:08:39 serenity kernel: wlan0: deauthenticated from  (Reason: 
> 15=4WAY_HANDSHAKE_TIMEOUT)
> 
> This just goes on and on and on.

And what do you see with 'ifconfig athn0 debug' on the AP?

Re: athn: device timeout

[Lévai , Dániel]

On Sunday, 19 May 2019 18:48, Stefan Sperling  wrote:
> On Sun, May 19, 2019 at 02:30:25PM +, Lévai, Dániel wrote:
>
> > Hi everyone!
> > I wonder if this 0 particular issue is what I'm experiencing. Judging from 
> > the fact that the only thing needed for this to happen is a full-bandwidth 
> > (~1MB/s) throughput via athn0 for about 20 seconds, I'm inclined to say yes.
> > I wanted to ask if this 1 commit should've fixed these kind of issues, or 
> > that "recalibration" is something else.
>
> What is your reason for asking?
>
> These timeouts should be infrequent and the driver should recover
> without intervention. If that matches your case, there is nothing
> critical to fix, though it would of course be nice to understand
> and perhaps fix the problem.
>
> Are these device timeouts causing you actual problems or are you
> just curious why these messages are appearing?

Well, in my experience here, there are two different kinds of consequences that 
can happen when these timeouts occur.
The first (that happens let's say 90% of the time) can be fixed with a swift:
# /sbin/ifconfig athn0 down; sleep 1; /sbin/ifconfig athn0 up
It needs to be done, but at least it's fixable -- otherwise no client can 
connect the AP.

And for some reason -- and this is really strange, I know --, sometimes it gets 
into a state where no client can connect/auth to the AP, and nothing seems to 
be able to fix it other than a hard reset of the AP. On a Linux client machine 
with wpa_supplicant(8) these are the log messages when this latter happens:

May 19 19:08:38 serenity kernel: wlan0: authenticate with 
May 19 19:08:38 serenity kernel: wlan0: send auth to  (try 1/3)
May 19 19:08:38 serenity kernel: wlan0: authenticated
May 19 19:08:38 serenity kernel: wlan0: associate with  (try 1/3)
May 19 19:08:38 serenity kernel: wlan0: RX AssocResp from  (capab=0x411 
status=0 aid=2)
May 19 19:08:38 serenity kernel: wlan0: associated
May 19 19:08:39 serenity kernel: wlan0: deauthenticated from  (Reason: 
15=4WAY_HANDSHAKE_TIMEOUT)

This just goes on and on and on. But e.g. Android phones cannot connect to the 
AP either in this case, and they say "Check password and try again" in the 
Wi-Fi settings menu, after trying to reconnect quickly a number of times -- 
these are really rapid, max 1 sec in between the retries. Bear in mind that I 
didn't not change the password on the AP or the phone.

Now I'm gradually trying to lower the allowed bandwidth of the athn(4) devices 
with pf(4) to see if there's any setting where it wouldn't fail (lowered from 
around the default/max 1MB/s, in the 800KB/s range this still happened).

> The latter is hard to say without sitting in front of your box.
> Device timeouts mean the hardware failed to send one frame.
> Which can happen for any number of reasons.

Hm, is it worth trying to switch around e.g. antennas?


Dani

Re: athn0: bad ROM checksum 0x2c64

[Stefan Sperling]

On Sun, May 19, 2019 at 06:49:25PM +0300, 3 wrote:
> > On Sun, May 19, 2019 at 12:33:33PM +0300, 3 wrote:
> >> shit. i have upgraded to 6.5 and now the interface is losing settings
> >> after about 30 seconds:
> >> athn0: flags=8843 mtu 1500
> >> lladdr b0:48:7a:8c:41:79
> >> index 17 priority 4 llprio 3
> >> groups: wlan
> >> media: IEEE802.11 autoselect (DS1)
> >> status: no network
> >> ieee80211: nwid ""
> >> 
> >> but within 30 seconds it works(though losing a lot of packets).
> >> maybe some more rescue patches? ;)
> >> 
> >> ps:
> >> athn0 at uhub0 port 5 configuration 1 interface 0 "ATHEROS USB WLAN" rev 
> >> 2.00/2.02 addr 3
> >> athn0: AR9287 rev 2 (2T2R), ROM rev 4, address b0:48:7a:8c:41:79
> >> 
> 
> > Try -current. kevlo@ has comitted a fix for this device.
> 
> i built the kernel with its fixes. little has changed. now after
> rebooting the device does not up(netstart does not help), only a
> physical power outage helps. but after that only sometimes the device
> works as it should, more often it turns off after about 30 seconds. in
> this case, netstart helps to start the device again, more often for 30
> seconds, but sometimes it continues to work as it should. all this is
> very sad -_-  

Try it on a different machine and/or USB port.

This driver has known issues on some host controllers but there is
no way to tell what you have plugged the device into because your
report lacks a full dmesg.

Re: athn: device timeout

[Stefan Sperling]

On Sun, May 19, 2019 at 02:30:25PM +, Lévai, Dániel wrote:
> Hi everyone!
> 
> I wonder if this [0] particular issue is what I'm experiencing. Judging from 
> the fact that the only thing needed for this to happen is a full-bandwidth 
> (~1MB/s) throughput via athn0 for about 20 seconds, I'm inclined to say yes.
> I wanted to ask if this [1] commit should've fixed these kind of issues, or 
> that "recalibration" is something else.

What is your reason for asking?

These timeouts should be infrequent and the driver should recover
without intervention. If that matches your case, there is nothing
critical to fix, though it would of course be nice to understand
and perhaps fix the problem.

Are these device timeouts causing you actual problems or are you
just curious why these messages are appearing?

The latter is hard to say without sitting in front of your box.
Device timeouts mean the hardware failed to send one frame.
Which can happen for any number of reasons.

> I'm using a wle200nx (9280) in a PC Engines apu4c4 running 6.5 now and 
> interestingly enough, I didn't experience these timeouts with 6.4 (although 
> with the same wle200nx in a different hardware).
> Also, I'm running with this [2] patch over -stable, I don't know if that 
> should make a difference.

Irrelevant. That patch fixes 1T2R devices; you have a 2T2R device.
 
> [0]: https://marc.info/?l=openbsd-misc&m=151782917217806&w=2
> [1]: 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/athn.c.diff?r1=1.100&r2=1.101
> [2]: 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/athn.c.diff?r1=1.102&r2=1.103
> 
> Any insight is appreciated!
> 
> Thanks,
> Dani
> 
> 
> dmesg:
> OpenBSD 6.5-stable (GENERIC.MP) #1: Thu May 16 16:36:18 CEST 2019
> daniell@firefly:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4261203968 (4063MB)
> avail mem = 4122423296 (3931MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdffd7020 (7 entries)
> bios0: vendor coreboot version "v4.0.24" date 02/04/2019
> bios0: PC Engines apu4
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S2 S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC HEST SSDT SSDT HPET
> acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) 
> UOH1(S3) UOH3(S3) UOH5(S3) XHC0(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 GX-412TC SOC, 998.25 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
> cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
> 16-way L2 cache
> cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: DTLB 40 4KB entries fully associative, 8 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, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD GX-412TC SOC, 998.14 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
> cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
> 16-way L2 cache
> cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
> cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
> 16-way L2 cache
> cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: AMD GX-412TC SOC, 998.23 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,

Re: athn0: bad ROM checksum 0x2c64

[3]

> On Sun, May 19, 2019 at 12:33:33PM +0300, 3 wrote:
>> shit. i have upgraded to 6.5 and now the interface is losing settings
>> after about 30 seconds:
>> athn0: flags=8843 mtu 1500
>> lladdr b0:48:7a:8c:41:79
>> index 17 priority 4 llprio 3
>> groups: wlan
>> media: IEEE802.11 autoselect (DS1)
>> status: no network
>> ieee80211: nwid ""
>> 
>> but within 30 seconds it works(though losing a lot of packets).
>> maybe some more rescue patches? ;)
>> 
>> ps:
>> athn0 at uhub0 port 5 configuration 1 interface 0 "ATHEROS USB WLAN" rev 
>> 2.00/2.02 addr 3
>> athn0: AR9287 rev 2 (2T2R), ROM rev 4, address b0:48:7a:8c:41:79
>> 

> Try -current. kevlo@ has comitted a fix for this device.

i built the kernel with its fixes. little has changed. now after
rebooting the device does not up(netstart does not help), only a
physical power outage helps. but after that only sometimes the device
works as it should, more often it turns off after about 30 seconds. in
this case, netstart helps to start the device again, more often for 30
seconds, but sometimes it continues to work as it should. all this is
very sad -_-  

Re: route-to rule problem after upgrading to 6.5

[Carlos Lopez]

On 19/05/2019 14:16, Ville Valkonen wrote:
> On Sun, 19 May 2019 at 12.14, Carlos Lopez  > wrote:
> 
> Hi all,
> 
>    Yesterday, I have upgraded my home OpenBSD's fws from 6.4 to 6.5.
> All
> seems to work ok execpt with route-to rules. The following rules have
> been working smoothly in previous versions:
> 
> pass in quick inet proto tcp from  to
>  port = 80 flags S/SA keep state (if-bound) label
> "Force access to Google sites via TOR" tag intlans-to-intlans route-to
> 172.22.56.5@vio4
> pass in quick inet proto tcp from  to
>  port = 443 flags S/SA keep state (if-bound) label
> "Force access to Google sites via TOR" tag intlans-to-intlans route-to
> 172.22.56.5@vio4
> 
>    .. but with 6.5 fails ... Any idea?
> -- 
> Regards,
> C. L. Martinez
> 
> 
> Hello Carlos,
> 
> you have "port = 443", shouldn't that be in "port 443" form? Didn't 
> check the pf.conf man page for the correct grammar while on mobile.
> 
> Regards,
> Ville

Thanks Ville, but not. This is not the problem. I have attached pfctl's 
output. Original rules is:

pass in quick inet proto tcp from  to 
 port { http https } route-to ($vpnif $inthost) tag 
intlans-to-intlans label "Force access to Google sites via TOR"

Re: malloc_conf J j

[Otto Moerbeek]

On Sun, May 19, 2019 at 04:46:44PM +0200, Ingo Schwarze wrote:

> Hi,
> 
> Otto Moerbeek wrote on Sun, May 19, 2019 at 02:55:09PM +0200:
> > On Sun, May 19, 2019 at 08:50:20AM +0200, Jan Stary wrote:
> 
> >> Does 'J' simply make the junk level two and
> >> does 'j' simply make the junk level zero?
> 
> No, it does not.
> 
> For example, if sysctl vm.malloc_conf contains j and MALLOC_OPTIONS
> contains J, or if any one source contains "jJ" or "jjJ", you end
> up with level 1: During the first malloc call in the program, the
> j first lowers the level from 1 to 0, then the J raises the level
> back to 1, but not to 2.
> 
> >> The current "increase/decrease" wording in malloc(3)
> >> can suggest it has a memory. For example, setting
> >> 
> >>vm.malloc_conf=J
> >> 
> >> "increases" junk level to two;
> >> does setting
> >> 
> >>vm.malloc_conf=C
> >> 
> >> later retain a junk level of two,
> >> as there is no 'j' to "decrease" it,
> >> or is the junk level the defult of one now?
> 
> Your question makes no sense whatsoever.
> 
> First, the word "later" makes no sense.  Malloc initialization is
> only done once during a run of any given program.  So if the sysctl
> contains J during startup, that is what governs program behaviour.
> Changing the sysctl later no longer has any effect on the running
> program.
> 
> Besides, while J and j manipulate mopts.def_malloc_junk, C sets
> mopts.chunk_canaries.  One doesn't have anything to do with the
> other.
> 
> > C is a combined flag, containing J amongst others.
> 
> Neither the code nor the manual page appears to agree with that
> statement.  Are you maybe thinking of S?

yes, I was thinking of S indeed.

> 
> To provide another example, MALLOC_OPTIONS=jS results in junk level
> 1 because j lowers it from 1 to 0, then S raises it from 0 to 1.
> MALLOC_OPTIONS=jSS results in junk level 2, whereas MALLOC_OPTIONS=SSj
> results in junk level 1.
> 
> 
> The manual page already seems quite clear.  Well, maybe we could
> add one sentence for even more clarity.  Right now, some might think
> that earlier flags win.
> 
> OK?
>   Ingo

yes,

-Otto
> 
> 
> Index: malloc.3
> ===
> RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
> retrieving revision 1.124
> diff -u -r1.124 malloc.3
> --- malloc.3  13 May 2019 06:04:55 -  1.124
> +++ malloc.3  19 May 2019 14:39:30 -
> @@ -270,6 +270,8 @@
>  in the program.
>  Each is scanned for the flags documented below.
>  Unless otherwise noted uppercase means on, lowercase means off.
> +During initialization, flags occurring later modify the behaviour
> +that was requested by flags processed earlier.
>  .Bl -tag -width indent
>  .It Cm C
>  .Dq Canaries .

Re: malloc_conf J j

[Ingo Schwarze]

Hi,

Otto Moerbeek wrote on Sun, May 19, 2019 at 02:55:09PM +0200:
> On Sun, May 19, 2019 at 08:50:20AM +0200, Jan Stary wrote:

>> Does 'J' simply make the junk level two and
>> does 'j' simply make the junk level zero?

No, it does not.

For example, if sysctl vm.malloc_conf contains j and MALLOC_OPTIONS
contains J, or if any one source contains "jJ" or "jjJ", you end
up with level 1: During the first malloc call in the program, the
j first lowers the level from 1 to 0, then the J raises the level
back to 1, but not to 2.

>> The current "increase/decrease" wording in malloc(3)
>> can suggest it has a memory. For example, setting
>> 
>>  vm.malloc_conf=J
>> 
>> "increases" junk level to two;
>> does setting
>> 
>>  vm.malloc_conf=C
>> 
>> later retain a junk level of two,
>> as there is no 'j' to "decrease" it,
>> or is the junk level the defult of one now?

Your question makes no sense whatsoever.

First, the word "later" makes no sense.  Malloc initialization is
only done once during a run of any given program.  So if the sysctl
contains J during startup, that is what governs program behaviour.
Changing the sysctl later no longer has any effect on the running
program.

Besides, while J and j manipulate mopts.def_malloc_junk, C sets
mopts.chunk_canaries.  One doesn't have anything to do with the
other.

> C is a combined flag, containing J amongst others.

Neither the code nor the manual page appears to agree with that
statement.  Are you maybe thinking of S?

To provide another example, MALLOC_OPTIONS=jS results in junk level
1 because j lowers it from 1 to 0, then S raises it from 0 to 1.
MALLOC_OPTIONS=jSS results in junk level 2, whereas MALLOC_OPTIONS=SSj
results in junk level 1.


The manual page already seems quite clear.  Well, maybe we could
add one sentence for even more clarity.  Right now, some might think
that earlier flags win.

OK?
  Ingo


Index: malloc.3
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
retrieving revision 1.124
diff -u -r1.124 malloc.3
--- malloc.313 May 2019 06:04:55 -  1.124
+++ malloc.319 May 2019 14:39:30 -
@@ -270,6 +270,8 @@
 in the program.
 Each is scanned for the flags documented below.
 Unless otherwise noted uppercase means on, lowercase means off.
+During initialization, flags occurring later modify the behaviour
+that was requested by flags processed earlier.
 .Bl -tag -width indent
 .It Cm C
 .Dq Canaries .

athn: device timeout

[Lévai , Dániel]

Hi everyone!

I wonder if this [0] particular issue is what I'm experiencing. Judging from 
the fact that the only thing needed for this to happen is a full-bandwidth 
(~1MB/s) throughput via athn0 for about 20 seconds, I'm inclined to say yes.
I wanted to ask if this [1] commit should've fixed these kind of issues, or 
that "recalibration" is something else.

I'm using a wle200nx (9280) in a PC Engines apu4c4 running 6.5 now and 
interestingly enough, I didn't experience these timeouts with 6.4 (although 
with the same wle200nx in a different hardware).
Also, I'm running with this [2] patch over -stable, I don't know if that should 
make a difference.

[0]: https://marc.info/?l=openbsd-misc&m=151782917217806&w=2
[1]: 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/athn.c.diff?r1=1.100&r2=1.101
[2]: 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/athn.c.diff?r1=1.102&r2=1.103

Any insight is appreciated!

Thanks,
Dani


dmesg:
OpenBSD 6.5-stable (GENERIC.MP) #1: Thu May 16 16:36:18 CEST 2019
daniell@firefly:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4261203968 (4063MB)
avail mem = 4122423296 (3931MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdffd7020 (7 entries)
bios0: vendor coreboot version "v4.0.24" date 02/04/2019
bios0: PC Engines apu4
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S2 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HEST SSDT SSDT HPET
acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) 
UOH1(S3) UOH3(S3) UOH5(S3) XHC0(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 GX-412TC SOC, 998.25 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 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, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD GX-412TC SOC, 998.14 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD GX-412TC SOC, 998.23 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins, remapped
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PBR4)
acpiprt2 at acpi0: bus 2 (PBR5)
acpiprt3 at acpi0: bus 3 (PBR6)
acpiprt4 at acpi0: bus 4 (PBR7)
acpiprt5 at acpi0: bus 5 (PBR8)
acpicpu0 at acpi0: C2(

Re: malloc_conf J j

[Otto Moerbeek]

On Sun, May 19, 2019 at 08:50:20AM +0200, Jan Stary wrote:

> Does 'J' simply make the junk level two and
> does 'j' simply make the junk level zero?
> 
> The current "increase/decrease" wording in malloc(3)
> can suggest it has a memory. For example, setting
> 
>   vm.malloc_conf=J
> 
> "increases" junk level to two;
> does setting
> 
>   vm.malloc_conf=C
> 
> later retain a junk level of two,
> as there is no 'j' to "decrease" it,
> or is the junk level the defult of one now?
> 
>   Jan
> 

C is a combined flag, containing J amongst others.

-Otto

malloc_conf J j

[Jan Stary]

Does 'J' simply make the junk level two and
does 'j' simply make the junk level zero?

The current "increase/decrease" wording in malloc(3)
can suggest it has a memory. For example, setting

vm.malloc_conf=J

"increases" junk level to two;
does setting

vm.malloc_conf=C

later retain a junk level of two,
as there is no 'j' to "decrease" it,
or is the junk level the defult of one now?

Jan

Re: route-to rule problem after upgrading to 6.5

[Ville Valkonen]

On Sun, 19 May 2019 at 12.14, Carlos Lopez  wrote:

> Hi all,
>
>   Yesterday, I have upgraded my home OpenBSD's fws from 6.4 to 6.5. All
> seems to work ok execpt with route-to rules. The following rules have
> been working smoothly in previous versions:
>
> pass in quick inet proto tcp from  to
>  port = 80 flags S/SA keep state (if-bound) label
> "Force access to Google sites via TOR" tag intlans-to-intlans route-to
> 172.22.56.5@vio4
> pass in quick inet proto tcp from  to
>  port = 443 flags S/SA keep state (if-bound) label
> "Force access to Google sites via TOR" tag intlans-to-intlans route-to
> 172.22.56.5@vio4
>
>   .. but with 6.5 fails ... Any idea?
> --
> Regards,
> C. L. Martinez
>

Hello Carlos,

you have "port = 443", shouldn't that be in "port 443" form? Didn't check
the pf.conf man page for the correct grammar while on mobile.

Regards,
Ville

Re: athn0: bad ROM checksum 0x2c64

[Stefan Sperling]

On Sun, May 19, 2019 at 12:33:33PM +0300, 3 wrote:
> shit. i have upgraded to 6.5 and now the interface is losing settings
> after about 30 seconds:
> athn0: flags=8843 mtu 1500
> lladdr b0:48:7a:8c:41:79
> index 17 priority 4 llprio 3
> groups: wlan
> media: IEEE802.11 autoselect (DS1)
> status: no network
> ieee80211: nwid ""
> 
> but within 30 seconds it works(though losing a lot of packets).
> maybe some more rescue patches? ;)
> 
> ps:
> athn0 at uhub0 port 5 configuration 1 interface 0 "ATHEROS USB WLAN" rev 
> 2.00/2.02 addr 3
> athn0: AR9287 rev 2 (2T2R), ROM rev 4, address b0:48:7a:8c:41:79
> 

Try -current. kevlo@ has comitted a fix for this device.

Re: Problems installing 6.5 on Supermicro X11SDV-8C-TP8 motherboard - can't see/find network interfaces

[Hrvoje Popovski]

On 19.5.2019. 3:08, Don Jackson wrote:
> I recently acquired a Supermicro 1019D-FRN8TP server with a X11SDV-8C-TP8 
> motherboard.

Hi,

try to install latest snapshot. After installation execute
sendbug -P > 1019D-FRN8TP.txt and send that output to b...@openbsd.org
with hardware description and links to that motherboard.

if you can't install latest snapshot collect some information from
other OS like acpidump, pcidump -v or lspci -nn, lsusb -vvv


i'm quite certain that openbsd should see 4 x 1Gbe Intel i354 interfaces
as em, not sure about x722 although this could be ixl ...


this box seems as quite nice router :) but i'm think i would go with
https://www.supermicro.com/Aplus/system/Embedded/AS-5019D-FTN4.cfm

Re: athn0: bad ROM checksum 0x2c64

[3]

> This should fix attach but there's some other remaining problem.
> The device detaches itself again when I try to use it.

> diff 709e530bc956c51de2da4aff727d8da450babdc4 /usr/src
> blob - 74025dba1aff37e328c92779398e428caef72c04
> file + sys/dev/ic/ar9287.c
> --- sys/dev/ic/ar9287.c
> +++ sys/dev/ic/ar9287.c
> @@ -100,7 +100,8 @@ voidar9280_spur_mitigate(struct athn_softc *, 
> struct
>  int
>  ar9287_attach(struct athn_softc *sc)
>  {
-   sc->>eep_base = AR9287_EEP_START_LOC;
+   sc->>eep_base = (sc->flags & ATHN_FLAG_USB) ?
> +   AR9287_HTC_EEP_START_LOC : AR9287_EEP_START_LOC;
> sc->eep_size = sizeof(struct ar9287_eeprom);
> sc->ngpiopins = (sc->flags & ATHN_FLAG_USB) ? 16 : 11;
> sc->led_pin = 8;
> blob - 340b28c2f84de4d40f15c42f13b1727a6f497bb0
> file + sys/dev/ic/ar9287reg.h
> --- sys/dev/ic/ar9287reg.h
> +++ sys/dev/ic/ar9287reg.h
> @@ -60,6 +60,7 @@
>   * ROM layout used by AR9287 (2GHz only).
>   */
>  #define AR9287_EEP_START_LOC   128
> +#define AR9287_HTC_EEP_START_LOC   256
>  #define AR9287_NUM_2G_CAL_PIERS3
>  #define AR9287_NUM_2G_CCK_TARGET_POWERS3
>  #define AR9287_NUM_2G_20_TARGET_POWERS   3

shit. i have upgraded to 6.5 and now the interface is losing settings
after about 30 seconds:
athn0: flags=8843 mtu 1500
lladdr b0:48:7a:8c:41:79
index 17 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (DS1)
status: no network
ieee80211: nwid ""

but within 30 seconds it works(though losing a lot of packets).
maybe some more rescue patches? ;)

ps:
athn0 at uhub0 port 5 configuration 1 interface 0 "ATHEROS USB WLAN" rev 
2.00/2.02 addr 3
athn0: AR9287 rev 2 (2T2R), ROM rev 4, address b0:48:7a:8c:41:79

route-to rule problem after upgrading to 6.5

[Carlos Lopez]

Hi all,

  Yesterday, I have upgraded my home OpenBSD's fws from 6.4 to 6.5. All 
seems to work ok execpt with route-to rules. The following rules have 
been working smoothly in previous versions:

pass in quick inet proto tcp from  to 
 port = 80 flags S/SA keep state (if-bound) label 
"Force access to Google sites via TOR" tag intlans-to-intlans route-to 
172.22.56.5@vio4
pass in quick inet proto tcp from  to 
 port = 443 flags S/SA keep state (if-bound) label 
"Force access to Google sites via TOR" tag intlans-to-intlans route-to 
172.22.56.5@vio4

  .. but with 6.5 fails ... Any idea?
-- 
Regards,
C. L. Martinez