Re: ath10k driver status?

2019-02-11 Thread Adrian Chadd
hi,

I'm trying to update things with Geramy right now. We hit a snag where his
updates broke my QCA9880 NIC in STA mode, so we're working through that
right now.



-adrian


On Mon, 11 Feb 2019 at 09:51, Ben Widawsky  wrote:

> On 19-02-04 00:29:29, Anthony Jenkins wrote:
>
> [snip]
>
> Hi Adrian. I too am wondering what the plan is for this chipset. I am
> currently
> using an awful USB wifi dongle. I can help with testing if needed - but I
> just
> really want to know if we should expect upstream support which is
> relatively
> stable in the next month or two. If not, I'll look for alternative
> solutions.
>
> Thanks.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: ath(4) issues?

2018-11-23 Thread Adrian Chadd
hi!

No. It's a side effect of how ath_rate_sample works. The TL;DR is:

* ath_rate_sample uses a fixed set of rates for each attempt - so say you
want to transmit at 54MBit OFDM, the second/third/fourth slower rates are
in a fixed table;
* net80211 negotiates which rates are acceptable to the hostap;
* a lot of hostaps these days are increasingly disabling doing the lower
OFDM/CCK rates so slower clients don't tie up so much air;
* .. but they'll still RECEIVE and ACK those frames, so:
* + you'll fail say, 54mbit
* + and 48mbit
* + then try something like 12mbit on the third attept, which the hostap
didn't negotiate with you; and
* + it ACKs it, cause it still receives it fine; then
* + ath_rate_sample complains that it got a completion for a rate it's not
supposed to use.

They're harmless. You can comment it out for now; I really need to fix
ath_rate_sample to use a dynamic table rather than the array of static
tables..



-adrian


On Thu, 22 Nov 2018 at 09:05, Steve Kargl 
wrote:

> I have an old D-Link AirPlus G (DWL-630) pccard card
> that I have used for years with FreeBSD.  Recently,
> I see
>
> % dmesg | grep ath
> mobile:kargl[201] dmesg | grep ath
> [ath_hal] loaded
> [ath_dfs] loaded
> [ath_rate] loaded
> [ath] loaded
> ath0:  irq 19 at device 0.0 on cardbus0
> ath0: AR2413 mac 7.8 RF2413 phy 4.5
> ath0: 2GHz radio: 0x; 5GHz radio: 0x0056
> ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0, final_rix=0
> ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0
> ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0, final_rix=0
> ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0
> ath0: bad series0 hwrate 0x1b, tries 2 ts_status 0x1
>
>
> The "bad series0 hwrate..." message fills syslog.  This message
> appearred with a month or so old /usr/src and an update to top
> of tree (r340736) still produces the message.
>
> So, is this a hardware-about-to-die issue or did someone break
> ath(4) with the recent changes to inet?
>
> % sysctl -a | grep ath | grep -v path
> net.wlan.0.%parent: ath0
> net.wlan.devices: ath0 wpi0
> hw.ath.bstuck: 4
> hw.ath.txbuf_mgmt: 32
> hw.ath.txbuf: 200
> hw.ath.rxbuf: 40
> hw.ath.anical: 100
> hw.ath.resetcal: 1200
> hw.ath.shortcal: 100
> hw.ath.longcal: 30
> irq19: cbb0 ath0:37 @cpu0(domain0): 53227
> dev.ath.0.hal.serialise_reg_war: 0
> dev.ath.0.hal.force_full_reset: 0
> dev.ath.0.hal.swba_backoff: 0
> dev.ath.0.hal.sw_brt: 10
> dev.ath.0.hal.dma_brt: 2
> dev.ath.0.hal.ar5416_biasadj: 0
> dev.ath.0.hal.debug: 0
> dev.ath.0.stats.sync_intr.31: 0
> dev.ath.0.stats.sync_intr.30: 0
> dev.ath.0.stats.sync_intr.29: 0
> dev.ath.0.stats.sync_intr.28: 0
> dev.ath.0.stats.sync_intr.27: 0
> dev.ath.0.stats.sync_intr.26: 0
> dev.ath.0.stats.sync_intr.25: 0
> dev.ath.0.stats.sync_intr.24: 0
> dev.ath.0.stats.sync_intr.23: 0
> dev.ath.0.stats.sync_intr.22: 0
> dev.ath.0.stats.sync_intr.21: 0
> dev.ath.0.stats.sync_intr.20: 0
> dev.ath.0.stats.sync_intr.19: 0
> dev.ath.0.stats.sync_intr.18: 0
> dev.ath.0.stats.sync_intr.17: 0
> dev.ath.0.stats.sync_intr.16: 0
> dev.ath.0.stats.sync_intr.15: 0
> dev.ath.0.stats.sync_intr.14: 0
> dev.ath.0.stats.sync_intr.13: 0
> dev.ath.0.stats.sync_intr.12: 0
> dev.ath.0.stats.sync_intr.11: 0
> dev.ath.0.stats.sync_intr.10: 0
> dev.ath.0.stats.sync_intr.9: 0
> dev.ath.0.stats.sync_intr.8: 0
> dev.ath.0.stats.sync_intr.7: 0
> dev.ath.0.stats.sync_intr.6: 0
> dev.ath.0.stats.sync_intr.5: 0
> dev.ath.0.stats.sync_intr.4: 0
> dev.ath.0.stats.sync_intr.3: 0
> dev.ath.0.stats.sync_intr.2: 0
> dev.ath.0.stats.sync_intr.1: 0
> dev.ath.0.stats.sync_intr.0: 0
> dev.ath.0.stats.rx_phy_err.63: 0
> dev.ath.0.stats.rx_phy_err.62: 0
> dev.ath.0.stats.rx_phy_err.61: 0
> dev.ath.0.stats.rx_phy_err.60: 0
> dev.ath.0.stats.rx_phy_err.59: 0
> dev.ath.0.stats.rx_phy_err.58: 0
> dev.ath.0.stats.rx_phy_err.57: 0
> dev.ath.0.stats.rx_phy_err.56: 0
> dev.ath.0.stats.rx_phy_err.55: 0
> dev.ath.0.stats.rx_phy_err.54: 0
> dev.ath.0.stats.rx_phy_err.53: 0
> dev.ath.0.stats.rx_phy_err.52: 0
> dev.ath.0.stats.rx_phy_err.51: 0
> dev.ath.0.stats.rx_phy_err.50: 0
> dev.ath.0.stats.rx_phy_err.49: 0
> dev.ath.0.stats.rx_phy_err.48: 0
> dev.ath.0.stats.rx_phy_err.47: 0
> dev.ath.0.stats.rx_phy_err.46: 0
> dev.ath.0.stats.rx_phy_err.45: 0
> dev.ath.0.stats.rx_phy_err.44: 0
> dev.ath.0.stats.rx_phy_err.43: 0
> dev.ath.0.stats.rx_phy_err.42: 0
> dev.ath.0.stats.rx_phy_err.41: 0
> dev.ath.0.stats.rx_phy_err.40: 0
> dev.ath.0.stats.rx_phy_err.39: 0
> dev.ath.0.stats.rx_phy_err.38: 0
> dev.ath.0.stats.rx_phy_err.37: 0
> dev.ath.0.stats.rx_phy_err.36: 0
> dev.ath.0.stats.rx_phy_err.35: 0
> dev.ath.0.stats.rx_phy_err.34: 0
> dev.ath.0.stats.rx_phy_err.33: 0
> dev.ath.0.stats.rx_phy_err.32: 0
> dev.ath.0.stats.rx_phy_err.31: 1875
> dev.ath.0.stats.rx_phy_err.30: 0
> dev.ath.0.stats.rx_phy_err.29: 0
> dev.ath.0.stats.rx_phy_err.28: 0
> dev.ath.0.stats.rx_phy_err.27: 0
> dev.ath.0.stats.rx_phy_err.26: 0
> dev.ath.0.stats.rx_phy_err.25: 0
> dev.ath.0.stats.rx_phy_err.24: 0
> 

Re: ath(4) issues?

2018-11-23 Thread Adrian Chadd
And I think 0x1b is "1mbit CCK", so I bet that's disabled on your AP?


On Fri, 23 Nov 2018 at 11:28, Adrian Chadd  wrote:

> hi!
>
> No. It's a side effect of how ath_rate_sample works. The TL;DR is:
>
> * ath_rate_sample uses a fixed set of rates for each attempt - so say you
> want to transmit at 54MBit OFDM, the second/third/fourth slower rates are
> in a fixed table;
> * net80211 negotiates which rates are acceptable to the hostap;
> * a lot of hostaps these days are increasingly disabling doing the lower
> OFDM/CCK rates so slower clients don't tie up so much air;
> * .. but they'll still RECEIVE and ACK those frames, so:
> * + you'll fail say, 54mbit
> * + and 48mbit
> * + then try something like 12mbit on the third attept, which the hostap
> didn't negotiate with you; and
> * + it ACKs it, cause it still receives it fine; then
> * + ath_rate_sample complains that it got a completion for a rate it's not
> supposed to use.
>
> They're harmless. You can comment it out for now; I really need to fix
> ath_rate_sample to use a dynamic table rather than the array of static
> tables..
>
>
>
> -adrian
>
>
> On Thu, 22 Nov 2018 at 09:05, Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
>> I have an old D-Link AirPlus G (DWL-630) pccard card
>> that I have used for years with FreeBSD.  Recently,
>> I see
>>
>> % dmesg | grep ath
>> mobile:kargl[201] dmesg | grep ath
>> [ath_hal] loaded
>> [ath_dfs] loaded
>> [ath_rate] loaded
>> [ath] loaded
>> ath0:  irq 19 at device 0.0 on cardbus0
>> ath0: AR2413 mac 7.8 RF2413 phy 4.5
>> ath0: 2GHz radio: 0x; 5GHz radio: 0x0056
>> ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0, final_rix=0
>> ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0
>> ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0, final_rix=0
>> ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0
>> ath0: bad series0 hwrate 0x1b, tries 2 ts_status 0x1
>>
>>
>> The "bad series0 hwrate..." message fills syslog.  This message
>> appearred with a month or so old /usr/src and an update to top
>> of tree (r340736) still produces the message.
>>
>> So, is this a hardware-about-to-die issue or did someone break
>> ath(4) with the recent changes to inet?
>>
>> % sysctl -a | grep ath | grep -v path
>> net.wlan.0.%parent: ath0
>> net.wlan.devices: ath0 wpi0
>> hw.ath.bstuck: 4
>> hw.ath.txbuf_mgmt: 32
>> hw.ath.txbuf: 200
>> hw.ath.rxbuf: 40
>> hw.ath.anical: 100
>> hw.ath.resetcal: 1200
>> hw.ath.shortcal: 100
>> hw.ath.longcal: 30
>> irq19: cbb0 ath0:37 @cpu0(domain0): 53227
>> dev.ath.0.hal.serialise_reg_war: 0
>> dev.ath.0.hal.force_full_reset: 0
>> dev.ath.0.hal.swba_backoff: 0
>> dev.ath.0.hal.sw_brt: 10
>> dev.ath.0.hal.dma_brt: 2
>> dev.ath.0.hal.ar5416_biasadj: 0
>> dev.ath.0.hal.debug: 0
>> dev.ath.0.stats.sync_intr.31: 0
>> dev.ath.0.stats.sync_intr.30: 0
>> dev.ath.0.stats.sync_intr.29: 0
>> dev.ath.0.stats.sync_intr.28: 0
>> dev.ath.0.stats.sync_intr.27: 0
>> dev.ath.0.stats.sync_intr.26: 0
>> dev.ath.0.stats.sync_intr.25: 0
>> dev.ath.0.stats.sync_intr.24: 0
>> dev.ath.0.stats.sync_intr.23: 0
>> dev.ath.0.stats.sync_intr.22: 0
>> dev.ath.0.stats.sync_intr.21: 0
>> dev.ath.0.stats.sync_intr.20: 0
>> dev.ath.0.stats.sync_intr.19: 0
>> dev.ath.0.stats.sync_intr.18: 0
>> dev.ath.0.stats.sync_intr.17: 0
>> dev.ath.0.stats.sync_intr.16: 0
>> dev.ath.0.stats.sync_intr.15: 0
>> dev.ath.0.stats.sync_intr.14: 0
>> dev.ath.0.stats.sync_intr.13: 0
>> dev.ath.0.stats.sync_intr.12: 0
>> dev.ath.0.stats.sync_intr.11: 0
>> dev.ath.0.stats.sync_intr.10: 0
>> dev.ath.0.stats.sync_intr.9: 0
>> dev.ath.0.stats.sync_intr.8: 0
>> dev.ath.0.stats.sync_intr.7: 0
>> dev.ath.0.stats.sync_intr.6: 0
>> dev.ath.0.stats.sync_intr.5: 0
>> dev.ath.0.stats.sync_intr.4: 0
>> dev.ath.0.stats.sync_intr.3: 0
>> dev.ath.0.stats.sync_intr.2: 0
>> dev.ath.0.stats.sync_intr.1: 0
>> dev.ath.0.stats.sync_intr.0: 0
>> dev.ath.0.stats.rx_phy_err.63: 0
>> dev.ath.0.stats.rx_phy_err.62: 0
>> dev.ath.0.stats.rx_phy_err.61: 0
>> dev.ath.0.stats.rx_phy_err.60: 0
>> dev.ath.0.stats.rx_phy_err.59: 0
>> dev.ath.0.stats.rx_phy_err.58: 0
>> dev.ath.0.stats.rx_phy_err.57: 0
>> dev.ath.0.stats.rx_phy_err.56: 0
>> dev.ath.0.stats.rx_phy_err.55: 0
>> dev.ath.0.stats.rx_phy_err.54: 0
>> dev.ath.0.stats.rx_phy_err.53: 0
>> dev.ath.0.stats.rx_phy_err.52: 0
>> dev.ath.0.stats.rx_phy_err

Re: numa involved in instability and swap usage despite RAM free?

2018-06-26 Thread Adrian Chadd
Hi,

Aren't there now per-domain VM counters you can query via sysctl?
Maybe they'd help in diagnosing what's going on.



-adrian

On Mon, 25 Jun 2018 at 11:23, Steve Kargl
 wrote:
>
> On Sun, Jun 24, 2018 at 12:03:29PM +0200, Alexander Leidinger wrote:
> >
> > I don't have hard evidence, but there is enough "smell" to open up a
> > discussion...
> >
> > Short:
> > Can it be that enabling numa in the kernel is the reason why some
> > people see instability with zfs and usage of swap while a lot of free
> > RAM is available?
>
> Interesting observation.  I do have NUMA in my kernel, and swap
> seems to be used instead of recycling freeing inactive memory.
> Top shows
>
> Mem: 506M Active, 27G Inact, 98M Laundry, 2735M Wired, 1474M Buf, 1536M Free
> Swap: 16G Total, 120M Used, 16G Free
>
> Perhaps, I don't understand what is meant by inactive memory.  I
> thought that this means memory is still available in the buffer
> cache, but nothing is current using what is there.
>
> --
> Steve
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Can't seem to use 5GHz APs with Intel wireless

2018-06-13 Thread Adrian Chadd
hm. Which country are you in? india?

It seems to think you're in the FCC4 regdomain and DE country, which
if I read it right won't give you 5G. So somehow it determined you're
in the "wrong" country?



-adrian

On Mon, 4 Jun 2018 at 07:15, Adam  wrote:
>
> On Sun, Jun 3, 2018 at 9:50 PM, Dhananjay Balan  wrote:
>
> > On Sun, Jun 03, 2018 at 07:33:30PM +0200, Christoph Moench-Tegeder wrote:
> >
> > > Is the regdomain/country setting correct for your area and matches your
> > > AP? Especially in the 5GHz band there are some "gaps" - not all channels
> > > may be used in all countries (because of possible interference with
> > > radar equipment and other stuff). See:
> > > https://en.wikipedia.org/wiki/List_of_WLAN_channels#5_GHz_(
> > 802.11a/h/j/n/ac/ax)
> > >
> >
> > Thanks for taking time to explain.
> >
> > Turns out PEBKAC. I had this offending line burried in rc.conf
> >
> > create_args_wlan0="country DE regdomain FCC4"
> >
> > According to regdomain(5) 
> >
> > So I was forcing my card to do 2.4Ghz it seems, removed it - everything
> > worked like charm. I can see and connect to 5GHz 11a aps.
> >
> > wlan0: flags=8843 metric 0 mtu
> > 1500
> > ether 
> > inet 192.168.1.13 netmask 0xff00 broadcast 192.168.1.255
> > nd6 options=29
> > media: IEEE 802.11 Wireless Ethernet MCS mode 11na
> > status: associated
> > ssid  channel 36 (5180 MHz 11a ht/40+) bssid 
> > regdomain FCC country US authmode WPA2/802.11i privacy ON
> > deftxkey UNDEF TKIP 2:128-bit txpower 17 bmiss 10 mcastrate 6
> > mgmtrate 6 scanvalid 60 ampdulimit 64k ampdudensity 4 -amsdutx
> > amsdurx
> > shortgi -stbc -ldpc wme roaming MANUAL
> >
> >
> Thanks for the posting.  It appears I made some errors in my previous
> response.  I'm using an iwm, not iwn.  And after your pointer I changed my
> country to NO which then allows me to see, but not associate to 5gz.
>
> Good yours is working.
>
> --
> Adam
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [RFC] Deprecation and removal of the drm2 driver

2018-06-13 Thread Adrian Chadd
On Mon, 4 Jun 2018 at 22:36, Matthew Macy  wrote:
>
> Implementing a callback in 140 different files for the sake of a handful of 
> out of tree drivers and people not reading updating is pretty prohibitive. 11 
> may be more your cup of tea.

This was the in tree wifi drivers.. :-)

Dude, we're on the same side. I'll take a look at the multicast
iterator stuff once I figure out why the athp receive performance in
my driver is terrible-y.



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [RFC] Deprecation and removal of the drm2 driver

2018-06-04 Thread Adrian Chadd
Hi,

If there's an API that isn't being used then great, I'll go find it
and fix up pieces in my spare time to use it. But the last drive by
cut/paste didn't do that; it just changed the code in place. :-)



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [RFC] Deprecation and removal of the drm2 driver

2018-06-04 Thread Adrian Chadd
Hi,

As a driver/framework developer - no, don't do that.

It's worked mostly great for the video side of things because your
touch points are "the VM system" and "linuxkpi". And they're all in
one big driver pull from Linux.

For wifi as an example - it has a bunch of userland components, a
kernel framework component (net80211); it gets API churn from people
who keep making networking API changes without making them opaque (i
just got bitten by the STAILQ -> CK_STAILQ changes for multicast
iteration, instead of us growing a multicast iterator function thing.)

Having it be multiple drivers/firmware means that anyone doing wifi
development here would have to install /all/ of the relevant packages
and the net80211 stuff and userland just to get any work done and hope
it stays in sync.

It'd be nice if that was our stretch goal, but we ain't there yet.

As for your intel NIC - I'm sorry that you've had issues getting that
into the tree but you can just jump in #freebsd-wifi and whine at us
until we commit it. That's what we're there for.




-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Periodical interrupt storm when playing game with USB keyboard

2018-01-22 Thread Adrian Chadd
Hi

Yeah the timers eventually get coalesced unless someone's asking for a
ridciulously accurate timer value.

So is some driver asking for hyper-accurate callout timer that isn't
being coalesced? hps, is there any useful debugging to try and find
callouts that are requesting stupidly accurate timers? Maybe a dtrace
probe on the callout schedule entry point?



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Programmatically cache line

2017-12-31 Thread Adrian Chadd
On 30 December 2017 at 00:28, Konstantin Belousov  wrote:
> On Sat, Dec 30, 2017 at 07:50:19AM +, blubee blubeeme wrote:
>> Is there some way to programmatically get the CPU cache line sizes on
>> FreeBSD?
>
> There are, all of them are MD.
>
> On x86, the CPUID instruction leaf 0x1 returns the information in
> %ebx register.

Hm, weird. Why don't we extend sysctl to include this info?



-adrian

> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [mips32] build is broken due to lack of .cfi-sections support in gcc 4.2.1

2017-11-11 Thread Adrian Chadd
Hi,

Have a look at what the atheros ports now do. They've been building
using the external toolchain gcc for a while now.

I think we need to kick over to that.



-adrian


On 11 November 2017 at 12:54, Michael Zhilin  wrote:
> Hi,
>
> I've got compilation error for mips32 build by gcc 4.2.1
> (freebsd-wifi-build):
> [halloween:/repo/onion/src/libexec/rtld-elf]$ make
> /repo/onion/src/libexec/rtld-elf/mips/rtld_start.S: Assembler messages:
> /repo/onion/src/libexec/rtld-elf/mips/rtld_start.S:35: Error: unknown
> pseudo-op: `.cfi_sections'
> *** Error code 1
>
> Stop.
> make[2]: stopped in /repo/onion/src/libexec/rtld-elf
> [halloween:/repo/onion/src/libexec/rtld-elf]$ cc -isystem
> /repo/onion/obj/mipsel/repo/onion/src/mips.mipsel/tmp/usr/include
> -L/repo/onion/obj/mipsel/repo/onion/src/mips.mipsel/tmp/usr/lib
> -B/repo/onion/obj/mipsel/repo/onion/src/mips.mipsel/tmp/usr/lib
> --sysroot=/repo/onion/obj/mipsel/repo/onion/src/mips.mipsel/tmp
> -B/repo/onion/obj/mipsel/repo/onion/src/mips.mipsel/tmp/usr/bin -O -pipe -G0
> -EL -mabi=32 -msoft-float -march=mips32 -Wall -DFREEBSD_ELF -DIN_RTLD
> -ffreestanding -I/repo/onion/src/lib/csu/common
> -I/repo/onion/src/libexec/rtld-elf/mips -I/repo/onion/src/libexec/rtld-elf
> -fpic -DPIC -g -MD -MF.depend.rtld_start.o -MTrtld_start.o -std=gnu99
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
> -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c
> /repo/onion/src/libexec/rtld-elf/mips/rtld_start.S -o rtld_start.o
> /repo/onion/src/libexec/rtld-elf/mips/rtld_start.S: Assembler messages:
> /repo/onion/src/libexec/rtld-elf/mips/rtld_start.S:35: Error: unknown
> pseudo-op: `.cfi_sections'
> [halloween:/repo/onion/src/libexec/rtld-elf]$ cc -v
> Using built-in specs.
> Target: mipsel-undermydesk-freebsd
> Configured with: FreeBSD/mipsel system compiler
> Thread model: posix
> gcc version 4.2.1 20070831 patched [FreeBSD]
>
> The section info for call frame information has been added in revision
> 325624 by jhb@. This impacts several MIPS32 builds by freebsd-wifi-build
> (broadcom, may be atheros).
>
> Is my gcc toolchain old? switch to clang?
>
> Thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: iwm not in GENERIC kernel

2017-11-02 Thread Adrian Chadd
ugh okay

So it's a chicken/egg problem.

You can't finish the device probe/attach until the firmware loads.

For iwn, you can read the chipset abilities and mac address from
EPROM/flash on the chip without the firmware being loaded, so you can
complete probe/attach before the root filesystem is mounted.

For iwm, you have to load the firmware before you can read the chipset
abilities and MAC address so you can't complete probe/attach until
AFTER the root filesystem is mounted.

If someone wants to go add all of that support in to have probe/attach
deferred until after rootfs is available then please do so. Or, just
support the firmware being 100% compiled in- but when I tried this the
last time I ran out of some firmware arena size preventing other
firmware for other chipsets from being loaded.

Otherwise this is the current hack. :)

Sorry!



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: cve-2017-13077 - WPA2 security vulni

2017-10-23 Thread Adrian Chadd
[snip]

yes you need to rebuild; the ioctl layout changed between -11 and -12
to account for the beginnings of 11ac.



-adrian


On 17 October 2017 at 11:30, Cy Schubert  wrote:
> I had no problems last night. It associated with one of my netgear APs. I 
> used /etc/wpa_supplicant.conf.
>
> I am running head and all my ports are built on head (most poudeiere and a 
> few by hand).
>
> ---
> Sent using a tiny phone keyboard. Apologies for any typos and autocorrect.
>
> Cy Schubert
>  or 
>
> -Original Message-
> From: David Wolfskill
> Sent: 17/10/2017 09:57
> To: Allan Jude
> Cc: freebsd-current@freebsd.org
> Subject: Re: cve-2017-13077 - WPA2 security vulni
>
> On Tue, Oct 17, 2017 at 12:51:23PM -0400, Allan Jude wrote:
>> 
>> > Question:  Should one expect a wpa_supplicant-2.6_2 executable built
>> > under FreeBSD stable/11 (amd64) to work on the same hardware, but
>> > running head?
>>
>> Did you run the version from ports, or did you run the base /etc/rc.d
>> script with your rc.conf set to point to the ports binary? This will run
>> the command with -c /etc/wpa_supplicant.conf overriding the ports default.
>>
>> So this is expected to work in this way.
>
> Ah.  When I installed the port, I was reminded:
>
> | ...
> | ===>   Registering installation for wpa_supplicant-2.6_2
> | Installing wpa_supplicant-2.6_2...
> | To use the ports version of WPA Supplicant instead of the base, add:
> |
> | wpa_supplicant_program="/usr/local/sbin/wpa_supplicant"
> |
> | to /etc/rc.conf
> |
> | ===> SECURITY REPORT:
> | 
>
> So I did that.  I did not do anything to the existing
> /etc/rc.d/wpa_supplicant, which had been installed as part of base
> FreeBSD.
>
>> 
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Unsubstantiated claims of "Fake News" are evidence that the claimant lies 
> again.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: cve-2017-13077 - WPA2 security vulni

2017-10-16 Thread Adrian Chadd
Right, there are backported patches against 2.6, but we're running 2.5
in contrib/ .

This is all "I'm out of time right now", so if someone wants to do the
ports work and/or the contrib work with the patches for this vuln then
please do. I should be able to get to it in the next few days but I'm
busy with family and employment.



-adrian


On 16 October 2017 at 10:19, Kevin Oberman <rkober...@gmail.com> wrote:
> On Mon, Oct 16, 2017 at 8:55 AM, Adrian Chadd <adrian.ch...@gmail.com>
> wrote:
>>
>> hi,
>>
>> I got the patches a couple days ago. I've been busy with personal life
>> stuff so I haven't updated our in-tree hostapd/wpa_supplicant. If
>> someone beats me to it, great, otherwise I'll try to do it in the next
>> couple days.
>>
>> I was hoping (!) for a hostap/wpa_supplicant 2.7 update to just update
>> everything to but so far nope. It should be easy enough to update the
>> port for now as it's at 2.6.
>>
>>
>>
>> -adrian
>>
>>
>> On 16 October 2017 at 06:04, Cy Schubert <cy.schub...@komquats.com> wrote:
>> > In message <44161b4d-f834-a01d-6ddb-475f20876...@freebsd.org>, Lev
>> > Serebryakov
>> > writes:
>> >> On 16.10.2017 13:38, blubee blubeeme wrote:
>> >>
>> >> > well, that's a cluster if I ever seen one.
>> >>  It is really cluster: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079,
>> >> CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084,
>> >> CVE-2017-13086,CVE-2017-13087, CVE-2017-13088.
>> >
>> > The gory details are here:
>> > https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt
>> >
>> > The announcement is here:
>> > https://www.krackattacks.com/
>> >
>> >
>> > --
>> > Cheers,
>> > Cy Schubert <cy.schub...@cschubert.com>
>> > FreeBSD UNIX:  <c...@freebsd.org>   Web:  http://www.FreeBSD.org
>> >
>> > The need of the many outweighs the greed of the few.
>> >
>
>
> While I do not encourage waiting, it is quite likely that the upstream patch
> wil show up very soon now that the vulnerability is public.
>
> It's also worth noting that fixing either end of the connection is all that
> is required, as I understand it. So getting an update for your AP is not
> required. That is very fortunate as the industry has a rather poor record of
> getting out firmware updates for hardware more than a few months old. Also,
> it appears that Windows and iOS are not vulnerable due to flaws in their
> implementation of the WPA2 spec. (Of course, if you update your AP(s), you
> no longer need to worry about your end devices.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: cve-2017-13077 - WPA2 security vulni

2017-10-16 Thread Adrian Chadd
hi,

I got the patches a couple days ago. I've been busy with personal life
stuff so I haven't updated our in-tree hostapd/wpa_supplicant. If
someone beats me to it, great, otherwise I'll try to do it in the next
couple days.

I was hoping (!) for a hostap/wpa_supplicant 2.7 update to just update
everything to but so far nope. It should be easy enough to update the
port for now as it's at 2.6.



-adrian


On 16 October 2017 at 06:04, Cy Schubert  wrote:
> In message <44161b4d-f834-a01d-6ddb-475f20876...@freebsd.org>, Lev Serebryakov
> writes:
>> On 16.10.2017 13:38, blubee blubeeme wrote:
>>
>> > well, that's a cluster if I ever seen one.
>>  It is really cluster: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079,
>> CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084,
>> CVE-2017-13086,CVE-2017-13087, CVE-2017-13088.
>
> The gory details are here: 
> https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt
>
> The announcement is here:
> https://www.krackattacks.com/
>
>
> --
> Cheers,
> Cy Schubert 
> FreeBSD UNIX:     Web:  http://www.FreeBSD.org
>
> The need of the many outweighs the greed of the few.
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Ports still broken by ino64?

2017-06-26 Thread Adrian Chadd
I'm sure stas can figure it out!


-a


On 25 June 2017 at 22:44, Thomas Mueller <mueller6...@twc.com> wrote:
> from Adrian Chadd:
>
>> valgrind broke as part of the ino64 work :(
>
> Valgrind was not on my mind!  Your post sent me to
>
> ls -d /usr/ports/*/val*
>
> to find valgrind, and then read the pkg-descr.
>
> One less tool for getting debugging information when something crashes?
>
> Tom
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Ports still broken by ino64?

2017-06-25 Thread Adrian Chadd
Hi,

valgrind broke as part of the ino64 work :(


-a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [RESOLVED] Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11

2017-06-23 Thread Adrian Chadd
hi!

Thanks! Yes please let's update the handbook at least.


-a


On 23 June 2017 at 10:06, Renato Botelho <ga...@freebsd.org> wrote:
> On 23/06/17 13:43, Adrian Chadd wrote:
>> Hi,
>>
>> You can't change a wifi mac address /after the interface is up/. So if
>> that's happening with this RC script combination then we should kinda
>> fix that.
>
> OK, so in the end I managed to make it work without any kernel change.
> This is how rc.conf look like, as pointed out by András Krasznai.
>
> ifconfig_em0="up"
> wlans_iwn0="wlan0"
> ifconfig_wlan0="WPA"
> create_args_wlan0="wlanaddr 3c:97:0e:48:3f:f8"
> cloned_interfaces="lagg0"
> ifconfig_lagg0="up laggproto failover laggport em0 laggport wlan0 DHCP"
>
> So now the only remaining issue is related to docs. lagg(4) manpage
> example and Handbook must be fixed
>
> Thank you all for the help
> --
> Renato Botelho
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11

2017-06-23 Thread Adrian Chadd
Hi,

You can't change a wifi mac address /after the interface is up/. So if
that's happening with this RC script combination then we should kinda
fix that.


-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [rfc] breaking out if_ath into ... lots of modules

2017-05-22 Thread Adrian Chadd
On 22 May 2017 at 13:17, John Baldwin  wrote:

> Why not have if_ath.ko just be a wrapper module that depends on everything
> like dtraceall.ko?  That would let 'kldload if_ath' and the auto-loading
> code in ifconfig still DTRT.  You could name the "only the driver" module
> ath.ko or some such.

Oh yeah, I could also do that to reduce POLA. :)

Ok, I'll add that to the TODO list before I submit a review. I'll
rename if_ath to if_ath_drv or something.

-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


[rfc] breaking out if_ath into ... lots of modules

2017-05-22 Thread Adrian Chadd
Hi,

I've been putting this off for a few years, but now I've reached a
point where I kind of need to do this.

The TL;DR is this - I'd like to break the ath driver /back/ out into
separate modules, and then have them be run-time loadable. It's part
for space savings, and part for the upcoming ath10k work where I need
to reuse the regulatory EEPROM code.

The reason? I can't easily build a modular ath driver without
compiling in /everything/. For the AR933x/AR934x embedded platforms
which don't require the previous HAL chipset code, this is almost
800kbyte extra binary code in the kernel that doesn't ever get run.
For earlier boards (say the AR9280 embedded boards), it's roughly
600kbyte of AR9300 HAL code that doesn't ever get run.

I have a patchset (which I'll push up soon) which turns if_ath into:

* if_ath - only the driver;
* (if_ath_pci / if_ath_ahb stay the same);
* ath_hal - only the shared, global HAL code (osdep routines, HAL
core, regulatory code);
* ath_rate - the ath rate control code (either sample, amrr, onoe);
* ath_dfs - just dfs_null for now, but this will eventually be a radar detector;
* ath_hal_{ar5210,ar5211,ar5212,ar5416,ar9300} - the individual chipset HALs.

Now, I'm thinking of further breaking out ar5416 into
{ar5416,ar9001,ar9002} just to save space for the embedded builds
(like AR9103/AR9106 which some people still use) but that can come
later.

There's no AR2312/AR5312 11abg + MIPS4k core support in FreeBSD, so
I'll go and look at making the AR5312 wifi support work. That'll
become another HAL module.

On the regulatory side, I then need to divorce the EEPROM regulatory
code from ath_hal and turn /it/ into a separate module because,
surprise, the ath10k 11ac hardware uses the same regulatory code. I'll
do this particular step later.

What does this mean?

* If you compile up a kernel with everything in it, nothing will
change - hopefully this is the majority of users;
* If you compile a modular kernel or embedded platform - you need to
load ath_hal and the relevant HAL modules before you load if_ath /
if_ath_pci otherwise it won't find your hardware.

I realise this is a bit of a POLA change, but I'd like to get it into
-HEAD before FreeBSD-12 is cut.

Thanks!



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: make concurrency kit a module

2017-05-19 Thread Adrian Chadd
On 17 May 2017 at 23:37, Warner Losh <i...@bsdimp.com> wrote:
> On Wed, May 17, 2017 at 11:53 PM, Baptiste Daroussin <b...@freebsd.org> wrote:
>> On Wed, May 17, 2017 at 06:04:09PM -0700, Adrian Chadd wrote:
>>> https://reviews.freebsd.org/D10778
>>>
>>
>> Except there are plans to use it elsewhere. Many areas may be improved using 
>> it.
>>
>> Having it as a module would mean some devs might refrain from using it 
>> because
>> there is no waranty for it to be there
>>
>> Areas like VFS and network stack could have a good benefice from using it.
>>
>> Out of curiousity what size is saved?
>
> I'd planned on using it newbus to solve the lifetime issues we have
> with device_t's

I'm happy with things using it in base outside of the linuxkpi.

I'm just trying to push back on the "death by a thousand cuts" that
the IOT platforms face for size constraints. There's plenty of stuff
in the base kernel that storage challenged platforms don't need but
they're not introduced or kept as modules.

It's 2017 and people /are still/ making embedded boards with 8MB of NOR flash.



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: make concurrency kit a module

2017-05-17 Thread Adrian Chadd
https://reviews.freebsd.org/D10778


-a


On 17 May 2017 at 17:46, Adrian Chadd <adr...@freebsd.org> wrote:
> hi,
>
> this is a quick change that makes concurrency_kit a module. Right now
> the only thing using it is linuxkpi so it's all dead code on
> non-linuxkpi platforms.
>
>
>
> -adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


make concurrency kit a module

2017-05-17 Thread Adrian Chadd
hi,

this is a quick change that makes concurrency_kit a module. Right now
the only thing using it is linuxkpi so it's all dead code on
non-linuxkpi platforms.



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: regression suspend/resume on Lenovo T420

2017-05-01 Thread Adrian Chadd
There were lots of commits that could break things. :-)


Can you compile up some intermediary versions between 315141 and
r317559 to find which commit range broke things? That'll make chasing
it down much quicker!

Thanks!


-a


On 29 April 2017 at 04:50, Manuel Stühn  wrote:
> Hi,
> I'd been sucessfully running CURRENT on my Lenovo T420 with functional
> suspend/resume since some time. But after updating to CURRENT r317032
> respectively r317559 suspend/resume does not work anymore. Putting it into
> suspend results only in a black screen, but no further action is possible
> (only pressing the powerbutton for some time to switch it off completely).
> The LEDs are not indicating any suspend mode.
> If i try to suspend it with X (intel-driver) stopped, the laptop does switch
> into suspend, but does not resume. It runs into some kind of resuming
> endless loop, where it tries to start the laptop again but at a certain
> point it restarts again. The screen stays dark all the time.
>
> I tried this with and without the following options but the same result.
> hw.acpi.reset_video=1
> dev.acpi_ibm.0.handlerevents='0x04'
>
> Booting a Bootenvironment with an older CURRENT(r315141), all is working.
> Was there any change between these commits concerning suspend/resume?
>
> BR
> Manuel
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: increased power consumption lately?

2017-04-26 Thread Adrian Chadd
can you file a bugzilla bug with this information in it? What's
triggering the interrupt?


-a


On 20 April 2017 at 02:05, Johannes Lundberg <johal...@gmail.com> wrote:
> I found another solution. Modifying the DSDT file by removing
>
> Method (_L06, 0, NotSerialized)  // _Lxx: Level-Triggered GPE
> {
> If (LAnd (\_SB.PCI0.IGPU.GSSE, LNot (GSMI)))
> {
> \_SB.PCI0.IGPU.GSCI ()
> }
> Else
> {
> Store (0x00, \_SB.PCI0.IGPU.GEFC)
> Store (0x01, SCIS) /* \SCIS */
> Store (0x00, \_SB.PCI0.IGPU.GSSE)
> Store (0x00, \_SB.PCI0.IGPU.SCIE)
> }
> }
>
> seem to solve the problem, as discussed here
> https://bugs.freedesktop.org/show_bug.cgi?id=98501
>
> I will keep an eye on that bug report and see what happens.
> I should also mention that I am running the Linux i915kms driver
> https://github.com/FreeBSDDesktop/freebsd-base-graphics
>
> Since we're constantly merging updates from Linux maybe there will be a fix
> for this soon.
>
>
>
> On Thu, Apr 20, 2017 at 10:35 AM, Johannes Lundberg <johal...@gmail.com>
> wrote:
>>
>> Seem like a temporary solution on Linux is to disable the interrupt. Can
>> this be done on FreeBSD somehow?
>>
>> On Thu, Apr 20, 2017 at 10:09 AM, Johannes Lundberg <johal...@gmail.com>
>> wrote:
>>>
>>> Thanks Ngie, that was a good one!  (I really need to learn dtrace...)
>>>
>>> Got this among other:
>>>
>>> AcpiNsLookup:entry PathInfo: \/ _SB_PCI0IGPUGSSE�GSMI\/
>>> _SB_PCI0IGPUGSCI�K p
>>>
>>> Might be related to:
>>> https://bugs.freedesktop.org/show_bug.cgi?id=98501
>>>
>>>
>>>
>>> On Wed, Apr 5, 2017 at 8:15 PM, Ngie Cooper (yaneurabeya)
>>> <yaneurab...@gmail.com> wrote:
>>>>
>>>>
>>>> > On Apr 5, 2017, at 10:39, Adrian Chadd <adr...@freebsd.org> wrote:
>>>> >
>>>> > hm, you could use dtrace to find what's calling that function and
>>>> > print out the call stack?
>>>>
>>>> *does shrug* something like this (I realize it’s not printing
>>>> out arg0 — arg0 is a union that would need decoding)?
>>>> Thanks,
>>>> -Ngie
>>>>
>>>> $ cat AcpiNsLookup.d
>>>> fbt:kernel:AcpiNsLookup:entry
>>>> {
>>>> printf("PathInfo: %s\nType: %d\nFlags: %u",
>>>> stringof(arg1), arg2, arg3);
>>>> }
>>>> $ sudo dtrace -s AcpiNsLookup.d
>>>
>>>
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: altq and head

2017-04-26 Thread Adrian Chadd
It'll be supported as much as someone is willing to pay for it.

It isn't out of the realm of possibility to implement an if_transmit
style layer for altq, etc so it could be a generic queue discipline.
It'd be nice to have a multi-queue version of this but we're not there
yet.

Thanks,



-adrian

On 25 April 2017 at 07:43, Nick Rogers  wrote:
> On Sat, Apr 8, 2017 at 3:55 AM, Eugene M. Zheganin  wrote:
>> Hi,
>>
>> regarding all this stir around ALTQ and igb(4), and mentioning that igb(4)
>> doesn't have ALTQ in HEAD - I wanted to ask - is this just igb(4) and
>> ixgbe(4) that lost ALTQ in HEAD, or is ALTQ being removed totally from
>> FreeBSD ? I did a couple of searches, but seems like I cannot find the
>> simple answer.
>
> I'm also curious what the plan is w.r.t ALTQ. I definitely depend on
> igb supporting it... Thanks.
>
>>
>>
>> Thanks.
>>
>> Eugene.
>>
>> ___
>> freebsd-...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: increased power consumption lately?

2017-04-05 Thread Adrian Chadd
hm, you could use dtrace to find what's calling that function and
print out the call stack?



-adrian


On 5 April 2017 at 02:32, Johannes Lundberg <johal...@gmail.com> wrote:
> Is there an easy way to do that with existing tools or do I need to add
> debug printing to the code?
>
>
> On Tue, Apr 4, 2017 at 9:39 PM, Adrian Chadd <adr...@freebsd.org> wrote:
>>
>> hiya,
>>
>> looks like yeah, you're going to have to do a bit more debugging. Can you
>> see what args are being passed to AcpiNsLookup() ?
>>
>>
>>
>> -adrian
>>
>>
>> On 3 April 2017 at 03:24, Johannes Lundberg <johal...@gmail.com> wrote:
>>>
>>> Hi Adrian
>>>
>>> The three threads are kernel(acpi_task_{0-2}) and they use ~30% each so
>>> total 100% of one core.
>>>
>>> Machine is 2013 MBP
>>>
>>> pmcstat screenshot attached.
>>>
>>>
>>> On Thu, 30 Mar 2017 at 21:16, Adrian Chadd <adr...@freebsd.org> wrote:
>>>>
>>>> I don't /think/ so - which thread is it on your end? Can you run
>>>> pmcstat -S instructions -T to see what's taking your CPU?
>>>>
>>>>
>>>>
>>>> -adrian
>>>>
>>>>
>>>> On 28 March 2017 at 13:36, Johannes Lundberg <johal...@gmail.com> wrote:
>>>> > Hi
>>>> >
>>>> > Personally I got some acpi-something kernel thread at 100% CPU
>>>> > constant
>>>> > usage. Need to lock CPU freq at lower value otherwise it runs with
>>>> > turboboost all the time.
>>>> >
>>>> > Could it be the same for you?
>>>> >
>>>> > On Tue, 28 Mar 2017 at 20:58, Adrian Chadd <adr...@freebsd.org> wrote:
>>>> >>
>>>> >> hiya,
>>>> >>
>>>> >> I've noticed that my battery life on my haswell laptop (T540p) seems
>>>> >> to have taken a nosedive lately. I could've /sworn/ it was getting
>>>> >> better than 15-16W at idle.
>>>> >>
>>>> >> Has anyone noticed any massive decrease in battery life lately?
>>>> >>
>>>> >>
>>>> >>
>>>> >> -adrian
>>>> >> ___
>>>> >> freebsd-current@freebsd.org mailing list
>>>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>> >> To unsubscribe, send any mail to
>>>> >> "freebsd-current-unsubscr...@freebsd.org"
>>
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: increased power consumption lately?

2017-04-04 Thread Adrian Chadd
hiya,

looks like yeah, you're going to have to do a bit more debugging. Can you
see what args are being passed to AcpiNsLookup() ?



-adrian


On 3 April 2017 at 03:24, Johannes Lundberg <johal...@gmail.com> wrote:

> Hi Adrian
>
> The three threads are kernel(acpi_task_{0-2}) and they use ~30% each so
> total 100% of one core.
>
> Machine is 2013 MBP
>
> pmcstat screenshot attached.
>
>
>
> On Thu, 30 Mar 2017 at 21:16, Adrian Chadd <adr...@freebsd.org> wrote:
>
>> I don't /think/ so - which thread is it on your end? Can you run
>> pmcstat -S instructions -T to see what's taking your CPU?
>>
>>
>>
>> -adrian
>>
>>
>> On 28 March 2017 at 13:36, Johannes Lundberg <johal...@gmail.com> wrote:
>> > Hi
>> >
>> > Personally I got some acpi-something kernel thread at 100% CPU constant
>> > usage. Need to lock CPU freq at lower value otherwise it runs with
>> > turboboost all the time.
>> >
>> > Could it be the same for you?
>> >
>> > On Tue, 28 Mar 2017 at 20:58, Adrian Chadd <adr...@freebsd.org> wrote:
>> >>
>> >> hiya,
>> >>
>> >> I've noticed that my battery life on my haswell laptop (T540p) seems
>> >> to have taken a nosedive lately. I could've /sworn/ it was getting
>> >> better than 15-16W at idle.
>> >>
>> >> Has anyone noticed any massive decrease in battery life lately?
>> >>
>> >>
>> >>
>> >> -adrian
>> >> ___
>> >> freebsd-current@freebsd.org mailing list
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@
>> freebsd.org"
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: increased power consumption lately?

2017-03-30 Thread Adrian Chadd
I don't /think/ so - which thread is it on your end? Can you run
pmcstat -S instructions -T to see what's taking your CPU?



-adrian


On 28 March 2017 at 13:36, Johannes Lundberg <johal...@gmail.com> wrote:
> Hi
>
> Personally I got some acpi-something kernel thread at 100% CPU constant
> usage. Need to lock CPU freq at lower value otherwise it runs with
> turboboost all the time.
>
> Could it be the same for you?
>
> On Tue, 28 Mar 2017 at 20:58, Adrian Chadd <adr...@freebsd.org> wrote:
>>
>> hiya,
>>
>> I've noticed that my battery life on my haswell laptop (T540p) seems
>> to have taken a nosedive lately. I could've /sworn/ it was getting
>> better than 15-16W at idle.
>>
>> Has anyone noticed any massive decrease in battery life lately?
>>
>>
>>
>> -adrian
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


increased power consumption lately?

2017-03-28 Thread Adrian Chadd
hiya,

I've noticed that my battery life on my haswell laptop (T540p) seems
to have taken a nosedive lately. I could've /sworn/ it was getting
better than 15-16W at idle.

Has anyone noticed any massive decrease in battery life lately?



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: cross compiling freebsd-head is sigh, now broken - thanks libllvm

2017-03-20 Thread Adrian Chadd
WITHOUT_CLANG fixed it for me. Thanks.




-adrian


On 20 March 2017 at 11:23, Ed Maste <ema...@freebsd.org> wrote:
> On 19 March 2017 at 03:00, Adrian Chadd <adr...@freebsd.org> wrote:
>> gcc version 5.3.0 (FreeBSD Ports Collection for mips)
>>
>> ... so uhm, why are we building libllvm?
>
> As of the Clang 4.0.0 import we build Clang by default, on all
> architectures other than those unsupported by Clang, if the
> cross-compiler supports C++11.
>
> I'm not sure if the issue you encountered here is in libllvm or GCC.
> For now though you can set WITHOUT_CLANG and WITHOUT_CLANG_FULL in
> /etc/src.conf.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


cross compiling freebsd-head is sigh, now broken - thanks libllvm

2017-03-19 Thread Adrian Chadd
===> lib/clang (all)
===> lib/clang/libllvm (all)
In file included from
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/math.h:309:0,
 from
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/cmath:305,
 from
/usr/home/adrian/work/freebsd/head-embedded/src/lib/clang/include/llvm/Support/DataTypes.h:34,
 from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/Hashing.h:48,
 from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/ArrayRef.h:13,
 from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMapInfo.h:17,
 from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:17,
 from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/IR/ValueMap.h:29,
 from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Transforms/Utils/ValueMapper.h:18,
 from
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/lib/Transforms/Utils/ValueMapper.cpp:15:
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:
In substitution of 'template static
std::__1::true_type
std::__1::__is_constructible_helper::__test_nary(int) [with _Tp =
{anonymous}::MDNodeMapper::Data; _Args = {}; 
= ]':
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:2993:59:
  required from 'struct
std::__1::__is_default_constructible<{anonymous}::MDNodeMapper::Data,
false>'
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3015:8:
  required from 'struct
std::__1::__libcpp_is_constructible<{anonymous}::MDNodeMapper::Data>'
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3043:29:
  required from 'struct
std::__1::is_constructible<{anonymous}::MDNodeMapper::Data>'
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3229:29:
  required from 'struct
std::__1::is_default_constructible<{anonymous}::MDNodeMapper::Data>'
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/utility:352:15:
  required from 'static constexpr bool std::__1::pair<_T1,
_T2>::_CheckArgs::__enable_default() [with _U1 = const
llvm::Metadata*; _U2 = {anonymous}::MDNodeMapper::Data; _T1 = const
llvm::Metadata*; _T2 = {anonymous}::MDNodeMapper::Data]'
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/utility:403:71:
  required by substitution of 'template::_CheckArgs,
std::__1::__check_tuple_constructor_fail>::type::
__enable_default(), bool>::type  >
constexpr std::__1::pair<_T1, _T2>::pair() [with bool _Dummy = true;
typename std::__1::enable_if::_CheckArgs,
std::__1::__check_tuple_constructor_fail>::type::
__enable_default(), bool>::type  =
]'
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:39:8:
  required from 'struct llvm::detail::DenseMapPair'
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Support/AlignOf.h:111:6:
  required from 'class
llvm::detail::AlignerImpl'
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Support/AlignOf.h:138:8:
  required from 'struct
llvm::AlignedCharArrayUnion'
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:759:59:
  required from 'class llvm::SmallDenseMap'
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/lib/Transforms/Utils/ValueMapper.cpp:182:47:
  required from here
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:2980:9:
error: constructor required before non-static data member for
'{anonymous}::MDNodeMapper::Data::HasChanged' has been parsed
 class = decltype(_Tp(_VSTD::declval<_Args>()...))>
 ^
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:2980:9:
error: 

Re: panic: invalid bcd xxx

2017-03-03 Thread Adrian Chadd
On 2 March 2017 at 01:31, Matthias Apitz <g...@unixarea.de> wrote:
> On Thursday, 2 March 2017 00:37:35 CET, Michael Gmelin <free...@grem.de>
> wrote:
>>
>>
>>
>>> On 2 Mar 2017, at 00:35, Adrian Chadd <adrian.ch...@gmail.com> wrote:
>>>
>>> This is an emulated BIOS though, right?
>>>
>>> I don't know if we're going to get the RTC 'bugfixed'...
>>>
>>
>>
>> It's SeaBIOS, yes. I feel like this might end up in another
>> quirk/workaround solution.
>>
>
> I'm one of the C720 owners and  apart of Michael, I only know two users more
> running FreeBSD. The SeaBIOS in our devices. is outdated, mine from 2013
> IIRC. I dont know if there is an easy way to update this.

We're not; we need to cope with crappy BIOS emulations and not crash :)

What's Linux doing instead? Ignoring the RTC?



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: panic: invalid bcd xxx

2017-03-01 Thread Adrian Chadd
This is an emulated BIOS though, right?

I don't know if we're going to get the RTC 'bugfixed'...


-adrian

On 28 February 2017 at 15:26, Michael Gmelin  wrote:
> On Tue, 28 Feb 2017 17:16:02 -0600
> Eric van Gyzen  wrote:
>
>> On 02/28/2017 16:57, Conrad Meyer wrote:
>> > On Tue, Feb 28, 2017 at 2:31 PM, Eric van Gyzen
>> >  wrote:
>> >> Your system's real-time clock is returning garbage.  r312702 added
>> >> some input validation a few weeks ago.  Previously, the kernel was
>> >> reading beyond the end of an array and either complaining about
>> >> the clock or setting it to the wrong time based on whatever was in
>> >> the memory beyond the array.
>> >>
>> >> The added validation shouldn't be an assertion because it operates
>> >> on data beyond the kernel's control.  Try this:
>> >>
>> >> --- sys/libkern.h   (revision 314424)
>> >> +++ sys/libkern.h   (working copy)
>> >> @@ -57,8 +57,10 @@
>> >>  bcd2bin(int bcd)
>> >>  {
>> >>
>> >> -   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
>> >> -   ("invalid bcd %d", bcd));
>> >> +   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
>> >> +   printf("invalid bcd %d\n", bcd);
>> >> +   return (0);
>> >> +   }
>> >> return (bcd2bin_data[bcd]);
>> >>  }
>> >
>> > I don't think removing this assertion and truncating to zero is the
>> > right thing to do.  Adding an error return to this routine is a
>> > little much, though.  I think probably the caller should perform
>> > input validation between the broken device and this routine.
>>
>> Either of those would be a much better solution.  This was just a
>> quick hack to get the memstick to boot.
>>
>
> Thanks for your response.
>
> I'm not in a hurry, so I can wait for a proper solution. Let me know if
> I should test anything or can help in some other way.
>
> -m
>
>
> --
> Michael Gmelin
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Possible overlooked "svn add" in r314192?

2017-02-24 Thread Adrian Chadd
fxed!


-a


On 24 February 2017 at 09:20, Ngie Cooper  wrote:
>
>> On Feb 24, 2017, at 05:39, David Wolfskill  wrote:
>>
>> Updating head in place from r314136 -> r314200, I find I can't build the
>> kernel because:
>>
>> ...
>> ===> iwifw/iwi_ibss (all)
>> --- all_subdir_iwifw/iwi_monitor ---
>> ===> iwifw/iwi_monitor (all)
>> --- all_subdir_ipmi ---
>> --- all_subdir_ipmi/ipmi_linux ---
>> ===> ipmi/ipmi_linux (all)
>> --- all_subdir_iwm ---
>> bmake[4]: bmake[4]: don't know how to make if_iwm_fw.c. Stop
>
> CCes Adrian.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: asmc driver patch merge request

2017-02-16 Thread Adrian Chadd
ok, lemme do a build and if it succeeds i'll commit it



-a


On 16 February 2017 at 06:39, Johannes Lundberg <johal...@gmail.com> wrote:
> My emacs remove trailing white spaces automatically on save.
>
> On Wed, Feb 15, 2017 at 22:59 Adrian Chadd <adrian.ch...@gmail.com> wrote:
>>
>> this looks fine to me. what's with the whitespace changes?
>>
>>
>>
>> -a
>>
>>
>> On 15 February 2017 at 19:27, Johannes Lundberg <johal...@gmail.com>
>> wrote:
>> > Hi
>> >
>> > This patch adds support for MacBook Pro 11,2 to asmc.
>> >
>> > The other day I tried patching my old
>> >
>> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214836
>> >
>> > submission and discovered it did not apply at all anymore. I uploaded an
>> > updated patch that should apply cleanly to HEAD.
>> >
>> > Someone got time to merge this while it's fresh?
>> >
>> > Thanks!
>> > ___
>> > freebsd-current@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to
>> > "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: asmc driver patch merge request

2017-02-15 Thread Adrian Chadd
this looks fine to me. what's with the whitespace changes?



-a


On 15 February 2017 at 19:27, Johannes Lundberg  wrote:
> Hi
>
> This patch adds support for MacBook Pro 11,2 to asmc.
>
> The other day I tried patching my old
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214836
>
> submission and discovered it did not apply at all anymore. I uploaded an
> updated patch that should apply cleanly to HEAD.
>
> Someone got time to merge this while it's fresh?
>
> Thanks!
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: vt(4) chops off the leftmost three columns

2017-01-24 Thread Adrian Chadd
hi!

Well, give it a go. I can only be supportive. :)


-a


On 24 January 2017 at 10:31, Anindya Mukherjee <anindy...@hotmail.com> wrote:
> Hi again,
>
> I have been switching back and forth between exploring the code and reading 
> J. Kong's Device Drivers book. As you explained, the first thing to tackle is 
> the coupling between vesa and sc. Right now I can't even load vesa unless the 
> kern.vty=sc, and then I cannot unload it.
>
> vesa depends on vesa.c and pulls in scvesactl.c for two functions: 
> vesa_load_ioctl() and vesa_unload_ioctl(). Although these are used only in 
> vesa.c, they depend on several structures (for example the virtual screen 
> structure scr_stat, and others) defined in syscons.h, which makes these two 
> systems coupled.
>
> I was wondering what would be a good way to decouple these dependencies. I 
> want to do the right thing even if it takes longer. Really appreciate you 
> taking the time to respond, thanks!
>
> Anindya
> 
> From: Adrian Chadd [adrian.ch...@gmail.com]
> Sent: January 20, 2017 3:11 PM
> To: Anindya Mukherjee
> Cc: freebsd-current@freebsd.org
> Subject: Re: vt(4) chops off the leftmost three columns
>
> hiya,
>
> Mechanically it doesn't look /that/ hard:
>
> * vesa.ko pulls in the vesa.c bits and the syscons vesa control bits.
> Ideally we'd have them as two separate modules, so you could load
> "vesa" without needing the syscons bits.
> * Maybe then write a vt 'fb' interface to talk to the old-school
> framebuffer interface
> * Then (if we're lucky) we can have vt use the same VGA, VESA, (mach,
> creator, etc!) through the fb interface, rather than reimplementing
> its own.
>
> I looked at it and it doesn't look /that/ hard. If you only cared
> about vesa, then you could do something like what 'creator' and
> 'creator_vt' did in sys/dev/fb/ . It's just sad that the vt interface
> to the screen buffer isn't as complete as the older school framebuffer
> interface is.
>
>
> -adrian
>
>
> On 19 January 2017 at 12:35, Anindya Mukherjee <anindy...@hotmail.com> wrote:
>> Hi Adrian,
>>
>> I was looking at the source for the vt driver. Wondering how much work it is 
>> to add VESA support to the VGA backend? As you say ATM it's hardcoded to use 
>> 640x480. Pardon my ignorance, but can we reuse any VESA code from syscons?
>>
>> Also, how dependent is splash/screensaver support on the VESA implementation?
>>
>> Thanks,
>> Anindya
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: vt(4) chops off the leftmost three columns

2017-01-20 Thread Adrian Chadd
hiya,

Mechanically it doesn't look /that/ hard:

* vesa.ko pulls in the vesa.c bits and the syscons vesa control bits.
Ideally we'd have them as two separate modules, so you could load
"vesa" without needing the syscons bits.
* Maybe then write a vt 'fb' interface to talk to the old-school
framebuffer interface
* Then (if we're lucky) we can have vt use the same VGA, VESA, (mach,
creator, etc!) through the fb interface, rather than reimplementing
its own.

I looked at it and it doesn't look /that/ hard. If you only cared
about vesa, then you could do something like what 'creator' and
'creator_vt' did in sys/dev/fb/ . It's just sad that the vt interface
to the screen buffer isn't as complete as the older school framebuffer
interface is.


-adrian


On 19 January 2017 at 12:35, Anindya Mukherjee  wrote:
> Hi Adrian,
>
> I was looking at the source for the vt driver. Wondering how much work it is 
> to add VESA support to the VGA backend? As you say ATM it's hardcoded to use 
> 640x480. Pardon my ignorance, but can we reuse any VESA code from syscons?
>
> Also, how dependent is splash/screensaver support on the VESA implementation?
>
> Thanks,
> Anindya
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Installing opt_*.h kernel headers

2017-01-15 Thread Adrian Chadd
hi,

As much as I'd like to see everything be default-options and ABI
compliant, things like INET/INET6 throw that assumption under the bus
a bit.
(Yes, I'd love to see INET/INET6 be .ko's..)

So yes, I'd like to see a solution to this too. I think installing the
kernel config for the running kernel somewhere would be nice. No, not
/usr/include, because you want it cycled /with/ the kernel you just
installed. We already have the problem with /usr/lib/debug/ and where
it puts kernel modules.

We already have the 'one file' option, it's called 'kernel config',
and so maybe:

* store the kernel config with the built kernel;
* have config patched to 'just' generate the .h files from the given config, and
* let the build system use that if needed?

However - it all feels terrible. Ideally (hah), there'd be separate
submodules for vt/syscons and the modules would combine appropriately
to provide increasing functionality - but that's a lot to ask given
the complexity of the current system.

2c,



-adrian


On 15 January 2017 at 09:08, Tijl Coosemans  wrote:
> Hi,
>
> The latest version of x11/nvidia-driver contains a call to a syscons
> function which is only available if the kernel config contains device
> sc (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216050).  The call
> doesn't seem to be critical so I'd like to patch it like this:
>
> +#include "opt_syscons.h"
>  ...
> +#ifdef DEV_SC
>  syscons stuff here
> +#endif
>
> And add opt_syscons.h to SRCS in the module Makefile.
>
> This doesn't work however because sys/conf/kmod.mk creates empty opt_*.h
> files in the module build directory.  Only when KERNBUILDDIR is set does
> it create opt_*.h files as symlinks to the same file in KERNBUILDDIR.
> This means that to build this port correctly users would have to have a
> kernel build directory (even if they just need the nvidia driver and
> don't otherwise build kernels) and the ports tree would need some way to
> find it (using KERNCONF etc.).
>
> It would be better if these opt_*.h files were installed along with the
> kernel.  Somewhere in /usr/include or /boot/kernel(.old)?  Perhaps
> concatenated into one file?  Then kmod.mk could create symlinks to this
> file if KERNBUILDDIR is undefined.  Building a module directly from
> sys/modules would then also just work without .if !defined(KERNBUILDDIR)
> magic that several Makefiles contain.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: vt(4) chops off the leftmost three columns

2017-01-14 Thread Adrian Chadd
heh.

As always, patches gratefully accepted. :)



-adrian


On 14 January 2017 at 21:07, Ernie Luzar <luzar...@gmail.com> wrote:
>
> You can add these things to the vt to-do list
>
> Change the default font to look like sc.
> Add copy/paste function like sc has.
> Add splash screen support like sc has.
>
>
>
> Adrian Chadd wrote:
>>
>> hi,
>>
>> no, the vt_vga backend doesn't yet do VESA.
>>
>> I keep meaning to sit down and fix this, but life and wifi gets in the
>> way.
>>
>>
>> -adrian
>>
>>
>> On 14 January 2017 at 16:27, Kevin Oberman <rkober...@gmail.com> wrote:
>>>
>>> On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd <adrian.ch...@gmail.com>
>>> wrote:
>>>>
>>>> It depends(tm). I think the VT code just does "640x480x4bpp" and lets
>>>> the BIOS sort it out. A lot of things don't cope well with 640x480
>>>> these days - they try autodetecting picture edges, but a black border
>>>> makes that very difficult.
>>>>
>>>>
>>>> -adrian
>>>
>>>
>>> Can you use vidcontrol(1) to change to something better? 1600x900, maybe?
>>> (Note, I have not tried this and I know that vt does not support a lot of
>>> vidcontrol functionality, but starting X sets the display to 200x56
>>> characters on my laptop.)
>>> --
>>> Kevin Oberman, Part time kid herder and retired Network Engineer
>>> E-mail: rkober...@gmail.com
>>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>>>
>>>
>>>> On 14 January 2017 at 08:57, Matthias Andree <matthias.and...@gmx.de>
>>>> wrote:
>>>>>
>>>>> Am 14.01.2017 um 00:11 schrieb Alan Somers:
>>>>>>
>>>>>> I take it back.  The first three columns _are_ rendered, but they
>>>>>> don't show up on some monitiors.  It's as if those monitors require a
>>>>>> minimum amount of overscan on the left side of the screen, and vt(4)
>>>>>> doesn't provide enough.  Can that be tuned?
>>>>>
>>>>> Once upon a time, I've seen similar things on Linux, but with fewer
>>>>> pixels offset, when switching framebuffer drivers - back then, the
>>>>> scanning-VGA-timing was an issue. Is there any way to tweak the row and
>>>>> column timings, with blank periods, viewport offsets and thereabouts?
>
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: vt(4) chops off the leftmost three columns

2017-01-14 Thread Adrian Chadd
hi,

no, the vt_vga backend doesn't yet do VESA.

I keep meaning to sit down and fix this, but life and wifi gets in the way.


-adrian


On 14 January 2017 at 16:27, Kevin Oberman <rkober...@gmail.com> wrote:
> On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd <adrian.ch...@gmail.com>
> wrote:
>>
>> It depends(tm). I think the VT code just does "640x480x4bpp" and lets
>> the BIOS sort it out. A lot of things don't cope well with 640x480
>> these days - they try autodetecting picture edges, but a black border
>> makes that very difficult.
>>
>>
>> -adrian
>
>
> Can you use vidcontrol(1) to change to something better? 1600x900, maybe?
> (Note, I have not tried this and I know that vt does not support a lot of
> vidcontrol functionality, but starting X sets the display to 200x56
> characters on my laptop.)
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
>
>>
>> On 14 January 2017 at 08:57, Matthias Andree <matthias.and...@gmx.de>
>> wrote:
>> > Am 14.01.2017 um 00:11 schrieb Alan Somers:
>> >> I take it back.  The first three columns _are_ rendered, but they
>> >> don't show up on some monitiors.  It's as if those monitors require a
>> >> minimum amount of overscan on the left side of the screen, and vt(4)
>> >> doesn't provide enough.  Can that be tuned?
>> >
>> > Once upon a time, I've seen similar things on Linux, but with fewer
>> > pixels offset, when switching framebuffer drivers - back then, the
>> > scanning-VGA-timing was an issue. Is there any way to tweak the row and
>> > column timings, with blank periods, viewport offsets and thereabouts?
>> > ___
>> > freebsd-current@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to
>> > "freebsd-current-unsubscr...@freebsd.org"
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: vt(4) chops off the leftmost three columns

2017-01-14 Thread Adrian Chadd
It depends(tm). I think the VT code just does "640x480x4bpp" and lets
the BIOS sort it out. A lot of things don't cope well with 640x480
these days - they try autodetecting picture edges, but a black border
makes that very difficult.


-adrian


On 14 January 2017 at 08:57, Matthias Andree  wrote:
> Am 14.01.2017 um 00:11 schrieb Alan Somers:
>> I take it back.  The first three columns _are_ rendered, but they
>> don't show up on some monitiors.  It's as if those monitors require a
>> minimum amount of overscan on the left side of the screen, and vt(4)
>> doesn't provide enough.  Can that be tuned?
>
> Once upon a time, I've seen similar things on Linux, but with fewer
> pixels offset, when switching framebuffer drivers - back then, the
> scanning-VGA-timing was an issue. Is there any way to tweak the row and
> column timings, with blank periods, viewport offsets and thereabouts?
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: onboard wifi raspberry pi3 and aarch64/freebsd-current

2017-01-09 Thread Adrian Chadd
hi!

no, and maybe.


-a


On 9 January 2017 at 05:30, tech-lists  wrote:
> Hello lists,
>
> [x-posted to freebsd-arm because this question appears to be equally
> relevant there]
>
> Does the onboard wireless on the raspberry pi 3 work in 12-current-aarch64?
>
> If not, are there plans afoot to make it work?
>
> many thanks,
> --
> J.
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Adrian Chadd
email freebsd-wireless with the wifi details. i know our iwm driver
gets antenna configs wrong sometimes and that can cause issues.


-a


On 6 January 2017 at 11:07, Jonathan Anderson  wrote:
> On 6 Jan 2017, at 13:53, Pete Wright wrote:
>>
>>
>> i've been having the same problems with iwm too (failing to load firmware
>> on boot).  my trick has been to either boot into an old kernel where iwm was
>> mostly usable.  also i've commented out the line enabling wlan0 in my
>> rc.conf then uncommented it after boot and manually running "service netif
>> start" to bring up iwm.  that method works most of the time...
>> -pete
>
>
> I am able to load iwm (iwm7265fw), but there are some networks that I just
> can't connect to (INIT -> INIT, swscan_cancel_scan, repeat). Attaching to an
> iPhone hotspot is one example of a not-entirely-helpful network, but there
> is other, more typical infrastructure that gives trouble too. There is an
> iwm8xxx in the room that seems to work fine, however... I do not meddle in
> the affairs of wi-fi, for it is subtle and quick to anger. :)
>
>
> Jon
> --
> Jonathan Anderson
> jonat...@freebsd.org
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: RFC: DTrace probes for debugging or testing in userland programs

2016-12-19 Thread Adrian Chadd
*mumble* damnit jordan this requires libdispatch *mumble*



-a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: RFC: DTrace probes for debugging or testing in userland programs

2016-12-19 Thread Adrian Chadd
On 19 December 2016 at 16:04, Jordan Hubbard <j...@mail.turbofuzz.com> wrote:
>
> On Dec 19, 2016, at 12:27 PM, Adrian Chadd <adrian.ch...@gmail.com> wrote:
>
> So although I like the sentiment, I don't think using dtrace for
> program logging is the right answer.  I like what apple did to wrap
> the program logging stuff so people didn't just write their own
> libraries (hi!) and so there's a unified-ish way to interact with
> apple programs. I think we could do with that.
>
>
> Thanks!
>
> We did a number of other things with ASL (Apple System Logger) which I miss
> very much today and would hope to see in any FreeBSD equivalent:
>
> 1. We structured all log data into dictionaries, so every application and/or
> subsystem within that application can add its own “tags” without squashing
> other key information.  This also unified the character encoding format, so
> some applications were no longer logging in ISO-Latin1, others in UTF-8 and
> yet others in SHIFT-JIS.
>
> 2.  There’s also a logging database, as one of the many possible “output
> sinks”, so searches / queries are fast (and there’s an API for querying and
> managing its contents).
>
> 3. We added client-side and server side logging filters, so you can “crank
> an application up” or shut its mouth without having to make any code
> changes.
>
> 4. It’s all thread-safe.

Hm. Where's the ASL source hiding? I'm kinda hoping it's light weight
enough to port over without porting a lot of other stuff, but I am
also afraid it's Apple.. :)



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: RFC: DTrace probes for debugging or testing in userland programs

2016-12-19 Thread Adrian Chadd
Hi,

I'd love to see a unified-ish logging API for FreeBSD applications. I
always end up reusing some C code I have here that I based on some
Squid style logging API in ages past. I could always polish it up and
put it up for review.

I'm not a big fan of requiring dtrace to use it though. On a lot of
the embedded systems dtrace varies from "it's very big" through to "we
don't have enough RAM/flash to do this".

So although I like the sentiment, I don't think using dtrace for
program logging is the right answer.  I like what apple did to wrap
the program logging stuff so people didn't just write their own
libraries (hi!) and so there's a unified-ish way to interact with
apple programs. I think we could do with that.

Thanks,



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: best approximation of getcpu() ?

2016-12-16 Thread Adrian Chadd
On 16 December 2016 at 11:45, Luigi Rizzo  wrote:
> On Fri, Dec 16, 2016 at 09:29:15AM +, David Chisnall wrote:
>> On 16 Dec 2016, at 03:10, Alan Somers  wrote:
>> >
>> > What about pthread_setaffinity(3) and friends?  You can use it to pin
>> > a thread to a single CPU, and know that it will never migrate.
>>
>> This is not a useable solution for anything that needs to live in a library 
>> and also doesn???t solve the problem.
>>
>> The Linux get_cpu call() is used for caches that are somewhere between 
>> global and thread-local.  Accessing them still requires a lock, but it???s 
>> very likely to be uncontended (contention only happens when you???re context 
>> switched at exactly the wrong time, or if a thread is migrated between cores 
>> in between the get_cpu() call and usage) and so you can use the userspace 
>> fast path for the lock and not suffer from cache contention effects.
>>
>> One x86, you can use cpuid from userspace and get the current core ID.  I 
>> have some code that does this and re-checks every few hundred accesses, 
>> storing the current CPU ID in a thread-local variable.  Using the per-CPU 
>> caches is a lot faster than using the global cache (and reduces contention 
>> on the global cache).  It would be great if we could have a syscall to do 
>> this on FreeBSD (it would be even better if we could have specify a TLS 
>> variable that the kernel automatically updates for the userspace thread when 
>> the scheduler migrates the thread between cores).
>
> indeed the following line seems to do the job for x86
> asm volatile("cpuid" : "=d"(curcpu), "=a"(tmp), "=b"(tmp), "=c"(tmp) 
> : "a"(0xb) );
> (there must be a better way to tell the compiler that eax, ebx, ecx, edx are
> all clobbered).
>
> 0xb is the CPUID function that returns the current APIC id for the
> core (not necessarily matching the OS core-id)
>
> The only problem is that this instruction is serialising and slow,
> seems to take some 70-100ns on several of my machines so you
> cannot afford to call it at all times but need the value cached
> somewhere. Exposing it as thread local storage, or a VDSO syscall,
> would be nicer because the kernel knows when it is actually changing
> value.

The problem is your CPU ID can change in the middle of packet handling.

So if you want it to be accurate, you need to bind your worker thread to a CPU.



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Enabling NUMA in BIOS stop booting FreeBSD

2016-12-15 Thread Adrian Chadd
heh, an updated BIOS that solves the problem will solve the problem. :)

I think you have enough information to provide to supermicro. Ie,
"SMAP says X, when physical memory pages at addresses X are accessed,
they don't behave like memory, maybe something is wrong".

All I can think of is some hack to add a blacklist for that region so
you can boot the unit. But it makes me wonder what else is going on.


-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: drm-next update and longer term plans

2016-12-01 Thread Adrian Chadd
Hi,

The challenge right now is figuring out how to implement / commit the
linux-y bits that the linux layer really wants. Kip has done a pretty
great job at figuring out the minimum set of hilarity that needs to go
into base versus linuxkpi.

But the "challenge" is figuring out some comprimise between what's
done and what we can do in FreeBSD land. Those changes are small but
unfortunately change the expectations we have. If someone's willing to
step up and help out with the linuxkpi side of things and the base
system bits (the new lock, some UMA changes, some VM changes, the
interrupt model that we have versus linux and what we're allowed to
do, etc, etc) then that'll really help.

I can help try to get stuff reviewed and help people know where some
of the quirky controversial bits are, but I don't have the cycles to
modify/rewrite any of it all to land in -HEAD. I need some help with
that.

If you're interested in helping out and can take some direction then
sign up and we'll figure the bits out.

Thanks!


-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Enabling NUMA in BIOS stop booting FreeBSD

2016-11-27 Thread Adrian Chadd
On 26 November 2016 at 13:59, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> On Sat, Nov 26, 2016 at 01:55:14PM -0800, Adrian Chadd wrote:
>
>> ok, hm. then i don' know offhand, not without putting in printf debugging. :)
>
> I am not expert in this code, I am need you patches for printf debugging.

heh, sorry, I'm too busy atm to help out more with this. My day job
doesn't involve FreeBSD at all and I have 802.11ac to get off the
ground.

Someone else will have to help figure this out :(



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Enabling NUMA in BIOS stop booting FreeBSD

2016-11-26 Thread Adrian Chadd
ok, hm. then i don' know offhand, not without putting in printf debugging. :)


-a

On 26 November 2016 at 13:51, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> On Sat, Nov 26, 2016 at 01:49:00PM -0800, Adrian Chadd wrote:
>
>> Ok. So boot verbose and let's see what it says.
>
> See first message: it's already verbose boot.
> Yes, only 3 lines.
>
>>
>> On 26 November 2016 at 10:39, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> > On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote:
>> >
>> >> The ACPI SRAT parsing code - sys/x86/acpica/srat.c .
>> >>
>> >> I'd start by enabling bootverbose - adds one echo (SLIT.Localities and
>> >> the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other
>> >> locality stuff.
>> >
>> > I am use r308809 of HEAD.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Enabling NUMA in BIOS stop booting FreeBSD

2016-11-26 Thread Adrian Chadd
Ok. So boot verbose and let's see what it says.


-adrian


On 26 November 2016 at 10:39, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote:
>
>> The ACPI SRAT parsing code - sys/x86/acpica/srat.c .
>>
>> I'd start by enabling bootverbose - adds one echo (SLIT.Localities and
>> the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other
>> locality stuff.
>
> I am use r308809 of HEAD.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Enabling NUMA in BIOS stop booting FreeBSD

2016-11-26 Thread Adrian Chadd
The ACPI SRAT parsing code - sys/x86/acpica/srat.c .

I'd start by enabling bootverbose - adds one echo (SLIT.Localities and
the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other
locality stuff.


-adrian


On 26 November 2016 at 09:37, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> On Sat, Nov 26, 2016 at 09:35:08AM -0800, Adrian Chadd wrote:
>
>> It may be something to do with memory topology parsing. Maybe we need
>> some more debugging there to try and catch it.
>
> What debug you need?
>
>> On 26 November 2016 at 01:21, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> > I am try to enable NUMA in bios and can't boot FreeBSD.
>> > Boot stoped after next messages:
>> >
>> > ===
>> > Booting...
>> > KDB: debugger backends: ddb
>> > KDB: current backend: ddb
>> > ===
>> >
>> > This is verbose boot.
>> > No reaction to ~^B, NMI.
>> >
>> > Same for head and 10.3-RELEASE.
>> >
>> > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM.
>> >
>> > On slight different hardware
>> > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM)
>> > 10.3 boot ok w/ BIOS NUMA enabled.
>> >
>> > ___
>> > freebsd-current@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Enabling NUMA in BIOS stop booting FreeBSD

2016-11-26 Thread Adrian Chadd
It may be something to do with memory topology parsing. Maybe we need
some more debugging there to try and catch it.



-a


On 26 November 2016 at 01:21, Slawa Olhovchenkov  wrote:
> I am try to enable NUMA in bios and can't boot FreeBSD.
> Boot stoped after next messages:
>
> ===
> Booting...
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> ===
>
> This is verbose boot.
> No reaction to ~^B, NMI.
>
> Same for head and 10.3-RELEASE.
>
> Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM.
>
> On slight different hardware
> (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM)
> 10.3 boot ok w/ BIOS NUMA enabled.
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: tput failing on 10 and 12 systems?

2016-11-21 Thread Adrian Chadd
Hiya,

Just to follow through - part of tput is to decode command args, but
it then just requests it from the ncurses tputs() call.

So it could be tput, but it could also be the BSD ncurses work.


-adrian


On 21 November 2016 at 07:54, Julian Elischer  wrote:
> example on freefall (FreeBSD 12.0-CURRENT #0 r306376)
>
> julian@freefall:tput setaf 4|od -c
> 000  033   [   m
> 003
>
> so nothing happens, and tput returns 1.
>
> but on a FreeBSD 8 system:
>
> [jelischer@alpha ~]$ tput setaf 4|od -c
> 000  033   [   3   4   m
> 005
>
> which make the text change color.
>
>
> similarly all the related tput color commands I can think of fail on
> 10,11,12
>
> but programs such as vim can use color just fine. So I suspect tput itself.
>
>
> anyone have experience with this? seems easy to reproduce.
>
>
>
>
>
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: SM bus ioctls incorrect in FreeBSD 11

2016-11-10 Thread Adrian Chadd
+10 on option 2. Hate to say it, but I'd rather this little corner of
freebsd be "right" before it gets more heavily used.


-a


On 10 November 2016 at 03:21, Andriy Gapon  wrote:
> On 14/10/2016 18:51, Lewis Donzis wrote:
>> Our opinion doesn’t count for much, but I like 2 or 4.  Option 1 would
>> essentially obviate the entire purpose of changing the structure.  Option 2
>> basically finishes the job and makes it work properly.  Option 3 is, as you
>> say, unappealing.  I have no problem with Option 4, obviously we can change
>> our code back to the old way, but assuming there was a good reason for this
>> change in the first place, Option 2 seems more logical.
>>
>> But whatever y’all decide is fine with us, we’ll just change code to match at
>> the appropriate time.
>
> Anyone interested in the issue, could you please take a look at this review?
> https://reviews.freebsd.org/D8430
>
> Thank you.
>
> --
> Andriy Gapon
> ___
> freebsd-a...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: hang during kldload if_bwn

2016-11-08 Thread Adrian Chadd
I don't know why it's hanging; and unfortunately I'll have to
reinstall -head to get a working console (since the device I have here
for doing ppc+bwn work wants syscons, /not/ vt.. :( )


-a


On 6 November 2016 at 14:42, Justin Hibbits  wrote:
> Hi folks,
>
> I have a PowerBook G4 with an Airport Extreme card (bwi/bwn, can use
> either one), and found if I don't have the exact correct firmware it
> hangs.  Here's a snippet of WITNESS before it hangs:
>
> siba_bwn0:  mem
> 0xa0004000-0xa0005fff irq 52 at device 17.0 on pci1 bwn0 on siba_bwn0
> bwn0: bwn_attach_core: forcing 2GHz only; no dual-band support for PHY
> bwn0: WLAN (chipid 0x4318 rev 9) PHY (analog 3 type 2 rev 7) RADIO
> (manuf 0x17f ver 0x2050 rev 8) bwn0: DMA (32 bits)
> wlan0: Ethernet address: 00:14:51:7d:60:39
> bwn0: ucode fw: ucode5
> Sleeping on "fwload" with the following non-sleepable locks held:
> exclusive sleep mutex bwn0 (network driver) r = 0 (0xd2e57004) locked
> @ /usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c:814 stack backtrace:
> #0 0x50fd64 at witness_warn+0x2c0
> #1 0x49ef0c at _sleep+0xc8
> #2 0x4e2e10 at firmware_get+0x120
> #3 0xd2d0a6e4 at bwn_fw_get+0xe4
> #4 0xd2d1057c at bwn_fw_gets+0x1ac
> #5 0xd2d13130 at bwn_core_init+0x28c
> #6 0xd2d151f0 at bwn_init+0x310
> #7 0xd2d15408 at bwn_parent+0x80
> #8 0xd2da794c at parent_updown+0x1c
> #9 0x4fe6dc at taskqueue_run_locked+0x178
> #10 0x4ff468 at taskqueue_thread_loop+0xa8
> #11 0x44c99c at fork_exit+0xc0
> #12 0x8229dc at fork_trampoline+0xc
> bwn_v4_ucode5: could not load firmware image, error 2
> bwn0: the fw file(bwn_v4_ucode5) not found
> bwn0: ucode fw: ucode5
> Sleeping on "fwload" with the following non-sleepable locks held:
> exclusive sleep mutex bwn0 (network driver) r = 0 (0xd2e57004) locked
> @ /usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c:814 stack backtrace:
> #0 0x50fd64 at witness_warn+0x2c0
> #1 0x49ef0c at _sleep+0xc8
> #2 0x4e2e10 at firmware_get+0x120
> #3 0xd2d0a6e4 at bwn_fw_get+0xe4
> #4 0xd2d1057c at bwn_fw_gets+0x1ac
> #5 0xd2d13130 at bwn_core_init+0x28c
> #6 0xd2d151f0 at bwn_init+0x310
> #7 0xd2d15408 at bwn_parent+0x80
> #8 0xd2da794c at parent_updown+0x1c
> #9 0x4fe6dc at taskqueue_run_locked+0x178
> #10 0x4ff468 at taskqueue_thread_loop+0xa8
> #11 0x44c99c at fork_exit+0xc0
> #12 0x8229dc at fork_trampoline+0xc
> bwn-open_v4_ucode5: could not load firmware image, error 2
> bwn0: the fw file(bwn-open_v4_ucode5) not found
>
>
> Creating a symlink in /boot/modules of bwn_v4_ucode5.ko ->
> bwn_v4_ucode.ko makes it not hang, but it still triggers WITNESS.
>
> - Justin
> ___
> freebsd-wirel...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

2016-10-11 Thread Adrian Chadd
Hiya,

So uhm - normal rtwn works fine, but andriy's merged version doesn't?



-a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

2016-10-02 Thread Adrian Chadd
hi,

can you turn on debugging? Do you see RX frames?


-a


On 1 October 2016 at 08:09, Kevin Lo  wrote:
> Strange, rtwn(4) stops working.  I tried to scan for the available network,
> but it just returns empty results.
>
> On Fri, Sep 23, 2016 at 02:44:13PM +0300, Andriy Voskoboinyk wrote:
>>
>> Fri, 23 Sep 2016 10:18:30 +0300 було написано Kevin Lo :
>>
>> Few more questions:
>> 1) does it work with h/w encryption support? (enabled by default)
>> (if 'yes' - I will remove 'hardware crypto enabled' warning).
>> 2) is there rate control support? (wlandebug -i wlan0 rate ; then transmit
>> something - if it works then AMRR will print it's current status
>> periodically)
>> 3) can you test some disabled capabilities? (ad-hoc/AP modes, 11n)
>> (see r92ce_adj_devcaps() in sys/dev/rtwn/rtl8192c/pci/r92ce_attach.c).
>>
>> > It works for me, thanks :)
>> >
>> > Kevin
>> >
>> > On Fri, Sep 23, 2016 at 09:08:15AM +0300, Andriy Voskoboinyk wrote:
>> >>
>> >> Fri, 23 Sep 2016 04:58:40 +0300 було написано Kevin Lo
>> >> :
>> >>
>> >> Thanks for the log file,
>> >>
>> >> Tx 'device timeouts' should be fixed in
>> >> https://github.com/s3erios/rtwn/commit/f78d51b6ed8590e3aeb65fbf616aa767034a89f5
>> >> (currently I'm reviewing PCI-specific code to see if there are any
>> >> additional
>> >> issues - e.g., there are no Rx events in the log file).
>> >>
>> >> > On Thu, Sep 22, 2016 at 01:54:21PM +0300, Andriy Voskoboinyk wrote:
>> >> >>
>> >> >> Thu, 22 Sep 2016 12:24:42 +0300 було написано Kevin Lo
>> >> >> :
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> So, the driver was fully tested. Thanks!
>> >> >> Can you set dev.rtwn.0.debug=0x829f for RTL8188CE to see how big
>> >> >> the problem is?
>> >> >
>> >> > Sure.  Here you go
>> >> https://people.freebsd.org/~kevlo/rtl8188ce-debug.txt
>> >> >
>> >> > Thanks,
>> >> > Kevin
>> >> >
>> >> >> > Hi Andriy,
>> >> >> >
>> >> >> > First of all, THANK YOU!  You're doing amazing work!
>> >> >> > Second, I've done some testing on the following devices,
>> >> downloading
>> >> >> > FreeBSD-12.0-CURRENT-amd64-20160809-r303880-disc1.iso from
>> >> >> > ftp.freebsd.org:
>> >> >> >
>> >> >> > - ASUS USB-N10 NANO (RTL8188CUS):
>> >> >> >   rtwn0: > >> addr
>> >> >> > 3> on usbus0
>> >> >> >   rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
>> >> >> >
>> >> >> > - TP-Link TL-WN725N v2 (RTL8188EU):
>> >> >> >   rtwn0:  on
>> >> >> > usbus0
>> >> >> >   rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
>> >> >> >
>> >> >> > - D-Link DWA-131 (RTL8192CU):
>> >> >> >   rtwn0: > >> addr
>> >> >> > 3> on usbus0
>> >> >> >   rtwn0: MAC/BB RTL8192CU, RF 6052 2T2R
>> >> >> >
>> >> >> > - TP-Link Archer T4U (RTL8812AU):
>> >> >> >   rtwn0:  on
>> >> >> > usbus0
>> >> >> >   rtwn0: MAC/BB RTL8812AU, RF 6052 2T2R
>> >> >> >
>> >> >> > - D-Link DWA-171 rev A1 (RTL8821AU):
>> >> >> >   rtwn0: <802.11n WLAN Adapter> on usbus0
>> >> >> >   rtwn0: MAC/BB RTL8821AU, RF 6052 1T1R
>> >> >> >
>> >> >> > - RTL8188CE mini pcie:
>> >> >> >   rtwn0:  port 0xd000-0xd0ff mem
>> >> >> > 0x9080-0x90803fff irq 17 at device 0.0 on pci1
>> >> >> >   rtwn0: r92ce_attach: warning: hardware crypto enabled
>> >> >> >   rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R
>> >> >> >
>> >> >> > All seems to be ok, except RTL8188CE PCIe adapter doesn't work:
>> >> >> >
>> >> >> > rtwn0: r92ce_post_init: warning: net80211 ratectl is used
>> >> >> > rtwn0: device timeout
>> >> >> >
>> >> >> >   Kevin
>> >> >> >
>> >> >> > On Mon, Sep 19, 2016 at 04:26:38PM +0300, Andriy Voskoboinyk wrote:
>> >> >> >>
>> >> >> >> Thu, 01 Sep 2016 19:29:03 +0300 було написано Andriy Voskoboinyk
>> >> >> >> :
>> >> >> >>
>> >> >> >> Now it resides on https://github.com/s3erios/freebsd-rtwn
>> >> (integrated
>> >> >> >> into src tree, so it can be built with 'make buildkernel' / 'make
>> >> >> >> buildworld').
>> >> >> >>
>> >> >> >> This the last stage; once all reported issues will be resolved,
>> >> I'm
>> >> >> >> going to merge it into HEAD.
>> >> >> >>
>> >> >> >> > Hi everyone,
>> >> >> >> >
>> >> >> >> > rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were
>> >> >> merged
>> >> >> >> > into a
>> >> >> >> > single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the
>> >> >> code is
>> >> >> >> > available on https://github.com/s3erios/rtwn repository. Among
>> >> >> >> bugfixes /
>> >> >> >> > code deduplication, there some new features too:
>> >> >> >> >
>> >> >> >> > 1) multi-vap support (one any wireless interface + one STA
>> >> >> interface +
>> >> >> >> > any number of monitor mode interfaces).
>> >> >> >> > 2) few new sysctls:
>> >> >> >> >   * dev.rtwn.#.crypto - controls how to use hardware crypto
>> >> >> >> acceleration
>> >> >> >> >   * dev.rtwn.#.ratectl_selected
>> >> >> >> >   * dev.rtwn.#.ratectl - selects current 'rate control'
>> >> algorithm
>> >> >> >> > (currently only 'none' and 'net80211' are supported; RTL8192CE
>> >> >> needs
>> >> >> >> > 

Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

2016-09-19 Thread Adrian Chadd
hi,

I'll try it out tonight! Is the rtwn repo still "ok" to try as a
standalone thing?

The usbdevs patch is fine standalone - would you like to just commit
this in advance?




-adrian


On 19 September 2016 at 06:26, Andriy Voskoboinyk  wrote:
> Thu, 01 Sep 2016 19:29:03 +0300 було написано Andriy Voskoboinyk
> :
>
> Now it resides on https://github.com/s3erios/freebsd-rtwn (integrated
> into src tree, so it can be built with 'make buildkernel' / 'make
> buildworld').
>
> This the last stage; once all reported issues will be resolved, I'm
> going to merge it into HEAD.
>
>> Hi everyone,
>>
>> rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were merged
>> into a
>> single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the code is
>> available on https://github.com/s3erios/rtwn repository. Among bugfixes /
>> code deduplication, there some new features too:
>>
>> 1) multi-vap support (one any wireless interface + one STA interface +
>> any number of monitor mode interfaces).
>> 2) few new sysctls:
>>   * dev.rtwn.#.crypto - controls how to use hardware crypto acceleration
>>   * dev.rtwn.#.ratectl_selected
>>   * dev.rtwn.#.ratectl - selects current 'rate control' algorithm
>> (currently only 'none' and 'net80211' are supported; RTL8192CE needs
>> testing
>> with the last).
>> 3) (incomplete) power management support for RTL8188EU (requires
>> firmware).
>> 4) Short Guard Interval support.
>>
>> It's known to work with RTL8188CUS, RTL8188EU and RTL8821AU; however,
>> it was never tested with RTL8192CE or RTL8812AU.
>>
>> How-to-build:
>> 1) download / checkout the repository.
>> 2) apply 'patch-usbdevs.diff' against '/usr/src'
>> 3) build and install rtwn module:
>> cd $repository/sys/modules/rtwn && make && make install
>> 4) build and install rtwn_usb/rtwn_pci:
>> cd ../rtwn_usb && make && make install
>> cd ../rtwn_pci && make && make install
>> 5) unload previous && load current drivers:
>> kldunload if_urtwn if_rtwn
>> kldload /boot/modules/if_rtwn.ko /boot/modules/if_rtwn_usb.ko
>> /boot/modules/if_rtwn_pci.ko
>> 6) Use.
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD12-RC2 and bluetooth?

2016-09-15 Thread Adrian Chadd
hi,

bluetooth uses netgraph.



-a


On 15 September 2016 at 11:36, Steve Kargl
 wrote:
> I recently got a spanky new Dell Precision 7510.  After
> freeing up space on the nvme device, I installed
> FreeBSD-12.0-CURRENT-amd64-20160829-r305028-memstick.img
> on her.  Nice, painless experience.  Thanks RE!
>
> I then used svnlite to grab /usr/src.  This was followed
> by a buildworld/buildkernel cycle where I used a custom
> kernel config file.  This config includes only the devices
> I need to function under freebsd, so it excludes any and
> all netgraph stuff.  When I rebooted the system, I find
>
> % kldstat
>
> Id Refs AddressSize Name
>  1   16 0x8020 1168ef0  kernel
>  21 0x81bfa000 367f ng_ubt.ko
>  35 0x81bfe000 951e netgraph.ko
>  41 0x81c08000 8bbb ng_hci.ko
>  53 0x81c11000 9cb  ng_bluetooth.ko
>  61 0x81c12000 b9e8 ng_l2cap.ko
>  71 0x81c1e000 173b6ng_btsocket.ko
>  81 0x81c36000 1d0b ng_socket.ko
>
> The laptop has bluetooth and it is enabled in the BIOS
> (for the Windows personality of the laptop).  I cannot
> find the reason or knobs that is causing kldload to
> automatically load netgraph.  How does one stop this?
>
> --
> Steve
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: 11.0-RC2 suspend/resume on thinkpad x201 kills poweroff

2016-09-09 Thread Adrian Chadd
is it too new to "kldload i915kms" ?


-adrian


On 9 September 2016 at 00:45, Philip Homburg  wrote:
>>What graphics driver are you using?
>
> Just the default:
> 'VT(vga): resolution 640x480'
>
> Booting with -v and switching I now noticed that each time I switch to a
> different console I get a line
> 'Timeout initializing vt_vga'
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: 11.0-RC2 suspend/resume on thinkpad x201 kills poweroff

2016-09-08 Thread Adrian Chadd
Try forcing a console switch - hit alt-f1, alt-f2, etc.


-a


On 8 September 2016 at 15:10, Glen Barber  wrote:
> On Thu, Sep 08, 2016 at 11:32:24PM +0200, Philip Homburg wrote:
>> The main culprit seems to be putting 'hw.acpi.reset_video=1' in
>> /boot/loader.conf
>>
>
> Yes, I have seen this cause problems on some (not all) hardware.
>
>> this causes resume to hang half way through. I managed to trigger
>> CMOS corruption once, but I can't systematically trigger it.
>>
>> Without hw.acpi.reset_video=1 in /boot/loader.conf, resume works except that
>> the screen stays black.
>>
>
> What graphics driver are you using?
>
> Glen
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Intel ac8260 and wpa_supplicant

2016-09-06 Thread Adrian Chadd
hi,

There's some interesting issues with the scan logic in -HEAD where we
abort/finish a scan if there's active traffic, but there's no way to
say "the scan was interrupted by active traffic and will continue"
versus "the scan was aborted" or "the scan is finished". So sometimes
the scan results list in wpa_supplicant returns prematurely and it
doesn't know to fetch an updated one.



-adrian


On 6 September 2016 at 13:17, Andreas Nilsson  wrote:
> Hello,
>
> I installed 12-CURRENT from a few days ago on my laptop ( thinkpad x1 yoga
> ). The wireless cards was detected and I could create a wlan0 device and
> scan for networks.
>
> Upon starting wpa_supplicant things go awry, running scan_results in
> wpa_cli times out  and returns empty list while ifconfig wlan0 list scan
> returns expected list. Any ideas on what to try?
>
> Seems to be dependent on the number of networks found.
>
> Best regards
> Andreas Nilsson
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Arcan [0.5.1] on FreeBSD/KMS

2016-09-05 Thread Adrian Chadd
Hey, this looks really cool!


-a


On 5 September 2016 at 06:25, bbjowhn .  wrote:
> I'm guessing most of you seeing this post aren't too familiar with the
> project, so I'll start with something of a synopsis.
>
> Arcan is a mix between a streaming realtime graphics (and audio) processor,
> a game engine and a display server. It has been in development under the
> radar for about a decade, patiently awaiting the time where lower level
> access to accelerated graphics hardware starts becoming bearable.
>
> As a display server, it has most of the hardcore features in place since a
> while back, i.e. hot-pluggable multi-displays with different orientation,
> mixed densities and subpixel layout, mouse, keyboard, game devices,
> trackpads, crash recovery, suspend and resume, clipboard, screen sharing,
> streaming and so on.
>
> One of the key differences to say, X.org is that the role of the 'window
> manager' has been moved into an authoritative Lua VM and it's the scripts
> (or collection of scripts) that you chose to run which defines permitted
> behaviour in terms of input and output routing and response. This also
> means that it can fit many roles: display manager, virtual terminals or
> just an image viewer if that's all you need -- with a pretty compact set of
> dependencies.
>
> Among its downsides: it's still missing an external protocol (though
> there's an internal one used for process separation of sensitive tasks, for
> providing a terminal and compatibility with some specific targets of
> personal importance, like QEmu and --hopefully soon-- Bhyve) so
> compatibility options are still limited. The simple reason being that I am
> waiting to see which one of the available ones (X, Spice, Mir, Wayland,
> ...) turns out to be the least painful option :-)
>
> Starting with the version in the subject (0.5.1), it's up and running on
> FreeBSD with an input driver using syscons/sysmouse (and respective
> keymaps). The reason I'm bothering people here is simply that I'm looking
> for more people interested in hammering out the details with the BSD
> integration and packaging.
>
> There is so much more to cover -- but if anyone is curious hare are some
> points of reference:
>
> Documentation on internals (including FreeBSD setup specifics) roadmaps,
> etc:
> https://arcan-fe.com and https://github.com/letoram/arcan/wiki
>
> A 'talking slide' high-level presentation:
> https://www.youtube.com/watch?v=07nqZIFRDJg
>
> A 'toy' desktop environment from a few years ago showing some of the crazy
> things that can be done:
> https://www.youtube.com/watch?v=3O40cPUqLbU
>
> The more serious desktop environment ('durden') that I am using myself:
> https://www.youtube.com/playlist?list=PLGqpKIeZOSp6quf6CmMOr91Tmj4UppyoR
>
> Regards,
>  Björn
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: APU2C4 information (was Re: 11.0-RC2 and 12-CURRENT won't boot on apu2c4)

2016-09-03 Thread Adrian Chadd
hi,

no, ar988x is 11ac, and i haven't finished the port.


-a


On 3 September 2016 at 06:36, O. Hartmann  wrote:
> Am Sat, 3 Sep 2016 15:25:17 +0200
> Guido Falsi  schrieb:
>
>> On 09/03/16 15:11, O. Hartmann wrote:
>> > Am Sat, 3 Sep 2016 14:01:15 +0200
>> > Michael Tuexen  schrieb:
>> >
>> >>> On 03 Sep 2016, at 13:24, Guido Falsi  wrote:
>> >>>
>> >>> On 09/03/16 13:08, Michael Tuexen wrote:
>> > On 03 Sep 2016, at 12:55, Oliver Böttcher  
>> > wrote:
>> >
>> > Am Freitag, den 02.09.2016, 22:09 +0200 schrieb Guido Falsi:
>> >> I think you should open a bug report and post the number here so
>> >> feedback about this can be collected there.
>> >
>> > Bug report filed [1]. I just noticed that the serial console is not
>> > working on >=11.0
>> >
>> > The update from 10.3 to 11.0 worked but has no output opon boot in
>> > 11.0.
>>  I'm running FreeBSD head on an apu2c4 without any problems, the serial
>>  console is working.
>> 
>>  However, I do have
>> 
>>  console="comconsole"
>>  comconsole_speed="115200"
>> 
>>  in /boot/loader.conf.
>>  It is not using ZFS and it is booting from an m-SATA SSD. Which boot 
>>  device
>>  are you using?
>> 
>> >>>
>> >>> SO it looks like a default configuration issue.
>> >>>
>> >>> This can explain why my custom nanobsd images work, I have a console
>> >>> configuration in loader there.
>> >> The default console speed of the apu2 is 115200, the one from FreeBSD 
>> >> isn't.
>> >> Without the above setting you have to use 115200 first to see the BIOS 
>> >> output
>> >> and than change the speed to whatever FreeBSD uses as its default. Using
>> >> the above settings you can use the same speed for both.
>> >>
>> >> Best regards
>> >> Michael
>> >>>
>> >>> --
>> >>> Guido Falsi 
>> >>> ___
>> >>> freebsd-current@freebsd.org mailing list
>> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> >>> To unsubscribe, send any mail to 
>> >>> "freebsd-current-unsubscr...@freebsd.org"
>> >>
>> >
>> > I do not want to "kidnap/threadnap" the thread, but I have a question: My 
>> > APU 2C4 is
>> > underway and I'm curious about whether it would boot via UEFI or not?
>>
>> I don't think it has UEFI support. These boards come with a traditional
>> old style BIOS.
>
> All right. It is coreboot, if not mistaken and I read something about a UEFI 
> support
> there, but forgot whether this is futural agenda or real by now.
>
>>
>> >
>> > I also ordered mine with a Atheros AR9882 based WiFi card and I'm also 
>> > curious about
>> > whether this chip is working with 12-CURRENT or not. The AR9880, more 
>> > powerful and
>> > newer, seems also available for this APU, but it is more expensive and I 
>> > didn't took
>> > the risc ...
>
> I checked the WiFi webpage at FreeBSD.org and these specific adapters are not 
> mentioned
> there. The support of AP capable WiFi adapters is rather limited (to Atheros 
> types), on
> Linux, more adapters seem to provide the AP functionality. Therefore, my 
> question.
>
>>
>> I don't know this device. Atheros cards have very good support in
>> general through the ath(4) driver, if you know the PCI ID of the device
>> you can check in the sources if it's known.
>>
> I'll check and report back ;-)
>
> Thank you very much.
>
> Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 11 RC1 - no wifi

2016-08-25 Thread Adrian Chadd
On 25 August 2016 at 12:45, Stefan Wendler  wrote:
> Hi,
>
> is this fixed in RC2? I haven't tried it yet but would be nice to know

Hi,

Just so everyone who may be interested/involved can see - I don't have
the spare bandwidth/cycles to try and make wifi + lagg "work", and
personally I still maintain it's unsupported until someone takes
ownership of it.

So I'd appreciate it if someone else would fix it up to continue
working. Please not rely on me to fix it. :)


-a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


compiling elf toolchain under gcc-5.3 mips

2016-08-14 Thread Adrian Chadd
hiya,

This seems to be needed for compiling elftoolchain under gcc-5.3
targeting mips (CROSS_TOOLCHAIN=mips-gcc) otherwise it complains that
sz isn't always initialised:

adrian@gertrude:~/work/freebsd/head-embedded/src % svn diff contrib
Index: contrib/elftoolchain/elfcopy/ascii.c
===
--- contrib/elftoolchain/elfcopy/ascii.c(revision 303837)
+++ contrib/elftoolchain/elfcopy/ascii.c(working copy)
@@ -251,6 +251,7 @@
sec_index = 1;
sec_addr = entry = 0;
while (fgets(line, _LINE_BUFSZ, ifp) != NULL) {
+   sz = 0; /* Quieten GCC-5.3 */
if (line[0] == '\r' || line[0] == '\n')
continue;
if (line[0] == '$' && line[1] == '$') {


Is that acceptable?



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Hardware rendered Wayland client up and running

2016-08-13 Thread Adrian Chadd
w!

ok, what has to be committed to -head?



-a


On 13 August 2016 at 19:12, Lundberg, Johannes
 wrote:
> Hi FreeBSD hackers!
>
> Today we reached a big milestone. For the first time, we could render
> Wayland clients, backed by hardware, not shm (shared memory), on Intel Atom
> Cherryview.
>
> Please see attached image of my setup.
>
> UP board (Intel Cherryview)
> OS running on on-board eMMC (need sdhci and mmc patches to function)
> Ports: https://github.com/freebsd/freebsd-ports-graphics/tree/wayland
> Base: https://github.com/FreeBSDDesktop/freebsd-base-graphics/tree/drm-next
> (from today, evdev enabled kernel)
>
> Mouse and keyboard available using libinput.
> Device detection by libudev-devd.
>
> Only one thing, we needed to disable PRIME in drm to get the Wayland
> clients to properly allocate image buffers. Working on getting that fixed!
>
> This opens up for the next big task, getting XWayland working that enable
> use of unmodified X clients as well as testing Wayland enabled libraries
> like Enlightenment, QT5, GTK3, etc. That however is not high priority for
> me so I will probably not work on that.
>
> [image: Inline image 1]
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 秘密保持について:この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
> もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
> 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
> ---
> CONFIDENTIALITY NOTE: The information in this email is confidential
> and intended solely for the addressee.
> Disclosure, copying, distribution or any other action of use of this
> email by person other than intended recipient, is prohibited.
> If you are not the intended recipient and have received this email in
> error, please destroy the original message.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: IWM(7260), no connect

2016-08-03 Thread Adrian Chadd
I've no idea, sorry. :(

Imre's out for another week, so let him finish his holiday first. :)


-a


On 3 August 2016 at 10:28, Larry Rosenman <l...@lerctr.org> wrote:
> Anyone?
> On Sun, Jul 31, 2016 at 09:19:02PM -0500, Larry Rosenman wrote:
>> I recompiled security/wpa_supplicant and seem to be able to get
>> associated.
>>
>> I'm not sure what is going on.
>>
>> Any suggestions?
>>
>> On Sun, Jul 31, 2016 at 08:36:47PM -0500, Larry Rosenman wrote:
>> > Even with that reverted, I'm still having iffy connections.
>> >
>> > Current code:
>> >
>> > FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r303597M: Sun Jul 31 
>> > 16:02:39 CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG  amd64 
>> > 121 121
>> >
>> > Current diff to that SVN Rev:
>> >
>> > Index: sys/dev/iwm/if_iwm.c
>> > ===
>> > --- sys/dev/iwm/if_iwm.c(revision 303597)
>> > +++ sys/dev/iwm/if_iwm.c(working copy)
>> > @@ -3357,15 +3357,12 @@
>> > uint8_t subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK;
>> >
>> > if (subtype == IEEE80211_FC0_SUBTYPE_ASSOC_REQ ||
>> > -   subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) {
>> > -   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_ASSOC);
>> > -   } else if (subtype == IEEE80211_FC0_SUBTYPE_ACTION) {
>> > -   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
>> > -   } else {
>> > -   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_MGMT);
>> > -   }
>> > +   subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ)
>> > +   tx->pm_frame_timeout = htole16(3);
>> > +   else
>> > +   tx->pm_frame_timeout = htole16(2);
>> > } else {
>> > -   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
>> > +   tx->pm_frame_timeout = htole16(0);
>> > }
>> >
>> > if (hdrlen & 3) {
>> > Index: sys/dev/iwm/if_iwmreg.h
>> > ===
>> > --- sys/dev/iwm/if_iwmreg.h (revision 303597)
>> > +++ sys/dev/iwm/if_iwmreg.h (working copy)
>> > @@ -4244,18 +4244,6 @@
>> > IWM_TX_CMD_FLG_HCCA_CHUNK   = (1 << 31)
>> >  }; /* IWM_TX_FLAGS_BITS_API_S_VER_1 */
>> >
>> > -/**
>> > - * enum iwm_tx_pm_timeouts - pm timeout values in TX command
>> > - * @IWM_PM_FRAME_NONE: no need to suspend sleep mode
>> > - * @IWM_PM_FRAME_MGMT: fw suspend sleep mode for 100TU
>> > - * @IWM_PM_FRAME_ASSOC: fw suspend sleep mode for 10sec
>> > - */
>> > -enum iwm_tx_pm_timeouts {
>> > -   IWM_PM_FRAME_NONE   = 0,
>> > -   IWM_PM_FRAME_MGMT   = 2,
>> > -   IWM_PM_FRAME_ASSOC  = 3,
>> > -};
>> > -
>> >  /*
>> >   * TX command security control
>> >   */
>> >
>> >
>> >
>> > Scan Debug:
>> > http://www.lerctr.org/~ler/FreeBSD/WIFI-Scan.txt
>> >
>> > What next?
>> >
>> > On Thu, Jul 28, 2016 at 06:06:47PM -0700, Adrian Chadd wrote:
>> > > +imre,
>> > >
>> > > Hi! Larry is having issues with r303418. Would you be able to help him 
>> > > out?
>> > >
>> > > (If it's not too bad, can we back this out until you figure out what's
>> > > going on?)
>> > >
>> > > Thanks!
>> > >
>> > >
>> > > -a
>> > >
>> > >
>> > > On 28 July 2016 at 18:05, Larry Rosenman <l...@lerctr.org> wrote:
>> > > > On 2016-07-28 20:02, Adrian Chadd wrote:
>> > > >>
>> > > >> Hi,
>> > > >>
>> > > >> Which commit(s) did you revert?
>> > > >>
>> > > >>
>> > > >>
>> > > >> -a
>> > > >
>> > > >
>> > > > revert r303418
>> > > >
>> > > > and now it connects again.
>> > > >
>> > > >
>> > > > --
>> > > > Larry Rosenman http://www.lerctr.org/~ler
>> > > > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
>> > > > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>> >
>> > --
>> > Larry Rosenman http://www.lerctr.org/~ler
>> > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
>> > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>>
>> --
>> Larry Rosenman http://www.lerctr.org/~ler
>> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
>> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [PATCH] randomized delay in locking primitives, take 2

2016-07-31 Thread Adrian Chadd
Hi,

Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are
any performance degredations on lower count CPUs?

Also, yeah, the MOD operator in each loop could get spendy on older
CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to
achieve much the same autotuning with pow2 operations instead of
divide/mod?


-a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: IWM(7260), no connect

2016-07-28 Thread Adrian Chadd
+imre,

Hi! Larry is having issues with r303418. Would you be able to help him out?

(If it's not too bad, can we back this out until you figure out what's
going on?)

Thanks!


-a


On 28 July 2016 at 18:05, Larry Rosenman <l...@lerctr.org> wrote:
> On 2016-07-28 20:02, Adrian Chadd wrote:
>>
>> Hi,
>>
>> Which commit(s) did you revert?
>>
>>
>>
>> -a
>
>
> revert r303418
>
> and now it connects again.
>
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: IWM(7260), no connect

2016-07-28 Thread Adrian Chadd
Hi,

Which commit(s) did you revert?



-a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: IWM(7260), no connect

2016-07-28 Thread Adrian Chadd
Hi,

Andriy responded?


-adrian


On 28 July 2016 at 16:04, Larry Rosenman  wrote:
> Anyone?
>
>
> On 2016-07-27 21:39, Larry Rosenman wrote:
>>
>> I'm running today's top of tree, and it doesn't seem to want to connect:
>>
>>
>> re0: flags=8843 metric 0 mtu 1500
>>
>> options=8209b
>> ether 20:47:47:73:07:5f
>> inet6 fe80::2247:47ff:fe73:75f%re0 prefixlen 64 scopeid 0x1
>> inet6 2001:470:1f0f:42c:2247:47ff:fe73:75f prefixlen 64 autoconf
>> inet 192.168.200.246 netmask 0xfc00 broadcast 192.168.203.255
>> nd6 options=23
>> media: Ethernet autoselect (1000baseT )
>> status: active
>> lo0: flags=8049 metric 0 mtu 16384
>> options=63
>> inet6 ::1 prefixlen 128
>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
>> inet 127.0.0.1 netmask 0xff00
>> nd6 options=21
>> groups: lo
>> wlan0: flags=8c43
>> metric 0 mtu 1500
>> ether 58:91:cf:1a:45:69
>> inet6 fe80::5a91:cfff:fe1a:4569%wlan0 prefixlen 64 scopeid 0x3
>> nd6 options=23
>> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
>> status: no carrier
>> ssid "" channel 8 (2447 MHz 11g)
>> regdomain FCC country US authmode WPA1+WPA2/802.11i privacy ON
>> deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS wme
>> roaming MANUAL
>> groups: wlan
>>
>>
>> hostb0@pci0:0:0:0:  class=0x06 card=0x07061028 chip=0x19108086
>> rev=0x07 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Skylake Host Bridge/DRAM Registers'
>> class  = bridge
>> subclass   = HOST-PCI
>> pcib1@pci0:0:1:0:   class=0x060400 card=0x20158086 chip=0x19018086
>> rev=0x07 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Skylake PCIe Controller (x16)'
>> class  = bridge
>> subclass   = PCI-PCI
>> pcib2@pci0:0:1:1:   class=0x060400 card=0x07061028 chip=0x19058086
>> rev=0x07 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Skylake PCIe Controller (x8)'
>> class  = bridge
>> subclass   = PCI-PCI
>> vgapci1@pci0:0:2:0: class=0x03 card=0x07061028 chip=0x191b8086
>> rev=0x06 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'HD Graphics 530'
>> class  = display
>> subclass   = VGA
>> none0@pci0:0:4:0:   class=0x118000 card=0x07061028 chip=0x19038086
>> rev=0x07 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Skylake Processor Thermal Subsystem'
>> class  = dasp
>> xhci0@pci0:0:20:0:  class=0x0c0330 card=0x07061028 chip=0xa12f8086
>> rev=0x31 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H USB 3.0 xHCI Controller'
>> class  = serial bus
>> subclass   = USB
>> none1@pci0:0:20:2:  class=0x118000 card=0x07061028 chip=0xa1318086
>> rev=0x31 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H Thermal subsystem'
>> class  = dasp
>> none2@pci0:0:21:0:  class=0x118000 card=0x07061028 chip=0xa1608086
>> rev=0x31 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H Serial IO I2C Controller'
>> class  = dasp
>> none3@pci0:0:22:0:  class=0x078000 card=0x07061028 chip=0xa13a8086
>> rev=0x31 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H CSME HECI'
>> class  = simple comms
>> ahci0@pci0:0:23:0:  class=0x010601 card=0x07061028 chip=0xa1038086
>> rev=0x31 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H SATA Controller [AHCI mode]'
>> class  = mass storage
>> subclass   = SATA
>> pcib3@pci0:0:28:0:  class=0x060400 card=0x07061028 chip=0xa1108086
>> rev=0xf1 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H PCI Express Root Port'
>> class  = bridge
>> subclass   = PCI-PCI
>> pcib4@pci0:0:28:4:  class=0x060400 card=0x07061028 chip=0xa1148086
>> rev=0xf1 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H PCI Express Root Port'
>> class  = bridge
>> subclass   = PCI-PCI
>> pcib5@pci0:0:28:5:  class=0x060400 card=0x07061028 chip=0xa1158086
>> rev=0xf1 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-H PCI Express Root Port'
>> class  = bridge
>> subclass   = PCI-PCI
>> pcib6@pci0:0:28:6:  class=0x060400 card=0x07061028 chip=0xa1168086
>> rev=0xf1 hdr=0x01
>> vendor = 'Intel 

Re: (boost::)asio and kqueue problem

2016-07-19 Thread Adrian Chadd
heh, nice catch. Would you please file a PR so we don't forget?

Thanks!


-a


On 19 July 2016 at 08:35, Hartmut Brandt  wrote:
> Hi,
>
> I'm trying to use asio (that's boost::asio without boost) to handle
> listening sockets asynchronuosly. This appears not to work. There are also
> some reports on the net about this problem. I was able to reproduce the
> problem with a small C-programm that does the same steps as asio. The
> relevant sequence of system calls is:
>
> kqueue() = 3 (0x3)
> socket(PF_INET,SOCK_STREAM,6)= 4 (0x4)
> setsockopt(0x4,0x,0x800,0x7fffea2c,0x4)  = 0 (0x0)
> kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0
> 4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
> setsockopt(0x4,0x,0x4,0x7fffea2c,0x4)= 0 (0x0)
> bind(4,{ AF_INET 0.0.0.0:8080 },16)  = 0 (0x0)
> listen(0x4,0x80) = 0 (0x0)
> ioctl(4,FIONBIO,0xea2c)  = 0 (0x0)
> kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0
> 4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
> kevent(3,0x0,0,0x7fffe5a0,32,0x0)ERR#4 'Interrupted system
> call'
>
> The problem here is that asio registers each file descriptor with
> EVFILT_READ and EVFILT_WRITE as soon as it is opened (first kevent call).
> After bringing the socket into the listening state and when async_accept()
> is called it registers the socket a second time. According to the man page
> this is perfectly legal and can be used to modify the registration.
>
> With this sequence of calls kevent() does not return when a connection is
> established successfully.
>
> I tracked down the problem and the reason is in soo_kqfilter(). This is
> called for the first EVFILT_READ registration and decides based on the
> SO_ACCEPTCONN flag which filter operations to use solisten_filtops or
> soread_filtops. In this case it chooses soread_filtops.
>
> The second EVFILT_READ registration does not call soo_kqfilter() again, but
> just updates the filter from the data and fflags field so the listening
> socket ends up with the wrong filter operations.
>
> The attached patch fixes this (kind of) by using the f_touch operation
> (currently used only by the user filter). The filt_sotouch() function
> changes the operation pointer in the knote when the socket is now in the
> listening state. I suppose that the required locking is already done in
> kqueue_register(), but I'm not sure. Asynchronous accepting now works.
>
> A better fix would probably be to change the operation vector on all knotes
> attached to the socket in solisten(), but I fear I don't have the necessary
> understanding of the locking that is required for this.
>
> Could somebody with enough kqueue() knowledge look whether the patch is
> correct lock-wise?
>
> Regards,
> harti
>
> Index: kern_event.c
> ===
> --- kern_event.c(revision 302977)
> +++ kern_event.c(working copy)
> @@ -1350,8 +1350,8 @@
> KQ_UNLOCK(kq);
> knl = kn_list_lock(kn);
> kn->kn_kevent.udata = kev->udata;
> -   if (!fops->f_isfd && fops->f_touch != NULL) {
> -   fops->f_touch(kn, kev, EVENT_REGISTER);
> +   if (kn->kn_fop->f_touch != NULL) {
> +   kn->kn_fop->f_touch(kn, kev, EVENT_REGISTER);
> } else {
> kn->kn_sfflags = kev->fflags;
> kn->kn_sdata = kev->data;
> Index: uipc_socket.c
> ===
> --- uipc_socket.c   (revision 302977)
> +++ uipc_socket.c   (working copy)
> @@ -160,6 +160,7 @@
>  static voidfilt_sowdetach(struct knote *kn);
>  static int filt_sowrite(struct knote *kn, long hint);
>  static int filt_solisten(struct knote *kn, long hint);
> +static voidfilt_sotouch(struct knote *kn, struct kevent *kev, u_long
> type);
>  static int inline hhook_run_socket(struct socket *so, void *hctx, int32_t
> h_id);
>  fo_kqfilter_t  soo_kqfilter;
>
> @@ -172,6 +173,7 @@
> .f_isfd = 1,
> .f_detach = filt_sordetach,
> .f_event = filt_soread,
> +   .f_touch = filt_sotouch,
>  };
>  static struct filterops sowrite_filtops = {
> .f_isfd = 1,
> @@ -3091,6 +3093,31 @@
> return (0);
>  }
>
> +static void
> +filt_sotouch(struct knote *kn, struct kevent *kev, u_long type)
> +{
> +   struct socket *so = kn->kn_fp->f_data;
> +
> +   switch (type) {
> +   case EVENT_REGISTER:
> +   if (kn->kn_fop == _filtops &&
> +   (so->so_options & SO_ACCEPTCONN))
> +   kn->kn_fop = _filtops;
> +
> +   kn->kn_sfflags = kev->fflags;
> +   kn->kn_sdata = kev->data;
> +   break;
> +
> +case EVENT_PROCESS:
> +   *kev = kn->kn_kevent;
> +   break;
> +
> 

Re: ath (AR9460) no longer works after going to 11-STABLE r302483

2016-07-15 Thread Adrian Chadd
Hi,

Just try disabling the others and see what happens.

Thanks!


-a


On 15 July 2016 at 13:28, Wolfgang Zenker <wolfg...@lyxys.ka.sub.org> wrote:
> * Adrian Chadd <adr...@freebsd.org> [160715 00:00]:
>> On 14 July 2016 at 14:37, Wolfgang Zenker <wolfg...@lyxys.ka.sub.org> wrote:
>>> * Adrian Chadd <adr...@freebsd.org> [160710 21:47]:
>>>> Since you've reverted the ath driver directories without success, I'm
>>>> mostly out of simple ideas. I think you need to bisect the whole
>>>> kernel version until you find the commit that broke things.
>
>>> done. The commit is 11-STABLE r302410. AFAICS the only change here
>>> is the removal of debugging options from the GENERIC kernel config:
>
>>> https://svnweb.freebsd.org/base/stable/11/sys/amd64/conf/GENERIC?r1=302408=302410
>
>> ... loool, okay. Let me see.
>
>> Try INVARIANTS and INVARIANT_SUPPORT. Maybe something in the ath
>> driver needs it.. oops!
>
> Nope, wlan0 still works after disabling INVARIANTS and INVARIANT_SUPPORT.
> Any suggestions for next try?
>
> Wolfgang
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: 4.6 DRM/i915 update CFT (Sandy Bridge?)/IvyBridge/Haswell/Broadwell/SkyLake/KabyLake supported

2016-07-15 Thread Adrian Chadd
Heh, I'll get mmacy to poke me some more so I can start landing more
stuff in -head to enable this.



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: ath (AR9460) no longer works after going to 11-STABLE r302483

2016-07-14 Thread Adrian Chadd
On 14 July 2016 at 14:37, Wolfgang Zenker <wolfg...@lyxys.ka.sub.org> wrote:
> Hi,
>
> * Adrian Chadd <adr...@freebsd.org> [160710 21:47]:
>> Since you've reverted the ath driver directories without success, I'm
>> mostly out of simple ideas. I think you need to bisect the whole
>> kernel version until you find the commit that broke things.
>
> done. The commit is 11-STABLE r302410. AFAICS the only change here
> is the removal of debugging options from the GENERIC kernel config:
>
> https://svnweb.freebsd.org/base/stable/11/sys/amd64/conf/GENERIC?r1=302408=302410

... loool, okay. Let me see.

Try INVARIANTS and INVARIANT_SUPPORT. Maybe something in the ath
driver needs it.. oops!



-adrian

>
> I guess next would be to remove single debugging options one after the
> other?
>
> Wolfgang
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

2016-07-13 Thread Adrian Chadd
There's a lot more in GENERIC, and we still build things twice - once
as modules, and then also inside the GENERIC image.

Hopefully warner (and others who may help!) can push forward the "bus
enumerate" bits early on in -12 so we can just use a modules-driven
kernel on platforms where that's now mostly easy (ie, i386/amd64,
arm/arm64 with loader support (which I think is all?), powerpc, etc.)

I think the one deviant atm is my embedded mips platforms, as
mips-loader is still under development.


-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: ath (AR9460) no longer works after going to 11-STABLE r302483

2016-07-10 Thread Adrian Chadd
Hi,

That message just means a receive interrupt was handled whilst the NIC
was in reset, which is mostly fine.

Since you've reverted the ath driver directories without success, I'm
mostly out of simple ideas. I think you need to bisect the whole
kernel version until you find the commit that broke things.

Thanks!


-a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: ath (AR9460) no longer works after going to 11-STABLE r302483

2016-07-09 Thread Adrian Chadd
hi,

There weren't any changes in net80211 between those times, and ath(4)
only has some changes for locationing; nothing that should cause that
particular issue.

I'll go update to the latest -head on something with that NIC and test
it out some more.

Try reverting sys/dev/ath/ and sys/contrib/dev/ath/ back to r302387
and test? (but leave the rest of the kernel as-is.)

Thanks,



-adrian

On 9 July 2016 at 12:01, Wolfgang Zenker  wrote:
> Hi,
>
> I just brought my Acer C720 from HEAD r302387 up to 11-STABLE r302483,
> using a GENERIC kernel. After the upgrade wlan0 failed to connect.
>
> Booting back into kernel.old with the new userland, wlan0 connects with
> IPv4, IPv6 only startet working after manually calling rtsol (or I might
> just have been to impatient).
>
> Relevant lines from /var/log/messages:
>
> Before the upgrade:
> Jul  9 11:58:19 faunus kernel: FreeBSD 11.0-ALPHA6 #26 r302387: Thu Jul  7 
> 14:35:59 CEST 2016
> Jul  9 11:58:19 faunus kernel: wolfgang@faunus:/usr/obj/usr/src/sys/GENERIC 
> amd64
> Jul  9 11:58:19 faunus kernel: FreeBSD clang version 3.8.0 
> (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
> Jul  9 11:58:19 faunus kernel: WARNING: WITNESS option enabled, expect 
> reduced performance.
> Jul  9 11:58:19 faunus kernel: can't re-use a leaf (ixl_rx_miss_bufs)!
> Jul  9 11:58:19 faunus kernel: VT(vga): resolution 640x480
> Jul  9 11:58:19 faunus kernel: CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz 
> (1396.79-MHz K8-class CPU)
> Jul  9 11:58:19 faunus kernel: Origin="GenuineIntel"  Id=0x40651  Family=0x6  
> Model=0x45  Stepping=1
> [..]
> Jul  9 11:58:19 faunus kernel: TSC: P-state invariant, performance statistics
> Jul  9 11:58:19 faunus kernel: real memory  = 4301258752 (4102 MB)
> Jul  9 11:58:19 faunus kernel: avail memory = 1914245120 (1825 MB)
> Jul  9 11:58:19 faunus kernel: Event timer "LAPIC" quality 600
> Jul  9 11:58:19 faunus kernel: ACPI APIC Table: 
> Jul  9 11:58:19 faunus kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 
> CPUs
> Jul  9 11:58:19 faunus kernel: FreeBSD/SMP: 1 package(s) x 2 core(s)
> [..]
> Jul  9 11:58:19 faunus kernel: pcib1:  at device 28.0 on 
> pci0
> Jul  9 11:58:19 faunus kernel: pci1:  on pcib1
> Jul  9 11:58:19 faunus kernel: ath0:  mem 
> 0xe040-0xe047 at device 0.0 on pci1
> Jul  9 11:58:19 faunus kernel: ar9300_attach: calling ar9300_hw_attach
> Jul  9 11:58:19 faunus kernel: ar9300_hw_attach: calling ar9300_eeprom_attach
> Jul  9 11:58:19 faunus kernel: ar9300_flash_map: unimplemented for now
> Jul  9 11:58:19 faunus kernel: Restoring Cal data from DRAM
> Jul  9 11:58:19 faunus kernel: Restoring Cal data from EEPROM
> Jul  9 11:58:19 faunus kernel: Restoring Cal data from Flash
> Jul  9 11:58:19 faunus kernel: Restoring Cal data from Flash
> Jul  9 11:58:19 faunus kernel: Restoring Cal data from OTP
> Jul  9 11:58:19 faunus kernel: ar9300_hw_attach: ar9300_eeprom_attach 
> returned 0
> Jul  9 11:58:19 faunus kernel: ath0: [HT] enabling HT modes
> Jul  9 11:58:19 faunus kernel: ath0: [HT] enabling short-GI in 20MHz mode
> Jul  9 11:58:19 faunus kernel: ath0: [HT] 1 stream STBC receive enabled
> Jul  9 11:58:19 faunus kernel: ath0: [HT] 1 stream STBC transmit enabled
> Jul  9 11:58:19 faunus kernel: ath0: [HT] LDPC transmit/receive enabled
> Jul  9 11:58:19 faunus kernel: ath0: [HT] 2 RX streams; 2 TX streams
> Jul  9 11:58:19 faunus kernel: ath0: AR9460 mac 640.2 RF5110 phy 610.2
> Jul  9 11:58:19 faunus kernel: ath0: 2GHz radio: 0x; 5GHz radio: 0x
> [..]
> Jul  9 11:58:19 faunus kernel: SMP: AP CPU #1 Launched!
> Jul  9 11:58:19 faunus kernel: Timecounter "TSC" frequency 1396793908 Hz 
> quality 1000
> Jul  9 11:58:19 faunus kernel: WARNING: WITNESS option enabled, expect 
> reduced performance.
> Jul  9 11:58:19 faunus kernel: Trying to mount root from 
> zfs:zroot/ROOT/default []...
> Jul  9 11:58:19 faunus kernel: wlan0: Ethernet address: 9c:d2:1e:9b:e6:41
> Jul  9 11:58:19 faunus kernel: wlan0: link state changed to UP
>
> After the upgrade:
> Jul  9 20:14:19 faunus kernel: FreeBSD 11.0-BETA1 #0 r302483: Sat Jul  9 
> 18:15:16 CEST 2016
> Jul  9 20:14:19 faunus kernel: wolfgang@faunus:/usr/obj/usr/src/sys/GENERIC 
> amd64
> Jul  9 20:14:19 faunus kernel: FreeBSD clang version 3.8.0 
> (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
> Jul  9 20:14:19 faunus kernel: can't re-use a leaf (ixl_rx_miss_bufs)!
> Jul  9 20:14:19 faunus kernel: VT(vga): resolution 640x480
> Jul  9 20:14:19 faunus kernel: CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz 
> (1396.80-MHz K8-class CPU)
> Jul  9 20:14:19 faunus kernel: Origin="GenuineIntel"  Id=0x40651  Family=0x6  
> Model=0x45  Stepping=1
> [..]
> Jul  9 20:14:19 faunus kernel: TSC: P-state invariant, performance statistics
> Jul  9 20:14:19 faunus kernel: real memory  = 4301258752 (4102 MB)
> Jul  9 20:14:19 faunus kernel: avail memory = 1918545920 (1829 MB)
> Jul  9 20:14:19 faunus kernel: Event timer "LAPIC" quality 600
> Jul  9 

Re: Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035

2016-06-27 Thread Adrian Chadd
Heh, there isn't any 11n support in rtwn (and won't be until I unify
rtwn and urtwn post-11.)

I'll go find the rtwn NIC and see if I can figure out what's going on.



-a


On 27 June 2016 at 10:21, Otacílio  wrote:
> Em 27/06/2016 14:06, Marcus von Appen escreveu:
>>
>> Hi,
>>
>> thanks to previous efforts, the rtwn(0) connection for my RTL8188CE
>> wireless card is far more stable. It seems to come at the price of
>> relatively bad performance, though. After r302035 from avos@, I
>> can't get more than 500 kbit/s downstream from anywhere.
>>
>> Let me know, what information is necessary to isolate and correct
>> that issue. I'll gladly test it. :-)
>>
>> Cheers
>> Marcus
>
>
> I have helped doing some tests with the urtwn. You can try creating the
> interface with -ht parameter. Here this improves performance.
>
> []'s
>
> -Otacílio
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic with tcp timers

2016-06-20 Thread Adrian Chadd
There's implications for RSS with how the callout system currently works.

If you don't know the RSS bucket ID of a connection in advance, you'll
create callouts on the wrong CPUs and then they're not migrated.

The initial work here did convert things over, but didn't place the
callouts in the right CPU/RSS bucket and there wasn't a mechanism to
fix this. :(

(But I'm also a firm believer of that too. I'd also finally just like
the callout system to not be tied to per-CPU queues, but also
per-RSS-bucket callout wheels so we could assign a CPU mask to a given
callout wheel and then migrating things around is just "change cpu
mask", not "change callout cpu id.")


-adrian


On 20 June 2016 at 04:00, Hans Petter Selasky  wrote:
> On 06/20/16 12:30, Gleb Smirnoff wrote:
>>
>> What does prevent us from converting TCP timeouts to locked? To my
>> understanding it is the lock order of taking pcbinfo after pcb lock.
>
>
> I started this work:
>
> https://reviews.freebsd.org/D1563
>
> --HPS
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: rtwn connection stops working on CURRENT

2016-06-17 Thread Adrian Chadd
Cool, thanks. Let's try to get this into -HEAD.


-a


On 16 June 2016 at 22:11, Marcus von Appen  wrote:
> Hi Andriy,
>
> On, Tue Jun 14, 2016, Andriy Voskoboinyk wrote:
>
>> Tue, 14 Jun 2016 08:24:01 +0300 було написано Marcus von Appen
>> :
>>
>> Hi!
>>
>> Try attached patch (adds some busdma synchronization,
>> unloads data instead of descriptor in rtwn_tx_done() and improves
>> watchdog logic for a bit).
>
> thanks a lot, the connection is far more reliable now and does not
> seem to stop working anymore.
>
> Cheers
> Marcus
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]

2016-06-17 Thread Adrian Chadd
Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.)

See if it's that.



-adrian


On 17 June 2016 at 04:19, Keith White  wrote:
> On Thu, 16 Jun 2016, Keith White wrote:
>
>> On Wed, 15 Jun 2016, Mark Millard wrote:
>>
>>> https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061904.html
>>> reports an RPI-B alignment fault for -r301815 (the snapshot) "when
>>> connecting via WiFi".
>>>
>>> -r301872 (
>>> https://lists.freebsd.org/pipermail/svn-src-head/2016-June/088339.html ) has
>>> a fix for networking vs. alignment handling for armv6 contexts that might be
>>> needed. Quoting:
>>>
 Author: ian
 Date: Mon Jun 13 16:48:27 2016
 New Revision: 301872
 URL:
 https://svnweb.freebsd.org/changeset/base/301872
>>>
>>> ...
>>
>>
>> Thanks for pointing this out!  I'll see if a (complete) rebuild at
>> that rev fixes the problem.
>>
>
> Tried that.  I still get a panic.
>
> I cross built on an amd64 at r301840, I'll try upgrading that machine too.
>
> In the meantime, other suggestions?
>
> FreeBSD 11.0-ALPHA3 #0 r301872: Thu Jun 16 21:11:44 EDT 2016
> kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm
> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM
> 3.8.0)
> VT: init without driver.
> ...
> Starting devd.
> urtwn0:  on
> usbus0
> urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
> urtwn0: enabling 11n
> wlan0: Ethernet address: 00:13:ef:74:07:a8
> Created wlan(4) interfaces: wlan0.
> ...
>
> [ nc rpi-b 22 ]
> Fatal kernel mode data abort: 'Alignment Fault' on read
> trapframe: 0xc18f28c0
> FSR=0001, FAR=c21a487a, spsr=6013
> r0 =c07a6548, r1 =0004, r2 =c0605338, r3 =07b6
> r4 =c18f2a28, r5 =c18f2b40, r6 =c21a4876, r7 =c1ccd240
> r8 =c1ccd240, r9 =c21a4Stopped at  $a.17+0x38: ldmib   r6, {r1-r2}
> db>
>
>
> ...keith
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Support for Elantech trackpads (common on new laptops)

2016-06-15 Thread Adrian Chadd
I'll test it out tonight to see if anything is regressing


a-


On 15 June 2016 at 16:50, Ben Woods  wrote:
> Hi everyone,
>
> Raphael Poss has kindly submitted a patch to bring support for Elantech
> trackpads, which are common in new laptops.
>
> I have tidied the patch so that it applies cleanly to 11-current (as of
> r301929). It is attached to PR205690.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205690
>
> Could someone familiar with moused and mice drivers in sys/dev/atkbdc/psm.c
> please have a look?
>
> Thanks,
> Ben
>
> --
> From: Benjamin Woods
> woods...@gmail.com
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: GPIO driver for Intel Atom SoC

2016-06-12 Thread Adrian Chadd
Take a look at what one of the gpio controllers do. Eg ar71xx_gpio.c.
You have to implement those methods.

(I think someone did a GPIO controller thing for some AMD CPU too?)


-a


On 11 June 2016 at 21:59, Lundberg, Johannes
 wrote:
> Hi
>
> I want to port the pinctrl-cherryview driver from Linux.
>
> I've seen there is the gpiobus and a controller gpioc, can any of these be
> leverage when porting pinctrl?
>
> What is the recommend way to proceed?
>
> Thanks!
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 秘密保持について:この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
> もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
> 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
> ---
> CONFIDENTIALITY NOTE: The information in this email is confidential
> and intended solely for the addressee.
> Disclosure, copying, distribution or any other action of use of this
> email by person other than intended recipient, is prohibited.
> If you are not the intended recipient and have received this email in
> error, please destroy the original message.
> ___
> freebsd-mob...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobile-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ath3kfw update is in the tree

2016-06-07 Thread Adrian Chadd
hi,

the ath3k update is in the tree. I'll try to get the firmware images
into the tree today.

Thanks!



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: wlan/ifconfig stopped working sometime between 5/25 and 6/3

2016-06-06 Thread Adrian Chadd
Hi,

this is a recent change to the regulatory handling. I've emailed
Andriy who wrote the code. :)

Andriy, any ideas?



-adrian


On 6 June 2016 at 20:15, Yoshihiro Ota  wrote:
> Hi,
>
> I started getting the following error when I tried to bring up wireless 
> connection since June 3rd.  I had last updated kernel and world on May 25th 
> before.
>
> "unable to get regulatory domain info: Device not configured"
>
> ifconfig starts working again after I reverted the user land backt May 25th 
> one; kernel don't seem to be a fact here.
>
> I use "ifconfig wlan create wlandev ath0 ssid  wepmode on wepkey  
> weptxkey 1 up".
> Is something changed in ifconfig?
> Do I need to use different arguments?
>
> Thanks,
> Hiro
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: r301305: buildkernel fails in ATH driver: if_ath_btcoex.c:237:9: error: no member named 'bt_period' in 'HAL_BT_COEX_INFO

2016-06-04 Thread Adrian Chadd
Fixed!


-a


On 4 June 2016 at 01:11, O. Hartmann  wrote:
> r301305 fails to buildkernel this morning with the lates updates.
>
> See below
>
>  [...]
> cc  -O2 -pipe -O3 -O3 -pipe -march=native  -fno-strict-aliasing -Werror 
> -D_KERNEL
> -DKLD_MODULE -nostdinc  -I. -I/usr/src/sys/modules/ath/../../dev/ath
> -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I.
> -I/usr/src/sys/modules/ath/../../contrib/dev/ath/ath_hal/ 
> -DHAVE_KERNEL_OPTION_HEADERS
> -include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I/usr/src/sys -fno-common
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
> -I/usr/obj/usr/src/sys/THOR  -MD
> -MF.depend.if_ath_btcoex_mci.o -MTif_ath_btcoex_mci.o -mcmodel=kernel 
> -mno-red-zone
> -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
> -ffreestanding -fwrapv
> -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
> -Wno-pointer-sign
> -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
> -fdiagnostics-show-option
> -Wno-unknown-pragmas  -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function  
> -Wno-error-pointer-sign
> -Wno-error-shift-negative-value  -mno-aes -mno-avx  -std=iso9899:1999
> -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex_mci.c -o 
> if_ath_btcoex_mci.o ---
> if_ath_btcoex.o --- 
> /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:236:9: error:
> no member named 'bt_dutyCycle' in 'HAL_BT_COEX_INFO' btinfo.bt_dutyCycle = 
> 55; ~~
> ^ /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:237:9: error: no 
> member named
> 'bt_period' in 'HAL_BT_COEX_INFO' btinfo.bt_period = 40; ~~ ^ 2 errors 
> generated.
>
>
> Regards,
>
> o.h.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: PostgreSQL performance on FreeBSD

2016-06-03 Thread Adrian Chadd
On 3 June 2016 at 11:27, Adrian Chadd <adr...@freebsd.org> wrote:

> That and the other NUMA stuff is something to address in -12.

And, I completely welcome continued development in NUMA scaling in
combination with discussion. The iterator changes I committed are a
more generic version of a patch people were applying on top of -10 and
-head for at least what, three years now? Maybe more if -9 also just
did round-robin and not first-touch?



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: PostgreSQL performance on FreeBSD

2016-06-03 Thread Adrian Chadd
On 3 June 2016 at 10:55, Konstantin Belousov  wrote:
> On Fri, Jun 03, 2016 at 11:29:13AM -0600, Alan Somers wrote:
>> On Fri, Jun 3, 2016 at 11:26 AM, Konstantin Belousov
>>  wrote:
>> > On Fri, Jun 03, 2016 at 09:29:16AM -0600, Alan Somers wrote:
>> >> I notice that, with the exception of the VM_PHYSSEG_MAX change, these
>> >> patches never made it into head or ports.  Are they unsuitable for low
>> >> core-count machines, or is there some other reason not to commit them?
>> >>  If not, what would it take to get these into 11.0 or 11.1 ?
>> >
>> > The fast page fault handler was redesigned and committed in r269728
>> > and r270011 (with several follow-ups).
>> > Instead of lock-less buffer queues iterators, Jeff changed buffer allocator
>> > to use uma, see r289279.  Other improvement to the buffer cache was
>> > committed as r267255.
>> >
>> > What was not committed is the aggressive pre-population of the phys objects
>> > mem queue, and a knob to further split NUMA domains into smaller domains.
>> > The later change is rotten.
>> >
>> > In fact, I think that with that load, what you would see right now on
>> > HEAD, is the contention on vm_page_queue_free_mtx.  There are plans to
>> > handle it.
>>
>> Thanks for the update.  Is it still recommended to enable the
>> multithreaded pagedaemon?
>
> Single-threaded pagedaemon cannot maintain the good system state even
> on non-NUMA systems, if machine has large memory.  This was the motivation
> for the NUMA domain split patch.  So yes, to get better performance you
> should enable VM_NUMA_ALLOC option.
>
> Unfortunately, there were some code changes of quite low quality which
> resulted in the NUMA-enabled system to randomly fail with NULL pointer
> deref in the vm page alloc path.  Supposedly that was fixed, but you
> should try that yourself.  One result of the mentioned changes was that
> nobody used/tested NUMA-enabled systems under any significant load, for
> quite long time.

The iterator bug was fixed, so it still behaves like it used to if
NUMA is enabled circa what, freebsd-9? If you'd like that older
behavior, you can totally flip back to the global policy being
round-robin only, and it's then a glorified, configurable-at-runtime
no-op.

The difference now is that you can tickle imbalances if you have too
many processes that need pages from a specific domain instead of round
robin, because the underlying tracking mechanisms still assume a
single global pool and global method of cleaning things.

That and the other NUMA stuff is something to address in -12.


-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: MMap in FreeBSD 11

2016-06-03 Thread Adrian Chadd
On 3 June 2016 at 05:34, Kubiak, Patryk  wrote:
> Hi ,
>
> I have question about mmap and /dev/mem in the FreeBSD 11. We found, that 
> ours applications does not work correct in the 11 - there is a problem with 
> mapping physical memory via mmap and /dev/mem device - we are receiving 
> "Permission Denied" error. Is there any important change in the new version, 
> that prohibits this operation, or it is just a bug in the OS or App?

Can you provide any further information? Maybe some example code?



-adrian

> Regards,
> Patryk
> 
>
> Intel Technology Poland sp. z o.o.
> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII 
> Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 
> 957-07-52-316 | Kapital zakladowy 200.000 PLN.
>
> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
> moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
> wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
> jakiekolwiek
> przegladanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the 
> sole use of the intended recipient(s). If you are not the intended recipient, 
> please contact the sender and delete all copies; any review or distribution by
> others is strictly prohibited.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads

2016-06-02 Thread Adrian Chadd
[snip]

a) is it on one core, or multiple cores?
b) CLOCK_MONOTONIC_FAST?
c) is it on a system that /has/ invariant-TSC ?
d) is this a multi-socket system?



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Streaming live tv over the udp protocol causes problems

2016-06-02 Thread Adrian Chadd
What are you streaming it over? wifi? ethernet? which chips?


-a


On 1 June 2016 at 20:03, Oleg Lelchuk  wrote:
> Hi. On 11-ALPHA1, when I use vlc to stream live tv over the udp protocol, I
> see a garbled and choppy video. This issue doesn't occur on 10.3-STABLE. I
> am puzzled as to the cause of this problem.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: if_iwn dhcp troubles

2016-05-30 Thread Adrian Chadd
hi,

what's the output of 'ifconfig -v wlan0 list scan' ?


-a


On 30 May 2016 at 14:15, Ronald Klop <ronald-li...@klop.ws> wrote:
> On Mon, 30 May 2016 03:01:10 +0200, Adrian Chadd <adrian.ch...@gmail.com>
> wrote:
>
>> ok, so there seem to be more lingering 802.11n issues. can you tell me
>> mrore about the environment there, so I can try to duplicate it?
>>
>> I'd like to fix whatever 11n issues there are in iwn!
>>
>> Thanks!
>>
>>
>> -a
>
>
> Hi Adrian,
>
> I don't know what you want to know, but it is just my laptop at home. I
> installed an Intel WiFi card, because the Broadcom it had didn't have
> support in FreeBSD. I normally have if_lagg configured, but disabled it to
> debug this.
> I connect with WiFi to a Ubiquiti Unifi AP AC Lite
> (https://www.ubnt.com/unifi/unifi-ap-ac-lite/).
> Other (non-freebsd) devices, like a phone, connect happily with the WiFi.
>
>
> pciconf -vl:
> ...
> iwn0@pci0:4:0:0:class=0x028000 card=0x40608086 chip=0x088e8086
> rev=0x24 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Centrino Advanced-N 6235'
> class  = network
> ...
> =
> cat /etc/wpa_supplicant.conf (really plain)
> network={
> ssid="x"
> psk=""
> }
> =
> cat /etc/rc.conf:
> # Kernel
> zfs_enable="YES"
> saver="green"
> accounting_enable="YES"
> powerd_enable="YES"
> devfs_system_ruleset="system"
> background_fsck="NO"
> dumpdev="AUTO"
> kld_list="coretemp ichsmb radeonkms fuse if_lagg vboxdrv cuse"
> keymap="/etc/keymap.test"
> # if_bwn bwn_v4_lp_ucode"
>
> # Networking
> hostname="sjakie.klop.ws"
> #wpa_supplicant_flags="$wpa_supplicant_flags -d"
> wlans_iwn0="wlan0"
> create_args_wlan0="wlanaddr 00:26:b9:12:40:a4 country NL"
> ifconfig_wlan0="-ht WPA"
> #ifconfig_bge0="up"
> #cloned_interfaces="lagg0"
> #ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0 SYNCDHCP"
>
> ifconfig_wlan0="$ifconfig_wlan0 DHCP"
>
> #ifconfig_DEFAULT="SYNCDHCP"
> #ifconfig_em0_alias0="inet 192.168.1.36 netmask 0x"
> firewall_enable="YES"
> firewall_type="/etc/ipfw.sjakie"
> #local_unbound_enable="YES"
>
> # Daemons
> ntpdate_enable="YES"
> ntpd_enable="YES"
> sshd_enable="YES"
> inetd_enable="YES"
> syslogd_flags=""
> sendmail_enable="NO"
> sendmail_submit_enable="NO"
> sendmail_outbound_enable="NO"
> sendmail_msp_queue_enable="NO"
>
> # Bluetooth
> #hcsecd_enable="YES"
> #sdpd_enable="YES"
> #bthidd_enable="YES"
>
> # Ports
> bsdstats_enable="YES"
> #postfix_enable="YES"
> #smtpd_enable="YES"
> #smtpd_flags="-v"
> cupsd_enable="YES"
> dbus_enable="YES"
> polkitd_enable="YES"
> #hald_enable="YES"
> smartd_enable="YES"
> #mdnsd_enable="YES"
> avahi_daemon_enable="YES"
> bruteblockd_enable="YES"
> bruteblockd_table="1"
> bruteblockd_flags="-s 5"
> #collectd_enable="YES"
>
> rpcbind_enable="YES"
> #nfs_client_enable="YES"
> mountd_enable="YES"
> nfs_server_enable="YES"
>
> panicmail_enable="YES"
> slim_enable="YES"
>
> webcamd_enable="YES"
> webcamd_flags="-m v4l2-dev.v4l_hflip=1"
>
>
> =
> dmesg:
> Copyright (c) 1992-2016 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 11.0-ALPHA1 #7 r300901M: Sat May 28 16:54:00 CEST 2016
> r...@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64
> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM
> 3.8.0)
> can't re-use a leaf (ixl_rx_miss_bufs)!
> VT(vga): resolution 640x480
> CPU: Pentium(R) Dual-Core CPU   T4300  @ 2.10GHz (2094.80-MHz K8-class
> CPU)
>   Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
>
> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>
> Features2=

Re: if_iwn dhcp troubles

2016-05-29 Thread Adrian Chadd
ok, so there seem to be more lingering 802.11n issues. can you tell me
mrore about the environment there, so I can try to duplicate it?

I'd like to fix whatever 11n issues there are in iwn!

Thanks!


-a


On 29 May 2016 at 14:27, Ronald Klop <ronald-li...@klop.ws> wrote:
> On Sun, 29 May 2016 19:59:05 +0200, Adrian Chadd <adrian.ch...@gmail.com>
> wrote:
>
>> hi,
>>
>> Do ifconfig wlan0 -ht (ie, disable 11n)
>>
>> see if that helps
>
>
> Hi,
>
> This does make the errors go away and startup more smoothly.
>
> Regards,
> Ronald.
>
>
>
>>
>>
>> -a
>>
>>
>> On 29 May 2016 at 05:46, Ronald Klop <ronald-li...@klop.ws> wrote:
>>>
>>> Hello,
>>>
>>> My laptop has troubles obtaining an ip address on the wlan0 (if_iwn). The
>>> interface has trouble staying up during dhcp resolving. Below some
>>> information from logs. *If* it obtains an IP address it seems quite
>>> stable
>>> afterwards.
>>> Before https://svnweb.freebsd.org/base?view=revision=300732 I
>>> had
>>> to reboot a couple of times before it would happen to get an IP address.
>>>
>>> If I need to supply more information please tell. I'm willing to test
>>> patches also.
>>>
>>> Regards,
>>> Ronald.
>>>
>>>
>>> From uname -a:
>>> FreeBSD sjakie.klop.ws 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #7 r300901M: Sat
>>> May
>>> 28 16:54:00 CEST 2016
>>> r...@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC-NODEBUG  amd64
>>>
>>> From dmesg:
>>> iwn0:  mem 0xf800-0xf8001fff irq 17 at
>>> device 0.0 on pci2
>>>
>>> From /etc/rc.conf.
>>> wlans_iwn0="wlan0"
>>> create_args_wlan0="wlanaddr 00:26:b9:12:40:a4 country NL"
>>> ifconfig_wlan0="WPA"
>>> ifconfig_wlan0="$ifconfig_wlan0 SYNCDHCP"
>>>
>>> From console.log:
>>> May 29 13:34:45 sjakie kernel: Created wlan(4) interfaces: wlan0.
>>> May 29 13:34:45 sjakie kernel: Starting wpa_supplicant.
>>> May 29 13:34:45 sjakie kernel: Starting dhclient.
>>> May 29 13:34:45 sjakie kernel: wlan0: no link ...
>>> May 29 13:34:45 sjakie kernel: ..
>>> May 29 13:34:45 sjakie kernel: ...
>>> May 29 13:34:45 sjakie kernel: got link
>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255
>>> port
>>> 67
>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255
>>> port
>>> 67
>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down
>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255
>>> port
>>> 67
>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up
>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255
>>> port
>>> 67
>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down
>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255
>>> port
>>> 67
>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255
>>> port
>>> 67 interval 6
>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up
>>> May 29 13:34:45 sjakie kernel:
>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255
>>> port
>>> 67
>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down
>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255
>>> port
>>> 67 interval 15
>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255
>>> port
>>> 67
>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up
>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255
>>> port
>>> 67
>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255
>>> port
>>> 67
>>> May 29 13:34:45 sjakie kernel: wlan0 link state up -> down
>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255
>>> port
>>> 67 interval 4
>>> May 29 13:34:45 sjakie kernel: DHCPDISCOVER on wlan0 to 255.255.255.255
>>> port
>>> 67 interval 9
>>> May 29 13:34:45 sjakie kernel: wlan0 link state down -> up
>>> May 29 13:34:45 sjakie kernel:
>>> May 29 13:34:45 sjakie kernel: DHCPREQUEST on wlan0 to 255.255.255.255
>>> port
>>> 67
>>> May 2

  1   2   3   4   5   6   7   8   9   10   >