Re: libc error question answered (partly)

[Tim Robbins]

On Sat, Sep 21, 2002 at 08:21:15PM -0700, walt wrote:

> walt wrote:
> 
> > My guess is that the syntax of 'sort' has changed since lorder
> > was modified in March of 2001(?)
> 
> David Wolfskill just pointed out to me that the behavior of 'sort'
> is completely different in -STABLE, which I've just confirmed.
> 
> Does anyone else see this behavior in -CURRENT?  What happens
> if you type 'sort +1' on your -CURRENT machine?

The +POS1 -POS2 syntax for specifying sort keys was (from memory) marked
as obsolescent in IEEE Std. 1003.2-1992 and removed (and disallowed) in
1003.1-2001. Many applications (like lorder) use the old syntax, so by default
GNU sort does not conform to the 2001 standard and accepts the old syntax.
If you set _POSIX2_VERSION=200112 in the environment before running GNU sort,
it will try to conform to the newer standard and treat "+pos" as a filename
instead of a sort key. The version of sort in -stable was written before
the 2001 standard and doesn't disable the obsolescent sort key syntax.

So the only explanation that I can think of is that you've got _POSIX2_VERSION
set in the environment:
$ _POSIX2_VERSION=200112 sort +1
sort: open failed: +1: No such file or directory

lorder should probably get changed to use the new syntax some time too.


Tim

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

Re: disklabel doesnt let root to edit labels anymore? (some details)

[mika ruohotie]

On Sat, Sep 21, 2002 at 11:40:00PM -0700, Crist J. Clark wrote:
> On Sat, Sep 21, 2002 at 12:32:47PM +0300, mika ruohotie wrote:
> > eh?
> > it seems regardless of the flags i'm giving to disklabel it prevents
> > me from editing/restoring/whatever labels. only thing i can do is
> What error are you getting?

apoligies for not giving all the details.

what i'm trying to do is something i've done in the past years tens
of times when i've "cloned" one installed system to be several more
or less identical ones, ofcourse systems sharing one identical
component, the hard drive and its layout.

anyway, i'm not able to overwrite the current disklabel on a drive
using the -R flag anymore, system tells me "Operation not permitted".

if i add -n flag, i dont get errors.

nowadays it seems my only way is to use boot floppies (for some reason
my system's /stand/sysinstall cant see any disks) and it's really quite
annoying... one other thing i noticed which have changed was that i'm no
longer able to even edit a label, i ended up having a label:

[the upper part of the label snipped to make this email a bit shorter]

8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  b:  2621440  1048576  swap# (Cyl.   65*- 228*)
  c: 1201018770unused0 0# (Cyl.0 - 7475*)
  e:  104857604.2BSD 2048 1638489   # (Cyl.0 - 65*)
  f: 12582912  36700164.2BSD 2048 1638489   # (Cyl.  228*- 1011*)
  g:  1048576 162529284.2BSD 2048 1638489   # (Cyl. 1011*- 1076*)
  h: 102800373 173015044.2BSD 2048 1638489  # (Cyl. 1076*- 7475*)

which i tried to edit to look like:

8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  a:  104857604.2BSD 2048 1638489   # (Cyl.0 - 65*)
  b:  2621440  1048576  swap# (Cyl.   65*- 228*)
  c: 1201018770unused0 0# (Cyl.0 - 7475*)
  e: 12582912  36700164.2BSD 2048 1638489   # (Cyl.  228*- 1011*)
  f:  1048576 162529284.2BSD 2048 1638489   # (Cyl. 1011*- 1076*)
  g: 102800373 173015044.2BSD 2048 1638489  # (Cyl. 1076*- 7475*)

(something which i too have done _tens_ of times in the past, i even went
 and tried this on a separate machine, older current. worked like it always
 has.)

and the system just told me:

disklabel: Operation not permitted
re-edit the label? [y]: 

also, no matter what i try to edit on the label, including not changing
_anything_ on the label, i get that same error.

so something has changed, and i really wish it hadnt.

and yes, the situation remains the same if i boot single user.

> Crist J. Clark | [EMAIL PROTECTED]


mickey

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

[no subject]

[Koop Mast]

subscribe hackers



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

Re: Trouble Building CURRENT on STABLE, cpp seg. fault

[Maxim Konovalov]

Works for me:

>>> Kernel build for GENERIC completed on Sun Sep 22 07:43:35 MSD 2002

$ uname -a
FreeBSD golf.macomnet.net 4.6-20020805-MACOMNET-STABLE FreeBSD
4.6-20020805-MACOMNET-STABLE #19: Fri Sep 20 17:09:52 MSD 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GOLF  i386.

-- 
Maxim Konovalov, [EMAIL PROTECTED]




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

Re: libc error question answered (partly)

[walt]

Tim Robbins wrote:
> On Sat, Sep 21, 2002 at 08:21:15PM -0700, walt wrote:
> 
> 
>>walt wrote:
>>
>>
>>>My guess is that the syntax of 'sort' has changed since lorder
>>>was modified in March of 2001(?)
>>
>>David Wolfskill just pointed out to me that the behavior of 'sort'
>>is completely different in -STABLE, which I've just confirmed.

> So the only explanation that I can think of is that you've got _POSIX2_VERSION
> set in the environment:

Well, in /usr/include/unistd.h I have this:

/* Define the versions we target for compliance. */
#define _POSIX_VERSION  200112L
#define _POSIX2_VERSION 200112L

which I think may have been added on 9-21 by Garrett.  If that's what
made the difference then it looks like lorder and friends had better
be updated sooner than later ;-)


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

alpha tinderbox failure

[Dag-Erling Smorgrav]

--
>>> Rebuilding the temporary build tree
--
>>> 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/alpha/obj/h/des/src/alpha/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
>>> Kernel build for GENERIC started on Sun Sep 22 03:25:23 PDT 2002
--
>>> Kernel build for GENERIC completed on Sun Sep 22 03:51:47 PDT 2002
--
>>> Kernel build for LINT started on Sun Sep 22 03:51:48 PDT 2002
--
===> vinum
cc1: warnings being treated as errors
/h/des/src/sys/coda/coda_namecache.c: In function `coda_nc_enter':
/h/des/src/sys/coda/coda_namecache.c:245: warning: cast from pointer to integer of 
different size
/h/des/src/sys/coda/coda_namecache.c:263: warning: cast from pointer to integer of 
different size
/h/des/src/sys/coda/coda_namecache.c: In function `coda_nc_lookup':
/h/des/src/sys/coda/coda_namecache.c:322: warning: cast from pointer to integer of 
different size
/h/des/src/sys/coda/coda_namecache.c: In function `coda_nc_zapfile':
/h/des/src/sys/coda/coda_namecache.c:520: warning: cast from pointer to integer of 
different size
/h/des/src/sys/coda/coda_namecache.c: In function `coda_nc_purge_user':
/h/des/src/sys/coda/coda_namecache.c:568: warning: cast from pointer to integer of 
different size
*** Error code 1

Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

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

failure in make buildworld

[Christoph Kukulies]

I tried to build glade2 (IDE for gtk toolkit) under my 4.6R
system but the port build failed in building the esd (esound) server
or whatever this is. 

To make a long story short: I cvsuped and started "make buildworld"
which ran into an error:

===> lib/libbz2
rm -f .depend
mkdep -f .depend -a-I/usr/src/lib/libbz2/../../contrib/bzip2  
/usr/src/lib/libbz2/../../contrib/bzip2/bzlib.c 
/usr/src/lib/libbz2/../../contrib/bzip2/blocksort.c 
/usr/src/lib/libbz2/../../contrib/bzip2/compress.c 
/usr/src/lib/libbz2/../../contrib/bzip2/crctable.c 
/usr/src/lib/libbz2/../../contrib/bzip2/decompress.c 
/usr/src/lib/libbz2/../../contrib/bzip2/huffman.c 
/usr/src/lib/libbz2/../../contrib/bzip2/randtable.c
===> lib/libc
make: don't know how to make wcstoimax.c. Stop
*** Error code 2

Stop in /usr/src/lib.
*** Error code 1

Stop in /usr/src.


Any clues?

--
Chris Christoph P. U. Kukulies [EMAIL PROTECTED]

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

Re: Trouble Building CURRENT on STABLE, cpp seg. fault

[Giorgos Keramidas]

On 2002-09-21 23:53, "Crist J. Clark" <[EMAIL PROTECTED]> wrote:
> I've been unable to build CURRENT on STABLE for a few days. I made
> sure to bring STABLE up to date. Is this just me? Is there a problem
> with building CURRENT on STABLE at the moment?

It isn't just you.  The same error stopped my build of current 2-3
days ago on 4.6-RELEASE.

>  if [ -f .olddep ]; then mv .olddep .depend; fi
>  rm -f .newdep
>  make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES |  MKDEP_CPP="cc -E" 
>CC="cc" xargs mkdep -a -f .newdep -O -pipe -march=pentium3 -Wall -Wredundant-decls 
>-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
>-Wcast-qual  -fformat-extensions -ansi  -nostdinc -I-  -I. -I/usr/src.CURRENT/sys 
>-I/usr/src.CURRENT/sys/dev -I/usr/src.CURRENT/sys/contrib/dev/acpica 
>-I/usr/src.CURRENT/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common  
>-mpreferred-stack-boundary=2 -ffreestanding
>  cc: Internal error: Segmentation fault (program cpp0)
>  Please submit a full bug report.
>  See http://www.gnu.org/software/gcc/bugs.html> for instructions.
>  mkdep: compile failed
>  *** Error code 1

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

Re: Followup to XFree86-4-Server and lcms problems

[Vallo Kallaste]

On Wed, Sep 18, 2002 at 09:59:29PM +0300, Vallo Kallaste  wrote:

> In case someone is interested about consistent test case, here's
> additional info. Now I built both world and kernel with CPUTYPE=p2
> and kan's patch. I haven't changed anything except uncommenting the
> aforementioned CPUTYPE clause in make.conf. The package build run
> ends up with same failure on the same place as before. I'm going to
> update the system sources because of recent gcc import.. in hopes
> it'll fix the bug.

The failure below is triggered consistently by setting CPUTYPE to
any of p[234] in /etc/make.conf. /usr/share/mk/bsd.cpu.mk defines
_CPUCFLAGS = -mcpu=pentiumpro and CPUTYPE = i386 in case
MACHINE_ARCH=i386 and CPUTYPE is unset. Setting CPUTYPE=p[234] will
cause precise setting of -march as seen below, in this case
-march=pentium2 and this is the bugger. CPUTYPE=i686 in make.conf
will cause -march=pentiumpro and this works. It's probably worth to
mention in some kind of document that precise setting of CPUTYPE to
p[234] can cause all sorts of weirdness and the more broad
definition CPUTYPE=i686 is more likely to work.

> rm -f miPck1Prim.o
> 
>LD_LIBRARY_PATH=/usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/exports/lib
> cc -O -pipe -march=pentium2 -march=pentium2  -ansi -pedantic -Dasm=__asm -Wall 
>-Wpointer-arith   -fno-merge-constants -I. -I../include
>-I/usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/exports/include/X11
>   -I../../../include  
>-I/usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver/include
>  -I/usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc 
>-I/usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/exports/include
>  -I/usr/X11R6/include -DCSRG_BASED -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP 
>-DXCSECURITY -DTOGCUP  -DXF86BIGFONT -DDPMSExtension   -DPANORAMIX  -DRENDER  
>-DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension 
>-DXFree86LOADER  -DXFree86Server -DXF86VIDMODE -DXvMCExtension  -DSMART_SCHEDULE 
>-DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG  -DFUNCPROTO=15 -DNARROWPROTO  
>-DIN_MODULE -DXFree86Module-c miPck1Prim.c
> miPck1Prim.c: In function `CheckFAreaPick1':
> miPck1Prim.c:337: unable to find a register to spill in class `FLOAT_REGS'
> miPck1Prim.c:337: this is the insn:
> (insn 275 273 277 (set (subreg:SF (reg/v:DI 29 rmm0 [64]) 0)
> (float:SF (mem/s/j:HI (reg/v/f:SI 2 ecx [61]) [0 .x+0 S2 A16]))) 
>167 {floathisf2} (insn_list 271 (nil))
> (nil))
> miPck1Prim.c:337: confused by earlier errors, bailing out
> *** Error code 1
> 
> Stop in 
>/usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver/PEX5/ddpex/mi/level1.
> *** Error code 1
> 
> Stop in 
>/usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver/PEX5.
> *** Error code 1
> 
> Stop in 
>/usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver.
> *** Error code 1 (ignored)
> *** Error code 1
> 
> Stop in /usr/ports/x11-servers/XFree86-4-Server.
> *** Error code 1
> 
> Stop in /usr/ports/x11/wrapper.
> *** Error code 1
> 
> Stop in /usr/ports/x11/XFree86-4.
-- 

Vallo Kallaste
[EMAIL PROTECTED]

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

World broken in ncurses ?!

[Marc Recht]

With -current sources as of today:

cc -O -pipe -march=athlon-xp -I. -I/usr/src/lib/libncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS  -c lib_keyname.c -o lib_keyname.o

lib_keyname.c:7: `KEY_A1' undeclared here (not in a function)
lib_keyname.c:7: initializer element is not constant
lib_keyname.c:7: (near initialization for `_nc_key_names[0].code')
lib_keyname.c:7: initializer element is not constant
lib_keyname.c:7: (near initialization for `_nc_key_names[0]')
lib_keyname.c:8: `KEY_A3' undeclared here (not in a function)
lib_keyname.c:8: initializer element is not constant
lib_keyname.c:8: (near initialization for `_nc_key_names[1].code')
lib_keyname.c:8: initializer element is not constant
lib_keyname.c:8: (near initialization for `_nc_key_names[1]')
lib_keyname.c:9: `KEY_B2' undeclared here (not in a function)
[...] And so on for every key..
lib_keyname.c:160: (near initialization for `_nc_key_names[153].code')
lib_keyname.c:160: initializer element is not constant
lib_keyname.c:160: (near initialization for `_nc_key_names[153]')
lib_keyname.c:161: initializer element is not constant
lib_keyname.c:161: (near initialization for `_nc_key_names[154]')
*** Error code 1

Marc



msg43179/pgp0.pgp
Description: PGP signature

Re: Trouble Building CURRENT on STABLE, cpp seg. fault

[qhwt]

On Sun, Sep 22, 2002 at 02:44:54PM +0300, Giorgos Keramidas wrote:
> On 2002-09-21 23:53, "Crist J. Clark" <[EMAIL PROTECTED]> wrote:
> > I've been unable to build CURRENT on STABLE for a few days. I made
> > sure to bring STABLE up to date. Is this just me? Is there a problem
> > with building CURRENT on STABLE at the moment?
> 
> It isn't just you.  The same error stopped my build of current 2-3
> days ago on 4.6-RELEASE.
> 
> >  if [ -f .olddep ]; then mv .olddep .depend; fi
> >  rm -f .newdep
> >  make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES |  MKDEP_CPP="cc 
>-E" CC="cc" xargs mkdep -a -f .newdep -O -pipe -march=pentium3 -Wall 
>-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
>-Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi  -nostdinc -I-  -I. 
>-I/usr/src.CURRENT/sys -I/usr/src.CURRENT/sys/dev 
>-I/usr/src.CURRENT/sys/contrib/dev/acpica -I/usr/src.CURRENT/sys/contrib/ipfilter 
>-D_KERNEL -include opt_global.h -fno-common  -mpreferred-stack-boundary=2 
>-ffreestanding
> >  cc: Internal error: Segmentation fault (program cpp0)
> >  Please submit a full bug report.
> >  See http://www.gnu.org/software/gcc/bugs.html> for instructions.
> >  mkdep: compile failed
> >  *** Error code 1

Try 'make depend && make' using cpp0 built from -CURRENT source
newer than the first import of gcc 3.2.1 prerelease:

$ pushd /usr/src/gnu/usr.bin/cc
$ make obj && make depend && make
$ popd
$ GCC_EXEC_PREFIX=/usr/obj/usr/src/usr.bin/cc/cpp0/ make depend
$ GCC_EXEC_PREFIX=/usr/obj/usr/src/usr.bin/cc/cpp0/ make

should work unless you are doing a cross-platform compiling.
The bug in cpp0 seems to me to have been fixed after the first
import of gcc 3.2.1-prerelease (2002-09-02(UTC)).

Cheers.

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

Re: cvs commit: src/sys/pci if_dc.c

[Stephen McKay]

On Friday, 20th September 2002, Martin Blapp wrote:

>I think we would have to test all cases with all cards. What cards
>do you have Stephen, with which clone Chipsets ? Can you make a list
>of them ?

I've only got DE500 (genuine Intel 21143) and Macronix 98715AEC cards.
Nothing PCMCIA or CardBus.  Not a very big selection, I know.  A lot
of us will have to band together to test changes.

>I've got somewhere another dc card which made problems. I guess
>it was PNIC.

PNIC is still a problem with the -current driver.

Stephen.

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

/usr/include/sys/select.h:61: syntax error before "fd_set"

[Josef Karthauser]

I'm trying to work out why the latest version of coldsync won't compile
on -current, even though it compiles on -stable.

I'm getting the compile time error:

/usr/include/sys/select.h:61: syntax error before "fd_set"

The coldsync header file looks like:

#include "config.h"
#include 
#include 
#include 

#if  HAVE_SYS_SELECT_H
#  include/* To make select() work rationally under AIX 
*/
#endif  /* HAVE_SYS_SELECT_H */

#if HAVE_STRINGS_H
#  include   /* For bzero() under AIX */
#endif  /* HAVE_STRINGS_H */

#if HAVE_LIBINTL_H
#  include   /* For i18n */
#endif  /* HAVE_LIBINTL_H */

What header am I missing here?

Joe
-- 
"As far as the laws of mathematics refer to reality, they are not certain;
and as far as they are certain, they do not refer to reality." - Albert
Einstein, 1921



msg43182/pgp0.pgp
Description: PGP signature

signal 12 - lotsa

[Christoph Kukulies]

In a 4.6 environment I'm trying to upgrade to -current but
make installworld as well as kernelbuild fails with signal 12 lots of.

Seems that new system calls and a mix of old kernel and
new binaries is now fighting against another on my system.

How can I get out of this situation? Boot from a floppy ?

--
Chris Christoph P. U. Kukulies [EMAIL PROTECTED]

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

Re: cvs commit: src/sys/pci if_dc.c

[Martin Blapp]

Hi,

I just got a report from a user which has several dc cards with all
the broken mac adresses.

dc0@pci0:13:0:  class=0x02 card=0x05741317 chip=0x09851317 rev=0x11
hdr=0x00
vendor   = 'Admtek Inc'
device   = 'ADM983 fast ethernet controller'
class= network
subclass = ethernet

We have a ADM983 here too. I'll send him now a patch for
this, let's see.

Martin


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

Re: cvs commit: src/sys/pci if_dc.c

[Stephen McKay]

On Friday, 20th September 2002, Martin Blapp wrote:

>mbr 2002/09/20 08:18:13 PDT
>
>  Modified files:
>sys/pci  if_dc.c 
>  Log:
>  Fix the support for the AN985/983 chips, which do not set the
>  RXSTATE to STOPPED, but to WAIT. This should fix hangs which
>  could only be solved by replugging the cable.

John's already mentioned we are still thinking about the right way to
handle this but...

>  MFC after:  2 weeks

... I thought I should explicitly mention that merging this particular
change as it stands is a bad idea because PNIC and Davicom cards (at least)
are not yet correctly handled.  The code in -stable is the old broken but
apparently harmless code.  This new code is attempting to be more correct
but breaks support for some cards.  Odd situation, no?

Stephen.

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

Re: /usr/include/sys/select.h:61: syntax error before "fd_set"

[Giorgos Keramidas]

On 2002-09-22 14:33, Josef Karthauser <[EMAIL PROTECTED]> wrote:
> I'm trying to work out why the latest version of coldsync won't compile
> on -current, even though it compiles on -stable.
>
> I'm getting the compile time error:
>
> /usr/include/sys/select.h:61: syntax error before "fd_set"
>
> The coldsync header file looks like:
>
> #include "config.h"
> #include 
> #include 
> #include 
>
> #if  HAVE_SYS_SELECT_H
> #  include  /* To make select() work rationally under AIX 
>*/
> #endif/* HAVE_SYS_SELECT_H */

The select() manpage mentions the following headers, in the order
shown below:

 #include 
 #include 
 #include 

You have only included the last one.

Giorgos.

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

Re: /usr/include/sys/select.h:61: syntax error before "fd_set"

[Marc Recht]

> I'm trying to work out why the latest version of coldsync won't compile
> on -current, even though it compiles on -stable.
> 
> I'm getting the compile time error:
> 
> /usr/include/sys/select.h:61: syntax error before "fd_set"
> 
> The coldsync header file looks like:
> 
> What header am I missing here?
sys/types.h (before sys/select.h)

Marc





msg43187/pgp0.pgp
Description: PGP signature

Cant see ACPI thermal zones on a Supermicro P6DBU

[David P. Reese Jr.]

Does anyone know a reason why i should not see any info about the thermal
zones on a Supermicro P6DBU in sysctl?  I'm not even seeing the acpi_tz's
in dmesg.  As far as i know, the board does have thermal sensors.  I can
check the cpu temperatures in bios.  If it would help, i could also provide
the output of acpidump.

dmesg:
FreeBSD 5.0-CURRENT-20020917-JPSNAP #0: Sat Sep 21 22:08:13 PDT 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/METROPOLIS
Preloaded elf kernel "/boot/kernel/kernel" at 0xc04a3000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04a30a8.
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x652  Stepping = 2
  
Features=0x183fbff
real memory  = 201195520 (196480K bytes)
avail memory = 190021632 (185568K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
IOAPIC #0 intpin 16 -> irq 11
IOAPIC #0 intpin 18 -> irq 5
IOAPIC #0 intpin 19 -> irq 10
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
Pentium Pro MTRR support enabled
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
acpi0: power button is handled as a fixed feature programming model.
Timecounter "ACPI-safe"  frequency 3579545 Hz
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
acpi_cpu0:  on acpi0
acpi_cpu1:  on acpi0
pcib1:  port 0xcf8-0xcff on acpi0
pci0:  on pcib1
agp0:  mem 0xf800-0xfbff at device 
0.0 on pci0
pcib2:  at device 1.0 on pci0
pci1:  on pcib2
pci1:  at device 0.0 (no driver attached)
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xffa0-0xffaf at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0:  port 0xef80-0xef9f irq 10 at device 
7.2 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
Timecounter "PIIX"  frequency 3579545 Hz
pci0:  at device 7.3 (no driver attached)
ahc_pci0:  port 0xe800-0xe8ff mem 
0xfebff000-0xfebf irq 11 at device 14.0 on pci0
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec00-0xec7f mem 0xfebfef80-0xfebfefff 
irq 5 at device 18.0 on pci0
xl0: Ethernet address: 00:50:da:05:a6:62
miibus0:  on xl0
xlphy0: <3c905C 10/100 internal PHY> on miibus0
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
acpi_button0:  on acpi0
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0:  irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
fdc0: cmd 3 failed at out byte 1 of 3
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
plip0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
fdc0: cmd 3 failed at out byte 1 of 3
orm0:  at iomem 0xc8800-0xc8fff,0xc8000-0xc87ff,0xc-0xc7fff on isa0
fdc0:  at port 
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
pmtimer0 on isa0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounters tick every 10.000 msec
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5%
ad0: 9787MB  [19885/16/63] at ata0-master UDMA33
acd0: CDROM  at ata1-master PIO4
Waiting 2 seconds for SCSI devices to settle
SMP: AP CPU #1 Launched!

-- 

   David P. Reese Jr.  [EMAIL PROTECTED]
   --
   C 
  You shoot yourself in the foot. 
   Assembler
  You try to shoot yourself in the foot, only to discover you must first
  invent the gun, the bullet, the trigger, and your foot. 

How to Shoot Yourself in the Foot


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

Re: -mcpu=pentiumpro still evil?

[Alexander Kabaev]

On Sat, 21 Sep 2002 23:10:51 -0500 (CDT)
Mike Silbersack <[EMAIL PROTECTED]> wrote:

> 
> Is anyone else still seeing Sig 11's from GCC when mcpu=pentiumpro is
> enabled (as it appears to be by default now)?  I get a segfault in the
> same place every time when compiling a DIAGNOSTIC kernel when I leave
> it enabled.
> 
> Just curious if this is just me or not...
> 
> Mike "Silby" Silbersack
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 
Please post an error message and a traceback from GCC if possible. I
might have the patch for that.

-- 
Alexander Kabaev


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

Re: cvs commit: src/sys/pci if_dc.c

[Martin Blapp]

Hi,

> ... I thought I should explicitly mention that merging this particular
> change as it stands is a bad idea because PNIC and Davicom cards (at least)
> are not yet correctly handled.  The code in -stable is the old broken but
> apparently harmless code.  This new code is attempting to be more correct
> but breaks support for some cards.  Odd situation, no?

What chips do have these card ? We can just do this check for the admtek
cards, can we ?

Have we now different cards with the same chips but different behaviour ???

I know that a

981
983
983b
985

admtek chip exist.

Martin


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

buildworld fails in gnu/usr.bin/gperf/doc with an internal error

[Alexander Leidinger]

Hi,

I try to update -current form Aug 26 to -current from today:
---snip---
===> gnu/usr.bin/gperf/doc
c++  -O -pipe-D__FBSDID=__RCSID -I/big/usr/src/gnu/usr.bin/gperf/../../../co
ntrib/gperf/lib -I/big/usr/src/gnu/usr.bin/gperf -c /big/usr/src/contrib/gperf/s
rc/bool-array.cc
c++  -O -pipe-D__FBSDID=__RCSID -I/big/usr/src/gnu/usr.bin/gperf/../../../co
ntrib/gperf/lib -I/big/usr/src/gnu/usr.bin/gperf -c /big/usr/src/contrib/gperf/s
rc/gen-perf.cc
/big/usr/src/contrib/gperf/src/gen-perf.cc:213: internal error: Segmentation 
   fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
*** Error code 1
---snip---

Any idea how to solve this?

Bye,
Alexander.

-- 
   Intel: where Quality is job number 0.9998782345!

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

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

Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error

[Alexander Kabaev]

On Sun, 22 Sep 2002 17:20:14 +0200
Alexander Leidinger <[EMAIL PROTECTED]> wrote:

Alexander, can you get me a backtrace from the failed GCC process? What
process it is, by the way? GCC, CC1, CPP1?

-- 
Alexander Kabaev


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

Fixing ports/palm/coldsync.

[Josef Karthauser]

Has anyone here got the time to help me out?  I want to fix the uvisor
code so that it works properly, but am getting caught up trying to fix
the coldsync port.  It compiles on -stable, but has been broken on
-current for a while.  Something changed in the fd_set area and it's not
compiled for a long time.  I'd really appreciate it is someone with a
knowledge of select foo could help me work out what's wrong.  Did we
tighten something up in -current, or have we deprecated something?

Thanks,
Joe
-- 
"As far as the laws of mathematics refer to reality, they are not certain;
and as far as they are certain, they do not refer to reality." - Albert
Einstein, 1921



msg43193/pgp0.pgp
Description: PGP signature

Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error

[Alexander Leidinger]

On Sun, 22 Sep 2002 11:27:08 -0400 Alexander Kabaev
<[EMAIL PROTECTED]> wrote:

> Alexander, can you get me a backtrace from the failed GCC process?
> What process it is, by the way? GCC, CC1, CPP1?

This is with a gcc 3.1 world, the internal error is in "stage 1:
bootstrap tools" and gcc 3.2 isn't build at this point. Do you still
want the backtrace?

If yes: I can't find a *.core in /usr/{src,obj}, there's no coredump
limit, so how do I get the backtrace? I already tried to go into
gnu/usr.bin/gperf and make a "make cleandir; make cleandir; make", but I
don't get a coredump.

I also tried to run it withhin gdb, but c++ exists with something like
exit(1) and thats it, no way to make a backtrace.

Bye,
Alexander.

-- 
   Reboot America.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

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

netns

[Erik Greenwald]

Does anyone use src/sys/netns (xerox networking)? it's currently
uncompilable, seems to have been so for a while, and sys/conf/NOTES says
it's provided for "amusement" value, and are only shipped due to
interest. I wouldn't mind seeing it go away in -current and if someone
wants it, they can cvs an older version or something...

-- 
-Erik <[EMAIL PROTECTED]> [http://math.smsu.edu/~erik]

The opinions expressed by me are not necessarily opinions. In all probability,
they are random rambling, and to be ignored. Failure to ignore may result in
severe boredom or confusion. Shake well before opening. Keep Refrigerated.

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

Re: netns

[Poul-Henning Kamp]

In message <20020922163034.GA29873@freya>, Erik Greenwald writes:
>
>Does anyone use src/sys/netns (xerox networking)? it's currently
>uncompilable, seems to have been so for a while, and sys/conf/NOTES says
>it's provided for "amusement" value, and are only shipped due to
>interest. I wouldn't mind seeing it go away in -current and if someone
>wants it, they can cvs an older version or something...

I think we can safely axe it.

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

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

Re: netns

[Eric Brunner-Williams in Portland Maine]

Keith Sklower did that work. PORTS?


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

Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error

[Alexander Kabaev]

> This is with a gcc 3.1 world, the internal error is in "stage 1:
> bootstrap tools" and gcc 3.2 isn't build at this point. Do you still
> want the backtrace?

Yes.

> 
> If yes: I can't find a *.core in /usr/{src,obj}, there's no coredump
> limit, so how do I get the backtrace? I already tried to go into
> gnu/usr.bin/gperf and make a "make cleandir; make cleandir; make", but
> I don't get a coredump.
> 
> I also tried to run it withhin gdb, but c++ exists with something like
> exit(1) and thats it, no way to make a backtrace.

What does kernel log say? When process dies with signal, kernel usually
logs the event. If anything, this should give you the name of the
process which has died. Running 'gcc' or 'c++' under debugger is not
very helpful, because these are just driver programs. The real processes
which do the work are cpp1, cc1, ccp1 etc.

-- 
Alexander Kabaev


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

Re: netns

[Julian Elischer]

I believe there are people whi use it in -stabel for netware
connectivity.
I think that not having it would be a killer for them when they try move
up to 5.x.

On Sun, 22 Sep 2002, Erik Greenwald wrote:

> 
> Does anyone use src/sys/netns (xerox networking)? it's currently
> uncompilable, seems to have been so for a while, and sys/conf/NOTES says
> it's provided for "amusement" value, and are only shipped due to
> interest. I wouldn't mind seeing it go away in -current and if someone
> wants it, they can cvs an older version or something...
> 
> -- 
> -Erik <[EMAIL PROTECTED]> [http://math.smsu.edu/~erik]
> 
> The opinions expressed by me are not necessarily opinions. In all probability,
> they are random rambling, and to be ignored. Failure to ignore may result in
> severe boredom or confusion. Shake well before opening. Keep Refrigerated.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


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

Re: netns

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Ju
lian Elischer writes:
>
>I believe there are people whi use it in -stabel for netware
>connectivity.
>I think that not having it would be a killer for them when they try move
>up to 5.x.

Well, they'd better get somebody to fix it then because if it doesn't
at least show a credible display of functionality when 5.0-R rolls
around I'll lobby hard for axing it.

If you know there are people using it, tell them this is the time
to fix it if they want it to be in 5.0

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

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

expensive timeouts?

[Koop Mast]

hi
 
does somebody know what this is?
those timeouts show up at boot after the harddisk is detected and when
enter or page-up and page-down in combo with scroll-lock is pressed.
the box works fine

 uname -a
FreeBSD  5.0-CURRENT FreeBSD 5.0-CURRENT #1: Sun Sep 22 19:22:37
CEST 2002 :/usr/obj/usr/src/sys/RAINBOW  i386

dmesg below

Koop

Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #1: Sun Sep 22 19:22:37 CEST 2002
:/usr/obj/usr/src/sys/RAINBOW
Preloaded elf kernel "/boot/kernel/kernel" at 0xc040e000.
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 199961423 Hz
CPU: Pentium/P55C (199.96-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x543  Stepping = 3
  Features=0x8001bf
real memory  = 134217728 (131072K bytes)
avail memory = 125923328 (122972K bytes)
Intel Pentium detected, installing workaround for F00F bug
Using $PIR table, 5 entries at 0xc00fdba0
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  at pcibus 0 on motherboard
pci0:  on pcib0
isab0:  at device 2.0 on pci0
isa0:  on isab0
rl0:  port 0x6400-0x64ff mem
0xe000-0xe0ff irq 11 at device 5.0 on pci0
rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect
mode
/usr/src/sys/vm/uma_core.c:1307: could sleep with "rl0" locked from
/usr/src/sys/pci/if_rl.c:872
/usr/src/sys/vm/uma_core.c:1307: could sleep with "rl0" locked from
/usr/src/sys/pci/if_rl.c:872
lock order reversal
 1st 0xc13b01c0 rl0 (network driver) @ /usr/src/sys/pci/if_rl.c:872
 2nd 0xc031e000 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:317
/usr/src/sys/vm/uma_core.c:1307: could sleep with "rl0" locked from
/usr/src/sys/pci/if_rl.c:872
/usr/src/sys/vm/uma_core.c:1307: could sleep with "rl0" locked from
/usr/src/sys/pci/if_rl.c:872
/usr/src/sys/vm/uma_core.c:1307: could sleep with "rl0" locked from
/usr/src/sys/pci/if_rl.c:872
rl0: Ethernet address: 00:10:a7:05:72:83
miibus0:  on rl0
rlphy0:  on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
/usr/src/sys/vm/uma_core.c:1307: could sleep with "rl0" locked from
/usr/src/sys/pci/if_rl.c:597
atapci0:  port 0xf000-0xf00f at
device 11.0 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
orm0:  at iomem 0xc-0xc7fff on isa0
atkbdc0:  at port 0x64,0x60 on isa0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
fdc0:  at port
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
pmtimer0 on isa0
ppc0:  at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
vpo0:  on ppbus0
vpo0: EPP mode
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on
isa0
ep0: <3Com 3C509B-TPO EtherLink III (PnP)> at port 0x210-0x21f irq 5 on
isa0
ep0: Ethernet address 00:50:da:07:1e:c6
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
Timecounters tick every 10.000 msec
ipfw2 initialized, divert enabled, rule-based forwarding enabled,
default to accept, logging unlimited
ad0: 19473MB  [39566/16/63] at ata0-master UDMA33
Expensive timeout(9) function: 0xc012da10(0xc0bb0800) 0.008746732
da0 at vpo0 bus 0 target 6 lun 0
da0:  Removable Direct Access SCSI-2 device 
da0: 96MB (196608 512 byte sectors: 64H 32S/T 96C)
Mounting root from ufs:/dev/ad0s1a
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001957617
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001979471
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001962473
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001957687
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001956082
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001977791
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001973180
Expensive timeout(9) function: 0xc028fa30(0) 0.006071210
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001957357
[and so on]



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

Re: netns

[Julian Elischer]

On Sun, 22 Sep 2002, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, Ju
> lian Elischer writes:
> >
> >I believe there are people whi use it in -stabel for netware
> >connectivity.
> >I think that not having it would be a killer for them when they try move
> >up to 5.x.
> 
> Well, they'd better get somebody to fix it then because if it doesn't
> at least show a credible display of functionality when 5.0-R rolls
> around I'll lobby hard for axing it.


I'll try find some.. 

> 
> If you know there are people using it, tell them this is the time
> to fix it if they want it to be in 5.0
> 
> -- 
> 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.
> 


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

current.freebsd.org points to japanese site?

[Kenneth Culver]

Why does current.freebsd.org point to the japanese snapshot site
snapshots.jp.freebsd.org? I'm just wondering because I am trying to
install -CURRENT on one of my machines.

Ken


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

Re: current.freebsd.org points to japanese site?

[Will Andrews]

On Sun, Sep 22, 2002 at 03:33:24PM -0400, Kenneth Culver wrote:
> Why does current.freebsd.org point to the japanese snapshot site
> snapshots.jp.freebsd.org? I'm just wondering because I am trying to
> install -CURRENT on one of my machines.

Because it's the only reliable current snapshot building site?

regards,
-- 
wca

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

Re: current.freebsd.org points to japanese site?

[Kenneth Culver]

Is there any difference between the snapshots built on the japanese site
and the ones that were built on the US one? Thanks

Ken

On Sun, 22 Sep 2002, Will Andrews wrote:

> On Sun, Sep 22, 2002 at 03:33:24PM -0400, Kenneth Culver wrote:
> > Why does current.freebsd.org point to the japanese snapshot site
> > snapshots.jp.freebsd.org? I'm just wondering because I am trying to
> > install -CURRENT on one of my machines.
>
> Because it's the only reliable current snapshot building site?
>
> regards,
> --
> wca
>


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

Who broke sort(1) ?

[Poul-Henning Kamp]

flat# date | sort +5n
sort: open failed: +5n: No such file or directory

This breaks the build in libncurses...

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

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

Re: Fixing ports/palm/coldsync.

[Josef Karthauser]

On Sun, Sep 22, 2002 at 04:42:32PM +0100, Josef Karthauser wrote:
> Has anyone here got the time to help me out?  I want to fix the uvisor
> code so that it works properly, but am getting caught up trying to fix
> the coldsync port.  It compiles on -stable, but has been broken on
> -current for a while.  Something changed in the fd_set area and it's not
> compiled for a long time.  I'd really appreciate it is someone with a
> knowledge of select foo could help me work out what's wrong.  Did we
> tighten something up in -current, or have we deprecated something?

Mark Trettin <[EMAIL PROTECTED]> sent me a patch (attached for reference).

Thanks Mark,
Joe
-- 
"As far as the laws of mathematics refer to reality, they are not certain;
and as far as they are certain, they do not refer to reality." - Albert
Einstein, 1921


--- config.h.in.origSun Sep 22 13:41:09 2002
+++ config.h.in Sun Sep 22 13:42:40 2002
@@ -316,19 +316,6 @@
 */
 #endif /* HAVE_O_BINARY */
 
-#ifndef _POSIX_C_SOURCE
-#  define _POSIX_C_SOURCE  2
-#endif /* _POSIX_C_SOURCE */
-
-#ifndef __EXTENSIONS__
-#  define __EXTENSIONS__   1
-#endif
-
-#ifndef _XOPEN_SOURCE_EXTENDED
-   /* Provides declaration for lstat() under DU, and strdup() under Linux */
-#  define _XOPEN_SOURCE_EXTENDED
-#endif /* _XOPEN_SOURCE_EXTENDED */
-
 #if __GNUC__
 
/* The following should fix gcc complaining about missing



msg43207/pgp0.pgp
Description: PGP signature

Re: netns

[John Hay]

Why don't they use the netipx code? Surely netware use ipx.

> 
> I believe there are people whi use it in -stabel for netware
> connectivity.
> I think that not having it would be a killer for them when they try move
> up to 5.x.
> 
> On Sun, 22 Sep 2002, Erik Greenwald wrote:
> 
> > 
> > Does anyone use src/sys/netns (xerox networking)? it's currently
> > uncompilable, seems to have been so for a while, and sys/conf/NOTES says
> > it's provided for "amusement" value, and are only shipped due to
> > interest. I wouldn't mind seeing it go away in -current and if someone
> > wants it, they can cvs an older version or something...
> > 

John
-- 
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]

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

Re: Who broke sort(1) ?

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes:
>
>flat# date | sort +5n
>sort: open failed: +5n: No such file or directory
>
>This breaks the build in libncurses...

Ok, nailed it down.

this commit, is the culprit.  I guess it changes the fts ABI in
some subtle way because backing the change to src/include/fts.h
out makes sort(1) work again.

I'll try if adding sort(1) to as a bootstrap-tool for buildworld
solves this...

Poul-Henning


wollman 2002/09/20 18:28:41 PDT

  Modified files:
bin/cp   cp.c 
bin/ls   ls.c 
include  fts.h 
lib/libc/gen fts.3 fts.c 
usr.bin/find find.c 
usr.sbin/ctm/ctm_dequeue ctm_dequeue.c 
usr.sbin/mtree   create.c 
usr.sbin/pkg_install/lib match.c 
  Log:
  Make the threatened fts(3) ABI fix.  FTSENT now avoids the use of the struct
  hack, thereby allowing future extensions to the structure (e.g., for extended
  attributes) without rebreaking the ABI.  FTSENT now contains a pointer to the
  parent stream, which fts_compar() can then take advantage of, avoiding the
  undefined behavior previously warned about.  As a consequence of this change,
  the prototype of the comparison function passed to fts_open() has changed
  to reflect the required amount of constness for its use.  All callers in the
  tree are updated to use the correct prototype.
  
  Comparison functions can now make use of the new parent pointer to access
  the new stream-specific private data pointer, which is intended to assist
  creation of reentrant library routines which use fts(3) internally.
  
  Not objected to in spirit by: -arch
  
  Revision  ChangesPath
  1.41  +2 -2  src/bin/cp/cp.c
  1.66  +2 -2  src/bin/ls/ls.c
  1.7   +10 -3 src/include/fts.h
  1.14  +41 -6 src/lib/libc/gen/fts.3
  1.21  +68 -14src/lib/libc/gen/fts.c
  1.15  +2 -2  src/usr.bin/find/find.c
  1.11  +3 -3  src/usr.sbin/ctm/ctm_dequeue/ctm_dequeue.c
  1.27  +2 -2  src/usr.sbin/mtree/create.c
  1.13  +2 -2  src/usr.sbin/pkg_install/lib/match.c


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

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

Re: Who broke sort(1) ?

[Steve Kargl]

On Sun, Sep 22, 2002 at 10:17:41PM +0200, Poul-Henning Kamp wrote:
> 
> flat# date | sort +5n
> sort: open failed: +5n: No such file or directory
> 
> This breaks the build in libncurses...
> 

POSIX via wollman.

See revision 1.58 of /usr/include/unistd.h, i.e.,

/* Define the versions we target for compliance. */
#define _POSIX_VERSION  200112L
#define _POSIX2_VERSION 200112L


See email in the last 24 hours from walt about 
problems building libc and Tim Robbins response
to the problem.

-- 
Steve

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

Re: netns

[Terry Lambert]

John Hay wrote:
> Why don't they use the netipx code? Surely netware use ipx.

IPX is based on XNS.  It differs by one significant field.  The
SAP (Service Advertisement Protocol) in IPX comed directly from
XNS.

FWIW.

-- Terry

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

Re: netns

[John Hay]

> John Hay wrote:
> > Why don't they use the netipx code? Surely netware use ipx.
> 
> IPX is based on XNS.  It differs by one significant field.  The
> SAP (Service Advertisement Protocol) in IPX comed directly from
> XNS.

So you are agreeing with me that to use netns to do ipx when we
have netipx does not make sense? :-)

> FWIW.

I know, a lot of my time went into netipx, which was derived from
netns. I also did IPXrouted which does SAP too.

John
-- 
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]

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

Re: current.freebsd.org points to japanese site?

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Kenneth Culver <[EMAIL PROTECTED]> writes:
: Is there any difference between the snapshots built on the japanese site
: and the ones that were built on the US one? Thanks

Not really.  No differences that are important. (eg, different machine
names, snapjp vs snap, and other such things).

Warner

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

Re: cvs commit: src/sys/pci if_dc.c

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Martin Blapp <[EMAIL PROTECTED]> writes:
: 
: Hi,
: 
: > ... I thought I should explicitly mention that merging this particular
: > change as it stands is a bad idea because PNIC and Davicom cards (at least)
: > are not yet correctly handled.  The code in -stable is the old broken but
: > apparently harmless code.  This new code is attempting to be more correct
: > but breaks support for some cards.  Odd situation, no?
: 
: What chips do have these card ? We can just do this check for the admtek
: cards, can we ?
: 
: Have we now different cards with the same chips but different behaviour ???
: 
: I know that a
: 
: 981
: 983
: 983b
: 985
: 
: admtek chip exist.

I have a similar problem with the Abocom FE2500 chip that's in one of
my cardbus cards.  Or maybe I'm confusing the two recent commits...

Warner

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

Re: cvs commit: src/sys/pci if_dc.c

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Stephen McKay <[EMAIL PROTECTED]> writes:
: On Friday, 20th September 2002, Martin Blapp wrote:
: 
: >I think we would have to test all cases with all cards. What cards
: >do you have Stephen, with which clone Chipsets ? Can you make a list
: >of them ?
: 
: I've only got DE500 (genuine Intel 21143) and Macronix 98715AEC cards.
: Nothing PCMCIA or CardBus.  Not a very big selection, I know.  A lot
: of us will have to band together to test changes.
: 
: >I've got somewhere another dc card which made problems. I guess
: >it was PNIC.
: 
: PNIC is still a problem with the -current driver.

I have a PNIC card that I can send to Martin if that would help.  I
got 10 of the goofy things a few years ago for $10 total because they
had funky brackets on them.  Take the bracket off and they work great
in pci slots.

Warner

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

Re: cvs commit: src/sys/pci if_dc.c

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Martin Blapp <[EMAIL PROTECTED]> writes:
: 
: Hi Mark,
: 
: > I have a Netgear FA510 (32-bit CardBus).
: >
: > cardbus0: Expecting link target, got 0x0
: > cardbus0: Resource not specified in CIS: id=10, size=80
: > cardbus0: Resource not specified in CIS: id=14, size=400
: > dc0:  port 0x1000-0x107f mem 0x88002400-0x880027ff irq
: >  11 at device 0.0 on cardbus0
: > dc0: Ethernet address: 00:80:00:80:00:80
: > miibus0:  on dc0
: > dcphy0:  on miibus0
: > dcphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
: 
: Can you try this PR patch and see if it helps ? Note that the patch isn't
: 100% correct for other cards and will break them.
: 
: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/35482

OpenBSD gets these cards right.  I've not ported their code to our
system at this time.  I know that the problem is due to our not
reading the SEEPROM correctly.  I talked to the openbsd folks about
this a long time ago, but didn't have the time needed to follow up.

There's about 4 cards in my cardbus card collection that fail in this
mode.

Warner

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

Re: /usr/include/sys/select.h:61: syntax error before "fd_set"

[Mike Barcroft]

Marc Recht <[EMAIL PROTECTED]> writes:
> > I'm trying to work out why the latest version of coldsync won't compile
> > on -current, even though it compiles on -stable.
> > 
> > I'm getting the compile time error:
> > 
> > /usr/include/sys/select.h:61: syntax error before "fd_set"
> > 
> > The coldsync header file looks like:
> > 
> > What header am I missing here?
> sys/types.h (before sys/select.h)

 includes ; see line 57 of rev 1.13.

Best regards,
Mike Barcroft

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

Re: cvs commit: src/sys/pci if_dc.c

[Martin Blapp]

Hi,

> OpenBSD gets these cards right.  I've not ported their code to our
> system at this time.  I know that the problem is due to our not
> reading the SEEPROM correctly.  I talked to the openbsd folks about
> this a long time ago, but didn't have the time needed to follow up.

Thanks for the tip. I'll look at their code now.

Martin


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

Re: netns

[Terry Lambert]

John Hay wrote:
> > > Why don't they use the netipx code? Surely netware use ipx.
> >
> > IPX is based on XNS.  It differs by one significant field.  The
> > SAP (Service Advertisement Protocol) in IPX comed directly from
> > XNS.
> 
> So you are agreeing with me that to use netns to do ipx when we
> have netipx does not make sense? :-)
> 
> > FWIW.
> 
> I know, a lot of my time went into netipx, which was derived from
> netns. I also did IPXrouted which does SAP too.

I was mostly agreeing with Julian, that if people are using it, it
shouldn't be orphaned because something moved out from under some
otherwise perfectly good code.  A lot of people used to do 802.3
vs. Ethernet II, as well, and they did it for compatability with
legacy systems... so whether it makes technical sense or not, it
might make business sense.  8-).

I can't run -current on my SMP box, because -current changed out
of compatability with it (I think KMB and Poul have similar ASUS
boxes that have the same problem), but I've been working on setting
up a -current system locally, both to bring some patches up to date,
and to deal with the SMP initialization issue that's been a thorn
in the side of the -smp list.  It'd be pretty trivial to deal with
the XNS compilation problems, if they are more recent that 4.4, so
if it turns out they are, I cn do that pretty easily, once I have
a -current box that actually boots without panic'ing.

-- Terry

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

alpha tinderbox failure

[Dag-Erling Smorgrav]

--
>>> Rebuilding the temporary build tree
--
>>> 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/alpha/obj/h/des/src/alpha/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
>>> Kernel build for GENERIC started on Sun Sep 22 15:22:25 PDT 2002
--
>>> Kernel build for GENERIC completed on Sun Sep 22 15:52:51 PDT 2002
--
>>> Kernel build for LINT started on Sun Sep 22 15:52:51 PDT 2002
--
===> vinum
cc1: warnings being treated as errors
/h/des/src/sys/coda/coda_venus.c: In function `venus_ioctl':
/h/des/src/sys/coda/coda_venus.c:277: warning: cast from pointer to integer of 
different size
/h/des/src/sys/coda/coda_venus.c:292: warning: cast from pointer to integer of 
different size
/h/des/src/sys/coda/coda_venus.c: In function `venus_readlink':
/h/des/src/sys/coda/coda_venus.c:380: warning: cast from pointer to integer of 
different size
/h/des/src/sys/coda/coda_venus.c: In function `venus_readdir':
/h/des/src/sys/coda/coda_venus.c:637: warning: cast from pointer to integer of 
different size
*** Error code 1

Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

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

Re: Trouble Building CURRENT on STABLE, cpp seg. fault

[qhwt]

On Sun, Sep 22, 2002 at 10:22:23PM +0900, I wrote:
> On Sun, Sep 22, 2002 at 02:44:54PM +0300, Giorgos Keramidas wrote:
> > On 2002-09-21 23:53, "Crist J. Clark" <[EMAIL PROTECTED]> wrote:
> > > I've been unable to build CURRENT on STABLE for a few days. I made
> > > sure to bring STABLE up to date. Is this just me? Is there a problem
> > > with building CURRENT on STABLE at the moment?
> > 
> > It isn't just you.  The same error stopped my build of current 2-3
> > days ago on 4.6-RELEASE.
> > 
> > >  if [ -f .olddep ]; then mv .olddep .depend; fi
> > >  rm -f .newdep
> > >  make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES |  MKDEP_CPP="cc 
>-E" CC="cc" xargs mkdep -a -f .newdep -O -pipe -march=pentium3 -Wall 
>-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
>-Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi  -nostdinc -I-  -I. 
>-I/usr/src.CURRENT/sys -I/usr/src.CURRENT/sys/dev 
>-I/usr/src.CURRENT/sys/contrib/dev/acpica -I/usr/src.CURRENT/sys/contrib/ipfilter 
>-D_KERNEL -include opt_global.h -fno-common  -mpreferred-stack-boundary=2 
>-ffreestanding
> > >  cc: Internal error: Segmentation fault (program cpp0)
> > >  Please submit a full bug report.
> > >  See http://www.gnu.org/software/gcc/bugs.html> for instructions.
> > >  mkdep: compile failed
> > >  *** Error code 1
> 
> Try 'make depend && make' using cpp0 built from -CURRENT source
> newer than the first import of gcc 3.2.1 prerelease:
> 
> $ pushd /usr/src/gnu/usr.bin/cc
> $ make obj && make depend && make
> $ popd
> $ GCC_EXEC_PREFIX=/usr/obj/usr/src/usr.bin/cc/cpp0/ make depend
> $ GCC_EXEC_PREFIX=/usr/obj/usr/src/usr.bin/cc/cpp0/ make
> 
> should work unless you are doing a cross-platform compiling.
> The bug in cpp0 seems to me to have been fixed after the first
> import of gcc 3.2.1-prerelease (2002-09-02(UTC)).

Actually the bug seems to be not only in cpp0 but in some other tools
under /usr/libexec, so even if make depend succeeds, you'll get another
crash:

cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstri
ct-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fform
at-extensions -ansi -g -nostdinc -I-  -I. -I/usr/src/sys -I/usr/src/sys/dev -I/u
sr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include
 opt_global.h -fno-common  -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/src/sys/netkey/keysock.c
In file included from /usr/src/sys/sys/systm.h:45,
 from /usr/src/sys/netkey/keysock.c:49:
machine/atomic.h: In function `atomic_set_long':
machine/atomic.h:253: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
*** Error code 1

So I had to build the world in advance, and use the tools under
/usr/obj/usr/src/${ARCH}/usr/libexec/ .
Also, it seems like it doesn't crash without -march= option, so
NO_CPU_CFLAGS and NO_CPU_COPTFLAGS might help you.

Anyway, I just managed to build the kernel from 2002-09-21(UTC) source,
on another machine with world built from 2002-09-01(UTC).

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

Re: -mcpu=pentiumpro still evil?

[Mike Silbersack]

On Sun, 22 Sep 2002, Alexander Kabaev wrote:

> On Sat, 21 Sep 2002 23:10:51 -0500 (CDT)
> Mike Silbersack <[EMAIL PROTECTED]> wrote:
>
> >
> > Is anyone else still seeing Sig 11's from GCC when mcpu=pentiumpro is
> > enabled (as it appears to be by default now)?  I get a segfault in the
> > same place every time when compiling a DIAGNOSTIC kernel when I leave
> > it enabled.
> >
> > Just curious if this is just me or not...
> >
> > Mike "Silby" Silbersack
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> >
> Please post an error message and a traceback from GCC if possible. I
> might have the patch for that.
>
> --
> Alexander Kabaev

Ok, I think this is the correct backtrace:

#0  0x0806ccee in cpp_ideq ()
#1  0x0806d31e in _cpp_lex_direct ()
#2  0x0806cfa5 in _cpp_lex_token ()
#3  0x080589e1 in cpp_macro_definition ()
#4  0x08058a69 in cpp_macro_definition ()
#5  0x08058ca7 in _cpp_handle_directive ()
#6  0x0806cfd4 in _cpp_lex_token ()
#7  0x08057dae in cpp_get_token ()
#8  0x08057ed9 in cpp_scan_nooutput ()
#9  0x080483e1 in do_preprocessing ()
#10 0x08048219 in main ()
#11 0x08048131 in _start ()

I'm seeing the segfault in the kernel make depend step, just as someone
else reported.

Mike "Silby" Silbersack


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

Re: Fixing ports/palm/coldsync.

[Mike Barcroft]

Josef Karthauser <[EMAIL PROTECTED]> writes:
> On Sun, Sep 22, 2002 at 04:42:32PM +0100, Josef Karthauser wrote:
> > Has anyone here got the time to help me out?  I want to fix the uvisor
> > code so that it works properly, but am getting caught up trying to fix
> > the coldsync port.  It compiles on -stable, but has been broken on
> > -current for a while.  Something changed in the fd_set area and it's not
> > compiled for a long time.  I'd really appreciate it is someone with a
> > knowledge of select foo could help me work out what's wrong.  Did we
> > tighten something up in -current, or have we deprecated something?
> 
> Mark Trettin <[EMAIL PROTECTED]> sent me a patch (attached for reference).

This turns out to be a bug in our headers.  I'm testing a patch which
fixes  in the standards case.  I'll post it to
-standards a little later if you want to test it.

Best regards,
Mike Barcroft

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

Re: Fixing ports/palm/coldsync.

[Josef Karthauser]

On Sun, Sep 22, 2002 at 07:47:20PM -0400, Mike Barcroft wrote:
> Josef Karthauser <[EMAIL PROTECTED]> writes:
> > On Sun, Sep 22, 2002 at 04:42:32PM +0100, Josef Karthauser wrote:
> > > Has anyone here got the time to help me out?  I want to fix the uvisor
> > > code so that it works properly, but am getting caught up trying to fix
> > > the coldsync port.  It compiles on -stable, but has been broken on
> > > -current for a while.  Something changed in the fd_set area and it's not
> > > compiled for a long time.  I'd really appreciate it is someone with a
> > > knowledge of select foo could help me work out what's wrong.  Did we
> > > tighten something up in -current, or have we deprecated something?
> > 
> > Mark Trettin <[EMAIL PROTECTED]> sent me a patch (attached for reference).
> 
> This turns out to be a bug in our headers.  I'm testing a patch which
> fixes  in the standards case.  I'll post it to
> -standards a little later if you want to test it.
> 

I thought it might be, but I'm the extreme opposite of bde in my
knowledge of this area (;.

Please can you Cc: me with the message to -standard, as I'm not on that
list.

Thanks Mike,
Joe
-- 
"As far as the laws of mathematics refer to reality, they are not certain;
and as far as they are certain, they do not refer to reality." - Albert
Einstein, 1921



msg43224/pgp0.pgp
Description: PGP signature

ldconfig in /etc/rc & /etc/rc.d/ldconfig

[Bakul Shah]

If the ldconfig_insecure flag is set in /etc/rc.conf,
ldconfig doesn't do anything useful at startup time except
complain.  The following patch should fix it.

diff -ur /usr/src/etc/rc ./rc
--- /usr/src/etc/rc Tue Sep 17 21:02:01 2002
+++ ./rcSun Sep 22 16:49:19 2002
@@ -692,9 +692,10 @@
 # add your own entries or you may come to grief.
 #
 ldconfig="/sbin/ldconfig"
+ldc_flags=""
 case ${ldconfig_insecure} in
 [Yy][Ee][Ss])
-   ldconfig="${ldconfig} -i"
+   ldc_flags="-i"
;;
 esac
 if [ -x /sbin/ldconfig ]; then
@@ -705,7 +706,7 @@
fi
done
echo 'ELF ldconfig path:' ${_LDC}
-   ${ldconfig} ${_LDC}
+   ${ldconfig} ${ldc_flags} ${_LDC}
 
# Legacy aout support for i386 only
case `sysctl -n hw.machine_arch` in
@@ -719,7 +720,7 @@
fi
done
echo 'a.out ldconfig path:' ${_LDC}
-   ${ldconfig} -aout ${_LDC}
+   ${ldconfig} -aout ${ldc_flags} ${_LDC}
;;
esac
 fi
diff -ur /usr/src/etc/rc.d/ldconfig ./rc.d/ldconfig
--- /usr/src/etc/rc.d/ldconfig  Tue Sep 17 21:02:03 2002
+++ ./rc.d/ldconfig Sun Sep 22 16:48:12 2002
@@ -21,7 +21,8 @@
case ${OSTYPE} in
FreeBSD)
ldconfig=${ldconfig_command}
-   checkyesno ldconfig_insecure && ldconfig="${ldconfig} -i"
+   ldc_flags=""
+   checkyesno ldconfig_insecure && ldc_flags="-i"
if [ -x "${ldconfig_command}" ]; then
_LDC=/usr/lib
for i in ${ldconfig_paths}; do
@@ -30,7 +31,7 @@
fi
done
echo 'ELF ldconfig path:' ${_LDC}
-   ${ldconfig} -elf ${_LDC}
+   ${ldconfig} -elf ${ldc_flags} ${_LDC}
 
# Legacy aout support for i386 only
case `sysctl -n hw.machine_arch` in
@@ -44,7 +45,7 @@
fi
done
echo 'a.out ldconfig path:' ${_LDC}
-   ${ldconfig} -aout ${_LDC}
+   ${ldconfig} -aout ${ldc_flags} ${_LDC}
;;
esac
fi

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

Re: Trouble Building CURRENT on STABLE, cpp seg. fault

[Jim Bloom]

Giorgos Keramidas wrote:
> 
> On 2002-09-21 23:53, "Crist J. Clark" <[EMAIL PROTECTED]> wrote:
> > I've been unable to build CURRENT on STABLE for a few days. I made
> > sure to bring STABLE up to date. Is this just me? Is there a problem
> > with building CURRENT on STABLE at the moment?
> 
> It isn't just you.  The same error stopped my build of current 2-3
> days ago on 4.6-RELEASE.
> 
> >  if [ -f .olddep ]; then mv .olddep .depend; fi
> >  rm -f .newdep
> >  make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES |  MKDEP_CPP="cc 
>-E" CC="cc" xargs mkdep -a -f .newdep -O -pipe -march=pentium3 -Wall 
>-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
>-Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi  -nostdinc -I-  -I. 
>-I/usr/src.CURRENT/sys -I/usr/src.CURRENT/sys/dev 
>-I/usr/src.CURRENT/sys/contrib/dev/acpica -I/usr/src.CURRENT/sys/contrib/ipfilter 
>-D_KERNEL -include opt_global.h -fno-common  -mpreferred-stack-boundary=2 
>-ffreestanding
> >  cc: Internal error: Segmentation fault (program cpp0)
> >  Please submit a full bug report.
> >  See http://www.gnu.org/software/gcc/bugs.html> for instructions.
> >  mkdep: compile failed
> >  *** Error code 1
> 

This is not just a problem with stable.  I had the same problem building a
kernel with Sept. 22, 7:30AM EDT cvsup of current source.  My machine is running
current from about a month ago.

Jim Bloom
[EMAIL PROTECTED]

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

i386 machine/endian.h

[Wesley Morgan]

I've been playing around with lang/icc a bit, and find it quite vexing
that machine/endian.h has macros that are ifdef'd around __GNUC__. The
intel compiler does not like the macros, partly because they are split
across multiple lines and possibly for other reasons.

It seems to me that making a header actually _require_ gcc-isms is
something that the FreeBSD team should be working away from... Would it
not be possible to put make some more generic macros available as well?
I'm sure it's not the only instance of similar issues, but making one
header less gcc-dependent is a step in the right direction is it not?

WNM


-- 
   _ __ ___   ___ ___ ___
  Wesley N Morgan   _ __ ___ | _ ) __|   \
  [EMAIL PROTECTED] _ __ | _ \._ \ |) |
  FreeBSD: The Power To Serve  _ |___/___/___/
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


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

Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error

[Alexander Leidinger]

On Sun, 22 Sep 2002 13:47:26 -0400 Alexander Kabaev
<[EMAIL PROTECTED]> wrote:

> > If yes: I can't find a *.core in /usr/{src,obj}, there's no coredump
> > limit, so how do I get the backtrace? I already tried to go into
> > gnu/usr.bin/gperf and make a "make cleandir; make cleandir; make",
> > but I don't get a coredump.
> > 
> > I also tried to run it withhin gdb, but c++ exists with something
> > like exit(1) and thats it, no way to make a backtrace.
> 
> What does kernel log say? When process dies with signal, kernel

/var/log/messages and dmesg only tell me about
---snip---
0xc31a2814 bw 6868 rttbest 1062 srtt 1653 bwnd 5816
0xc31a2814 bw 6268 rttbest 1062 srtt 1647 bwnd 5556
0xc398235c bw 7746 rttbest 3417 srtt 6833 bwnd 15309
---snip---
there's nothing else.

> usually logs the event. If anything, this should give you the name of
> the process which has died. Running 'gcc' or 'c++' under debugger is
> not very helpful, because these are just driver programs. The real
> processes which do the work are cpp1, cc1, ccp1 etc.

What about a "ktrace -i": http://www.leidinger.net/ktrace.out.bz2
(~50k), please tell me when you got it, I want to remove it then.

Bye,
Alexander.

-- 
   There's no place like ~

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

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

Re: i386 machine/endian.h

[Bruce Evans]

On Sun, 22 Sep 2002, Wesley Morgan wrote:

> I've been playing around with lang/icc a bit, and find it quite vexing
> that machine/endian.h has macros that are ifdef'd around __GNUC__. The
> intel compiler does not like the macros, partly because they are split
> across multiple lines and possibly for other reasons.

The Intel compiler shouldn't see these macros, so it should emit calls
to the corresponding library functions.  The macros work correctly with
Tendra because it doesn't see them.

Bruce


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

Re: i386 machine/endian.h

[Wesley Morgan]

As far as I can tell there are no __bswap* macros in the libraries; they
are defined as bswap*. Whatever should be happening, the network byte
swapping functions are creeping in using the __hton* and __ntoh* macros.
These are pulling in the __bswap* functions that are of course undefined.

Unless I'm doing something completely wrong here... Just dropping in icc
to replace gcc/g++.

On Mon, 23 Sep 2002, Bruce Evans wrote:

> On Sun, 22 Sep 2002, Wesley Morgan wrote:
>
> > I've been playing around with lang/icc a bit, and find it quite vexing
> > that machine/endian.h has macros that are ifdef'd around __GNUC__. The
> > intel compiler does not like the macros, partly because they are split
> > across multiple lines and possibly for other reasons.
>
> The Intel compiler shouldn't see these macros, so it should emit calls
> to the corresponding library functions.  The macros work correctly with
> Tendra because it doesn't see them.
>
> Bruce
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>

-- 
   _ __ ___   ___ ___ ___
  Wesley N Morgan   _ __ ___ | _ ) __|   \
  [EMAIL PROTECTED] _ __ | _ \._ \ |) |
  FreeBSD: The Power To Serve  _ |___/___/___/
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


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

Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error

[Craig Rodrigues]

On Sun, Sep 22, 2002 at 08:10:38PM +0200, Alexander Leidinger wrote:
> What about a "ktrace -i": http://www.leidinger.net/ktrace.out.bz2
> (~50k), please tell me when you got it, I want to remove it then.


What you want to do is, figure out exactly which program is crashing.
Add -v to your gcc flags, eg.

gcc -v -march=pentium-pro -c a.c

This will show you which programs are being invoked by gcc, which 
do the actual compiling.

For example,
===
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.2.1 [FreeBSD] 20020901 (prerelease)
 /usr/libexec/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL
__=1 -D__GXX_ABI_VERSION=102 -D__FreeBSD__=5 -D__FreeBSD_cc_version=53 -Duni
x -D__KPRINTF_ATTRIBUTE__ -D__FreeBSD__=5 -D__FreeBSD_cc_version=53 -D__unix
__ -D__KPRINTF_ATTRIBUTE__ -D__unix -Asystem=unix -Asystem=bsd -Asystem=FreeBSD
-D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D
__i386__ -D__ELF__ a.c -quiet -dumpbase a.c -march=pentium-pro -version -o /var/
tmp//ccqHiDhs.s
GNU CPP version 3.2.1 [FreeBSD] 20020901 (prerelease) (cpplib) (i386 FreeBSD/ELF)
===

The next thing you want to do is, invoke /usr/libexec/cc1 (or whatever
the program is on your system), manually from the command-line, with
all the same command-line flags, and verify that the crash still occurs.

The next thing you want to do is to invoke the same program under
gdb:

gdb /usr/libexec/cc1

==
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
(no debugging symbols found)...

(gdb) run [put all the command-line flags to cc1]
==

>From there, you should be able to see what the backtrace is to where
things are crashing.

Another helpful thing to do is to follow the instructions at:
http://gcc.gnu.org/bugs.html, and use the -save-temps flag to 
save the preprocessed source code of what is causing gcc to crash.
-- 
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]

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

Re: i386 machine/endian.h

[Mike Barcroft]

Wesley Morgan <[EMAIL PROTECTED]> writes:
> I've been playing around with lang/icc a bit, and find it quite vexing
> that machine/endian.h has macros that are ifdef'd around __GNUC__. The
> intel compiler does not like the macros, partly because they are split
> across multiple lines and possibly for other reasons.
> 
> It seems to me that making a header actually _require_ gcc-isms is
> something that the FreeBSD team should be working away from... Would it
> not be possible to put make some more generic macros available as well?
> I'm sure it's not the only instance of similar issues, but making one
> header less gcc-dependent is a step in the right direction is it not?

This was my fault.  I wasn't paying attention closely to issues with
other compilers.  I've had the attached patch in my local tree for
some time, but haven't had a chance to test it with ICC.  Can you
confirm it fixes the issues you're seeing?

Best regards,
Mike Barcroft


Be careful not to define GCC-specific optimizations in the non-GCC
case.

Index: endian.h
===
RCS file: /work/repo/src/sys/i386/include/endian.h,v
retrieving revision 1.34
diff -u -r1.34 endian.h
--- endian.h21 Aug 2002 16:19:58 -  1.34
+++ endian.h22 Aug 2002 00:29:19 -
@@ -117,11 +117,18 @@
return (__byte_swap_word(_x));
 }
 
-#endif /* __GNUC__ */
-
 #define__htonl(x)  __bswap32(x)
 #define__htons(x)  __bswap16(x)
 #define__ntohl(x)  __bswap32(x)
 #define__ntohs(x)  __bswap16(x)
+
+#else /* !__GNUC__ */
+
+#undef htonl
+#undef htons
+#undef ntohl
+#undef ntohl
+
+#endif /* __GNUC__ */
 
 #endif /* !_MACHINE_ENDIAN_H_ */

Re: VESA 800x600 console not working

[David Xu]

I have two patches:
http://people.freebsd.org/~davidxu/vm86.diff
http://people.freebsd.org/~davidxu/vm86_2.diff
the first patch is to keep vm86lock as a sleep lock,  and allow the
thread calling vm86 bios could be preempted, but still only one
thread can call vm86 bios.  so if we want a sleep mutex in trap() code
execute path, it hasn't problem.

the second patch try to keep source code modification minimal,
change vm86lock to spin lock, don't allow to be preempted when calling
vm86 bios, but if someday someone wants a sleep mutex in trap() code
execute path, it would have trouble.

you can select one of them to apply. I am not maintainer of VM86 code,
so I have trouble to commit this patch unless someone allow me to do.

David Xu

On Sunday 22 September 2002 06:09, Gavin Atkinson wrote:
> On Fri, 26 Jul 2002, David Xu wrote:
> > Yes, this is a known problem. I have a patch for this, you may
> > download it from here:
> > http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz
>
> Is there any chance of geting these committed? With them, my laptop is
> happy to give a 100x37 screen on VESA_800x600.
>
>
> Gavin
>
> > - Original Message -
> > From: "Rob" <[EMAIL PROTECTED]>
> > To: "Current" <[EMAIL PROTECTED]>
> > Sent: Saturday, July 27, 2002 6:46 AM
> >
> > > Having a laptop here, I wanted to get the same 800x600 console that I
> > > have in -stable.  I built my kernel with OPTIONS VESA and OPTIONS
> > > SC_PIXEL_MODE.  I have tried two methods.  The first was to put 0x0080
> > > in the device.hints file for SC.  That gave me a blank screen upon
> > > startup.  I also tried putting into /usr/local/etc/rc.d the vidcontrol
> > > command "vidcontrol -g 100x37 VESA_800x600.  That gave me a blank
> > > screen at the end of the bootup.  Is this functionality broken in
> > > -current, or am I doing something wrong?
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


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

Re: i386 machine/endian.h

[Mike Barcroft]

Mike Barcroft <[EMAIL PROTECTED]> writes:
> Wesley Morgan <[EMAIL PROTECTED]> writes:
> > I've been playing around with lang/icc a bit, and find it quite vexing
> > that machine/endian.h has macros that are ifdef'd around __GNUC__. The
> > intel compiler does not like the macros, partly because they are split
> > across multiple lines and possibly for other reasons.
> > 
> > It seems to me that making a header actually _require_ gcc-isms is
> > something that the FreeBSD team should be working away from... Would it
> > not be possible to put make some more generic macros available as well?
> > I'm sure it's not the only instance of similar issues, but making one
> > header less gcc-dependent is a step in the right direction is it not?
> 
> This was my fault.  I wasn't paying attention closely to issues with
> other compilers.  I've had the attached patch in my local tree for
> some time, but haven't had a chance to test it with ICC.  Can you
> confirm it fixes the issues you're seeing?

I thought about this a little bit more, and the previous patch won't
do anything unless two headers call .  A new patch
which is much more likely to work is attached.  Can you try this one
instead?

Best regards,
Mike Barcroft


Be careful not to define GCC-specific optimizations in the non-GCC
case.

Index: endian.h
===
RCS file: /work/repo/src/sys/i386/include/endian.h,v
retrieving revision 1.34
diff -u -r1.34 endian.h
--- endian.h21 Aug 2002 16:19:58 -  1.34
+++ endian.h23 Sep 2002 01:58:16 -
@@ -117,11 +117,20 @@
return (__byte_swap_word(_x));
 }
 
-#endif /* __GNUC__ */
-
 #define__htonl(x)  __bswap32(x)
 #define__htons(x)  __bswap16(x)
 #define__ntohl(x)  __bswap32(x)
 #define__ntohs(x)  __bswap16(x)
+
+#else /* !__GNUC__ */
+
+/*
+ * No optimizations are available for this compiler.  Fall back to
+ * non-optimized functions by defining the constant usually used to prevent
+ * redefinition.
+ */
+#define_BYTEORDER_FUNC_DEFINED
+
+#endif /* __GNUC__ */
 
 #endif /* !_MACHINE_ENDIAN_H_ */

Re: Who broke sort(1) ?

[Tim Robbins]

On Sun, Sep 22, 2002 at 01:43:38PM -0700, Steve Kargl wrote:

> On Sun, Sep 22, 2002 at 10:17:41PM +0200, Poul-Henning Kamp wrote:
> > 
> > flat# date | sort +5n
> > sort: open failed: +5n: No such file or directory
> > 
> > This breaks the build in libncurses...
> > 
> 
> POSIX via wollman.
> 
> See revision 1.58 of /usr/include/unistd.h, i.e.,
> 
> /* Define the versions we target for compliance. */
> #define _POSIX_VERSION  200112L
> #define _POSIX2_VERSION 200112L
> 
> 
> See email in the last 24 hours from walt about 
> problems building libc and Tim Robbins response
> to the problem.

I didn't read src/contrib/gnu-sort/lib/posixver.c carefully enough to
notice that it uses the the _POSIX2_VERSION macro, I thought it only used
the environment variable by that same name.

A workaround might be to #undef _POSIX2_VERSION after #include'ing 
in posixver.c but I don't think that would be correct. It's probably better
to either change all the scripts that use the obsolescent +pos -pos syntax
to use the new -k syntax or to change _POSIX2_VERSION back to whatever it
was before. I think the second is more realistic.


Tim

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

Re: i386 machine/endian.h

[marius]

On Sun, Sep 22, 2002 at 09:57:57PM -0400, Mike Barcroft wrote:
> Mike Barcroft <[EMAIL PROTECTED]> writes:
> > Wesley Morgan <[EMAIL PROTECTED]> writes:
> > > I've been playing around with lang/icc a bit, and find it quite vexing
> > > that machine/endian.h has macros that are ifdef'd around __GNUC__. The
> > > intel compiler does not like the macros, partly because they are split
> > > across multiple lines and possibly for other reasons.
> > > 
> > > It seems to me that making a header actually _require_ gcc-isms is
> > > something that the FreeBSD team should be working away from... Would it
> > > not be possible to put make some more generic macros available as well?
> > > I'm sure it's not the only instance of similar issues, but making one
> > > header less gcc-dependent is a step in the right direction is it not?
> > 
> > This was my fault.  I wasn't paying attention closely to issues with
> > other compilers.  I've had the attached patch in my local tree for
> > some time, but haven't had a chance to test it with ICC.  Can you
> > confirm it fixes the issues you're seeing?
> 
> I thought about this a little bit more, and the previous patch won't
> do anything unless two headers call .  A new patch
> which is much more likely to work is attached.  Can you try this one
> instead?
> 

Works fine, please commit.


> Best regards,
> Mike Barcroft

> Be careful not to define GCC-specific optimizations in the non-GCC
> case.
> 
> Index: endian.h
> ===
> RCS file: /work/repo/src/sys/i386/include/endian.h,v
> retrieving revision 1.34
> diff -u -r1.34 endian.h
> --- endian.h  21 Aug 2002 16:19:58 -  1.34
> +++ endian.h  23 Sep 2002 01:58:16 -
> @@ -117,11 +117,20 @@
>   return (__byte_swap_word(_x));
>  }
>  
> -#endif /* __GNUC__ */
> -
>  #define  __htonl(x)  __bswap32(x)
>  #define  __htons(x)  __bswap16(x)
>  #define  __ntohl(x)  __bswap32(x)
>  #define  __ntohs(x)  __bswap16(x)
> +
> +#else /* !__GNUC__ */
> +
> +/*
> + * No optimizations are available for this compiler.  Fall back to
> + * non-optimized functions by defining the constant usually used to prevent
> + * redefinition.
> + */
> +#define  _BYTEORDER_FUNC_DEFINED
> +
> +#endif /* __GNUC__ */
>  
>  #endif /* !_MACHINE_ENDIAN_H_ */


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

Re: -mcpu=pentiumpro still evil?

[Alexander Kabaev]

On Sun, 22 Sep 2002 18:51:14 -0500 (CDT)
Mike Silbersack <[EMAIL PROTECTED]> wrote:

> I'm seeing the segfault in the kernel make depend step, just as
> someone else reported.

OK, could you please try the patch at
http://people.freebsd.org/~kan/gcc-cpp.diff and let me know the results.


-- 
Alexander Kabaev


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

Re: Trouble Building CURRENT on STABLE, cpp seg. fault

[Alexander Kabaev]

I am asking people having CPP0 dying with SIG11 to try the patch at URL
below. Success/failure reports are appreciated.

http://people.freebsd.org/~kan/gcc-cpp.diff

-- 
Alexander Kabaev


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

Re: netns

[John Hay]

> > > > Why don't they use the netipx code? Surely netware use ipx.
> > >
> > > IPX is based on XNS.  It differs by one significant field.  The
> > > SAP (Service Advertisement Protocol) in IPX comed directly from
> > > XNS.
> > 
> > So you are agreeing with me that to use netns to do ipx when we
> > have netipx does not make sense? :-)
> > 
> > > FWIW.
> > 
> > I know, a lot of my time went into netipx, which was derived from
> > netns. I also did IPXrouted which does SAP too.
> 
> I was mostly agreeing with Julian, that if people are using it, it
> shouldn't be orphaned because something moved out from under some
> otherwise perfectly good code.  A lot of people used to do 802.3
> vs. Ethernet II, as well, and they did it for compatability with
> legacy systems... so whether it makes technical sense or not, it
> might make business sense.  8-).

You can tell them it makes business sense to do a s/AF_NS/AF_IPX/g
in their code and suddenly they will be able to do even more then
before, for instance they will be able to do different frame types
on the same wire and one different wires. The netns code can only
do one frame type per box, which is a pain if you want to connect
part 802.3 and part Ethernet II networks. Yes I know because we
run it like that at work. As a bonus FreeBSD get to maintain one
piece of code and not two pieces that do almost exactly the same
thing. Bugs fixed in one place, enhancements made in one place.
I'm sure it makes business sense. :-)

John
-- 
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]

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

Re: Who broke sort(1) ?

[Mike Barcroft]

Tim Robbins <[EMAIL PROTECTED]> writes:
> On Sun, Sep 22, 2002 at 01:43:38PM -0700, Steve Kargl wrote:
> > On Sun, Sep 22, 2002 at 10:17:41PM +0200, Poul-Henning Kamp wrote:
> > > 
> > > flat# date | sort +5n
> > > sort: open failed: +5n: No such file or directory
> > > 
> > > This breaks the build in libncurses...
> > > 
> > 
> > POSIX via wollman.
> > 
> > See revision 1.58 of /usr/include/unistd.h, i.e.,
> > 
> > /* Define the versions we target for compliance. */
> > #define _POSIX_VERSION  200112L
> > #define _POSIX2_VERSION 200112L
> > 
> > 
> > See email in the last 24 hours from walt about 
> > problems building libc and Tim Robbins response
> > to the problem.
> 
> I didn't read src/contrib/gnu-sort/lib/posixver.c carefully enough to
> notice that it uses the the _POSIX2_VERSION macro, I thought it only used
> the environment variable by that same name.
> 
> A workaround might be to #undef _POSIX2_VERSION after #include'ing 
> in posixver.c but I don't think that would be correct. It's probably better
> to either change all the scripts that use the obsolescent +pos -pos syntax
> to use the new -k syntax or to change _POSIX2_VERSION back to whatever it
> was before. I think the second is more realistic.

I think we'd really like to target POSIX 2001 for 5.0-RELEASE, so the
first solution would be best.  Temporarily backing out the updated
POSIX version bump might not be a bad idea if this is a task which
will take a while.

Best regards,
Mike Barcroft

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

Re: i386 machine/endian.h

[Mike Barcroft]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> writes:
> On Sun, Sep 22, 2002 at 09:57:57PM -0400, Mike Barcroft wrote:
> > Mike Barcroft <[EMAIL PROTECTED]> writes:
> > > This was my fault.  I wasn't paying attention closely to issues with
> > > other compilers.  I've had the attached patch in my local tree for
> > > some time, but haven't had a chance to test it with ICC.  Can you
> > > confirm it fixes the issues you're seeing?
> > 
> > I thought about this a little bit more, and the previous patch won't
> > do anything unless two headers call .  A new patch
> > which is much more likely to work is attached.  Can you try this one
> > instead?
> > 
> 
> Works fine, please commit.

Done.

Best regards,
Mike Barcroft

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

Re: netns

[Julian Elischer]

On Mon, 23 Sep 2002, John Hay wrote:

> > > > > Why don't they use the netipx code? Surely netware use ipx.
> > > >
> > > > IPX is based on XNS.  It differs by one significant field.  The
> > > > SAP (Service Advertisement Protocol) in IPX comed directly from
> > > > XNS.
> > > 
> > > So you are agreeing with me that to use netns to do ipx when we
> > > have netipx does not make sense? :-)
> > > 
> > > > FWIW.
> > > 
> > > I know, a lot of my time went into netipx, which was derived from
> > > netns. I also did IPXrouted which does SAP too.
> > 
> > I was mostly agreeing with Julian, that if people are using it, it
> > shouldn't be orphaned because something moved out from under some
> > otherwise perfectly good code.  A lot of people used to do 802.3
> > vs. Ethernet II, as well, and they did it for compatability with
> > legacy systems... so whether it makes technical sense or not, it
> > might make business sense.  8-).
> 
> You can tell them it makes business sense to do a s/AF_NS/AF_IPX/g
> in their code and suddenly they will be able to do even more then
> before, for instance they will be able to do different frame types
> on the same wire and one different wires. The netns code can only
> do one frame type per box, which is a pain if you want to connect
> part 802.3 and part Ethernet II networks. Yes I know because we
> run it like that at work. As a bonus FreeBSD get to maintain one
> piece of code and not two pieces that do almost exactly the same
> thing. Bugs fixed in one place, enhancements made in one place.
> I'm sure it makes business sense. :-)

My original posting was in error..
One of the things I remembered as using XNS actually uses IPX.


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


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

Re: Cant see ACPI thermal zones on a Supermicro P6DBU

[Doug White]

On Sun, 22 Sep 2002, David P. Reese Jr. wrote:

> Does anyone know a reason why i should not see any info about the thermal
> zones on a Supermicro P6DBU in sysctl?  I'm not even seeing the acpi_tz's
> in dmesg.  As far as i know, the board does have thermal sensors.  I can
> check the cpu temperatures in bios.  If it would help, i could also provide
> the output of acpidump.

Providing ACPI access routines for the onboard system monitoring chip(s)
doesn't seem to be widely implemented. I suspect its the complications in
writing ACPI code to access SMBus without stomping something else, or
touching the wrong device and hanging the system.

The Intel systems I work with have IPMI and you can access them that way
instead of through ACPI.  Looks like the P6DBU predates IPMI so the only
access to the health chip is through the chipset.

The only machine I have around here that provides thermal information is a
HP laptop, and it has other ACPI issues.

Otherwise, you can try healthd and related programs that directly access
the SMBus.

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org


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