Amdgpu card support

[Peter Kay]

First of all, thanks for including this, but should a diff be submitted
to the man page that states it supports everything between SI and Vega?
If I'm reading the documentation and past posts correctly, amdgpu uses
Xorg's Glamor and Mesa to output anything. Mesa is at 19.0.8, so it
should support Vega, but not Navi (Navi support seems to arrive in 19.2).
I've just bought a Vega56 on the grounds it would shortly be supported in
OpenBSD (didn't expect it this fast!), is supported in Free/NetBSD, has
open source drivers, and at least isn't actively blocking PCI
passthrough. 
(I didn't choose the Vega64 as the 56 seems to be able to be made quieter
and retain most of the performance. The RX 5700 cards appear to still be
bedding in)
PK

Re: mira sfer overflow panic (was: Re: 11n support for athn(4))

[Peter Kay]

On Thu, Jan 26, 2017 at 10:38:44AM +0100, Stefan Sperling wrote:
> On Thu, Jan 26, 2017 at 06:36:06AM +0000, Peter Kay wrote:
> > sfer overflow
> 
> Interesting. This is the first time I've ever seen this panic trigger.
> 
> Can you apply this patch and try to trigger it again?
I've been running with MIRADEBUG since Feb 1st, just now had a different panic

Bogus long slot station count 0

Ieee80211_node_leave _11g+0xd0

Will post details later when I've had chance to ocr the screencaps

Re: 11n support for athn(4)

[Peter Kay]

On 17 January 2017 at 12:25, Stefan Sperling  wrote:
> On Tue, Jan 17, 2017 at 11:56:09AM +0100, Stefan Sperling wrote:
>> Without more details, all I can do is guess.
>> I made one guess already (antennas) and sadly I guessed wrong.
>
> Another thing where your setup differs from mine is that you are
> using a device with 3 antennas, whereas my devices only have 2.
>
> I have already ordered a 3 antenna device two days ago so I should
> have one to test with soon. Perhaps I will see a problem then.
>
> Is anyone else reading this list using a 3 antenna device?
> Please let us know whether it works.
I'd actually recompiled the kernel using January 16th sources and it
was working fine, until tonight. Brought up the glass console to see a
panic

The following was photographed, then OCRd. I've given it a quick look
to check it seems ok, but not a fine toothcomb.

sfer overflow

ddb> trace Debugger(d09e973d,13734d68,d09cf94e,f3734db8,b200) at
Debugger+0x7 panic(d09cf9de,f3734d8c,d03c88c9,d1605008,13734df8) at
panic.0x71
ieee80211_mira_update_stats(d169ab58,d1364030,4169a000,d03b9634,d0c6c980)
at ieee80211 mira_update_siats+0x3bf
 ieee80211_mira_choose(d169ab58,d1364030,d169a000,0,d13be040) at
ieee80.2.11_mira_choose+0x4e
ar5008_tx_process (d1364009 ,0 , f3734edc,760f4a ,8354c175) at
arS008_tx_process+0x1f2
 ar5008_tx intr (d1364000,c0,f3734f0c, d03ba33f ,f3734ef4) at ar5008tx_intr+0x7c
ar5008_intr (d1364000 , d135d380) at ar5008_intr+021b
 Xintrlegacy3() at Xintr_legacy3+0x81
--- interrupt ---
 cpu_idle_cycle(d0c6c960) at cpu_idlecycle+0xf

I also have the ps lists, but I ran out of time to OCR them. Let me
know if needed and I can forward the photos

Re: 11n support for athn(4)

[Peter Kay]

  Original Message  
From: s...@stsp.name
Sent: 17 January 2017 12:25 p.m.
To: syllops...@syllopsium.co.uk; tech@openbsd.org
Subject: Re: 11n support for athn(4)

On Tue, Jan 17, 2017 at 11:56:09AM +0100, Stefan Sperling wrote:
>> Without more details, all I can do is guess.
>> I made one guess already (antennas) and sadly I >guessed wrong.

>Another thing where your setup differs from mine is >that you are
>using a device with 3 antennas, whereas my devices >only have 2.

>I have already ordered a 3 antenna device two days >ago so I should
>have one to test with soon. Perhaps I will see a >problem then.

>Is anyone else reading this list using a 3 antenna >device?
>Please let us know whether it works.
Assuming my firewall hangs again tonight, I'll revert to 11g and see if the 
issue persists. Would ssh access help to diagnose the problem? I can put other 
hardware in to do firewall duties and swap my current box out

Re: 11n support for athn(4)

[Peter Kay]

  Original Message  
From: s...@stsp.name
Sent: 17 January 2017 10:00 a.m.
To: syllops...@syllopsium.co.uk
Cc: tech@openbsd.org
Subject: Re: 11n support for athn(4)

On Mon, Jan 16, 2017 at 11:58:51PM +, Peter Kay wrote:
>> 
>> Three, yes, but note that unless the antennas have been unreasonably
>> disturbed during the snapshot upgrade nothing has changed. Also, it
>> takes a day or so for the access point to start failing, so I'm
>> suspecting a software issue.

>Fair enough. But I can't see anything in your reports >that would guide me
>where to look for bugs in the code. Let me know if >you find out more.

What diagnostics are available to narrow down the cause of this issue?

Re: 11n support for athn(4)

[Peter Kay]

On 16 January 2017 at 23:30, Stefan Sperling <s...@stsp.name> wrote:
> On Mon, Jan 16, 2017 at 07:18:04PM +0000, Peter Kay wrote:
>> I'm still having issues with this.
>>
>> When the access p64 bytes from 192.168.1.251: icmp_seq=678 ttl=255 
>> time=4.502 ms
oint wedges, it seems to affect my Android phone more
>> than the iwn laptop. ifconfig athn0 down up does resolve the problem
>> in the short term.
>
> Do you have 2 antennas properly connected to the athn card?

Three, yes, but note that unless the antennas have been unreasonably
disturbed during the snapshot upgrade nothing has changed. Also, it
takes a day or so for the access point to start failing, so I'm
suspecting a software issue.

Re: 11n support for athn(4)

[Peter Kay]

I'm still having issues with this.

When the access point wedges, it seems to affect my Android phone more
than the iwn laptop. ifconfig athn0 down up does resolve the problem
in the short term.

I see the changes have already been committed, so it's no longer
necessary to patch recent snapshots (running 14th, #133).

ifconfig athn0 media produces

athn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr x:x:x:x
description: 802.11b/g wireless
index 1 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (autoselect mode 11n hostap)
status: active
ieee80211: nwid myAP chan 9 bssid x:x:x:x wpakey 0xdeadbeef
wpaprotos wpa2 wpaakms psk paciphers ccmp wpagroupcipher ccmp
supported media:
media autoselect
media autoselect mediaopt hostap
media autoselect mediaopt monitor
media autoselect mode 11b
media autoselect mode 11b mediaopt hostap
media autoselect mode 11b mediaopt monitor
media autoselect mode 11g
media autoselect mode 11g mediaopt hostap
media autoselect mode 11g mediaopt monitor
media autoselect mode 11n
media autoselect mode 11n mediaopt hostap
media autoselect mode 11n mediaopt monitor
inet 1.1.1.1 netmask 0xff00 broadcast 1.1.1.255

I can possibly try switching developer options on one of the Android
phones I have lying around.


On 14 January 2017 at 12:53, Stefan Sperling <s...@stsp.name> wrote:
> On Sat, Jan 14, 2017 at 12:42:09PM +, Peter Kay wrote:
>> On 14 January 2017 at 12:02, Stefan Sperling <s...@stsp.name> wrote:
>> > On Sat, Jan 14, 2017 at 11:31:00AM +, Peter Kay wrote:
>> >> On 14 January 2017 at 11:23, Stefan Sperling <s...@stsp.name> wrote:
>>
>> > If one of your clients says it cannot authenticate, then this client may be
>> > trying to use TKIP/WPA1. You can enable wpa1 explicitly for such clients:
>> >   ifconfig athn0 wpaprotos wpa1,wpa2
>> > But understand that you'll be running broken WEP-grade crypto if you do 
>> > this.
>> I'll upgrade to the latest snapshot. It's not a TKIP/WPA1 issue as a
>> reboot fixes it.
>
> A reboot is very drastic and won't help with narrowing down the
> cause of your issue.
>
> Can you find a better way to unwedge the AP when it runs into problems?
> Does 'ifconfig iwn0 scan' on the client help?
> Does 'ifconfig athn0 down up' on the AP help?

Re: 11n support for athn(4)

[Peter Kay]

On 14 January 2017 at 11:23, Stefan Sperling <s...@stsp.name> wrote:
> On Sat, Jan 14, 2017 at 11:03:24AM +0000, Peter Kay wrote:
>> On 12 January 2017 at 15:06, Stefan Sperling <s...@stsp.name> wrote:

> So your first test might not have had 11n enabled since the first two
> versions of my patch had a bug where 11n was left disabled on 2GHz only
> devices. Please check with 'ifconfig media athn0' whether 11n mode is
> actually supported.
'bad value' regardless of what interface I run this on?

> What does your /etc/hostname.athn0 file look like?
> Please specify 'mode 11n' in your /etc/hostname.athn0, and also fix the
> channel with a line such as 'chan 1'. There are known problems otherwise.
> For reference, this is what I am using:
>
>   media autoselect mode 11n mediaopt hostap chan 10
>   nwid stsp.name wpakey xxx
>   up
inet 1.1.1.1 255.255.255.0 1.1.1.255 description "802.11b/g wireless"
media autoselect mode 11n mediaopt hostap chan 9 nwid "myap" wpakey
"ultrasecurepassword" wpaprotos "wpa2"

I'll try applying the latest patch if it will make a difference, but
the clients did think they had a carrier at greater than g speeds.

Re: 11n support for athn(4)

[Peter Kay]

On 12 January 2017 at 15:06, Stefan Sperling  wrote:
> On Tue, Jan 10, 2017 at 12:27:47AM +0100, Stefan Sperling wrote:
>> On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
>> > This diff adds 11n support to the athn(4) driver.
>> > Requires -current net80211 code from today.
>>
I'm now getting some very odd issues that did not previously exist
with my hostap before upgrading to the snapshot and applying the
patch.

Phone complains about an 'authentication problem', iwn laptop with
issues about buffer space and then associates with a different ap.
There's nothing in the logs and a reboot is required.

At first I thought it was a clock problem, because I found my firewall
clock was somehow a month ahead, but after correcting that the second
time it occurred the time was ok.

Going to have to revert to snapshot without the 11n patches and see if
the issue persists. Unfortunately it takes a while to manifest itself.

PK

Re: 11n support for athn(4)

[Peter Kay]

OK, got it working. Pulled the kernel sources direct from cvs without
pre-loading and it compiled.

Haven't had time for a proper test, but there are a couple of points.

Hardware MAC AR5416 rev 2, RF AR2133 (3T2R), ROM rev 5 (PCI adapter)

Blackberry Priv - connects between 100 and 130M at 2.4GHz 802.11n ,
throughput not tested yet

FreeBSD - iwn4965. Connects at 11ng, but if you start in 11g mode,
change the hostap to 11n, then reassociate the client it uses 11b. May
be a FreeBSD issue..?

Vista - same machine, connects at 130Mb.

Throughput testing, more machines later. Basic connectivity is working.

On 11 January 2017 at 23:28, Peter Kay <syllops...@syllopsium.co.uk> wrote:
> On 11 January 2017 at 22:05, Stefan Sperling <s...@stsp.name> wrote:
>
>>
>> You haven't updated all of src/sys.
>
> I'm obviously being really dumb, but what is wrong with
> cd /usr
> tar zxf sys.tar.gz (from 6.0)
> cvs -qd anon...@anoncvs.au.openbsd.org:/cvs update -dP sys
> cd sys
> patch -p0 < /path/to/wlan.diff
> cd arch/i386/conf
> config GENERIC
> cd ../compile/GENERIC
> make
>
> ? I see reference in current.html to
> make obj (this does not work (don't know how to make obj).
>
> Note : I am building this as root, because it's a VM (firewall is too
> slow to build) and building releases is all it is doing

Re: 11n support for athn(4)

[Peter Kay]

On 11 January 2017 at 22:05, Stefan Sperling  wrote:

>
> You haven't updated all of src/sys.

I'm obviously being really dumb, but what is wrong with
cd /usr
tar zxf sys.tar.gz (from 6.0)
cvs -qd anon...@anoncvs.au.openbsd.org:/cvs update -dP sys
cd sys
patch -p0 < /path/to/wlan.diff
cd arch/i386/conf
config GENERIC
cd ../compile/GENERIC
make

? I see reference in current.html to
make obj (this does not work (don't know how to make obj).

Note : I am building this as root, because it's a VM (firewall is too
slow to build) and building releases is all it is doing

Re: 11n support for athn(4)

[Peter Kay]

On 9 January 2017 at 23:27, Stefan Sperling  wrote:
> On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
>> This diff adds 11n support to the athn(4) driver.
>> Requires -current net80211 code from today.
>
> A better diff which fixes several bugs.
>
I'm getting

undefined reference to ieee80211_mira_node_init

ieee80211_mira_node_destroy and
ieee80211_mira_choose

i386, GENERIC. My firewall is not multi core. Running current with
updated patch.

PK

Re: Support power saving with athn(4) in host AP mode

[Peter Kay]

It's working reasonably well here, but there's glitches with Android
devices. After a while they either say the AP is 'out of range' or 'saved'
with the non functional option to connect. That's with both an Androided
ICS HP Touchpad and a Sony Ericcson Xperia Pro with latest official ICS.

Sadly the net is not particularly forthcoming with whether this is
ultimately an access point or Android issue. Windows works fine.

I also had one complete wireless failure, but that could easily have been
another issue/hardware, as I managed to pull out the power cable when
fitting a video cable to check the console..

athn0 at pci0 dev 15 function 0 Atheros AR5416 rev 0x01: irq 3
athn0: MAC AR5416 rev 2, RF AR2133 (3T2R), ROM rev 5, address ...

Cheers - this is much appreciated!

Peter

On 10 September 2012 19:21, Jan Stary h...@stare.cz wrote:

 On Aug 18 10:40:23, Mark Kettenis wrote:
  Finally got annoyed enough that my MacBook running OS X (don't ask)
  didn't work too well on my OpenBSD AP at home.  The reason is the
  following caveat listed in the athn(4) man page:
 
   Host AP mode doesn't support power saving.  Clients attempting to
 use
   power saving mode may experience significant packet loss (disabling
 power
   saving on the client will fix this).

 Same here.

  Unfortunately Steve doesn't allow you to disable power saving.  So
  here is a diff to make athn(4) in host AP mode handle clients that use
  power saving.  The Mac is much happier now.
 
  Further testing would be welcome.  Even if you don't use clients with
  power saving enabled.  So if you're running an athn(4) based AP,
  please give this a spin.

 This diff seems to be in the tree already, and in the snapshots,
 so I upgraded my i386 AP to current, and indeed, the connections
 from my macbook via wifi no longer die out.

 Thank you!

 Jan

Re: Source Overview

[Peter Kay (Syllopsium)]

From: Bret S. Lambert blamb...@openbsd.org

Or, in short, we need to not deter people straight away, and accept that
perhaps sometimes decent programmers start from ones that make lots
of mistakes.

Perhaps a ports TODO similar to the NetBSD ports TODO might help; it
doesn't require quite the same level of kernel or userspace hacking and
provides very visible feedback and thanks once completed.


But you're also missing a big point: if someone can't figure out what
needs to be fixed, or is incapable of mustering enough motivation to
do the work, then they're not as useful to us as someone who can do
one or the other (or hopefully both).

tedu@ once said that there's an entrance exam to get an account; this
happens to be part of it, IMO.

Sure, and I understand that viewpoint. It's a valid one provided we want the
OpenBSD community to stay as it is.

I tend to think there's an in-between option. If I think back to some of my
earlier coding days, say on OS/2, and omit the coding I did as part of work,
most of it never saw the light of day. Some of it was just me playing around
with code and often I found other ways of achieving the aim that rendered 
the

code useless.

I never did (and probably never would at the time) get around to coding
anything serious, but I did port a number of apps - at the time it was 
pretty

easy.

Surely people can move on from the low hanging fruit of a port that needs
a ./configure  make install, to minor code or makefile changes, to specific
new functionality to from the scratch coding. Certainly, if at the time 
someone

with zero coding knowledge had asked for a port and it was trivial, I would
certainly have done it.

PK