Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

[Hans Ottevanger]

On 05/30/18 17:50, Glen Barber wrote:

Hi,

Could folks please help boot-test the most recent 12.0-CURRENT amd64
memstick images on various hardware?  Note, this is not a request to
install 12.0-CURRENT, only a boot-test with various system knobs
tweaked.

The most recent images are available at:
https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img
https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img

We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we
would like to get this included in the upcoming 11.2-RELEASE if the
change that had been committed addresses several boot issues reported
recently.

Please help test, and report back (both successes and failures).



Hi,

I tried to boot the memstick.img on the following two systems (both 
fairly ancient and just having a BIOS):


ASUS N4L-VM DH, CPU T7400 @2.16GHz
Intel  DP965LT, CPU Q6600 @2.40GHz

Both booted perfectly.

With FreeBSD 11.1 the latter system needed a freshly written USB stick 
to be treated with "gpart recover da0 && gpart set -a active da0" before 
it would boot, so this is certainly an improvement.


Kind regards,

Hans Ottevanger

www.beastielabs.net
___
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: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

[Idwer Vollering]

2018-06-03 7:23 GMT+02:00 Albert :
> Hi,
>
>
> I successfully tested the memstick.img on:
> Acer Chromebook 14 (EDGAR) [CB3-431-C5EX]
>
> The Results:
> UEFI (Coreboot) works perfectly, no issues there.
> BIOS (SeaBIOS) does *NOT* work. It puts the machine into a bootloop until
> the install medium is disconnected. It does, however, make it past the
> FreeBSD boot loader on the first try.

That's odd, which version of SeaBIOS are you using? did you had to run
'gpart recover '?

CFT report: I'm able to boot
FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img using
coreboot with SeaBIOS 1.11.1 just fine.

>
>
>
>
> ___
> 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: ``make buildkernel'' fails when /usr/obj is empty

[Matt Smith]

On May 31 22:50, Konstantin Belousov wrote:

On Thu, May 31, 2018 at 08:19:20PM +0200, Dimitry Andric wrote:

On 31 May 2018, at 20:11, Warner Losh  wrote:
>
> On Thu, May 31, 2018 at 11:47 AM, Dimitry Andric  wrote:
> On 31 May 2018, at 18:04, Benjamin Kaduk  wrote:
> > On Thu, May 31, 2018 at 09:58:50AM +0200, Gary Jennejohn wrote:
> >> On Thu, 31 May 2018 09:52:22 +0200
> >> Gary Jennejohn  wrote:
...
> > Whatever happened to the "run buildworld or kernel-toolchain before
> > buildkernel" requirement?
>
> That is still a requirement, yes.  Otherwise, you might have outdated
> toolchain components are in your /usr/obj.
>
> Usually you can get away without doing that, and now that clang is the 
toolchain that's rebuilt (and that's not fast) people try to get away with it more 
and more...

Actually clang doesn't get updated *that* often, but there is a minor
snag that one of llvm's config files (lib/clang/include/llvm/Config/config.h)
includes , so each time __FreeBSD_version is bumped, quite
a lot of dependencies get triggered...

The version is only used for two checks:

#if __FreeBSD_version >= 152
/* Define to 1 if you have the `backtrace' function. */
#define HAVE_BACKTRACE TRUE

and:

/* Define to 1 if you have the `futimens' function. */
#if __FreeBSD_version >= 1100056
#define HAVE_FUTIMENS 1
#endif

Maybe the first check could be dropped, assuming that backtrace() is
always available, but I'm not sure about futimens().  Is there any
supported version of FreeBSD left that does *not* have it?

Or you can manually define the symbols as needed on each branch,
eliminating the need for osreldate.h and reusable if some other
configuration variable needs to be conditionally set.


Are these the kind of things that could get done in current and stable?  
Currently llvm/clang is rebuilt on pretty much every buildworld cycle 
that I do because of this which makes using things like WITH_META_MODE 
pretty pointless.


It would be great to get this kind of change in the trees.

--
Matt
___
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"

Error build nvidia-driver with r334555

[Alex V. Petrov]

cc  -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"390.59\"
-D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2
-fno-strict-aliasing -mno-red-zone -mcmodel=kernel -Wno-sign-co
mpare -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG -Werror=undef
-Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I. -I../common/inc -I.
-I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-
common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   -MD
-MF.depend.nvlink_freebsd.o -MTnvlink_freebsd.o -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchr
onous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointe
r-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equ
ality -Wno-error-unused-function -Wno-error-pointer-sign
-Wno-error-shift-negative-value -Wno-address-of-packed-member  -mno-aes
-mno-avx  -std=iso9899:1999 -c nvlink_freebsd.c -o nvlink_fre
ebsd.o


--- nvidia_subr.o ---


nvidia_subr.c:367:26: error: 'memset' call operates on objects of type
'struct nv_ioctl_card_info' while the size is based on a different type
'struct nv_ioctl_card_info *' [-Werror,-Wsizeof
-pointer-memaccess]
memset(ci, 0, sizeof(ci));
   ~~^~
nvidia_subr.c:367:26: note: did you mean to dereference the argument to
'sizeof' (and multiply it by the number of elements)?

memset(ci, 0, sizeof(ci));
 ^~
1 error generated.
*** [nvidia_subr.o] Error code 1

make[4]: stopped in
/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.59/src/nvidia
1 error

make[4]: stopped in
/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.59/src/nvidia
*** [all_subdir_src/nvidia] Error code 2

make[3]: stopped in
/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.59/src
1 error

make[3]: stopped in
/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.59/src
*** [all_subdir_src] Error code 2

make[2]: stopped in
/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.59
1 error

make[2]: stopped in
/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.59
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

-- 
-
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: Error build nvidia-driver with r334555

[David Wolfskill]

On Sun, Jun 03, 2018 at 06:48:01PM +0700, Alex V. Petrov wrote:
> 
> --- nvidia_subr.o ---
> 
> 
> nvidia_subr.c:367:26: error: 'memset' call operates on objects of type
> 'struct nv_ioctl_card_info' while the size is based on a different type
> 'struct nv_ioctl_card_info *' [-Werror,-Wsizeof
> -pointer-memaccess]
> memset(ci, 0, sizeof(ci));
>~~^~
> nvidia_subr.c:367:26: note: did you mean to dereference the argument to
> 'sizeof' (and multiply it by the number of elements)?
> 
> memset(ci, 0, sizeof(ci));
>  ^~
> 1 error generated.
> *** [nvidia_subr.o] Error code 1
> 

Aye; please ref.
 for
additional details.

The issue has been narrowed down to the range r334529 - r334535; I'm
suspecting r334533 and/or r334534.  (Not that the commits are in any way
"faulty" -- merely that the nvidia-driver port may need some "evasive
action" to allow for the change).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Mr. Trump, you reap what you sow:  This is YOUR trade war.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Error build nvidia-driver with r334555

[Konstantin Belousov]

On Sun, Jun 03, 2018 at 05:08:34AM -0700, David Wolfskill wrote:
> On Sun, Jun 03, 2018 at 06:48:01PM +0700, Alex V. Petrov wrote:
> > 
> > --- nvidia_subr.o ---
> > 
> > 
> > nvidia_subr.c:367:26: error: 'memset' call operates on objects of type
> > 'struct nv_ioctl_card_info' while the size is based on a different type
> > 'struct nv_ioctl_card_info *' [-Werror,-Wsizeof
> > -pointer-memaccess]
> > memset(ci, 0, sizeof(ci));
> >~~^~
> > nvidia_subr.c:367:26: note: did you mean to dereference the argument to
> > 'sizeof' (and multiply it by the number of elements)?
> > 
> > memset(ci, 0, sizeof(ci));
> >  ^~
> > 1 error generated.
> > *** [nvidia_subr.o] Error code 1
> > 
> 
> Aye; please ref.
>  for
> additional details.
> 
> The issue has been narrowed down to the range r334529 - r334535; I'm
> suspecting r334533 and/or r334534.  (Not that the commits are in any way
> "faulty" -- merely that the nvidia-driver port may need some "evasive
> action" to allow for the change).

Even not looking at the actual code, I am quite sure that the line
nvidia_subr.c:367 should be changed to
memset(ci, 0, sizeof(*ci));
This is a bug in the driver sources.
___
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: Error build nvidia-driver with r334555

[Waitman Gobble]

​
‐‐‐ Original Message ‐‐‐

On June 3, 2018 8:21 AM, Konstantin Belousov  wrote:

> On Sun, Jun 03, 2018 at 05:08:34AM -0700, David Wolfskill wrote:
> 
> > On Sun, Jun 03, 2018 at 06:48:01PM +0700, Alex V. Petrov wrote:
> > 
> > > 
> > > 
> > > --- nvidia_subr.o ---
> > > 
> > > nvidia_subr.c:367:26: error: 'memset' call operates on objects of type
> > > 
> > > 'struct nv_ioctl_card_info' while the size is based on a different type
> > > 
> > > 'struct nv_ioctl_card_info *' [-Werror,-Wsizeof
> > > 
> > > -pointer-memaccess]
> > > 
> > > memset(ci, 0, sizeof(ci));
> > > 
> > > ~~ ^~
> > > 
> > > nvidia_subr.c:367:26: note: did you mean to dereference the argument to
> > > 
> > > 'sizeof' (and multiply it by the number of elements)?
> > > 
> > > memset(ci, 0, sizeof(ci));
> > >  ^~
> > > 
> > > 
> > > 1 error generated.
> > > 
> > > *** [nvidia_subr.o] Error code 1
> > > 
> > > 
> > 
> > Aye; please ref.
> > 
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228709 for
> > 
> > additional details.
> > 
> > The issue has been narrowed down to the range r334529 - r334535; I'm
> > 
> > suspecting r334533 and/or r334534. (Not that the commits are in any way
> > 
> > "faulty" -- merely that the nvidia-driver port may need some "evasive
> > 
> > action" to allow for the change).
> 
> Even not looking at the actual code, I am quite sure that the line
> 
> nvidia_subr.c:367 should be changed to
> 
> memset(ci, 0, sizeof(*ci));
> 
> This is a bug in the driver sources.
> 
> 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"



That solved the build problem for me. 
I haven't noticed any other issues with nvidia driver.


Waitman Gobble

Sent with ProtonMail Secure Email.​


___
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: Error build nvidia-driver with r334555

[Tomoaki AOKI]

This is caused by r334533 and/or r334534 (memset-related changes).
sysutils/lsof is also affected.

You should revert r334533 and r334534 temporarily until nvidia-driver
support this change.

CC'ing the revision author and maintainers of both ports.


On Sun, 3 Jun 2018 18:48:01 +0700
"Alex V. Petrov"  wrote:

> cc  -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"390.59\"
> -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2
> -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -Wno-sign-co
> mpare -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG -Werror=undef
> -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I. -I../common/inc -I.
> -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-
> common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   -MD
> -MF.depend.nvlink_freebsd.o -MTnvlink_freebsd.o -mcmodel=kernel
> -mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchr
> onous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointe
> r-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
> -fdiagnostics-show-option -Wno-unknown-pragmas
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equ
> ality -Wno-error-unused-function -Wno-error-pointer-sign
> -Wno-error-shift-negative-value -Wno-address-of-packed-member  -mno-aes
> -mno-avx  -std=iso9899:1999 -c nvlink_freebsd.c -o nvlink_fre
> ebsd.o
> 
> 
> --- nvidia_subr.o ---
> 
> 
> nvidia_subr.c:367:26: error: 'memset' call operates on objects of type
> 'struct nv_ioctl_card_info' while the size is based on a different type
> 'struct nv_ioctl_card_info *' [-Werror,-Wsizeof
> -pointer-memaccess]
> memset(ci, 0, sizeof(ci));
>~~^~
> nvidia_subr.c:367:26: note: did you mean to dereference the argument to
> 'sizeof' (and multiply it by the number of elements)?
> 
> memset(ci, 0, sizeof(ci));
>  ^~
> 1 error generated.
> *** [nvidia_subr.o] Error code 1
> 
> make[4]: stopped in
> /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.59/src/nvidia
> 1 error
> 
> make[4]: stopped in
> /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.59/src/nvidia
> *** [all_subdir_src/nvidia] Error code 2
> 
> make[3]: stopped in
> /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.59/src
> 1 error
> 
> make[3]: stopped in
> /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.59/src
> *** [all_subdir_src] Error code 2
> 
> make[2]: stopped in
> /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.59
> 1 error
> 
> make[2]: stopped in
> /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.59
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
> 
> -- 
> -
> 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"
> 


-- 
Tomoaki AOKI
___
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"

Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

Hi,

After upgrading CURRENT to r333992 (from something at least a year
old, quite some changes in mp_machdep.c since), this machine crashes
on boot:

Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #1 r333992: Tue May 22 00:31:04 CEST 2018
root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
6.0.0)
WARNING: WITNESS option enabled, expect reduced performance.
VT(vga): resolution 640x480
CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45  Stepping=1
  Features=0xbfebfbff
  
Features2=0x4ddaebbf
  AMD Features=0x2c100800
  AMD Features2=0x21
  Structured Extended Features=0x2603
  XSAVE Features=0x1
  VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 4301258752 (4102 MB)
avail memory = 1907572736 (1819 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
kernel trap 12 with interrupts disabled

Fatal trap 12: page fault while in kernel mode 
cpuid = 0; apic id = 00
fault virtual address= 0xf8000100
fault code   = supervisor write data, protection violation
instruction pointer  = 0x20:Ox8102955f
stack pointer= 0x28:0x82a79be0
frame pointer= 0x28:0x82a79c10
code segment = base Ox0, limit Oxf, type Ox1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process  = 0 ()
[ thread pid 0 tid 0 ]
Stopped at  native_start_all_aps+0x08f:  movq %rax,(%rsi)
db>

Any key press in the debugger will reboot the machine.

Booting with kern.smp.disabled=1 works.

Any ideas?

-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"

Re: Error build nvidia-driver with r334555

[Mateusz Guzik]

On Sun, Jun 3, 2018 at 2:42 PM, Tomoaki AOKI 
wrote:

> This is caused by r334533 and/or r334534 (memset-related changes).
> sysutils/lsof is also affected.
>
> You should revert r334533 and r334534 temporarily until nvidia-driver
> support this change.
>
> CC'ing the revision author and maintainers of both ports.
>
>
Support in what sense? The error message clearly indicates a bug in the
driver
(also trivially fixable). Is there a problem adding a patch to files/?

diff -ru src.orig/nvidia/nvidia_subr.c src/nvidia/nvidia_subr.c
--- src.orig/nvidia/nvidia_subr.c2018-06-03 13:19:56.49048 +
+++ src/nvidia/nvidia_subr.c2018-06-03 13:21:15.289344000 +
@@ -364,7 +364,7 @@
 }

 ci = args;
-memset(ci, 0, sizeof(ci));
+memset(ci, 0, sizeof(*ci));

 for (i = 0; i < NV_MAX_DEVICES; i++) {
 sc = devclass_get_softc(nvidia_devclass, i);


As for lsof:
--- dlsof.h.orig2018-06-03 13:16:14.712701000 +
+++ dlsof.h2018-06-03 13:17:15.042655000 +
@@ -489,6 +489,12 @@
 # endif/* FREEBSDV>=2020 */

 #undefbzero/* avoid _KERNEL conflict */
+#undefbcmp
+#undefbcopy
+#undefmemcmp
+#undefmemmove
+#undefmemcpy
+#undefmemset
 #include 

-- 
Mateusz Guzik 
___
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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Konstantin Belousov]

On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:
> Hi,
> 
> After upgrading CURRENT to r333992 (from something at least a year
> old, quite some changes in mp_machdep.c since), this machine crashes
> on boot:
> 
> Copyright (c) 1992-2018 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>   The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT #1 r333992: Tue May 22 00:31:04 CEST 2018
> root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
> 6.0.0)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(vga): resolution 640x480
> CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45  Stepping=1
>   
> Features=0xbfebfbff CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>   
> Features2=0x4ddaebbf xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
>   AMD Features=0x2c100800
>   AMD Features2=0x21
>   Structured Extended Features=0x2603
>   XSAVE Features=0x1
>   VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 4301258752 (4102 MB)
> avail memory = 1907572736 (1819 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
What does this mean ?  Did you flashed coreboot ?

> kernel trap 12 with interrupts disabled
> 
> Fatal trap 12: page fault while in kernel mode 
> cpuid = 0; apic id = 00
> fault virtual address= 0xf8000100
> fault code   = supervisor write data, protection violation
> instruction pointer  = 0x20:Ox8102955f
> stack pointer= 0x28:0x82a79be0
> frame pointer= 0x28:0x82a79c10
> code segment = base Ox0, limit Oxf, type Ox1b
>  = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = resume, IOPL = 0
> current process  = 0 ()
> [ thread pid 0 tid 0 ]
> Stopped at  native_start_all_aps+0x08f:  movq %rax,(%rsi)
Look up the source line number for this address.

> db>
> 
> Any key press in the debugger will reboot the machine.
> 
> Booting with kern.smp.disabled=1 works.
> 
> Any ideas?
> 
> -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: Error build nvidia-driver with r334555

[Larry Rosenman]

sysutils/lsof fixed in r471495.

 

Thanks, Mateusz!

-- 

Larry Rosenman http://www.lerctr.org/~ler

Phone: +1 214-642-9640 E-Mail: l...@lerctr.org

US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106

 

From: Mateusz Guzik 
Date: Sunday, June 3, 2018 at 8:20 AM
To: 
Cc: "freebsd-current@freebsd.org" , 
, Mateusz Guzik , Alexey Dokuchaev 
, 
Subject: Re: Error build nvidia-driver with r334555

 

On Sun, Jun 3, 2018 at 2:42 PM, Tomoaki AOKI  wrote:

This is caused by r334533 and/or r334534 (memset-related changes).
sysutils/lsof is also affected.

You should revert r334533 and r334534 temporarily until nvidia-driver
support this change.

CC'ing the revision author and maintainers of both ports.

 

 

Support in what sense? The error message clearly indicates a bug in the driver

(also trivially fixable). Is there a problem adding a patch to files/?

diff -ru src.orig/nvidia/nvidia_subr.c src/nvidia/nvidia_subr.c
--- src.orig/nvidia/nvidia_subr.c2018-06-03 13:19:56.49048 +
+++ src/nvidia/nvidia_subr.c2018-06-03 13:21:15.289344000 +
@@ -364,7 +364,7 @@
 }
 
 ci = args;
-memset(ci, 0, sizeof(ci));
+memset(ci, 0, sizeof(*ci));
 
 for (i = 0; i < NV_MAX_DEVICES; i++) {
 sc = devclass_get_softc(nvidia_devclass, i);

As for lsof:
--- dlsof.h.orig2018-06-03 13:16:14.712701000 +
+++ dlsof.h2018-06-03 13:17:15.042655000 +
@@ -489,6 +489,12 @@
 # endif/* FREEBSDV>=2020 */
 
 #undefbzero/* avoid _KERNEL conflict */
+#undefbcmp
+#undefbcopy
+#undefmemcmp
+#undefmemmove
+#undefmemcpy
+#undefmemset
 #include 

-- 

Mateusz Guzik 

___
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: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

[Albert Gem]

SeaBIOS 1.10.2

Upgrading seems to do the trick

> Am 03.06.2018 um 06:25 schrieb Idwer Vollering :
> 
> 2018-06-03 7:23 GMT+02:00 Albert :
>> Hi,
>> 
>> 
>> I successfully tested the memstick.img on:
>> Acer Chromebook 14 (EDGAR) [CB3-431-C5EX]
>> 
>> The Results:
>> UEFI (Coreboot) works perfectly, no issues there.
>> BIOS (SeaBIOS) does *NOT* work. It puts the machine into a bootloop until
>> the install medium is disconnected. It does, however, make it past the
>> FreeBSD boot loader on the first try.
> 
> That's odd, which version of SeaBIOS are you using? did you had to run
> 'gpart recover '?
> 
> CFT report: I'm able to boot
> FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img using
> coreboot with SeaBIOS 1.11.1 just fine.
> 
>> 
>> 
>> 
>> 
>> ___
>> 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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

On Sun, 3 Jun 2018 16:21:10 +0300
Konstantin Belousov  wrote:

> On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:
> > Hi,
> > 
> > After upgrading CURRENT to r333992 (from something at least a year
> > old, quite some changes in mp_machdep.c since), this machine crashes
> > on boot:
> > 
> > Copyright (c) 1992-2018 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> > 1994 The Regents of the University of California. All rights
> > reserved. FreeBSD is a registered trademark of The FreeBSD
> > Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue May 22 00:31:04
> > CEST 2018 root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based
> > on LLVM 6.0.0) WARNING: WITNESS option enabled, expect reduced
> > performance. VT(vga): resolution 640x480
> > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> >   Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45
> > Stepping=1
> > Features=0xbfebfbff > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > Features2=0x4ddaebbf > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > AMD Features=0x2c100800 AMD
> > Features2=0x21 Structured Extended
> > Features=0x2603 XSAVE
> > Features=0x1 VT-x: (disabled in BIOS)
> > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance
> > statistics real memory  = 4301258752 (4102 MB)
> > avail memory = 1907572736 (1819 MB)
> > Event timer "LAPIC" quality 600
> > ACPI APIC Table:   
> What does this mean ?  Did you flashed coreboot ?

This machine comes with it by default (my model was delivered with 
SeaBIOS 20131018_145217-build121-m2). So I didn't flash anything
(didn't feel like bricking it).

> 
> > kernel trap 12 with interrupts disabled
> > 
> > Fatal trap 12: page fault while in kernel mode 
> > cpuid = 0; apic id = 00
> > fault virtual address= 0xf8000100
> > fault code   = supervisor write data, protection
> > violation instruction pointer  = 0x20:Ox8102955f
> > stack pointer= 0x28:0x82a79be0
> > frame pointer= 0x28:0x82a79c10
> > code segment = base Ox0, limit Oxf, type Ox1b
> >  = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags = resume, IOPL = 0
> > current process  = 0 ()
> > [ thread pid 0 tid 0 ]
> > Stopped at  native_start_all_aps+0x08f:  movq
> > %rax,(%rsi)  
> Look up the source line number for this address.
> 

I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr), called by
native_start_all_aps. Any additional hints how I can track it down?

Thanks,
Michael

> > db>  
> > 
> > Any key press in the debugger will reboot the machine.
> > 
> > Booting with kern.smp.disabled=1 works.
> > 
> > Any ideas?
> > 
> > -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"



-- 
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"

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Konstantin Belousov]

On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:
> 
> 
> On Sun, 3 Jun 2018 16:21:10 +0300
> Konstantin Belousov  wrote:
> 
> > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:
> > > Hi,
> > > 
> > > After upgrading CURRENT to r333992 (from something at least a year
> > > old, quite some changes in mp_machdep.c since), this machine crashes
> > > on boot:
> > > 
> > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> > > 1994 The Regents of the University of California. All rights
> > > reserved. FreeBSD is a registered trademark of The FreeBSD
> > > Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue May 22 00:31:04
> > > CEST 2018 root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based
> > > on LLVM 6.0.0) WARNING: WITNESS option enabled, expect reduced
> > > performance. VT(vga): resolution 640x480
> > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > >   Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45
> > > Stepping=1
> > > Features=0xbfebfbff > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > Features2=0x4ddaebbf > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > AMD Features=0x2c100800 AMD
> > > Features2=0x21 Structured Extended
> > > Features=0x2603 XSAVE
> > > Features=0x1 VT-x: (disabled in BIOS)
> > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance
> > > statistics real memory  = 4301258752 (4102 MB)
> > > avail memory = 1907572736 (1819 MB)
> > > Event timer "LAPIC" quality 600
> > > ACPI APIC Table:   
> > What does this mean ?  Did you flashed coreboot ?
> 
> This machine comes with it by default (my model was delivered with 
> SeaBIOS 20131018_145217-build121-m2). So I didn't flash anything
> (didn't feel like bricking it).
> 
> > 
> > > kernel trap 12 with interrupts disabled
> > > 
> > > Fatal trap 12: page fault while in kernel mode 
> > > cpuid = 0; apic id = 00
> > > fault virtual address= 0xf8000100
> > > fault code   = supervisor write data, protection
> > > violation instruction pointer  = 0x20:Ox8102955f
> > > stack pointer= 0x28:0x82a79be0
> > > frame pointer= 0x28:0x82a79c10
> > > code segment = base Ox0, limit Oxf, type Ox1b
> > >  = DPL 0, pres 1, long 1, def32 0, gran 1
> > > processor eflags = resume, IOPL = 0
> > > current process  = 0 ()
> > > [ thread pid 0 tid 0 ]
> > > Stopped at  native_start_all_aps+0x08f:  movq
> > > %rax,(%rsi)  
> > Look up the source line number for this address.
> > 
> 
> I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr), called by
> native_start_all_aps. Any additional hints how I can track it down?
Why did you decided that this is rdmsr_safe() ? First,
native_start_all_aps() does not call rdmsr, second the ddb
report clearly indicates that the fault occured acessing DMAP in
native_start_all_aps().

Just look up the source line by the address native_start_all_aps+0x08f.
___
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 buildkernel'' fails when /usr/obj is empty

[Eitan Adler]

On 31 May 2018 at 11:19, Dimitry Andric  wrote:
> On 31 May 2018, at 20:11, Warner Losh  wrote:
>>
>> On Thu, May 31, 2018 at 11:47 AM, Dimitry Andric  wrote:
>> On 31 May 2018, at 18:04, Benjamin Kaduk  wrote:
>> > On Thu, May 31, 2018 at 09:58:50AM +0200, Gary Jennejohn wrote:
>> >> On Thu, 31 May 2018 09:52:22 +0200
>> >> Gary Jennejohn  wrote:
> ...
>> > Whatever happened to the "run buildworld or kernel-toolchain before
>> > buildkernel" requirement?
>>
>> That is still a requirement, yes.  Otherwise, you might have outdated
>> toolchain components are in your /usr/obj.
>>
>> Usually you can get away without doing that, and now that clang is the 
>> toolchain that's rebuilt (and that's not fast) people try to get away with 
>> it more and more...
>
> Actually clang doesn't get updated *that* often, but there is a minor
> snag that one of llvm's config files (lib/clang/include/llvm/Config/config.h)
> includes , so each time __FreeBSD_version is bumped, quite
> a lot of dependencies get triggered...
>
> The version is only used for two checks:
>
> #if __FreeBSD_version >= 152
> /* Define to 1 if you have the `backtrace' function. */
> #define HAVE_BACKTRACE TRUE
>
> and:
>
> /* Define to 1 if you have the `futimens' function. */
> #if __FreeBSD_version >= 1100056
> #define HAVE_FUTIMENS 1
> #endif
>
> Maybe the first check could be dropped, assuming that backtrace() is
> always available, but I'm not sure about futimens().  Is there any
> supported version of FreeBSD left that does *not* have it?

10.4 is supported until October 31, 2018 but it might be worth making
the change in -current  ?






-- 
Eitan Adler
___
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

[Dhananjay Balan]

On Sat, Jun 02, 2018 at 12:37:12AM +0200, Christoph Moench-Tegeder wrote:
> Did you try adding "mode 11a" to select 5GHz band? (This might be
> out-of-date, as my WiFi stuff is all on 11) (currently I'm also
> using 2.4GHz only, for compatibility with some devices and the fact
> that I have quite some trouble running 2.4GHz and 5GHz from the same
> interface at the same time).

I did a bit more testing, I have to admit that I am not well versed in wifi 
internals.

1. ifconfig wlan0 list aps shows my aps having rate 54M (Im not entirely sure 
what this means).
   But however when I connect to it, it shows up as 11g

wlan0: flags=8843 metric 0 mtu 1500
ether a4:4e:31:02:70:3c
inet 192.168.23.111 netmask 0xff00 broadcast 192.168.23.255
nd6 options=29
media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
status: associated
ssid LA03 channel 6 (2437 MHz 11g ht/20) bssid 52:d9:e7:47:c0:c2
regdomain FCC4 country DE authmode WPA2/802.11i privacy ON
deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid 60
protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi
-stbc -ldpc wme roaming MANUAL
groups: wlan

2. Adding mode 11a to rc.conf didn't change anything. Still connects to 2.4Ghz 
band.

3. ifconfing wlan0 scan still doesn't show my 5Ghz only APs (at least some I 
tested)

Also, what does 11a mean? shouldn't it be 11n?
-
dbalan
___
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

[Adam]

On Sun, Jun 3, 2018 at 9:53 AM, Dhananjay Balan  wrote:

> On Sat, Jun 02, 2018 at 12:37:12AM +0200, Christoph Moench-Tegeder wrote:
> > Did you try adding "mode 11a" to select 5GHz band? (This might be
> > out-of-date, as my WiFi stuff is all on 11) (currently I'm also
> > using 2.4GHz only, for compatibility with some devices and the fact
> > that I have quite some trouble running 2.4GHz and 5GHz from the same
> > interface at the same time).
>
> I did a bit more testing, I have to admit that I am not well versed in
> wifi internals.
>
> 1. ifconfig wlan0 list aps shows my aps having rate 54M (Im not entirely
> sure what this means).
>But however when I connect to it, it shows up as 11g
>
> wlan0: flags=8843 metric 0 mtu
> 1500
> ether a4:4e:31:02:70:3c
> inet 192.168.23.111 netmask 0xff00 broadcast 192.168.23.255
> nd6 options=29
> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
> status: associated
> ssid LA03 channel 6 (2437 MHz 11g ht/20) bssid 52:d9:e7:47:c0:c2
> regdomain FCC4 country DE authmode WPA2/802.11i privacy ON
> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid 60
> protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi
> -stbc -ldpc wme roaming MANUAL
> groups: wlan
>

I do not believe the response you are replying to actually addressed 5gz
which is different than mode.  You may be able to achieve better speeds
using channel parameters.  man ifconfig.

A simple test is to have your AP present SSID of 2.4 and 5 as different
names.  If the 5 doesn't show in the above command, 5 isn't working.


> 2. Adding mode 11a to rc.conf didn't change anything. Still connects to
> 2.4Ghz band.
>

Yup


> 3. ifconfing wlan0 scan still doesn't show my 5Ghz only APs (at least some
> I tested)
>

I don't believe the iwn driver is capable of 5gz.  At least mine doesn't
work on CURRENT.


> Also, what does 11a mean? shouldn't it be 11n?
> -
> dbalan
> ___
> 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"
>



-- 
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"

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

[Christoph Moench-Tegeder]

## Dhananjay Balan (m...@dbalan.in):

> On Sat, Jun 02, 2018 at 12:37:12AM +0200, Christoph Moench-Tegeder wrote:
> > Did you try adding "mode 11a" to select 5GHz band? (This might be
> > out-of-date, as my WiFi stuff is all on 11) (currently I'm also
> > using 2.4GHz only, for compatibility with some devices and the fact
> > that I have quite some trouble running 2.4GHz and 5GHz from the same
> > interface at the same time).
> 
> I did a bit more testing, I have to admit that I am not well versed in
> wifi internals.

Here's the non-technical overview: https://en.wikipedia.org/wiki/IEEE_802.11
(The real details can be really gory, but this should be good enough).

> 1. ifconfig wlan0 list aps shows my aps having rate 54M (Im not entirely
>sure what this means).
>But however when I connect to it, it shows up as 11g

A data rate of 54 MBit/s would be perfectly in sync with 11g - 20MHz
channel width, OFDM modulation, 2.4 GHz. And we see that in this line:

> ssid LA03 channel 6 (2437 MHz 11g ht/20) bssid 52:d9:e7:47:c0:c2

And this shows that even MIMO ("Multiple Input, Multiple Output" has
been activated (that's the "n" in "11ng"):

> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng

The 5GHz part of 802.11 is 802.11a (and related, like ac), there's no
5GHz band in 11g.

I'm a little puzzled about this:
> regdomain FCC4 country DE authmode WPA2/802.11i privacy ON

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)

Regards,
Christoph

-- 
Spare Space.
___
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

[Christoph Moench-Tegeder]

## Adam (amvandem...@gmail.com):

> > 3. ifconfing wlan0 scan still doesn't show my 5Ghz only APs (at least some
> > I tested)
> 
> I don't believe the iwn driver is capable of 5gz.  At least mine doesn't
> work on CURRENT.

The iwn driver has code for 5GHz (I've no idea if that's complete).
But looking at that reminded me: there are many "iwn" devices, including
some having "BGN" appended to their names - I'd guess those devices
don't support 5GHz aka 11a mode.

Regards,
Christoph

-- 

___
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

[Cy Schubert]

In message <20180603174401.rbxa3fcnuopro...@squirrel.exwg.net>, 
Christoph Moenc
h-Tegeder writes:
> ## Adam (amvandem...@gmail.com):
>
> > > 3. ifconfing wlan0 scan still doesn't show my 5Ghz only APs (at least som
> e
> > > I tested)
> > 
> > I don't believe the iwn driver is capable of 5gz.  At least mine doesn't
> > work on CURRENT.
>
> The iwn driver has code for 5GHz (I've no idea if that's complete).
> But looking at that reminded me: there are many "iwn" devices, including
> some having "BGN" appended to their names - I'd guess those devices
> don't support 5GHz aka 11a mode.

My iwn device (iwn0: ) supports 5 GHz. 
I just disabled my 2.4 GHz APs and reassociated:

wlan0: flags=8843 metric 0 mtu 
1500
ether 
nd6 options=29
media: IEEE 802.11 Wireless Ethernet MCS mode 11na
status: associated
ssid -5G channel 153 (5765 MHz 11a ht/40-) bssid 
regdomain FCC country US authmode WPA2/802.11i privacy ON
deftxkey UNDEF AES-CCM 2:128-bit txpower 23 bmiss 120 mcastrate 6
mgmtrate 6 scanvalid 16959 ampdulimit 64k ampdudensity 8
-amsdutx amsdurx shortgi -stbc -ldpc wme roaming MANUAL
groups: wlan 

Some devices do and others don't. For example, I have an ath card for 
this same laptop (I swapped out my iwn card for an ath card for a short 
while) that supports station mode (BTW iwn firmware doesn't), 
discovering my ath device firmware does not support 5 GHz. I suspect 
that some iwn devices may be similarly "crippled", though the driver 
supports 5 GHz the firmware does not. My point is it's not a binary 
issue. You may need to Google your particular card to determine if the 
manufacturer has implemented the feature or not. I did for my ath card 
discovering not all implementations are equal. I wouldn't be surprised 
this might be true of iwn as well.



-- 
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"

SPDX-License-Id for new files

[Rick Macklem]

I have a few (3) new files in the projects/pnfs-planb-server subversion tree
that all have the 2 clause FreeBSD copyright.

Do I just add the "SPDX..." line for this license at the top of the copyright 
comment
or is there some other exercise needed to be done for this?

Thanks, rick
___
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: Deadlocks / hangs in ZFS

[Alexander Leidinger]

Quoting Alexander Leidinger  (from Mon, 28  
May 2018 09:02:01 +0200):


Quoting Slawa Olhovchenkov  (from Mon, 28 May 2018  
01:06:12 +0300):



On Sun, May 27, 2018 at 09:41:59PM +0200, Kirill Ponomarev wrote:


On 05/22, Slawa Olhovchenkov wrote:

> It has been a while since I tried Karl's patch the last time, and I
> stopped because it didn't apply to -current anymore at some point.
> Will what is provided right now in the patch work on -current?

I am mean yes, after s/vm_cnt.v_free_count/vm_free_count()/g
I am don't know how to have two distinct patch (for stable and  
current) in one review.


I'm experiencing these issues sporadically as well, would you mind
to publish this patch for fresh current?


Week ago I am adopt and publish patch to fresh current and stable, is
adopt need again?


I applied the patch in the review yesterday to rev 333966, it  
applied OK (with some fuzz). I will try to reproduce my issue with  
the patch.


The behavior changed (or the system was long enough in this state  
without me noticing it). I have a panic now:
panic: deadlkres: possible deadlock detected for 0xf803766db580,  
blocked for 1803003 ticks


I only have the textdump. Is nayone up to debug this? If yes, I switch  
to normal dumps, just tell me what I shall check for.


db:0:kdb.enter.panic>  run lockinfo
db:1:lockinfo> show locks
No such command; use "help" to list available commands
db:1:lockinfo>  show alllocks
No such command; use "help" to list available commands
db:1:lockinfo>  show lockedvnods
Locked vnodes
db:0:kdb.enter.panic>  show pcpu
cpuid= 6
dynamic pcpu = 0xfe008f03e840
curthread= 0xf80370c82000: pid 0 tid 100218 "deadlkres"
curpcb   = 0xfe0116472cc0
fpcurthread  = none
idlethread   = 0xf803700b9580: tid 18 "idle: cpu6"
curpmap  = 0x80d28448
tssp = 0x80d96d90
commontssp   = 0x80d96d90
rsp0 = 0xfe0116472cc0
gs32p= 0x80d9d9c8
ldt  = 0x80d9da08
tss  = 0x80d9d9f8
db:0:kdb.enter.panic>  bt
Tracing pid 0 tid 100218 td 0xf80370c82000
kdb_enter() at kdb_enter+0x3b/frame 0xfe0116472aa0
vpanic() at vpanic+0x1c0/frame 0xfe0116472b00
panic() at panic+0x43/frame 0xfe0116472b60
deadlkres() at deadlkres+0x3a6/frame 0xfe0116472bb0
fork_exit() at fork_exit+0x84/frame 0xfe0116472bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0116472bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpWdWfEqHP6I.pgp
Description: Digitale PGP-Signatur

Re: Deadlocks / hangs in ZFS

[Slawa Olhovchenkov]

On Sun, Jun 03, 2018 at 09:14:50PM +0200, Alexander Leidinger wrote:

> Quoting Alexander Leidinger  (from Mon, 28  
> May 2018 09:02:01 +0200):
> 
> > Quoting Slawa Olhovchenkov  (from Mon, 28 May 2018  
> > 01:06:12 +0300):
> >
> >> On Sun, May 27, 2018 at 09:41:59PM +0200, Kirill Ponomarev wrote:
> >>
> >>> On 05/22, Slawa Olhovchenkov wrote:
>  > It has been a while since I tried Karl's patch the last time, and I
>  > stopped because it didn't apply to -current anymore at some point.
>  > Will what is provided right now in the patch work on -current?
> 
>  I am mean yes, after s/vm_cnt.v_free_count/vm_free_count()/g
>  I am don't know how to have two distinct patch (for stable and  
>  current) in one review.
> >>>
> >>> I'm experiencing these issues sporadically as well, would you mind
> >>> to publish this patch for fresh current?
> >>
> >> Week ago I am adopt and publish patch to fresh current and stable, is
> >> adopt need again?
> >
> > I applied the patch in the review yesterday to rev 333966, it  
> > applied OK (with some fuzz). I will try to reproduce my issue with  
> > the patch.
> 
> The behavior changed (or the system was long enough in this state  
> without me noticing it). I have a panic now:
> panic: deadlkres: possible deadlock detected for 0xf803766db580,  
> blocked for 1803003 ticks

Hmm, may be first determinate locked function

addr2line -ie /boot/kernel/kernel 0xf803766db580

or

kgdb
x/10i 0xf803766db580


> I only have the textdump. Is nayone up to debug this? If yes, I switch  
> to normal dumps, just tell me what I shall check for.
> 
> db:0:kdb.enter.panic>  run lockinfo
> db:1:lockinfo> show locks
> No such command; use "help" to list available commands
> db:1:lockinfo>  show alllocks
> No such command; use "help" to list available commands
> db:1:lockinfo>  show lockedvnods
> Locked vnodes
> db:0:kdb.enter.panic>  show pcpu
> cpuid= 6
> dynamic pcpu = 0xfe008f03e840
> curthread= 0xf80370c82000: pid 0 tid 100218 "deadlkres"
> curpcb   = 0xfe0116472cc0
> fpcurthread  = none
> idlethread   = 0xf803700b9580: tid 18 "idle: cpu6"
> curpmap  = 0x80d28448
> tssp = 0x80d96d90
> commontssp   = 0x80d96d90
> rsp0 = 0xfe0116472cc0
> gs32p= 0x80d9d9c8
> ldt  = 0x80d9da08
> tss  = 0x80d9d9f8
> db:0:kdb.enter.panic>  bt
> Tracing pid 0 tid 100218 td 0xf80370c82000
> kdb_enter() at kdb_enter+0x3b/frame 0xfe0116472aa0
> vpanic() at vpanic+0x1c0/frame 0xfe0116472b00
> panic() at panic+0x43/frame 0xfe0116472b60
> deadlkres() at deadlkres+0x3a6/frame 0xfe0116472bb0
> fork_exit() at fork_exit+0x84/frame 0xfe0116472bf0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0116472bf0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> 
> 
> Bye,
> Alexander.
> 
> -- 
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


___
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: Recent changes in routing or IPv6 related parts?

[Alexander Leidinger]

Quoting Alexander Leidinger  (from Sun, 27  
May 2018 21:12:17 +0200):


Quoting Chris H  (from Tue, 22 May 2018  
09:59:04 -0700):



Hello, Alexander.
I'm not sure if this landed in -CURRENT. I only know it landed in 11.
But your trouble might be related to pr #224247 :

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224247

Hope this helps.


Thanks, I've compiled a kernel which will print a message with the  
interface name when a packet will be dropped because of this. If I  
see something which makes it look like it could be related, I will  
disable it and try again.


It doesn't look like this is causing the issues I see. I have added  
some printfs in the silent-discard parts and nothing in printed when  
the workaround-script detects the issue.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpkLatnCaWi8.pgp
Description: Digitale PGP-Signatur

ACPI is broken on CURRENT

[Yuri]

I couldn't make the S3 suspend to work at all.

Please see the bug report: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228654



Yuri


___
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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

On Sun, 3 Jun 2018 18:04:23 +0300
Konstantin Belousov  wrote:

> On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Sun, 3 Jun 2018 16:21:10 +0300
> > Konstantin Belousov  wrote:
> >   
> > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:  
> > > > Hi,
> > > > 
> > > > After upgrading CURRENT to r333992 (from something at least a
> > > > year old, quite some changes in mp_machdep.c since), this
> > > > machine crashes on boot:
> > > > 
> > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,
> > > > 1993, 1994 The Regents of the University of California. All
> > > > rights reserved. FreeBSD is a registered trademark of The
> > > > FreeBSD Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue May 22
> > > > 00:31:04 CEST 2018
> > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565)
> > > > (based on LLVM 6.0.0) WARNING: WITNESS option enabled, expect
> > > > reduced performance. VT(vga): resolution 640x480 CPU: Intel(R)
> > > > Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > > > Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45
> > > > Stepping=1
> > > > Features=0xbfebfbff > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > Features2=0x4ddaebbf > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > AMD Features=0x2c100800 AMD
> > > > Features2=0x21 Structured Extended
> > > > Features=0x2603 XSAVE
> > > > Features=0x1 VT-x: (disabled in BIOS)
> > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > performance statistics real memory  = 4301258752 (4102 MB)
> > > > avail memory = 1907572736 (1819 MB) Event timer "LAPIC" quality
> > > > 600 ACPI APIC Table: 
> > > What does this mean ?  Did you flashed coreboot ?  
> > 
> > This machine comes with it by default (my model was delivered with 
> > SeaBIOS 20131018_145217-build121-m2). So I didn't flash anything
> > (didn't feel like bricking it).
> >   
> > >   
> > > > kernel trap 12 with interrupts disabled
> > > > 
> > > > Fatal trap 12: page fault while in kernel mode 
> > > > cpuid = 0; apic id = 00
> > > > fault virtual address= 0xf8000100
> > > > fault code   = supervisor write data, protection
> > > > violation instruction pointer  = 0x20:Ox8102955f
> > > > stack pointer= 0x28:0x82a79be0
> > > > frame pointer= 0x28:0x82a79c10
> > > > code segment = base Ox0, limit Oxf, type Ox1b
> > > >  = DPL 0, pres 1, long 1, def32 0, gran
> > > > 1 processor eflags = resume, IOPL = 0
> > > > current process  = 0 ()
> > > > [ thread pid 0 tid 0 ]
> > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > %rax,(%rsi)
> > > Look up the source line number for this address.
> > >   
> > 
> > I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr),
> > called by native_start_all_aps. Any additional hints how I can
> > track it down?  
> Why did you decided that this is rdmsr_safe() ? First,
> native_start_all_aps() does not call rdmsr, second the ddb
> report clearly indicates that the fault occured acessing DMAP in
> native_start_all_aps().
> 
> Just look up the source line by the address
> native_start_all_aps+0x08f.

Okay, according to kgbd this should be here:

https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369

364
365/* Create the initial 1GB replicated page tables */
366for (i = 0; i < 512; i++) {
367/* Each slot of the level 4 pages points to the same
level 3 page */ 368pt4[i] =
(u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE); 369
pt4[i] |= PG_V | PG_RW | PG_U; 370
371/* Each slot of the level 3 pages points to the same
level 2 page */ 372pt3[i] =
(u_int64_t)(uintptr_t)(mptramp_pagetables + (2 * PAGE_SIZE));
373pt3[i] |= PG_V | PG_RW | PG_U; 374
375/* The level 2 page slots are mapped with 2MB pages for
1GB. */ 376pt2[i] = i * (2 * 1024 * 1024);
377pt2[i] |= PG_V | PG_RW | PG_PS | PG_U;
378}

-m

p.s. This machine uses quirks in biosmem.c, see

Type '?' for a list of command, 'help' for more detailed
help.
OK biosmem
bios_basemem: 0x9e400
bios_extmem: 0x3ff0
memtop: 0x3c00
high_heap_base: 0x3c00
high_heap_size: 0x400
bios_quirks: 0x01 BQ_DISTRUST_820_EXTMEM
b_bios_probed: 0x0a B_BASEMEM_12 B_EXTMEM_E801

-- 
Michael Gmelin

-- 
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"

local_unbound segfaults at boot

[Patrick McMunn]

I believe the problem of local_unbound segfaulting began after I compiled
the source after the large commit to unbound on Saturday, May 12, 2018
(about 3 weeks ago).

I assumed the problem was probably common if I was experiencing it, but
I've seen no other mentions of it. I'm not sure what info I need to
provide, but will do so upon request.
___
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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Konstantin Belousov]

On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:
> 
> 
> On Sun, 3 Jun 2018 18:04:23 +0300
> Konstantin Belousov  wrote:
> 
> > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:
> > > 
> > > 
> > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > Konstantin Belousov  wrote:
> > >   
> > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:  
> > > > > Hi,
> > > > > 
> > > > > After upgrading CURRENT to r333992 (from something at least a
> > > > > year old, quite some changes in mp_machdep.c since), this
> > > > > machine crashes on boot:
> > > > > 
> > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,
> > > > > 1993, 1994 The Regents of the University of California. All
> > > > > rights reserved. FreeBSD is a registered trademark of The
> > > > > FreeBSD Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue May 22
> > > > > 00:31:04 CEST 2018
> > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565)
> > > > > (based on LLVM 6.0.0) WARNING: WITNESS option enabled, expect
> > > > > reduced performance. VT(vga): resolution 640x480 CPU: Intel(R)
> > > > > Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > > > > Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45
> > > > > Stepping=1
> > > > > Features=0xbfebfbff > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > > Features2=0x4ddaebbf > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > AMD Features=0x2c100800 AMD
> > > > > Features2=0x21 Structured Extended
> > > > > Features=0x2603 XSAVE
> > > > > Features=0x1 VT-x: (disabled in BIOS)
> > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > performance statistics real memory  = 4301258752 (4102 MB)
> > > > > avail memory = 1907572736 (1819 MB) Event timer "LAPIC" quality
> > > > > 600 ACPI APIC Table: 
> > > > What does this mean ?  Did you flashed coreboot ?  
> > > 
> > > This machine comes with it by default (my model was delivered with 
> > > SeaBIOS 20131018_145217-build121-m2). So I didn't flash anything
> > > (didn't feel like bricking it).
> > >   
> > > >   
> > > > > kernel trap 12 with interrupts disabled
> > > > > 
> > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > cpuid = 0; apic id = 00
> > > > > fault virtual address= 0xf8000100
> > > > > fault code   = supervisor write data, protection
> > > > > violation instruction pointer  = 0x20:Ox8102955f
> > > > > stack pointer= 0x28:0x82a79be0
> > > > > frame pointer= 0x28:0x82a79c10
> > > > > code segment = base Ox0, limit Oxf, type Ox1b
> > > > >  = DPL 0, pres 1, long 1, def32 0, gran
> > > > > 1 processor eflags = resume, IOPL = 0
> > > > > current process  = 0 ()
> > > > > [ thread pid 0 tid 0 ]
> > > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > > %rax,(%rsi)
> > > > Look up the source line number for this address.
> > > >   
> > > 
> > > I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr),
> > > called by native_start_all_aps. Any additional hints how I can
> > > track it down?  
> > Why did you decided that this is rdmsr_safe() ? First,
> > native_start_all_aps() does not call rdmsr, second the ddb
> > report clearly indicates that the fault occured acessing DMAP in
> > native_start_all_aps().
> > 
> > Just look up the source line by the address
> > native_start_all_aps+0x08f.
> 
> Okay, according to kgbd this should be here:
> 
> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369
> 
> 364
> 365/* Create the initial 1GB replicated page tables */
> 366for (i = 0; i < 512; i++) {
> 367/* Each slot of the level 4 pages points to the same
> level 3 page */ 368pt4[i] =
> (u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE); 369
> pt4[i] |= PG_V | PG_RW | PG_U; 370
> 371/* Each slot of the level 3 pages points to the same
> level 2 page */ 372pt3[i] =
> (u_int64_t)(uintptr_t)(mptramp_pagetables + (2 * PAGE_SIZE));
> 373pt3[i] |= PG_V | PG_RW | PG_U; 374
> 375/* The level 2 page slots are mapped with 2MB pages for
> 1GB. */ 376pt2[i] = i * (2 * 1024 * 1024);
> 377pt2[i] |= PG_V | PG_RW | PG_PS | PG_U;
> 378}
> 
> -m
You have fault on write due to read-only mapping of the portion of
the direct map, which maps the kernel text.  It is consistent with
the faulting address.  It is not clear if it is something new on
your machine, or before the kernel text was silently corrupted, since
ro protection is somewhat recent.

It seems that mp_bootaddress() selected the bad place for the bootstrap
page tables. Even more, we do not include the kernel text

how to deal with variable set but not used warnings?

[Rick Macklem]

mmacy has sent me a bunch of warnings of the "variable set but not used" kind
generated by gcc8.

When I've looked at the code, these are for RPC arguments I parse but do not
use at this time.
I'd  like to leave the code in place, since these arguments may be needed in the
future and it is hard to figure out how to get them years from now, when they
might be needed.
I can think of 3 ways to handle this:
1 - Get rid of the code. (As above, I'd rather not do this.)
2 - Wrap the code with "#if 0"/"#endif" or similar. I'll admit that I find this 
rather
  ugly and tends to make the code harder to follow.
3 - Leave the code and add a comment w.r.t. why the variables are set but not 
used.

So, what do others think is the preferable alternative?
(Or maybe you have a #4 that seems better than any of these.)

Thanks for your comments, rick
___
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: how to deal with variable set but not used warnings?

[Warner Losh]

On Sun, Jun 3, 2018 at 3:28 PM, Rick Macklem  wrote:

> mmacy has sent me a bunch of warnings of the "variable set but not used"
> kind
> generated by gcc8.
>
> When I've looked at the code, these are for RPC arguments I parse but do
> not
> use at this time.
> I'd  like to leave the code in place, since these arguments may be needed
> in the
> future and it is hard to figure out how to get them years from now, when
> they
> might be needed.
> I can think of 3 ways to handle this:
> 1 - Get rid of the code. (As above, I'd rather not do this.)
> 2 - Wrap the code with "#if 0"/"#endif" or similar. I'll admit that I find
> this rather
>   ugly and tends to make the code harder to follow.
> 3 - Leave the code and add a comment w.r.t. why the variables are set but
> not used.
>
> So, what do others think is the preferable alternative?
> (Or maybe you have a #4 that seems better than any of these.)
>

4. Disable the stupid warning in the Makefile / build system. If you don't
care, and there's a good reason for what you are doing (sounds like there
is), better to just disable the warning as so much useless noise.

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"

Re: how to deal with variable set but not used warnings?

[Theron]

On 06/03/18 17:33, Warner Losh wrote:

On Sun, Jun 3, 2018 at 3:28 PM, Rick Macklem  wrote:


mmacy has sent me a bunch of warnings of the "variable set but not used"
kind
generated by gcc8.

When I've looked at the code, these are for RPC arguments I parse but do
not
use at this time.
I'd  like to leave the code in place, since these arguments may be needed
in the
future and it is hard to figure out how to get them years from now, when
they
might be needed.
I can think of 3 ways to handle this:
1 - Get rid of the code. (As above, I'd rather not do this.)
2 - Wrap the code with "#if 0"/"#endif" or similar. I'll admit that I find
this rather
   ugly and tends to make the code harder to follow.
3 - Leave the code and add a comment w.r.t. why the variables are set but
not used.

So, what do others think is the preferable alternative?
(Or maybe you have a #4 that seems better than any of these.)


4. Disable the stupid warning in the Makefile / build system. If you don't
care, and there's a good reason for what you are doing (sounds like there
is), better to just disable the warning as so much useless noise.

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"

Or possibly, alongside a comment as in (3), use one of these:
5 - Disable warning pragma - 
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
6 - Use __attribute__((unused)) - 
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes


___
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: how to deal with variable set but not used warnings?

[Cy Schubert]

In message 
, Warner Losh writes:
> On Sun, Jun 3, 2018 at 3:28 PM, Rick Macklem  wrote:
>
> > mmacy has sent me a bunch of warnings of the "variable set but not used"
> > kind
> > generated by gcc8.
> >
> > When I've looked at the code, these are for RPC arguments I parse but do
> > not
> > use at this time.
> > I'd  like to leave the code in place, since these arguments may be needed
> > in the
> > future and it is hard to figure out how to get them years from now, when
> > they
> > might be needed.
> > I can think of 3 ways to handle this:
> > 1 - Get rid of the code. (As above, I'd rather not do this.)
> > 2 - Wrap the code with "#if 0"/"#endif" or similar. I'll admit that I find
> > this rather
> >   ugly and tends to make the code harder to follow.
> > 3 - Leave the code and add a comment w.r.t. why the variables are set but
> > not used.
> >
> > So, what do others think is the preferable alternative?
> > (Or maybe you have a #4 that seems better than any of these.)
> >
>
> 4. Disable the stupid warning in the Makefile / build system. If you don't
> care, and there's a good reason for what you are doing (sounds like there
> is), better to just disable the warning as so much useless noise.

And leave a comment in the Makefile in case someone decides to 
re-enable the warning at some later date.


-- 
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"

Re: how to deal with variable set but not used warnings?

[Steve Kargl]

On Sun, Jun 03, 2018 at 09:28:47PM +, Rick Macklem wrote:
> mmacy has sent me a bunch of warnings of the "variable set but not used" kind
> generated by gcc8.
> 
> When I've looked at the code, these are for RPC arguments I parse but do not
> use at this time.
> I'd  like to leave the code in place, since these arguments may be needed in 
> the
> future and it is hard to figure out how to get them years from now, when they
> might be needed.
> I can think of 3 ways to handle this:
> 1 - Get rid of the code. (As above, I'd rather not do this.)
> 2 - Wrap the code with "#if 0"/"#endif" or similar. I'll admit that I find 
> this rather
>   ugly and tends to make the code harder to follow.
> 3 - Leave the code and add a comment w.r.t. why the variables are set but not 
> used.
> 
> So, what do others think is the preferable alternative?
> (Or maybe you have a #4 that seems better than any of these.)
> 

CFLAGS+=-Wno-unused

-- 
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"

Re: how to deal with variable set but not used warnings?

[Matthew Macy]

On Sun, Jun 3, 2018 at 2:40 PM, Theron  wrote:
>> 4. Disable the stupid warning in the Makefile / build system. If you don't
>> care, and there's a good reason for what you are doing (sounds like there
>> is), better to just disable the warning as so much useless noise.
>>
>> 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"
>
> Or possibly, alongside a comment as in (3), use one of these:
> 5 - Disable warning pragma -
> http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
> 6 - Use __attribute__((unused)) -
> https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes


There is already an __unused alias for #6. It's what I've used to
annotate variables that are only used by INVARIANTS builds. It
legitimately finds a bunch of dead code. However, 90+% of the
instances of the warning are not interesting.
-M
___
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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

On Sun, 3 Jun 2018 23:53:40 +0300
Konstantin Belousov  wrote:

> On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Sun, 3 Jun 2018 18:04:23 +0300
> > Konstantin Belousov  wrote:
> >   
> > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:  
> > > > 
> > > > 
> > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > Konstantin Belousov  wrote:
> > > > 
> > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin
> > > > > wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > After upgrading CURRENT to r333992 (from something at least
> > > > > > a year old, quite some changes in mp_machdep.c since), this
> > > > > > machine crashes on boot:
> > > > > > 
> > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
> > > > > > 1992, 1993, 1994 The Regents of the University of
> > > > > > California. All rights reserved. FreeBSD is a registered
> > > > > > trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT
> > > > > > #1 r333992: Tue May 22 00:31:04 CEST 2018
> > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > > > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565)
> > > > > > (based on LLVM 6.0.0) WARNING: WITNESS option enabled,
> > > > > > expect reduced performance. VT(vga): resolution 640x480
> > > > > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz
> > > > > > K8-class CPU) Origin="GenuineIntel"  Id=0x40651
> > > > > > Family=0x6  Model=0x45 Stepping=1
> > > > > > Features=0xbfebfbff > > > > >   
> > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>  
> > > > > > Features2=0x4ddaebbf > > > > >   
> > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > >   
> > > > > > AMD Features=0x2c100800 AMD
> > > > > > Features2=0x21 Structured Extended
> > > > > > Features=0x2603 XSAVE
> > > > > > Features=0x1 VT-x: (disabled in BIOS)
> > > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > > performance statistics real memory  = 4301258752 (4102 MB)
> > > > > > avail memory = 1907572736 (1819 MB) Event timer "LAPIC"
> > > > > > quality 600 ACPI APIC Table:   
> > > > > What does this mean ?  Did you flashed coreboot ?
> > > > 
> > > > This machine comes with it by default (my model was delivered
> > > > with SeaBIOS 20131018_145217-build121-m2). So I didn't flash
> > > > anything (didn't feel like bricking it).
> > > > 
> > > > > 
> > > > > > kernel trap 12 with interrupts disabled
> > > > > > 
> > > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > > cpuid = 0; apic id = 00
> > > > > > fault virtual address= 0xf8000100
> > > > > > fault code   = supervisor write data, protection
> > > > > > violation instruction pointer  = 0x20:Ox8102955f
> > > > > > stack pointer= 0x28:0x82a79be0
> > > > > > frame pointer= 0x28:0x82a79c10
> > > > > > code segment = base Ox0, limit Oxf, type
> > > > > > Ox1b = DPL 0, pres 1, long 1, def32 0, gran
> > > > > > 1 processor eflags = resume, IOPL = 0
> > > > > > current process  = 0 ()
> > > > > > [ thread pid 0 tid 0 ]
> > > > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > > > %rax,(%rsi)  
> > > > > Look up the source line number for this address.
> > > > > 
> > > > 
> > > > I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr),
> > > > called by native_start_all_aps. Any additional hints how I can
> > > > track it down?
> > > Why did you decided that this is rdmsr_safe() ? First,
> > > native_start_all_aps() does not call rdmsr, second the ddb
> > > report clearly indicates that the fault occured acessing DMAP in
> > > native_start_all_aps().
> > > 
> > > Just look up the source line by the address
> > > native_start_all_aps+0x08f.  
> > 
> > Okay, according to kgbd this should be here:
> > 
> > https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369
> > 
> > 364
> > 365/* Create the initial 1GB replicated page tables */
> > 366for (i = 0; i < 512; i++) {
> > 367/* Each slot of the level 4 pages points to the same
> > level 3 page */ 368pt4[i] =
> > (u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE); 369
> > pt4[i] |= PG_V | PG_RW | PG_U; 370
> > 371/* Each slot of the level 3 pages points to the same
> > level 2 page */ 372pt3[i] =
> > (u_int64_t)(uintptr_t)(mptramp_pagetables + (2 * PAGE_SIZE));
> > 373pt3[i] |= PG_V | PG_RW | PG_U; 374
> > 375/* The level 2 page slots are mapped with 2MB pages
> > for 1GB. */ 376pt2[i] = i * (2 * 1024 * 1024);
> > 377pt2[i] |= PG_V | PG_RW | PG_PS | PG_U;
> > 378}
> > 
> > -m  
> You have fault on write due to read-only mapping of the portion of
> the direct map, which maps the kerne

Re: SPDX-License-Id for new files

[Rodney W. Grimes]

> I have a few (3) new files in the projects/pnfs-planb-server subversion tree
> that all have the 2 clause FreeBSD copyright.
> 
> Do I just add the "SPDX..." line for this license at the top of the copyright 
> comment
> or is there some other exercise needed to be done for this?

Just add the SPDX line, Try to make it the first line inside the block comment:
/*-
 * SPDX-License-Identifier: BSD-2-Clause

Regards,
-- 
Rod Grimes rgri...@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: Elantech Touchpad Woes - Support for Elantech touchpads over i2c/SMBus still possibly missing

[Brian Kidney]

Hi all,

I have a ASUS Zenbook UX430U with the same problem. I am heading to 
BSDCan (and the FreeBSD Dev Submit as a guest) this week and could spend 
some time working on this in the hacker lounge. That said, I am new to 
FreeBSD driver code, so I could use some guidance to help me along. 
Anyone headed to the conference that might be able to lend me a hand?


Thanks,
Brian

Brian Kidney, M.Eng., P.Eng.
PGP Fingerprint: B8C9 D174 BABC 7FD8 67D0  DF84 FDEE B338 F248 A893

On 3 Jun 2018, at 2:43, Albert wrote:


Michael,

Good to know you still have plans to work on that eventually. It'd be 
much appreciated.


Looking at the source for your cyapa driver, I see you've ported it 
from the DragonFlyBSD driver (and they in turn adapted it from the 
Linux one). I should've looked into that earlier... Instead I spent 
most of my day trying to get OpenBSD running to try and follow Tom's 
hint at possible support there, but I had so many more issues along 
the way that in the end I figured "if I'm having trouble even getting 
a keyboard to work on this with my system, a touchpad will likely be 
the least of my worries."


So, I'm back to my FreeBSD CURRENT install, still no touchpad support 
(obviously). I guess I'll be doing some more research on these things 
and tinkering with what I find. Unfortunately, I'm moving overseas in 
a couple of weeks and leaving my desktop behind, which means I need to 
have this laptop in full working condition by then, so if I don't make 
any progress, I'll have to somewhat reluctantly go back to Linux for 
the time being. If/when that happens, I'll still be happy to help with 
any testing.


MfG,

- Albert

___
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

[Dhananjay Balan]

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


-
dbalan

___
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"