Re: x11/nvidia-driver / Compilation has failed

[Nali Toja]

Ali Mashtizadeh  writes:

> 2011/8/31 Alexey Dokuchaev :
>> On Mon, Aug 29, 2011 at 02:59:48PM +0200, Olivier Smedts wrote:
>>> 2011/8/29 ken :
>>> > Could I test your patch for nvidia-driver, too?
>>> > I cannot find your patch in this mail.
>>>
>>> I took the patch in :
>>> http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026515.html
>>>
>>> And it worked for me.
>>
>> Should be fixed in the port itself now (also updated to 280.13).
>
> Is there any reason I should still be hitting this bug when building
> on 9-STABLE? With Linux compatibility disabled I can build the driver,
> but the kernel refuses to load it saying it's incompatible with my
> kernel version.

Only if you're using 285.05.09 with the port. And it'd affect both
/stable/9 and /head users.

  // from src/nv-freebsd.h:
  #if __FreeBSD_version >= 900041
  #include 
  #else
  #define fget(td, fd, cap, fp) fget(td, fd, fp)
  #endif

--- Begin Message ---
Can you commit below tiny change? It should make testing the new version a
bit easier for people who are impatient to wait for the next port update.

That version also includes tunable support similar to ports/156386.

  $ make
  [...]
  nvidia_linux.c:40:51: error: too many arguments to function call, expected 4, 
have 5
  if ((error = fget(td, args->fd, CAP_IOCTL, 0, &fp)) != 0)
    ^~~
  @/sys/file.h:186:1: note: 'fget' declared here
  int fget(struct thread *td, int fd, cap_rights_t rights, struct file **fpp);
  ^
  1 error generated.

Index: x11/nvidia-driver/Makefile
===
RCS file: /a/.csup/ports/x11/nvidia-driver/Makefile,v
retrieving revision 1.109
diff -u -p -r1.109 Makefile
--- x11/nvidia-driver/Makefile  31 Aug 2011 12:30:24 -  1.109
+++ x11/nvidia-driver/Makefile  4 Oct 2011 05:33:52 -
@@ -112,7 +113,7 @@ post-patch: .SILENT
${REINPLACE_CMD} -e 's/status != status/status != RM_OK/' \
${WRKSRC}/src/nvidia_os.c
 # Fix the build after fget(9) KPI was changed in r224778
-.if ${OSVERSION} > 900040 && ${NVVERSION} >= 1952200
+.if ${OSVERSION} > 900040 && ${NVVERSION} >= 1952200 && ${NVVERSION} < 2850509
${REINPLACE_CMD} -e '/fget/s/&fp/0, &/' ${WRKSRC}/src/nvidia_linux.c
 .endif
 .if defined(WITH_FREEBSD_AGP)
--- End Message ---
___
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: Patch for ports on 10-current

[Nali Toja]

Doug Barton  writes:

> Until the pointy-haireds come up with a better solution, here is a patch
> that incorporates work that others have done into a manageable form so
> that those interested in working with ports on 10-current have some
> tools to work with:
>
> http://dougbarton.us/bam.patch
[...]
> +.if ${OSVERSION} >= 100 && !defined(NO_LIBTOOL_FIXED)

The issue does not lie in OSVERSION but in OSREL. So, why not be smarter
and detect if a user has UNAME_r workaround in environment by

  .if ${OSREL:R} >= 10 && !defined(NO_FOO_FIX)
___
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: Patch for ports on 10-current

[Nali Toja]

Doug Barton  writes:

> http://dougbarton.us/bam.patch
[...]
> +.if ${OSVERSION} >= 100 && !defined(NO_AUTOTOOLS_FIX)

Being not limited to GNU_CONFIGURE, is it a feature?

Also, there are a few ports that either set WRKSRC instead of
BUILD_WRKSRC or extract several distfiles. Why not use WRKDIR then?

  # lang/python27, it does not use devel/libffi (ports/146823)
  WRKSRC/../Modules/_ctypes/libffi/configure:freebsd1*)
  WRKSRC/../Modules/_ctypes/libffi/configure:freebsd1*)
___
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"

crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread

[Nali Toja]

After r216641 sbcl built with sb-thread dies on mailbox tests. It also
dies when I try to complete a symbol in slime. The workaround seems to
be to revert libthr to r216640.

  http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/154050
  http://svn.freebsd.org/changeset/base/216641
  http://www.freshports.org/lang/sbcl # or see ports/161444 for sbcl-1.0.52

Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@
in case it's the latter one.

  $ cd lang/sbcl
  $ rm files/patch-disable-failing-tests
  $ make # it should fail
  $ cd $(make -V WRKSRC)
  $ SBCL_HOME=contrib/ ./src/runtime/sbcl \
  --core output/sbcl.core --no-userinit --no-sysinit \
  --eval "(require 'sb-concurrency)" \
  --eval "(asdf:oos 'asdf:test-op :sb-concurrency-tests)"
  This is SBCL 1.0.52, an implementation of ANSI Common Lisp.
  More information about SBCL is available at .

  SBCL is free software, provided as is, with absolutely no warranty.
  It is mostly in the public domain; some portions are provided under
  BSD-style licenses.  See the CREDITS and COPYING files in the
  distribution for more information.
  Doing 16 pending tests of 16 tests total.
   SB-CONCURRENCY-TEST::QUEUE.1 SB-CONCURRENCY-TEST::QUEUE.2
   SB-CONCURRENCY-TEST::QUEUE.3 SB-CONCURRENCY-TEST::QUEUE.4
   SB-CONCURRENCY-TEST::QUEUE.5 SB-CONCURRENCY-TEST::QUEUE.T.1
   SB-CONCURRENCY-TEST::QUEUE.T.2 SB-CONCURRENCY-TEST::QUEUE.T.3
   SB-CONCURRENCY-TEST::MAILBOX-TRIVIA.1 SB-CONCURRENCY-TEST::MAILBOX-TRIVIA.2
   SB-CONCURRENCY-TEST::MAILBOX-TRIVIA.3
   SB-CONCURRENCY-TEST::MAILBOX.SINGLE-PRODUCER-SINGLE-CONSUMER
   SB-CONCURRENCY-TEST::MAILBOX.SINGLE-PRODUCER-MULTIPLE-CONSUMERS
  FFatal error 'thread was already on queue.' at atal error 'thread was already 
on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  FaFtfatal error encounteredalal error 'thread was already on queue.' at line 
222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in tal error 'thread 
was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  ine 222 in file /usr/src/lib/libthr/thread/thr_cond.c (erf in SBCL pid 
1993rfatal error encounteredFatal error 'thread was already on queue.' at line 
infatal error encountered222 in file /usr/src/lib/libthr/thread/thr_cond.c 
(errnole /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  o = 0)
  (tid 34384826368)  in SBCL pid 1993= 0F)fatal error encounteredaFFataltfatal 
error encounteredatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
   error 'thread was already on queue.' aa
   in SBCL pid 1993t lFataFl error 'thread was already on queue.' at line 222 
in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  l error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  ine 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  :
  (tid 34384824320) in SBCL pid 1993fatal error encounteredfatal error 
encounteredfatal error encountered in SBCL pid 1993fatal error encounteredfatal 
error encountered in SBCL pid 1993(tid 34384815104):
  SIGABRT received.
  atal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)

  fatal error encountered(tid 34384823296)SIGABRT received.
  :
  (tid 34384822272) in SBCL pid 1993 in SBCL pid 1993 in SBCL pid 1993(tid 
34384828416) in SBCL pid 1993(tid 34384813056)FFaFatal error 'thread was 
already on queue.' t
  at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  al error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  aFatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 Fatal error 'thread 
was already on queue.' at lFine 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (err in SBCL pid 1993:

  SIGABRT received

Re: [RFC] Prepend timestamp in msgbuf

[Nali Toja]

Alexander Best  writes:

>> On Fri Oct 14 11, Poul-Henning Kamp wrote:
>> > In message <20111014085609.ga3...@freebsd.org>, Alexander Best writes:
>> > 
>> > >1) would it be possible to prepend those timestamps to the actual console
>> > >output and not only to the output of demsg? maybe via a sysctl toggle?
>> > 
>> > The kernel does not know enough about timezones to emit anything
>> > but UTC timestamps.
>> 
>> hmm ok.
>> 
>> > 
>> > >2) my dmesg output contains a lot of these entries: "<118>"
>> > 
>> > These are magic markers for syslogd(8) specifying priority.
>> 
>> it would be nice, if their output could be turned off via a dmesg flag imo.
>> 
>> > 
>> > >3) roughly the first 30 lines of my dmesg output have the timestamp 
>> > >"[1.0]".
>> > >would it be possible to have more accuracy there?
>> > 
>> > No, because we don't know the time until we've found the RTC chip.
>> 
>> maybe prepending the output with [??] instead of [1.0] would make more sense,
>> so users knows that those timestamps are bogus.
>
> maybe the granularity of the timestamps could be limited to a static value? 
> the
> following output doesn't really look pretty:
>
> [7.729516] <118>/dev/ufs/varfs: clean, 879143 free (7407 frags, 108967 
> blocks, 0.7% fragmentation)
> [7.891512] <118>Mounting local file systems:WARNING: TMPFS is considered to 
> be a highly experimental feature in FreeBSD.
> [8.33519] .
> [9.440514] <118>Setting hostname: otaku.
> [9.744516] wlan0: Ethernet address: 00:0f:b5:82:07:c8
> [9.850516] <118>Starting wpa_supplicant.
> [10.335514] <118>Starting Network: lo0 ath0.
>
> so it would be nice, if trailing zeros got printed out, too.

Why not make formatting similar to linux/xorg logs, e.g.

  [31.897] (**) Option "XkbLayout" "us"
  [31.897] (II) XINPUT: Adding extended input device "" 
(type: KEYBOARD, id 7)
  [ 11485.404] (II) 3rd Button detected: disabling emulate3Button

  [0.00] Linux version 3.0-ARCH (tobias@T-POWA-LX) (gcc version 4.6.1 
20110819 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST 2011
  [0.00] Command line: 
root=/dev/disk/by-uuid/625db1f5-9b51-4d2d-acb7-6726f4d7e199 ro
  [...]
  [   15.096862] NET: Registered protocol family 10
  [   16.792594] [drm] nouveau :01:00.0: plugged DVI-I-2
  [   26.054186] eth0: no IPv6 routers present

A way to convert those timestamps to localtime or time delta[1] post-mortem
via dmesg(8) would be good, too.

[1] like in tcpdump -ttt
___
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: sys/conf/newvers.sh vs. subversion-1.7

[Nali Toja]

Olivier Smedts  writes:

>>
>> $(svn info | awk '/^Revision:/ {print $2}')
>>
>> is what I use in my installkernel wrapper script. Granted, I didn't know
>> about svnversion some time later, but it appears that svnversion broke some
>> things by consolidating the .svn directories as Chris shows above with the
>> 'exported' line.
>
> Won't work for localized builds :
> $ echo $LANG
> fr_FR.ISO8859-15
> $ pwd
> /usr/src
> $ $(svn info | awk '/^Revision:/ {print $2}')
> $ svn info

While you can try to set LC_MESSAGES to `C' locale
subversion also supports XML output

  $ echo $(svn info --xml | awk -F\" '/revision/ && ++i > 1 { print $2 }')
  226629

Unlike `svnversion' it doesn't show whether the checked out
sources are `M' (modified) or not. Not that I found it useful
compared to `svn st -q' though.

> Chemin : .
> Chemin racine de la copie de travail : /usr/src
> URL : http://svn.freebsd.org/base/stable/9
> Racine du dépôt : http://svn.freebsd.org/base
> UUID du dépôt : ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Révision : 226629
> [...]
___
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"