Re: Reading from bad disk ?

[Rainer Hurling]

Leif Neland wrote:
 
  It seems Warner Losh wrote:
 ...
   mount it in front of the drive to get it to run at  a reasonable
   temperature.  W/o the fan, it was running at 58C or so.  With the fan
   it runs at 39C or so.  I've included the script that I use to find
   this information out.  Ken Merry sent it to me.  It works on some IBM
   drives.
  
   Warner
  
   #!/bin/sh
  
   TEMPC=`camcontrol cmd -v -n da -u 0 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"`
  
   TEMPF=`echo " 2 k $TEMPC 9 * 5 / 32 + p" | dc`
  
   echo "The temperature is: $TEMPF F $TEMPC C"
 
 Tried this:
 #!/bin/sh
 
 TEMPC=`camcontrol cmd -v -n da -u 2 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"`
 TEMPF=`echo " 2 k $TEMPC 9 * 5 / 32 + p" | dc`
 echo "The temperature is: $TEMPF F $TEMPC C"
 
 I.e. replaced -u 0 with -u 2, because unit 2 is an IBM:
 
 ncr0: ncr 53c810 fast10 scsi port 0xd100-0xd1ff mem 0x2000-0x20ff irq 11 
at device 1.0 on pci0
 ncr0: driver is using old-style compatability shims
 da1 at ncr0 bus 0 target 1 lun 0
 da0 at ncr0 bus 0 target 0 lun 0
 da2 at ncr0 bus 0 target 2 lun 0
 da2: IBM DCAS-34330 S65A Fixed Direct Access SCSI-2 device
 da2: 10.000MB/s transfers (10.000MHz, offset 8)
 da2: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C)
 
 But I get this:
 
 camcontrol: error sending command
 (pass2:ncr0:0:2:0): LOG SENSE. CDB: 4d 0 76 0 0 0 0 0 20 0
 (pass2:ncr0:0:2:0): ILLEGAL REQUEST asc:24,0
 (pass2:ncr0:0:2:0): Invalid field in CDB
 dc: stack empty
 The temperature is: 33.80 F  C
 
 Does this simply mean this drive does not support temperature measurement,
 or should something more be changed to use dev da2 instead of da0?
 
 I'm running a week or so old current.
 
 Leif
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message

Have had same Problem with my DCAS-34330's. Having a look in IBM's
product specification at
http://www.storage.ibm.com/techsup/hddtech/prodspec/dcas_spw.pdf,
chapter 7.8 and others. It seems there is no information logging in this
type of harddisk drive?!

Rainer


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Port problems after r253839 on HEAD

[Rainer Hurling]

After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c),
I recognized some wired behaviour in the ports system on my CURRENT boxes.

Some of the ports do not build anymore. They print almost similar
messages about an ld problem (invalid DSO for symbol 'xxx' definition),
followed by the lib, which symbols are not found.

With a recent 10.0-CURRENT (at least r253839) you can try this for
example with the following two ports:


(1) editors/nano
cc  -O2 -pipe -fno-strict-aliasing  -L/usr/local/lib -o nano browser.o
chars.o color.o  cut.o files.o global.o help.o  move.o nano.o prompt.o
rcfile.o search.o text.o  utils.o winio.o /usr/local/lib/libintl.so
/usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib -lncursesw
/usr/bin/ld: .: invalid DSO for symbol `keypad' definition
/usr/local/lib/libtinfow.so.5.9: could not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see invocation)

(2) www/evolution-webcal
cc  -O2 -pipe -fno-strict-aliasing  -L/usr/local/lib -o evolution-webcal
evolution-webcal-main.o evolution-webcal-notify.o -lgtk-x11-2.0
-lgdk-x11-2.0 -lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi -lXrandr
-lXcursor -lXcomposite -lXdamage -lXfixes -lX11 -latk-1.0 -lcairo
-lgdk_pixbuf-2.0 -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig
-lecal-1.2 -lical -licalss -licalvcal -pthread -ledataserver-1.2 -lxml2
-lgconf-2 -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -L/usr/local/lib -lglib-2.0
-lintl
/usr/bin/ld: R: invalid DSO for symbol `g_thread_init' definition
/usr/local/lib/libgthread-2.0.so.0: could not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see invocation)


This errors disappear when I revert /usr/bin/ld to a revision before 253839.


Furthermore I observed some wired behaviour for SAGA GIS (math/saga; I
am the maintainer of it).
This port should build and install a SAGA GIS module as
/usr/local/lib/saga/libopencv.so (for this it has graphics/opencv as a
dependency).
With /usr/bin/ld rev. 253839 installed, the autotools configure process
from math/saga is not able to find /usr/local/lib/libopencv_legacy.so
and so it does not build the module. Unfortunately it gives no
clarifying hint about the problem).
Reverting the version of /usr/bin/ld before r253839 solves this problem ...


I hope my description is of some use and does not point in the wrong
direction.
Rainer Hurling
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Port problems after r253839 on HEAD

[Rainer Hurling]

Thanks, Bapt, for answering.

Am 07.08.2013 19:43, schrieb Baptiste Daroussin:
 On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote:
 After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c),
 I recognized some wired behaviour in the ports system on my CURRENT boxes.

 Some of the ports do not build anymore. They print almost similar
 messages about an ld problem (invalid DSO for symbol 'xxx' definition),
 followed by the lib, which symbols are not found.

 With a recent 10.0-CURRENT (at least r253839) you can try this for
 example with the following two ports:

 normally I had tracked down all those ports, except if you are building them
 with nom default options,

#cd /usr/ports/www/evolution-webcal
#make config
=== No options to configure

#cd /usr/ports/editors/nano
#make config
=== No options to configure

 What that means is basically the said ports are missing some -lbla in ldflags,
 
 The missing ones are those listed in the line following the DSO bla
 in nano for example the first failure means -liconv is missing.

Yupp, thanks, the following two patches seem to work:

--- Makefile.orig   2013-07-17 16:59:50.0 +0200
+++ Makefile2013-08-07 20:42:11.0 +0200
@@ -15,11 +15,13 @@

 CONFLICTS= nano-devel-2*

+LIB_DEPENDS=   tinfow:${PORTSDIR}/devel/ncurses
+
 GNU_CONFIGURE= yes

 CONFIGURE_ARGS=--docdir=${DOCSDIR}
 CPPFLAGS+= -I${LOCALBASE}/include
-LDFLAGS+=  -L${LOCALBASE}/lib
+LDFLAGS+=  -L${LOCALBASE}/lib -ltinfow

 .include bsd.port.options.mk



--- Makefile.orig   2013-06-20 17:40:13.0 +0200
+++ Makefile2013-08-07 20:47:21.0 +0200
@@ -23,7 +23,7 @@
 USE_GNOME= gnomeprefix gnomehack intlhack evolutiondataserver libgnomeui
 GNU_CONFIGURE= yes
 CPPFLAGS+= -I${LOCALBASE}/include
-LDFLAGS+=  -L${LOCALBASE}/lib
+LDFLAGS+=  -L${LOCALBASE}/lib -lgthread-2.0

 GCONF_SCHEMAS= evolution-webcal.schemas


 
 I afk until 24th so I can't commit any fix to the said ports.


 There were properly building in my exp-run for the said change, meaning either
 you build with non default options im that case the port requires a fix or
 perhaps your ports tree is not uptodate, in particular lots of those failures
 are fixed by the recent glib update.

Hmm. As far as I can say my ports tree is uptodate and I did the
complete glib update (/usr/ports/UPDATING entry 20130731). So I have no
clue, why editors/nano does complain about devel/ncurses.

In particular I am wondering about the misbehaviour of my port
math/saga. As I wrote before, the autotools process does not find
libopencv.so, only and only if HEAD is using /usr/bin/ld r253839.
Probably there is a hidden problem, not seen before without the ld
patch? Any hint would be very appreciated.

Many thanks for your fast help and greetings from Göttingen in Germany,
Rainer
 
 regards,
 Bapt
 

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

Re: Port problems after r253839 on HEAD

[Rainer Hurling]

Am 07.08.2013 21:01 (UTC+1) schrieb Rainer Hurling:
 Thanks, Bapt, for answering.
 
 Am 07.08.2013 19:43, schrieb Baptiste Daroussin:
 On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote:
 After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c),
 I recognized some wired behaviour in the ports system on my CURRENT boxes.

 Some of the ports do not build anymore. They print almost similar
 messages about an ld problem (invalid DSO for symbol 'xxx' definition),
 followed by the lib, which symbols are not found.

 With a recent 10.0-CURRENT (at least r253839) you can try this for
 example with the following two ports:

 normally I had tracked down all those ports, except if you are building them
 with nom default options,
 
 #cd /usr/ports/www/evolution-webcal
 #make config
 === No options to configure
 
 #cd /usr/ports/editors/nano
 #make config
 === No options to configure
 
 What that means is basically the said ports are missing some -lbla in 
 ldflags,

 The missing ones are those listed in the line following the DSO bla
 in nano for example the first failure means -liconv is missing.
 
 Yupp, thanks, the following two patches seem to work:
 
 --- Makefile.orig 2013-07-17 16:59:50.0 +0200
 +++ Makefile  2013-08-07 20:42:11.0 +0200
 @@ -15,11 +15,13 @@
 
  CONFLICTS=   nano-devel-2*
 
 +LIB_DEPENDS= tinfow:${PORTSDIR}/devel/ncurses
 +
  GNU_CONFIGURE=   yes
 
  CONFIGURE_ARGS=  --docdir=${DOCSDIR}
  CPPFLAGS+=   -I${LOCALBASE}/include
 -LDFLAGS+=-L${LOCALBASE}/lib
 +LDFLAGS+=-L${LOCALBASE}/lib -ltinfow
 
  .include bsd.port.options.mk
 
 
 
 --- Makefile.orig 2013-06-20 17:40:13.0 +0200
 +++ Makefile  2013-08-07 20:47:21.0 +0200
 @@ -23,7 +23,7 @@
  USE_GNOME=   gnomeprefix gnomehack intlhack evolutiondataserver libgnomeui
  GNU_CONFIGURE=   yes
  CPPFLAGS+=   -I${LOCALBASE}/include
 -LDFLAGS+=-L${LOCALBASE}/lib
 +LDFLAGS+=-L${LOCALBASE}/lib -lgthread-2.0
 
  GCONF_SCHEMAS=   evolution-webcal.schemas
 
 

 I afk until 24th so I can't commit any fix to the said ports.
 
 
 There were properly building in my exp-run for the said change, meaning 
 either
 you build with non default options im that case the port requires a fix or
 perhaps your ports tree is not uptodate, in particular lots of those failures
 are fixed by the recent glib update.
 
 Hmm. As far as I can say my ports tree is uptodate and I did the
 complete glib update (/usr/ports/UPDATING entry 20130731). So I have no
 clue, why editors/nano does complain about devel/ncurses.
 
 In particular I am wondering about the misbehaviour of my port
 math/saga. As I wrote before, the autotools process does not find
 libopencv.so, only and only if HEAD is using /usr/bin/ld r253839.
 Probably there is a hidden problem, not seen before without the ld
 patch? Any hint would be very appreciated.

Ok, after getting your hint about missing LDFLAGS I narrowed it down for
SAGA GIS 2.1.0. As complained in the config.log, conftest for autotools
is also missing one library. The following in math/saga should do the
trick (I will open a PR for it):

--- Makefile.orig   2013-07-31 18:09:58.0 +0200
+++ Makefile2013-08-08 11:11:15.0 +0200
@@ -47,7 +47,7 @@

 .include bsd.port.options.mk

-LDFLAGS+=  -L${LOCALBASE}/lib
+LDFLAGS+=  -L${LOCALBASE}/lib -lopencv_core
 CONFIGURE_ARGS+=   CFLAGS=${CFLAGS} LDFLAGS=${LDFLAGS}

 .if ${PORT_OPTIONS:MPYTHON}


So no problems left for me with new /usr/bin/ld :)
Thanks again for any help.

Greetings,
Rainer

 
 Many thanks for your fast help and greetings from Göttingen in Germany,
 Rainer

 regards,
 Bapt

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

Re: Port problems after r253839 on HEAD

[Rainer Hurling]

Am 09.08.2013 19:27 UTC+2, schrieb Steve Kargl:
 On Wed, Aug 07, 2013 at 07:43:33PM +0200, Baptiste Daroussin wrote:
 On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote:
 After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c),
 I recognized some wired behaviour in the ports system on my CURRENT boxes.

 Some of the ports do not build anymore. They print almost similar
 messages about an ld problem (invalid DSO for symbol 'xxx' definition),
 followed by the lib, which symbols are not found.

 With a recent 10.0-CURRENT (at least r253839) you can try this for
 example with the following two ports:

 normally I had tracked down all those ports, except if you are building them
 with nom default options,

 What that means is basically the said ports are missing some -lbla in 
 ldflags,

 The missing ones are those listed in the line following the DSO bla
 in nano for example the first failure means -liconv is missing.

 I afk until 24th so I can't commit any fix to the said ports.
 There were properly building in my exp-run for the said change, meaning 
 either
 you build with non default options im that case the port requires a fix or
 perhaps your ports tree is not uptodate, in particular lots of those failures
 are fixed by the recent glib update.
 
 
 On a freshly rebuilt freebsd-current where I've deleted all ports
 to do a fresh build of everything I use, I see
 
 % portmaster news/pan
 ...
   CXXLD  pan
 /usr/bin/ld: ,: invalid DSO for symbol `libiconv_open' definition
 /usr/local/lib/libiconv.so.3: could not read symbols: Bad value
 c++: error: linker command failed with exit code 1 (use -v to see invocation)
 gmake[5]: *** [pan] Error 1
 gmake[5]: Leaving directory `/usr/ports/news/pan/work/pan-0.139/pan/gui'
 gmake[4]: *** [all-recursive] Error 1
 gmake[4]: Leaving directory `/usr/ports/news/pan/work/pan-0.139/pan'
 
 Please, fix.
 

If I understand bapt@ right, this should be all what is needed:


--- Makefile.orig   2013-06-20 17:48:12.0 +0200
+++ Makefile2013-08-09 20:56:36.0 +0200
@@ -15,7 +15,8 @@
 LICENSE=   GPLv2

 LIB_DEPENDS=   pcre:${PORTSDIR}/devel/pcre \
-   gmime-2.6:${PORTSDIR}/mail/gmime26
+   gmime-2.6:${PORTSDIR}/mail/gmime26 \
+   iconv:${PORTSDIR}/converters/libiconv

 USE_BZIP2= yes
 USE_GMAKE= yes
@@ -23,7 +24,7 @@
 USE_GNOME= intlhack
 GNU_CONFIGURE= yes
 CPPFLAGS+= -I${LOCALBASE}/include
-LDFLAGS+=  -L${LOCALBASE}/lib -lgnuregex
+LDFLAGS+=  -L${LOCALBASE}/lib -lgnuregex -liconv

 OPTIONS_DEFINE=GTKSPELL GTK3
 OPTIONS_DEFAULT=GTKSPELL


HTH,
Rainer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Rainer Hurling]

 = kmem_alloc_contig(kmem_arena, size, flags, 0,
  sc-dma_mask, PAGE_SIZE, 0, attr);
  if (!address) {
  status = ENOMEM;
 @@ -994,7 +994,7 @@
  os_flush_cpu_cache();
  
  if (at-pte_array[0].virtual_address != NULL) {
 -kmem_free(kernel_map,
 +kmem_free(kmem_arena,
  at-pte_array[0].virtual_address, at-size);
  malloc_type_freed(M_NVIDIA, at-size);
  }
 @@ -1021,7 +1021,7 @@
  if (at-attr != VM_MEMATTR_WRITE_BACK)
  os_flush_cpu_cache();
  
 -kmem_free(kernel_map, at-pte_array[0].virtual_address,
 +kmem_free(kmem_arena, at-pte_array[0].virtual_address,
  at-size);
  malloc_type_freed(M_NVIDIA, at-size);
  
 @@ -1085,7 +1085,7 @@
  }
  
  for (i = 0; i  count; i++) {
 -address = kmem_alloc_contig(kernel_map, PAGE_SIZE, flags, 0,
 +address = kmem_alloc_contig(kmem_arena, PAGE_SIZE, flags, 0,
  sc-dma_mask, PAGE_SIZE, 0, attr);
  if (!address) {
  status = ENOMEM;
 @@ -1139,7 +1139,7 @@
  for (i = 0; i  count; i++) {
  if (at-pte_array[i].virtual_address == 0)
  break;
 -kmem_free(kernel_map,
 +kmem_free(kmem_arena,
  at-pte_array[i].virtual_address, PAGE_SIZE);
  malloc_type_freed(M_NVIDIA, PAGE_SIZE);
  }
 @@ -1169,7 +1169,7 @@
  os_flush_cpu_cache();
  
  for (i = 0; i  count; i++) {
 -kmem_free(kernel_map,
 +kmem_free(kmem_arena,
  at-pte_array[i].virtual_address, PAGE_SIZE);
  malloc_type_freed(M_NVIDIA, PAGE_SIZE);
  }
 
 The primary differences are
 1) use kmem_arena instead of kernel_map everywhere.  The REINPLACE_CMD
uses kernel_arena
 2) DO NOT use kva_free, but kmem_free as previously
 
 To use the patch
 Delete or comment out the 4 lines starting at 160 in Makefile
 Run ``make patch''
 cd work/NVIDIA-FreeBSD-x86_64-319.32/src
 patch  [wherever the patch is]
 cd ../../..
 make deinstall install clean
 kldunload the old nvidia.ko
 kldload the new nvidia.ko
 start X
 

Yes, I can confirm, that it builds, installs and runs fine for me.

The patch should be placed as
x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it?

Many thanks for this work.

Regards and a nice weekend,
Rainer Hurling

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

Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv

[Rainer Hurling]

Am 07.09.2013 00:07, schrieb Baptiste Daroussin:
 On Fri, Sep 06, 2013 at 11:51:32PM +0200, O. Hartmann wrote:
 On Fri, 06 Sep 2013 21:11:26 +0400
 Boris Samorodov b...@passap.ru wrote:

 06.09.2013 20:44, O. Hartmann пишет:
 On Fri, 06 Sep 2013 20:08:59 +0400
 Boris Samorodov b...@passap.ru wrote:

 06.09.2013 19:44, O. Hartmann пишет:

 Here we go. It is the config.log from one of the failing machines,
 failing in print/cups-client.

 Please, show the output of following commands (at the host in
 question): # svn info /usr/ports/
 # svn svn st /usr/ports/print/cups*

 svn info /usr/ports/

 Path: /usr/ports
 Working Copy Root Path: /usr/ports
 URL: svn://svn.de.freebsd.org/ports/head
 Relative URL: ^/head
 Repository Root: svn://svn.de.freebsd.org/ports
 Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
 Revision: 326523
 Node Kind: directory
 Schedule: normal
 Last Changed Author: danfe
 Last Changed Rev: 326523
 Last Changed Date: 2013-09-06 18:22:29 +0200 (Fri, 06 Sep 2013)


 svn st /usr/ports/print/cups*
 ?   /usr/ports/print/cups-base/work
 ?   /usr/ports/print/cups-client/work

 That is really stange... Some more info:
 # svn st /usr/ports/Mk

 nothin (NULL output)

 # make -C /usr/ports/print/cups-client -V ICONV_LIB -V CONFIGURE_ARGS

 make -C /usr/ports/print/cups-client -V ICONV_LIB -V CONFIGURE_ARGS

 --localstatedir=/var
 --disable-slp
 --disable-gssapi--with-cups-user=cups
 --with-cups-group=cups   --with-system-groups=wheel
 --with-docdir=/usr/local/share/doc/cups
 --with-icondir=/usr/local/share/icons
 --with-menudir=/usr/local/share/applications
 --with-domainsocket=/var/run/cups.sock  --with-cachedir=/var/db/cups
 --with-pam-module=unix--enable-ssl
 --with-printcap=/usr/local/etc/printcap --disable-gnutls
 --enable-openssl --without-php --disable-dnssd --disable-pam
 --disable-ldap --disable-dbus --disable-libusb LIBS=-lssp_nonshared
 --prefix=/usr/local ${_LATE_CONFIGURE_ARGS}




 I see a lot of those obscure libtool errors not finding libiconv.la.
 Where the hell does the tool take those ecos from the past? I guess I
 have to reboot the box after X11 has been compiled

 
 Can you try to force rebuilding gettext first?

I can confirm that at least on my box after rebuilding gettext there are
no more of these 'not finding libiconv.la' errors.

For some reason gmake should be also rebuilded in an early stage. After
that, rebuilding libxml2 works fine.

 
 and then retry?
 
 regards,
 Bapt
 

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

latest sbin/pkg updates seem to break HEAD

[Rainer Hurling]

After svn update my 11.0-CURRENT box to r257152, the build breaks.
Obviously there is something wrong with the newest patches for sbin/pkg
(or libcrypt). Am I the only one observing this?

Any help is appreciated,
Rainer Hurling


[..snip..]
=== usr.sbin/pkg (all)
cc  -O2 -pipe  -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include
-std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.sbin/pkg/pkg.c
cc  -O2 -pipe  -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include
-std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.sbin/pkg/dns_utils.c
cc  -O2 -pipe  -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include
-std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.sbin/pkg/config.c
cc  -O2 -pipe  -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include
-std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int
-L/usr/obj/usr/src/tmp/usr/lib/private -rpath /usr/lib/private -o pkg
pkg.o dns_utils.o config.o -larchive -lelf -lfetch -lyaml -lsbuf -lssl

/usr/obj/usr/src/tmp/usr/bin/ld: D: invalid DSO for symbol
`EVP_PKEY_free' definition
/usr/obj/usr/src/tmp/lib/libcrypto.so.7: could not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1
Stop.
make[4]: stopped in /usr/src/usr.sbin/pkg
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: latest sbin/pkg updates seem to break HEAD

[Rainer Hurling]

Am 26.10.2013 13:04, schrieb Matthias Andree:
 Am 26.10.2013 12:56, schrieb Rainer Hurling:
 After svn update my 11.0-CURRENT box to r257152, the build breaks.
 Obviously there is something wrong with the newest patches for sbin/pkg
 (or libcrypt). Am I the only one observing this?

 Any help is appreciated,
 Rainer Hurling


 [..snip..]
 === usr.sbin/pkg (all)
 ...
 cc  -O2 -pipe  -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include
 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror
 -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
 -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
 -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
 -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
 -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign
 -Wno-empty-body -Wno-string-plus-int
 -L/usr/obj/usr/src/tmp/usr/lib/private -rpath /usr/lib/private -o pkg
 pkg.o dns_utils.o config.o -larchive -lelf -lfetch -lyaml -lsbuf -lssl

 /usr/obj/usr/src/tmp/usr/bin/ld: D: invalid DSO for symbol
 `EVP_PKEY_free' definition
 /usr/obj/usr/src/tmp/lib/libcrypto.so.7: could not read symbols: Bad value
 cc: error: linker command failed with exit code 1 (use -v to see invocation)
 *** Error code 1
 Stop.
 make[4]: stopped in /usr/src/usr.sbin/pkg
 
 These can happen if a library is missing, for instance, -lcrypto is
 apparently not mentioned on the linker's command line, but AFAIR the
 clang linker accepts no unresolved symbols from .so when linking
 executables, and -lssl likely needs -lcrypto.  This avoids run-time
 surprises due to missing dependencies (on libcrypto, in this case).
 
 Try pasting that command line with -lcrypto added after -lssl, and if
 that helps, try to debug where the -lcrypto has been or gets lost, or
 should get added.
 
 HTH

Yep, adding -lcrypto seems to help. I patched usr.sbin/pkg/Makefile for it.

But I am wondering if nobody else has this problem? I did not change my
systems sources before.

Many thanks for your fast reply and help,
Rainer



--- Makefile.orig   2013-10-26 08:33:50.0 +0200
+++ Makefile2013-10-26 14:26:06.0 +0200
@@ -7,7 +7,7 @@
 CFLAGS+=-I${.CURDIR}/../../contrib/libyaml/include
 .PATH: ${.CURDIR}/../../contrib/libyaml/include
 DPADD= ${LIBARCHIVE} ${LIBELF} ${LIBFETCH} ${LIBYAML} ${LIBSBUF}
-LDADD= -larchive -lelf -lfetch -lyaml -lsbuf -lssl
+LDADD= -larchive -lelf -lfetch -lyaml -lsbuf -lssl -lcrypto
 USEPRIVATELIB= yaml

 .include bsd.prog.mk

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

Re: libc++ vs. libstdc++ usage in the ports tree

[Rainer Hurling]

Am 14.11.2013 10:54 (UTC+1) schrieb David Chisnall:
 On 13 Nov 2013, at 19:40, Dimitry Andric d...@freebsd.org wrote:
 
 On the other hand, different C++ standard libraries simply cannot be
 mixed.  The internal implementations are usually completely different.
 This is not really news at all, certainly not to the ports people. :-)
 
 That said, it should still be possible to mix them in different libraries.
 The constraint from the wiki still applies: if you don't use STL types at 
 library boundaries, then it should still work.  If you do, then the libc++ 
 and libstdc++ symbols will be mangled differently and so you will get 
 link-time errors.
 
 In theory, if it links it should run...
 
 David

With the in this thread described change of the behaviour in 10.x and
HEAD, I have massive problems with building my port math/saga. Before
the changes, all built and worked fine.

Now, even when I add

  USES=   compiler:openmp
  CXXFLAGS+=  -std=gnu++0x

and commenting out USE_GCC=any

in the Makefile of math/saga, the build breaks with problems between
x11-toolkits/wxgtk29 (build with clang) and math/saga (try to build with
gcc46), see below, please.

I am clueless, what to do here. Building x11-toolkits/wxgtk29 with
gcc46+ is not an option.

Any help is really appreciated,
Rainer Hurling


make -D MAKE_JOBS_UNSAFE=yes
===  Building for saga-2.1.0_2
--- all ---
/usr/bin/make  all-recursive
--- all-recursive ---
Making all in .
Making all in src
--- all-recursive ---
Making all in saga_core
--- all-recursive ---
Making all in saga_api
Making all in saga_odbc
Making all in saga_gdi
Making all in saga_cmd
--- all-recursive ---
Making all in man
Making all in saga_gui
--- all-recursive ---
Making all in man
--- saga_gui ---
/bin/sh ../../../libtool  --tag=CXX--mode=link g++46 -fPIC
-D_SAGA_LINUX -D_TYPEDEF_BYTE -D_TYPEDEF_WORD -D_SAGA_DONOTUSE_HARU
-DMODULE_LIBRARY_PATH=\/usr/local/lib/saga\
-DSHARE_PATH=\/usr/local/share/saga\  -I.. -I.
`/usr/local/bin/wxgtk2u-2.9-config --unicode=yes --cxxflags`
-D_SAGA_UNICODE -fopenmp  -O2 -pipe -I/usr/local/include
-Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -std=gnu++0x
-Wl,-rpath=/usr/local/lib/gcc46 -fPIC `/usr/local/bin/wxgtk2u-2.9-config
--unicode=yes --libs adv,aui,base,core,html,net,propgrid,xml`
-L/usr/local/lib -lopencv_core -pthread -Wl,-rpath=/usr/local/lib/gcc46
-o saga_gui active.o active_attributes.o  active_description.o
active_history.o  active_HTMLExtraInfo.o active_legend.o
active_parameters.o callback.o  data_source.o data_source_files.o
data_source_odbc.o dc_helper.o  dlg_about.o dlg_about_logo.o  dlg_base.o
dlg_colors.o  dlg_colors_control.o dlg_list_base.o  dlg_list_grid.o
dlg_list_pointcloud.o  dlg_list_shapes.o dlg_list_table.o
dlg_list_tin.o dlg_parameters.o  dlg_table.o dlg_text.o helper.o  info.o
info_messages.o  parameters_control.o parameters_properties.o  project.o
res_commands.o  res_controls.o res_dialogs.o  res_images.o saga.o
saga_frame.o  saga_frame_droptarget.o view_base.o  view_histogram.o
view_layout.o  view_layout_control.o view_layout_info.o
view_layout_printout.o view_map.o  view_map_3d.o view_map_3d_image.o
view_map_control.o view_ruler.o  view_scatterplot.o view_table.o
view_table_control.o view_table_diagram.o  wksp.o wksp_base_control.o
wksp_base_item.o wksp_base_manager.o  wksp_data_control.o
wksp_data_item.o  wksp_data_layers.o wksp_data_manager.o
wksp_data_menu_file.o wksp_data_menu_files.o  wksp_grid.o
wksp_grid_manager.o  wksp_grid_system.o wksp_layer.o
wksp_layer_classify.o wksp_layer_legend.o  wksp_map.o wksp_map_buttons.o
 wksp_map_control.o wksp_map_dc.o  wksp_map_layer.o wksp_map_manager.o
wksp_module.o wksp_module_control.o  wksp_module_library.o
wksp_module_manager.o  wksp_module_menu.o wksp_pointcloud.o
wksp_pointcloud_manager.o wksp_shapes.o  wksp_shapes_edit.o
wksp_shapes_line.o  wksp_shapes_manager.o wksp_shapes_point.o
wksp_shapes_points.o wksp_shapes_polygon.o  wksp_shapes_type.o
wksp_table.o  wksp_table_manager.o wksp_tin.o  wksp_tin_manager.o
../saga_api/libsaga_api.la ../saga_odbc/libsaga_odbc.la
libtool: link: g++46 -fPIC -D_SAGA_LINUX -D_TYPEDEF_BYTE -D_TYPEDEF_WORD
-D_SAGA_DONOTUSE_HARU -DMODULE_LIBRARY_PATH=\/usr/local/lib/saga\
-DSHARE_PATH=\/usr/local/share/saga\ -I.. -I.
-I/usr/local/lib/wx/include/gtk2-unicode-2.9 -I/usr/local/include/wx-2.9
-D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -D_THREAD_SAFE
-D_SAGA_UNICODE -fopenmp -O2 -pipe -I/usr/local/include
-Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -std=gnu++0x
-Wl,-rpath=/usr/local/lib/gcc46 -fPIC -pthread -pthread
-Wl,-rpath=/usr/local/lib/gcc46 -o .libs/saga_gui active.o
active_attributes.o active_description.o active_history.o
active_HTMLExtraInfo.o active_legend.o active_parameters.o callback.o
data_source.o data_source_files.o data_source_odbc.o dc_helper.o
dlg_about.o dlg_about_logo.o dlg_base.o dlg_colors.o
dlg_colors_control.o dlg_list_base.o dlg_list_grid.o
dlg_list_pointcloud.o dlg_list_shapes.o

r259031 breaks build on CURRENT

[Rainer Hurling]

I just tried to build head (r259037) and it stops with the following
messages. This is on amd64 with systems clang. Please let me know, if I
should provide more info, thanks.


[..snip..]
=== usb/run (all)
cc  -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/RHURLIN/opt_global.h -I. -I@ -I@/contrib/altq
-fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-I/usr/obj/usr/src/sys/RHURLIN  -mno-aes -mno-avx -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs
-fdiagnostics-show-option  -Wno-error-tautological-compare
-Wno-error-empty-body  -Wno-error-parentheses-equality  -c
/usr/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c
/usr/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:3233:6:
error: invalid application of 'sizeof' to an
  incomplete type 'struct rt2870_txwi'
sizeof(struct rt2870_txwi)), rt2860_rates[ridx].rate, qid);
^ 
@/dev/usb/usb_debug.h:41:21: note: expanded from macro 'DPRINTFN'
   __FUNCTION__ ,##__VA_ARGS__);\
   ^
/usr/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:3233:20:
note: forward declaration of
  'struct rt2870_txwi'
sizeof(struct rt2870_txwi)), rt2860_rates[ridx].rate, qid);
  ^
@/dev/usb/usb_debug.h:41:21: note: expanded from macro 'DPRINTFN'
   __FUNCTION__ ,##__VA_ARGS__);\
   ^
1 error generated.
*** Error code 1
Stop.
make[5]: stopped in /usr/src/sys/modules/usb/run
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: fdescfs mount causes hard lock

[Rainer Hurling]

Am 05.08.2011 10:33 (UTC+1) schrieb Ian FREISLICH:

Hi

Since CURRENT Aug 2, my machine has hardlocked at boot time on
Mounting local filesystems.  I traced it this morning to

fdesc  /dev/fd fdescfs rw  0   0

Not mounting this stopped the hardlock.  I added it because one
installed port requeried it, but I can't remember which port that
was.


I am observing the same since 02/08/2011. Without mounting fdescfs the 
system does not freeze anymore.


The reason for using fdescfs was java/openjdk, if I remember right.

Rainer Hurling


Is this related to the panic recently reported by David Wolfskill?

Ian

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

After r22561[78] some kmods do not build any more

[Rainer Hurling]

Upgrading 9.0-BETA2 last night after r22561[78] was committed brings me 
trouble with at least to kmods from ports. They do not load anymore and 
also I am not able the build them:



/usr/ports/print/acroreadwrapper#make
===  Vulnerability check disabled, database not found
===  License check disabled, port has not defined LICENSE
===  Extracting for acroreadwrapper-0.0.20110529
= SHA256 Checksum OK for linux_adobe_kmod-20110529.tar.gz.
===  Patching for acroreadwrapper-0.0.20110529
===  Configuring for acroreadwrapper-0.0.20110529
===  Building for acroreadwrapper-0.0.20110529
Warning: Object directory not changed from original 
/usr/ports/print/acroreadwrapper/work/linux_adobe_kmod-20110529

@ - /usr/src/sys
machine - /usr/src/sys/amd64/include
x86 - /usr/src/sys/x86/include
cc -O2 -fno-strict-aliasing -pipe -msse3 -DCOMPAT_FREEBSD32 
-DCOMPAT_LINUX32 -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -I. -I@ 
-I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000 -fno-common  -fno-omit-frame-pointer 
 -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector 
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option -c 
linux_adobe.c

cc1: warnings being treated as errors
linux_adobe.c: In function 'linux_adobe_linux_sched_setscheduler':
linux_adobe.c:88: warning: implicit declaration of function 
'sched_setscheduler'
linux_adobe.c:88: warning: nested extern declaration of 
'sched_setscheduler' [-Wnested-externs]

*** Error code 1
Stop in /usr/ports/print/acroreadwrapper/work/linux_adobe_kmod-20110529.
*** Error code 1
Stop in /usr/ports/print/acroreadwrapper.



/usr/ports/emulators/rtc#make
===  Vulnerability check disabled, database not found
===  License check disabled, port has not defined LICENSE
===  Extracting for rtc-2004.02.24.1_8
===  Patching for rtc-2004.02.24.1_8
===  Configuring for rtc-2004.02.24.1_8
===  Building for rtc-2004.02.24.1_8
/usr/share/mk/bsd.compat.mk, line 35: warning: NOMAN is deprecated in 
favour of NO_MAN
/sys/conf/kmod.mk, line 268: warning: duplicate script for target @ 
ignored

@ - /sys
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h
Warning: Object directory not changed from original 
/usr/ports/emulators/rtc/work/files

machine - /usr/src/sys/amd64/include
x86 - /usr/src/sys/x86/include
cc -O2 -fno-strict-aliasing -pipe -msse3 -DCDEV_MAJOR_=202 -Werror 
-D_KERNEL -DKLD_MODULE -nostdinc  -I/usr/ports/emulators/rtc/work/files 
-I/sys -I. -I@ -I@/contrib/altq -finline-limit=8000 --param 
inline-unit-growth=100 --param large-function-growth=1000 -fno-common 
-fno-omit-frame-pointer  -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx 
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding 
-fstack-protector -std=iso9899:1999 -fstack-protector -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs 
-fdiagnostics-show-option -c rtc.c
cc -O2 -fno-strict-aliasing -pipe -msse3 -DCDEV_MAJOR_=202 -Werror 
-D_KERNEL -DKLD_MODULE -nostdinc  -I/usr/ports/emulators/rtc/work/files 
-I/sys -I. -I@ -I@/contrib/altq -finline-limit=8000 --param 
inline-unit-growth=100 --param large-function-growth=1000 -fno-common 
-fno-omit-frame-pointer  -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx 
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding 
-fstack-protector -std=iso9899:1999 -fstack-protector -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs 
-fdiagnostics-show-option -c rtc_linux.c

cc1: warnings being treated as errors
rtc_linux.c: In function 'linux_ioctl_rtc':
rtc_linux.c:74: warning: implicit declaration of function 'ioctl'
rtc_linux.c:74: warning: nested extern declaration of 'ioctl' 
[-Wnested-externs]

*** Error code 1
Stop in /usr/ports/emulators/rtc/work/files.
*** Error code 1
Stop in /usr/ports/emulators/rtc.


Am I doing something wrong or is this intended and some ports need 
adaptions?


Thanks in advance,
Rainer Hurling
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: After r22561[78] some kmods do not build any more

[Rainer Hurling]

On 17.09.2011 14:30 (UTC+1), K. Macy wrote:

This is a side effect of the syscall namespace disambiguation. I will
send patches to the ports maintainers.


Ok, so my first thought was right ;-)

I just tested your patch for emulators/rtc, offered on #bsdports. It 
builds fine and seems to work.


Thanks a lot for responding so fast.


Thanks

On Sat, Sep 17, 2011 at 10:29 AM, Rainer Hurlingrhur...@gwdg.de  wrote:

Upgrading 9.0-BETA2 last night after r22561[78] was committed brings me
trouble with at least to kmods from ports. They do not load anymore and also
I am not able the build them:


/usr/ports/print/acroreadwrapper#make
===Vulnerability check disabled, database not found
===License check disabled, port has not defined LICENSE
===Extracting for acroreadwrapper-0.0.20110529
=  SHA256 Checksum OK for linux_adobe_kmod-20110529.tar.gz.
===Patching for acroreadwrapper-0.0.20110529
===Configuring for acroreadwrapper-0.0.20110529
===Building for acroreadwrapper-0.0.20110529
Warning: Object directory not changed from original
/usr/ports/print/acroreadwrapper/work/linux_adobe_kmod-20110529
@ -  /usr/src/sys
machine -  /usr/src/sys/amd64/include
x86 -  /usr/src/sys/x86/include
cc -O2 -fno-strict-aliasing -pipe -msse3 -DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32
-Werror -D_KERNEL -DKLD_MODULE -nostdinc   -I. -I@ -I@/contrib/altq
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common  -fno-omit-frame-pointer  -mno-sse
-mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
  -Wmissing-include-dirs -fdiagnostics-show-option -c linux_adobe.c
cc1: warnings being treated as errors
linux_adobe.c: In function 'linux_adobe_linux_sched_setscheduler':
linux_adobe.c:88: warning: implicit declaration of function
'sched_setscheduler'
linux_adobe.c:88: warning: nested extern declaration of 'sched_setscheduler'
[-Wnested-externs]
*** Error code 1
Stop in /usr/ports/print/acroreadwrapper/work/linux_adobe_kmod-20110529.
*** Error code 1
Stop in /usr/ports/print/acroreadwrapper.



/usr/ports/emulators/rtc#make
===Vulnerability check disabled, database not found
===License check disabled, port has not defined LICENSE
===Extracting for rtc-2004.02.24.1_8
===Patching for rtc-2004.02.24.1_8
===Configuring for rtc-2004.02.24.1_8
===Building for rtc-2004.02.24.1_8
/usr/share/mk/bsd.compat.mk, line 35: warning: NOMAN is deprecated in
favour of NO_MAN
/sys/conf/kmod.mk, line 268: warning: duplicate script for target @
ignored
@ -  /sys
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h
Warning: Object directory not changed from original
/usr/ports/emulators/rtc/work/files
machine -  /usr/src/sys/amd64/include
x86 -  /usr/src/sys/x86/include
cc -O2 -fno-strict-aliasing -pipe -msse3 -DCDEV_MAJOR_=202 -Werror -D_KERNEL
-DKLD_MODULE -nostdinc  -I/usr/ports/emulators/rtc/work/files -I/sys -I. -I@
-I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common -fno-omit-frame-pointer  -mno-sse
-mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
  -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
  -Wmissing-include-dirs -fdiagnostics-show-option -c rtc.c
cc -O2 -fno-strict-aliasing -pipe -msse3 -DCDEV_MAJOR_=202 -Werror -D_KERNEL
-DKLD_MODULE -nostdinc  -I/usr/ports/emulators/rtc/work/files -I/sys -I. -I@
-I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common -fno-omit-frame-pointer  -mno-sse
-mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
  -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
  -Wmissing-include-dirs -fdiagnostics-show-option -c rtc_linux.c
cc1: warnings being treated as errors
rtc_linux.c: In function 'linux_ioctl_rtc':
rtc_linux.c:74: warning: implicit declaration of function 'ioctl'
rtc_linux.c:74: warning: nested extern declaration of 'ioctl'
[-Wnested-externs]
*** Error code 1
Stop in /usr/ports/emulators/rtc/work/files.
*** Error code 1
Stop in /usr/ports/emulators/rtc.


Am I doing something wrong or is this intended and some ports need
adaptions?

Thanks in advance,
Rainer Hurling

___
freebsd

Re: After r22561[78] some kmods do not build any more

[Rainer Hurling]

On 17.09.2011 15:08 (UTC+1), Rainer Hurling wrote:

On 17.09.2011 14:30 (UTC+1), K. Macy wrote:

This is a side effect of the syscall namespace disambiguation. I will
send patches to the ports maintainers.


Ok, so my first thought was right ;-)

I just tested your patch for emulators/rtc, offered on #bsdports. It
builds fine and seems to work.


Same with your second patch on http://pastebin.com/1vx8RMVn for 
print/acroreadwrapper. It also works :-)


BTW, I just recognized, that there is a PR open for it:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/160769

I CC'd Conrad J. Sabatier as its author.


Thanks a lot for responding so fast.


Thanks

On Sat, Sep 17, 2011 at 10:29 AM, Rainer Hurlingrhur...@gwdg.de wrote:

Upgrading 9.0-BETA2 last night after r22561[78] was committed brings me
trouble with at least to kmods from ports. They do not load anymore
and also
I am not able the build them:


/usr/ports/print/acroreadwrapper#make
=== Vulnerability check disabled, database not found
=== License check disabled, port has not defined LICENSE
=== Extracting for acroreadwrapper-0.0.20110529
= SHA256 Checksum OK for linux_adobe_kmod-20110529.tar.gz.
=== Patching for acroreadwrapper-0.0.20110529
=== Configuring for acroreadwrapper-0.0.20110529
=== Building for acroreadwrapper-0.0.20110529
Warning: Object directory not changed from original
/usr/ports/print/acroreadwrapper/work/linux_adobe_kmod-20110529
@ - /usr/src/sys
machine - /usr/src/sys/amd64/include
x86 - /usr/src/sys/x86/include
cc -O2 -fno-strict-aliasing -pipe -msse3 -DCOMPAT_FREEBSD32
-DCOMPAT_LINUX32
-Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mno-sse
-mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs -fdiagnostics-show-option -c linux_adobe.c
cc1: warnings being treated as errors
linux_adobe.c: In function 'linux_adobe_linux_sched_setscheduler':
linux_adobe.c:88: warning: implicit declaration of function
'sched_setscheduler'
linux_adobe.c:88: warning: nested extern declaration of
'sched_setscheduler'
[-Wnested-externs]
*** Error code 1
Stop in /usr/ports/print/acroreadwrapper/work/linux_adobe_kmod-20110529.
*** Error code 1
Stop in /usr/ports/print/acroreadwrapper.



/usr/ports/emulators/rtc#make
=== Vulnerability check disabled, database not found
=== License check disabled, port has not defined LICENSE
=== Extracting for rtc-2004.02.24.1_8
=== Patching for rtc-2004.02.24.1_8
=== Configuring for rtc-2004.02.24.1_8
=== Building for rtc-2004.02.24.1_8
/usr/share/mk/bsd.compat.mk, line 35: warning: NOMAN is deprecated in
favour of NO_MAN
/sys/conf/kmod.mk, line 268: warning: duplicate script for target @
ignored
@ - /sys
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h
Warning: Object directory not changed from original
/usr/ports/emulators/rtc/work/files
machine - /usr/src/sys/amd64/include
x86 - /usr/src/sys/x86/include
cc -O2 -fno-strict-aliasing -pipe -msse3 -DCDEV_MAJOR_=202 -Werror
-D_KERNEL
-DKLD_MODULE -nostdinc -I/usr/ports/emulators/rtc/work/files -I/sys
-I. -I@
-I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100
--param
large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mno-sse
-mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs -fdiagnostics-show-option -c rtc.c
cc -O2 -fno-strict-aliasing -pipe -msse3 -DCDEV_MAJOR_=202 -Werror
-D_KERNEL
-DKLD_MODULE -nostdinc -I/usr/ports/emulators/rtc/work/files -I/sys
-I. -I@
-I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100
--param
large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mno-sse
-mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs -fdiagnostics-show-option -c rtc_linux.c
cc1: warnings being treated as errors
rtc_linux.c: In function 'linux_ioctl_rtc':
rtc_linux.c:74: warning: implicit declaration of function 'ioctl'
rtc_linux.c:74: warning: nested extern declaration of 'ioctl'
[-Wnested-externs]
*** Error code 1
Stop in /usr/ports

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 09.07.2012 01:36 (UTC+2), Steve Kargl wrote:

On Sun, Jul 08, 2012 at 11:51:56AM -0600, Warner Losh wrote:


On Jul 8, 2012, at 6:40 AM, David Schultz wrote:


On Tue, May 29, 2012, Peter Jeremy wrote:

On 2012-May-28 15:54:06 -0700, Steve Kargl s...@troutmask.apl.washington.edu 
wrote:

Given that cephes was written years before C99 was even
conceived, I suspect all functions are sub-standard.


Well, most of cephes was written before C99.  The C99 parts of
cephes were written to turn it into a complete C99 implementation.


I'm a bit late to the party, but I thought I'd chime in with some
context.  We did consider using Cephes years ago, and even got
permission from the author to release it under an acceptable license.
We later decided not to use it for technical reasons.

By the way, virtually none of the people who have complained about the
missing functions actually need them.  Mostly they just want to
compile some software that was written by a naive programmer who
thought it would be cool to use the most precise type available.  The
complex functions are even less commonly needed, and the truth is that
they have no business being part of the C standard anyway.

The question remains of what to do about the missing functions.  Bruce
and Steve have been working on expl and logl for years.  If those ever
get in the tree, the remaining long double functions are easy.  Those
functions are basically done, modulo a bunch of cleanup and testing,
and I encourage any mathematically inclined folks who are interested
in pushing things along to get in touch with them.  I'm not going to
have any time myself for a few months at least.


Where can I find these?


I've posted expl() a few times for the ld80 version.
I don't have an ld128 version, which is why I have
yet to submit a formal patch for expl().  I also
have an ld80 expm1l().  I have a copy of bde's ld80
logl().  IIRC, bde wrote an ld128, but I don't have
nor do I know if it has been tested.


Do you think your version from 
http://www.freebsd.org/cgi/query-pr.cgi?pr=152415 for expl() ld80 
version could be the one getting into head? Would you be willing to 
commit it?


As far as I understand from discussions on R mailing list 
(r-de...@r-project.org), they plan to reduce the emulation and/or 
workaround of long and complex math functions for FreeBSD and other 
systems with their next releases of R devel. So we could really need 
some progress with our C99 conform math functions ;-)



Lastly, there's the question of mediocre alternatives, such as
solutions that get the boundary cases wrong or don't handle 128-bit
floating point.  For the exponential and logarithmic functions, Bruce
and Steve have already written good implementations, so there's no
reason to settle for less.  As for the other long double functions,
bringing in some Cephes code in a separate directory as a temporary
fix might be the way to go.  I don't like that solution, and Steve
raises some good technical points about why it isn't ideal; however, a
better solution is more than a decade overdue, and people are
justified in finding that unacceptable.


Don't let the perfect be the enemy of the good.  It is better to
have OK implementations of these functions than none at all.


You'll need to define OK, because some of the implementations
I've read are poor.  I also hope that before anything is
committed to libm that the person doing the committing does
some rather thorough testing of the code.


We originally had so-so double support, but bruce spent many
years optimizing them to make them very good.  If we were
just starting out, and hadn't let 10 years get behind us, I'd
give the substandard argument some weight.  But now that we're
13 years down the line from c99's publication I think we need
to relax our standards a bit.  I'd even argue that these
functions being a little bad could easily spur people to make
them better.  Their absence makes people just
#define llexp(x) lexp(x), etc. :(


Of course, the converse argument is that people have had 10 years
to learn enough about floating point to actually write and submit
code.  I knew very little about FP before I wrote sqrtl().  I had
a need for sqrtl() and so I went looking for a solution.

PS: I also wrote sincos[fl](), which is very handy for the
complex trig functions.





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

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 10.07.2012 16:02 (UTC+2), Warner Losh wrote:


On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote:

As far as I understand from discussions on R mailing list 
(r-de...@r-project.org), they plan to reduce the emulation and/or workaround of 
long and complex math functions for FreeBSD and other systems with their next 
releases of R devel. So we could really need some progress with our C99 conform 
math functions ;-)


Not having R would be a bit pain in my backside.  That's one of the practical 
considerations that I was talking about.  It is very real, and if I have to, 
I'll commit the #define junk I railed against to get it back.  Please, let's 
get some progress.  I have some time to help.


Yes, thank you Warner, that is also my problem. As I wrote some weeks 
ago (05/28/2012) when starting this thread, I am using FreeBSD as a 
scientific desktop because of its good scaling properties. For some 
years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL and 
some more.


If I would not be able to run upcoming versions of R on FreeBSD any 
more, that would be really, really hard :-(


Rainer


Warner



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

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 10.07.2012 17:11 (UTC+2), David Schultz wrote:

On Tue, Jul 10, 2012, Rainer Hurling wrote:

On 10.07.2012 16:02 (UTC+2), Warner Losh wrote:


On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote:

As far as I understand from discussions on R mailing list
(r-de...@r-project.org), they plan to reduce the emulation and/or
workaround of long and complex math functions for FreeBSD and other
systems with their next releases of R devel. So we could really need some
progress with our C99 conform math functions ;-)


Not having R would be a bit pain in my backside.  That's one of the
practical considerations that I was talking about.  It is very real, and
if I have to, I'll commit the #define junk I railed against to get it
back.  Please, let's get some progress.  I have some time to help.


Yes, thank you Warner, that is also my problem. As I wrote some weeks
ago (05/28/2012) when starting this thread, I am using FreeBSD as a
scientific desktop because of its good scaling properties. For some
years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL and
some more.

If I would not be able to run upcoming versions of R on FreeBSD any
more, that would be really, really hard :-(


Do you have a list of the essential functions here?  There are 17 long
double functions and some complex functions missing, but only a
handful of those are of general interest.  The reason I ask is that if
R is just looking for a few missing functions that are already mostly
implemented, then the best solution is probably to finish that work.
But if it's expecting us to have something arcane like long double
Bessel functions of the first kind, then we need to pursue a workaround
in the short term.



That is, what I found by grepping the sources of a recent R development 
version:


expl:   src/nmath/pnchisq.c

log10l: src/extra/trio/trio.c

log1pl: src/nmath/pnbeta.c

logl:   src/nmath/dnbeta.c
src/nmath/pnbeta.c

powl:   src/extra/trio/triostr.c
src/extra/trio/trio.c
src/main/format.c


In the R NEWS file I found the following three entries about C99 
(complex) functions:


NEWS:l2044
The C99 functions acosh, asinh, atanh, snprintf and vsnprintf are
now required.

NEWS:l3032
The C99 double complex type is now required.
The C99 complex trigonometric functions (such as csin) are not
currently required (FreeBSD lacks most of them): substitutes are
used if they are missing.

NEWS:l3277
Complex arithmetic (notably z^n for complex z and integer n) gave
incorrect results since R 2.10.0 on platforms without C99 complex
support.  This and some lesser issues in trigonometric functions
have been corrected.
Such platforms were rare (we know of Cygwin and FreeBSD).
However, because of new compiler optimizations in the way complex
arguments are handled, the same code was selected on x86_64 Linux
with gcc 4.5.x at the default -O2 optimization (but not at -O).


From the discussions on the R-devel mailing list we could expect, that 
there will be more complex (long, longlong) functions introduced in the 
near future. (But it is very likely that b.f. does know much more about 
this.)


Rainer


BTW: There seems to be a discrepancy about missing functions listed in
http://wiki.freebsd.org/MissingMathStuff and in
http://svnweb.freebsd.org/base/head/lib/msun/src/math.h?r1=227472r2=236148pathrev=236148. 
So the wiki is a bit outdated now?

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

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 11.07.2012 00:58 (UTC+2), David Schultz wrote:

On Tue, Jul 10, 2012, Rainer Hurling wrote:

On 10.07.2012 17:11 (UTC+2), David Schultz wrote:

On Tue, Jul 10, 2012, Rainer Hurling wrote:

On 10.07.2012 16:02 (UTC+2), Warner Losh wrote:


On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote:

As far as I understand from discussions on R mailing list
(r-de...@r-project.org), they plan to reduce the emulation and/or
workaround of long and complex math functions for FreeBSD and other
systems with their next releases of R devel. So we could really need
some
progress with our C99 conform math functions ;-)


Not having R would be a bit pain in my backside.  That's one of the
practical considerations that I was talking about.  It is very real, and
if I have to, I'll commit the #define junk I railed against to get it
back.  Please, let's get some progress.  I have some time to help.


Yes, thank you Warner, that is also my problem. As I wrote some weeks
ago (05/28/2012) when starting this thread, I am using FreeBSD as a
scientific desktop because of its good scaling properties. For some
years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL and
some more.

If I would not be able to run upcoming versions of R on FreeBSD any
more, that would be really, really hard :-(


Do you have a list of the essential functions here?  There are 17 long
double functions and some complex functions missing, but only a
handful of those are of general interest.  The reason I ask is that if
R is just looking for a few missing functions that are already mostly
implemented, then the best solution is probably to finish that work.
But if it's expecting us to have something arcane like long double
Bessel functions of the first kind, then we need to pursue a workaround
in the short term.



That is, what I found by grepping the sources of a recent R development
version:

expl:   src/nmath/pnchisq.c


Many thanks to you three for implementing expl() with r238722 and r238724.

I am not a C programmer, but would like to ask if the following example 
is correct and suituable as a minimalistic test of this new C99 function?



//---
#include stdio.h
#include math.h

int main(void)
{
  double c = 2.0;
  long double d = 2.0;

  double e = exp(c);
  long double f = expl(d);

  printf(exp(%f)  is %.*f\n,  c, 90, e);
  printf(expl(%Lf) is %.*Lf\n, d, 90, f);

  return 0;
}
//---


Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards 
it gives me:


exp(2.00)  is 
7.38905609893065040694182243896648287773132324218750
expl(2.00) is 
7.38905609893065022739794267536694860609713941812515258789062500



Already the sixteenth position after decimal point differs.

Please forgive me, if this is a really stupid approach for producing 
some expl() output.


uname -a: FreeBSD xxx.xxx.xxx 10.0-CURRENT FreeBSD 10.0-CURRENT #0 
r238740: Tue Jul 24 18:08:13 CEST 2012 
x...@xxx.xxx.xxx:/usr/obj/usr/src/sys/XXX  amd64


Rainer



logl:   src/nmath/dnbeta.c
 src/nmath/pnbeta.c


Bruce has versions of these that could be committed with some cleanup.
It's a matter of sorting through about 1200 emails from him and 3
source trees to find the most up-to-date patches, then cleaning them
up and testing and committing them.  I have no time right now, but I
will do at least the first step as soon as I can, and try to get the
patches to someone willing to do the final few steps.


log10l: src/extra/trio/trio.c

log1pl: src/nmath/pnbeta.c


If Bruce doesn't already have implementations of these, they are easy
wrappers around logl() or some internal k_logl in Bruce's implementation.


powl:   src/extra/trio/triostr.c
 src/extra/trio/trio.c
 src/main/format.c


It's hard to do a good job on powl(), but the simple approach
(exp(log(x)*y)) plus a few special cases may suffice for many uses.


NEWS:l2044
The C99 functions acosh, asinh, atanh, snprintf and vsnprintf are
now required.


We have had them forever.


NEWS:l3032
The C99 double complex type is now required.
The C99 complex trigonometric functions (such as csin) are not
currently required (FreeBSD lacks most of them): substitutes are
used if they are missing.


We have these (but not the inverse trig functions).


NEWS:l3277
Complex arithmetic (notably z^n for complex z and integer n) gave
incorrect results since R 2.10.0 on platforms without C99 complex
support.  This and some lesser issues in trigonometric functions
have been corrected.
Such platforms were rare (we know of Cygwin and FreeBSD).
However, because of new compiler optimizations in the way complex
arguments are handled, the same code was selected on x86_64 Linux
with gcc 4.5.x at the default -O2 optimization (but not at -O).


Not sure if this is relevant.


BTW: There seems to be a discrepancy about missing functions listed in
http://wiki.freebsd.org/MissingMathStuff

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 25.07.2012 19:00 (UTC+2), Steve Kargl wrote:

On Wed, Jul 25, 2012 at 06:29:18PM +0200, Rainer Hurling wrote:


Many thanks to you three for implementing expl() with r238722 and r238724.

I am not a C programmer, but would like to ask if the following example
is correct and suituable as a minimalistic test of this new C99 function?



It's not clear to me what you mean by test.  If expl() is
not available in libm, then linking the code would fail.
So, testing for the existence of expl() (for example,
in a configure script) is as simple as


Sorry for not being clear enough. I didn't mean testing for the 
existence, but for some comparable output between exp() and expl(), on a 
system with expl() available in libm.



#include math.h
long double
func(long double x)
{
   return (expl(x));
}


//---
#include stdio.h
#include math.h

int main(void)
{
   double c = 2.0;
   long double d = 2.0;

   double e = exp(c);
   long double f = expl(d);

   printf(exp(%f)  is %.*f\n,  c, 90, e);
   printf(expl(%Lf) is %.*Lf\n, d, 90, f);


If you mean testing that the output is correct, then
asking for 90 digits is of little use.  The following
is sufficient (and my actually produce a digit or two
more than is available in number)


Ok, I understand. I printed the 90 digits to be able to take a look at 
the decimal places, I did not expect to get valid digits in this area.



troutmask:fvwm:kargl[203] diff -u a.c.orig a.c
--- a.c.orig2012-07-25 09:38:31.0 -0700
+++ a.c 2012-07-25 09:40:36.0 -0700
@@ -1,5 +1,6 @@
  #include stdio.h
  #include math.h
+#include float.h

  int main(void)
  {
@@ -9,8 +10,8 @@
double e = exp(c);
long double f = expl(d);

-  printf(exp(%f)  is %.*f\n,  c, 90, e);
-  printf(expl(%Lf) is %.*Lf\n, d, 90, f);
+  printf(exp(%f)  is %.*f\n,  c, DBL_DIG+2, e);
+  printf(expl(%Lf) is %.*Lf\n, d, LDBL_DIG+2, f);

return 0;
  }


Thanks, I was not aware of DBL_DIG and LDBL_DIG.


   return 0;
}
//---

Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards
it gives me:

exp(2.00)  is
7.38905609893065040
expl(2.00) is
7.38905609893065022739

Already the sixteenth position after decimal point differs.


DBL_DIG is 15 on x86 hardware and LDBL_DIG is 18.  You can
expect at most 15 correct digits from exp().


Please forgive me, if this is a really stupid approach for producing
some expl() output.


If you actually want to test expl() to see if it is producing
a decent result, you need a reference solution that contains
a higher precision.  I use mpfr with 256 bits of precision.

troutmask:fvwm:kargl[213] ./testl -V 2
ULP = 0.3863
   x = 2.00e+00
libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2
mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2
mpfr: 7.3890560989306502272304274605750078131803155705518\
   47324087127822522573796079054e+00
mpfr: 0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0

The 1st 'mpfr:' line is produced after converting the results
fof mpfr_exp() to long double.  The 2nd 'mpfr:' line is
produced by mpfr_printf() where the number of printed
digits depends on the 256-bit precision.  The last 'mpfr:'
line is mpfr_printf()'s hex formatting.  Unfortunately, it
does not normalize the hex representation to start with
'0x1.', which makes comparison somewhat difficult.



Many thanks also for this mpfr example. This helps me to understand a 
little bit more what is going here. So on amd64 even the expl() result 
is far from what mpfr provides.

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

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

Am 26.07.2012 03:52 (UTC+1) schrieb Bruce Evans:

On Wed, 25 Jul 2012, Rainer Hurling wrote:


On 25.07.2012 19:00 (UTC+2), Steve Kargl wrote:

On Wed, Jul 25, 2012 at 06:29:18PM +0200, Rainer Hurling wrote:


Many thanks to you three for implementing expl() with r238722 and
r238724.

I am not a C programmer, but would like to ask if the following example
is correct and suituable as a minimalistic test of this new C99
function?


It's not clear to me what you mean by test.  If expl() is
not available in libm, then linking the code would fail.
So, testing for the existence of expl() (for example,
in a configure script) is as simple as


Sorry for not being clear enough. I didn't mean testing for the
existence, but for some comparable output between exp() and expl(), on
a system with expl() available in libm.


This is basically what I do to test exp() (with a few billion cases
automatically generated and compared).  It is not sufficient for
checking expl(), except for consistency.  (It is assumed that expl()
is reasonably accurate.  If it is in fact less accurate than exp(),
this tends to show up in the comparisons.)


Ahh ok, I think I understand it better now.


#include math.h
long double
func(long double x)
{
   return (expl(x));
}


//---
#include stdio.h
#include math.h

int main(void)
{
   double c = 2.0;
   long double d = 2.0;

   double e = exp(c);
   long double f = expl(d);

   printf(exp(%f)  is %.*f\n,  c, 90, e);
   printf(expl(%Lf) is %.*Lf\n, d, 90, f);


If you mean testing that the output is correct, then
asking for 90 digits is of little use.  The following
is sufficient (and my actually produce a digit or two
more than is available in number)


Ok, I understand. I printed the 90 digits to be able to take a look at
the decimal places, I did not expect to get valid digits in this area.


Use binary format (%a) for manual comparison.  Don't print any more
bits than the format has.  This is DBL_MANT_DIG (53) for doubles and
LDLBL_MANT_DIG (64 on x86) for long doubles.  %a format is in nybbles
and tends to group the bits into nybbles badly.  See below on reducing
problems from this.  Decimal format has to print about 3 more digits
than are really meaningful, to allow recovering the original value
uniquely.  For manual comparison, you need to print these extra digits
and manually round or ignore them as appropriate.  The correct number
of extra digits is hard to determine.  For the any, type, it is
DECIMAL_DIG (21) on x86.  The corresponding number of normally-accurate
decimal digits for long doubles is given by LDBL_DIG (18).  For
floats and doubles, this corresponds to FLT_DIG (6) and DBL_DIG (15).
Unfortunately, float.h doesn't define anything corresponding to
DECIMAL_DIG for the smaller types.  21 is a lot of digits and noise
digits take a long time to determine and ignore (its worse on sparc64
where DECIMAL_DIG is 36).  I usually add 2 extra digits to the number
of normally-accurate digits.  This is sloppy.  3 is needed in some
cases, depending on MANT_DIG and the bits in log(2) and/or log(10).


I printed more bits (digits) than the format provides, because I wanted 
to see if and when what the new function would do in this 'outside' 
area. Of course you are right that this has nothing to do with more 
precision and these digits may not be used in subsequent calculations. 
But this really was not my intention here (only curiosity).



troutmask:fvwm:kargl[203] diff -u a.c.orig a.c
--- a.c.orig2012-07-25 09:38:31.0 -0700
+++ a.c 2012-07-25 09:40:36.0 -0700
@@ -1,5 +1,6 @@
  #include stdio.h
  #include math.h
+#include float.h

  int main(void)
  {
@@ -9,8 +10,8 @@
double e = exp(c);
long double f = expl(d);

-  printf(exp(%f)  is %.*f\n,  c, 90, e);
-  printf(expl(%Lf) is %.*Lf\n, d, 90, f);
+  printf(exp(%f)  is %.*f\n,  c, DBL_DIG+2, e);
+  printf(expl(%Lf) is %.*Lf\n, d, LDBL_DIG+2, f);

return 0;
  }


Thanks, I was not aware of DBL_DIG and LDBL_DIG.


Steve is sloppy and adds 2 also :-).  For long doubles, it is clear that
3 are strictly needed, since DECIMAL_DIG is 3 more.


So I better use +3 here?
printf(expl(%Lf) is %.*Lf\n, d, LDBL_DIG+3, f);
  ^^


For most long double functions on i386, you need to switch the rounding
precision to 64 bits around calls to them, and also to do any operations
on the results except printing them.  expl() is one of the few large
functions that does the switch internally.  So the above should work
(since it only prints), but (expl(d) + 0) should round to the default
53-bit precision and this give the same result as exp(d).


Now that this rounding problem is more understandable to me, I am happy 
that in most cases I can use math/R for my calculations ;-)



If you actually want to test expl() to see if it is producing
a decent result, you need a reference solution that contains
a higher precision.  I use mpfr with 256 bits of precision

Re: post SVN r238886 no boot?

[Rainer Hurling]

On 29.07.2012 19:40 (UTC+2), Michael Butler wrote:

Is anyone else having troubles getting -current after SVN r238886 to
boot? In my case, I have an unstoppable stream of pager_something
console messages :-(

imb


Yes, it's the same here. I had to revert to old kernel.

Rainer

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

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[Rainer Hurling]

On 28.12.2011 15:29 (UTC+1), Kostik Belousov wrote:

On Wed, Dec 28, 2011 at 03:10:12PM +0100, O. Hartmann wrote:

Am 12/28/11 14:58, schrieb Kostik Belousov:

On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote:

Hello out here.

I run into a problem since one of the last portupdates and I do not know
whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0
AMD64.

Background:
We use a scientific graphical toolset for planetary research called
ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD
8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a
couple of weeks ago.
On all of my boxes, I do frequently a portupgrade, so I saw binutils got
bumped up and gcc 4.6 is also getting really frequently changed these days.
After a some portupdates within the last weeks, I just decided to
compile ISIS3 again to keep it fresh and on track, but it won't
compile anymore.

On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and
CLANG built) I receive in some subfolders containing sources the
follwoing error:

[...]
 Adding API object [UniqueIOCachingAlgorithm]
 Adding API object [UniversalGroundMap]
 Adding API object [UserInterface]
 Adding API object [VariableLineScanCameraDetectorMap]
 Adding API object [VecFilter]
 Adding API object [WorldMapper]
 Adding API object [iException]
 Adding API object [iString]
 Adding API object [iTime]
   Working on Package [mex] (11:30:15)
 Adding API object [HrscCamera]
/usr/local/bin/ld:
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o):
relocation R_X86_64_32 against `std::bad_exception::~bad_exception()'
can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a:
could not read symbols: Bad value
collect2: ld returned 1 exit status
gmake[5]: *** [plugin] Error 1
cp: libHrscCamera.so: No such file or directory
gmake[4]: *** [install] Error 1

The error is completely clear as it is: the build tries to link static
library libstdc++.so into shared object. This is not supported.


Thanks, Kostik, for the fast response.
The error isn't so clear to me, sorry. I thought libstdc++.a is the
static library and it is taken to be referenced/compiled into a shared

Linked in.


object created by the application I try to compile.

Right, and this is not supported. Code linked into shared object must
be compiled PIC. An .a library usually does not contain objects compiled
by PIC, ld just dutifully reported back.



I'm much more confused now, since I thought the last time I compiled
that piece of software, I never got any error like that. Well, clang
fails with some obscure errors on the code itself and I'm unwilling to
correct them, I'll try the legacy gcc 4.2.1 and will report what's
happening.


It might have worked by accident (because libstdc++.a objects referenced
during the link did not carried unsupported relocations), or, much more
likely, the build system has changed and started doing stupid things.
It must not link static libraries into shared objects.

You should examine why it does this, and fix it. Changing compilers is
just wasting a time.



Hmm, I get a similar error when trying to build lang/gcc46 on recent 
10-CURRENT:



[..snip..]
Making all in include
gmake[4]: Entering directory 
`/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include'

mkdir -p ./x86_64-portbld-freebsd10.0/bits/stdc++.h.gch
/usr/ports/lang/gcc46/work/build/./gcc/xgcc -shared-libgcc 
-B/usr/ports/lang/gcc46/work/build/./gcc -nostdinc++ 
-L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src 
-L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src/.libs 
-B/usr/local/x86_64-portbld-freebsd10.0/bin/ 
-B/usr/local/x86_64-portbld-freebsd10.0/lib/ -isystem 
/usr/local/x86_64-portbld-freebsd10.0/include -isystem 
/usr/local/x86_64-portbld-freebsd10.0/sys-include-x c++-header 
-nostdinc++ -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing 
-I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/x86_64-portbld-freebsd10.0 
-I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include 
-I/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/libsupc++ -O2 
-g -std=gnu++0x 
/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h 
\

-o x86_64-portbld-freebsd10.0/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from 
/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/chrono:38:0,
 from 
/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:100:
/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/ratio:133:31: 
error: macro _Static_assert passed 3 

Re: lang/lua: /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC

[Rainer Hurling]

On 29.12.2011 13:59 (UTC+1), O. Hartmann wrote:

Am 12/29/11 13:34, schrieb Daniel Kalchev:



On 29.12.11 14:19, O. Hartmann wrote:

Am 12/29/11 12:59, schrieb Kostik Belousov:

On Thu, Dec 29, 2011 at 12:19:40PM +0100, O. Hartmann wrote:

[...]
/usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_'
can not be used when making a shared object; recompile with -fPIC
lapi.o: could not read symbols: Bad value
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
*** Error code 1

Stop in /usr/ports/lang/lua/work/lua-5.1.4/src.
*** Error code 1

Stop in /usr/ports/lang/lua/work/lua-5.1.4/src.
*** Error code 1

Stop in /usr/ports/lang/lua/work/lua-5.1.4.
*** Error code 1

Stop in /usr/ports/lang/lua.

===   make failed for lang/lua
===   Aborting update

Terminated
Terminated

This is very strange!

What is strange ? It is exactly the same problem as in the first message
started this thread. You must use -fPIC flag for compiler when compiling
objects that shall be later linked into dso. So, for lua case, -fPIC
must be present on the cc -c command line.

This therefore strange, since this problem with lua occurs on machines,
where I've set CFLAGS= and COPTFLAGS= as in
/usr/share/examples/etc/make.conf and on one box, one box I accidentally
set those flags to CFLAGS+= and COPTFLAGS+= and there it works and
the -fPIC flag is set by the FreeBSD's port framework.

So I guess there is a bug introduced with one of the last Mk-files
updates.



As suggested by the howto for using newer GCC versions,
http://www.freebsd.org/doc/en/articles/custom-gcc/article.html you are
supposed to use CFLAGS+= to add additional compile flags.


Just for the record I'd like to repeat, that the error above mentioned
is also with the legacy FreeBSD's gcc 4.2.X compiler.

As Kostik Belousov made clear in his last posting, the error occurs due
to a missing -fPIC - which is now clear to me.

People not sleeping with their OS, like myself, would simply copy the
make.conf from /usr/share/examples/etc/ and set some additional flags.
Then the problem will occur again. Maybe it would be wise to reflect
this issue by some additional words in make.conf?


As stated earlier, the following fails in /etc/make.conf for lang/lua:

  CFLAGS= -O2 -fno-strict-aliasing -pipe -msse3

The next one works ( += instead of = ) and -fPIC is preserved this way:

  CFLAGS+= -O2 -fno-strict-aliasing -pipe -msse3

Thanks, Kostik and Daniel for clearing this. I think, like Oliver, that 
this should be mentioned in /etc/make.conf or make.conf(5).


Rainer


By the way, -O2 -fno-strict-aliasing -pipe are the default flags, that
are used when CFLAGS is not set by the user.

COPTFLAGS is used only to build the kernel and doing it with non-system
GCC is not likely to be safe.

Daniel



Oliver


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

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[Rainer Hurling]

On 28.12.2011 19:31 (UTC+1), Kostik Belousov wrote:

On Wed, Dec 28, 2011 at 07:21:00PM +0100, O. Hartmann wrote:

Am 12/28/11 19:10, schrieb Ed Schouten:

* Rainer Hurlingrhur...@gwdg.de, 20111228 17:31:

error: macro _Static_assert passed 3 arguments, but takes just 2
In file included from 
/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0:


Hmmm... This seems to apply to my changes. I will look into this
tomorrow. Thanks for the report!




Be aware that the error produced by the linker I mentioned in the
initial post occurs on FreeBSD 10 as well as FreeBSD 9.0.

I already filed a PR about the problem of a non compiling lang/gcc46
today (ports/163672: lang/gcc46: make failed for lang/gcc46). For test
puproses, I rebuild gcc46 on our FreeBSD 9.0 boxes - without any problem.

I guess, the commit r228902 has been done to FreeBSD 10.0 and not 9.0.


Obviously, linker error during the compilation of third-party software
has nothing to do with compiler error occuring when building gcc.

Do people ever read the texts of the messages ?


Kostik, probably you are right. I had read the messages, but there are 
some strange errors with gcc46 on head for two days now, which leaded me 
in the wrong direction. So sorry for erroneously 'hijacking' this thread 
with another problem most certain only existing in head.



I found another trail, which hopefully is more usefull for solving the 
problem Oliver described.


Whe I try to build lang/lua I get this error:

[..snip..]
cc -o liblua.so -O2 -fno-strict-aliasing -pipe -msse3  -Wall 
-DLUA_USE_LINUX   -shared -Wl,-soname=liblua-5.1.so.1 lapi.o lcode.o 
ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o 
lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o 
lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o 
lstrlib.o loadlib.o linit.o
ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o 
llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o 
ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o 
lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o

ranlib liblua.a
cc -o lua  lua.o liblua.a -lm -Wl,-E -lreadline
cc -o luac  luac.o print.o liblua.a -lm -Wl,-E -lreadline
/usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' 
can not be used when making a shared object; recompile with -fPIC

lapi.o: could not read symbols: Bad value
*** Error code 1


It also gives a linker error, almost the same relocation is named. This 
does only happen with option '-msse3' enabled in /etc/make.conf:


CFLAGS= -O2 -fno-strict-aliasing -pipe -msse3

Using CLFAGS without -msse3 (default) works well:

CFLAGS= -O2 -fno-strict-aliasing -pipe


The systems processor, were this happens, is a

CPU: AMD Phenom(tm) II X6 1090T Processor (3214.32-MHz K8-class CPU)
  Origin = AuthenticAMD  Id = 0x100fa0  Family = 10  Model = a 
Stepping = 0

Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT
  Features2=0x802009SSE3,MON,CX16,POPCNT
  AMD 
Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!
  AMD 
Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT

  TSC: P-state invariant, performance statistics

FreeBSD 10-CURRENT (amd64) r228920

In hope of a more belonging posting,
Rainer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Kernel does not build on 10.0-CURRENT (amd64)

[Rainer Hurling]

I am getting the following error when trying to build recent 
10.0-CURRENT kernel (amd64)?


[..snip..]
cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Werror -D_KERNEL 
-DKLD_MODULE -nostdinc  -I. -I/usr/src/sys/modules/ath/../../dev/ath 
-I/usr/src/sys/modules/ath/../../dev/ath/ath_hal 
-DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/obj/usr/src/sys/RHURLIN/opt_global.h -I. -I@ -I@/contrib/altq 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -fno-common  -fno-omit-frame-pointer 
-I/usr/obj/usr/src/sys/RHURLIN  -mno-sse -mcmodel=kernel -mno-red-zone 
-mno-mmx -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding 
-fstack-protector -std=iso9899:1999 -fstack-protector -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs 
-fdiagnostics-show-option-c 
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 
'ath_tx_aggr_comp_aggr':
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct 
ath_tx_status' has no member named 'ts_flags'
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct 
ath_tx_status' has no member named 'ts_ba_low'
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct 
ath_tx_status' has no member named 'ts_ba_high'
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct 
ath_tx_status' has no member named 'ts_tid'
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct 
ath_tx_status' has no member named 'ts_tid'

*** Error code 1
Stop in /usr/src/sys/modules/ath.
*** Error code 1


I observe this behaviour on three boxes. Any help is really appreciated.

Thanks in advance,
Rainer Hurling
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Kernel does not build on 10.0-CURRENT (amd64)

[Rainer Hurling]

On 06.01.2012 18:30 (UTC+1), Adrian Chadd wrote:

i thought I had captured these.

just add

options AH_SUPPORT_AR5416

to your kernel.


Ah, I indeed missed the new option in GENERIC, because I build with 
modified kernel config file.


I commented all wireless network drivers and their options out. But the 
error remains. Is it necessary to have this option uncommented even when 
the driver ath is commented out?


Many thanks for your fast response,
Rainer


Adrian

On 6 January 2012 09:14, Rainer Hurlingrhur...@gwdg.de  wrote:

I am getting the following error when trying to build recent 10.0-CURRENT
kernel (amd64)?

[..snip..]
cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Werror -D_KERNEL
-DKLD_MODULE -nostdinc  -I. -I/usr/src/sys/modules/ath/../../dev/ath
-I/usr/src/sys/modules/ath/../../dev/ath/ath_hal
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/RHURLIN/opt_global.h -I. -I@ -I@/contrib/altq
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common  -fno-omit-frame-pointer
-I/usr/obj/usr/src/sys/RHURLIN  -mno-sse -mcmodel=kernel -mno-red-zone
-mno-mmx -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding
-fstack-protector -std=iso9899:1999 -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign
-fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option-c
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function
'ath_tx_aggr_comp_aggr':
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct
ath_tx_status' has no member named 'ts_flags'
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct
ath_tx_status' has no member named 'ts_ba_low'
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct
ath_tx_status' has no member named 'ts_ba_high'
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct
ath_tx_status' has no member named 'ts_tid'
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct
ath_tx_status' has no member named 'ts_tid'
*** Error code 1
Stop in /usr/src/sys/modules/ath.
*** Error code 1


I observe this behaviour on three boxes. Any help is really appreciated.

Thanks in advance,
Rainer Hurling

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

Re: Kernel does not build on 10.0-CURRENT (amd64)

[Rainer Hurling]

On 06.01.2012 22:42 (UTC+1), Adrian Chadd wrote:

On 6 January 2012 10:19, Rainer Hurlingrhur...@gwdg.de  wrote:


I commented all wireless network drivers and their options out. But the
error remains. Is it necessary to have this option uncommented even when the
driver ath is commented out?


Yes, because of how the wlan/ath modules are built. You need to have
AH_SUPPORT_AR5416 in the kernel config file, as the driver/module
currently doesn't build without it.


I just tested it with AH_SUPPORT_AR5416 enabled (but ath devices 
disabled) and it builds fine.



I'll eventually fix that, but right now I just want to leave that
option in and not hack up the Makefile to define said option.
Otherwise other options (eg enabling 11n, enabling hal debugging, etc)
are completely ignored when building modules.

Same with IEEE80211_SUPPORT_MESH i believe. I should really re-verify that.


Even with IEEE80211_SUPPORT_MESH disabled the kernel builds. So it seems 
this is not necessary to activate.


Thanks again for help and clarifying it,
Rainer


Adrian


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

Re: Kernel does not build on 10.0-CURRENT (amd64)

[Rainer Hurling]

On 06.01.2012 22:49 (UTC+1), Alexander Yerenkow wrote:

2012/1/6 Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org

On 6 January 2012 10:19, Rainer Hurling rhur...@gwdg.de
mailto:rhur...@gwdg.de wrote:

  I commented all wireless network drivers and their options out.
But the
  error remains. Is it necessary to have this option uncommented
even when the
  driver ath is commented out?

Yes, because of how the wlan/ath modules are built. You need to have
AH_SUPPORT_AR5416 in the kernel config file, as the driver/module
currently doesn't build without it.


I'm sorry for intruding in this topic, but it seems to me similar subject;


No problem. I also sometimes have to try for functional configs, before 
kernel build again. Some kind of deps spec could be very useful. And 
also some kind of notification for relevant kernel config changes, 
introduced by updates, would be of help.



Did FreeBSD ever tried to make config variables structured and with
specified dependencies?
To make clear what I mean - is anyone tried to implement some deps spec
file (Or some special Makefile's sections, whatever), so if you
specified feature A in kernel, it can check if you also specified B
(which is required by A)?
In this way config could provide feedback when you trying to build
kernel without needed dependencies, and many peoples could save their
time not compiling non-buildable kernel.


I'll eventually fix that, but right now I just want to leave that
option in and not hack up the Makefile to define said option.
Otherwise other options (eg enabling 11n, enabling hal debugging, etc)
are completely ignored when building modules.

Same with IEEE80211_SUPPORT_MESH i believe. I should really
re-verify that.


Adrian


--
Regards,
Alexander Yerenkow


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

Re: [RFT] Major snd_hda rewrite

[Rainer Hurling]

On 12.01.2012 12:18 (UTC+1), Alexander Motin wrote:

On 01/12/12 12:52, Gary Jennejohn wrote:

On Wed, 11 Jan 2012 21:33:17 +0200
Alexander Motinm...@freebsd.org wrote:

I would like request for testing of my work on further HDA sound driver
improvement.


[big snip]


Patch can be found here:
http://people.freebsd.org/~mav/hda.rewrite.patch

Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
and 8-STABLE branches also.


The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes
in size (mostly the section which deletes all the manufacturer-specific
defines at the top of the file).


That is probably because of $FreeBSD$ macro resolution. Here is version
with present value from 10-CURRENT SVN (sources from CVS or STABLE will
need that patch line modified respectively) and some minor additional
improvements like CODEC ODs and some more sysctls:
http://people.freebsd.org/~mav/hda.rewrite2.patch



I just patched 10.0-CURRENT (amd64) r230009 against hda.rewrite2.patch. 
All went fine so far. My box is now running again with following messages:


hdacc0: NVidia (Unknown) HDA CODEC at cad 0 on hdac0
hdaa0: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc0
pcm0: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0
hdacc1: NVidia (Unknown) HDA CODEC at cad 1 on hdac0
hdaa1: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc1
pcm1: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1
hdacc2: NVidia (Unknown) HDA CODEC at cad 2 on hdac0
hdaa2: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc2
pcm2: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2
hdacc3: NVidia (Unknown) HDA CODEC at cad 3 on hdac0
hdaa3: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc3
pcm3: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3
hdacc4: Realtek ALC892 HDA CODEC at cad 0 on hdac1
hdaa4: Realtek ALC892 HDA CODEC Audio Function Group at nid 1 on hdacc4
pcm4: Realtek ALC892 HDA CODEC PCM (Rear Analog 7.1/2.0) at nid 
20,22,23,21 and 24,26 on hdaa4
pcm5: Realtek ALC892 HDA CODEC PCM (Front Analog) at nid 27 and 25 on 
hdaa4

pcm6: Realtek ALC892 HDA CODEC PCM (Rear Digital) at nid 30 on hdaa4
pcm7: Realtek ALC892 HDA CODEC PCM (Onboard Digital) at nid 17 on hdaa4

I am using pcm4 with 5.1 surround sound and pulseaudio. All seems to 
work fine :-)


The mainboard is an Asus M4A88TD-V EVO/USB3, the graphics card is a 
NVidia GeForce GTS 450. The Realtek ALC892 is regocnized by the driver, 
the NVidia HDMI sound device is not.


I am looking forward to the commit of this patch!



After fixing that per hand I was able to make a kernel with which sound
still works. Here the relevant bits from dmesg:

hdac0:NVidia (Unknown) HDA Controller mem 0xfcffc000-0xfcff irq
18 at device 0.1 on pci1
hdac1:ATI SB600 HDA Controller mem 0xfe024000-0xfe027fff irq 16 at
device 20.2 on pci0
hdacc0:NVidia GT21x HDA CODEC at cad 0 on hdac0
hdaa0:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc0
pcm0:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0
hdacc1:NVidia GT21x HDA CODEC at cad 1 on hdac0
hdaa1:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc1
pcm1:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1
hdacc2:NVidia GT21x HDA CODEC at cad 2 on hdac0
hdaa2:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc2
pcm2:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2
hdacc3:NVidia GT21x HDA CODEC at cad 3 on hdac0
hdaa3:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc3
pcm3:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3
hdacc4:Realtek ALC889A HDA CODEC at cad 0 on hdac1
hdaa4:Realtek ALC889A HDA CODEC Audio Function Group at nid 1 on hdacc4
pcm4:Realtek ALC889A HDA CODEC PCM (Rear Analog 7.1/2.0) at nid
20,22,21,23 and 24,26 on hdaa4
pcm5:Realtek ALC889A HDA CODEC PCM (Front Analog) at nid 27 and 25
on hdaa4
pcm6:Realtek ALC889A HDA CODEC PCM (Rear Digital) at nid 30 and 31
on hdaa4

I particularly like that the messages now show which jack corresponds to
which pcm - makes deciding which jack to use much simpler.


Thank you for the report.



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

Re: HEADS UP: set_rcvar() removed from rc.subr

[Rainer Hurling]

On 14.01.2012 10:05 (UTC+1), Doug Barton wrote:

Howdy,

Per discussion in freebsd-rc@, I have removed set_rcvar() from rc.subr.
The concept of set_rcvar() was nice in theory, but the forks it creates
are a drag on the startup process, which is especially noticeable on
slower systems, such as embedded ones.

I have no plans to MFC this change, so it should only affect users who
are actually on 10-current. If you have scripts in /usr/local/etc/rc.d
(which if you have ports installed you almost certainly do) ...

to make the change by hand, change this:

name=foo
rcvar=`set_rcvar`

to:

name=foo
rcvar=foo_enable

I didn't bump PORTREVISIONs because the change only applies to HEAD. But
all of the ports are updated, so if you can't figure out how to make the
change, just reinstall it.


Doug


Seems that ports-mgmt/tinderbox needs an update like this:

files/patch-etc__rc.d__tinderd

--- etc/rc.d/tinderd.orig   2011-11-20 07:01:09.0 +0100
+++ etc/rc.d/tinderd2012-01-14 16:07:38.0 +0100
@@ -16,7 +16,7 @@
 . /etc/rc.subr

 name=tinderd
-rcvar=`set_rcvar`
+rcvar=tinderd_enable

 # read settings, set default values
 load_rc_config ${name}


Have not checked tinderbox-devel.

BTW, is there any reason not to set 'rcvar=${name}_enable' in all that 
cases?


Rainer Hurling
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: HEADS UP: set_rcvar() removed from rc.subr

[Rainer Hurling]

On 14.01.2012 22:29 (UTC+1), Doug Barton wrote:

On 01/14/2012 07:16, Rainer Hurling wrote:

BTW, is there any reason not to set 'rcvar=${name}_enable' in all that
cases?


http://lists.freebsd.org/pipermail/freebsd-rc/2012-January/002660.html

Also, as I pointed out in my commit message, using the literal value is
a tiny bit faster, and every little bit helps. :)



OK, I understand. Thanks for answering.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: kernel build failure

[Rainer Hurling]

On 15.04.2012 00:01 (UTC+1), AN wrote:



On Fri, 13 Apr 2012, O. Hartmann wrote:


Am 04/13/12 00:21, schrieb AN:

At Thu Apr 12 17:52:05 EDT 2012:

[root@FBSD10 /usr/src]# svn up
Updating '.':
At revision 234196.

Trying to build the kernel I get the following failure:

time make -j8 buildkernel KERNCONF=MYKERNEL

snip

=== zlib (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/MYKERNEL/opt_global.h -I. -I@ -I@/contrib/altq
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer
-I/usr/obj/usr/src/sys/MYKERNEL -mcmodel=kernel -mno-red-zone -mno-mmx
-mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding
-fstack-protector -std=iso9899:1999 -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
-fdiagnostics-show-option -c /usr/src/sys/modules/zlib/../../net/zlib.c
ld -d -warn-common -r -d -o zlib.ko.debug zlib.o
: export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms |
xargs -J% objcopy % zlib.ko.debug
objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols
objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug
zlib.ko
1 error
*** [buildkernel] Error code 2
1 error
*** [buildkernel] Error code 2
1 error

real 8m20.095s
user 12m37.161s
sys 6m59.844s

I tried this 4 times, twice with MYKERNEL and twice with GENERIC. It
failed in the same spot every time. Is anyone else seeing this?

Also, I tried without -j8, and it fails with the following:

cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
-fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys
-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS
-include opt_global.h -fno-common -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000
-fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float -fno-asynchronous-unwind-tables -ffreestanding
-fstack-protector -Werror /usr/src/sys/kern/subr_turnstile.c
cc1: warnings being treated as errors
/usr/src/sys/kern/subr_turnstile.c: In function 'propagate_priority':
/usr/src/sys/kern/subr_turnstile.c:220: warning: implicit declaration of
function 'kdb_backtrace_thread'
/usr/src/sys/kern/subr_turnstile.c:220: warning: nested extern
declaration of 'kdb_backtrace_thread' [-Wnested-externs]
*** [subr_turnstile.o] Error code 1

Stop in /usr/obj/usr/src/sys/MYKERNEL.
*** [buildkernel] Error code 1

Stop in /usr/src.
*** [buildkernel] Error code 1

Stop in /usr/src.

real 5m19.701s
user 4m33.051s
sys 0m51.466s



Here is /etc/make.conf

# cat /etc/make.conf
OVERRIDE_LINUX_BASE_PORT=f10
QT4_OPTIONS= QGTKSTYLE
WITH_OPENSSL_PORT=yes
# added by use.perl 2012-04-04 01:11:13
PERL_VERSION=5.14.2

The kernel previously built without problems with this same
configuration.
___



clang -c -O2 -pipe -pipe -O3 -fno-strict-aliasing -march=native -std=c99
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I.
-I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
-fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone
-mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables
-ffreestanding -fstack-protector -Werror
/usr/src/sys/kern/subr_turnstile.c
/usr/src/sys/kern/subr_turnstile.c:220:4: error: implicit declaration of
function 'kdb_backtrace_thread' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
kdb_backtrace_thread(td);
^
1 error generated.
*** [subr_turnstile.o] Error code 1
1 error
*** [buildkernel] Error code 2
1 error
*** [buildkernel] Error code 2
1 error


I still get this error on one of my boxes. Another, with almost the same
setup and config, build fine!
All systems build with CLANG. They share the same /etc/src.conf and have
the same /etc/make.conf.

Before building kernel/world, I cleanup/delete /usr/obj. But the error
still persists.


Regards,
Oliver




I updated source with svn within the last hour, and rebuilt world and
kernel. When I tried to boot to single-user mode to installworld the
machine panicked and rebooted. I needed to boot kernel.old to get
machine back. Is anyone else seeing a problem with the kernel? It seems
it is still broken for me.


Same problem here with revision 234306. I am not able to boot 

Re: Kernel builds, but crashes at boot (amd64, Revision: 234306)

[Rainer Hurling]

On 16.04.2012 16:55 (UTC+1), Konstantin Belousov wrote:

On Mon, Apr 16, 2012 at 07:35:23AM -0700, matt wrote:

On 04/16/12 01:57, O. Hartmann wrote:

On 04/15/12 12:30, Conrad J. Sabatier wrote:

Today I'm suddenly unable to boot a newly built kernel without crashing
right near the end of the device probes, just before the system is
about to actually come up:

Fatal trap 18: integer divide fault while in kernel mode

Stopped at 0x803b2646 = g_label_ufs_taste_common+0x36
divl 0x50(%rcx),%eax

Backtrace lists this chain of calls:
g_label_ufs_taste_common
g_label_taste
g_new_provider_event
g_run_events
g_event_procbody
fork_exit
fork_trampoline

Whether built with clang or gcc, CUSTOM config or GENERIC, same results
on rebooting.  No idea why this suddenly started happening, haven't
changed anything at all in my setup.

My recent kernel does the same on two FreeBSD 10.0-CURRENT #1 r234309:
Sun Apr 15 14:14:11 CEST 2012 boxes. Both boxes in common is they are
attached to a Dell UltraSharp U2711 screen which does have a built-in
USB/MMC hub. I realized that it was possible to log into my lab's box
from remote when I'm not in the lab and that is usually coincidentally
with a switched off screen.
This morning I loged in from home, loged out and got to the office,
switched on the screen - and reboot! I wasn't able to get the system
running again, it always got stuck in a

Fatal trap 18: integer divide fault while in kernel mode

Unplugging the screen's USB hub makes the system booting again!

Following is one of the last logged messages from the kernel, I don not
know whether this is usefull looking for the problem.

Regards,
Oliver

Apr 12 15:32:33 telesto kernel: hwpmc:
SOFT/16/64/0x67INT,USR,SYS,REA,WRI  TSC/1/64/0x20REA
IAP/4/48/0x3ffINT,USR,SYS,EDG,THR,REA,WRI,INV,QUA,PRC
IAF/3/48/0x61INT,REA,WRI  UCP/8/48/0x3f8EDG,THR,REA,WRI,INV,QUA,PRC
UCF/1/48/0x60REA,WRI
Apr 12 15:32:33 telesto kernel: uhub1: 4 ports with 4 removable, self
powered
Apr 12 15:32:33 telesto kernel: uhub2: 4 ports with 4 removable, self
powered
Apr 12 15:32:33 telesto kernel: uhub3: 2 ports with 2 removable, self
powered
Apr 12 15:32:33 telesto kernel: uhub0: 2 ports with 2 removable, self
powered
Apr 12 15:32:33 telesto kernel: ugen3.2:vendor 0x8087  at usbus3
Apr 12 15:32:33 telesto kernel: uhub4:vendor 0x8087 product 0x0024,
class 9/0, rev 2.00/0.00, addr 2  on usbus3
Apr 12 15:32:33 telesto kernel: ugen0.2:vendor 0x8087  at usbus0
Apr 12 15:32:33 telesto kernel: uhub5:vendor 0x8087 product 0x0024,
class 9/0, rev 2.00/0.00, addr 2  on usbus0
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3 usbus0
Apr 12 15:32:33 telesto kernel: uhub5: 6 ports with 6 removable, self
powered
Apr 12 15:32:33 telesto kernel: uhub4: 8 ports with 8 removable, self
powered
Apr 12 15:32:33 telesto kernel: ugen3.3:Cherry GmbH  at usbus3
Apr 12 15:32:33 telesto kernel: ukbd0:Cherry GmbH wired keyboard,
class 0/0, rev 2.00/1.11, addr 3  on usbus3
Apr 12 15:32:33 telesto kernel: kbd2 at ukbd0
Apr 12 15:32:33 telesto kernel: uhid0:Cherry GmbH wired keyboard,
class 0/0, rev 2.00/1.11, addr 3  on usbus3
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: ugen3.4:vendor 0x0424  at usbus3
Apr 12 15:32:33 telesto kernel: uhub6:vendor 0x0424 product 0x2514,
class 9/0, rev 2.00/0.00, addr 4  on usbus3
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: uhub6: 3 ports with 2 removable, self
powered
Apr 12 15:32:33 telesto kernel: ugen3.5:vendor 0x0424  at usbus3
Apr 12 15:32:33 telesto kernel: uhub7:vendor 0x0424 product 0x2640,
class 9/0, rev 2.00/0.00, addr 5  on usbus3
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: uhub7: 3 ports with 2 removable, self
powered
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: ugen3.6:Generic  at usbus3
Apr 12 15:32:33 telesto kernel: umass0:Generic Ultra Fast Media
Reader, class 0/0, rev 2.00/1.91, addr 6  on usbus3
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: (probe0:umass-sim0:0:0:0): TEST UNIT
READY. CDB: 0 0 0 0 0 0
Apr 12 15:32:33 telesto kernel: (probe0:umass-sim0:0:0:0): CAM status:
SCSI Status Error
Apr 12 15:32:33 telesto kernel: (probe0:umass-sim0:0:0:0): SCSI status:
Check Condition
Apr 12 15:32:33 telesto kernel: (probe0:umass-sim0:0:0:0): SCSI sense:
NOT READY asc:3a,0 (Medium not present)
Apr 12 15:32:33 telesto kernel: da0 at umass-sim0 bus 0 scbus14 target 0
lun 0
Apr 12 15:32:33 telesto kernel: da0:Generic Ultra HS-SD/MMC 1.91
Removable Direct Access SCSI-0 device
Apr 12 15:32:33 telesto kernel: da0: 40.000MB/s transfers
Apr 12 15:32:33 telesto kernel: da0: Attempt to query device size
failed: NOT READY, Medium not present
Apr 12 15:32:33 telesto kernel: ugen3.7:Logitech  at usbus3
Apr 12 15:32:33 telesto kernel: ums0:Logitech USB Laser Mouse, class
0/0, rev 2.00/56.01, 

Re: Kernel builds, but crashes at boot (amd64, Revision: 234306)

[Rainer Hurling]

On 16.04.2012 19:31 (UTC+1), Konstantin Belousov wrote:

On Mon, Apr 16, 2012 at 06:15:32PM +0200, Rainer Hurling wrote:

On 16.04.2012 16:55 (UTC+1), Konstantin Belousov wrote:

On Mon, Apr 16, 2012 at 07:35:23AM -0700, matt wrote:

On 04/16/12 01:57, O. Hartmann wrote:

On 04/15/12 12:30, Conrad J. Sabatier wrote:

Today I'm suddenly unable to boot a newly built kernel without crashing
right near the end of the device probes, just before the system is
about to actually come up:

Fatal trap 18: integer divide fault while in kernel mode

Stopped at 0x803b2646 = g_label_ufs_taste_common+0x36
divl 0x50(%rcx),%eax

Backtrace lists this chain of calls:
g_label_ufs_taste_common
g_label_taste
g_new_provider_event
g_run_events
g_event_procbody
fork_exit
fork_trampoline

Whether built with clang or gcc, CUSTOM config or GENERIC, same results
on rebooting.  No idea why this suddenly started happening, haven't
changed anything at all in my setup.

My recent kernel does the same on two FreeBSD 10.0-CURRENT #1 r234309:
Sun Apr 15 14:14:11 CEST 2012 boxes. Both boxes in common is they are
attached to a Dell UltraSharp U2711 screen which does have a built-in
USB/MMC hub. I realized that it was possible to log into my lab's box

from remote when I'm not in the lab and that is usually coincidentally

with a switched off screen.
This morning I loged in from home, loged out and got to the office,
switched on the screen - and reboot! I wasn't able to get the system
running again, it always got stuck in a

Fatal trap 18: integer divide fault while in kernel mode

Unplugging the screen's USB hub makes the system booting again!

Following is one of the last logged messages from the kernel, I don not
know whether this is usefull looking for the problem.

Regards,
Oliver

Apr 12 15:32:33 telesto kernel: hwpmc:
SOFT/16/64/0x67INT,USR,SYS,REA,WRI   TSC/1/64/0x20REA
IAP/4/48/0x3ffINT,USR,SYS,EDG,THR,REA,WRI,INV,QUA,PRC
IAF/3/48/0x61INT,REA,WRI   UCP/8/48/0x3f8EDG,THR,REA,WRI,INV,QUA,PRC
UCF/1/48/0x60REA,WRI
Apr 12 15:32:33 telesto kernel: uhub1: 4 ports with 4 removable, self
powered
Apr 12 15:32:33 telesto kernel: uhub2: 4 ports with 4 removable, self
powered
Apr 12 15:32:33 telesto kernel: uhub3: 2 ports with 2 removable, self
powered
Apr 12 15:32:33 telesto kernel: uhub0: 2 ports with 2 removable, self
powered
Apr 12 15:32:33 telesto kernel: ugen3.2:vendor 0x8087   at usbus3
Apr 12 15:32:33 telesto kernel: uhub4:vendor 0x8087 product 0x0024,
class 9/0, rev 2.00/0.00, addr 2   on usbus3
Apr 12 15:32:33 telesto kernel: ugen0.2:vendor 0x8087   at usbus0
Apr 12 15:32:33 telesto kernel: uhub5:vendor 0x8087 product 0x0024,
class 9/0, rev 2.00/0.00, addr 2   on usbus0
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3 usbus0
Apr 12 15:32:33 telesto kernel: uhub5: 6 ports with 6 removable, self
powered
Apr 12 15:32:33 telesto kernel: uhub4: 8 ports with 8 removable, self
powered
Apr 12 15:32:33 telesto kernel: ugen3.3:Cherry GmbH   at usbus3
Apr 12 15:32:33 telesto kernel: ukbd0:Cherry GmbH wired keyboard,
class 0/0, rev 2.00/1.11, addr 3   on usbus3
Apr 12 15:32:33 telesto kernel: kbd2 at ukbd0
Apr 12 15:32:33 telesto kernel: uhid0:Cherry GmbH wired keyboard,
class 0/0, rev 2.00/1.11, addr 3   on usbus3
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: ugen3.4:vendor 0x0424   at usbus3
Apr 12 15:32:33 telesto kernel: uhub6:vendor 0x0424 product 0x2514,
class 9/0, rev 2.00/0.00, addr 4   on usbus3
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: uhub6: 3 ports with 2 removable, self
powered
Apr 12 15:32:33 telesto kernel: ugen3.5:vendor 0x0424   at usbus3
Apr 12 15:32:33 telesto kernel: uhub7:vendor 0x0424 product 0x2640,
class 9/0, rev 2.00/0.00, addr 5   on usbus3
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: uhub7: 3 ports with 2 removable, self
powered
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: ugen3.6:Generic   at usbus3
Apr 12 15:32:33 telesto kernel: umass0:Generic Ultra Fast Media
Reader, class 0/0, rev 2.00/1.91, addr 6   on usbus3
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: (probe0:umass-sim0:0:0:0): TEST UNIT
READY. CDB: 0 0 0 0 0 0
Apr 12 15:32:33 telesto kernel: (probe0:umass-sim0:0:0:0): CAM status:
SCSI Status Error
Apr 12 15:32:33 telesto kernel: (probe0:umass-sim0:0:0:0): SCSI status:
Check Condition
Apr 12 15:32:33 telesto kernel: (probe0:umass-sim0:0:0:0): SCSI sense:
NOT READY asc:3a,0 (Medium not present)
Apr 12 15:32:33 telesto kernel: da0 at umass-sim0 bus 0 scbus14 target 0
lun 0
Apr 12 15:32:33 telesto kernel: da0:Generic Ultra HS-SD/MMC 1.91
Removable Direct Access SCSI-0 device
Apr 12 15:32:33 telesto kernel: da0: 40.000MB/s transfers
Apr 12 15:32:33 telesto kernel: da0: Attempt to query device size
failed: NOT READY, Medium not present
Apr 12 15:32

Re: Kernel builds, but crashes at boot (amd64, Revision: 234306)

[Rainer Hurling]

Am 17.04.2012 03:53 (UTC+1) schrieb Edward Tomasz Napierała:

Wiadomość napisana przez Rainer Hurling w dniu 16 kwi 2012, o godz. 19:58:

On 16.04.2012 19:31 (UTC+1), Konstantin Belousov wrote:

On Mon, Apr 16, 2012 at 06:15:32PM +0200, Rainer Hurling wrote:


I just updated my system to r234342, only downgraded
/usr/src/sys/cam/scsi/scsi_da.c to r233746, and now the system is
booting again. So obviously there is something wrong with the newest
patch to  scsi_da.c.

It is too broad, try to revert exactly one patch and see whether it works.


Sorry for my bad english. I wanted to say, that I only reverted exactly one 
patch (file scsi_da.c from 234177 back to 233746 manually). The rest is up to 
r234342.


Could you try the patch below?

Index: sys/cam/scsi/scsi_da.c
===
--- sys/cam/scsi/scsi_da.c  (revision 234314)
+++ sys/cam/scsi/scsi_da.c  (working copy)
@@ -938,7 +938,9 @@ daopen(struct disk *dp)
if (error != 0)
xpt_print(periph-path, unable to retrieve capacity data);

-   if (periph-flags  CAM_PERIPH_INVALID)
+   if (periph-flags  CAM_PERIPH_INVALID ||
+   softc-disk-d_sectorsize == 0 ||
+   softc-disk-d_mediasize == 0)
error = ENXIO;

if (error == 0  (softc-flags  DA_FLAG_PACK_REMOVABLE) != 0




Thanks for the patch. I just tried it with 10.0-CURRENT (amd64) r234370 
and it at least boots again.

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

stat(1) - option doubled in manpage

[Rainer Hurling]

Just a small note.

In stat(1) the description of option -l doubles:

-l  Display output in ls -lT format.


Perhaps someone with a commit bit is interested in correcting this?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Use of C99 extra long double math functions after r236148

[Rainer Hurling]

Yesterday r236148 (Allow inclusion of libc++ cmath to work after 
including math.h) was comitted to head, many thanks.


Does this mean, that extra long double functions like acoshl, expm1l or 
log1pl are now really implemented? As far as I understand, they had 
only been declared before?


If this is right, are they usable on a recent CURRENT, built with gcc42 
(system compiler), by ports which use gcc46 (not clang)? If not, are 
there any plans to implement these functions in the near future?


The use of C99 extra long double functions would be of interest for 
example for programs like math/R, especially its upcoming releases.


Many thanks for any clarification.

Regards,
Rainer Hurling
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:

On 28 May 2012, at 05:35, Rainer Hurling wrote:


First I should note that I am by no means an expert in C / C++ or C99 
standards. So my comments are only on a level of someone who is using 
FreeBSD for scientific purposes like GIS and math applications and who 
is the maintainer of some scientific ports (like math/saga).



Yesterday r236148 (Allow inclusion of libc++cmath  to work after including 
math.h) was comitted to head, many thanks.

Does this mean, that extra long double functions like acoshl, expm1l or log1pl are now 
really implemented? As far as I understand, they had only been declared 
before?


They are still not implemented.  Thecmath  header in libc++ provides wrappers around 
these functions for C++, but if they are not declared then the compiler throws an error.  Now 
there is a linker error if they are used, but if they are not used then it works irrespective of 
whether you just includecmath  or do undefined things like includemath.h  first.


Ok, that's what I had supposed. Because the main difference between 
r236147 and r2136148 seems to be the define of _MATH_EXTRA_H_, the rest 
is more a type of binning?



If this is right, are they usable on a recent CURRENT, built with gcc42 (system 
compiler), by ports which use gcc46 (not clang)? If not, are there any plans to 
implement these functions in the near future?


I think they're one of the last bits of C99 / C11 that anyone actually cares 
about (C11 unicode support being another), so they'll probably get done at some 
point, but doing them correctly is nontrivial, except on platforms where double 
and long double are the same.


Yes, I agree. These outstanding long double math functions (like log1pl) 
and better unicode support are really needed for some important third 
party projects like R or SAGA GIS.


In the past I have read several times discussions about the correctness 
of long double functions on FreeBSD. Some drafts have been dismissed 
because of there inaccuracy in special cases. Also was discussed to get 
missing libm routines from NetBSD [1]. It appears as if we have to wait 
some more time ...



The use of C99 extra long double functions would be of interest for example for 
programs like math/R, especially its upcoming releases.


I would be very wary of anything that depends on long double.  The C spec makes 
no constraints on the range of float, double, or long double, but by convention 
on most platforms float is an IEEE 754 32-bit floating point value and double 
is 64-bit.  No such conventions apply to long doubles and I know of (widely 
deployed) platforms where they are 64 bits, 80 bits and 128 bits, respectively. 
 I believe on PowerPC FreeBSD actually gets it wrong and uses 64 bits even 
though the platform ABI spec recommends using 128 bits.  x86 uses 80-bit x87 
values (although sizeof(long double) may be 16 because they have some padding 
bytes in memory).  If your program is tolerant of a potential variation in 
precision between 64 bits and 128 bits, then it is probably tolerant of just 
using doubles.


Yes, I think in most cases math/R is tolerant enough of just using 
doubles. But in the near future they plan to implement much more of the 
C99 stuff and their tolerance to offer workarounds for FreeBSD shrinks 
from release to release [2]. So these problems will increase :-(


Many thanks for your fast und well explained answer, I really appreciate it.

Rainer


David



[1] 
http://lists.freebsd.org/pipermail/freebsd-standards/2011-February/002119.html


[2] https://stat.ethz.ch/pipermail/r-devel/2012-May/064128.html

And some more places I found interesting about C99 and FreeBSD

[3] http://www.freebsd.org/projects/c99/index.html

[4] http://wiki.freebsd.org/MissingMathStuff

[5] http://marc.info/?l=freebsd-standardsm=123158761305427

[6] 
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/028030.html


[7] 
http://www.koders.com/c/fid164FD2F50C9AAA63119A641875824455B3AE6B55.aspx?s=log1pl.c


[8] http://www.mail-archive.com/bug-gnulib@gnu.org/msg26571.html

[9] http://leaf.dragonflybsd.org/mailarchive/commits/2011-12/msg00190.html
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 28.05.2012 14:49 (UTC+1), David Chisnall wrote:

On 28 May 2012, at 13:30, Rainer Hurling wrote:


On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:

On 28 May 2012, at 05:35, Rainer Hurling wrote:


Ok, that's what I had supposed. Because the main difference between r236147 and 
r2136148 seems to be the define of _MATH_EXTRA_H_, the rest is more a type of 
binning?


Yes, it's just about making libc++'s cmath header compile, nothing more.


I see, thanks.


Yes, I agree. These outstanding long double math functions (like log1pl) and 
better unicode support are really needed for some important third party 
projects like R or SAGA GIS.


I very much doubt that anything is using the C11 unicode stuff yet, since no 
compiler or libc currently supports it...


Of course you are right with C11 unicode stuff.

I thougt more about my actual problems to get the right charset 
conversions between different apps, i.e. qgis - wxgtk29 - saga gis. 
Or using Gnome apps (utf8) on windowmaker using ISO8859-15. But this is 
OT here, sorry.



In the past I have read several times discussions about the correctness of long 
double functions on FreeBSD. Some drafts have been dismissed because of there 
inaccuracy in special cases. Also was discussed to get missing libm routines 
from NetBSD [1]. It appears as if we have to wait some more time ...


I thought we did pull in some NetBSD libm stuff recently.  Not sure what the 
status of that is, you'd need to check with das@.


I am not aware of it and will have a look. But this did not implement 
the missing long double functions.



Yes, I think in most cases math/R is tolerant enough of just using doubles. But 
in the near future they plan to implement much more of the C99 stuff and their 
tolerance to offer workarounds for FreeBSD shrinks from release to release [2]. 
So these problems will increase :-(


Reading that email, it seems that they would prefer a function that exists and 
returns the wrong result to one that does not exist.  If this is really the 
attitude of the developers of R, then I shall make absolutely certain that I 
avoid using R for anything where I actually care about the results, and would 
strongly encourage everyone else to do the same.


This was a statement of just one (though not unimportant) person from 
the R Core team. I don't think that this is the only view of R Core 
developers. On the other hand he is the person, who actually did most of 
the stuff within R for years now to circumvent the problems running on 
FreeBSD.



In general, (sane) people use the long double versions because they need the 
extra precision and care about the result.  We could easily implement the long 
double versions now as toy versions that just called the double versions, but 
that would upset a lot of people who actually care about accuracy, who are the 
main target audience for these functions.


It seems to be a general trend (outside of FreeBSD) to implement more 
and more stuff at the cost of quality. I am certain that for many 
FreeBSD users accuracy is more important than completeness, especially 
for scientists.


Nevertheless this policy brings some problems in the real world ;-)

Thanks again for your thoughts,
Rainer


David

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

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 29.05.2012 08:10 (UTC+1), Steve Kargl wrote:

On Tue, May 29, 2012 at 02:56:13PM +1000, Peter Jeremy wrote:

On 2012-May-28 15:54:06 -0700, Steve Kargls...@troutmask.apl.washington.edu  
wrote:

There some test code in cephes.  Can you point me to a suitable test
suite for LD80 and LD128?  The reason for calling it libm is to avoid
having to hack every consumer to add an additional library.


I can't point you to test code.  When I work on a function,
I write test code.


  It took
me 3+ years to get sqrtl() into libm, but bde and das (and
myself) wanted to make sure the code worked.


Last time I checked (a couple of years ago), FreeBSD was missing 65
C99 libm functions.  At 3 years per function, we should have C99
support available early in the 23rd century - which may be a bit late.


sqrtl() is a bit special in that IEEE 754 requires that
it have no more than 0.5 ULP for all arguments in all
roundng modes.  As to other functions, I've been trying
for 10+ years to get some of these into FreeBSD.  I can
assure you that there has never been a rush of people
volunteering to help or a rush of people willing to fund
the development of the necessary code.


The almost complete absence of volunteers in this case is first of all 
caused by the need of very special, deep knowlegdes on mathematical and 
informatical issues. I bet there are only a few people out there, who 
are really good in both (three of them are known to us ;) ). The 
problems with quality standards in such libraries spreaded over most 
OS'es and platforms support this view. (I am aware that these arguments 
are kown and discussed before.)


People like me, who wanted to _use_ FreeBSD as scientific desktops, have 
an urgent need on such mathematical libraries. But most of us have no 
chance to contribute conceptual. For some tasks we could use specialized 
libraries or software, which include missing procedures and functions. 
But more often, modern apps expect to get this functionalities from the OS.


This discussion confirms my impression, that it should be possible as an 
interim solution, to use a port for missing math functions (cephes alike 
or whatever). The port itself could warn the user about inaccuracies and 
edge-cases.


The more important question to me is, how can the remaining (huge!) work 
on the systems libm done in a foreseeable time. As one possibility, 
wouldn't it be imaginable to pay some people for doing (some of) this 
work (FreeBSD Foundation, Sponsors from industry and science etc.)? I 
personally, as a private person, would be willing to pay a few hundred 
dollars for it. Paying people for other tasks in FreeBSD is not entirely 
uncommon, if I am not mistaken.




On 2012-May-28 22:03:43 -0500, Stephen Montgomery-Smithstep...@missouri.edu  
wrote:

1.  By being so picky about being so precise, FreeBSD is behind the time
line in rolling out a usable set of C99 functions.


And at the current rate, we'll all be long dead before they are
available.


It seems you've had a couple of years to implement one or
more of the missing functions.  Yes, we'll all be dead before
libm is C99 ready because no one, other than bde@, das@ and
myself, has been willing to actually help write the code.  I
know that at least one of those three people has had no time
in the last year or two work on libm.



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

Re: CURRENT ( r249381): can't find boot partition on GPT disk

[Rainer Hurling]

On 13.04.2013 12:07 (UTC+2), Marcus Reid wrote:
 On Sat, Apr 13, 2013 at 09:14:10AM +0200, O. Hartmann wrote:
 Trying to boot a kernel  r249381 fails and I see on the console the
 loader prompt at mountroot. Obviously, the bootloader doesn't find
 the root/boot partition.
 
 Same problem observed here.  r249435, gpt zfs root.  Entering
 zfs:zroot at the mountroot prompt allows system to continue booting.

Same here without gtp and zfs, but with ufs. Seems to be solved for me
with r249436.

Rainer

 Marcus

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

Re: Booting an alternative kernel from loader prompt fails the first time only

[Rainer Hurling]

On 20.04.2013 18:47 (UTC+2), Florian Smeets wrote:
 On 20.04.13 18:05, Steven Hartland wrote:
 When trying to boot an alternative kernel from the loader prompt
 it fails the first time the command is run but succeeds the second
 time.

 Type '?' for a list of commands, 'help' for more detailed help.
 OK boot kernel.generic
 Booting...
 don't know how to load module '/boot/kernel.generic/kernel'
 OK boot kernel.generic
 Booting...
 /boot/kernel.generic/kernel text=0xd21288 data=..

 
 Yes, I've been seeing the same thing for about 6-12 months maybe more.
 None of the people I asked were able to confirm, so I'm happy that I'm
 not imagining it :)

I also can confirm this behaviour for month now (on 10.0-CURRENT amd64
with clang).

Rainer

 
 I see this on serial as well as on the normal console in front of a PC.
 
 Florian
 

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

Re: Booting an alternative kernel from loader prompt fails the first time only

[Rainer Hurling]

On 21.04.2013 02:36 (UTC+2), Steven Hartland wrote:
 
 - Original Message - From: Joshua Isom jri...@gmail.com
 To: freebsd-current@freebsd.org
 Sent: Sunday, April 21, 2013 12:41 AM
 Subject: Re: Booting an alternative kernel from loader prompt fails the
 first time only
 
 
 On 4/20/2013 12:41 PM, Manfred Antar wrote:
 At 10:24 AM 4/20/2013, Rainer Hurling wrote:
 On 20.04.2013 18:47 (UTC+2), Florian Smeets wrote:
 On 20.04.13 18:05, Steven Hartland wrote:
 When trying to boot an alternative kernel from the loader prompt
 it fails the first time the command is run but succeeds the second
 time.

 Type '?' for a list of commands, 'help' for more detailed help.
 OK boot kernel.generic
 Booting...
 don't know how to load module '/boot/kernel.generic/kernel'
 OK boot kernel.generic
 Booting...
 /boot/kernel.generic/kernel text=0xd21288 data=..


 Yes, I've been seeing the same thing for about 6-12 months maybe more.
 None of the people I asked were able to confirm, so I'm happy that I'm
 not imagining it :)

 I also can confirm this behaviour for month now (on 10.0-CURRENT amd64
 with clang).

 Rainer


 Have you tried:
 OK boot /boot/kernel.generic/kernel

 Use full path name always works for me
 Manfred
 
 I believe this may well have been introduced by:-
 http://svnweb.freebsd.org/base?view=revisionrevision=241069
 
 When booting with a /boot/loader.conf that contains a module load line
 e.g. zfs_load=YES then this is loaded before the kernel.
 
 Loading any module causes last_file_format to get set so when the next
 file that's loaded is in fact a kernel it still try's to load it as a
 kernel module using what was stored with last_file_format.
 
 This fails and trips the Restart from the beginning case which contains:
   last_file_format = i = 0;
   fp = NULL;
   continue;
 
 So i gets set to 0 but the loop then increments it to 1 before running
 the next iteration, so its impossible to use first handler in the retry
 case; which I suspect is the kernel loader.
 
 This also explains why the second call to boot works as last_file_format
 is now 0 due to the previous failure.
 
 If this is the issue the attached patch should fix it. I can't test it
 ATM as my current box is at the office and doesn't have remote KVM, so
 I need to be in front of it.
 
 If anyone can confirm this attached patch fixes the problem then I'll get
 it committed, otherwise I'll test on Monday.

I tried your patch with recent 10.0-CURRENT amd64 (r249715, clang), and
it seems to work. I can set module path, load some modules, and
afterwards load a kernel in one call.

Thank you very much.

Best wishes,
Rainer

 
Regards
Steve

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

Re: kernel panic with _autoload_ nvidia driver

[Rainer Hurling]

On 05.05.2013 08:01 (UTC+2), de...@stasyan.com wrote:
   Hello !
 
   This problems appears about 4-6 months ago after updating of -CURRENT
 host.
 Unable to boot host with nvidia_load=YES in loader.conf because panic.
 But when nvidia driver loads manually via kldload, everything OK.
 Nvidia driver version is 310.44 at this moment, but problem was and on
 earlier version too.

As far as I can tell this is OK again with nvidia version 319.17.

This version is not in the ports yet, but you can try it by overwriting
the Makefiles version number ('make makesum' also adjusts the distfile
than).

HTH,
Rainer

 
 Here is output of debugging (full version at
 http://www.stasyan.com/devel/kern_crash_nvidia_autoload.txt)
 
 
 Loaded symbols for /boot/kernel/udf.ko.symbols
 #0  doadump (textdump=0) at pcpu.h:253
 253 __asm(movl %%fs:%1,%0 : =r (td)
 (kgdb) backtrace
 #0  doadump (textdump=0) at pcpu.h:253
 #1  0xc050a991 in db_dump (dummy=-1062503683, dummy2=0, dummy3=-1,
 dummy4=0xfad2c8b4 ) at /usr/src/sys/ddb/db_command.c:543
 #2  0xc050a487 in db_command (cmd_table=value optimized out) at
 /usr/src/sys/ddb/db_command.c:449
 #3  0xc050a1a0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502
 #4  0xc050c9e0 in db_trap (type=value optimized out, code=-86848816)
 at /usr/src/sys/ddb/db_main.c:231
 #5  0xc0ab8278 in kdb_trap (type=value optimized out, code=value
 optimized out, tf=value optimized out)
 at /usr/src/sys/kern/subr_kdb.c:654
 #6  0xc0e9f1ae in trap (frame=value optimized out) at
 /usr/src/sys/i386/i386/trap.c:720
 #7  0xc0e8835c in calltrap () at /usr/src/sys/i386/i386/exception.s:169
 #8  0xc0ab7afd in kdb_enter (why=0xc10786cb panic, msg=value
 optimized out) at cpufunc.h:71
 #9  0xc0a81503 in vpanic (fmt=value optimized out, ap=value optimized
 out) at /usr/src/sys/kern/kern_shutdown.c:747
 #10 0xc0a813ba in kassert_panic (fmt=value optimized out) at
 /usr/src/sys/kern/kern_shutdown.c:642
 #11 0xc0acfb55 in witness_warn (flags=value optimized out, lock=value
 optimized out) at /usr/src/sys/kern/subr_witness.c:1727
 #12 0xc0ac7d95 in userret (td=0xc866c000, frame=value optimized out)
 at /usr/src/sys/kern/subr_trap.c:151
 #13 0xc0e9fff1 in syscall (frame=value optimized out) at
 subr_syscall.c:178
 #14 0xc0e883f1 in Xint0x80_syscall () at
 /usr/src/sys/i386/i386/exception.s:267
 #15 0x0033 in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 Current language:  auto; currently minimal
 

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

Re: kernel panic with _autoload_ nvidia driver

[Rainer Hurling]

On 05.05.2013 09:24 (UTC+2), de...@stasyan.com wrote:
 Hello !
   This problems appears about 4-6 months ago after updating of -CURRENT
 host.
 Unable to boot host with nvidia_load=YES in loader.conf because panic.
 But when nvidia driver loads manually via kldload, everything OK.
 Nvidia driver version is 310.44 at this moment, but problem was and on
 earlier version too.
 As far as I can tell this is OK again with nvidia version 319.17.
 I've got panic with nvidia-driver 319.17 too.
 

Do you know the workaround to build the port with

  'env USE_GCC=any make' ?

With this it should not panic anymore, but start normal again ...

Perhaps danfe@ as the maintainer has more ideas?

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

Typo in /usr/src/UPDATING

[Rainer Hurling]

I am not a native speaker, but isn't there a typo in /usr/src/UPDATING
entry from 20130121?

--- UPDATING.orig   2013-05-09 09:46:55.0 +0200
+++ UPDATING2013-05-12 17:58:20.0 +0200
@@ -108,7 +108,7 @@
Due to the use of the new -l option to install(1) during build
and install, you must take care not to directly set the INSTALL
make variable in your /etc/make.conf, /etc/src.conf, or on the
-   command line.  If you with to use the -C flag for all installs
+   command line.  If you wish to use the -C flag for all installs
you may be able to add INSTALL+=-C to /etc/make.conf or
/etc/src.conf.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: mouse pointer has gone.

[Rainer Hurling]

Am 16.01.2014 15:07, schrieb clutton:
 Using X, I have a frozen mouse pointer.
 Mouse works fine from syscons but not from X. Booting from kernel.old
 resolves the problem.
 
 Here is my X log with current kernel.
 
 158:[34.043] (==) NVIDIA(0): Silken mouse enabled
 208:[34.232] (II) config/hal: Adding input device PS/2 Mouse
 209:[34.232] (II) LoadModule: mouse
 210:[34.233] (II)
 Loading /usr/local/lib/xorg/modules/input/mouse_drv.so
 211:[34.236] (II) Module mouse: vendor=X.Org Foundation
 215:[34.237] (II) Using input driver 'mouse' for 'PS/2 Mouse'
 216:[34.237] (**) PS/2 Mouse: always reports core events
 218:[34.237] (==) PS/2 Mouse: Protocol: Auto
 219:[34.237] (**) PS/2 Mouse: always reports core events
 222:[34.238] (EE) PS/2 Mouse: cannot open input device
 223:[34.238] (EE) PreInit returned 2 for PS/2 Mouse
 224:[34.238] (II) UnloadModule: mouse
 
 
 And with kernel.old
 
 158:[30.743] (==) NVIDIA(0): Silken mouse enabled
 208:[30.941] (II) config/hal: Adding input device PS/2 Mouse
 209:[30.941] (II) LoadModule: mouse
 210:[30.942] (II)
 Loading /usr/local/lib/xorg/modules/input/mouse_drv.so
 211:[30.945] (II) Module mouse: vendor=X.Org Foundation
 215:[30.946] (II) Using input driver 'mouse' for 'PS/2 Mouse'
 216:[30.946] (**) PS/2 Mouse: always reports core events
 217:[30.946] (**) Option Device /dev/sysmouse
 218:[30.946] (==) PS/2 Mouse: Protocol: Auto
 219:[30.946] (**) PS/2 Mouse: always reports core events
 220:[30.947] (==) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50
 221:[30.947] (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5
 222:[30.947] (**) PS/2 Mouse: Buttons: 5
 224:[30.947] (II) XINPUT: Adding extended input device PS/2
 Mouse (type: MOUSE, id 7)
 225:[30.948] (**) PS/2 Mouse: (accel) keeping acceleration scheme 1
 226:[30.948] (**) PS/2 Mouse: (accel) acceleration profile 0
 227:[30.948] (**) PS/2 Mouse: (accel) acceleration factor: 2.000
 228:[30.948] (**) PS/2 Mouse: (accel) acceleration threshold: 4
 229:[30.948] (II) PS/2 Mouse: SetupAuto: hw.iftype is 4, hw.model is
 0
 230:[30.948] (II) PS/2 Mouse: SetupAuto: protocol is SysMouse
 

For me, it helped to rebuild devel/dbus and sysutils/hal and restart
that services again.

HTH,
Rainer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CURRENT]: claws-mail and firefox fail with Invalid alignment

[Rainer Hurling]

Am 22.02.2014 10:03, schrieb Ranjan1018 .:
 The problem is still present in r262325. Verified with Firefox.

Just for the record. With r262334 the problem seems to be solved,
Firefox, Thunderbird etc. work again :-)

Thanks to davidxu@ for the quick fix.

Greetings,
Rainer Hurling


 2014-02-22 9:12 GMT+01:00 Alexandr shur...@shurik.kiev.ua:
 
 21.02.2014 20:03, O. Hartmann пишет:
 On Fri, 21 Feb 2014 19:00:13 +0100
 O. Hartmann ohart...@zedat.fu-berlin.de wrote:

 On Fri, 21 Feb 2014 18:49:13 +0100
 Dimitry Andric d...@freebsd.org wrote:

 On 21 Feb 2014, at 18:40, O. Hartmann ohart...@zedat.fu-berlin.de
 wrote:
 On every FreeBSD 11.0-CURRENT #0 r262294: Fri Feb 21 14:11:20 CET
 2014 amd64 I run neither claws-mail nor firfox run after the last
 buildworld. They fail both with the error

 Invalid alignment

 Does anyone see this problem too? I tried to recompile claws-mail
 and firefox, but without success (compilation succeeded, but the
 error stays).

 What happened here? How to solve?
 Can you try reverting r262277, rebuilding libexec/rtld-elf and
 reinstalling it, and seeing if that fixes it?

 -Dimitry

 Hello Dimitry,

 in r262277 there is no change in libexec/rtld-elf, I had to go back to
 r262270. I did as requested and reinstalling libexec/rtld-elf fixes
 the reported issue.

 Regards,
 Oliver
 Sorry, it is r262276


 I have the same issue with firefox and thunderbird. Reverting
 libexec/rtld-elf to r262276 solves a problem.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 

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

Re: mounting ntfs partition from /etc/fstab

[Rainer Hurling]

Am 06.03.2014 08:35, schrieb MS - Krasznai András:
 Hi
 
 I am using freebsd 10 64bit on an IBM T510.
 
 I can not mount ntfs partition from /etc/fstab with the normal method, thatis 
 specifying
 
 /dev/ada0s2  /windows/C  ntfs-3g ro   0   
   0

For me it works with

/dev/ada0s2 /windows/C  ntfsro,mountprog=/usr/local/bin/ntfs-3g 
0   0

HTH,
Rainer

 
 in /etc/fstab
 
 the mount -a command gives me an error message:
 
 /dev/ada0s2:Operation not supported by the device
 
 
 but I can mount the same partition from the command line:
 
 ntfs-3g -o ro /dev/ada0s2  /windows/C
 
 works.
 
 
 What is the cause of this problem?
 
 Krasznai András
 rendszermérnök
 MS Informatikai Zrt.
 1136 Budapest, Pannónia u. 17/A.
 Telefon: +36   1 703-2923
 Mobil:+36 30 703-2923

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

Re: freebsd and utf-8 directory names

[Rainer Hurling]

Am 30.06.2014 08:30 (UTC+1) schrieb MS - Krasznai András:
 Hi
 
 I have been using FreeBSD as desktop since 2003, and living in a mixed 
 (windows-linux) environment I installed FreeBSd along with my usual (Windows 
 7) work environment, I have a dualboot configured laptop. I use FreeBSD-10 
 STABLE.
 
 There is a partition formatted for FAT32 where I store documents which I 
 would like to view (and edit) both in  windows and freebsd.
 
 The problem is that if the path name contains certain Hungarian characters 
 (e.g o with double accent), then libreoffice in FreeBSD refuses to open them 
 complaining about illegal characters. The directory was created in windows, 
 the document also, and I can handle them perfectly from windows (what is 
 more, libreoffice under a linux can also open those documents). Some accented 
 characters are shown as a question mark in FreeBSD, and some others are as a 
 black rectangle; these latter are causing problems. If a file-nam contains 
 such characters then the file is shown as 0- length in Midnight Commander.
 
 I tried some steps described in the „Localization” part of the FreeBSD 
 Handbook, but things did not improve.
 
 I installed PC-BSD with Hungarian language support, thinking that it would 
 handle the localized directory names correctly but no, it gives the same 
 error message.
 
 This problem is really annoying. How could I solve it?

In my German environment I also use FAT32 formatted drives, mounted like:

/dev/adaXsX /XXXmsdosfs rw,large,-Lde_DE.UTF-8  0   0

This should also work for Hungarian?

HTH,
Rainer Hurling


 Krasznai András
 rendszermérnök
 MS Informatikai Zrt.
 1136 Budapest, Pannónia u. 17/A.
 Telefon: +36   1 703-2923
 Mobil:+36 30 703-2923
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Endless CAM messages with recent CURRENT

[Rainer Hurling]

Today I updated my 9.0-CURRENT system (amd64) to revision 199506: After 
rebooting I get the following messages two times per second in an 
endless run:



-
...
Jan 14 09:37:47 krabat kernel: (sg1:umass-sim0:0:0:0): 
cam_periph_release_locked: release 0xfe0009f41200 when refcount is zero

Jan 14 09:37:47 krabat kernel:
Jan 14 09:37:48 krabat kernel: (sg2:umass-sim0:0:0:1): 
cam_periph_release_locked: release 0xfe0009f41100 when refcount is zero

Jan 14 09:37:48 krabat kernel:
...
-


sg1 and sg2 are devices from my front panel card reader Silverstone 
SST-FP35B:


#camcontrol devlist
[..snip..]
Generic STORAGE DEVICE 9744  at scbus6 target 0 lun 0 (sg1,pass3,da0)
Generic STORAGE DEVICE 9744  at scbus6 target 0 lun 1 (sg2,pass4,da1)


Is it possible that the last changes in usb code (xhci) or in cam code 
are responsible for this? Does anyone else observe this behaviour?


Please let me know if you need more info or if I can test something.

Thank you for any hint,
Rainer Hurling
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Endless CAM messages with recent CURRENT

[Rainer Hurling]

After looking around I had been able to localise the cause for the 
described messages, see below:


On 14.01.2011 10:07 (UTC+1), Rainer Hurling wrote:

Today I updated my 9.0-CURRENT system (amd64) to revision 199506: After
rebooting I get the following messages two times per second in an
endless run:


-
...
Jan 14 09:37:47 krabat kernel: (sg1:umass-sim0:0:0:0):
cam_periph_release_locked: release 0xfe0009f41200 when refcount is zero
Jan 14 09:37:47 krabat kernel:
Jan 14 09:37:48 krabat kernel: (sg2:umass-sim0:0:0:1):
cam_periph_release_locked: release 0xfe0009f41100 when refcount is zero
Jan 14 09:37:48 krabat kernel:
...
-


When turning off hald no more of these messages appear. hald is trying 
to poll the card reader, but it does not like this. So prohibiting the 
polling in /usr/local/share/hal/fdi/preprobe/20thirdparty/ solves my 
problem:


#cat 10-broken-usb-card-reader.fdi
?xml version=1.0 encoding=UTF-8?

deviceinfo version=0.2
  device

!-- Generic STORAGE DEVICE 9744 --
match key=storage.bus string=usb
  !-- usb card reader Silverstone SST-FP35B doesn't like polling --
  match key=@storage.originating_device:usb.vendor_id int=0x05e3
match key=@storage.originating_device:usb.product_id 
int=0x0716
  merge key=storage.media_check_enabled 
type=boolfalse/merge

/match
  /match
/match

  /device
/deviceinfo




sg1 and sg2 are devices from my front panel card reader Silverstone
SST-FP35B:

#camcontrol devlist
[..snip..]
Generic STORAGE DEVICE 9744 at scbus6 target 0 lun 0 (sg1,pass3,da0)
Generic STORAGE DEVICE 9744 at scbus6 target 0 lun 1 (sg2,pass4,da1)


Is it possible that the last changes in usb code (xhci) or in cam code
are responsible for this? Does anyone else observe this behaviour?


A more generic approach would be to integrate the polling info into 
/usr/local/share/hal/fdi/preprobe/10osvendor/20-broken-usb-sticks.fdi. 
Is anyone willing to integrate the code (.fdi file or some quirks) in 
the usb stuff?



In that case Linux is offering some more info about this device:

#lssub
Bus 002 Device 002: ID05e3:0716 Genesys Logic, Inc. USB2.0 Multislot 
Card Reader/Writer

idVendor 0x05e3 Genesys Logic, Inc.

#usb-devices
T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver=2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P: Vendor=05e3 ProdID=0176 Rev=97.44
S: Product=USB Storage
S: SerialNumber=9744
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage


Note, that the card reader from Benesys Logic is only one device of some 
more (firewire, eSATA, USB slots ...), which are provided from the 
'Silverstone SST-FP35B' front panel access unit.



Please let me know if you need more info or if I can test something.


Thanks in advance,
Rainer Hurling
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Endless CAM messages with recent CURRENT

[Rainer Hurling]

On 14.01.2011 20:10 (UTC+1), Hans Petter Selasky wrote:

Marcus,

Can you have a look at this?


Are there any news?

Thanks,
Rainer


--HPS

On Friday 14 January 2011 16:21:00 Rainer Hurling wrote:

After looking around I had been able to localise the cause for the
described messages, see below:

On 14.01.2011 10:07 (UTC+1), Rainer Hurling wrote:

Today I updated my 9.0-CURRENT system (amd64) to revision 199506: After
rebooting I get the following messages two times per second in an
endless run:


-
...
Jan 14 09:37:47 krabat kernel: (sg1:umass-sim0:0:0:0):
cam_periph_release_locked: release 0xfe0009f41200 when refcount is
zero Jan 14 09:37:47 krabat kernel:
Jan 14 09:37:48 krabat kernel: (sg2:umass-sim0:0:0:1):
cam_periph_release_locked: release 0xfe0009f41100 when refcount is
zero Jan 14 09:37:48 krabat kernel:
...
-


When turning off hald no more of these messages appear. hald is trying
to poll the card reader, but it does not like this. So prohibiting the
polling in /usr/local/share/hal/fdi/preprobe/20thirdparty/ solves my
problem:

#cat 10-broken-usb-card-reader.fdi
?xml version=1.0 encoding=UTF-8?

deviceinfo version=0.2
device

  !-- Generic STORAGE DEVICE 9744 --
  match key=storage.bus string=usb
!-- usb card reader Silverstone SST-FP35B doesn't like polling --
match key=@storage.originating_device:usb.vendor_id int=0x05e3
  match key=@storage.originating_device:usb.product_id
int=0x0716
merge key=storage.media_check_enabled
type=boolfalse/merge
  /match
/match
  /match

/device
/deviceinfo


sg1 and sg2 are devices from my front panel card reader Silverstone
SST-FP35B:

#camcontrol devlist
[..snip..]
Generic STORAGE DEVICE 9744  at scbus6 target 0 lun 0 (sg1,pass3,da0)
Generic STORAGE DEVICE 9744  at scbus6 target 0 lun 1 (sg2,pass4,da1)


Is it possible that the last changes in usb code (xhci) or in cam code
are responsible for this? Does anyone else observe this behaviour?


A more generic approach would be to integrate the polling info into
/usr/local/share/hal/fdi/preprobe/10osvendor/20-broken-usb-sticks.fdi.
Is anyone willing to integrate the code (.fdi file or some quirks) in
the usb stuff?


In that case Linux is offering some more info about this device:

#lssub
Bus 002 Device 002: ID05e3:0716 Genesys Logic, Inc. USB2.0 Multislot
Card Reader/Writer
idVendor 0x05e3 Genesys Logic, Inc.

#usb-devices
T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver=2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P: Vendor=05e3 ProdID=0176 Rev=97.44
S: Product=USB Storage
S: SerialNumber=9744
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage


Note, that the card reader from Benesys Logic is only one device of some
more (firewire, eSATA, USB slots ...), which are provided from the
'Silverstone SST-FP35B' front panel access unit.


Please let me know if you need more info or if I can test something.


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

Re: Endless CAM messages with recent CURRENT

[Rainer Hurling]

On 30.01.2011 15:13 (UTC+1), Hans Petter Selasky wrote:

On Sunday 30 January 2011 14:57:37 Rainer Hurling wrote:

On 14.01.2011 20:10 (UTC+1), Hans Petter Selasky wrote:

Marcus,

Can you have a look at this?


Are there any news?



I don't have any news, except it is a HAL problem and it needs to be solved
there.


Ok, I understand.

Besides this I think that my device is not fully recognized by usb code. 
I only get 'Generic STORAGE DEVICE 9744' instead of something like 
'Genesys Logic, Inc. USB2.0 Multislot Card Reader/Writer'.


Wouldn't it be useful to integrate the device info into the usb driver?

#lssub
Bus 002 Device 002: ID05e3:0716 Genesys Logic, Inc. USB2.0 Multislot 
Card Reader/Writer

idVendor 0x05e3 Genesys Logic, Inc.

#usb-devices
T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver=2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P: Vendor=05e3 ProdID=0176 Rev=97.44
S: Product=USB Storage
S: SerialNumber=9744
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

Rainer


--HPS


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

Re: Endless CAM messages with recent CURRENT

[Rainer Hurling]

On 30.01.2011 16:22 (UTC+1), Hans Petter Selasky wrote:

On Sunday 30 January 2011 16:15:02 Rainer Hurling wrote:

Wouldn't it be useful to integrate the device info into the usb driver?


You can check if your kernel is compiled with options USB_VERBOSE. That
should bring some more verbosity based on sys/dev/usb/usbdevs.


Thanks for the hint. Now I am getting

#usbconfig -u 3 -a 2 dump_device_desc
ugen3.2: USB Storage Genesys Logic at usbus3, cfg=0 md=HOST spd=HIGH 
(480Mbps) pwr=ON


  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x
  bDeviceSubClass = 0x
  bDeviceProtocol = 0x
  bMaxPacketSize0 = 0x0040
  idVendor = 0x05e3
  idProduct = 0x0716
  bcdDevice = 0x9744
  iManufacturer = 0x  no string
  iProduct = 0x0001  USB Storage
  iSerialNumber = 0x0002  9744
  bNumConfigurations = 0x0001

So it seems there already is some info about this device in the code.

Rainer


--HPS


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

Kernel from today does not build any more

[Rainer Hurling]

After cvsup my CURRENT amd64 systems today I am not able to build custom 
kernel any more. Does anyone else observes the following breakage?


=== bwn (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE 
-nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/obj/usr/src/sys/RHURLIN/opt_global.h -I. -I@ -I@/contrib/altq 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -fno-common  -fno-omit-frame-pointer 
-I/usr/obj/usr/src/sys/RHURLIN -mcmodel=kernel -mno-red-zone 
-mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow 
-msoft-float -fno-asynchronous-unwind-tables -ffreestanding 
-fstack-protector -std=iso9899:1999 -fstack-protector -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -fformat-extensions -c 
/usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c

cc1: warnings being treated as errors
/usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c: In function 'bwn_tsf_read':
/usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c:10384: warning: unused 
variable 'sc'

*** Error code 1
Stop in /usr/src/sys/modules/bwn.
*** Error code 1
Stop in /usr/src/sys/modules.
*** Error code 1
...

Thanks in advance,
Rainer Hurling
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Kernel from today does not build any more

[Rainer Hurling]

On 10.03.2010 22:46 (UTC+1), Pyun YongHyeon wrote:

On Wed, Mar 10, 2010 at 09:23:26PM +0100, Rainer Hurling wrote:

After cvsup my CURRENT amd64 systems today I am not able to build custom
kernel any more. Does anyone else observes the following breakage?



Fixed in r204983.


Thanks, will try it tomorrow.
Rainer


===  bwn (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/RHURLIN/opt_global.h -I. -I@ -I@/contrib/altq
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common  -fno-omit-frame-pointer
-I/usr/obj/usr/src/sys/RHURLIN -mcmodel=kernel -mno-red-zone
-mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow
-msoft-float -fno-asynchronous-unwind-tables -ffreestanding
-fstack-protector -std=iso9899:1999 -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions -c
/usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c
cc1: warnings being treated as errors
/usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c: In function 'bwn_tsf_read':
/usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c:10384: warning: unused
variable 'sc'
*** Error code 1
Stop in /usr/src/sys/modules/bwn.
*** Error code 1
Stop in /usr/src/sys/modules.
*** Error code 1


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

Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]

[Rainer Hurling]

On 04.04.2010 13:24 (UTC+1), Garrett Cooper wrote:

On 3/26/10, Robert Watsonrwat...@freebsd.org  wrote:

On Mon, 22 Mar 2010, Xin LI wrote:


A MFC of this update is planned, but we will have to make some rather
aggressive changes against the library and more testing.

Please make sure that you have at least libxml2-2.7.6_2 in your ports tree

before even thinking about updating your ports tree.  Older libxml2 uses
some knowledge of zlib internals that has been changed in this update
which
is known to cause problem.


While the update sounds like a good idea (as does moving to symbol
verisoning
for this library), I'm not yet convinced an MFC is a good idea given the
compatibility issues you describe.  Perhaps you could clarify a bit the
failure mode: this affects only people who rebuild their ports using exactly
the same ports versions, but after having done an upgrade that includes this
update?  It sounds like existing binaries will continue to work since they
will reference the old library version?


Yes, but the number of libraries which need to be fixed is a pain. If
you go the conservative (not ultra conservative) route, you'll have to
rebuild all dependencies of graphics/png and graphics/tiff (which
includes a ton of gnome apps, X, etc). Oh, and did I forget to mention
that libtool hardcodes paths and versioning information? Of course
most people won't see this fact until they run make delete-old-libs,
but it's a doosy... This is the primary reason why Gentoo Linux has a
script to clean up these [libtool] messes...


To avoid the biggest trouble when updating I temporarily went another 
way. Before 'make delete-old-libs' I made a copy of libz.so.5 under compat:


cp -p /lib/libz.so.5 /usr/local/lib/compat/
cp -p /usr/lib32/libz.so.5 /usr/local/lib32/compat/

I plan to delete these copies in some weeks. Do you think this is ok or 
do I have to expect unwanted side effects?


Thanks,
Rainer Hurling



That point alone is a reason for being ultra-conservative with this
MFCing change. This won't affect folks building from scratch after
this commit, but it'll easily kill off an afternoon or day for folks
upgrading if they one isn't careful because the impact is large.

Of course scripting the activity to avoid these times of base system
library bumps is trivial, but my script that I whipped up still has
rough edges and I'd rather not submit it quite yet...

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

Re: Recent sys/vm/ changes and nvidia-driver

[Rainer Hurling]

On 08.05.2010 22:30 (UTC+1), Doug Barton wrote:

On 05/05/10 11:56, Alan Cox wrote:


I'm afraid that I would advise waiting a few days.  This round of changes
are not yet complete.


Is the coast clear yet? :)  I have been holding off on updating -current
due to the SUJ stuff, but that seems to have mostly settled down now, so
I'm hoping that the work on the VM won't prevent me from running
nvidia-driver.


Hope I do not misunderstand the item. I updated current (amd64) today 
and it seems all is fine with newest nvidia driver at the moment,


Rainer


Thanks,

Doug

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

Re: nvidia-driver not work

[Rainer Hurling]

On 17.08.2010 16:11 (UTC+1), Ivan Klymenko wrote:

В Tue, 17 Aug 2010 09:52:50 -0400
John Baldwinj...@freebsd.org  пишет:


On Saturday, August 14, 2010 9:35:02 pm Álvaro Castillo wrote:

$ dmesg (cut)

panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759
cpuid = 0
Uptime: 3m35s


Use the latest nvidia driver from the website (256.44) and not from
the port.


Here the test port...


Sorry, I am afraid there is no attachment
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: nvidia-driver not work

[Rainer Hurling]

On 17.08.2010 18:47 (UTC+1), Ivan Klymenko wrote:

$ dmesg (cut)

panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759
cpuid = 0
Uptime: 3m35s


Use the latest nvidia driver from the website (256.44) and not from
the port.


Here the test port...


Sorry, I am afraid there is no attachment


another attempt...


Thanks for the test port. It works like a charm for me :-)

This is on recent FreeBSD 9.0-CURRENT (amd64) with 4GB RAM and NVidia 
GeForce 9800GT.

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

bge0 does not work anymore

[Rainer Hurling]

I am using FreeBSD 9.0-CURRENT (amd64) on a DELL Latitude D630. With 
todays kernel the driver 'bge0' does not work anymore. With kernel from 
October 9th it does.


The network controller is a Broadcom NetXtreme Gigabit Ethernet, ASIC 
rev. 0x00a002; CHIP ID 0xa0002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E.


The entry in /etc/rc.conf is 'ifconfig_bge0=DHCP.

Does anyone else observe this behaviour? Is there something I can try?

Thanks in advance,
Rainer Hurling
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: pkg/ports system terribly messed up?

[Rainer Hurling]

Am 30.09.2014 um 08:13 schrieb O. Hartmann:
 
 Hello.
 
 I just made the last update of the ports yesterday (I use portmaster -da 
 performing this
 task) and obviously or superficially everything went all right.
 
 I'm running on the boxes in question most recent CURRENT.
 
 On one system, a subsequent start of updating ports starts to freak out when 
 updateing
 lang/gcc: it loops over and over on some ports already updated, especially
 devel/binutils, but the port looping on isn't specific and varies.
 
 On every CURRENT box I tried this morning to update the ports again, I find 
 this
 frsutrating message (depends on installation, but it seems in principal the 
 same, only
 the affected ports in dependency chain varies):
 
  === Gathering distinfo list for installed ports
 
 === Starting check of installed ports for available updates
 === Launching child to update openldap-sasl-client-2.4.39_2 to
 openldap-sasl-client-2.4.40
 
 === All  openldap-sasl-client-2.4.39_2 (1/1)
 
 === Currently installed version: openldap-sasl-client-2.4.39_2
 === Port directory: /usr/ports/net/openldap24-sasl-client
 
 === Launching 'make checksum' for net/openldap24-sasl-client in background
 === Gathering dependency list for net/openldap24-sasl-client from ports
 === Launching child to install 
 net/openldap24-sasl-client/../../ports-mgmt/pkg
 
 === All  openldap-sasl-client-2.4.39_2 
 net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2)
 
 === Port directory: 
 /usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg
 
 
 === Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed
 === Aborting update
 
 === Update for openldap-sasl-client-2.4.39_2 failed
 === Aborting update
 
 You have new mail.
 
 
 This isn't, so far, OpenLDAP specific, on other systems without LDAP the 
 update fails on
 another port.
 
 Oliver
 

I am afraid I am observing something similar to what Oliver reported. On
a CURRENT box (r272295) I get the following for all ports execpt pkg itself:

portmaster indexinfo-0.2

=== Currently installed version: indexinfo-0.2
=== Port directory: /usr/ports/print/indexinfo

=== Gathering distinfo list for installed ports

=== Launching 'make checksum' for print/indexinfo in background
=== Gathering dependency list for print/indexinfo from ports
=== Launching child to install print/indexinfo/../../ports-mgmt/pkg

=== indexinfo-0.2  print/indexinfo/../../ports-mgmt/pkg (1/1)

=== Port directory: /usr/ports/print/indexinfo/../../ports-mgmt/pkg

=== Update for print/indexinfo/../../ports-mgmt/pkg failed
=== Aborting update


When I try to build other ports, it does not complain about
ports-mgmt/pkg, but something else in the dependency list. For example,
for net/mpich2 it complains about devel/binutils ...


This does not happen on my other CURRENT boxes (they build ports as
exected). All systems have pkg-1.3.8_2 installed. The main difference
between these boxes is, that the boxes without problems come from older
installations, which were converted via pkg2ng.

Only the box in question has all ports built and installed from scratch
after installing pkg, without any installations via pkg_* before.

As far as I can say, all went well until r369572. After svn'ing to a
more recent revision, I was not able to build ports any more ...

HTH,
Rainer Hurling

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

Re: pkg/ports system terribly messed up?

[Rainer Hurling]

Am 01.10.2014 um 05:44 schrieb Chuck Burns:

On Tuesday, September 30, 2014 8:13:01 AM O. Hartmann wrote:

Hello.

I just made the last update of the ports yesterday (I use portmaster -da
performing this task) and obviously or superficially everything went all
right.



snip

It's portmaster actually.  While it -usually- works great, I've noticed that
occassionally it loops like that.

kill the script, upgrade the port that is looping.


Because it seems that I have the same problem as Oliver: What script you 
are talking about?




That usually fixes it.



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

Re: pkg/ports system terribly messed up?

[Rainer Hurling]

Am 02.10.2014 um 04:40 schrieb Chuck Burns:
 On Wednesday, October 01, 2014 7:48:08 AM Rainer Hurling wrote:
 Am 01.10.2014 um 05:44 schrieb Chuck Burns:
 On Tuesday, September 30, 2014 8:13:01 AM O. Hartmann wrote:
 Hello.

 I just made the last update of the ports yesterday (I use 
 portmaster -da
 performing this task) and obviously or superficially everything 
 went all
 right.

 snip

 It's portmaster actually.  While it -usually- works great, I've noticed
 that occassionally it loops like that.

 kill the script, upgrade the port that is looping.

 Because it seems that I have the same problem as Oliver: What script 
 you
 are talking about?

 That usually fixes it.
 
 portmaster is just a (not-so-)simple shell script.  Kill portmaster (CTRL-C 
 a few times) then build the offending port with make  make 
 deinstall reinstall clean
 
Thanks for your answer. I tried it, but unfortunately, this does not
change my problems with using portmaster for updating ports.

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

Re: pkg/ports system terribly messed up?

[Rainer Hurling]

Am 01.10.2014 um 22:17 schrieb NGie Cooper:
 On Mon, Sep 29, 2014 at 11:13 PM, O. Hartmann
 ohart...@zedat.fu-berlin.de wrote:

 Hello.

 I just made the last update of the ports yesterday (I use portmaster -da 
 performing this
 task) and obviously or superficially everything went all right.

 I'm running on the boxes in question most recent CURRENT.

 On one system, a subsequent start of updating ports starts to freak out when 
 updateing
 lang/gcc: it loops over and over on some ports already updated, especially
 devel/binutils, but the port looping on isn't specific and varies.

 On every CURRENT box I tried this morning to update the ports again, I find 
 this
 frsutrating message (depends on installation, but it seems in principal the 
 same, only
 the affected ports in dependency chain varies):
 
 Are you using portmaster? If so, it might be fallout from r272282.
 Cheers,

Yup, after defining

setenv PORTSDIR /usr/ports

my problems, described on my mail in this thread from 30th September,
completely went away.

Thanks for this hint. It helps a lot!

Regards,
Rainer Hurling

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

Upgrade to Unbound 1.5.1 incomplete?

[Rainer Hurling]

It seems, that r276605 is missing a file 'dnstap/dnstap_config.h'.

At least, I get this output, when I try to build world now:


--- depend_subdir_libunbound ---
In file included from
/usr/src/lib/libunbound/../../contrib/unbound/util/netevent.c:48:
/usr/src/lib/libunbound/../../contrib/unbound/dnstap/dnstap.h:38:10:
fatal error: 'dnstap/dnstap_config.h' file not found
#include dnstap/dnstap_config.h
 ^
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Error building x11/nvidia-driver kernel module @r284408

[Rainer Hurling]

Am 15.06.2015 um 22:07 schrieb David Wolfskill:
 On Mon, Jun 15, 2015 at 11:33:47AM -0700, Simon J. Gerraty wrote:
 Garrett Cooper yaneurab...@gmail.com wrote:
 Now that vanilla head @284408 builds ( boots):


 I fixed this the other day - just realized I haven't committed it.

 make[6]: don't know how to make 
 /common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src/machine.
  Stop

 
 OK; following up: I see Simon committed r284420; after hand-appling that
 (1-line fix); I performed:
 
 make -DNOCLEAN -j16 buildkernel
 make installkernel
 ... [mergemaster c...]
 make installworld
 ...
 make delete-old
 
 for each of head/amd64  head/i386 on my laptop; since /etc/src.conf is:
 
 KERNCONF=CANARY
 PORTS_MODULES=x11/nvidia-driver
 PORTS_MODULES+=multimedia/cuse4bsd-kmod
 PORTS_MODULES+=emulators/virtualbox-ose-kmod
 WITHOUT_DEBUG_FILES=1
 IWN_DEBUG=1
 IEEE80211_DEBUG=1
 
 the above process also built kernel modules for x11/nvidia-driver,
 multimedia/cuse4bsd-kmod, and emulators/virtualbox-ose-kmod.
 
 Each was successful:
 
 FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #95  
 r284408M/284408:1100077: Mon Jun 15 06:09:41 PDT 2015 
 r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64
 
 FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #30  
 r284408M/284408:1100077: Mon Jun 15 07:25:43 PDT 2015 
 r...@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386
 
 Peace,
 david
 

I just tried r284421 and get another error. My '/etc/src.conf' includes
'WITH_LLDB=1':


[..snip..]
--- usr.bin.all__D ---
--- all_subdir_clang ---
--- all_subdir_lldb ---
c++: error: linker command failed with exit code 1 (use -v to see
invocation)
*** [lldb] Error code 1

make[5]: stopped in /usr/src/usr.bin/clang/lldb
.CURDIR='/usr/src/usr.bin/clang/lldb'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/usr.bin/clang/lldb'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH='/usr/local/grass/lib'
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH=''
MAKE_VERSION='20150606'
SRCTOP='/usr/src'
OBJTOP=''
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/bsd.mkopt.mk
/etc/make.conf /usr/src/share/mk/local.sys.mk
/usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/share/mk/bsd.cpu.mk
/usr/src/usr.bin/clang/lldb/Makefile /usr/src/share/mk/bsd.own.mk
/usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.compiler.mk
/usr/src/usr.bin/clang/clang.prog.mk /usr/src/lib/clang/clang.build.mk
/usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.prog.mk
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk
/usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.files.mk
/usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk
/usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk
/usr/src/share/mk/bsd.sys.mk /usr/obj/usr/src/usr.bin/clang/lldb/.depend'
.PATH='. /usr/src/usr.bin/clang/lldb
/usr/src/usr.bin/clang/lldb/../../../contrib/llvm/tools/lldb/tools/driver'
1 error

make[5]: stopped in /usr/src/usr.bin/clang/lldb
.CURDIR='/usr/src/usr.bin/clang/lldb'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/usr.bin/clang/lldb'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH='/usr/local/grass/lib'
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH=''
MAKE_VERSION='20150606'
SRCTOP='/usr/src'
OBJTOP=''
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/bsd.mkopt.mk
/etc/make.conf /usr/src/share/mk/local.sys.mk
/usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/share/mk/bsd.cpu.mk
/usr/src/usr.bin/clang/lldb/Makefile /usr/src/share/mk/bsd.own.mk
/usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.compiler.mk
/usr/src/usr.bin/clang/clang.prog.mk /usr/src/lib/clang/clang.build.mk
/usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.prog.mk
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk
/usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.files.mk
/usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk
/usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk
/usr/src/share/mk/bsd.sys.mk /usr/obj/usr/src/usr.bin/clang/lldb/.depend'
.PATH='. /usr/src/usr.bin/clang/lldb
/usr/src/usr.bin/clang/lldb/../../../contrib/llvm/tools/lldb/tools/driver'
*** [all_subdir_lldb] Error code 2

make[4]: stopped in /usr/src/usr.bin/clang
.CURDIR='/usr/src/usr.bin/clang'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/usr.bin/clang'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH='/usr/local/grass/lib'
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH=''
MAKE_VERSION='20150606'
SRCTOP='/usr/src'
OBJTOP=''
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/bsd.mkopt.mk
/etc/make.conf 

Re: freebsd-current compile with clang & ccache

[Rainer Hurling]

Am 25.11.15 um 20:37 schrieb Bryan Drewery:
> On 11/25/2015 11:34 AM, Rainer Hurling wrote:
>> Am 25.11.15 um 19:50 schrieb Bryan Drewery:
>>> On 11/25/2015 10:09 AM, Juan Molina wrote:
>>>>> On 11/24/2015 1:31 AM, M - Krasznai András wrote:
>>>>>> /What can I do to eliminate the ccache error during installworld
>>>>> apart from not using ccache? /
>>>>> I would recommend not setting CC or CCACHE_PATH in make.conf and using
>>>>> the new WITH_CCACHE_BUILD=yes option instead.
>>>>>
>>>>> -- 
>>>>> Regards,
>>>>> Bryan Drewery
>>>>
>>>> Hi.
>>>>
>>>> I’m seeing the same ccache errors and I do not have CC or CCACHE_PATH
>>>> defined anywhere. Only WITH_CCACHE_BUILD and WITH_FAST_DEPEND in src.conf.
>>>>
>>>
>>> WITH_FAST_DEPEND is not related.
>>>
>>> Are you building and installing as a different user? Using a different
>>> MAKEOBJDIRPREFIX in build and install?
>>>
>>> Do you have CCACHE_PATH in your environment?
>>>
>>> Run 'make ccache-print-options|grep path'. It should have no value.
>>>
>>
>> Is there any possibility to redirect the .ccache directory, something
>> like CCACHE_PATH for userland?
>>
>> I am asking, because in my attempts to build base with WITH_CCACHE_BUILD
>> and WITH_FAST_DEPEND enabled, it breaks with error message 'file system
>> full'. My root partition has only 1GB and ccache itself seems to need
>> more than 800MB in /root/.ccache.
>>
> 
> You want to modify CCACHE_DIR. You can do this in make.conf or the
> environment.
> 
> I tend to just symlink /root/.ccache to somewhere else though and let
> the default work via the symlink.
> 
> Also see 'man src.conf' (WITH_CCACHE_BUILD section) and 'man ccache'.
> 

Oops, I should have looked into man src.conf before asking here, sorry.

And many thanks for the quick and helpful answer.
___
freebsd-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-current compile with clang & ccache

[Rainer Hurling]

Am 25.11.15 um 19:50 schrieb Bryan Drewery:
> On 11/25/2015 10:09 AM, Juan Molina wrote:
>>> On 11/24/2015 1:31 AM, M - Krasznai András wrote:
>>>> /What can I do to eliminate the ccache error during installworld
>>> apart from not using ccache? /
>>> I would recommend not setting CC or CCACHE_PATH in make.conf and using
>>> the new WITH_CCACHE_BUILD=yes option instead.
>>>
>>> -- 
>>> Regards,
>>> Bryan Drewery
>>
>> Hi.
>>
>> I’m seeing the same ccache errors and I do not have CC or CCACHE_PATH
>> defined anywhere. Only WITH_CCACHE_BUILD and WITH_FAST_DEPEND in src.conf.
>>
> 
> WITH_FAST_DEPEND is not related.
> 
> Are you building and installing as a different user? Using a different
> MAKEOBJDIRPREFIX in build and install?
> 
> Do you have CCACHE_PATH in your environment?
> 
> Run 'make ccache-print-options|grep path'. It should have no value.
> 

Is there any possibility to redirect the .ccache directory, something
like CCACHE_PATH for userland?

I am asking, because in my attempts to build base with WITH_CCACHE_BUILD
and WITH_FAST_DEPEND enabled, it breaks with error message 'file system
full'. My root partition has only 1GB and ccache itself seems to need
more than 800MB in /root/.ccache.

Thanks in advance,
Rainer Hurling

___
freebsd-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: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8)

[Rainer Hurling]

Hi Oliver,

Am 02.03.16 um 15:29 schrieb O. Hartmann:

On Tue, 1 Mar 2016 23:39:22 +0200
"Reko Turja"  wrote:


-Original Message-
From: O. Hartmann
Subject: mounting CIFS share (tcp/455) with FreeBSD and mount_smbfs(8)


I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445
as NetBIOS service (tcp/139) has been deprecated due to serious
vulnerability issues. .
.
.
I desperately need CIFS and I need tcp/445 since tcp/139 is from now on
firewalled.


There's actually alternative available that's far more UNIX-friendly and not
depending on the SAMBA foibles.

https://technet.microsoft.com/en-us/library/jj574143.aspx?f=255=-2147217396

Of course, you need to have admin access to the server or get the admins
enable NFS on it.

-Reko

(I've used the Windows NFS the other way around- FreeBSD NFS shares mounted
with on Win7.) ___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Using others than CIFS is impossible, I'm dependend on existing services.
Within the next forseable time port tcp/139 gets firewalled.

So far I have compiled NETSMB, SMBFS, LIBMCHAIN and LIBICONV (I think the
latter two are prerequests for NETSMB/SMBFS, didn't find much in the very
sparse and unfinished docs for that subject!) into the kernel.

I found this following the exact subject I ran into:

http://agreif.blogspot.de/2014/01/blog-post.html

It doesn't work with either SAMBA 4.3 or Windows Server 2012 R2. Consider the
following situation.

Windows/samba server has IP 10.0.0.1, it's WINS name is locus, its domain is
ASUF the user is pimmel. The passowrd is in /etc/nsmb.conf,
hashed:


[default]
charsets=utf-8:utf-8

[LOCUS:PIMMEL]
address=10.0.0.1
password=$$ajdhasuih57

The, following the above instructions, the mount_smbfs(8) command would be

mount_smbfs -I10.0.0.1 -Wasuf -N //pimmel@10.0.0.1:445/share /mnt

If -W is fed with ASUF (all uppercase), I get a strange error:

mount_smbfs: invalid local charset specification (IT4)

Connecting to the SAMBA 4.3 server, and with -Wasuf, I get

mount_smbfs: unable to open connection: syserr = RPC struct is bad

Connectingto the Windows 2012 R2 server results in

mount_smbfs: unable to open connection: syserr = Connection reset by peer

First, the manpage for mount_smbfs(8) is everything else than FreeBSD standard!
There is an unexplained option "-n opt". What is that?

Second, CIFS over tcp/445 seems to be now very(!) common in the Windooze world
- why is that fact not reflected by FreeBSD? I tried to find some
explanations/manpages for "man netsmb" or "smbfs" (the kernel options), but
none found :-(

My interpretation of the above errors are: FreeBSD is incapable to handle CIFS
over tcp/445. The above URL/site claims to have solved the problem, but it
seems not true for CURRENT.


For me, the described scenario works well with base smbfs (on recent 
HEAD amd64). My configuration differs in some way from yours.


GROUPNAME, SERVERNAME, and USERNAME should be written in capital letters 
(?), domainname\\username in small letters (?):



# ---
#cat /etc/nsmb.conf
...
[default]
workgroup=GROUPNAME

[SERVERNAME]
nbns=xxx.xxx.xxx.xxx  (IPv4 address)
charsets=UTF-8:CP866
addr=servername.xxx.de

[SERVERNAME:USERNAME]
username=domainname\\username
password=HASHED_PASSWORD


# ---
My entries in /etc/fstab look like this:
...
### Mountpoints for mount_smbfs (of base system)
//username@servername/dir   /SMB/DIRsmbfs   rw,late 0   0

[and this also works with port 445:]
//username@servername:445/dir   /SMB/DIRsmbfs   rw,late 0   0


# ---
!!! If this was a real hashed password in your mail above, you should 
change it ...


HTH and greetings,
Rainer

___
freebsd-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: HEAD does not build bwn (after r297405 ?)

[Rainer Hurling]

Am 30.03.16 um 13:08 schrieb Jia-Shiun Li:

On Wed, Mar 30, 2016 at 2:06 PM, Rainer Hurling <rhur...@gwdg.de
<mailto:rhur...@gwdg.de>> wrote:

If I try to build most recent HEAD (r297407), I get the following error:

I suspect r297405 with its migration of time_* macros to be the reason?


Adrian Chadd fixed that in r297409.


Thanks for the info. I already noticed it and rebuild my box. Works fine 
so far.




-Jia-Shiun.



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

HEAD does not build bwn (after r297405 ?)

[Rainer Hurling]

If I try to build most recent HEAD (r297407), I get the following error:


[..snip..]
===> bwn (all)
machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h
/usr/local/bin/ccache cc  -O2 -pipe  -fno-strict-aliasing -Werror 
-D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/obj/usr/src/sys/RHURLIN/opt_global.h -I. -I/usr/src/sys -fno-common 
 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I/usr/obj/usr/src/sys/RHURLIN  -MD  -MF.depend.if_bwn.o -MTif_bwn.o 
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__ 
-Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas 
-Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-negative-value 
-Wno-error-sometimes-uninitialized -mno-aes -mno-avx  -std=iso9899:1999 
-c /usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c -o if_bwn.o
/usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c:2615:7: error: implicit 
declaration of function 'time_before' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]

if (time_before(lo->pwr_vec_read_time, expire)) {
^
1 error generated.
*** Error code 1
Stop.
make[4]: stopped in /usr/src/sys/modules/bwn
*** Error code 1



I suspect r297405 with its migration of time_* macros to be the reason?

Regards,
Rainer Hurling
___
freebsd-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: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current

[Rainer Hurling]

Am 27.03.2017 um 10:31 schrieb Andriy Gapon:

On 03/26/2017 00:21, Manfred Antar wrote:

Recent change to genassym.c breaks building a current kernel:

--

stage 3.1: building everything

--
cd /usr/obj/usr/src/sys/pozo; COMPILER_VERSION=4  COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=126 MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE= 
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin  GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font  GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac 
CC="/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="/usr/local/bin/ccache c++  
-target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -target x86_64-unknown-freebsd12.0 
--sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""  NM=nm 
OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"  INSTALL="sh /usr/src/tools/install.sh"  
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/us

r

  /sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make  -m 
/usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ

machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 
--sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe 
-fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD 
-MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx 
-mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual 
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ 
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas 
-Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-negative-value 
-Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso

9

  899:1999 /usr/src/sys/amd64/amd64/genassym.c

In file included from /usr/src/sys/amd64/amd64/genassym.c:47:
/usr/src/sys/sys/bus.h:730:10: fatal error: 'device_if.h' file not found
#include "device_if.h"
  ^
1 error generated.
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/sys/pozo
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src


cd /usr/obj/usr/src/sys/pozo ; make device_if.h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h

also bus_if.h is missing:
(pozo)5023}make
/usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. 
-I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o 
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare 
-Wno-error-empty-body -Wno-error-parentheses-equality 
-Wno-error-unused-function -Wno-error-pointer-sign 
-Wno-error-shift-negative-value -Wno-error-address-of-packed-member -mno-aes 
-mno-avx -std=iso9899:1999 /usr/src/sys/amd64/amd64/genassym.c
In file included from /usr/src/sys/amd64/amd64/genassym.c:47:
/usr/src/sys/sys/bus.h:731:10: fatal error: 'bus_if.h' file not found

so:
make bus_if.h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h
then the build works:

MAKE=make sh /usr/src/sys/conf/newvers.sh  pozo
--- vers.o ---
/usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. 
-I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse 
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual 
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ 
-Wmissing-include-dirs 

Re: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current

[Rainer Hurling]

Am 27.03.2017 um 13:07 schrieb Andriy Gapon:

On 03/27/2017 14:35, Rainer Hurling wrote:

Am 27.03.2017 um 10:31 schrieb Andriy Gapon:

On 03/26/2017 00:21, Manfred Antar wrote:

Recent change to genassym.c breaks building a current kernel:

--

stage 3.1: building everything

--
cd /usr/obj/usr/src/sys/pozo; COMPILER_VERSION=4  COMPILER_TYPE=clang
COMPILER_FREEBSD_VERSION=126 MAKEOBJDIRPREFIX=/usr/obj
MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
CC="/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0
--sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin"
CXX="/usr/local/bin/ccache c++  -target x86_64-unknown-freebsd12.0
--sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp
-target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""  NM=nm
OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"  INSTALL="sh
/usr/src/tools/install.sh"
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr


   /sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make  -m
/usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ

machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0
--sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe
-fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys
-I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD
-MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx
-mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wno-error-shift-negative-value
-Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9

   899:1999 /usr/src/sys/amd64/amd64/genassym.c

In file included from /usr/src/sys/amd64/amd64/genassym.c:47:
/usr/src/sys/sys/bus.h:730:10: fatal error: 'device_if.h' file not found
#include "device_if.h"
   ^
1 error generated.
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/sys/pozo
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src


cd /usr/obj/usr/src/sys/pozo ; make device_if.h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h

also bus_if.h is missing:
(pozo)5023}make
/usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I.
-I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wno-error-shift-negative-value
-Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999
/usr/src/sys/amd64/amd64/genassym.c
In file included from /usr/src/sys/amd64/amd64/genassym.c:47:
/usr/src/sys/sys/bus.h:731:10: fatal error: 'bus_if.h' file not found

so:
make bus_if.h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h
then the build works:

MAKE=make sh /usr/src/sys/conf/newvers.sh  pozo
--- vers.o ---
/usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I.
-I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs

Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832

[Rainer Hurling]

Am 12.01.2018 um 00:03 schrieb Sean Bruno:
> https://reviews.freebsd.org/D13832  <--- test this update
> 
> I'd like to get some feedback from AMD cpu users on this update.  I've
> restructured and undone a few things that may have been keeping folks
> using this port from getting their runtime cpu microcode updates.
> 
> After installing the port, grab your microcode version via
> sysutils/x86info.  If you don't see an update, that only means there is
> no update available for your system.
> 
> x86info -a | grep Microcode
> 
> Run the microcode_update and repeat.  Check /var/log/messages for a
> notification that the code was updated.  You should be able to get
> something like the following for your system if it executed an update:
> 
> root@lab:/home/sbruno # x86info -a | grep "CPU Model"
> CPU Model (x86info's best guess): AMD FX Series Processor (OR-B2)
> 
> root@lab:/home/sbruno # x86info -a | grep Microcode
> Microcode patch level: 0x6000629
> 
> root@lab:/home/sbruno # /usr/local/etc/rc.d/microcode_update onestart
> Updating CPU Microcode...
> Done.
> 
> root@lab:/home/sbruno # x86info -a | grep Microcode
> Microcode patch level: 0x600063d
> 
> root@lab:/home/sbruno # grep microcode_update /var/log/messages
> Jan 10 16:52:26 lab microcode_update:
> /usr/local/share/cpucontrol/microcode_amd_fam15h.bin: updating cpu
> /dev/cpuctl0 to revision 0x600063d... done.
> 

Just for the record, for an older Phenom with dmesg:

CPU: AMD Phenom(tm) II X6 1090T Processor (3214.31-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x100fa0  Family=0x10  Model=0xa  Stepping=0
Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x802009<SSE3,MON,CX16,POPCNT>
  AMD
Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
  AMD
Features2=0x37ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT>
  SVM: NP,NRIP,NAsids=64
  TSC: P-state invariant, performance statistics


#x86info -a | grep "CPU Model"
CPU Model (x86info's best guess): Phenom/Athlon/Sempron/Turion
(II)/Opteron (PH-E0)

#x86info -a | grep Microcode
Microcode patch level: 0x1bf

#/usr/local/etc/rc.d/microcode_update onestart
Updating CPU Microcode...
Done.

#x86info -a | grep Microcode
Microcode patch level: 0x1bf

#grep microcode_update /var/log/messages
---

So no recent update and no log messages, as expected ;)

Regards,
Rainer Hurling
___
freebsd-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: devd in r329188M don't start

[Rainer Hurling]

Am 13.02.2018 um 13:50 schrieb Hans Petter Selasky:

On 02/13/18 10:47, Jakob Alvermark wrote:

+1

My USB mouse was working fine before the switch to devmatch. Now I 
have to 'kldload ums' manually.


Same for USB audio, snd_uaudio.ko was loaded by devd before.



Hi,

This is a known issue.

Can you try the attached patch?

Rebuild devmatch(8) and reinstall /etc/devd/devmatch.conf and 
/etc/rc.d/devmatch only.


--HPS



Is there any chance to get this committed into base in the near future?

Thanks for any answer,
Rainer Hurling
___
freebsd-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: devd in r329188M don't start

[Rainer Hurling]

Am 16.02.2018 um 07:17 schrieb Warner Losh:



On Thu, Feb 15, 2018 at 11:12 PM, Rainer Hurling <rhur...@gwdg.de 
<mailto:rhur...@gwdg.de>> wrote:


Am 13.02.2018 um 13:50 schrieb Hans Petter Selasky:

On 02/13/18 10:47, Jakob Alvermark wrote:

+1

My USB mouse was working fine before the switch to devmatch.
Now I have to 'kldload ums' manually.

Same for USB audio, snd_uaudio.ko was loaded by devd before.


Hi,

This is a known issue.

Can you try the attached patch?

Rebuild devmatch(8) and reinstall /etc/devd/devmatch.conf and
/etc/rc.d/devmatch only.

--HPS



Is there any chance to get this committed into base in the near future?


Yes.

Warner


Nice, 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: pkg does not recognize correct kernel version

[Rainer Hurling]

Am 19.02.2018 um 21:24 schrieb Ronald Klop:
> On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling <rhur...@gwdg.de> wrote:
> 
>> Hi Ronald,
>>
>> Am 19.02.2018 um 20:27 schrieb Ronald Klop:
>>> I just did this.
>>>
>>> root@sjakie ~]# pkg upgrade
>>> Updating FreeBSD repository catalogue...
>>> Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
>>> Fetching packagesite.txz: 100%    6 MiB   6.0MB/s    00:01
>>> Processing entries:   0%
>>> pkg: Newer FreeBSD version for package gnome-menus:
>>> - package: 1200058
>>> - running kernel: 1200056
>>> pkg: repository FreeBSD contains packages for wrong OS version:
>>> FreeBSD:12:amd64
>>> Processing entries: 100%
>>> Unable to update repository FreeBSD
>>> Error updating repositories!
>>>
>>> [root@sjakie ~]# uname -UK
>>> 1200058 1200058
>>>
>>> [root@sjakie ~]# uname -a
>>> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
>>> 12:37:36 CET 2018  
>>> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUGamd64
>>>
>>>
>>>
>>> So uname gives a different version than pkg detects.
>>>
>>> What is happening? pkg update -f gives the same result. -o
>>> OSVERSION=1200058 helps, but does not feel like the right solution.
>>>
>>> Regards,
>>> Ronald.
>>
>> Please try
>>
>> #sysctl kern.osreldate
>> kern.osreldate: 1200058
>>
>> HTH,
>> Rainer Hurling
> 
> 
> [root@sjakie ~]# sysctl kern.osreldate
> kern.osreldate: 1200058
> 
> Regards,
> Ronald.

On my kernel patchlevel 1200058 (r329446) I get:

#pkg update -f
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%944 B   0.9kB/s00:01
Fetching packagesite.txz: 100%6 MiB   1.2MB/s00:05
Processing entries: 100%
FreeBSD repository update completed. 28645 packages processed.
All repositories are up to date.


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

Re: pkg does not recognize correct kernel version

[Rainer Hurling]

Hi Ronald,

Am 19.02.2018 um 20:27 schrieb Ronald Klop:
> I just did this.
> 
> root@sjakie ~]# pkg upgrade
> Updating FreeBSD repository catalogue...
> Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
> Fetching packagesite.txz: 100%    6 MiB   6.0MB/s    00:01
> Processing entries:   0%
> pkg: Newer FreeBSD version for package gnome-menus:
> - package: 1200058
> - running kernel: 1200056
> pkg: repository FreeBSD contains packages for wrong OS version:
> FreeBSD:12:amd64
> Processing entries: 100%
> Unable to update repository FreeBSD
> Error updating repositories!
> 
> [root@sjakie ~]# uname -UK
> 1200058 1200058
> 
> [root@sjakie ~]# uname -a
> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
> 12:37:36 CET 2018
> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG
>  
> amd64
> 
> 
> So uname gives a different version than pkg detects.
> 
> What is happening? pkg update -f gives the same result. -o
> OSVERSION=1200058 helps, but does not feel like the right solution.
> 
> Regards,
> Ronald.

Please try

#sysctl kern.osreldate
kern.osreldate: 1200058

HTH,
Rainer Hurling
___
freebsd-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: r336921 broke booting on MBP 2017, EFIRT related

[Rainer Hurling]

Am 29.08.18 um 15:25 schrieb Kyle Evans:
> On Wed, Aug 29, 2018 at 8:20 AM Rainer Hurling  wrote:
>>
>> Am 29.08.18 um 11:37 schrieb Yuri Pankov:
>>> Hi,
>>>
>>> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
>>> 20180802) fail to boot on MBP 2017:
>>>
>>> kbd0 at kbdmux0
>>> netmap: loaded module
>>> nexus0
>>>
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 2: apic id = 02
>>> fault virtual address  = 0x74c64a50
>>> fault code = supervisor read data, page not present
>>> instruction pointer= 0x20: 0x7abece31
>>> stack pointer  = 0x28: 0x82b2f7c0
>>> frame pointer  = 0x28: 0x82b2f810
>>> code segment   = base 0x0, limit 0xf, type 0x1b
>>>= DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags   = interrupt enabled, resume, IOPL = 0
>>> current process= 0 (swapper)
>>> [ thread pid 0 tid 10 ]
>>> Stopped at  0x7abece31:calll   *0x18(%rax)
>>> db>
>>>
>>> Sadly, there's no support for internal keyboard yet (it's connected via
>>> SPI), and external USB one stops working.
>>>
>>> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
>>>
>>> Some questions here:
>>> - is this something that can/should be fixed?
>>> - can we print some "enabling EFIRT" message to the console to make
>>>   guesses about the problem source a bit easier?
>>
>>
>> I have almost exactly the same trap on a DELL Latitude E6520 with ALPHA3.
> 
> Hmm... that's a good data point. I might have a nearby Dell on-hand
> with same firmware to reproduce with, then.
> 
>> Only _with_ 'OPTIONS EFIRT' enabled in the kernel _and_ deactivating it
>> via efi.rt.disabled=1 in /boot/loader.conf, it works for me.
>>
>> An oddity is, that the spelling of the loader tuneable has to be
>> efi.rt.disabled, not efi.rt_disabled (note the dot instead of an
>> underscore!). The one with the underscore, as mentioned in UPDATING,
>> does not work for me. Isn't this a typo somewhere in the code?
>>
> 
> The UPDATING entry was later amended to reflect the new spelling
> ("efi.rt.disabled")

Oops, I must have missed it. Thanks for the update.

> 
> 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: r336921 broke booting on MBP 2017, EFIRT related

[Rainer Hurling]

Am 29.08.18 um 11:37 schrieb Yuri Pankov:
> Hi,
> 
> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
> 20180802) fail to boot on MBP 2017:
> 
> kbd0 at kbdmux0
> netmap: loaded module
> nexus0
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2: apic id = 02
> fault virtual address  = 0x74c64a50
> fault code = supervisor read data, page not present
> instruction pointer    = 0x20: 0x7abece31
> stack pointer  = 0x28: 0x82b2f7c0
> frame pointer  = 0x28: 0x82b2f810
> code segment   = base 0x0, limit 0xf, type 0x1b
>    = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags   = interrupt enabled, resume, IOPL = 0
> current process    = 0 (swapper)
> [ thread pid 0 tid 10 ]
> Stopped at  0x7abece31:    calll   *0x18(%rax)
> db>
> 
> Sadly, there's no support for internal keyboard yet (it's connected via
> SPI), and external USB one stops working.
> 
> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
> 
> Some questions here:
> - is this something that can/should be fixed?
> - can we print some "enabling EFIRT" message to the console to make
>   guesses about the problem source a bit easier?


I have almost exactly the same trap on a DELL Latitude E6520 with ALPHA3.

Only _with_ 'OPTIONS EFIRT' enabled in the kernel _and_ deactivating it
via efi.rt.disabled=1 in /boot/loader.conf, it works for me.

An oddity is, that the spelling of the loader tuneable has to be
efi.rt.disabled, not efi.rt_disabled (note the dot instead of an
underscore!). The one with the underscore, as mentioned in UPDATING,
does not work for me. Isn't this a typo somewhere in the code?

Regards,
Rainer Hurling
___
freebsd-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: r336921 broke booting on MBP 2017, EFIRT related

[Rainer Hurling]

Am 31.08.18 um 10:27 schrieb Konstantin Belousov:
> On Thu, Aug 30, 2018 at 10:12:33PM +0300, Konstantin Belousov wrote:
>> On Thu, Aug 30, 2018 at 12:22:36PM +0300, Yuri Pankov wrote:
>>> Sorry, I accidentally took the discussion off-list, where Konstantin 
>>> provided some more patches.  I'm attaching the one that finally worked 
>>> for me.  It also adds some diagnostic prints which require bootverbose 
>>> to be enabled.
>>
>> This patch requires some more work to make it committable.
>> Do not try to build it with efirt device in the kernel config,
>> only efirt.ko works, but it can be preloaded from loader.
> 
> A version of the patch which finishes items which I wanted
> to handle, is available both for review and for testing at
> https://reviews.freebsd.org/D16972 .
> 

I tried the patches from D16972 and it seems to work on a DELL Latitude
E6520. It now boots with OPTIONS EFIRT and without efi.rt.disabled=1.

Many 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: r336921 broke booting on MBP 2017, EFIRT related

[Rainer Hurling]

Am 29.08.18 um 16:12 schrieb Kyle Evans:
> On Wed, Aug 29, 2018 at 6:53 AM Yuri Pankov  wrote:
>>
>> Yuri Pankov wrote:
>>> Konstantin Belousov wrote:
>>>> On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:
>>>>> Hi,
>>>>>
>>>>> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
>>>>> 20180802) fail to boot on MBP 2017:
>>>>>
>>>>> kbd0 at kbdmux0
>>>>> netmap: loaded module
>>>>> nexus0
>>>>>
>>>>> Fatal trap 12: page fault while in kernel mode
>>>>> cpuid = 2: apic id = 02
>>>>> fault virtual address  = 0x74c64a50
>>>>> fault code = supervisor read data, page not present
>>>>> instruction pointer= 0x20: 0x7abece31
>>>>> stack pointer  = 0x28: 0x82b2f7c0
>>>>> frame pointer  = 0x28: 0x82b2f810
>>>>> code segment   = base 0x0, limit 0xf, type 0x1b
>>>>>  = DPL 0, pres 1, long 1, def32 0, gran 1
>>>>> processor eflags   = interrupt enabled, resume, IOPL = 0
>>>>> current process= 0 (swapper)
>>>>> [ thread pid 0 tid 10 ]
>>>>> Stopped at  0x7abece31:calll   *0x18(%rax)
>>>>> db>
>>>>>
>>>>> Sadly, there's no support for internal keyboard yet (it's connected via
>>>>> SPI), and external USB one stops working.
>>>>>
>>>>> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
>>>>>
>>>>> Some questions here:
>>>>> - is this something that can/should be fixed?
>>>>> - can we print some "enabling EFIRT" message to the console to make
>>>>> guesses about the problem source a bit easier?
>>>>
>>>> It is not in 'enabling'.  Looking at the faulting VA, I believe that
>>>> it occurs inside the BIOS code.
>>>>
>>>> Disable efirt by removing the kernel option, then try to load the module
>>>> at runtime.  Does it still fault ?  Also, get the efi mem map for the
>>>> machine and look at which region the faulting address and the faulting
>>>> instruction belong.
>>>
>>> kldload'ing the efirt module gets the same fault.  Several top lines of
>>> backtrace:
>>>
>>> kernphys() at 0x7abece31
>>> efi_get_time() at efi_get_time+0xd9
>>> efirtc_probe() at efirtc_probe+0x17
>>
>> For the efi mem map, if I'm understanding it correctly, there's the
>> following:
>>
>> ...
>> BootServicesData 7421d000  0a8b UC WC WT WB
>> ...
>> RuntimeServicesCode 7ab9f000  0070 UC WC WT WB
>> ...
>>
> 
> Hi,
> 
> I guess this patch might do it:
> https://people.freebsd.org/~kevans/efi-bootmap.diff
> 
> Linux commit messages depict a tale in which they used to also only
> map RUNTIME entries, but they were effectively forced to back down on
> that because of buggy firmware that does exactly what you've described
> and they later reintroduced the restrictive mapping for i386-only
> where they'd not found such bugs.
> 
> Thanks,
> 
> Kyle Evans

Hi Kyle,

After Yuri had no success with the patches of kib, I tried your patch on
a DELL Latitude E6520 with BIOS version A21.

Kernel config file contains OPTIONS EFIRT, efi.rt.disabled is commented
out in /boot/loader.conf.

Unfortunately, it also does not work. My trap message is this:


[..snip..]
netmap: loaded module
kbd1 at kbdmux0
nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX
platforms 390.77  Tue Jul. 10 21:54:30 PDT 2018
nexus0

Fatal trap 12: page fault while in kernel mode
cpuid = 0: apic id = 00
fault virtual address  = 0xce09ee60
fault code = supervisor read data, page not present
instruction pointer= 0x20: 0xcf58334d
stack pointer  = 0x28: 0x83252920
frame pointer  = 0x28: 0x832529a0
code segment   = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags   = interrupt enabled, resume, IOPL = 0
current process= 0 (swapper)
trap number= 12
panic: page fault
cpuid = 0
time = 1
Uptime: 1s
Automatic reboot in 15 seconds ...


Regards,
Rainer Hurling
___
freebsd-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: r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)

[Rainer Hurling]

Am 16.06.19 um 18:33 schrieb Warner Losh:
> 
> 
> On Sun, Jun 16, 2019, 9:51 AM Rainer Hurling  <mailto:rhur...@gwdg.de>> wrote:
> 
> If I try to build world almost recent sources (r349100) on HEAD amd64
> (r348775), it stops with the following error:
> 
> 
> [..snip..]
> (cd /usr/src/tests/sys/kern &&  DEPENDFILE=.depend.libkern_crc32
> NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t
> PROG=libkern_crc32 )
> echo libkern_crc32: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.a
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libprivateatf-c.a >>
> .depend.libkern_crc32
> cc -target x86_64-unknown-freebsd13.0
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe
> -DUSERSPACE_TESTING -MD  -MF.depend.libkern_crc32.libkern_crc32.o
> -MTlibkern_crc32.o -std=gnu99 -fstack-protector-strong -Wsystem-headers
> -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
> -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member   -Qunused-arguments   -c
> /usr/src/tests/sys/kern/libkern_crc32.c -o libkern_crc32.o
> cc -target x86_64-unknown-freebsd13.0
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DUSERSPACE_TESTING
> -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall
> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
> -Wno-unused-local-typedef -Wno-address-of-packed-member
> -Qunused-arguments -DUSERSPACE_TESTING    -o libkern_crc32
> libkern_crc32.o  /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
> /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
> ld: error: duplicate symbol: sse42_crc32c
> >>> defined at crc32_sse42.c
> >>>            /tmp/crc32_sse42-2988bd.o:(sse42_crc32c)
> >>> defined at crc32_sse42.c
> >>>            /tmp/crc32_sse42-bcf3d2.o:(.text+0x3C0)
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** [libkern_crc32] Error code 1
> make[6]: stopped in /usr/src/tests/sys/kern
> 1 error
> make[6]: stopped in /usr/src/tests/sys/kern
> *** [libkern_crc32] Error code 2
> 
> 
> This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom
> II X6 1090T).
> 
> Am I the only one, who observes this breakage? Thanks for any hint.
> 
> 
> Try adding -DWITHOUT_TESTS to buildworld...
> 
> Warner
> 
> 
> Regards,
> Rainer Hurling



Many thanks Warner,

With -DWITHOUT_TESTS buildworld was able to finish. Is it secure to also
install it now?

BTW, in Poudriere, the same breakage seems to happen.

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

r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)

[Rainer Hurling]

If I try to build world almost recent sources (r349100) on HEAD amd64
(r348775), it stops with the following error:


[..snip..]
(cd /usr/src/tests/sys/kern &&  DEPENDFILE=.depend.libkern_crc32
NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t
PROG=libkern_crc32 )
echo libkern_crc32: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.a
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libprivateatf-c.a >>
.depend.libkern_crc32
cc -target x86_64-unknown-freebsd13.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe
-DUSERSPACE_TESTING -MD  -MF.depend.libkern_crc32.libkern_crc32.o
-MTlibkern_crc32.o -std=gnu99 -fstack-protector-strong -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of-packed-member   -Qunused-arguments   -c
/usr/src/tests/sys/kern/libkern_crc32.c -o libkern_crc32.o
cc -target x86_64-unknown-freebsd13.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DUSERSPACE_TESTING
-std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
-Wno-unused-local-typedef -Wno-address-of-packed-member
-Qunused-arguments -DUSERSPACE_TESTING-o libkern_crc32
libkern_crc32.o  /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
/usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
ld: error: duplicate symbol: sse42_crc32c
>>> defined at crc32_sse42.c
>>>/tmp/crc32_sse42-2988bd.o:(sse42_crc32c)
>>> defined at crc32_sse42.c
>>>/tmp/crc32_sse42-bcf3d2.o:(.text+0x3C0)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [libkern_crc32] Error code 1
make[6]: stopped in /usr/src/tests/sys/kern
1 error
make[6]: stopped in /usr/src/tests/sys/kern
*** [libkern_crc32] Error code 2


This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom
II X6 1090T).

Am I the only one, who observes this breakage? Thanks for any hint.

Regards,
Rainer Hurling
___
freebsd-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: r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)

[Rainer Hurling]

Am 19.06.19 um 21:20 schrieb Bryan Drewery:
> On 6/19/19 11:05 AM, Bryan Drewery wrote:
>> On 6/19/19 11:02 AM, Bryan Drewery wrote:
>>> On 6/16/19 9:33 AM, Warner Losh wrote:
>>>> On Sun, Jun 16, 2019, 9:51 AM Rainer Hurling  wrote:
>>>>
>>>>> If I try to build world almost recent sources (r349100) on HEAD amd64
>>>>> (r348775), it stops with the following error:
>>>>>
>>>>>
>>>>> [..snip..]
>>>>> (cd /usr/src/tests/sys/kern &&  DEPENDFILE=.depend.libkern_crc32
>>>>> NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t
>>>>> PROG=libkern_crc32 )
>>>>> echo libkern_crc32: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.a
>>>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libprivateatf-c.a >>
>>>>> .depend.libkern_crc32
>>>>> cc -target x86_64-unknown-freebsd13.0
>>>>> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
>>>>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe
>>>>> -DUSERSPACE_TESTING -MD  -MF.depend.libkern_crc32.libkern_crc32.o
>>>>> -MTlibkern_crc32.o -std=gnu99 -fstack-protector-strong -Wsystem-headers
>>>>> -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
>>>>> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
>>>>> -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
>>>>> -Wno-string-plus-int -Wno-unused-const-variable
>>>>> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
>>>>> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
>>>>> -Wno-address-of-packed-member   -Qunused-arguments   -c
>>>>> /usr/src/tests/sys/kern/libkern_crc32.c -o libkern_crc32.o
>>>>> cc -target x86_64-unknown-freebsd13.0
>>>>> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
>>>>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DUSERSPACE_TESTING
>>>>> -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall
>>>>> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
>>>>> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
>>>>> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
>>>>> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
>>>>> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
>>>>> -Wno-unused-local-typedef -Wno-address-of-packed-member
>>>>> -Qunused-arguments -DUSERSPACE_TESTING-o libkern_crc32
>>>>> libkern_crc32.o  /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
>>>>> /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
>>>>> ld: error: duplicate symbol: sse42_crc32c
>>>>>>>> defined at crc32_sse42.c
>>>>>>>>/tmp/crc32_sse42-2988bd.o:(sse42_crc32c)
>>>>>>>> defined at crc32_sse42.c
>>>>>>>>/tmp/crc32_sse42-bcf3d2.o:(.text+0x3C0)
>>>>> cc: error: linker command failed with exit code 1 (use -v to see
>>>>> invocation)
>>>>> *** [libkern_crc32] Error code 1
>>>>> make[6]: stopped in /usr/src/tests/sys/kern
>>>>> 1 error
>>>>> make[6]: stopped in /usr/src/tests/sys/kern
>>>>> *** [libkern_crc32] Error code 2
>>>>>
>>>>>
>>>>> This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom
>>>>> II X6 1090T).
>>>>>
>>>>> Am I the only one, who observes this breakage? Thanks for any hint.
>>>>>
>>>>
>>>> Try adding -DWITHOUT_TESTS to buildworld...
>>>>
>>>> Warner
>>>>
>>>
>>> ~/git/freebsd2/tests/sys/kern # env|grep TEST
>>> MK_TESTS=no
>>>
>>>
>>> Doh. Turns out I've had TESTS disabled in some of my recent build tests
>>> / commits. This is likely my fault.
>>>
>>
>> Yup it is from my r349065.
>>
>> It's an ambiguity between LDADD. and my newly added
>> LDADD..
>>
>> LDADD.libkern_crc32+=   ${SRCTOP}/sys/libkern/x86/crc32_sse42.c
>>
>> So it's added in twice.
>>
>>
> 
> This should be fixed in r349202. Sorry for the trouble.
> 

Many thanks for this fix. It works fine for me on the box with Intel
Core 17-4770, but it fails on AMD Phenom II X6 1090T (both systems
mentioned in the initial mail):


[..

r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Since r365488 (and above until recent) my box breaks with the following
error when starting:

Fatal trap 12: page fault while in kernel mode
cpuid = 31; apic id = 1f
fault virtual address   = 0x0
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x808f452b
stack pointer   = 0x28:0x81711800
frame pointer   = 0x28:0x81711800
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 31
time = 1



Some infos about the system, the page fault occurs:

CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz
K8-class CPU)
  Origin="AuthenticAMD"  Id=0x870f10  Family=0x17  Model=0x71  Stepping=0
Features=0x178bfbff
Features2=0x7ed8320b
  AMD Features=0x2e500800
  AMD
Features2=0x75c237ff
  Structured Extended
Features=0x219c91a9
  Structured Extended Features2=0x44
  XSAVE Features=0xf
  AMD Extended Feature Extensions ID
EBX=0x108b657
  SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
  TSC: P-state invariant, performance statistics
real memory  = 68717379584 (65534 MB)
avail memory = 66756149248 (63663 MB)
Event timer "LAPIC" quality 600


#cat /etc/sysctl.conf
security.bsd.map_at_zero=1
kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules
kern.evdev.rcpt_mask=6
kern.maxfiles=49312
kern.ipc.shm_allow_removed=1
kern.ipc.maxsockbuf=16777216
vfs.usermount=1
net.inet.tcp.rfc1323=1
net.inet.tcp.sack.enable=1
net.inet.tcp.sendbuf_auto=1
net.inet.tcp.recvbuf_auto=1
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet6.ip6.use_tempaddr=1
net.inet6.ip6.prefer_tempaddr=1
net.local.stream.recvspace=65536
net.local.stream.sendspace=65536


Please let me know, if I should provide more info or test something.
Thanks in advance,
Rainer
___
freebsd-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: buildworld: "cp: /dev/null: Invalid argument"

[Rainer Hurling]

Am 12.09.20 um 11:05 schrieb Hartmann, O.:
> On Sat, 12 Sep 2020 10:03:18 +0200
> Michael Gmelin  wrote:
> 
>>> On 12. Sep 2020, at 09:55, Hartmann, O. 
>>> wrote:
>>>
>>> On Fri, 11 Sep 2020 07:18:33 -0600
>>> Alan Somers  wrote:
>>>   
> On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann
>  wrote:
>
> On Thu, 10 Sep 2020 10:44:08 -0600
> Alan Somers  wrote:
>   
>> No, it's devfs.  I'll fix it.
>>
>> On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone 
>> wrote:   
>>> I'm curious: does this give a similar issue?
>>>
>>> touch /tmp/foo
>>> cp /tmp/foo /tmo/foo2
>>>
>>> I'm wondering if the issue is that copy_file_range isn't
>>> handling empty files, or if it's a devfs issue.
>>>
>>>
>>> On Thu, Sep 10, 2020 at 11:45 AM Michael Butler
>>>  wrote:

 It seems that SVN r365549 broke "cp /dev/null ..."

imb

 On 9/10/20 10:35 AM, Michael Butler wrote:
> Is anyone else seeing failures like this in building world
> and, in
> my
> case, cron jobs as well?
>
>
> Building
> /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr
> --- all_subdir_sbin ---
> Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel
> --- all_subdir_stand ---
> --- zfsboot.ldr ---
> cp: /dev/null: Invalid argument
> *** [zfsboot.ldr] Error code 1
> make[5]: *** zfsboot.ldr removed
> --- all_subdir_kerberos5 ---
> Building
>>> /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log
>>>   
> --- all_subdir_stand ---
>
> make[5]: stopped in /usr/src/stand/i386/zfsboot
> .ERROR_TARGET='zfsboot.ldr'
>   
>>>   
> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta'
>   
>>>   
> .MAKE.LEVEL='5'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes
> silent=yes
>>> verbose'
> _ERROR_CMD='cp /dev/null zfsboot.ldr;'
> .CURDIR='/usr/src/stand/i386/zfsboot'
> .MAKE='make'
> .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot'
> .TARGETS='all'
> DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp'
> LD_LIBRARY_PATH=''
> MACHINE='amd64'
> MACHINE_ARCH='amd64'
> MAKEOBJDIRPREFIX=''
> MAKESYSPATH='/usr/src/share/mk'
> MAKE_VERSION='20200902'
>
> ___
> freebsd-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"
>
> I still get this error on a couple of boxes, while others seem to
> buildworld
> fine. All boxes are at CURRENT revision 365625. It is a bit
> looking weird to
> me. Running now a make cleanworld/cleandir on the specific boxes
> and start building OS again.
>
> oh
>   

 I don't know why it's intermittent, but in any case this patch
 should fix it:
 https://reviews.freebsd.org/D26395
 -Alan  
>>>
>>> I checked on ALL CURRENT boxes. After "make cleanworld cleandir" (or
>>> just deleting usr/obj/) and starting a fresh build, those boxes
>>> with an newer kernel all fail at the very same point. We use
>>> META_MODE on some boxes, switched to WITHOUT_CLEAN these days and
>>> cleanded up on some systems therefore. That might be the reason why
>>> the problem occurs not consistently on all systems.
>>>
>>> When will the pacth be committed?
>>>   
>>
>> Alan already committed it:
>>
>> https://svnweb.freebsd.org/base?view=revision=365643
>>
>> -m
>>
>>> Thanks in advance,
>>>
>>> oh  
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to
>> "freebsd-current-unsubscr...@freebsd.org"
> 
> Sources at:
> 
> At revision 365652.
> 
> Host is running kernel FreeBSD 13.0-CURRENT #20 r365382: Fri Sep 11
> 19:01:26 CEST 2020 amd64.
> 
> make -j4 buildworld buildkernel
> 
> quit with same error as shown below.
> 
> Is there anything that has to prepared 

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Am 22.09.20 um 00:13 schrieb Konstantin Belousov:

On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote:

Fatal trap 12: page fault while in kernel mode
cpuid = 31; apic id = 1f
fault virtual address   = 0x25407efa

This address is very suspicious.

I cannot claim it as the fact, but most likely cause for such garbage
pointer value is mismatched ABI between kernel and module.  In other
words, the module was built against headers from different kernel.


Hmm, thanks for the pointer. I will double check this evening and 
reporting back.


Normally, this module should have been built and installed with the 
kernel build.





fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80ec0b63
stack pointer   = 0x28:0x826018b0
frame pointer   = 0x28:0x82601940
code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 31
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0x82601560
vpanic() at vpanic+0x182/frame 0x826015b0
panic() at panic+0x43/frame 0x82601610
trap_fatal() at trap_fatal+0x387/frame 0x82601670
trap_pfault() at trap_pfault+0x97/frame 0x826016d0
trap() at trap+0x2ab/frame 0x826017e0
calltrap() at calltrap+0x8/frame 0x826017e0
--- trap 0xc, rip = 0x80ec0b63, rsp = 0x826018b0, rbp =
0x82601940 ---
vm_map_insert() at vm_map_insert+0x2f3/framw 0x82601940
vm_map_find() at vm_map_find+0x4a4/frame 0x82601a00
rtR0MemObjFreeBSDAllocHelper() at
rtR0MemObjFreeBSDAllocHelper+0x96/frame 0x82601a70
rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
0x82601ac0
supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
0x82601bf0
module_register_init() at module_register_init+0xbd/frame 0x82601c20
mi_startup() at mi_startup+0xec/frame 0x82601c70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at  kdb_enter+0x37: movq$0,0x10b5616(%rip)
db>


Perhaps this gives some more insight into the problem? I can't assess,
sorry.


___
freebsd-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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

On 23.09.20 00:51, Mark Johnston wrote:
> On Tue, Sep 22, 2020 at 01:13:29AM +0300, Konstantin Belousov wrote:
>> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote:
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 31; apic id = 1f
>>> fault virtual address   = 0x25407efa
>> This address is very suspicious.
>>
>> I cannot claim it as the fact, but most likely cause for such garbage
>> pointer value is mismatched ABI between kernel and module.  In other
>> words, the module was built against headers from different kernel.
> 
> For some reason clang is not complaining about a missing declaration for
> vm_pager_allocate(), despite -Wmissing-prototypes in the CFLAGS...
> 
> This patch is required on top of a patched extract of the vbox sources:
> 
> --- the-freebsd-kernel.h.orig 2020-09-22 18:49:26.499329000 -0400
> +++ the-freebsd-kernel.h  2020-09-22 18:49:55.317615000 -0400
> @@ -68,6 +68,7 @@
>  #include 
>  #include /* KERN_SUCCESS ++ */
>  #include 
> +#include 
>  #include  /* vm_phys_alloc_* */
>  #include/* kmem_alloc_attr */
>  #include   /* vm_contig_grow_cache */
> --- memobj-r0drv-freebsd.c.orig   2020-09-22 18:49:25.010456000 -0400
> +++ memobj-r0drv-freebsd.c2020-09-22 18:49:47.462276000 -0400
> @@ -323,7 +323,8 @@
>  size_t  cPages = atop(pMemFreeBSD->Core.cb);
>  int rc;
>  
> -pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages);
> +pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL,
> +pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred);
>  
>  /* No additional object reference for auto-deallocation upon unmapping. 
> */
>  #if __FreeBSD_version >= 155
> @@ -457,7 +458,8 @@
>  return VERR_NO_MEMORY;
>  }
>  
> -pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, atop(cb));
> +pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL,
> +pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred);
>  
>  if (PhysHighest != NIL_RTHCPHYS)
>  VmPhysAddrHigh = PhysHighest;
> 

I can confirm that these patches (two files) work for me. The system
reboots with loaded vbox kernel modules.

Many thanks for your help and investigations!

Best regards,
Rainer
___
freebsd-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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

On 22.09.20 07:51, monochrome wrote:
> Rainer, I'm all up and running and clean with the latest again, if it
> still doesn't work after your next try, send me your step-by-step to
> patch and i'll try it here. I'm using ryzen video so I have to disable
> stuff to even see the fault messages.

Hi monochrome,

The attached file is the patched version, I put in the files dir of
emulators/virtualbox-ose (the main port, not the kernel modules one).

Then I rebuilt and reinstall the ports mulators/virtualbox-ose-kmod and
mulators/virtualbox-ose and rebooted the box.

In my case, the boot process freezes after the page fault messages.


> 
> On 9/22/20 1:06 AM, Rainer Hurling wrote:
>> Am 22.09.20 um 00:13 schrieb Konstantin Belousov:
>>> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote:
>>>> Fatal trap 12: page fault while in kernel mode
>>>> cpuid = 31; apic id = 1f
>>>> fault virtual address   = 0x25407efa
>>> This address is very suspicious.
>>>
>>> I cannot claim it as the fact, but most likely cause for such garbage
>>> pointer value is mismatched ABI between kernel and module.  In other
>>> words, the module was built against headers from different kernel.
>>
>> Hmm, thanks for the pointer. I will double check this evening and
>> reporting back.
>>
>> Normally, this module should have been built and installed with the
>> kernel build.
>>
>>>
>>>> fault code  = supervisor read data, page not present
>>>> instruction pointer = 0x20:0x80ec0b63
>>>> stack pointer   = 0x28:0x826018b0
>>>> frame pointer   = 0x28:0x82601940
>>>> code segment    = base 0x0, limit 0xf, type 0x1b
>>>>  = DPL 0, pres 1, long 1, def32 0, gran 1
>>>> processor eflags    = interrupt enabled, resume, IOPL = 0
>>>> current process = 0 (swapper)
>>>> trap number = 12
>>>> panic: page fault
>>>> cpuid = 31
>>>> time = 1
>>>> KDB: stack backtrace:
>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>>> 0x82601560
>>>> vpanic() at vpanic+0x182/frame 0x826015b0
>>>> panic() at panic+0x43/frame 0x82601610
>>>> trap_fatal() at trap_fatal+0x387/frame 0x82601670
>>>> trap_pfault() at trap_pfault+0x97/frame 0x826016d0
>>>> trap() at trap+0x2ab/frame 0x826017e0
>>>> calltrap() at calltrap+0x8/frame 0x826017e0
>>>> --- trap 0xc, rip = 0x80ec0b63, rsp = 0x826018b0, rbp =
>>>> 0x82601940 ---
>>>> vm_map_insert() at vm_map_insert+0x2f3/framw 0x82601940
>>>> vm_map_find() at vm_map_find+0x4a4/frame 0x82601a00
>>>> rtR0MemObjFreeBSDAllocHelper() at
>>>> rtR0MemObjFreeBSDAllocHelper+0x96/frame 0x82601a70
>>>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
>>>> 0x82601ac0
>>>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
>>>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
>>>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
>>>> 0x82601bf0
>>>> module_register_init() at module_register_init+0xbd/frame
>>>> 0x82601c20
>>>> mi_startup() at mi_startup+0xec/frame 0x82601c70
>>>> btext() at btext+0x2c
>>>> KDB: enter: panic
>>>> [ thread pid 0 tid 10 ]
>>>> Stopped at  kdb_enter+0x37: movq    $0,0x10b5616(%rip)
>>>> db>
>>>>
>>>>
>>>> Perhaps this gives some more insight into the problem? I can't assess,
>>>> sorry.
>>

___
freebsd-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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

On 22.09.20 07:06, Rainer Hurling wrote:
> Am 22.09.20 um 00:13 schrieb Konstantin Belousov:
>> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote:
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 31; apic id = 1f
>>> fault virtual address   = 0x25407efa
>> This address is very suspicious.
>>
>> I cannot claim it as the fact, but most likely cause for such garbage
>> pointer value is mismatched ABI between kernel and module.  In other
>> words, the module was built against headers from different kernel.
> 
> Hmm, thanks for the pointer. I will double check this evening and
> reporting back.
> 
> Normally, this module should have been built and installed with the
> kernel build.

As I said, the module was rebuild and reinstalled with the kernel build,
and I double checked, the module was the patched version.

So the boot messages about the page fault should be created by the
rebuild, patched module.

> 
>>
>>> fault code  = supervisor read data, page not present
>>> instruction pointer = 0x20:0x80ec0b63
>>> stack pointer   = 0x28:0x826018b0
>>> frame pointer   = 0x28:0x82601940
>>> code segment    = base 0x0, limit 0xf, type 0x1b
>>>  = DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags    = interrupt enabled, resume, IOPL = 0
>>> current process = 0 (swapper)
>>> trap number = 12
>>> panic: page fault
>>> cpuid = 31
>>> time = 1
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>> 0x82601560
>>> vpanic() at vpanic+0x182/frame 0x826015b0
>>> panic() at panic+0x43/frame 0x82601610
>>> trap_fatal() at trap_fatal+0x387/frame 0x82601670
>>> trap_pfault() at trap_pfault+0x97/frame 0x826016d0
>>> trap() at trap+0x2ab/frame 0x826017e0
>>> calltrap() at calltrap+0x8/frame 0x826017e0
>>> --- trap 0xc, rip = 0x80ec0b63, rsp = 0x826018b0, rbp =
>>> 0x82601940 ---
>>> vm_map_insert() at vm_map_insert+0x2f3/framw 0x82601940
>>> vm_map_find() at vm_map_find+0x4a4/frame 0x82601a00
>>> rtR0MemObjFreeBSDAllocHelper() at
>>> rtR0MemObjFreeBSDAllocHelper+0x96/frame 0x82601a70
>>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
>>> 0x82601ac0
>>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
>>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
>>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
>>> 0x82601bf0
>>> module_register_init() at module_register_init+0xbd/frame
>>> 0x82601c20
>>> mi_startup() at mi_startup+0xec/frame 0x82601c70
>>> btext() at btext+0x2c
>>> KDB: enter: panic
>>> [ thread pid 0 tid 10 ]
>>> Stopped at  kdb_enter+0x37: movq    $0,0x10b5616(%rip)
>>> db>
>>>
>>>
>>> Perhaps this gives some more insight into the problem? I can't assess,
>>> sorry.

___
freebsd-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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

On 20.09.20 22:35, Rainer Hurling wrote:
> On 20.09.20 22:07, Konstantin Belousov wrote:
>> On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote:
>>> On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote:
>>>> Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
>>>>> On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
>>>>>> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
>>>>>>> On 2020-09-20 10:05, Rainer Hurling wrote:
>>>>>>>> Hi monochrome,
>>>>>>>>
>>>>>>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even
>>>>>>>> with newest sources the error occurs.
>>>>>>>>
>>>>>>>> After looking around somewhat more, I found some hints about Virtualbox
>>>>>>>> kernel module having problems with r365488. Unfortunately, I am not 
>>>>>>>> able
>>>>>>>> to find the thread again :(
>>>>>>>>
>>>>>>>> What seems to help as a workaround is to disable the loading of
>>>>>>>> VirtualBox in /boot/loader.conf
>>>>>>>>
>>>>>>>> #vboxdrv_load="YES"
>>>>>>>>
>>>>>>>> and in /etc/rc.conf
>>>>>>>>
>>>>>>>> #vboxnet_enable="YES"
>>>>>>>> #vboxguest_enable="YES"
>>>>>>>>
>>>>>>>>
>>>>>>>> So probably, this page fault is not restricted to AMD Ryzen?
>>>>>>>>
>>>>>>>
>>>>>>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
>>>>>>> version was not bumped correctly.
>>>>>>>
>>>>>>> --HPS
>>>>>>>
>>>>>>
>>>>>> Thanks for the hint. But I did rebuild all kernel modules before
>>>>>> rebooting, in my case vbox*.ko, nvidia*.ko.
>>>>>
>>>>> Provide backtrace of the panic.
>>>>>
>>>>
>>>> Hi Konstantin,
>>>>
>>>> Thanks for your response.
>>>>
>>>> After trying several ways to produce a core dump or a working kdb prompt
>>>> without success, all I can offer is the following screen contents. I
>>>> built a GENERIC kernel with debugging enabled, enable loading of vboxdrv
>>>> via /boot/loader.conf and /etc/rc.conf as described above:
>>>>
>>>>
>>>> [..snip..]
>>>> procfs registered
>>>> modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060,
>>>> 0x82520a70) error 17
>>>> Timecounters tick every 1.000 msec
>>>> lo0: bpf attached
>>>> vlan: initialized, using hash tables with chaining
>>>>
>>>>
>>>> Fatal trap 12: page fault while in kernel mode
>>>> cpuid = 31; apic id = 1f
>>>> fault virtual address   = 0x0
>>>> fault code  = supervisor read data, page not present
>>>> instruction pointer = 0x20:0x80ea889b
>>>> stack pointer   = 0x20:0x826017e0
>>>> frame pointer   = 0x20:0x826017e0
>>>> code segment= base 0x0, limit 0xf, type 0x1b
>>>> = DPL 0, pres 1, long 1, def32 0, gran 1
>>>> processor eflags= interrupt enabled, resume, IOPL = 0
>>>> current process = 0 (swapper)
>>>> trap number = 12
>>>> panic: page fault
>>>> cpuid = 31
>>>> time = 1
>>>> KDB: stack backtrace:
>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>>> 0x82601490
>>>> vpanic() at vpanic+0x182/frame 0x826014e0
>>>> panic() at panic+0x43/frame 0x82601540
>>>> trap_fatal() at trap_fatal+0x387/frame 0x826015a0
>>>> trap_pfault() at trap_pfault+0x97/frame 0x82601600
>>>> calltrap() at calltrap+0x8/frame 0x82601710
>>>> --- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp =
>>>> 0x826017e0 ---
>>>> phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0
>>>> vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830
&g

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Hi monochrome,

back to keyboard, it tried newest CURRENT (r365920) on my box and even
with newest sources the error occurs.

After looking around somewhat more, I found some hints about Virtualbox
kernel module having problems with r365488. Unfortunately, I am not able
to find the thread again :(

What seems to help as a workaround is to disable the loading of
VirtualBox in /boot/loader.conf

#vboxdrv_load="YES"

and in /etc/rc.conf

#vboxnet_enable="YES"
#vboxguest_enable="YES"


So probably, this page fault is not restricted to AMD Ryzen?

HTH,
Rainer


Am 20.09.20 um 08:04 schrieb monochrome:
> I have confirmed that r365487 is the last kernel that will boot on my
> 2400G. These are the files changed between r365487 and r365488:
> 
> U    sys/vm/phys_pager.c
> U    sys/vm/vm_object.c
> U    sys/vm/vm_object.h
> U    sys/vm/vm_pager.h
> 
> 
> 
> On 9/18/20 8:57 AM, Rainer Hurling wrote:
>> Hi,
>> I am AFK until Sunday, so can't investigate ATM.
>> And no, I haven't solved it until now. Thanks for your report.
>> Rainer
>>
>> Am 18. September 2020 00:38:31 MESZ schrieb monochrome
>> :
>>>
>>> forgot you
>>>
>>>  Forwarded Message 
>>> Subject: Re: r365488 page faults on AMD Ryzen 9 3950X
>>> Date: Thu, 17 Sep 2020 17:03:49 -0400
>>> From: monochrome 
>>> To: freebsd-current@freebsd.org
>>>
>>> I am also having this problem. Have you resolved it? Mine is a Ryzen
>>> 5 2400G
>>>
>>> On 9/12/20 5:22 AM, Rainer Hurling wrote:
>>>> Since r365488 (and above until recent) my box breaks with the following
>>>> error when starting:
>>>>
>>>> Fatal trap 12: page fault while in kernel mode
>>>> cpuid = 31; apic id = 1f
>>>> fault virtual address   = 0x0
>>>> fault code  = supervisor read data, page not present
>>>> instruction pointer = 0x20:0x808f452b
>>>> stack pointer   = 0x28:0x81711800
>>>> frame pointer   = 0x28:0x81711800
>>>> code segment    = base 0x0, limit 0xf, type 0x1b
>>>>   = DPL 0, pres 1, long 1, def32 0, gran 1
>>>> processor eflags    = interrupt enabled, resume, IOPL = 0
>>>> current process = 0 (swapper)
>>>> trap number = 12
>>>> panic: page fault
>>>> cpuid = 31
>>>> time = 1
>>>>
>>>>
>>>>
>>>> Some infos about the system, the page fault occurs:
>>>>
>>>> CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz
>>>> K8-class CPU)
>>>>     Origin="AuthenticAMD"  Id=0x870f10  Family=0x17  Model=0x71 
>>>> Stepping=0
>>>> Features=0x178bfbff
>>>>
>>>> Features2=0x7ed8320b
>>>>
>>>>     AMD Features=0x2e500800
>>>>     AMD
>>>> Features2=0x75c237ff
>>>>
>>>>     Structured Extended
>>>> Features=0x219c91a9
>>>>
>>>>     Structured Extended Features2=0x44
>>>>     XSAVE Features=0xf
>>>>     AMD Extended Feature Extensions ID
>>>> EBX=0x108b657
>>>>     SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
>>>>     TSC: P-state invariant, performance statistics
>>>> real memory  = 68717379584 (65534 MB)
>>>> avail memory = 66756149248 (63663 MB)
>>>> Event timer "LAPIC" quality 600
>>>>
>>>>
>>>> #cat /etc/sysctl.conf
>>>> security.bsd.map_at_zero=1
>>>> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules
>>>> kern.evdev.rcpt_mask=6
>>>> kern.maxfiles=49312
>>>> kern.ipc.shm_allow_removed=1
>>>> kern.ipc.maxsockbuf=16777216
>>>> vfs.usermount=1
>>>> net.inet.tcp.rfc1323=1
>>>> net.inet.tcp.sack.enable=1
>>>> net.inet.tcp.sendbuf_auto=1
>>>> net.inet.tcp.recvbuf_auto=1
>>>> net.inet.tcp.sendbuf_max=16777216
>>>> net.inet.tcp.recvbuf_max=16777216
>>>> net.inet6.ip6.use_tempaddr=1
>>>> net.inet6.ip6.prefer_tempaddr=1
>>>> net.local.stream.recvspace=65536
>>>> net.local.stream.sendspace=65536
>>>>
>>>>
>>>> Please let me know, if I should provide more info or test something.
>>>> Thanks in advance,
>>>> Rainer
>>>> ___
>>>> freebsd-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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
> On 2020-09-20 10:05, Rainer Hurling wrote:
>> Hi monochrome,
>>
>> back to keyboard, it tried newest CURRENT (r365920) on my box and even
>> with newest sources the error occurs.
>>
>> After looking around somewhat more, I found some hints about Virtualbox
>> kernel module having problems with r365488. Unfortunately, I am not able
>> to find the thread again :(
>>
>> What seems to help as a workaround is to disable the loading of
>> VirtualBox in /boot/loader.conf
>>
>> #vboxdrv_load="YES"
>>
>> and in /etc/rc.conf
>>
>> #vboxnet_enable="YES"
>> #vboxguest_enable="YES"
>>
>>
>> So probably, this page fault is not restricted to AMD Ryzen?
>>
> 
> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
> version was not bumped correctly.
> 
> --HPS
> 

Thanks for the hint. But I did rebuild all kernel modules before
rebooting, in my case vbox*.ko, nvidia*.ko.

Best wishes,
Rainer
___
freebsd-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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
> On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
>> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
>>> On 2020-09-20 10:05, Rainer Hurling wrote:
>>>> Hi monochrome,
>>>>
>>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even
>>>> with newest sources the error occurs.
>>>>
>>>> After looking around somewhat more, I found some hints about Virtualbox
>>>> kernel module having problems with r365488. Unfortunately, I am not able
>>>> to find the thread again :(
>>>>
>>>> What seems to help as a workaround is to disable the loading of
>>>> VirtualBox in /boot/loader.conf
>>>>
>>>> #vboxdrv_load="YES"
>>>>
>>>> and in /etc/rc.conf
>>>>
>>>> #vboxnet_enable="YES"
>>>> #vboxguest_enable="YES"
>>>>
>>>>
>>>> So probably, this page fault is not restricted to AMD Ryzen?
>>>>
>>>
>>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
>>> version was not bumped correctly.
>>>
>>> --HPS
>>>
>>
>> Thanks for the hint. But I did rebuild all kernel modules before
>> rebooting, in my case vbox*.ko, nvidia*.ko.
> 
> Provide backtrace of the panic.
> 

Hi Konstantin,

Thanks for your response.

After trying several ways to produce a core dump or a working kdb prompt
without success, all I can offer is the following screen contents. I
built a GENERIC kernel with debugging enabled, enable loading of vboxdrv
via /boot/loader.conf and /etc/rc.conf as described above:


[..snip..]
procfs registered
modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060,
0x82520a70) error 17
Timecounters tick every 1.000 msec
lo0: bpf attached
vlan: initialized, using hash tables with chaining


Fatal trap 12: page fault while in kernel mode
cpuid = 31; apic id = 1f
fault virtual address   = 0x0
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80ea889b
stack pointer   = 0x20:0x826017e0
frame pointer   = 0x20:0x826017e0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 31
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0x82601490
vpanic() at vpanic+0x182/frame 0x826014e0
panic() at panic+0x43/frame 0x82601540
trap_fatal() at trap_fatal+0x387/frame 0x826015a0
trap_pfault() at trap_pfault+0x97/frame 0x82601600
calltrap() at calltrap+0x8/frame 0x82601710
--- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp =
0x826017e0 ---
phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0
vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830
vm_fault() at vm_fault+0x5d6/frame 0x82601940
vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0x826019f0
vm_map_wire() at vm_map_wire+0x6b/frame 0x82601a20
rtR0MemObjFreeBSDAllocHelper() at
rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0x82601a70
rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
0x82601ac0
supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
0x82601bf0
module_register_init() at module_register_init+0xbd/frame 0x82601c20
mi_startup() at mi_startup+0xec/frame 0x82601c70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at  kdb_enter+0x37: movq$0,0x10b5796(%rip9
db>


The system freezes at this point, no core dump is generated ;)  This
does not happen without loading VBoxDrv.

At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope,
this is of some help.

Best regards,
Rainer
___
freebsd-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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

On 20.09.20 22:07, Konstantin Belousov wrote:
> On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote:
>> On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote:
>>> Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
>>>> On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
>>>>> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
>>>>>> On 2020-09-20 10:05, Rainer Hurling wrote:
>>>>>>> Hi monochrome,
>>>>>>>
>>>>>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even
>>>>>>> with newest sources the error occurs.
>>>>>>>
>>>>>>> After looking around somewhat more, I found some hints about Virtualbox
>>>>>>> kernel module having problems with r365488. Unfortunately, I am not able
>>>>>>> to find the thread again :(
>>>>>>>
>>>>>>> What seems to help as a workaround is to disable the loading of
>>>>>>> VirtualBox in /boot/loader.conf
>>>>>>>
>>>>>>> #vboxdrv_load="YES"
>>>>>>>
>>>>>>> and in /etc/rc.conf
>>>>>>>
>>>>>>> #vboxnet_enable="YES"
>>>>>>> #vboxguest_enable="YES"
>>>>>>>
>>>>>>>
>>>>>>> So probably, this page fault is not restricted to AMD Ryzen?
>>>>>>>
>>>>>>
>>>>>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
>>>>>> version was not bumped correctly.
>>>>>>
>>>>>> --HPS
>>>>>>
>>>>>
>>>>> Thanks for the hint. But I did rebuild all kernel modules before
>>>>> rebooting, in my case vbox*.ko, nvidia*.ko.
>>>>
>>>> Provide backtrace of the panic.
>>>>
>>>
>>> Hi Konstantin,
>>>
>>> Thanks for your response.
>>>
>>> After trying several ways to produce a core dump or a working kdb prompt
>>> without success, all I can offer is the following screen contents. I
>>> built a GENERIC kernel with debugging enabled, enable loading of vboxdrv
>>> via /boot/loader.conf and /etc/rc.conf as described above:
>>>
>>>
>>> [..snip..]
>>> procfs registered
>>> modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060,
>>> 0x82520a70) error 17
>>> Timecounters tick every 1.000 msec
>>> lo0: bpf attached
>>> vlan: initialized, using hash tables with chaining
>>>
>>>
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 31; apic id = 1f
>>> fault virtual address   = 0x0
>>> fault code  = supervisor read data, page not present
>>> instruction pointer = 0x20:0x80ea889b
>>> stack pointer   = 0x20:0x826017e0
>>> frame pointer   = 0x20:0x826017e0
>>> code segment= base 0x0, limit 0xf, type 0x1b
>>> = DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags= interrupt enabled, resume, IOPL = 0
>>> current process = 0 (swapper)
>>> trap number = 12
>>> panic: page fault
>>> cpuid = 31
>>> time = 1
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>> 0x82601490
>>> vpanic() at vpanic+0x182/frame 0x826014e0
>>> panic() at panic+0x43/frame 0x82601540
>>> trap_fatal() at trap_fatal+0x387/frame 0x826015a0
>>> trap_pfault() at trap_pfault+0x97/frame 0x82601600
>>> calltrap() at calltrap+0x8/frame 0x82601710
>>> --- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp =
>>> 0x826017e0 ---
>>> phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0
>>> vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830
>>> vm_fault() at vm_fault+0x5d6/frame 0x82601940
>>> vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0x826019f0
>>> vm_map_wire() at vm_map_wire+0x6b/frame 0x82601a20
>>> rtR0MemObjFreeBSDAllocHelper() at
>>> rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0x82601a70
>>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
>>&

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Hi, 
I am AFK until Sunday, so can't investigate ATM. 
And no, I haven't solved it until now. Thanks for your report.
Rainer

Am 18. September 2020 00:38:31 MESZ schrieb monochrome 
:
>
>forgot you
>
> Forwarded Message 
>Subject: Re: r365488 page faults on AMD Ryzen 9 3950X
>Date: Thu, 17 Sep 2020 17:03:49 -0400
>From: monochrome 
>To: freebsd-current@freebsd.org
>
>I am also having this problem. Have you resolved it? Mine is a Ryzen 5 2400G
>
>On 9/12/20 5:22 AM, Rainer Hurling wrote:
>> Since r365488 (and above until recent) my box breaks with the following
>> error when starting:
>> 
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 31; apic id = 1f
>> fault virtual address   = 0x0
>> fault code  = supervisor read data, page not present
>> instruction pointer = 0x20:0x808f452b
>> stack pointer   = 0x28:0x81711800
>> frame pointer   = 0x28:0x81711800
>> code segment= base 0x0, limit 0xf, type 0x1b
>>  = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags= interrupt enabled, resume, IOPL = 0
>> current process = 0 (swapper)
>> trap number = 12
>> panic: page fault
>> cpuid = 31
>> time = 1
>> 
>> 
>> 
>> Some infos about the system, the page fault occurs:
>> 
>> CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz
>> K8-class CPU)
>>Origin="AuthenticAMD"  Id=0x870f10  Family=0x17  Model=0x71  Stepping=0
>> Features=0x178bfbff
>> Features2=0x7ed8320b
>>AMD Features=0x2e500800
>>AMD
>> Features2=0x75c237ff
>>Structured Extended
>> Features=0x219c91a9
>>Structured Extended Features2=0x44
>>XSAVE Features=0xf
>>AMD Extended Feature Extensions ID
>> EBX=0x108b657
>>SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
>>TSC: P-state invariant, performance statistics
>> real memory  = 68717379584 (65534 MB)
>> avail memory = 66756149248 (63663 MB)
>> Event timer "LAPIC" quality 600
>> 
>> 
>> #cat /etc/sysctl.conf
>> security.bsd.map_at_zero=1
>> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules
>> kern.evdev.rcpt_mask=6
>> kern.maxfiles=49312
>> kern.ipc.shm_allow_removed=1
>> kern.ipc.maxsockbuf=16777216
>> vfs.usermount=1
>> net.inet.tcp.rfc1323=1
>> net.inet.tcp.sack.enable=1
>> net.inet.tcp.sendbuf_auto=1
>> net.inet.tcp.recvbuf_auto=1
>> net.inet.tcp.sendbuf_max=16777216
>> net.inet.tcp.recvbuf_max=16777216
>> net.inet6.ip6.use_tempaddr=1
>> net.inet6.ip6.prefer_tempaddr=1
>> net.local.stream.recvspace=65536
>> net.local.stream.sendspace=65536
>> 
>> 
>> Please let me know, if I should provide more info or test something.
>> Thanks in advance,
>> Rainer
>> ___
>> freebsd-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"