Re: 3D graphic cards

[Dag-Erling Smørgrav]

Bruno Afonso <[EMAIL PROTECTED]> writes:
> No they don't. I have a radeon 7200 and at the moment the support
> seems to be broken (I don't think anyone has updated XFree to fix
> it). This is on 5.1. Search the -current archives and you will someone
> also complaining about it.

I have -CURRENT boxes with 7000s and 7500s, and they work like a
charm.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Panic linux ldconfig with MUTEX_PROFILING

[Dag-Erling Smørgrav]

Jun Kuriyama <[EMAIL PROTECTED]> writes:
> But I used linux.ko which sync'ed with kernel itself (both were built
> with same config).  Is MUTEX_PROFILING not passed to kernel module
> building?

Modules are compiled without options.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: what is the suggested way to do void * arithmetic ?

[Harti Brandt]

On Thu, 10 Jul 2003, David Leimbach wrote:

DL> I always feel better when I convert void * to char * but that's probably
DL>because C++ doesn't allow pointer arithmetic on void *'s.  The argument
DL>being that you don't know the size of what's being pointed to with a void *
DL>and therefore can't know how far to seek the the pointer to get to the next
DL>valid address.
DL>
DL>I think C takes a more low-level approach and says "void * is just an address
DL>void * + 1 means the next valid address".

void pointer arithmetic is a sun and gcc specific extension and by no
means a standardized thing.

DL>
DL>Anyway... it just seems to help when porting code between C/C++ to use
DL>char *...

Yes.

harti

DL>Dave
DL>On Thursday, July 10, 2003, at 11:40AM, Luigi Rizzo <[EMAIL PROTECTED]> wrote:
DL>
DL>>On Thu, Jul 10, 2003 at 03:42:04AM -0700, Terry Lambert wrote:
DL>>> Luigi Rizzo wrote:
DL>>> > in several places in ipfw2.c i have to move pointers across
DL>>> > structures of variable length (lists of ipfw2 instructions
DL>>> > returned by the getsockopt()), and i use the following type of code:
DL>>> >
DL>>> > void *next;
DL>>> > foo *p;
DL>>> > next = (void *)p + len;
DL>>> > foo = (foo *)p + len;
DL>>^^
DL>>
DL>>sorry i meant   p = (void *)p + len;
DL>>
DL>>...
DL>>> I don't understand the second one.  The first one blows up because
DL>>> you aren't parenthesizing, e.g.:
DL>>>
DL>>>   next = (void *)(p + len);
DL>>>
DL>>> The compiler is complaining because it doesn't know sizeof(*((void *)0))
DL>>
DL>>ok, it actually evaluates to 1 and i thought it was some standard, probably
DL>>it is not so i guess i have to cast to (char *) instead
DL>>
DL>>thanks
DL>>luigi
DL>>
DL>>> (pointer arithmatic is coerced to the type of the lvalue, in most
DL>>> cases of casts).
DL>>>
DL>>> Unless you are referencing them as array elements (in which case,
DL>>> packing becomes a problem for you, when referencing them as arrays
DL>>> of foo's, since you don't know how foo's are packed in an array),
DL>>> you should probably cast them to char for the arithmatic, and add
DL>>> them with byte counts.
DL>>>
DL>>> -- Terry
DL>>___
DL>>[EMAIL PROTECTED] mailing list
DL>>http://lists.freebsd.org/mailman/listinfo/freebsd-current
DL>>To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DL>>
DL>>
DL>___
DL>[EMAIL PROTECTED] mailing list
DL>http://lists.freebsd.org/mailman/listinfo/freebsd-current
DL>To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DL>

-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [-CURRENT tinderbox] failure on amd64/amd64

[Alexander Kabaev]

All of these failures are caused by incomplete compiler import.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[-CURRENT tinderbox] failure on sparc64/sparc64

[Tinderbox]

TB --- 2003-07-11 05:45:13 - starting CURRENT tinderbox run for sparc64/sparc64
TB --- 2003-07-11 05:45:13 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-11 05:47:13 - building world
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
[...]
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/genpreds.c:25:
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/system.h:607:9: 
warning: poisoning existing macro "WCHAR_UNSIGNED"
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/system.h:625:31: 
warning: poisoning existing macro "SCCS_DIRECTIVE"
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/genpreds.c:28:
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/rtl.h:97: syntax 
error before '(' token
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/rtl.h:104: 
syntax error before '}' token
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/genpreds.c:28:
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/rtl.h:22:1: 
unterminated #ifndef
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_tools.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
TB --- 2003-07-11 05:48:57 - /usr/bin/make returned exit code  1 
TB --- 2003-07-11 05:48:57 - ERROR: failed to build world
TB --- 2003-07-11 05:48:57 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[-CURRENT tinderbox] failure on ia64/ia64

[Tinderbox]

TB --- 2003-07-11 05:41:02 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2003-07-11 05:41:02 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-11 05:43:12 - building world
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
[...]
echo '#include "cp/cp-tree.def"'> gencheck.h
echo '#include "objc/objc-tree.def"'>> gencheck.h
cc -O -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -DCROSS_COMPILE 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc_tools/../cc_tools
 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc_tools/../cc_tools
 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc
 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config
 -static -DGENERATOR_FILE 
-I/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/legacy/usr/include
 -c 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genpreds.c
In file included from tconfig.h:10,
 from hconfig.h:2,
 from 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gcc/genpreds.c:24:
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gcc/config/ia64/ia64.h:2371:
 syntax error before '(' token
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gcc/config/ia64/ia64.h:2384:
 syntax error before '}' token
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc_tools.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
TB --- 2003-07-11 05:45:12 - /usr/bin/make returned exit code  1 
TB --- 2003-07-11 05:45:12 - ERROR: failed to build world
TB --- 2003-07-11 05:45:12 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[-CURRENT tinderbox] failure on i386/pc98

[Tinderbox]

TB --- 2003-07-11 05:36:45 - starting CURRENT tinderbox run for i386/pc98
TB --- 2003-07-11 05:36:45 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-11 05:39:01 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
[...]
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/genpreds.c:25:
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/system.h:607:9: 
warning: poisoning existing macro "WCHAR_UNSIGNED"
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/system.h:625:31: 
warning: poisoning existing macro "SCCS_DIRECTIVE"
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/genpreds.c:28:
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/rtl.h:97: syntax error 
before '(' token
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/rtl.h:104: syntax 
error before '}' token
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/genpreds.c:28:
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/rtl.h:22:1: 
unterminated #ifndef
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc_tools.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
TB --- 2003-07-11 05:41:02 - /usr/bin/make returned exit code  1 
TB --- 2003-07-11 05:41:02 - ERROR: failed to build world
TB --- 2003-07-11 05:41:02 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[-CURRENT tinderbox] failure on i386/i386

[Tinderbox]

TB --- 2003-07-11 05:32:46 - starting CURRENT tinderbox run for i386/i386
TB --- 2003-07-11 05:32:46 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/i386
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-11 05:34:48 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
[...]
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/genpreds.c:25:
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/system.h:607:9: 
warning: poisoning existing macro "WCHAR_UNSIGNED"
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/system.h:625:31: 
warning: poisoning existing macro "SCCS_DIRECTIVE"
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/genpreds.c:28:
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/rtl.h:97: syntax error 
before '(' token
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/rtl.h:104: syntax 
error before '}' token
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/genpreds.c:28:
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/rtl.h:22:1: 
unterminated #ifndef
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc_tools.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
TB --- 2003-07-11 05:36:44 - /usr/bin/make returned exit code  1 
TB --- 2003-07-11 05:36:44 - ERROR: failed to build world
TB --- 2003-07-11 05:36:44 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[-CURRENT tinderbox] failure on amd64/amd64

[Tinderbox]

TB --- 2003-07-11 05:28:47 - starting CURRENT tinderbox run for amd64/amd64
TB --- 2003-07-11 05:28:47 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-11 05:30:55 - building world
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src
TB --- /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
[...]
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/contrib/gcc/genpreds.c:25:
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/contrib/gcc/system.h:607:9: 
warning: poisoning existing macro "WCHAR_UNSIGNED"
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/contrib/gcc/system.h:625:31: 
warning: poisoning existing macro "SCCS_DIRECTIVE"
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/contrib/gcc/genpreds.c:28:
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/contrib/gcc/rtl.h:97: syntax 
error before '(' token
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/contrib/gcc/rtl.h:104: syntax 
error before '}' token
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/contrib/gcc/genpreds.c:28:
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/contrib/gcc/rtl.h:22:1: 
unterminated #ifndef
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc_tools.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
TB --- 2003-07-11 05:32:45 - /usr/bin/make returned exit code  1 
TB --- 2003-07-11 05:32:45 - ERROR: failed to build world
TB --- 2003-07-11 05:32:45 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NVidia driver stability?

[Mike Makonnen]

I don't know if this is relevant, but the NVidia drivers won't work
with libkse or libthr, because it messes with the %gs segment
register, which both threading libraries use. The only threading
library it currently works with is libc_r.


Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9
[EMAIL PROTECTED]| FreeBSD - Unleash the Daemon!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

HEADS UP: GCC 3.3.1 import in progress

[Alexander Kabaev]

I'll be importing a GCC 3.3.1 snapshot in a couple of minutes. 
Please hold your updates until I post 'all clear' message.

--
Alexander Kabaev
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [acpi-jp 2393] Re: Updated ec-burst.diff patch

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Nate Lawson <[EMAIL PROTECTED]> writes:
: Please send me your patch for reseting USB on resume.  I will test it and
: commit it.

Acutally, I have some generic resume stuff in the pipeline, so please
run it by me too.  Too many drivers do too many bogus things for
suspend/resume as it is...

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NVidia driver stability?

[Bruce Cran]

On Thu, Jul 10, 2003 at 04:41:40PM -0700, Evan Dower wrote:
> The new nvidia-driver was unstable for me as well. So much so that I 
> deinstalled it so I could get some actual work done. I never was able o get 
> any specifics about it, as I don't have a serial console set up, and when 
> it crashes it freezes the screen. I can tell you this much though. 
> Sometimes when it locked up, I was able to ssh in from another machine, see 
> that XFree86 was taking 98-99% of CPU time, kill XFree86, and continue on. 
> Other times, I couldn't even ssh in, as the connection hung, so I had to do 
> a hard restart. The timing of these crashes was entirely unpredictable.
> I have a GeForce 3 Ti 200 and FreeBSD 5.1-RELENG. I tried with both AGP's. 
> Loading nvidia-driver into a debug kernel (INVARIANTS and WITNESS) still 
> causes an immediate panic. I don't know how the Nvidia people can do QA on 
> this without a debugging kernel. Just poorly I guess. I hope someone finds 
> this helpful though I would be shocked if it did. I would be happy 
> (ecstatic, actually) to run any experiments someone might be interested in.

I've found the nvidia driver to be very stable, using a new -CURRENT 
build and the NVidia agp driver.  I've got a GeForce 4200 Go, and the only
thing the nvidia driver doesn't seem to like is changing resolutions - I've
had a few problems including a reboot from that.   Unloading the module
panics the kernel, with

malloc(9)/free(9) confusion
possibly freeing with wrong type, but maybe not here.

I can get a backtrace, if anybody's interested.

I also get a few LORs from the driver, which trace back to the sources in
/usr/ports/x11/nvidia-driver/work.

--
Bruce Cran

> Many thanks,
> Evan Dower
> Undergraduate, Computer Science
> University of Washington
> 
> >From: "Brian Kincaid" <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: NVidia driver stability?
> >Date: 10 Jul 2003 15:45:41 -0700
> >MIME-Version: 1.0
> >Received: from mx2.freebsd.org ([216.136.204.119]) by 
> >mc3-f9.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 10 
> >Jul 2003 15:46:07 -0700
> >Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18])by 
> >mx2.freebsd.org (Postfix) with ESMTPid 1BF42562AC; Thu, 10 Jul 2003 
> >15:45:50 -0700 (PDT)(envelope-from [EMAIL PROTECTED])
> >Received: from hub.freebsd.org (localhost [127.0.0.1])by hub.freebsd.org 
> >(Postfix) with ESMTPid AE42737B40B; Thu, 10 Jul 2003 15:45:49 -0700 (PDT)
> >Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])by 
> >hub.freebsd.org (Postfix) with ESMTP id 1A39337B401for 
> ><[EMAIL PROTECTED]>; Thu, 10 Jul 2003 15:45:42 -0700 (PDT)
> >Received: from smtp.webbox.com (66.234.quiknet.com [207.183.234.66])by 
> >mx1.FreeBSD.org (Postfix) with ESMTP id 87FCE43FD7for 
> ><[EMAIL PROTECTED]>; Thu, 10 Jul 2003 15:45:41 -0700 (PDT)(envelope-from 
> >[EMAIL PROTECTED])
> >Received: from mdev ([207.183.234.66]) by smtp.webbox.com  with 
> >MicrosoftSMTPSVC(5.5.1877.197.19);Thu, 10 Jul 2003 15:45:41 -0700
> >X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP
> >Delivered-To: [EMAIL PROTECTED]
> >Message-Id: <[EMAIL PROTECTED]>
> >X-BeenThere: [EMAIL PROTECTED]
> >X-Mailman-Version: 2.1.1
> >Precedence: list
> >List-Id: Discussions about the use of 
> >FreeBSD-current
> >List-Unsubscribe: 
> >, >PROTECTED]>
> >List-Archive: 
> >List-Post: 
> >List-Help: 
> >List-Subscribe: 
> >, >PROTECTED]>
> >Sender: [EMAIL PROTECTED]
> >Errors-To: [EMAIL PROTECTED]
> >Return-Path: [EMAIL PROTECTED]
> >X-OriginalArrivalTime: 10 Jul 2003 22:46:07.0824 (UTC) 
> >FILETIME=[0D491D00:01C34735]
> >
> >
> >Hi,
> >
> >Yes, I can replicate the behavior you describe upon running glxinfo
> >repeatedly. I have not yet had any trouble with xvinfo. I have
> >also seen a couple of crashes (not repeatable) after running
> >some of the xscreensaver-demo examples and/or some of the GL
> >apps for xscreensaver directly.
> >
> >I am running a freshly built 4.8-STABLE system, plus a GeForce3
> >Ti 200 PCI card and a rebuilt version of the nvidia-driver port.
> >Before I rebuilt the entire system and kernel the nvidia-port
> >driver caused the system to page fault immediately upon starting
> >X.
> >
> >I reverted to the standard nv driver for a while, then read a
> >couple of messages on one of the freebsd mailing lists about
> >the necessity of rebuilding everything due to a change in proc.h.
> >
> >After the cvsup, rebuild process, the nvidia driver seems to
> >work, except for the problems mentioned above.
> >
> >Brian
> >
> >
> >
> >___
> >[EMAIL PROTECTED] mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >To unsubscribe, send any mail 

Re: NVidia driver stability?

[Evan Dower]

The new nvidia-driver was unstable for me as well. So much so that I 
deinstalled it so I could get some actual work done. I never was able o get 
any specifics about it, as I don't have a serial console set up, and when it 
crashes it freezes the screen. I can tell you this much though. Sometimes 
when it locked up, I was able to ssh in from another machine, see that 
XFree86 was taking 98-99% of CPU time, kill XFree86, and continue on. Other 
times, I couldn't even ssh in, as the connection hung, so I had to do a hard 
restart. The timing of these crashes was entirely unpredictable.
I have a GeForce 3 Ti 200 and FreeBSD 5.1-RELENG. I tried with both AGP's. 
Loading nvidia-driver into a debug kernel (INVARIANTS and WITNESS) still 
causes an immediate panic. I don't know how the Nvidia people can do QA on 
this without a debugging kernel. Just poorly I guess. I hope someone finds 
this helpful though I would be shocked if it did. I would be happy 
(ecstatic, actually) to run any experiments someone might be interested in.
Many thanks,
Evan Dower
Undergraduate, Computer Science
University of Washington

From: "Brian Kincaid" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: NVidia driver stability?
Date: 10 Jul 2003 15:45:41 -0700
MIME-Version: 1.0
Received: from mx2.freebsd.org ([216.136.204.119]) by 
mc3-f9.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 10 Jul 
2003 15:46:07 -0700
Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18])by 
mx2.freebsd.org (Postfix) with ESMTPid 1BF42562AC; Thu, 10 Jul 2003 
15:45:50 -0700 (PDT)(envelope-from [EMAIL PROTECTED])
Received: from hub.freebsd.org (localhost [127.0.0.1])by hub.freebsd.org 
(Postfix) with ESMTPid AE42737B40B; Thu, 10 Jul 2003 15:45:49 -0700 (PDT)
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])by 
hub.freebsd.org (Postfix) with ESMTP id 1A39337B401for 
<[EMAIL PROTECTED]>; Thu, 10 Jul 2003 15:45:42 -0700 (PDT)
Received: from smtp.webbox.com (66.234.quiknet.com [207.183.234.66])by 
mx1.FreeBSD.org (Postfix) with ESMTP id 87FCE43FD7for 
<[EMAIL PROTECTED]>; Thu, 10 Jul 2003 15:45:41 -0700 (PDT)(envelope-from 
[EMAIL PROTECTED])
Received: from mdev ([207.183.234.66]) by smtp.webbox.com  with 
MicrosoftSMTPSVC(5.5.1877.197.19);	 Thu, 10 Jul 2003 15:45:41 -0700
X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP
Delivered-To: [EMAIL PROTECTED]
Message-Id: <[EMAIL PROTECTED]>
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of 
FreeBSD-current
List-Unsubscribe: 
,
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: 
,
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 10 Jul 2003 22:46:07.0824 (UTC) 
FILETIME=[0D491D00:01C34735]

Hi,

Yes, I can replicate the behavior you describe upon running glxinfo
repeatedly. I have not yet had any trouble with xvinfo. I have
also seen a couple of crashes (not repeatable) after running
some of the xscreensaver-demo examples and/or some of the GL
apps for xscreensaver directly.
I am running a freshly built 4.8-STABLE system, plus a GeForce3
Ti 200 PCI card and a rebuilt version of the nvidia-driver port.
Before I rebuilt the entire system and kernel the nvidia-port
driver caused the system to page fault immediately upon starting
X.
I reverted to the standard nv driver for a while, then read a
couple of messages on one of the freebsd mailing lists about
the necessity of rebuilding everything due to a change in proc.h.
After the cvsup, rebuild process, the nvidia driver seems to
work, except for the problems mentioned above.
Brian



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NVidia driver stability?

[Jeremy Messenger]

On Thu, 10 Jul 2003 16:43:34 -0500, Craig Boston <[EMAIL PROTECTED]> 
wrote:

Hi, all,

Just wondering if anyone has had any experiences (good or bad) with the 
new nvidia driver on CURRENT?  So far I've found it to be pretty 
unstable...  I tried reverting back to 5.1-RELEASE and recompiling the 
driver (i'm installing it from the port), but no luck.
On 5.1-RELEASE and old 5.1-CURRENT, I can use NVIDIA's AGP GART Driver 
until one or two weeks ago of 5.1-CURRENT, I am not able to use it any 
longer. It will lock my machine very hard, which only way I can do is turn 
the power off then boot into single to disable it. Current, I am stuck with 
FreeBSD's AGP GART driver (agp.ko) with Nvidia and it works great, but the 
perferomce descrease.

NVIDIA's AGP GART Driver = The glxgears will go over 3600 fps.
FreeBSD's AGP GART driver = The glxgears will go over 2500 fps.
I really have no idea how I can debug, because it only will lock up the 
machine very hard.


[EMAIL PROTECTED]:5:0:   class=0x03 card=0x88911462 chip=0x028110de 
rev=0xa1 hdr=0x00
   vendor   = 'NVIDIA Corporation'
   device   = 'GeForce4 Ti 4200 with AGP 8x [NV28]'
   class= display
   subclass = VGA


Note: The problem is same on old and new of Nvidia driver, they both behave 
same.

Cheers,
Mezz
It works fine in 2D mode, but running GL apps sometimes causes kernel 
panics.  Running glxinfo and xvinfo repeatedly is a quick way to cause 
strange things to happen -- segmentation faults, bus errors, and kernel 
panics.  The backtraces I've gotten are pretty worthless since the panic 
happens in a completely random place every time (to date, inside the VM, 
in ATA, USB, and a couple other places but almost never in the NVidia 
module itself).  Smells like kernel memory corruption to me.

My setup is a PCI Geforce2 MX and a PCI TNT2.  I'm using standard multi- 
head (NOT Xinerama).  The port is compiled with WITH_FREEBSD_AGP, though 
it shouldn't make a difference.  I do have an AGP Matrox card in the 
system, but disabling and/or removing it seems to make no difference.

The only thing slightly strange is that I had to put Options 
"UseInt10Module" "on" in XF86Config to soft-boot the TNT2.  Otherwise it 
had a big solid-colored block covering approximately 1/3 of the screen...

Anyway, just curious if this is typical this driver on 5.1 or if it's an 
isolated problem :)

Craig


--
bsdforums.org 's moderator, mezz.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: radeon lockups w/ 5.1-R

[Scott M. Likens]

On Thu, 2003-07-10 at 15:25, Matthias Buelow wrote:
> Scott M. Likens writes:
> 
> >Are you using the drm kernel drivers from the kernel, or are you using
> >DRI-HEAD from dri.sf.net?
> 
> >From the kernel (I didn't install anything else).

Yes you can get it from dri.sf.net

Easiest way and most painful as you have to download alot,

cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri login

cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri -z3 co xc

2hours later, or whatever it may be.

cd xc/xc
make World

then after that's done, yes you'll want libGL and such... 

so first off

cd ~/xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel
make -f Makefile.bsd

then make -f Makefile.bsd install

then go through and install the proper stubs and drivers, you can it
easily done at,

xc/xc/programs/Xserver/hw/xfree86/drivers

make install
xc/xc/lib/GL
make install

and go through you don't need to install the whole thing, unless you
want.

Either works... but that will give you native support

make sure the radeon.kld from the os-support/... gets into /boot/kernel

kldxref /boot/kernel

radeon_load="YES" in /boot/loader.conf

and that will give you MUCH more recent DRI support that'll get you
OpenGL 1.3 support which you can verify with glxinfo.

If you have any questions you can email me, or the list... i prefer the
list for educational purposes.

the DRI-HEAD as it is builds perfectly for FreeBSD and NetBSD i
believe... FreeBSD i have exp with.

if you need linux support, we can work on that too.

-- 
Scott M. Likens <[EMAIL PROTECTED]>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NVidia driver stability?

[Brian Kincaid]

Hi,

Yes, I can replicate the behavior you describe upon running glxinfo
repeatedly. I have not yet had any trouble with xvinfo. I have
also seen a couple of crashes (not repeatable) after running
some of the xscreensaver-demo examples and/or some of the GL
apps for xscreensaver directly.

I am running a freshly built 4.8-STABLE system, plus a GeForce3
Ti 200 PCI card and a rebuilt version of the nvidia-driver port.
Before I rebuilt the entire system and kernel the nvidia-port
driver caused the system to page fault immediately upon starting
X.

I reverted to the standard nv driver for a while, then read a
couple of messages on one of the freebsd mailing lists about
the necessity of rebuilding everything due to a change in proc.h.

After the cvsup, rebuild process, the nvidia driver seems to
work, except for the problems mentioned above.

Brian



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: small scheduler hack/patch

[Marcel Moolenaar]

On Thu, Jul 10, 2003 at 03:03:41PM -0700, Julian Elischer wrote:
> 
> it comes I think from the fact that some hardware treats things as
> bitmaps. (?)

I have to guess that a bitmap is a natural way to represent sets
when the sets aren't large and that this is why we use bitmaps.
We have a need to send an IPI to multiple CPUs, which is expressed
nicely with bitmaps.

> there are lots of cases where the code is doing 
> foreach cpu
>  if (cpu->mask & our_mask) 
>   continue;   /* skip ourself */
> 
> 
> which could easly be 
> if (cpu->number == PCPU_GET(cpu_number))

Agreed.

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: radeon lockups w/ 5.1-R

[Matthias Buelow]

Scott M. Likens writes:

>Are you using the drm kernel drivers from the kernel, or are you using
>DRI-HEAD from dri.sf.net?

>From the kernel (I didn't install anything else).

-- 
  Matthias Buelow;  [EMAIL PROTECTED],informatik.uni-wuerzburg.de}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: small scheduler hack/patch

[Julian Elischer]

On Thu, 10 Jul 2003, Marcel Moolenaar wrote:

> On Fri, Jul 11, 2003 at 07:21:16AM +1000, Bruce Evans wrote:
> > have MD definitions.  Its first arg has type u_int64_t on ia64's and
> > u_int on other arches.  This is bogus for ia64's since subr_smp.c uses
> > u_int for all bitmaps of CPUs, so systems with more than 32 CPUs cannot
> > actually work.
> 
> The bogosity is in MI code. Not being able to support 64-way (or higher)
> XYZ machines because MI code uses 32-bit bitmaps is wrong. Both the type
> and the access to it should be abstracted in MI code to allow for
> compound types. Much akin to sigset_t.

I think that the fact that it is even a bitmap should be hidden
it comes I think from the fact that some hardware treats things as
bitmaps. (?)

there are lots of cases where the code is doing 
foreach cpu
 if (cpu->mask & our_mask) 
continue;   /* skip ourself */


which could easly be 
if (cpu->number == PCPU_GET(cpu_number))

i.e there are a lot of cases where a mask is not the natural
way to express the information being used..
abstracting it to
cpu_is_us(pcpu)
makes it more readable and more MI



> 
> -- 
>  Marcel Moolenaar   USPA: A-39004  [EMAIL PROTECTED]
> 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

NVidia driver stability?

[Craig Boston]

Hi, all,

Just wondering if anyone has had any experiences (good or bad) with the new 
nvidia driver on CURRENT?  So far I've found it to be pretty unstable...  I 
tried reverting back to 5.1-RELEASE and recompiling the driver (i'm 
installing it from the port), but no luck.

It works fine in 2D mode, but running GL apps sometimes causes kernel panics.  
Running glxinfo and xvinfo repeatedly is a quick way to cause strange things 
to happen -- segmentation faults, bus errors, and kernel panics.  The 
backtraces I've gotten are pretty worthless since the panic happens in a 
completely random place every time (to date, inside the VM, in ATA, USB, and 
a couple other places but almost never in the NVidia module itself).  Smells 
like kernel memory corruption to me.

My setup is a PCI Geforce2 MX and a PCI TNT2.  I'm using standard multi-head 
(NOT Xinerama).  The port is compiled with WITH_FREEBSD_AGP, though it 
shouldn't make a difference.  I do have an AGP Matrox card in the system, but 
disabling and/or removing it seems to make no difference.

The only thing slightly strange is that I had to put Options "UseInt10Module" 
"on" in XF86Config to soft-boot the TNT2.  Otherwise it had a big 
solid-colored block covering approximately 1/3 of the screen...

Anyway, just curious if this is typical this driver on 5.1 or if it's an 
isolated problem :)

Craig

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: small scheduler hack/patch

[Marcel Moolenaar]

On Fri, Jul 11, 2003 at 07:21:16AM +1000, Bruce Evans wrote:
> have MD definitions.  Its first arg has type u_int64_t on ia64's and
> u_int on other arches.  This is bogus for ia64's since subr_smp.c uses
> u_int for all bitmaps of CPUs, so systems with more than 32 CPUs cannot
> actually work.

The bogosity is in MI code. Not being able to support 64-way (or higher)
XYZ machines because MI code uses 32-bit bitmaps is wrong. Both the type
and the access to it should be abstracted in MI code to allow for
compound types. Much akin to sigset_t.

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: small scheduler hack/patch

[John Baldwin]

On 10-Jul-2003 Bruce Evans wrote:
> On Thu, 10 Jul 2003, Julian Elischer wrote:
> 
>> I have a small "proof of concept" scheduler hack at:
>> http://www.freebsd.org/~julian/it.diff
>> ...
>> It's only implemented for SMP/i386 as the code to halt the cpu is only
>> present (from my quick view) in x86 and it doesn't make sense in UP..
> 
> ipi_selected() is essentially MI although it is declared in
>  and takes MD arg types, since it is used in subr_smp.c
> and subr_smp.c is MI by definition.  Its second arg is u_int64_t on
> alphas, int on ia64's, and u_int on other arches.  This isn't a problem
> since the arg is always a #define'd value like IPI_AST and these values
> have MD definitions.  Its first arg has type u_int64_t on ia64's and
> u_int on other arches.  This is bogus for ia64's since subr_smp.c uses
> u_int for all bitmaps of CPUs, so systems with more than 32 CPUs cannot
> actually work.

I'm actually not a big fan of the CPU bitmap thing, but perhaps an MD
cpu_bitmap typedef should be defined?

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: small scheduler hack/patch

[Julian Elischer]

On Fri, 11 Jul 2003, Bruce Evans wrote:

> On Thu, 10 Jul 2003, Julian Elischer wrote:
> 
> > I have a small "proof of concept" scheduler hack at:
> > http://www.freebsd.org/~julian/it.diff
> > ...
> > It's only implemented for SMP/i386 as the code to halt the cpu is only
> > present (from my quick view) in x86 and it doesn't make sense in UP..
> 
> ipi_selected() is essentially MI although it is declared in
>  and takes MD arg types, since it is used in subr_smp.c
> and subr_smp.c is MI by definition.  Its second arg is u_int64_t on
> alphas, int on ia64's, and u_int on other arches.  This isn't a problem
> since the arg is always a #define'd value like IPI_AST and these values
> have MD definitions.  Its first arg has type u_int64_t on ia64's and
> u_int on other arches.  This is bogus for ia64's since subr_smp.c uses
> u_int for all bitmaps of CPUs, so systems with more than 32 CPUs cannot
> actually work.

I meant that it's pointless to do the IPI on other architectures as only
i386 does the halt in the idle loop.

all you say is true but I'm not out to fix the IPI code..
(jhb on the other hand IS and I see him checking in lots of changes to
it in his P4 tree. Maybe your comments will help him on his cleanup.)

> 
> Bruce
> 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: radeon lockups w/ 5.1-R

[Scott M. Likens]

On Thu, 2003-07-10 at 12:14, Matthias Buelow wrote:
> Hi folks,
> 
> anyone else still seeing occasional lockups when using a Radeon
> graphics card?  I've had these frequently with a R7500 on 5.0p7
> and now installed 5.1 hoping that the issue had been fixed in
> the meantime.  It went well for two days but it just fscked up
> again so the problem is still there.  It only happens when I
> exit the X session.  Display becomes garbled and the machine
> locked up completely (didn't always do so in the past with 5.0,
> I sometimes could log in over the network and reboot the machine.)
> I think the problem was already known for 5.0, or does it warrant
> a new PR?

Are you using the drm kernel drivers from the kernel, or are you using
DRI-HEAD from dri.sf.net?



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: small scheduler hack/patch

[Bruce Evans]

On Thu, 10 Jul 2003, Julian Elischer wrote:

> I have a small "proof of concept" scheduler hack at:
> http://www.freebsd.org/~julian/it.diff
> ...
> It's only implemented for SMP/i386 as the code to halt the cpu is only
> present (from my quick view) in x86 and it doesn't make sense in UP..

ipi_selected() is essentially MI although it is declared in
 and takes MD arg types, since it is used in subr_smp.c
and subr_smp.c is MI by definition.  Its second arg is u_int64_t on
alphas, int on ia64's, and u_int on other arches.  This isn't a problem
since the arg is always a #define'd value like IPI_AST and these values
have MD definitions.  Its first arg has type u_int64_t on ia64's and
u_int on other arches.  This is bogus for ia64's since subr_smp.c uses
u_int for all bitmaps of CPUs, so systems with more than 32 CPUs cannot
actually work.

Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: support for mounting md(4) based filesystem at boot [PATCHES]

[Daniel C. Sobral]

Poul-Henning Kamp wrote:

Bah. Add a prerequisites field to fstab with all the filesystems that 
must be mounted before that one can be mounted.


That's not enough.

I have filesystems I don't want fscked/mounted until after sshd
will accept my login for instance (I hate waiting for a fsck of
/home/ncvs...) (Yes yes yes, bgfsck improves things a bit).
Please don't hack /etc/fstab yet another time, please try to do
it in a future-proof way (which doesn't suck)
I should have waited a bit before replying (after all, the message was 
from 22th last month anyway). Your next reply on the thread enlightened 
me to the scope of the problem.

Having a different script for each fs in rc.d would enable one to deal 
with such problems. Want a fs to have a particular dependency? Edit the 
script and add it.

But then we would have many files to deal with the fs, and very verbose 
at that, not to mention easy to misconfigure. We could teach some tool 
to edit them, but we would be back to teaching some program about all 
filesystems.



It fails the "doesn't suck" requirement, but, as I said, it is food for 
thought. Whatever we chose, I think filesystems should be something that 
can be dependencies and depended on for rc.d ordering.

--
Daniel C. Sobral   (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
VIVO Centro Oeste Norte
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Outros:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
After all my erstwhile dear,
My no longer cherished,
Need we say it was not love,
Just because it perished?
-- Edna St. Vincent Millay
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: jails and 5-roadmap ?

[Eirik Oeverby]

It would be great if this could be sorted out ASAP. With the patches
floating around and (seemingly) working (not that I have tested any of
them), they add enough extra functionality and flexibility to be very
valuable.. The multi-IP, process injection and the SysV stuff is (from
where I stand) the only missing pieces to make jails truly universal.

I'm already using jails, though I don't like the idea of having to run
some of the SW in the host OS..

/Eirik

I hate applying non-standard patches to my sourcetree, so .. The sooner 

On Thu, 10 Jul 2003 16:29:56 + (UTC)
"Bjoern A. Zeeb" <[EMAIL PROTECTED]> wrote:

> On Thu, 10 Jul 2003, Pawel Jakub Dawidek wrote:
> 
> > On Wed, Jul 09, 2003 at 11:28:45PM +0200, Poul-Henning Kamp wrote:
> > +> >there are floating around some patches for jails. At least
> > +> >- multi-IP
> > +> >- statfs restrictions
> > +> >- sysv
> > +> >come to my mind and there are perhaps others too.
> >
> > It looks like all of those are mine:
> >
> > http://garage.freebsd.pl
> 
> yeah I know. At least most. I also have a statfs restriction patch for
> 5.x (compileable as module starting with ~5.1). It's mostly the same
> as yours but some more sysctl options etc.
> 
> see http://sources.zabbadoz.net/freebsd/jail.html or kern/49085.
> 
> 
> > And there are few more. My favorite one is multi-level jails - you
> > can
> 
> Yes some other are still floating around I guess.
> 
> 
> > Exactly. And my patches are in desynch with current source, because
> > it is hard to maintain them when they aren't intergrated...
> 
> yeah, great problem :( I copied most of the sources for the .ko
> from sys/* and added my patches + some module magic. This had been
> the easiest way for me.
> 
> > And here I am!:)
> 
> Many thanks.
> 
> -- 
> Bjoern A. Zeebbzeeb at Zabbadoz dot NeT
> 56 69 73 69 74http://www.zabbadoz.net/
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "[EMAIL PROTECTED]"




pgp0.pgp
Description: PGP signature

Re: support for mounting md(4) based filesystem at boot [PATCHES]

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" writes:
>Andrew Kenneth Milton wrote:
>> +---[ Poul-Henning Kamp ]--
>> |
>> | I think we need somebody to reconsider how we configure our filesystems
>> | in the future, in order to avoid a confusion of config files whose
>> | interrelationship users will have no chance of figuring out.
>> | 
>> | We have CCD, GBDE, MD and in the future likely other technologies for
>> | configuring the underlying devices, we have FSCK, UFS and NFS and
>> | other filesystems to mount.
>> | 
>> | Somebody must be able to come up with some creative stuff here... ?
>> 
>> We want 
>> 
>> A REGISTRY! 
>> 
>> Ni! Ni! Ni! Ni! Ni! Ni!
>
>Bah. Add a prerequisites field to fstab with all the filesystems that 
>must be mounted before that one can be mounted.

That's not enough.

I have filesystems I don't want fscked/mounted until after sshd
will accept my login for instance (I hate waiting for a fsck of
/home/ncvs...) (Yes yes yes, bgfsck improves things a bit).

Please don't hack /etc/fstab yet another time, please try to do
it in a future-proof way (which doesn't suck)

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: support for mounting md(4) based filesystem at boot [PATCHES]

[Daniel C. Sobral]

Andrew Kenneth Milton wrote:
+---[ Poul-Henning Kamp ]--
|
| I think we need somebody to reconsider how we configure our filesystems
| in the future, in order to avoid a confusion of config files whose
| interrelationship users will have no chance of figuring out.
| 
| We have CCD, GBDE, MD and in the future likely other technologies for
| configuring the underlying devices, we have FSCK, UFS and NFS and
| other filesystems to mount.
| 
| Somebody must be able to come up with some creative stuff here... ?

We want 

A REGISTRY! 

Ni! Ni! Ni! Ni! Ni! Ni!
Bah. Add a prerequisites field to fstab with all the filesystems that 
must be mounted before that one can be mounted.

Then just teach mountlocal and mountremote to iterate mounting until no 
new filesystems can be mounted.

Maybe we should add a "remote" flag to fstab, and make the rc.d script 
read fstab itself instead of relying on mount to know which filesystems 
are local and which are remote. The rc.d scripts can then extract that 
info and benefit from it in two ways:

1) It will know which filesystems can be mounted before network, and 
which require network.
2) The filesystems themselves could be used in BEFORE or REQUIRE.

Mm.

Either rcorder gets taught about this improved fstab, or we would have 
to add a program that reads fstab and then generates rc.d scripts as 
appropriate. Not sure I like the latter, but it has the advantage of 
keeping rcorder simple.

Just food for thought.

--
Daniel C. Sobral   (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
VIVO Centro Oeste Norte
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Outros:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Love means having to say you're sorry every five minutes.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: SMP and setrunnable()- scheduler 4bsd

[John Baldwin]

On 10-Jul-2003 Julian Elischer wrote:
> BTW in cpu_idle()
> 
>#ifdef SMP
> if (mp_grab_cpu_hlt())
> return;
>#endif
> 
> 
> whta gain is there in this returning.. it will anyhow if there is work
> to do, and sched_runnable is called either way..
> 
> couldn't it just be 
> 
>#ifdef SMP
>   mp_grab_cpu_hlt();
>#endif
> 
> ?

*shrug*, ps@ stuck that in there and I didn't really look too closely.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Witness panic (fxp/polling related)

[John Baldwin]

On 10-Jul-2003 Robin P. Blanchard wrote:
> Sources as of this morning yield:

Do you have the actual panic message?

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: SMP and setrunnable()- scheduler 4bsd

[Julian Elischer]

On Thu, 10 Jul 2003, John Baldwin wrote:

> > 307.504u 93.581s 4:23.22 152.3% 3047+5913k 29+1055io 8pf+0w
> > 
> > What is so stunning is the massive increase in user time 
> > for the case where the cpu is not being idled.
> > I'm hoping this is a statistical artifact of some sort..
> 
> I don't think it is, but you'd need more samples to be truly confident.
> One possible reason: having the CPU's not halt means that idle CPU's
> bang on the runq state continuously.  Perhaps this can penalize the
> non-idle CPU's due to cache interactions both when the non-idle CPU's
> are manipulating the queues and also by making the cache lines holding
> the queue state always be resident and not allowing their effective use
> by the real code executing on other CPUs.

possibly the  cpu continuously testing
sched_runnable() is interfering with such things as 
the clock ticks that want to account user time.

By making them a lot slower (schedlock/giant)? the
user time is being 'extended'.

I think I see more *Giant in 'top' when the cpu is not halted then when
it is. 

> > I'll do some tests.
> 
> Yes.  As it stands now, adding the IPI would just make things more
> complex for no gain.  However, if this IPI is present, then we can
> engage in perhaps more drastic measures like really putting a CPU
> to sleep (perhaps disabling interrupts to it?) until it is needed
> which might bring significant power and heat savings to idle SMP
> machines.

check the patch at http://www.freebsd.org/~julian/it.diff

it's trivial.

BTW in cpu_idle()

#ifdef SMP
if (mp_grab_cpu_hlt())
return;
#endif


whta gain is there in this returning.. it will anyhow if there is work
to do, and sched_runnable is called either way..

couldn't it just be 

#ifdef SMP
mp_grab_cpu_hlt();
#endif

?

> 
> > It seems however that having the halt on idle turned on is the 
> > right thing these days. (which is the current default)
> > but the odd user times are a worry.
> 
> I'm sure Terry is all torn up by that conclusion. :-P
>

:-) 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: SMP and setrunnable()- scheduler 4bsd

[John Baldwin]

On 10-Jul-2003 Julian Elischer wrote:
> OK so I return with some numbers
> 
> 
> On Tue, 8 Jul 2003, John Baldwin wrote:
> 
>> 
>> On 08-Jul-2003 Julian Elischer wrote:
>> > It looks tp me that if we make a thread runnable
>> > and there is a processor in the idle loop, the idle processor should be
>> > kicked in some way to make it go get the newly runnable thread.
>> > 
>> > If the processors are halting in the idle loop however, it may take
>> > quite a while for the new work to be noticed..
>> > (possibly up to milliseconds I think)
>> > 
>> > Is there a mechanism to send an IPI to particular processors?
>> > or is it just broadcast?  
>> > 
>> > 
>> > I think we would be better served to alter idle_proc(void *dummy)
>> > (or maybe choosethread()) to increment or decrement a count
>> > of idle processors (atomically of course) so that 
>> > setrunnable (or it's lower parts) can send that IPI
>> > and get the idle processor into actioan as soon as a thread is
>> > available.
>> > 
>> > I have not seen any such code but maybe I'm wrong
>> 
>> This is why HLT is not enabled in SMP by default (or at least was,
>> it may be turned on now).  Given that the clock interrupts are
>> effectively broadcast to all CPU's one way or another for all
>> arch's (that I know of), you will never halt more than the interval
>> between clock ticks on any CPU.
> 
> 
> So here are some figures..
> dual# sysctl machdep.cpu_idle_hlt
> machdep.cpu_idle_hlt: 1
> 307.773u 93.000s 4:22.17 152.8% 3055+5920k 51+1046io 284pf+0w
> 307.762u 93.082s 4:23.22 152.2% 3061+5925k 4+1012io 8pf+0w
> 
> dual# sysctl machdep.cpu_idle_hlt=0
> machdep.cpu_idle_hlt: 1 -> 0
> 
> 357.264u 115.377s 4:25.21 178.2%3150+5982k 7+1021io 8pf+0w
> 356.193u 116.551s 4:24.70 178.5%3145+5980k 5+991io 8pf+0w
>  
> reboot to kernel with IPIs for idle processors.. (patch available)
> 
> dual# sysctl machdep.cpu_idle_hlt
> machdep.cpu_idle_hlt: 1
> 
> 308.113u 90.422s 4:19.46 153.5% 3061+5941k 13+989io 22pf+0w
> 308.430u 93.501s 4:22.86 152.9% 3045+5897k 70+1022io 8pf+0w
> 
> dual# sysctl machdep.cpu_idle_hlt=0
> machdep.cpu_idle_hlt: 1 -> 0
> 357.809u 113.757s 4:24.12 178.5%3148+6020k 31+1016io 8pf+0w
> 356.193u 115.195s 4:24.22 178.4%3150+5983k 30+1029io 8pf+0w
> 
> dual# sysctl machdep.cpu_idle_hlt=1
> machdep.cpu_idle_hlt: 0 -> 1
> 308.132u 92.196s 4:23.15 152.1% 3044+5910k 30+1033io 8pf+0w
> 307.504u 93.581s 4:23.22 152.3% 3047+5913k 29+1055io 8pf+0w
> 
> What is so stunning is the massive increase in user time 
> for the case where the cpu is not being idled.
> I'm hoping this is a statistical artifact of some sort..

I don't think it is, but you'd need more samples to be truly confident.
One possible reason: having the CPU's not halt means that idle CPU's
bang on the runq state continuously.  Perhaps this can penalize the
non-idle CPU's due to cache interactions both when the non-idle CPU's
are manipulating the queues and also by making the cache lines holding
the queue state always be resident and not allowing their effective use
by the real code executing on other CPUs.

> either way, the times are almost identical.
> Having the cpu halt during idle time seems to be 
> slightly faster (1 second out of 250? not too significant)
> It would however be good to see thread wakeup latency times.
> (I'll work on that)
> 
> The patch to send an IPI when an thread becomes runnabel and there 
> are idle CPUs seems to not hurt this case at least.
> it may however make a lot of difference in the case of
> KSE threads waking each other up..
> I'll do some tests.

Yes.  As it stands now, adding the IPI would just make things more
complex for no gain.  However, if this IPI is present, then we can
engage in perhaps more drastic measures like really putting a CPU
to sleep (perhaps disabling interrupts to it?) until it is needed
which might bring significant power and heat savings to idle SMP
machines.

> It seems however that having the halt on idle turned on is the 
> right thing these days. (which is the current default)
> but the odd user times are a worry.

I'm sure Terry is all torn up by that conclusion. :-P

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

radeon lockups w/ 5.1-R

[Matthias Buelow]

Hi folks,

anyone else still seeing occasional lockups when using a Radeon
graphics card?  I've had these frequently with a R7500 on 5.0p7
and now installed 5.1 hoping that the issue had been fixed in
the meantime.  It went well for two days but it just fscked up
again so the problem is still there.  It only happens when I
exit the X session.  Display becomes garbled and the machine
locked up completely (didn't always do so in the past with 5.0,
I sometimes could log in over the network and reboot the machine.)
I think the problem was already known for 5.0, or does it warrant
a new PR?

-- 
  Matthias Buelow;  [EMAIL PROTECTED],informatik.uni-wuerzburg.de}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: BSD video capture emulation question

[John-Mark Gurney]

Sean Welch wrote this message on Thu, Jul 10, 2003 at 08:29 -0500:
> Linux accomplishes this with the video4linux API and
> thus has access to a wide range of usb webcams for use
> with programs like gnomemeeting.  FreeBSD has no such
> API though it does have programs like cqcam, camserv,
> and bktr2jpeg (not in ports)... for obsolete cameras.
> It seems Linux achieves its success with devices
> represented as a generic video device handled directly
> by the kernel.  The programs I mentioned above are
> userland programs (of course) and so don't (apparently)
> have the same utility.

Yes, video capture in FreeBSD is sorely lacking.  I recently did a
Zoran driver and found that the bktr interface is horrid.

> Asking around it seems that porting the video4linux
> API would be tedious and exceedingly painful (my
> paraphrasing).  It also has the possible disadvantage
> of being GPL'd -- personally I think BSD (Free, Net,
> and Open) would benefit more from a BSD licensed
> solution.  It seems writing a video4bsd API from
> scratch that is compatible with video4linux would also
> be rather daunting.

Not only that, but the v4l interface isn't that great.  It also doesn't
mesh with FreeBSD's newbus frame work.

> It occurred to me however that there does exist one
> kernel video device -- the bktr device family.  It is

(originally meteor)

> well established and works well (that is what I read,
> at any rate).  In addition, the firewire video capture
> program is not GPL'd (to the best of my knowledge) and
> seems a good candidate.  My impression is that capture
> from firewire is a bit more straight-forward than
> capture from usb.  Apple is now stirring up the
> industry with iSight and I expect it will increase the
> availability of firewire webcams at lower prices.
> 
> So, would it be possible to emulate a bktr device
> front end for a firewire cam (of some sort) in the
> same manner as is currently done with atapicam for
> scsi emulation on top of atapi?

This may be possible.  It shouldn't be too hard to write a bunch
of shims to convert it.  I would rather see work be done on
creating a better interface.  Also, just doing a kernel interface like
v4l is not good for future.  I would like to see a combination of
kernel and userland library.  That way for usb web cams, we can keep
the driver in userland w/o expecting the user to load a kernel module.

> FreeBSD keeps up so well in all the other categories
> relevant to a desktop media system that it would be
> really nice to have it also encompass this ability.
> Not to mention it would allow me to video conference
> with the rest of my family located 1100 miles away
> without resorting to another operating system.
> 
> I'm not competent enough to attempt this myself (yet!)
> but I'm more than willing to help as much as I can
> with coding and testing (assuming this proposition is
> even feasible).

I'm definately interested in this too.

Also, a better list for this would be -multimedia.  I have cc'd the
list.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: what is the suggested way to do void * arithmetic ?

[Amar Takhar]

On 2003-07-10 12:03 -0700, Tim Kientzle wrote:
> David Leimbach wrote:
> >I think C takes a more low-level approach and says "void * is just an
> >address
> >void * + 1 means the next valid address".
>
> This is not true.
>
> The ANSI C standard forbids arithmetic on void * pointers,
> just as C++ does.
>
> GNU gcc has supported void * arithmetic for a long
> time as an extension, but it's not standard behavior
> and you should not rely on it.


Yes, please don't it'll just make things harder for TenDRA in the future :)

<-goes back to his cave.


Amar.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: what is the suggested way to do void * arithmetic ?

[Tim Kientzle]

David Leimbach wrote:
I think C takes a more low-level approach and says "void * is just an address
void * + 1 means the next valid address".
This is not true.

The ANSI C standard forbids arithmetic on void * pointers,
just as C++ does.
GNU gcc has supported void * arithmetic for a long
time as an extension, but it's not standard behavior
and you should not rely on it.
Tim Kientzle

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: panic: kmem_malloc

[Bosko Milekic]

Sorry for the top-reply...

But for now the only advice I have is that you tune the boot-time
kern.vm.kmem.size tunable.  Don't set it too high, but you can try about
250,000 for your configuration.  The constant we have that caps the size
is getting too small and we're at least going to have to bump that up
soon.

-Bosko

On Thu, Jul 10, 2003 at 07:45:46PM +0200, Lukas Ertl wrote:
> Hi,
> 
> we are currently stress-testing two 5.1 machines. Each of the machines
> have a 2.6GHz P4 and 512 MB RAM. The machines are running zebra, ospfd and
> nscd. We bomb the machines with many DNS requests (up to 50k/s),
> transmitted over Gigabit Ethernet.
> 
> Unfortunately, both machines panic soon after starting the tests, and both
> go down with "kmem_malloc(4096): kmem_map too small" and says the current
> process is "4 (g_down)". I'd love to present a coredump and a backtrace,
> but somehow it just doesn't dump, it rather panics again with
> "ata_dmasetup: transfer active".
> 
> Well, if I get this right, it means that the kernel VM is exhausted. Is
> there anything I can do apart from using more RAM?
> 
> regards,
> le
> 
> -- 
> Lukas Ertl eMail: [EMAIL PROTECTED]
> UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
> Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
> der Universit?t Wien   http://mailbox.univie.ac.at/~le/
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 
> 

-- 
Bosko Milekic  *  [EMAIL PROTECTED]  *  [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 3D graphic cards

[Scott M. Likens]

On Thu, 2003-07-10 at 07:03, Bruno Afonso wrote:
> Dag-Erling Smørgrav wrote:
> 
> > "Julian St." <[EMAIL PROTECTED]> writes:
> > 
> >>is there any list that provides information about what graphic cards
> >>on FreeBSD have supported 3D acceleration? (I need only X-Video
> >>support in particular, but it seems tied to 3D acceleration).
> > 
> > 
> > http://people.freebsd.org/~anholt/dri/
> > 
> > Radeon-based cards (up to 8500) are fairly cheap and work well.
> 
> No they don't. I have a radeon 7200 and at the moment the support seems 
> to be broken (I don't think anyone has updated XFree to fix it). This is 
> on 5.1. Search the -current archives and you will someone also 
> complaining about it.

That's funny knowing I have a ATI Radeon 7200 and I have ALWAYS
supported FreeBSD and the ATI Radeon for ages.  Ever since one person
known as 'erek' showed me DRI-HEAD i've learned that XFree86 4.3.0 is
just a little outdated.

I use DRI-HEAD on my other server that is using a Matrox G400 Dual Head
also, works snappy on 5.1

I stopped relying on XFree to keep updating their stuff along time ago. 
I've had problems with DRI admitidly but it works now.

They get the kinks out in waves if you ask me.

-- 
Scott M. Likens <[EMAIL PROTECTED]>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

small scheduler hack/patch

[Julian Elischer]

I have a small "proof of concept" scheduler hack at:
http://www.freebsd.org/~julian/it.diff

what it is supposed to do is check if there is an idle CPU at the time
that a thread is made runnable (assuming that idle CPUs are halted)
and if there is, it selects an idle CPU and gives it an IPI
to wake it up. (presumably it will then pick up the work).

It's only implemented for SMP/i386 as the code to halt the cpu is only
present (from my quick view) in x86 and it doesn't make sense in UP..

any comments and suggestions? (oh, and yes it's only in the 4bsd
scheduler.. I think jeff already handles this sort of thing).


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

panic: kmem_malloc

[Lukas Ertl]

Hi,

we are currently stress-testing two 5.1 machines. Each of the machines
have a 2.6GHz P4 and 512 MB RAM. The machines are running zebra, ospfd and
nscd. We bomb the machines with many DNS requests (up to 50k/s),
transmitted over Gigabit Ethernet.

Unfortunately, both machines panic soon after starting the tests, and both
go down with "kmem_malloc(4096): kmem_map too small" and says the current
process is "4 (g_down)". I'd love to present a coredump and a backtrace,
but somehow it just doesn't dump, it rather panics again with
"ata_dmasetup: transfer active".

Well, if I get this right, it means that the kernel VM is exhausted. Is
there anything I can do apart from using more RAM?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemadministrator   Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)   Fax.:  (+43 1) 4277-9140
der Universität Wien   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kudos to FreeBSD team!!!

[David Leimbach]

 I second that!

5.2 is going to have some good stuff in it!!  I am very enthusiastic about it.

It will be the first release that supports my Asus board's SATA controller... {Silicon 
Image 3112A}.

There are even new Nvidia drivers to try on FreeBSD CURRENT.

Seems we aren't as dead as the trolls would have you think :).

Dave
On Thursday, July 10, 2003, at 11:55AM, John Reynolds~ <[EMAIL PROTECTED]> wrote:

>Hi all, just wanted to send a quick "kudos" message to everybody involved in
>bringing -current up to the 5.1-RELEASE level of quality. I finally got my new
>h/w in and assembled and 5.1-RELEASE installed flawlessly on it. No issues!
>The system feels solid and looks great.
>
>Great work! I eagerly look forward to 5.2!
>
>-Jr
>
>-- 
>John ReynoldsSr. Physical Design Engineer - WCCG/CCE PDE
>Intel Corporation   MS: CH6-210   Phone: 480-554-9092RIM PIN: 10326855
>[EMAIL PROTECTED] (e-mail with "PAGE" in subj to forward to RIM)
>
>___
>[EMAIL PROTECTED] mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: PATCH - updated EC driver

[Nate Lawson]

On Wed, 9 Jul 2003, John Baldwin wrote:
> Yes, this gets rid of the message at boot times.  I do get some of these messages
> while the system is running, but I used to receive those erros before.  The only
> difference is that now the error code is AE_NO_HARDWARE_RESPONSE rather than
> AE_ERROR.

Ok, I have committed the patch and the default behavior is to wait up to
50 ms instead of 10 ms (which was the previous default).  For waits longer
than 1 ms, msleep is used instead of DELAY.  I'm hoping 50 ms is enough to
even get rid of your occasional timeouts.  I changed the error code to be
more descriptive than AE_ERROR so that is intentional.

Let me know if there are any problems.

-Nate

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: what is the suggested way to do void * arithmetic ?

[David Leimbach]

 I always feel better when I convert void * to char * but that's probably 
because C++ doesn't allow pointer arithmetic on void *'s.  The argument
being that you don't know the size of what's being pointed to with a void *
and therefore can't know how far to seek the the pointer to get to the next
valid address.

I think C takes a more low-level approach and says "void * is just an address
void * + 1 means the next valid address".

Anyway... it just seems to help when porting code between C/C++ to use
char *...

my $0.02.

Dave
On Thursday, July 10, 2003, at 11:40AM, Luigi Rizzo <[EMAIL PROTECTED]> wrote:

>On Thu, Jul 10, 2003 at 03:42:04AM -0700, Terry Lambert wrote:
>> Luigi Rizzo wrote:
>> > in several places in ipfw2.c i have to move pointers across
>> > structures of variable length (lists of ipfw2 instructions
>> > returned by the getsockopt()), and i use the following type of code:
>> > 
>> > void *next;
>> > foo *p;
>> > next = (void *)p + len;
>> > foo = (foo *)p + len;
>^^
>
>sorry i meant   p = (void *)p + len;
>
>...
>> I don't understand the second one.  The first one blows up because
>> you aren't parenthesizing, e.g.:
>> 
>>  next = (void *)(p + len);
>> 
>> The compiler is complaining because it doesn't know sizeof(*((void *)0))
>
>ok, it actually evaluates to 1 and i thought it was some standard, probably
>it is not so i guess i have to cast to (char *) instead
>
>   thanks
>   luigi
>
>> (pointer arithmatic is coerced to the type of the lvalue, in most
>> cases of casts).
>> 
>> Unless you are referencing them as array elements (in which case,
>> packing becomes a problem for you, when referencing them as arrays
>> of foo's, since you don't know how foo's are packed in an array),
>> you should probably cast them to char for the arithmatic, and add
>> them with byte counts.
>> 
>> -- Terry
>___
>[EMAIL PROTECTED] mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [acpi-jp 2393] Re: Updated ec-burst.diff patch

[Nate Lawson]

On Sat, 5 Jul 2003, Anish Mistry wrote:
> I applied it on my Fujitsu P-2110 and rebuilt world, but didn't see any
> changes or regression.
> Outstanding issues:
> - - Battery still drains uncontrollably in S3
> - - USB devices dead on resume (working a usb code patch for this)

Please send me your patch for reseting USB on resume.  I will test it and
commit it.

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Witness panic (fxp/polling related)

[Robin P. Blanchard]

Sources as of this morning yield:

(kgdb) bt full
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
No locals.
#1  0xc01d805b in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
No locals.
#2  0xc01d8373 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
td = (struct thread *) 0xc151e390
bootopt = 256
newpanic = 1
ap = 0xd6935c30 "'Y0À\003\006"
buf = "recurse", '\0' 
#3  0xc01fae9d in witness_lock (lock=0xc152c160, flags=8, 
file=0xc0305927 "/usr/src/sys/dev/fxp/if_fxp.c", line=1502)
at /usr/src/sys/kern/subr_witness.c:651
lock_list = (struct lock_list_entry **) 0xc151e3fc
lle = (struct lock_list_entry *) 0xc151e3fc
lock1 = (struct lock_instance *) 0xc03865fc
lock2 = (struct lock_instance *) 0x0
class = (struct lock_class *) 0xc0333c0c
w = (struct witness *) 0xc0363348
w1 = (struct witness *) 0xc01de131
td = (struct thread *) 0xc151e3fc
i = -694985628
go_into_ddb = 0
#4  0xc01cf743 in _mtx_lock_flags (m=0xc151e3fc, opts=0, file=0xc03865fc
"`ÁRÁ'Y0À\003\006", 
line=-1051541152) at /usr/src/sys/kern/kern_mutex.c:334
No locals.
---Type  to continue, or q  to quit---
#5  0xc0183af7 in fxp_poll (ifp=0xc03865fc, cmd=3243426144, count=0)
at /usr/src/sys/dev/fxp/if_fxp.c:1502
sc = (struct fxp_softc *) 0xc151e3fc
statack = 193 'Á'
#6  0xc0183cb1 in fxp_intr (xsc=0xc152c000) at
/usr/src/sys/dev/fxp/if_fxp.c:1553
sc = (struct fxp_softc *) 0xc152c000
ifp = (struct ifnet *) 0xc152c000
statack = 0 '\0'
#7  0xc01c60d2 in ithread_loop (arg=0xc4023a80) at
/usr/src/sys/kern/kern_intr.c:534
ithd = (struct ithd *) 0xc4023a80
ih = (struct intrhand *) 0xc401dec0
td = (struct thread *) 0xc151e390
p = (struct proc *) 0xc401e3c8
#8  0xc01c523e in fork_exit (callout=0xc01c5f80 , arg=0x0,
frame=0x0)
at /usr/src/sys/kern/kern_fork.c:794
td = (struct thread *) 0x0
p = (struct proc *) 0xc401e3c8
(kgdb) 

---
Robin P. Blanchard
Systems Integration Specialist
Georgia Center for Continuing Education
fon: 706.542.2404 <|> fax: 706.542.6546
---
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Kudos to FreeBSD team!!!

[John Reynolds~]

Hi all, just wanted to send a quick "kudos" message to everybody involved in
bringing -current up to the 5.1-RELEASE level of quality. I finally got my new
h/w in and assembled and 5.1-RELEASE installed flawlessly on it. No issues!
The system feels solid and looks great.

Great work! I eagerly look forward to 5.2!

-Jr

-- 
John ReynoldsSr. Physical Design Engineer - WCCG/CCE PDE
Intel Corporation   MS: CH6-210   Phone: 480-554-9092RIM PIN: 10326855
[EMAIL PROTECTED] (e-mail with "PAGE" in subj to forward to RIM)

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: what is the suggested way to do void * arithmetic ?

[Luigi Rizzo]

On Thu, Jul 10, 2003 at 03:42:04AM -0700, Terry Lambert wrote:
> Luigi Rizzo wrote:
> > in several places in ipfw2.c i have to move pointers across
> > structures of variable length (lists of ipfw2 instructions
> > returned by the getsockopt()), and i use the following type of code:
> > 
> > void *next;
> > foo *p;
> > next = (void *)p + len;
> > foo = (foo *)p + len;
^^

sorry i meant   p = (void *)p + len;

...
> I don't understand the second one.  The first one blows up because
> you aren't parenthesizing, e.g.:
> 
>   next = (void *)(p + len);
> 
> The compiler is complaining because it doesn't know sizeof(*((void *)0))

ok, it actually evaluates to 1 and i thought it was some standard, probably
it is not so i guess i have to cast to (char *) instead

thanks
luigi

> (pointer arithmatic is coerced to the type of the lvalue, in most
> cases of casts).
> 
> Unless you are referencing them as array elements (in which case,
> packing becomes a problem for you, when referencing them as arrays
> of foo's, since you don't know how foo's are packed in an array),
> you should probably cast them to char for the arithmatic, and add
> them with byte counts.
> 
> -- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: jails and 5-roadmap ?

[Bjoern A. Zeeb]

On Thu, 10 Jul 2003, Pawel Jakub Dawidek wrote:

> On Wed, Jul 09, 2003 at 11:28:45PM +0200, Poul-Henning Kamp wrote:
> +> >there are floating around some patches for jails. At least
> +> >- multi-IP
> +> >- statfs restrictions
> +> >- sysv
> +> >come to my mind and there are perhaps others too.
>
> It looks like all of those are mine:
>
>   http://garage.freebsd.pl

yeah I know. At least most. I also have a statfs restriction patch for
5.x (compileable as module starting with ~5.1). It's mostly the same
as yours but some more sysctl options etc.

see http://sources.zabbadoz.net/freebsd/jail.html or kern/49085.


> And there are few more. My favorite one is multi-level jails - you can

Yes some other are still floating around I guess.


> Exactly. And my patches are in desynch with current source, because it
> is hard to maintain them when they aren't intergrated...

yeah, great problem :( I copied most of the sources for the .ko
from sys/* and added my patches + some module magic. This had been
the easiest way for me.

> And here I am!:)

Many thanks.

-- 
Bjoern A. Zeeb  bzeeb at Zabbadoz dot NeT
56 69 73 69 74  http://www.zabbadoz.net/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

5.1R system crash (VT8233/33A AC97)

[Ion-Mihai Tetcu]

Hi,

Are know problems with the VT8233/33A AC97
[EMAIL PROTECTED]:17:5: class=0x040100 card=0xa0021458 chip=0x30591106 rev=0x50 
hdr=0x00
vendor   = 'VIA Technologies Inc'
device   = 'VT8233/33A AC97 Enhanced Audio Controller'
class= multimedia
subclass = audio
?
I've started a thread:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=816905+0+current/freebsd-questions 
that ended with the suggestion of sending a bug-report, but I want to 
check here first if there is someone with the same problem ?

I don't know if there is HW or aRts/KDE related.

Thanks,
IOnut
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

BSD video capture emulation question

[Sean Welch]

First the question, then the motivation and reasoning.

Is it feasible to create an emulation interface for
firewire video capture such that it appears as a bktr
device?

I've recently begun playing with gnomemeeting and had
some success with the audio conferencing end of it.
I'm able to receive video feeds, but unable to send
them.  This is because 2.5 years ago I made the
transition to a laptop as my main workstation.  I no
longer even maintain a desktop system.

I use this laptop for everything -- including a media
center (of sorts).  I don't need Windows or Linux for
this and I'm quite a bit more productive under
FreeBSD than I would be under either of the other two
(and the performance happens to be better as well).
FreeBSD is well equiped to handle everything you might
normally run across (ogle, wavrec, mplayer, mozilla,
flashplugin-wrapper, mplayerplug-in, DRI, s10sh, gimp,
gaim, gnomemeeting, TeX, OpenOffice, VMWare, realplay,
xmms, apache, samba, etc) EXCEPT video capture.

Linux accomplishes this with the video4linux API and
thus has access to a wide range of usb webcams for use
with programs like gnomemeeting.  FreeBSD has no such
API though it does have programs like cqcam, camserv,
and bktr2jpeg (not in ports)... for obsolete cameras.
It seems Linux achieves its success with devices
represented as a generic video device handled directly
by the kernel.  The programs I mentioned above are
userland programs (of course) and so don't (apparently)
have the same utility.

Asking around it seems that porting the video4linux
API would be tedious and exceedingly painful (my
paraphrasing).  It also has the possible disadvantage
of being GPL'd -- personally I think BSD (Free, Net,
and Open) would benefit more from a BSD licensed
solution.  It seems writing a video4bsd API from
scratch that is compatible with video4linux would also
be rather daunting.

It occurred to me however that there does exist one
kernel video device -- the bktr device family.  It is
well established and works well (that is what I read,
at any rate).  In addition, the firewire video capture
program is not GPL'd (to the best of my knowledge) and
seems a good candidate.  My impression is that capture
from firewire is a bit more straight-forward than
capture from usb.  Apple is now stirring up the
industry with iSight and I expect it will increase the
availability of firewire webcams at lower prices.

So, would it be possible to emulate a bktr device
front end for a firewire cam (of some sort) in the
same manner as is currently done with atapicam for
scsi emulation on top of atapi?

FreeBSD keeps up so well in all the other categories
relevant to a desktop media system that it would be
really nice to have it also encompass this ability.
Not to mention it would allow me to video conference
with the rest of my family located 1100 miles away
without resorting to another operating system.

I'm not competent enough to attempt this myself (yet!)
but I'm more than willing to help as much as I can
with coding and testing (assuming this proposition is
even feasible).

Sean
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: wierd dsl performance with -CURRENT

[Kenneth Culver]

> You should visit the FreeBSD -performance list archives for a
> (fairly) recent discussion on network performance (I believe
> between a couple of us, we were able to come up with tuning
> parameters that improved someone's file transfer performance by
> about a factor of 10 for some tests).

Remember the name of the thread?

Ken
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 3D graphic cards

[Bruno Afonso]

Dag-Erling Smørgrav wrote:

"Julian St." <[EMAIL PROTECTED]> writes:

is there any list that provides information about what graphic cards
on FreeBSD have supported 3D acceleration? (I need only X-Video
support in particular, but it seems tied to 3D acceleration).


http://people.freebsd.org/~anholt/dri/

Radeon-based cards (up to 8500) are fairly cheap and work well.
No they don't. I have a radeon 7200 and at the moment the support seems 
to be broken (I don't think anyone has updated XFree to fix it). This is 
on 5.1. Search the -current archives and you will someone also 
complaining about it.

--
Bruno Miguel Afonso
Biological Eng. student.
D.E.Q. @ I.S.T. - Portugal
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: lock order reversal

[Kris Kennaway]

On Thu, Jul 10, 2003 at 11:58:14AM +0200, Gordon Bergling wrote:
> Hi,
> 
> getting this on a -current from 'Jul  6 23:16:01 CEST 2003'.
> I'll recieve this error a few minutes ago directly after booting the
> system. No user where logged in this time.

FAQ..it's harmless

Kris


pgp0.pgp
Description: PGP signature

[-CURRENT tinderbox] failure on sparc64/sparc64

[Tinderbox]

TB --- 2003-07-10 10:55:44 - starting CURRENT tinderbox run for sparc64/sparc64
TB --- 2003-07-10 10:55:44 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-10 10:58:07 - building world
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
>>> stage 3: cross tools
>>> stage 4: populating 
>>> /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include
>>> stage 4: building libraries
>>> stage 4: make dependencies
>>> stage 4: building everything..
[...]
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/getvfsbyname.3 
> getvfsbyname.3.gz
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/getvfsent.3 > 
getvfsent.3.gz
gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/glob.3 
> glob.3.gz
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/initgroups.3 > 
initgroups.3.gz
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/isgreater.3 > 
isgreater.3.gz
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/ldexp.3 > 
ldexp.3.gz
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/lockf.3 > 
lockf.3.gz
Bus error (core dumped)
*** Error code 138

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
TB --- 2003-07-10 11:34:54 - /usr/bin/make returned exit code  1 
TB --- 2003-07-10 11:34:54 - ERROR: failed to build world
TB --- 2003-07-10 11:34:54 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: what is the suggested way to do void * arithmetic ?

[Terry Lambert]

Luigi Rizzo wrote:
> in several places in ipfw2.c i have to move pointers across
> structures of variable length (lists of ipfw2 instructions
> returned by the getsockopt()), and i use the following type of code:
> 
> void *next;
> foo *p;
> next = (void *)p + len;
> foo = (foo *)p + len;
> 
> When using WARNS=5, the compiler in -current flags them with 'Warning
> void * arithmetic'.
> 
> What is the best way to do the above given that i do need to use
> these variable-size structures ?

I don't understand the second one.  The first one blows up because
you aren't parenthesizing, e.g.:

next = (void *)(p + len);

The compiler is complaining because it doesn't know sizeof(*((void *)0))
(pointer arithmatic is coerced to the type of the lvalue, in most
cases of casts).

Unless you are referencing them as array elements (in which case,
packing becomes a problem for you, when referencing them as arrays
of foo's, since you don't know how foo's are packed in an array),
you should probably cast them to char for the arithmatic, and add
them with byte counts.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Panic linux ldconfig with MUTEX_PROFILING

[Bruce Evans]

On Thu, 10 Jul 2003, Dag-Erling [iso-8859-1] Smørgrav wrote:

> Jun Kuriyama <[EMAIL PROTECTED]> writes:
> > I'm trying to use MUTEX_PROFILING, but paniced in linux ldconfig.
> > Any clues?
>
> is COMPAT_LINUX compiled into the kernel?  You can't use modules with
> MUTEX_PROFILING; it changes the size and layout of struct mtx, and
> since modules aren't built with the same options as the kernel, they
> use the wrong struct mtx.

This was broken in rev.1.9 of _mutex.h:

% RCS file: /home/ncvs/src/sys/sys/_mutex.h,v
% Working file: _mutex.h
% head: 1.9
% ...
% 
% revision 1.9
% date: 2002/12/29 11:14:41;  author: phk;  state: Exp;  lines: +6 -1
% Save 16 bytes per mutex if MUTEX_PROFILING is not defined.
%
% MUTEX_PROFILING is in opt_global.h, so this does not introduce a risk of
 ^
% variant structure sizes unless foreign kernel modules are used.
  ^^
%
% This saved 16 bytes per vnode and 16 bytes per vm object for a total of
% 4MB on a 2GB machine.
%
% Idea from:alc
% 

Actually, this ensures variant struct sizes if *any* kernel module is used.

The saving is machine-dependent (24 instead of 16 on most 64-bit
machines).  If bloat is a problem, then there is plenty more in the
mutex struct (not to mention the vnode struct) that could be attacked
(mainly for LOCK_DEBUG in the case of mutexes).  I think mutex profiling
should use external data, but this would be less efficient and more
work to implement.  Perhaps similarly for LOCK_DEBUG, but LOCK_DEBUG is
still needed in most configurations, unlike MUTEX_PROFILING.

Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HTT on single CPU?

[Terry Lambert]

Jens Rehsack wrote:
> How can I found out whether a board supports HTT or not?
> I haven't seen it in none description I checked. Are some
> chipsets (865, 875) always ready or is the bios programmer
> the guy who must activate this feature?

One non-obvious-at-first-glance thing that springs to mind is
that for a single CPU board, you have to pick one with a support
chipset that includes an IO APIC (minimally), since the SMP code
require that you use APIC I/O.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

lock order reversal

[Gordon Bergling]

Hi,

getting this on a -current from 'Jul  6 23:16:01 CEST 2003'.
I'll recieve this error a few minutes ago directly after booting the
system. No user where logged in this time.

lock order reversal
 1st 0xc2ea9094 vm object (vm object) @ /usr/src/sys/vm/vm_object.c:1516
 2nd 0xc082f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:325
Stack backtrace:
backtrace(c03cb376,c082f110,c03d9b16,c03d9b16,c03d99b1) at backtrace+0x17
witness_lock(c082f110,8,c03d99b1,145,1) at witness_lock+0x697
_mtx_lock_flags(c082f110,0,c03d99b1,145,60e) at _mtx_lock_flags+0xb1
_vm_map_lock(c082f0b0,c03d99b1,145,c03c7a6a,1bc) at _vm_map_lock+0x36
kmem_malloc(c082f0b0,1000,101,d27e8a8c,c0357f5a) at kmem_malloc+0x39
page_alloc(c083a1c0,1000,d27e8a7f,101,c041210c) at page_alloc+0x27
slab_zalloc(c083a1c0,101,c03db375,664,c268ba94) at slab_zalloc+0x14a
uma_zone_slab(c083a1c0,101,c03db375,664,0) at uma_zone_slab+0xd8
uma_zalloc_internal(c083a1c0,0,101,6e8,0) at uma_zalloc_internal+0x55
uma_zfree_arg(c268ba80,d1c36114,0,1,0) at uma_zfree_arg+0x2e7
swp_pager_meta_free(c2ea9094,1a,0,1,0) at swp_pager_meta_free+0x1b2
swap_pager_freespace(c2ea9094,1a,0,1,0) at swap_pager_freespace+0x57
vm_object_backing_scan(c2c725c8,4,c03da44e,5ec,c03da44e) at
vm_object_backing_scan+0x36a
vm_object_collapse(c2c725c8,0,c03da44e,1ef,c02390d0) at
vm_object_collapse+0xdd
vm_object_deallocate(c2e6b940,c285b03c,c2e6b940,c285b03c,d27e8c64) at
vm_object_deallocate+0x28e
vm_map_entry_delete(c2c73200,c285b03c,c03d9b84,8bc,c03c6b3c) at
vm_map_entry_delete+0x3b
vm_map_delete(c2c73200,0,bfc0,c2c73200,c2690380) at
vm_map_delete+0x3e3
vm_map_remove(c2c73200,0,bfc0,11d,c03c60ed) at vm_map_remove+0x58
exit1(c2dd8980,0,c03c60ed,65,d27e8d40) at exit1+0x696
sys_exit(c2dd8980,d27e8d10,c03def62,3fd,1) at sys_exit+0x41
syscall(2f,2f,2f,0,) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (1), eip = 0x2829f29f, esp = 0xbfbfc3ec, ebp = 0xbfbfc408
---

best regards,

Gordon

-- 
There is no place like 127.0.0.1/8!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: wierd dsl performance with -CURRENT

[Terry Lambert]

Kenneth Culver wrote:
> > Just as an experiment, try setting "net.inet.tcp.newreno" to 0 using
> > sysctl(8).  It might help; it might not.  Please let us know.
> 
> It didn't help. I also tried setting several other sysctl OID's in
> net.inet.tcp, but nothing helped. I'm totally out of ideas for why this
> could be happening. I mean it IS only 16KB/sec, but it seems wierd that
> only FreeBSD is having problems out of all the OS's I use at home.

Your Macintosh processes network traffic differently than FreeBSD
does.  What it does is basically this:

o   Network interrupts kick off a Mach thread that runs the
data from the card into a buffer in the IOKit driver,
until there is no more data, or until the buffer hits
a high watermark.

o   They kick another Mach thread telling it there's data,
and that Mach thread begins servicing the data.  In
the meantime, you may get more interrupts.  The second
Mach thread loads the data through ether_input.  This
in turn goes through the network stack, and is, in effect,
the NETISR processing as well.

What this basically means is that there is a lot less latency in
the MacOS X stack than there is in the normal FreeBSD stack.

You can't do this without redesigning FreeBSD's network handling,
and getting away from the 5.x "interrupt thread" style architecture;
that's a long discussion, though.

But there are some things you can do.

You should visit the FreeBSD -performance list archives for a
(fairly) recent discussion on network performance (I believe
between a couple of us, we were able to come up with tuning
parameters that improved someone's file transfer performance by
about a factor of 10 for some tests).

The major part of this discussion was about turning on direct
dispatch, dealing with polling, tuning TCP paramters via sysctl,
and setting a number of kernel options.

I would *NOT* recommend adjusting the TCP timers in your case, but
you *could* make the NETISR happen more frequently by upping your
HZ value.

If you want to discuss performance issues in networking further,
-performance or -net are much better lists to use than -current,
which is kind of a generic catch-all list for work on FreeBSD 5.x.


Or... you could also just do the work and fix the code.

Now, you are using a link with a big downchannel and a large
upchannel; the ideal way to use such a link is called "rate based
ACK", which basically means that you send your ACK up at timed
intervals according to the data rate, instead of sending it up
at "window full" intervals and risking getting stalled.  There
is a FreeBSD committer who got her Master's degree based on work
in this area: Jennifer Yang.

One way to (almost) get this effect would be to set the "PUSH"
option on the socket; this won't effect ACK's in FreeBSD, though.

Another way is to implement TCP Rate Halving.  This is much better
than New Reno at congestion avoidance; it was implemented in a
fairly recent NetBSD stack at Carnegie-Mellon's Pittsburgh
Supercomputing Center (CMU PSC).  Their implementation is available
on the net for download, but you would have to hack it.

Another way is called Lazy Receiver Processing (LRP).  LRP comes
out of Peter Druschel's group at Rice University, and was developed
as part of the Scala Server Project.  Mohit Aron, who last I heard
wa working for Zambeel (a distributed storage area network FS
company in the Bay Area) did the most recent work on that for 4.x
FreeBSD; it has a pretty bad license.  There is also a port of it
to a more recent 4.x by a researcher from Duke University.  This
would be an easy port, but the code isn't really that production,
and if you were going to productize it, you should probably start
with the ancient 2.4 implementation, which has a free license.

I mention this last, because I'm always hopeful that someone who
has a chance of getting the code committed because they already
have commit bits, and it's easier to ask for forgiveness than
permission, will do the work on the other, better approaches.  ;^).

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: what is the suggested way to do void * arithmetic ?

[Harti Brandt]

On Thu, 10 Jul 2003, Luigi Rizzo wrote:

LR>
LR>Hi,
LR>in several places in ipfw2.c i have to move pointers across
LR>structures of variable length (lists of ipfw2 instructions
LR>returned by the getsockopt()), and i use the following type of code:
LR>
LR> void *next;
LR> foo *p;
LR>
LR> ...
LR>
LR> next = (void *)p + len;
LR> ...
LR> foo = (foo *)p + len;
LR>
LR>When using WARNS=5, the compiler in -current flags them with 'Warning
LR>void * arithmetic'.
LR>
LR>What is the best way to do the above given that i do need to use
LR>these variable-size structures ?

Because sizeof(char), sizeof(unsigned char) and sizeof(signed char) all
are defined to be 1 by the standard, any of them'll do it. Arithmetic on
void pointers is undefined by the standard.

next_foo = (struct foo *)((char *)this_foo + this_foo->len);

provided that the object pointed to by this_foo is at least this_foo->len
bytes long.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: jails and 5-roadmap ?

[Pawel Jakub Dawidek]

On Wed, Jul 09, 2003 at 11:28:45PM +0200, Poul-Henning Kamp wrote:
+> >there are floating around some patches for jails. At least
+> >- multi-IP
+> >- statfs restrictions
+> >- sysv
+> >come to my mind and there are perhaps others too.

It looks like all of those are mine:

http://garage.freebsd.pl

And there are few more. My favorite one is multi-level jails - you can
run jails in jails, jails in those jailed jails, etc.:)

+> > [...]
+> >
+> >So my question from a user's point of view is if anybody is working on
+> >integrating these or if we can get some of this done/in for the next
+> >relases ?
+> 
+> Due to lack of time, I'm not in the jail-business right now, I'm sort
+> of hoping that Robert Watson is keeping an eye on the various patches
+> but I suspect he is too busy to actively steer the issue too.

Exactly. And my patches are in desynch with current source, because it
is hard to maintain them when they aren't intergrated...

+> Of course, I can't resist a pun when it presents itself so
+> directly, so:
+> 
+> 
+>  JAIL maintainer wanted.
+>  (apply within)
+> 
+> :-)

And here I am!:)

-- 
Pawel Jakub Dawidek   [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net


pgp0.pgp
Description: PGP signature

Re: HTT on single CPU?

[Terry Lambert]

Wilko Bulte wrote:
> On Wed, Jul 09, 2003 at 10:14:47AM -0500, Thomas T. Veldhouse wrote:
> 
> I can confirm my 2.4G P4 does have HTT:

This is unfortunately not definitive for CPUs other than your
own.  The "Intel Extends..." announcement that was quoted really
means two things:

o   Parts with those speeds fabricated before "Intel Extends..."
announcement *don't* support it.

o   Parts fabricated after the anouncement *may* support it, or
may require specific parts/steppings, out of the set of those
currently being fabricated, in order to support it.

So it's still necessary to look at the CPUID result and the probe
result messages out of dmesg for other people who think P4 == HTT
automatically, because your part may be from an older mask, and
even if there are no older masks currently in fabrication, it
could have sat in a cardboard box in a warehouse for a long time
before it fell into your hands.

To add to the confusion, the "slower" P4's they announce may have
been downclocked out of a large fabrication run that failed to pass
certification testing at the higher speed, and had their gates
lasered to "turn them into" lower speed parts; and the announcement
was just Intel's way of recovering part of their loss on the deal
(yeah, I know, I'm a cynic ;^)).

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SMP and setrunnable()- scheduler 4bsd

[Terry Lambert]

John Baldwin wrote:
> On 09-Jul-2003 Terry Lambert wrote:
> > I thought that there was either a SPARC or Alpha box where Poul
> > had to mess with the divider because they were delivered round
> > robin, instead?
> 
> No.  The only anomaly I know of is that on Alpha 2100's, the clock
> interrupt seems to be round robin rather than broadcast (it is broadcast
> on all other SMP Alpha's as far as we can tell.)  So far we aren't sure
> exactly how off it is so there isn't a correction in the tree.

The 2100 was exactly what I was thinking of when I posted that; I
had to check my mail archives to find the email about it.  Thanks!

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: OpenPAM dynamic module loading not working ?

[Dominic Marks]

On 10/07/2003 08:46, Dag-Erling Sm?rgrav wrote:
> Dominic Marks <[EMAIL PROTECTED]> writes:
> > Jul  7 22:10:40 bacon dovecot-auth: in openpam_load_module(): no pam_pgsql.so 
> > found 
> > Jul  7 22:10:40 bacon dovecot-auth: PAM: pam_start(example) failed: failed to load 
> > module
> 
> The module probably lacks dependency information.  I'll try to figure
> it out later today.

I rebuilt OpenPAM with debugging info and looked at what was happening.
It turned out that it was not able to resolve pam_get_pass from the
module and would then state (confusingly) that the module didnt exist
'no pam_pgsql.so found' is bogus. The port has patches which remove
these symbols and I managed to get it working (mostly) by putting those
functions back. Now I can successfully get past authentication with this
module but when I try and login to dovecot it passes down the PAM chain
into pam.d/other and seems to choke. I suppose this is because there is
no local user which matches the user/pass and pam_unix doesn't like
that. If I remove pam_unix from the chain then Dovecot (my test program)
crashes while trying to continue post-auth. If you'd like I can provide
lots of logged openpam debug info and do testing.

> DES
> -- 
> Dag-Erling Sm?rgrav - [EMAIL PROTECTED]
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Thanks,
-- 
Dominic
  
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

what is the suggested way to do void * arithmetic ?

[Luigi Rizzo]

Hi,
in several places in ipfw2.c i have to move pointers across
structures of variable length (lists of ipfw2 instructions
returned by the getsockopt()), and i use the following type of code:

void *next;
foo *p;

...

next = (void *)p + len;
...
foo = (foo *)p + len;

When using WARNS=5, the compiler in -current flags them with 'Warning
void * arithmetic'.

What is the best way to do the above given that i do need to use
these variable-size structures ?

cheers
luigi
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Panic linux ldconfig with MUTEX_PROFILING

[Jun Kuriyama]

At Thu, 10 Jul 2003 08:32:28 +0200,
Dag-Erling Smørgrav wrote:
> > I'm trying to use MUTEX_PROFILING, but paniced in linux ldconfig.
> > Any clues?
> 
> is COMPAT_LINUX compiled into the kernel?  You can't use modules with
> MUTEX_PROFILING; it changes the size and layout of struct mtx, and
> since modules aren't built with the same options as the kernel, they
> use the wrong struct mtx.

Ah, bingo!  I'm using linux.ko for Linux ABI.  I'll try with
COMPAT_LINUX.

But I used linux.ko which sync'ed with kernel itself (both were built
with same config).  Is MUTEX_PROFILING not passed to kernel module
building?


-- 
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
 <[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"