Re: iwn failure on -current (XEN3_DOM0)

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

I just upgraded my EliteBook laptop with -current from 18th of
November. XEN3_DOM0 again timeouts on ehci in a loop taking about two
minutes, after which it panics with a message about a recursive panic;
no crash dump is generated.

On the other hand my older XEN3_DOM0 from 8.99.5 continues to work
fine with xen.gz 4.8.2, on this I also have iwn0 working as expected
(although not the bridging, of course, I am doing the bridging through
wm0, which works fine - the DOMU can access the Internet through this
bridge, then over to an ICS connection through my W10 laptop, being
used for a fast wifi link between two floors, then the Virgin Media
SH3 etc... ).

So there is some regression as far as Xen is concerned around the USB
subsystem. Again it may be relevant to port-xen@, so I am forwarding
there as well.

Chavdar Ivanov


On 19 November 2017 at 22:21, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
> Thanks for the tip!
>
> On Sun, 19 Nov 2017 at 18:31, <maya%netbsd.org@localhost> wrote:
>>
>> On Sun, Nov 19, 2017 at 11:11:44AM +0000, Chavdar Ivanov wrote:
>> > Here my point was that iwn used to work under XEN3_DOM0 a few months
>> > ago and is not working now, which may indicate some problem or
>> > regression elsewhere, which was the main reason for my question.
>>
>> 'Git bisect' is a good way to quickly point out issues, you can
>> probably bisect iwn file changes only.
>>
>> > the way, speedtest.net maybe a lame way to test a wifi connection, but
>> > on mine (200mb/s cable) connection, running -current with iwn gives me
>> > about 23mb/s, whereas on the same hardware / dns / router etc. some
>> > Linux gives me about 57 mb/s ( I do get my full about 212mb/s when
>> > running the test over AC7275 wifi from my W10 laptop, so it is not the
>> > infrastructure, with the possible exception that NetBSD runs off a
>> > HDD, whereas the Linux distro off an SSD, but that probably doesn't
>> > matter here. ).
>>
>> it looks like in your scenario:
>> netbsd: 802.11g
>> linux: 802.11n
>> windows : 802.11ac
>>
>> netbsd lacks stack support for 802.11n/ac, but also would need to adapt
>> the driver for it once it happens.



-- 
----