Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
Hi! So, my Lenovo T540p also doesn't work right now; it just panics the kernel with a NULL pointer deref inside some deferred interrupt registration / callback thing. If I disable it at the boot console then it's fine. -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: Correct net80211 channel flag.
lemme go see (again). That's why I wanted to re-review it all before I landed stuff! -a On Fri, 2 Apr 2021 at 13:41, Bjoern A. Zeeb wrote: > > On 2 Apr 2021, at 6:44, Adrian Chadd wrote: > > > I've got this in my local tree now. > > That’s not a good idea? > > > I have a note to go dig up which > > draft I yanked this from and update it with reference to the draft and > > the current spec. > > > > Thanks for pointing this out! > > Aehm, am I missing something but I believe everywhere we use these > values > we do properly apply a maskshift apart from > ieee80211_vht_get_vhtcap_ie() where > we apply a shiftmask when setting them again after doing the logic > checks > so changing them will do us no good at all or am I looking at the wrong > tree? > > /bz ___ 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: Correct net80211 channel flag.
I've got this in my local tree now. I have a note to go dig up which draft I yanked this from and update it with reference to the draft and the current spec. Thanks for pointing 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: Correct net80211 channel flag.
Hi!
Oh, so from what I recall, implementations got it wrong in the early
draft days with their interop so the flag values changed.
-adrian
On Thu, 1 Apr 2021 at 20:45, qcwap <1051244...@qq.com> wrote:
>
> Well, I see.
>
> I am newly to freebsd, thanks for your answering.
> I had tried using this section of code and found these flags are not
> satisfied, after changing them, I can negotiate VHT80, VHT160 fine with iwm,
> so I pointed out this problem. I am also wondering what's the badly wrong of
> you said in draft VHT implementation?
>
> thanks
> zxystd
>
> > 2021年3月30日 上午1:26，Adrian Chadd 写道：
> >
> > hm!
> >
> > On Mon, 29 Mar 2021 at 08:02, qcwap <1051244...@qq.com> wrote:
> >>
> >> This patch corrects ieee80211_vht_get_vhtcap_ie for 160/80P80 channel
> >> width recognition.
> >>
> >> diff --git a/sys/net80211/ieee80211.h b/sys/net80211/ieee80211.h
> >> index 86ab1459cca..76c43629b33 100644
> >> --- a/sys/net80211/ieee80211.h
> >> +++ b/sys/net80211/ieee80211.h
> >> @@ -811,9 +811,9 @@ struct ieee80211_ie_vht_operation {
> >> #defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_MASK 0x000C
> >> #defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_MASK_S 2
> >> #defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_NONE 0
> >> -#defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_160MHZ 1
> >> -#defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_160_80P80MHZ 2
> >> -#defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_RESERVED 3
> >> +#defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_160MHZ 4
> >> +#defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_160_80P80MHZ 8
> >> +#defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_RESERVED 16
> >>
> >> #defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160MHZ(_vhtcaps)
> >> \
> >> (_IEEE80211_MASKSHIFT(_vhtcaps, IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_MASK)
> >> >= \
> >
> >
> > This is the flag change from the draft 11ac spec to the released 11ac
> > spec, right?
> >
> > I remember they needed to change the flags because existing draft
> > implementations got the 80+80/160MHz negotiation really badly wrong in
> > some interop places...
> >
> >
> > -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: Correct net80211 channel flag.
hm!
On Mon, 29 Mar 2021 at 08:02, qcwap <1051244...@qq.com> wrote:
>
> This patch corrects ieee80211_vht_get_vhtcap_ie for 160/80P80 channel width
> recognition.
>
> diff --git a/sys/net80211/ieee80211.h b/sys/net80211/ieee80211.h
> index 86ab1459cca..76c43629b33 100644
> --- a/sys/net80211/ieee80211.h
> +++ b/sys/net80211/ieee80211.h
> @@ -811,9 +811,9 @@ struct ieee80211_ie_vht_operation {
> #defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_MASK 0x000C
> #defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_MASK_S 2
> #defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_NONE 0
> -#defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_160MHZ 1
> -#defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_160_80P80MHZ 2
> -#defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_RESERVED 3
> +#defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_160MHZ 4
> +#defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_160_80P80MHZ 8
> +#defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_RESERVED 16
>
> #defineIEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160MHZ(_vhtcaps)
> \
> (_IEEE80211_MASKSHIFT(_vhtcaps, IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_MASK)
> >= \
This is the flag change from the draft 11ac spec to the released 11ac
spec, right?
I remember they needed to change the flags because existing draft
implementations got the 80+80/160MHz negotiation really badly wrong in
some interop places...
-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 + gcc9 -- still broken
I'm just testing the build out before I put up some patches. jhb mentioned we don't install the libatomic gcc bits right now? So we should likely poke at that somewhat too after this. I'll put up some patches to fix gcc builds and this c++ contention thing soon. -adrian On Sun, 4 Oct 2020 at 23:47, Dimitry Andric wrote: > Sorry, i hadn't picked up on this thread at all. What is the concrete > patch you are proposing? Is is in Phabricator somewhere? > > (Note that when building with gcc, we should really just automatically add > -latomic, to get rid of these errors.) > > -Dimitry > > > On 5 Oct 2020, at 05:40, Adrian Chadd wrote: > > > > ping! > > > > I've got the world building on gcc + mips32 just patching > cxx_contention_t to be 32 bits, but it looks like an ABI change. > > > > Would the better thing be to just make it 32 bits on FreeBSD + MIPS for > now? I don't think anyone is going to mind that changing at this point. > > > > > > > > -adrian > > > > > > On Sat, 3 Oct 2020 at 13:35, Adrian Chadd wrote: > > > > > > On Mon, 21 Sep 2020 at 00:43, Alexander Richardson < > arichard...@freebsd.org> wrote: > > > > On Mon, 21 Sep 2020, 07:38 Adrian Chadd, wrote: > > So, the big list of unknown symbols was my fault! Whoops. > > > > i've gotten further using gcc-6.4 by fixing some of the warnings/issues > > that have crept up. > > > > Here's a review for one of them: > > > > https://reviews.freebsd.org/D26504 > > > > However, now I've hit: > > > > /usr/local/bin/mips-unknown-freebsd13.0-ld: > > > /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: > > undefined reference to `__atomic_fetch_sub_8' > > /usr/local/bin/mips-unknown-freebsd13.0-ld: > > > /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: > > undefined reference to `__atomic_load_8' > > /usr/local/bin/mips-unknown-freebsd13.0-ld: > > > /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: > > undefined reference to `__atomic_fetch_add_8' > > > > .. looks like we need some 64 bit atomics now in mips32 for libc++ / devd > > > > Those are now provided by compiler-rt when using clang. With GCC you'll > have to link libatomic. I had a quick look at the code in libc++ that uses > the 64-bit atomics a few weeks ago and I believe it's the futex fallback > code. The best solution would probably be to port it to use umtx but for > MIPS32 it might be fine to use a 32 bit atomic instead. > > > > It compiled fine with a 32 bit atomic. Why's it 64 bit for everything > but Linux? > > > > Can we make it a 32 bit atomic for all FreeBSD platforms? Are there ABI > concerns? > > > > > > > > -adrian > > > > > > Alex > > ___ 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 + gcc9 -- still broken
ping! I've got the world building on gcc + mips32 just patching cxx_contention_t to be 32 bits, but it looks like an ABI change. Would the better thing be to just make it 32 bits on FreeBSD + MIPS for now? I don't think anyone is going to mind that changing at this point. -adrian On Sat, 3 Oct 2020 at 13:35, Adrian Chadd wrote: > > > On Mon, 21 Sep 2020 at 00:43, Alexander Richardson < > arichard...@freebsd.org> wrote: > >> >> On Mon, 21 Sep 2020, 07:38 Adrian Chadd, wrote: >> >>> So, the big list of unknown symbols was my fault! Whoops. >>> >>> i've gotten further using gcc-6.4 by fixing some of the warnings/issues >>> that have crept up. >>> >>> Here's a review for one of them: >>> >>> https://reviews.freebsd.org/D26504 >>> >>> However, now I've hit: >>> >>> /usr/local/bin/mips-unknown-freebsd13.0-ld: >>> >>> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: >>> undefined reference to `__atomic_fetch_sub_8' >>> /usr/local/bin/mips-unknown-freebsd13.0-ld: >>> >>> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: >>> undefined reference to `__atomic_load_8' >>> /usr/local/bin/mips-unknown-freebsd13.0-ld: >>> >>> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: >>> undefined reference to `__atomic_fetch_add_8' >>> >>> .. looks like we need some 64 bit atomics now in mips32 for libc++ / devd >>> >> >> Those are now provided by compiler-rt when using clang. With GCC you'll >> have to link libatomic. I had a quick look at the code in libc++ that uses >> the 64-bit atomics a few weeks ago and I believe it's the futex fallback >> code. The best solution would probably be to port it to use umtx but for >> MIPS32 it might be fine to use a 32 bit atomic instead. >> > > It compiled fine with a 32 bit atomic. Why's it 64 bit for everything but > Linux? > > Can we make it a 32 bit atomic for all FreeBSD platforms? Are there ABI > concerns? > > > > -adrian > > >> >> Alex >> >>> ___ 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 + gcc9 -- still broken
On Mon, 21 Sep 2020 at 00:43, Alexander Richardson wrote: > > On Mon, 21 Sep 2020, 07:38 Adrian Chadd, wrote: > >> So, the big list of unknown symbols was my fault! Whoops. >> >> i've gotten further using gcc-6.4 by fixing some of the warnings/issues >> that have crept up. >> >> Here's a review for one of them: >> >> https://reviews.freebsd.org/D26504 >> >> However, now I've hit: >> >> /usr/local/bin/mips-unknown-freebsd13.0-ld: >> >> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: >> undefined reference to `__atomic_fetch_sub_8' >> /usr/local/bin/mips-unknown-freebsd13.0-ld: >> >> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: >> undefined reference to `__atomic_load_8' >> /usr/local/bin/mips-unknown-freebsd13.0-ld: >> >> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: >> undefined reference to `__atomic_fetch_add_8' >> >> .. looks like we need some 64 bit atomics now in mips32 for libc++ / devd >> > > Those are now provided by compiler-rt when using clang. With GCC you'll > have to link libatomic. I had a quick look at the code in libc++ that uses > the 64-bit atomics a few weeks ago and I believe it's the futex fallback > code. The best solution would probably be to port it to use umtx but for > MIPS32 it might be fine to use a 32 bit atomic instead. > It compiled fine with a 32 bit atomic. Why's it 64 bit for everything but Linux? Can we make it a 32 bit atomic for all FreeBSD platforms? Are there ABI concerns? -adrian > > Alex > >> ___ 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 + gcc9 -- still broken
So, the big list of unknown symbols was my fault! Whoops. i've gotten further using gcc-6.4 by fixing some of the warnings/issues that have crept up. Here's a review for one of them: https://reviews.freebsd.org/D26504 However, now I've hit: /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: undefined reference to `__atomic_fetch_sub_8' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: undefined reference to `__atomic_load_8' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: undefined reference to `__atomic_fetch_add_8' .. looks like we need some 64 bit atomics now in mips32 for libc++ / devd. -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: Plans for git
On Sun, 20 Sep 2020 at 15:37, Rick Macklem wrote: > Christian Weisgerber wrote: > > On 2020-09-19, Zaphod Beeblebrox wrote: > > > > > Hrm. Maybe what I hear others saying, tho, and not entirely being > replied > > > to is just a nice concise document of the why. What I hear you saying > is > > > that GIT has momentum and that it's popular... (and I accept that --- > it is > > > evidently true), but then I hear handwaving about features, but no > list of > > > features that are a clear win/loose. > > > > How about the very basics (that Warner appears to have lost sight > > of)? > > > > Git is a distributed version control system. You clone a repository > > and apart from pulling and pushing changes to another repository, > > all your work happens with the local repository. Subversion has a > > central repository and needs to talk to the server all the time. > > Laptop on a plane? No change of workflow with Git. > Well, I (mostly lurk) on the linux-...@vger.kernels.org mailing list, > where the Linux NFS work gets done. > What I see is the following, when someone has an enhancement/change > for the Linux NFS code. > Do I see one diff with all the changes in it...No. > I see anywhere from a few to over 50 email messages, each with > one little piece of the pie, out of git. > > I have no idea how they review this stuff. > It's done in patchwork.kernel.org. This takes the contents of very specifically correctly formatted git-email contents and wraps up the series as something that can be assigned to patchwork users for review/feedback. All of it goes in and out of email. It's basically using the public Linux email lists as part discussion and part RPC between everyones' git repositories. I think this stuff predates github, where there's a much nicer web flow for doing stuff like this. The linux model works great in a world where you're /truely/ decentralised. I bet that 99% of git users use some web frontend that's integrated into CI and patch review. HTH, -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"
mips32 + gcc9 -- still broken
hi! So mips32 and gcc9 is broken, and things have been broken with mips32+gcc for months now. I've been poking slowly at the various build failures and they're getting slowly fixed, but this one deep in linker fun is stumping me: === /usr/local/bin/mips-unknown-freebsd13.0-gcc9 --sysroot=/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp -B/usr/local/mips-unknown-freebsd13.0/bin/ -O -pipe -fno-common -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/usr/home/adrian/work/freebsd/head-embedded/src/usr.bin/at -I/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun -DLOGIN_CAP -DPAM -G0 -EB -mabi=32 -msoft-float -march=mips32 -g -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered -Wno-error=deprecated-declarations -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing -Wno-error=uninitialized -Wno-error=unused-but-set-variable -Wno-error=unused-function -Wno-error=unused-value -Wno-error=empty-body -Wno-error=maybe-uninitialized -Wno-error=nonnull-compare -Wno-error=redundant-decls -Wno-error=shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable -Wno-error=bool-operation -Wno-error=deprecated -Wno-error=expansion-to-defined -Wno-error=format-overflow -Wno-error=format-truncation -Wno-error=implicit-fallthrough -Wno-error=int-in-bool-context -Wno-error=memset-elt-size -Wno-error=noexcept-type -Wno-error=nonnull -Wno-error=pointer-compare -Wno-error=stringop-overflow -Wno-error=aggressive-loop-optimizations -Wno-error=cast-function-type -Wno-error=catch-value -Wno-error=multistatement-macros -Wno-error=restrict -Wno-error=sizeof-pointer-memaccess -Wno-error=stringop-truncation -Wno-error=empty-body -Wno-error=overflow -Wno-address-of-packed-member -EB -mabi=32 -o atrun.full atrun.o gloadavg.o -lpam -lutil /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/crt1.o: in function `__start': /usr/home/adrian/work/freebsd/head-embedded/src/lib/csu/mips/crt1_c.c:76: undefined reference to `_init_tls' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/lib/csu/mips/crt1_c.c:76: undefined reference to `_init_tls' /usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `perr': /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:417: undefined reference to `vsyslog' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:417: undefined reference to `vsyslog' /usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `perrx': /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:433: undefined reference to `vsyslog' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:433: undefined reference to `vsyslog' /usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `run_file': /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:348: undefined reference to `waitpid' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:348: undefined reference to `waitpid' /usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `main': /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:478: undefined reference to `openlog' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:478: undefined reference to `openlog' /usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `usage': /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:590: undefined reference to `syslog' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:590: undefined reference to `syslog' /usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `main': /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:532: undefined reference to `time' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:532: undefined reference to `time' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:510: undefined reference to `sysctlbyname' /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home/adrian/work/freebsd/head-embedded/src/libexec
Re: svn commit: r364936 - in head: lib lib/libnetmap share/mk
hi!
This code fails compilation on mips32 + gcc, as it assumes uint64_t and
pointer casts are the same underlying size.
===
/usr/local/bin/mips-unknown-freebsd13.0-gcc9
--sysroot=/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp
-B/usr/local/mips-unknown-freebsd13.0/bin/ -O -pipe -fno-common -G0 -EB
-mabi=32 -msoft-float -march=mips32
-I/usr/home/adrian/work/freebsd/head-embedded/src/sys/net
-I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap -g -MD
-MF.depend.nmport.o -MTnmport.o -std=gnu99 -Wno-format-zero-length
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds
-Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align
-Wno-error=clobbered -Wno-error=deprecated-declarations
-Wno-error=enum-compare -Wno-error=extra -Wno-error=inline
-Wno-error=logical-not-parentheses -Wno-error=strict-aliasing
-Wno-error=uninitialized -Wno-error=unused-but-set-variable
-Wno-error=unused-function -Wno-error=unused-value -Wno-error=empty-body
-Wno-error=maybe-uninitialized -Wno-error=nonnull-compare
-Wno-error=redundant-decls -Wno-error=shift-negative-value
-Wno-error=tautological-compare -Wno-error=unused-const-variable
-Wno-error=bool-operation -Wno-error=deprecated
-Wno-error=expansion-to-defined -Wno-error=format-overflow
-Wno-error=format-truncation -Wno-error=implicit-fallthrough
-Wno-error=int-in-bool-context -Wno-error=memset-elt-size
-Wno-error=noexcept-type -Wno-error=nonnull -Wno-error=pointer-compare
-Wno-error=stringop-overflow -Wno-error=aggressive-loop-optimizations
-Wno-error=cast-function-type -Wno-error=catch-value
-Wno-error=multistatement-macros -Wno-error=restrict
-Wno-error=sizeof-pointer-memaccess -Wno-error=stringop-truncation
-Wno-error=empty-body -Wno-error=overflow -Wno-address-of-packed-member
-c /usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c
-o nmport.o
In file included from
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c:46:
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c: In
function 'nmport_register':
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/libnetmap.h:557:14:
error: cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]
557 | for ((o_) = (struct nmreq_option *)((h_)->nr_options);\
| ^
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c:547:3:
note: in expansion of macro 'nmreq_foreach_option'
547 | nmreq_foreach_option(&d->hdr, o) {
| ^~~~
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/libnetmap.h:559:14:
error: cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]
559 | (o_) = (struct nmreq_option *)((o_)->nro_next))
| ^
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c:547:3:
note: in expansion of macro 'nmreq_foreach_option'
547 | nmreq_foreach_option(&d->hdr, o) {
| ^~~~
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c: In
function 'nmport_mmap':
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c:617:13:
error: cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]
617 |m->mem = (void *)d->extmem->nro_usrptr;
| ^
cc1: all warnings being treated as errors
*** [nmport.o] Error code 1
===
Are you able to fix this? pretty please? :)
-adrian
On Fri, 28 Aug 2020 at 13:04, Vincenzo Maffione
wrote:
> Author: vmaffione
> Date: Fri Aug 28 20:03:54 2020
> New Revision: 364936
> URL: https://svnweb.freebsd.org/changeset/base/364936
>
> Log:
> lib: add libnetmap
>
> This changeset introduces the new libnetmap library for writing
> netmap applications.
> Before libnetmap, applications could either use the kernel API
> directly (e.g. NIOCREGIF/NIOCCTRL) or the simple header-only-library
> netmap_user.h (e.g. nm_open(), nm_close(), nm_mmap() etc.)
>
> The new library offers more functionalities than netmap_user.h:
> - Support for complex netmap options, such as external memory
> allocators or per-buffer offsets. This opens the way to future
> extensions.
> - More flexibility in the netmap port bind options, such as
> non-numeric names for pipes, or the ability to specify the netmap
> allocator that must be used for a given port.
> - Automatic tracking of the netmap memory regions in use across the
> open ports.
>
> At the moment there is no man page, but the libnetmap.h header file
> has in-depth documentation.
>
> Reviewed by: hrs
> MFC after:2 weeks
> Differential Revision:https://reviews.freebsd.org/D26171
>
> Added:
> head/lib/libnetmap/
> head/lib/libnetmap/Makefile (contents, props changed)
> head/lib/libnetmap/libnetmap.h (contents, props changed)
>
Re: Panic with wifi + usb in latest FreeBSD-current
On Sun, 13 Sep 2020 at 22:34, Warner Losh wrote: > > > On Sun, Sep 13, 2020, 11:29 PM Adrian Chadd > wrote: > >> Yeah, this was also reported in #freebsd-wireless today. >> >> Is there a lock being held in the rtwn path that shouldn't be? >> > > I'll check in the morning... this was like the 20th thing to go wrong this > weekend, so I copied the panic down, send the email and grabbed a beer and > turned it off... > Ok. I checked the driver and the usb stack; nothing in the change lists obviously stands out to me at 11pm on a Sunday. Can you see if any locks are held? or an epoch? Something smells fishy. (defining EPOCH_TRACE will dump the list of epochs, if I'm reading the subr_sleepqueue.c code correctly.) Ok, so, since I dug a bit more on a hunch, I bet the NET epoch is being held - it's grabbed in rtwn_bulk_rx_callback, and rtwn_rx_common is reading some registers as part of processing the receive queue. I bet that act of reading registers over blocking USB is causing things to explode. If it is net epoch then we're going to have to think of a better design pattern here to migrate all of these here wifi drivers to, because I guarantee you they're all behaving poorly in this newer world order. Thanks, -adrian > > panic: sleepq_add: td to sleep on wchan with sleeping >>> prohibited >>> cpuid = 5 >>> time = 1600057358 >>> KDB: stack backtrace: >>> ... >>> panic() >>> sleepq_add() >>> _cv_wait() >>> usbd_do_request_flags >>> rtwn_do_request >>> rtwn_usb_read_4 >>> rtwn_rx_common >>> rtwn_bulk_rx_callback >>> usbd_callback_wrapper >>> usb_command_wrapper >>> usb_callback_proc >>> usb_process >>> ... >>> >>> I've done a fresh installworld and installkernel, but am running packages >>> from late may since I've not updated them. I've updated the iichid and >>> drm-kmod ports and rebuilt them and reinstalled them as well (so I know >>> they aren't out of date). >>> >>> Has anybody else seen this? >>> >>> Warner >>> ___ >>> 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 wifi + usb in latest FreeBSD-current
Yeah, this was also reported in #freebsd-wireless today. Is there a lock being held in the rtwn path that shouldn't be? -adrian On Sun, 13 Sep 2020 at 21:30, Warner Losh wrote: > I'm running current as of -2h ago. > > When I plug in my rtwn0 device and it configures, etc, I get: > > rtwn0 on uhub 0 > rtwn0: on > usbus0 > rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > host dpa_supplicant[1619]: ioctl[SIOS80211, op=20, val=0, > arg_len=7]: Invalid argument > panic: sleepq_add: td to sleep on wchan with sleeping > prohibited > cpuid = 5 > time = 1600057358 > KDB: stack backtrace: > ... > panic() > sleepq_add() > _cv_wait() > usbd_do_request_flags > rtwn_do_request > rtwn_usb_read_4 > rtwn_rx_common > rtwn_bulk_rx_callback > usbd_callback_wrapper > usb_command_wrapper > usb_callback_proc > usb_process > ... > > I've done a fresh installworld and installkernel, but am running packages > from late may since I've not updated them. I've updated the iichid and > drm-kmod ports and rebuilt them and reinstalled them as well (so I know > they aren't out of date). > > Has anybody else seen this? > > Warner > ___ > 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: driver for cp2112 (USB GPIO and I2C gadget)
hi! On Wed, 8 Jul 2020 at 02:39, Andriy Gapon wrote: > On 19/06/2020 17:14, Andriy Gapon wrote: > > > > If anyone interested in reviewing a new driver please help yourself to: > > https://reviews.freebsd.org/D25359 > > https://reviews.freebsd.org/D25360 > > What might be curious about it is that there are usb, i2c and gpio mixed > together. > Any interest at all? > I am still torn about which of the approaches to take. > I prefer the non monolithic one. i left comments on that one. :-) -adrian > -- > Andriy Gapon > ___ > 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: iflib and options RSS is a no go for igbX
On Tue, 26 May 2020 at 17:01, Matthew Macy wrote: > > > > > I can go setup my second PC this week (I have PTO!) and go see if I > > have any PCIe igb hardware here. I /think/ I do but it's fibre. > > The RSS compile time option used to be disabled in part because of > this. The drivers had working RSS that relied on packet receipt before > setting flowid. And it should also work fine if you don't compile in the RSS option. The reason it's annoying is when you do RSS + PCBGROUPS; as I said in the ena review the challenge was getting traffic into the right pcbgroup inpcb list and that isn't doable if you're waiting for hardware flowid first. Honestly I think we should rename it to something else besides RSS, cause it's more like PCBGROUPS + microsoft RSS. It's not very well named right now and I think it's confusing tf out a lot of people. -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: iflib and options RSS is a no go for igbX
reply to all this time: On Tue, 26 May 2020 at 02:03, Hans Petter Selasky wrote: > > Hi, > > I just found a bug where outgoing TCP connections over igb0 doesn't work > because likely the software computed hash is wrong, so the incoming > packets get dropped because they are received on the wrong queue. > > It is the management port, so I'm just using this hack for now: > > dev.igb.0.iflib.override_nrxqs=1 > dev.igb.0.iflib.override_ntxqs=1 Did iflib + RSS get broken? Cause it used to work just fine when I was still doing networking stuff at norse, and igb was one of the supported pieces of hardware I fixed up RSS on. The trick was literally making sure the tcp/udp l3 / l4 hash configuration was setup right (which it was by default for at least igb, where RSS worked!) and the hardware programmed in the right RSS key. Outbound connections would work fine, but they wouldn't be created in the local RSS CPU because you didn't know the details until you finished creating a socket. But all the hijinx were done behind the scenes so things got lined up in the right queues. I can go setup my second PC this week (I have PTO!) and go see if I have any PCIe igb hardware here. I /think/ I do but it's fibre. -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: Can't cross-compile HEAD
On Fri, 21 Feb 2020 at 12:57, Kyle Evans wrote: > Ahhh, this makes more sense now. > > > Not sure about Makefile.depend file as it says 'Autogenerated - do NOT > > edit!' (would be great to extend the comment with info autogenerated > > by 'what' exactly), and not sure if I pointed dependency dirs right. > > > > We'll just drop the Makefile.depend hunk of the patch -- this is > autogenerated and maintained by particular people, and shouldn't need > active attention. > > > As far as I know Andrian is trying to get rid of libarchive entirely > > in freebsd-wifi-build project, so this should not be a problem in the > > future. > > > > But isn't it has to be fixed right now until we get a replacement? > > > > I'd be inclined to agree. Unless Adrian objects, I think it'd be a > good idea to go ahead and commit the additional linkage until he does > get it hashed out. > yeah, do it. I need to update bsdbox a bit anyway to allow for external build configs... -adrian > Thanks, > > Kyle Evans ___ 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 can't discover known networks after relocating
I've no idea, bgscan is broken with atheros NICs because the driver still doesn't do background scan without dropping frames :( (one of many thing I'd love to fix, but life/time.) please do experiment though! I think wpa_supplicant's roaming logic would benefit from a lot more work. -adrian On Thu, 19 Sep 2019 at 15:21, Johannes Lundberg wrote: > > On 9/19/19 3:06 PM, Adrian Chadd wrote: > > So roaming in ifconfig/net80211 is what's set to manual. > > wpa_supplicant right now does RSSI threshold based roaming. All of the > roaming and network preferences when wpa_supplicant is running is done in > wpa_supplicant. That's where you have to look. Ideally wpa_supplicant would > be triggering bgscan too periodically rather than only when the RSSI is low. > > > > -adrian > > > On Thu, 19 Sep 2019 at 15:04, Cy Schubert wrote: > >> On September 19, 2019 8:20:07 AM PDT, Adrian Chadd < >> adrian.ch...@gmail.com> wrote: >> >Roaming is done in wpa_supplicant when it's running.That's where the >> >smarts >> >need to be. :( >> > >> > >> > >> >-adrian >> > >> > >> >On Thu, 19 Sep 2019 at 05:44, Bjoern A. Zeeb >> > >> >wrote: >> > >> >> On 19 Sep 2019, at 12:28, Tom Jones wrote: >> >> >> >> Hi, >> >> >> >> freebsd-wireless might be a better list for all this .. >> >> >> >> >> >> > On Tue, Sep 17, 2019 at 04:36:28PM +, Poul-Henning Kamp wrote: >> >> >> >> >> >> In message <707bcd3f-fa6b-82eb-fa8f-09c4b800f...@freebsd.org> >> <707bcd3f-fa6b-82eb-fa8f-09c4b800f...@freebsd.org>, >> >> >> Johannes Lundber >> >> >> g writes: >> >> >> >> >> >>> For a long time now I have had this problem with iwm and wlan0. >> >> >>> Whenever >> >> >>> I move between work and home it won't reconnect automatically and >> >I >> >> >>> have >> >> >>> to do wlan0 scan manually for it to pick up the different >> >network. >> >> >> >> >> >> I suffer from the dreaded "reason=0" when I move inside my house: >> >> >> >> >> >> > scan >> >> >> OK >> >> >> <3>CTRL-EVENT-SCAN-RESULTS >> >> >> <3>Trying to associate with 6c:3b:6b:3d:a2:e9 >> >(SSID='Palombia' >> >> >> freq=2452 MHz) >> >> >> <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:3d:a2:e9 reason=0 >> >> >> <3>CTRL-EVENT-SCAN-RESULTS >> >> >> <3>Trying to associate with 6c:3b:6b:ab:ce:d4 >> >(SSID='Palombia' >> >> >> freq=2412 MHz) >> >> >> <3>Associated with 6c:3b:6b:ab:ce:d4 >> >> >> >> >> >> a2:e9 is the loudest AP here in my office, but my I have been in >> >the >> >> >> other end of the house iwn consistently fails to associate with it >> >> >> and >> >> >> and keeps picking the weaker AP in the far end. >> >> >> >> >> >> Eventually (hours!) it disconnects from the weaker ap, also with >> >> >> "reason=0" and gets it right: >> >> >> >> >> >> <3>WPA: Group rekeying completed with 6c:3b:6b:ab:ce:d4 >> >[GTK=CCMP] >> >> >> <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:ab:ce:d4 reason=0 >> >> >> <3>CTRL-EVENT-SCAN-RESULTS >> >> >> <3>Trying to associate with 6c:3b:6b:3d:a2:e9 >> >(SSID='Palombia' >> >> >> freq=2452 MHz) >> >> >> <3>Associated with 6c:3b:6b:3d:a2:e9 >> >> >> <3>WPA: Key negotiation completed with 6c:3b:6b:3d:a2:e9 >> >[PTK=CCMP >> >> >> GTK=CCMP] >> >> >> <3>CTRL-EVENT-CONNECTED - Connection to 6c:3b:6b:3d:a2:e9 >> >> completed >> >> >> [id=3 id_str=] >> >> >> <3>WPA: Group rekeying completed with 6c:3b:6b:3d:a2:e9 >> >[GTK=CCMP] >> >> >> >> >> >> And yes, working roaming would be nice too... >> >> > >> >> > I have the problem that when roaming networks become disabled >> >>
Re: wlan can't discover known networks after relocating
So roaming in ifconfig/net80211 is what's set to manual. wpa_supplicant right now does RSSI threshold based roaming. All of the roaming and network preferences when wpa_supplicant is running is done in wpa_supplicant. That's where you have to look. Ideally wpa_supplicant would be triggering bgscan too periodically rather than only when the RSSI is low. -adrian On Thu, 19 Sep 2019 at 15:04, Cy Schubert wrote: > On September 19, 2019 8:20:07 AM PDT, Adrian Chadd > wrote: > >Roaming is done in wpa_supplicant when it's running.That's where the > >smarts > >need to be. :( > > > > > > > >-adrian > > > > > >On Thu, 19 Sep 2019 at 05:44, Bjoern A. Zeeb > > > >wrote: > > > >> On 19 Sep 2019, at 12:28, Tom Jones wrote: > >> > >> Hi, > >> > >> freebsd-wireless might be a better list for all this .. > >> > >> > >> > On Tue, Sep 17, 2019 at 04:36:28PM +, Poul-Henning Kamp wrote: > >> >> > >> >> In message <707bcd3f-fa6b-82eb-fa8f-09c4b800f...@freebsd.org>, > >> >> Johannes Lundber > >> >> g writes: > >> >> > >> >>> For a long time now I have had this problem with iwm and wlan0. > >> >>> Whenever > >> >>> I move between work and home it won't reconnect automatically and > >I > >> >>> have > >> >>> to do wlan0 scan manually for it to pick up the different > >network. > >> >> > >> >> I suffer from the dreaded "reason=0" when I move inside my house: > >> >> > >> >> > scan > >> >> OK > >> >> <3>CTRL-EVENT-SCAN-RESULTS > >> >> <3>Trying to associate with 6c:3b:6b:3d:a2:e9 > >(SSID='Palombia' > >> >> freq=2452 MHz) > >> >> <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:3d:a2:e9 reason=0 > >> >> <3>CTRL-EVENT-SCAN-RESULTS > >> >> <3>Trying to associate with 6c:3b:6b:ab:ce:d4 > >(SSID='Palombia' > >> >> freq=2412 MHz) > >> >> <3>Associated with 6c:3b:6b:ab:ce:d4 > >> >> > >> >> a2:e9 is the loudest AP here in my office, but my I have been in > >the > >> >> other end of the house iwn consistently fails to associate with it > >> >> and > >> >> and keeps picking the weaker AP in the far end. > >> >> > >> >> Eventually (hours!) it disconnects from the weaker ap, also with > >> >> "reason=0" and gets it right: > >> >> > >> >> <3>WPA: Group rekeying completed with 6c:3b:6b:ab:ce:d4 > >[GTK=CCMP] > >> >> <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:ab:ce:d4 reason=0 > >> >> <3>CTRL-EVENT-SCAN-RESULTS > >> >> <3>Trying to associate with 6c:3b:6b:3d:a2:e9 > >(SSID='Palombia' > >> >> freq=2452 MHz) > >> >> <3>Associated with 6c:3b:6b:3d:a2:e9 > >> >> <3>WPA: Key negotiation completed with 6c:3b:6b:3d:a2:e9 > >[PTK=CCMP > >> >> GTK=CCMP] > >> >> <3>CTRL-EVENT-CONNECTED - Connection to 6c:3b:6b:3d:a2:e9 > >> completed > >> >> [id=3 id_str=] > >> >> <3>WPA: Group rekeying completed with 6c:3b:6b:3d:a2:e9 > >[GTK=CCMP] > >> >> > >> >> And yes, working roaming would be nice too... > >> > > >> > I have the problem that when roaming networks become disabled > >> > > >> > $ wpa_cli > >> > Selected interface 'wlan0' > >> > > >> > Interactive mode > >> > > >> > > list_networks > >> > network id / ssid / bssid / flags > >> > 0 network1any [CURRENT] > >> > 1 network2 any[DISABLED] > >> > 2 network3 any[DISABLED] > >> > 3 network4 any[DISABLED] > >> > 4 network5 any[DISABLED] > >> > Selected interface 'wlan0' > >> > > >> > > >> > I address this by doing network_enable x in wpa_cli and it all > >comes > >> > back. I asked Adrian about this in the past, but it needs some > >> > debugging > >> &
Re: wlan can't discover known networks after relocating
Roaming is done in wpa_supplicant when it's running.That's where the smarts need to be. :( -adrian On Thu, 19 Sep 2019 at 05:44, Bjoern A. Zeeb wrote: > On 19 Sep 2019, at 12:28, Tom Jones wrote: > > Hi, > > freebsd-wireless might be a better list for all this .. > > > > On Tue, Sep 17, 2019 at 04:36:28PM +, Poul-Henning Kamp wrote: > >> > >> In message <707bcd3f-fa6b-82eb-fa8f-09c4b800f...@freebsd.org>, > >> Johannes Lundber > >> g writes: > >> > >>> For a long time now I have had this problem with iwm and wlan0. > >>> Whenever > >>> I move between work and home it won't reconnect automatically and I > >>> have > >>> to do wlan0 scan manually for it to pick up the different network. > >> > >> I suffer from the dreaded "reason=0" when I move inside my house: > >> > >> > scan > >> OK > >> <3>CTRL-EVENT-SCAN-RESULTS > >> <3>Trying to associate with 6c:3b:6b:3d:a2:e9 (SSID='Palombia' > >> freq=2452 MHz) > >> <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:3d:a2:e9 reason=0 > >> <3>CTRL-EVENT-SCAN-RESULTS > >> <3>Trying to associate with 6c:3b:6b:ab:ce:d4 (SSID='Palombia' > >> freq=2412 MHz) > >> <3>Associated with 6c:3b:6b:ab:ce:d4 > >> > >> a2:e9 is the loudest AP here in my office, but my I have been in the > >> other end of the house iwn consistently fails to associate with it > >> and > >> and keeps picking the weaker AP in the far end. > >> > >> Eventually (hours!) it disconnects from the weaker ap, also with > >> "reason=0" and gets it right: > >> > >> <3>WPA: Group rekeying completed with 6c:3b:6b:ab:ce:d4 [GTK=CCMP] > >> <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:ab:ce:d4 reason=0 > >> <3>CTRL-EVENT-SCAN-RESULTS > >> <3>Trying to associate with 6c:3b:6b:3d:a2:e9 (SSID='Palombia' > >> freq=2452 MHz) > >> <3>Associated with 6c:3b:6b:3d:a2:e9 > >> <3>WPA: Key negotiation completed with 6c:3b:6b:3d:a2:e9 [PTK=CCMP > >> GTK=CCMP] > >> <3>CTRL-EVENT-CONNECTED - Connection to 6c:3b:6b:3d:a2:e9 > completed > >> [id=3 id_str=] > >> <3>WPA: Group rekeying completed with 6c:3b:6b:3d:a2:e9 [GTK=CCMP] > >> > >> And yes, working roaming would be nice too... > > > > I have the problem that when roaming networks become disabled > > > > $ wpa_cli > > Selected interface 'wlan0' > > > > Interactive mode > > > > > list_networks > > network id / ssid / bssid / flags > > 0 network1any [CURRENT] > > 1 network2 any[DISABLED] > > 2 network3 any[DISABLED] > > 3 network4 any[DISABLED] > > 4 network5 any[DISABLED] > > Selected interface 'wlan0' > > > > > > I address this by doing network_enable x in wpa_cli and it all comes > > back. I asked Adrian about this in the past, but it needs some > > debugging > > to pin down. > > > Is this iwm(4) as well in your case or another card? > > /bz > ___ > 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: ath10k driver status?
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?
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 > dev.ath.0.sta
Re: ath(4) issues?
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.5
Re: numa involved in instability and swap usage despite RAM free?
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
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
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
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
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
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
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
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
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
[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
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 wrote: > On Mon, Oct 16, 2017 at 8:55 AM, Adrian Chadd > 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 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. >> > > > > 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
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?
I'm sure stas can figure it out! -a On 25 June 2017 at 22:44, Thomas Mueller 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?
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
hi! Thanks! Yes please let's update the handbook at least. -a On 23 June 2017 at 10:06, Renato Botelho 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
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
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
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
On 17 May 2017 at 23:37, Warner Losh wrote: > On Wed, May 17, 2017 at 11:53 PM, Baptiste Daroussin 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
https://reviews.freebsd.org/D10778 -a On 17 May 2017 at 17:46, Adrian Chadd 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
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
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?
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 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
> 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
>> 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)
>>> wrote:
>>>>
>>>>
>>>> > On Apr 5, 2017, at 10:39, Adrian Chadd 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
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?
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 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 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 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 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 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 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?
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 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 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 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 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?
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 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 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?
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
WITHOUT_CLANG fixed it for me. Thanks. -adrian On 20 March 2017 at 11:23, Ed Maste wrote: > On 19 March 2017 at 03:00, Adrian Chadd 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
===> 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 [32],
llvm::SmallDenseMap::LargeRep, char, char, char,
char, char, char, char, char>'
/usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Support/AlignOf.h:138:8:
required from 'struct
llvm::AlignedCharArrayUnion [32],
llvm::SmallDenseMap::LargeRep, char, char, char,
char, char, char, char, char>'
/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: constructor required before non-static data member for
Re: panic: invalid bcd xxx
On 2 March 2017 at 01:31, Matthias Apitz wrote: > On Thursday, 2 March 2017 00:37:35 CET, Michael Gmelin > wrote: >> >> >> >>> On 2 Mar 2017, at 00:35, Adrian Chadd 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
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?
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
ok, lemme do a build and if it succeeds i'll commit it -a On 16 February 2017 at 06:39, Johannes Lundberg wrote: > My emacs remove trailing white spaces automatically on save. > > On Wed, Feb 15, 2017 at 22:59 Adrian Chadd wrote: >> >> 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: asmc driver patch merge request
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
hi! Well, give it a go. I can only be supportive. :) -a On 24 January 2017 at 10:31, Anindya Mukherjee 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 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
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
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
heh. As always, patches gratefully accepted. :) -adrian On 14 January 2017 at 21:07, Ernie Luzar 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 wrote: >>> >>> On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd >>> 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 >>>> 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
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 wrote: > On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd > 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 >> 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
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
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
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
*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
On 19 December 2016 at 16:04, Jordan Hubbard wrote: > > On Dec 19, 2016, at 12:27 PM, Adrian Chadd 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
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() ?
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
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
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
On 26 November 2016 at 13:59, Slawa Olhovchenkov 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
ok, hm. then i don' know offhand, not without putting in printf debugging. :) -a On 26 November 2016 at 13:51, Slawa Olhovchenkov 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 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
Ok. So boot verbose and let's see what it says. -adrian On 26 November 2016 at 10:39, Slawa Olhovchenkov 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
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 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 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
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?
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
+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
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
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
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 >> >> >> >> > testing >> >> >> >> > with the last). >> >> >> >> > 3) (incomplete) power management support fo
Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing
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?
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
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
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
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
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)
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
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
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
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
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 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 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
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
+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 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
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
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 Corporation' >> device = 'Sunrise Point-H PCI Express Root Port' >> class = bridge >> subclass = PCI-PCI >> isab0@pci0:0:31:0: class=0x060100 card=0x07061028 chip=0xa14e8086 >> rev=0x31 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Sunrise Point-H LPC Controller' >> class = bridge >> subclass = PC
Re: (boost::)asio and kqueue problem
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 == &soread_filtops &&
> + (so->so_options & SO_ACCEPTCONN))
> + kn->kn_fop = &solisten_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
Hi, Just try disabling the others and see what happens. Thanks! -a On 15 July 2016 at 13:28, Wolfgang Zenker wrote: > * Adrian Chadd [160715 00:00]: >> On 14 July 2016 at 14:37, Wolfgang Zenker wrote: >>> * Adrian Chadd [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&r2=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"
