Re: IPv6 testing...willing to help
I added the options a couple weeks ago. Everthing has been working fairly well. Two issues I have seen which I haven't verified if they are are related to INET6 or something else. First, ever since I added INET6, I have been seeing errors like looutput: af=0 unexpected (or something close to that) These are appearing frequently (several a minute). (There also is no newline after this error message in the kernel.) I ran cvsup around 15:00 EST today and built world and a new kernel. After rebooting, I started getting error messages from dhclient about unsupported address families. I haven't looked into this to determine if dhclient is working correctly and reporting warnings or is not working at all. I'll try to do some more checking later tonight or tomorrow. I'll also try to do more testing of INET6 in general. Starting in another week, I'll be unemployed and will use the time (when I'm not job hunting) to try and set up a network of a couple machines for testing. I can probably put a gateway in the middle as well. Jim Bloom [EMAIL PROTECTED] Yoshinobu Inoue wrote: > > The 1st thing I want to be tested is that, a kernel with > following additions to the config file > > options INET6 #IPv6 communications protocols > options IPSEC #IP security > options IPSEC_ESP #IP security (crypto; define w/ IPSEC) > options IPSEC_IPV6FWD #IP security tunnel for IPv6 > options IPSEC_DEBUG #debug for IP security > > pseudo-device gif 4 #IPv6 and IPv4 tunneling > pseudo-device faith 1 #for IPv6 and IPv4 translation > > just works fine, > and also all apps on your environments which you are usually > using still works fine on that kernel. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 testing...willing to help
I found the problems I was seeing. I had an old configuration of dhclient dating from before it was integrated into FreeBSD. At that time, I just called dhclient without specifying the interface. (I only had one NIC.) Dhclient then tried using all interfaces it could find. One of the interfaces it tried to use was faith0 which generated all of the errors. I just fixed by network startup to specify the interface for dhclient and all of the error messages went away. Jim Bloom [EMAIL PROTECTED] Jim Bloom wrote: > > I added the options a couple weeks ago. Everthing has been working fairly > well. Two issues I have seen which I haven't verified if they are are related > to INET6 or something else. > > First, ever since I added INET6, I have been seeing errors like > > looutput: af=0 unexpected (or something close to that) > > These are appearing frequently (several a minute). (There also is no newline > after this error message in the kernel.) > > I ran cvsup around 15:00 EST today and built world and a new kernel. After > rebooting, I started getting error messages from dhclient about unsupported > address families. I haven't looked into this to determine if dhclient is > working correctly and reporting warnings or is not working at all. I'll try to > do some more checking later tonight or tomorrow. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/secure/lib/libcrypto Makefile.inc Makefile
Add lynx-ssl to the list of ports which are broken on current. This was
as of Jan. 16 at 14:00 EST cvsup of ports and source followed by a make
world.
Jim Bloom
[EMAIL PROTECTED]
Kris Kennaway wrote:
>
> On 17 Jan 2000, Satoshi - Ports Wraith - Asami wrote:
>
> > Should I add some stuff to handle the differences in bsd.port.mk (like
> > we did with perl5)?
>
> It may be useful - although there are a lot of inconsistencies in how the
> openssl ports look for it. Dirk Froemberg was going to help with this -
> I'm not sure exactly what the best way to do it is. For example, ports
> like w3m-ssl pass the location of the openssl include directory, which
> needs to be either /usr/include or ${LOCALBASE}/include. Perhaps the best
> thing would be to bump OSVERSION (belatedly).
>
> Kris
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/secure/lib/libcrypto Makefile.inc Makefile
Here is the sequence I used for installing thing yesterday when I had
the problem. First, I cvsup'ed and did a make world. Next, I installed
the rsaref-2.0 port. Finally, I tried to make the lynx-ssl port.
The basic problem is that some of the include files are not being found
(ssl.h and crypto.h). I haven't read everything closely, but I believe
that the source uses
#include
#include
and puts -I${PREFIX}/include/openssl (in the Makefile) in CFLAGS. This
might be fixed by changing the source to
#include
#include
and having -I${PREFIX}/include in CFLAGS.
Here is the build log minus the configuration output:
===> Extracting for lynx-ssl-2.8.2.1
>> Checksum OK for lynx2.8.2rel.1.tar.gz.
>> Checksum OK for lynx-282-ssl.patch.gz.
===> lynx-ssl-2.8.2.1 depends on executable: openssl - found
===> lynx-ssl-2.8.2.1 depends on shared library: crypto.1 - found
===> lynx-ssl-2.8.2.1 depends on shared library: ssl.1 - found
===> Patching for lynx-ssl-2.8.2.1
===> Applying distribution patches for lynx-ssl-2.8.2.1
===> Applying FreeBSD patches for lynx-ssl-2.8.2.1
===> Configuring for lynx-ssl-2.8.2.1
... (Config deleted) ...
===> Building for lynx-ssl-2.8.2.1
PATH=.:$PATH; export PATH; /bin/sh -c './cfg_defs.sh'
Constructing sed-script
sed -e '/^#/d' -e '/^$/d' -e 's%\(.*\)=\(.*\@.*\)$%s=@\1@=\2=g%'
-e 's%\(.
*\)=\(http:.*\)$%s=@\1@=\2=g%' -e 's%\(.*\)=\(ftp:.*\)$%s=@\1@=\2=g%'
-e 's%\(
.*\)=\(.*\.html\)$%s=@\1@=\2=g%' ./lynx_help/help_files.txt | tr '='
'%' > hel
p_files.sed
Creating LYHelp.h
**
Help files will NOT be gzipped.
**
cd WWW/Library/Implementation && make CC="cc" LY_CFLAGS="-O -pipe
-I/usr/local/
include/openssl" CPPFLAGS="" LYFLAGS="-I/usr/local/include -DUSE_SSL"
cc -DHAVE_CONFIG_H -I/usr/local/include -DUSE_SSL -I../../..
-I../../../src
-I../../.. -I../../../src -I../../../WWW/Library/Implementation -O
-pipe -I/u
sr/local/include/openssl -I/usr/local/include -DUSE_SSL
-I../../../WWW/Library/
Implementation/ -DXMOSAIC_HACK -DACCESS_AUTH -c
../../../WWW/Library/Implementat
ion/HTParse.c
cc -DHAVE_CONFIG_H -I/usr/local/include -DUSE_SSL -I../../..
-I../../../src
-I../../.. -I../../../src -I../../../WWW/Library/Implementation -O
-pipe -I/u
sr/local/include/openssl -I/usr/local/include -DUSE_SSL
-I../../../WWW/Library/
Implementation/ -DXMOSAIC_HACK -DACCESS_AUTH -c
../../../WWW/Library/Implementat
ion/HTAccess.c
cc -DHAVE_CONFIG_H -I/usr/local/include -DUSE_SSL -I../../..
-I../../../src
-I../../.. -I../../../src -I../../../WWW/Library/Implementation -O
-pipe -I/u
sr/local/include/openssl -I/usr/local/include -DUSE_SSL
-I../../../WWW/Library/
Implementation/ -DXMOSAIC_HACK -DACCESS_AUTH -c
../../../WWW/Library/Implementat
ion/HTTP.c
../../../WWW/Library/Implementation/HTTP.c:15: ssl.h: No such file or
directory
../../../WWW/Library/Implementation/HTTP.c:16: crypto.h: No such file or
directo
ry
../../../WWW/Library/Implementation/HTTP.c:75: syntax error before `*'
../../../WWW/Library/Implementation/HTTP.c:75: warning: data definition
has no t
ype or storage class
../../../WWW/Library/Implementation/HTTP.c:83: syntax error before `*'
../../../WWW/Library/Implementation/HTTP.c: In function
`HTGetSSLHandle':
../../../WWW/Library/Implementation/HTTP.c:90: warning: assignment makes
pointer
from integer without a cast
../../../WWW/Library/Implementation/HTTP.c:91: request for member `cert'
in some
thing not a structure or union
../../../WWW/Library/Implementation/HTTP.c:100: warning: return makes
pointer fr
om integer without a cast
../../../WWW/Library/Implementation/HTTP.c: In function `HTLoadHTTP':
../../../WWW/Library/Implementation/HTTP.c:178: `SSL' undeclared (first
use in t
his function)
../../../WWW/Library/Implementation/HTTP.c:178: (Each undeclared
identifier is r
eported only once
../../../WWW/Library/Implementation/HTTP.c:178: for each function it
appears in.
)
../../../WWW/Library/Implementation/HTTP.c:178: `handle' undeclared
(first use i
n this function)
../../../WWW/Library/Implementation/HTTP.c:323: warning: passing arg 1
of `HTPro
gress' makes pointer from integer without a cast
*** Error code 1
Jim Bloom
[EMAIL PROTECTED]
Kris Kennaway wrote:
>
> On Mon, 17 Jan 2000, Jim Bloom wrote:
>
> > Add lynx-ssl to the list of ports which are broken on current. This was
> > as of Jan. 16 at 14:00 EST cvsup of ports and source followed by a make
> > world.
>
> Well, that makes a list of one. Can you provide more information (e.g. a
> transcript?) Are you using openssl-rsaref, or openssl with no RSA (the
> latter will break many ports, the former has a restrictive license).
>
> Kris
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: installworld fialed
Yes, I had the same problem. I simply removed /usr/share/info and ran
installworld again. I don't know what you might lose if you try this,
but I don't use info much so I didn't really care.
Jim Bloom
[EMAIL PROTECTED]
"T. Hsiang" wrote:
>
> Does anyone have the same problem?
>
> --
> ===> gnu/usr.bin/texinfo
> ===> gnu/usr.bin/texinfo/libtxi
> ===> gnu/usr.bin/texinfo/makeinfo
> install -c -s -o root -g wheel -m 555 makeinfo /usr/bin
> install -c -o root -g wheel -m 444 makeinfo.1.gz /usr/share/man/man1
> ===> gnu/usr.bin/texinfo/info
> install -c -s -o root -g wheel -m 555 info /usr/bin
> install -c -o root -g wheel -m 444 info.1.gz /usr/share/man/man1
> install -c -o root -g wheel -m 444 info.5.gz texinfo.5.gz /usr/share/man/man5
> ===> gnu/usr.bin/texinfo/install-info
> install -c -s -o root -g wheel -m 555 install-info /usr/bin
> install -c -o root -g wheel -m 444 install-info.1.gz /usr/share/man/man1
> ===> gnu/usr.bin/texinfo/texindex
> install -c -s -o root -g wheel -m 555 texindex /usr/bin
> install -c -o root -g wheel -m 444 texindex.1.gz /usr/share/man/man1
> ===> gnu/usr.bin/texinfo/doc
> sflag=`grep -q ^INFO-DIR-SECTION info.info || echo 1`; eflag=`grep -q
>^START-INFO-DIR-ENTRY info.info || echo 1`; install-info
>${sflag:+--section=Miscellaneous} ${eflag:+--entry=} info.info /usr/share/info/dir
> sflag=`grep -q ^INFO-DIR-SECTION info-stnd.info || echo 1`; eflag=`grep -q
>^START-INFO-DIR-ENTRY info-stnd.info || echo 1`; install-info
>${sflag:+--section=Miscellaneous} ${eflag:+--entry=} info-stnd.info
>/usr/share/info/dir
> sflag=`grep -q ^INFO-DIR-SECTION texinfo.info || echo 1`; eflag=`grep -q
>^START-INFO-DIR-ENTRY texinfo.info || echo 1`; install-info
>${sflag:+--section=Miscellaneous} ${eflag:+--entry=} texinfo.info
>/usr/share/info/dir
> install-info: menu item `makeinfo' already exists, for file `makeinfo'
> *** Error code 1
>
> Stop in /usr/src/gnu/usr.bin/texinfo/doc.
> *** Error code 1
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: More breakages
It looks like your last make world or make installworld did not complete. There is an install problem with installworld bootstrapping itself. New libraries are installed before the install binary is installed. When they try to use the "-fschg" option, you get that error. (installworld aborts at rcp with the same problem.) Simple recompile and install /usr/src/usr.bin/xinstall to fix both of these problems. Jim Bloom [EMAIL PROTECTED] Forrest Aldrich wrote: > > cc -c -O -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. > -I../../../include -D_KERNEL -include opt_global.h > -elf -mpreferred-stack-boundary=2 vers.c > linking kernel > textdata bss dec hex filename > 1807056 139340 115448 2061844 1f7614 kernel > chflags noschg /kernel > mv /kernel /kernel.old > install -c -m 555 -o root -g wheel -fschg kernel /kernel > /usr/libexec/ld-elf.so.1: install: Undefined symbol "string_to_flags" > *** Error code 1 > > This is from a cvsup I just performed minutes ago, FYI. > > 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: kernel breakage from ipfw6?
The problem here is that ip6_fw.c is dependent upon INET6 instead of IPv6FIREWALL. I sent mail to shin a little while ago about the problem. If you want to compile a kernel in the interim, change the line for ip6_fw.c in sys/conf/files to netinet6/ip6_fw.c optional ipv6firewall I believe this is the correct fix in any case. Jim Bloom [EMAIL PROTECTED] Kris Kennaway wrote: > > I get this whenever I try and build a kernel (with or without IPFIREWALL): > > linking kernel.debug > ip6_fw.o: In function `ip6_fw_init': > /sys/compile/MORDEN/../../netinet6/ip6_fw.c(.text+0x18a4): undefined reference to >`ip6_fw_chk_ptr' > /sys/compile/MORDEN/../../netinet6/ip6_fw.c(.text+0x18ae): undefined reference to >`ip6_fw_ctl_ptr' > *** Error code 1 > 1 error > > I've just verified my sources are up-to-date from cvsup3. Kernel config: > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
In the cross-build case, I would guess that the 'make installworld' could be run on either machine. It would depend upon which way the mounts are done. Is the host machine mounted on the target machine or the other way around. Some people strongly believe it should be one way or the other. Optimally, both cases should be handled correctly. Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: > > Hmm, ok. I think my terminology may have been poor. I meant that the > new sources should have been used to build the tools, but using the > existing machine headers/libraries to build the static binaries. One > question though, what architecture *should* the install-tools be? > Normally, one would run installworld on the target machine and not > necessarily the host machine. For example, if I was cross-building an > axp world on my x86 machine, then I would want to run 'make buildworld' > on the x86, but would want to run 'make installworld' on the axp. Thus, > the build tools in that case need to be x86 binaries, but the install > tools need to be axp binaries. Of course, in that case you can't use > the build machine's header files or libraries to build the install tools. > Thus, you could use the headers/binaries in the source tree, except that > you might then end up linking against a newer libc that needs a newer > kernel to run. The other choice is to build the install tools during > installworld using the target machine's headers/libraries, but then > installworld would no longer be a read-only operation. :( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING
I did the following and it worked for me: cd /usr/src make buildworld make installworld cd /usr/src/usr.bin/xinstall make install cd /usr/src make installworld The first make installworld terminates with an errors, but the second on goes through. I don't see any reason why the following wouldn't work as well: cd /usr/src make buildworld cd /usr/src/usr.bin/xinstall make install cd /usr/src make installworld I just NFS mounted a completed buildworld on my laptop (which had a two week old -current) and I am trying this as I type. It is a slow machine, so it might take a while. I'll post an update when it completes. Jim Bloom [EMAIL PROTECTED] Warner Losh wrote: > > In message <[EMAIL PROTECTED]> Max Khon writes: > : actually instructions are wrong. > : you can't build xinstall before `make buildworld' now with old libc. > > I've seen multiple, conflicting reports on this. I've not personally > hit this bug. What's the exact sequence one must do? > > Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING
The method below worked just fine on my laptop. I can't guarantee how it will do on a 3.x system for upgrading. Also, if a kernel is being installed, it must be done before installing install or after the installworld. Jim Bloom [EMAIL PROTECTED] Jim Bloom wrote: > > I don't see any reason why the following wouldn't work as well: > > cd /usr/src > make buildworld > cd /usr/src/usr.bin/xinstall > make install > cd /usr/src > make installworld > > I just NFS mounted a completed buildworld on my laptop (which had a two > week old -current) and I am trying this as I type. It is a slow > machine, so it might take a while. I'll post an update when it > completes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING
This reminds me of a simpler way to do it in the current situation. In all cases except crossbuilding and running the install on the build host with DESTDIR=/mount_point, The folowing command should work: make installworld INSTALL=/usr/obj/usr/src/usr.bin/xinstall/xinstall Jim Bloom [EMAIL PROTECTED] Bruce Evans wrote: > > Installing the xinstall built by buildworld, with itself, would be safe. > Similarly for the new libc -- install it using the new xinstall using > something like > > cd /usr/src/libc > MAKEOBJDIRPREFIX=/somehwere INSTALL=/somehwere/.../xinstall install > > Simpler method: build and install the host xinstall static (NOSHARED=yes) > before running installworld. It's too late to do this after installworld > corrupts the host's includes and libutil.a. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mail.freebsd.org's host id changed
Will someone please put an MX record up for hub.freebsd.org so it's mail gets rerouted. I have mail queued up for delivery to there. Jim Bloom [EMAIL PROTECTED] Matthew Dillon wrote: > > : > :On Tuesday, 1 February 2000 at 18:49:22 -0800, Matthew Dillon wrote: > :> Did someone do something to mail.freebsd.org, my ssh is telling me > :> it's hostid has been changed. > : > :Right, hub had disk problems, so jmb moved mail to builder. > : > :Greg > >Ah, ok. Thanks! Just making sure. > > -Matt > Matthew Dillon > <[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: UPDATING
Ruslan Ermilov wrote: > > On Tue, Feb 01, 2000 at 02:51:11PM -0500, Jim Bloom wrote: > > I did the following and it worked for me: > > > > cd /usr/src > > make buildworld > > make installworld > > cd /usr/src/usr.bin/xinstall > > make install > > cd /usr/src > > make installworld > > > > The first make installworld terminates with an errors, but the second on > > goes through. > > > It can't be true! Nope, I'm pretty sure that is exactly what I did. > > After the first `make installworld' fails, we will have: > 1) a new `libutil' without string_to_flags() > 2) an old `libc' without setflags() > 3) an old /usr/bin/install with string_to_flags() linked against libutil. I believe the new libc has been installed as well. My first installworld got an error while trying to install rcp. I believe this is the first program that uses any flags to install. Once you get to this point, all of the libraries have been installed. I believe there is lazy resolution of the library symbols at run time. They are not checked until they are actually referenced, not when the program starts executing. They are first checked when ln is run, but that used consistent versions of the libraries for both version of install. > > Apparently that (cd /usr/src/usr.bin/xinstall; make install) will fail > with `/usr/lib/ld-elf.so.1: install: Undefined symbol "string_to_flags"'. > > Seems you did something different... maybe you just copied new xinstall > over an old /usr/bin/install? I don't believe I copied the executable. I don't have an easy way to go back and test it again. Yesterday, I tried NFS mounting /usr/src and /usr/obj (after a buildworld had completed) on a two week old copy of current (before the commits). That time I simple did a make install for xinstall followed by an installworld. No problems on that test. Jim Bloom To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING
No, I don;t have the log. It has been overwritten by a newer copy.
I looked into PRECIOUSLIB. It appears to be broken in
/usr/share/mk/bsd.lib.mk. Review this excerpt from the file:
.if defined(PRECIOUSLIB) && !defined(NOFSCHG)
SHLINSTALLFLAGS+= -fschg
.endif
_INSTALLFLAGS:= ${INSTALLFLAGS}
.for ie in ${INSTALLFLAGS_EDIT}
_INSTALLFLAGS:= ${_INSTALLFLAGS${ie}}
.endfor
_SHLINSTALLFLAGS:= ${INSTALLFLAGS}
.for ie in ${INSTALLFLAGS_EDIT}
_SHLINSTALLFLAGS:= ${_SHLINSTALLFLAGS${ie}}
.endfor
First, _SHLINSTALLFLAGS is used for install and not SHLINSTALLFLAGS.
This then uses uses INSTALLFLAGS twice. Try the patch below if you want
to fix the problem. (It may have whitespace errors from cut and paste
and a missing empty line.)
--- bsd.lib.mk.orig Wed Feb 2 11:50:59 2000
+++ bsd.lib.mk Wed Feb 2 11:51:31 2000
@@ -280,8 +280,8 @@
.for ie in ${INSTALLFLAGS_EDIT}
_INSTALLFLAGS:=${_INSTALLFLAGS${ie}}
.endfor
-_SHLINSTALLFLAGS:= ${INSTALLFLAGS}
-.for ie in ${INSTALLFLAGS_EDIT}
+_SHLINSTALLFLAGS:= ${SHLINSTALLFLAGS}
+.for ie in ${SHLINSTALLFLAGS_EDIT}
_SHLINSTALLFLAGS:= ${_SHLINSTALLFLAGS${ie}}
.endfor
Jim Bloom
[EMAIL PROTECTED]
Ruslan Ermilov wrote:
> Yeah, just figured this myself, but one thing I still don't understand
> is how the new libc.so.4 gets installed on the first pass? The problem
> is that it is declared as PRECIOUSLIB in libc/Makefile, this will result
> in -fschg passed to install. Do you have a log from the first failed
> installworld?
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mail.freebsd.org's host id changed
John Polstra wrote: > > In article <[EMAIL PROTECTED]>, Jim Bloom <[EMAIL PROTECTED]> wrote: > > Will someone please put an MX record up for hub.freebsd.org so it's mail > > gets rerouted. I have mail queued up for delivery to there. > > Why are you addressing mail to [EMAIL PROTECTED]? The correct > address to use is [EMAIL PROTECTED] Because I replied to a message I received which had [EMAIL PROTECTED] The message originated on hub and I guess the sender's address was not rewritten. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [install-tools stage in Makefile.inc1] (was: Re: 3.4->4.0 ... *almost* ...)
Ruslan Ermilov wrote: > > texinfo is already in bootstrap tools. The problem is that we do not have > such a thing like `install' tools. Apparently, every tool we are using > at installworld stage, should be compiled `static' at buildworld stage, > and then these tools should be used at installworld. Among these tools, > there should be at least xinstall and install-info. Don't forget the cross platform installation issues. If the installworld is executed on the target machine with the host machine's build area mounted, then this works fine. If you have the target machine's root mounted on the host machine, you can't use anything out of the build area. > > I could MFC the -current texinfo into -stable, so installworld of > -current would be possible from the latest -stable, but... > > Another possibility would be to add install-tools target to Makeinfo.inc1 > to statically build install tools like xinstall and install-info, and > use them at installworld stage. I will prepare the patch tomorrow, will > test it on my -stable machine, and will then send it to -current. The problem with install-info is not a linkage problem, but a feature change between the versions. So far I don't see a reason to to link it 'static'. I believe what needs to be done in this case is to ensure that install-info is installed before it is used. I suspect that a bit of careful addition of early installs in the middle of installworld will solve this problem. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS UP HEADS UP] xinstall now statically linked again.
This won't give you a statically linked install. You might try adding 'NOSHARED=yes' to the make command below. Jim Bloom [EMAIL PROTECTED] Josef Karthauser wrote: > > I've committed the fix. Another way of not tripping over problems is: > > # cd /usr/src/usr.bin/xinstall > # make clean depend all install > > This'll give you an install that's statically linked. > > If your install program is already broken then you'll need to copy the > install binary into /usr/bin from your obj tree by hand. > > Sorry for the inconvenience that this has caused. > Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING - kernel fails to compile
You still didn't get your installworld to complete succesfully. You have install, libc, and libutil out of sync. I believe the correct procedure for installing everything in your case is: make -k -NOFSCHG installworld make installworld Jim Bloom [EMAIL PROTECTED] Dan Langille wrote: > > [root@buff:/usr/src/sys/compile/BUFF] # make install > install -c -m 555 -o root -g wheel -fschg kernel /kernel > /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" > *** Error code 1 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with openssl in 4.0rc and ports/security/openssh
The problem initially reported was made worse by a couple of things. First, Kris has not yet committed the changes to the openssh port so that it will issue errors about the cryptography not being installed "correctly". This will not be in all ports that use openssl when 4.0 is released. The ports which will not be modified are the ones which are using configure to find openssl and have not had build problems reported. (I have been looking at bento's error reports, but not on the ports mailing list since I can't handle the additional e-mail volume.) These include several ports which simply disable SSL when they do not link correctly when they test for the existence of openssl (RSA symbols undefined). (If you come across any ports like this, please let Kris and me know so we can patch the port.) I also still have a couple ports in this class to be completed. The ports Kris and I have fixed also will use the system version of openssl over the port if it is installed. Unpatched ports may use either version if the openssl port is installed. Next, the error messages in ports/MK/bsd.ports.mk refer to a section of the handbook which had not been committed when the release candidate was created (and is still not on the web). We still need the packages (USA and international) created to upgrade the cryptography to include RSA. In conclussion, this will never be completed fixed (until all of the legal issues disappear). People will need to manually install upgraded cryptography as part of installing. The original complaint just points out that we are not yet at the point where we want to be for the final release of 4.0, but that was why 4.0RC was created. Jim Bloom [EMAIL PROTECTED] Kris Kennaway wrote: > > On Sat, 12 Feb 2000, John Hay wrote: > > > and to me it looks like rsa.h is included: > > > > internat:/home/ftp/pub/FreeBSD/releases/i386/4.0-2211-SNAP/des > cat des.?? | >tar -tzvf - | grep rsa > > -r--r--r-- root/wheel12208 Feb 12 07:09 2000 usr/include/openssl/rsa.h > > > > Or is there something that I miss? > > That looks right. I think the original person was getting their crypto > from the wrong place. > > Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yes, current is broke...
Yes it is. strlcat and strlcpy are not needed in libssh since they are in the libc already. They existed in the port because earlier version of 3.x did not have them. Mark is in the middle of committing all of the changes. It might be a little while until everything is clean again. Jim Bloom [EMAIL PROTECTED] Dan Langille wrote: > > I'm guessing this is related to jkh's mention of OpenSSH coming into > the tree, but I'm posting it anyway. Just in case it helps. my cvsup is > less then 4 hours old. > > ===> libssl > cd /usr/src/secure/lib/libssl; make _EXTRADEPEND > echo libssl.so.1: /usr/obj/usr/src/secure/lib/libssl/openssl/opensslconf.h >> .depend > ===> libssh > make: don't know how to make strlcat.c. Stop > *** Error code 2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mergemaster fail with crypto changes
While I was working on this project before I found out that Mark was 95%
done already, I made those tests be:
.in !defined(NO_OPENSSH) && !defined(NOCRYPT)
NOCRYPT has been the standard way of indicating that the cryptograph
package has not been installed.
Jim Bloom
[EMAIL PROTECTED]
Munehiro Matsuda wrote:
>
> Hi all,
>
> I don't have crypto in my source tree, because I'm in Japan,
> I get following error using mergemaster.
>
> --8<-8<-Cut here-8<-8<-
> # mergemaster
>
>
> install: /usr/src/etc/../crypto/openssh/ssh_config: No such file or directory
> *** Error code 71
>
> Stop in /usr/src/etc.
>
> *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to the
> temproot environment
> --8<-8<-Cut here-8<-8<-
>
> In /usr/src/etc/Makefile (rev 1.214), it should check for existance of
> crypto directory.
>
> --- Makefile.ctmFri Feb 25 11:53:34 2000
> +++ MakefileFri Feb 25 13:47:10 2000
> @@ -20,7 +20,7 @@
> ${.CURDIR}/../usr.bin/mail/misc/mail.rc \
> ${.CURDIR}/../usr.bin/locate/locate/locate.rc
>
> -.if !defined(NO_OPENSSH)
> +.if exists(${.CURDIR}../crypto) && !defined(NO_OPENSSH)
> BIN1+= ${.CURDIR}/../crypto/openssh/ssh_config \
> ${.CURDIR}/../crypto/openssh/sshd_config
> .endif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: openssh uses /etc (bad)
I'm not suprised to here this. The Makefiles in that directory are from
OpenBSD's version of openssh. If you want to build ssh manually, you
will need to build parts of /usr/src/secure/{lib,user.sbin,usr.bin} and
/usr/src/lib/libpam. The makefiles are for reference only.
Jim Bloom
[EMAIL PROTECTED]
Ollivier Robert wrote:
>
> BTW manual build in /usr/src/crypto/openssh (i.e. outside buildworld) is
> rather broken but I'm sure Mark will look at that.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: openssh uses /etc (bad)
Crypto/ is just a storage location for the for files. They are committed there just like files are in contrib. Buildworld never explicitly goes into either of these directories; the files stored there are referenced by makefiles in other parts of the tree. For example, look at the directory src/secure/usr.bin/ssh. The only file there is Makefile. Reading the Makefile, you will see that it needs several files. These are found through the .PATH derective which references crypto/openssh. Jim Bloom [EMAIL PROTECTED] Ollivier Robert wrote: > > According to Kris Kennaway: > > crypto/ is the analogue of contrib/ for crypto code. You're not supposed > > to build there..look under secure/. > > I was confused :) > > "buildworld" is now running on the two machines here... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is openssl/openssh working right yet for others?
Andrew Sherrod wrote: > > I had similar problems with mod_ssl (for apache). And > once I completed that, getting it to install, and for > apache to recognize it... > Well, actually still working on it. > Apache tells me to configure ssl, I do, ssl tells me > to run "make certificate" on apache, and I do, apache > crashes then tells me to configure ssl... > and so on, ad infinitum. > > Any ideas? There were some patches committed to apache13-modssl and apache13-php3 a little while ago. They fix the build problems and I got apache13-modssl up and running with them without any problems. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cpp change breaks ipfw
I have been using cpp on my firewall to expand my local firewall rules and fill in the local address and subnetmask. This makes things easier my ISP decides to change my IP address using DHCP. My firewall is running an approximately one year old version of current and I'm trying to upgrade it to a recent version. I am running ipfw as "ipfw -p /usr/bin/cpp -Daddr=value1 -Dmask=value2 file". My firewall rules have been using constructs similar to the following if put in a file. #define addr 192.168.2.5 #define mask 255.255.254.0 add pass tcp from addr:mask to any 25 setup On the old version of current this expands to add pass tcp from 192.168.2.5:255.255.254.0 to any 25 setup but on a new version of current this expands to add pass tcp from 192.168.2.5 : 255.255.254.0 to any 25 setup Note the extra spaces around the colon. Unfortunately, this breaks ipfw which interprets the colon where it expects the "to". There are several options here: 1) Fix cpp to not emit the extra spaces 2) Fix ipfw to handle addresses being multiple arguments 3) Document the cpp is not a valid preprocessor for ipfw on the manual page. Option 1 seems like it might be a little difficult. Option 2 looks to be reasonably simple to implement after reading the code. Option 3 is the easiest, but I believe it is the wrong way to handle the problem. I can submit patches for 2 or 3 reasonably quickly. I have no idea about fixing cpp. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fix for problems building openssl ports
I found the problem Jordan and Robert Watson were having building ports that
require rsaref and openssl. The test for whether libcrypto was compiled with
RSA was using shell syntax for executing the command and not make's syntax.
The extra 'true' on the command is to silence make's warning about a non-zero
exit status of the command.
With the fix below, the error about RSA being required is now displayed at
the correct time. This still does not solve the more fundamental problem of
what gets distributed on the CD in terms openssl and RSA.
Jim Bloom
[EMAIL PROTECTED]
--- ports/Mk/bsd.port.mk.orig Sat Feb 19 21:51:49 2000
+++ ports/Mk/bsd.port.mkSat Feb 19 22:00:39 2000
@@ -582,7 +582,7 @@
@${FALSE}
.else
.if ${USE_OPENSSL} == RSA
-_HASRSA= "`/usr/bin/nm /usr/lib/libcrypto.a | /usr/bin/grep RSA_free`"
+_HASRSA!= /usr/bin/nm /usr/lib/libcrypto.a | /usr/bin/grep RSA_free ; true
.if empty(_HASRSA)
.BEGIN:
@${ECHO} "This port requires RSA crypto, which is not present in your"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make world
See the file src/UPDATING. This is one of a couple problems that one sees when trying to install current on an older system. If this error isn't mentioned explicitly, check the sections relating to flags and xinstall (install). Jim Bloom [EMAIL PROTECTED] Omachonu Ogali wrote: > > Anyone else got this error? > > -- snip -- > ===> lib/libcom_err/doc > install-info --quiet --defsection="Programming & development tools." --defentry="* >libcom_err: (com_err).A Common Error Description Library for UNIX." >com_err.info /usr/share/info/dir > install-info: unrecognized option `--defsection=Programming & development tools.' > Try `install-info --help' for a complete list of options. > *** Error code 1 > > Stop. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: breakage in make release
David O'Brien committed some changes a few hours ago adding the gasp infodocs into the build. He might have introduced a bug here. Here is the commit message. Jim Bloom [EMAIL PROTECTED] > obrien 2000/02/21 12:33:32 PST > > Modified files: > gnu/usr.bin/binutils/doc Makefile > gnu/usr.bin/binutils/gasp Makefile > Removed files: > gnu/usr.bin/binutils/gasp/doc Makefile > Log: > Build and install gasp's infodocs along side the other binutil docs rather > than seperately. > > Pointed out by: bde > > Revision ChangesPath > 1.4 +3 -2 src/gnu/usr.bin/binutils/doc/Makefile > 1.6 +1 -3 src/gnu/usr.bin/binutils/gasp/Makefile Bill Swingle wrote: > > On Mon, Feb 21, 2000 at 06:21:48PM -0800, Thomas Dean wrote: > > There were some posts on -current in the past few days about binutils. > > I believe they were related. > > > > Look at the archive on FreeBSD, search current for binutils. > > Hehe, funny that you would suggest that I should look in the archives > since I'm still trying to get them back up again. :) > > Thanks for the pointer anyway :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cpp change breaks ipfw
No. It has the same bug. That method of concatenation only works for strings. Jim Bloom [EMAIL PROTECTED] Kai Großjohann wrote: > / > | #define rule(ADDR,MASK) \ > | add pass tcp from ADDR ## : ## MASK to any 25 setup > | > | rule(192.168.2.5,255.255.254.0) > \ > > Does it do what you want? Somewhat clumsy, but it does seem to work. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cpp change breaks ipfw
Kai Großjohann wrote: > > / > | $ cat foo > | #define rule(ADDR,MASK) add pass tcp from ADDR ## : ## MASK to any 25 setup > | rule(192.168.2.5,255.255.254.0) > | $ type cpp > | cpp is hashed (/usr/bin/cpp) > | $ cpp foo > | # 1 "foo" > | > | add pass tcp from 192.168.2.5:255.255.254.0 to any 25 setup > | $ cpp --version > | 2.95.2 > \ > > Note that there is no space in ``192.168.2.5:255.255.254.0''. I > thought that this is what you wanted? If this isn't what you wanted, > I'm sorry for the misunderstanding. That small test works fine, but doesn't solve the problem I was having. Try this small test case to see my problem: #define addr 192.186.2.5 #define mask 255.255.240.0 #define rule(ADDR,MASK) add pass tcp from ADDR ## : ## MASK to any 25 setup rule(addr,mask) This also does not work if addr and mask are defined on the command line. The problem arises from using another defined value as the string being concatenated. The concatenation works for constants though. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mod_ssl & current
You definitely don't need -lRSAglue. That file is an empty library just for compatibility. The port apache3-modssl worked a couple days ago when I last made a pass through all of the ports using openssl in -current. I'll take a look at it again (by tomorrow) and see where things stand. The recent upgrade of modssl might have caused a problem or broken a patch. Jim Bloom [EMAIL PROTECTED] Manfred Antar wrote: > > I needed to add -lRSAglue -lrsaUSA to the SSL_LIBS= line in > /usr/ports/www/apache13-php3/work/apache_1.3.12/src/modules/ssl/Makefile > and install the recompiled libssl.so in /usr/local/libexec/apache. > Works fine > Note this is for the apache13-php3 port but I bet it will work for the apache13-php4 >port > Manfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mod_ssl & current
I am seeing the same thing with a world built yesterday afternoon. I don't know if this is an issue with multiple dlopen'ed libraries or what. Here is what I believe the port is doing. During the build process, the main apache server is built. The ssl layer is created as an add-in module (.so) which I would assume is dlopen'ed. This module is linked as follows: gcc -L/usr/lib -shared -o libssl.so -lssl -lcrypto At runtine, apache tries to dlopen libssl.so. libcrypto should dlopen librsaUSA.so. Something doesn't seem to be happening correctly though. My previous test was before librsaUSA was created. Can Peter or John shed any light on possible linker or dynamic loader issues here? Jim Bloom [EMAIL PROTECTED] Kris Kennaway wrote: > > On Tue, 29 Feb 2000, Manfred Antar wrote: > > > I needed to add -lRSAglue -lrsaUSA to the SSL_LIBS= line in > > /usr/ports/www/apache13-php3/work/apache_1.3.12/src/modules/ssl/Makefile > > and install the recompiled libssl.so in /usr/local/libexec/apache. > > Works fine > > Note this is for the apache13-php3 port but I bet it will work for the >apache13-php4 port > > This may work, but I doubt this is necessary. -lRSAglue is an empty > library which only exists to keep legacy ports happy, and -lrsaUSA will be > automatically dlopen()ed if you have a recent libcrypto.so. > > As with the other guy, please make sure your libcrypto.so is up to date - > I haven't seen evidence from either of you yet that this is the case :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mod_ssl & current
We have found a fix that will change the building of librsaUSA to fix the problem. The fix will get committed after the release engineer approve the commit. The port will not need to be changed in the long run. Jim Bloom [EMAIL PROTECTED] Jim Bloom wrote: > > You definitely don't need -lRSAglue. That file is an empty library just for > compatibility. > > The port apache3-modssl worked a couple days ago when I last made a pass through > all of the ports using openssl in -current. I'll take a look at it again (by > tomorrow) and see where things stand. The recent upgrade of modssl might have > caused a problem or broken a patch. > > Jim Bloom > [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: no openssh after build
In either case, the answer is that you do not need to install the rsaref port before any builds. It is only a runtime dependency now. Jim Bloom [EMAIL PROTECTED] Walter Brameld wrote: > > > Do you still need to install the rsaref port before openssh? > > (/usr/ports/security) > > > Ah, sorry. That's for SSL. Not awake yet, I guess.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hangs booting fresh -current
Nik Clayton wrote: > > On a related note, why does UPDATING say to build and install the kernel, > and then reboot, before doing the "installworld"? That contradicts the > advice in the Handbook (which I wrote), and I would've thought it's wrong > precisely because it allows for things like kernel/mount mismatches to > occur. Because the signal interface changed several months ago. If you ran installworld on an old kernel, the machine would panic part way through the install. It is almost impossible to do forward compatibility on major changes. I guess you need to update the handbook to reflect this change. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld failures
Are you building with -DNOSHARE? That is the only way I can think of off the top of my head. Jim Bloom [EMAIL PROTECTED] Jeff Palmer wrote: > > Hi all, > > I have cvsupped and tried to build world mutiple times over the past 3 > days, each time I get the same error. I have been following the mailing > lists and don't see any other complaints.. So I'm sure the trouble is > with my machine... > > /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to > `ERR_load_RSAREF_strings' > /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to > `RSA_PKCS1_RSAref' > *** Error code 1 > Stop in /usr/src/usr.sbin/ppp. > *** Error code 1 > > anyone know what may be causing this, and what I may be able to do, to > correct? > > Please CC: any replies to: > [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: AWE64 & PCM
The only minor problem I see is that your game port is detected twice. Other than that, the hardware is detected correctly. You have asked for help, but what problem(s) are you seeing? I believe to get everything currently support on the AWE64, your config file should look like this: device pcm device sbc device joy There is no support for the wave table part of the card at this time. Jim Bloom [EMAIL PROTECTED] Chris Wasser wrote: > > Hi all, hate to post something this insignificant to the mailing list, but > I've search the entire src tree with no luck in resolving this myself > (well, grepping for awe64,wavetable,game .. found the AWE64 define in > /usr/src/sys/dev/sound/isa/sbc.c easily enough) .. I'm sure it's due to > some braindeadness on my behalf, but I'd sure appriciate someone steering > me in the right direction on this. I also searched for the > matching/compatible ID strings, no luck. > > Hopefully I provided enough information here... > > FreeBSD area51.v-wave.com 4.0-CURRENT FreeBSD 4.0-CURRENT #1: Sun Mar 5 > 12:02:16 MST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/AREA51 > i386 > > (cvsupped today -- well, at time of this posting.) > > joy0 at port 0x201 on isa0 > sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq > 5 drq 1,5 on isa0 > sbc0: setting card to irq 5, drq 1, 5 > pcm0: on sbc0 > joy1: at port 0x208-0x20f on isa0 > unknown0: at port 0x620-0x623 on isa0 > > Now I tried enabling PNPBIOS in the kernel config, but that just produced > a screenful of crap [PNP OS is disabled in the BIOS], here are the > relevant kernel config options (no, I didn't add anything else for sound > but this): > > [I read somewhere that the PCM driver doesn't support MIDI yet, not sure > if this is related] > > device pcm > device joy0at isa? port IO_GAME > > Adding the sbc driver into the config didn't help either, produced the > same dmesg output as above. > > I didn't use anything from the Voxware drivers like I used to under 3.x, I > also tried using the pnp directives for userconfig at boot time, but that > only produced syntax errors [same config I used for 3.x]: > > in /boot/kernel.conf: > > pnp 1 0 os enable irq0 5 drq0 1 drq1 5 port0 0x220 port1 0x330 port2 0x388 > pnp 1 1 os disable > pnp 1 2 os enable port0 0x620 port1 0xa20 port2 0xe20 > pnp 1 3 os disable > > devices in /dev: > > (sh MAKEDEV snd0) > > 0 lrwxrwxrwx 1 root wheel 6 Feb 24 02:05 /dev/mixer@ -> mixer0 > 0 crw-rw-rw- 1 root wheel 30, 0 Feb 24 02:05 /dev/mixer0 > 0 lrwxrwxrwx 1 root wheel10 Feb 24 02:05 /dev/sequencer@ -> > sequencer0 > 0 crw-rw-rw- 1 root wheel 30, 1 Feb 24 02:05 /dev/sequencer0 > 0 crw-rw-rw- 1 root wheel 30, 2 Feb 24 02:05 /dev/midi0 > 0 lrwxrwxrwx 1 root wheel 4 Feb 24 02:05 /dev/dsp@ -> dsp0 > 0 crw-rw-rw- 1 root wheel 30, 3 Mar 5 12:43 /dev/dsp0 > 0 lrwxrwxrwx 1 root wheel 5 Feb 24 02:05 /dev/dspW@ -> dspW0 > 0 crw-rw-rw- 1 root wheel 30, 5 Feb 24 02:05 /dev/dspW0 > 0 lrwxrwxrwx 1 root wheel 6 Feb 24 02:05 /dev/audio@ -> audio0 > 0 crw-rw-rw- 1 root wheel 30, 4 Feb 24 02:05 /dev/audio0 > 0 crw-rw-rw- 1 root wheel 30, 6 Feb 24 02:05 /dev/sndstat > 0 lrwxrwxrwx 1 root wheel 6 Feb 24 02:05 /dev/music@ -> music0 > 0 crw-rw-rw- 1 root wheel 30, 8 Feb 24 02:05 /dev/music0 > 0 lrwxrwxrwx 1 root wheel 4 Feb 24 02:05 /dev/pss@ -> pss0 > 0 crw-rw-rw- 1 root wheel 30, 9 Feb 24 02:05 /dev/pss0 > > /dev/sndstat reports: > > FreeBSD Audio Driver (newpcm) Mar 5 2000 12:00:51 > Installed devices: > pcm0: at io 0x220 irq 5 drq 1:5 (1p/1r channels duplex) > > And finally, a pnpinfo dump: > > Checking for Plug-n-Play devices... > > Card assigned CSN #1 > Vendor ID CTL00c3 (0xc3008c0e), Serial Number 0x1fa45429 > PnP Version 1.0, Vendor Version 16 > Device Description: Creative SB AWE64 PnP > *** Small Vendor Tag Detected > > Logical Device ID: CTL0045 0x45008c0e #0 > Device Description: Audio > TAG Start DF > Good Configuration > IRQ: 5 - only one type (true/edge) > DMA: channel(s) 1 > 8-bit, not a bus master, count by byte, , Compatibility mode > DMA: channel(s) 5 > 16-bit, not a bus master, , count by word, Compatibility mode > I/O Range 0x220 .. 0x220, alignment 0x1, len 0x10 > [16-bit addr] > I/O Range 0x330 .. 0x330, alignment 0x1, len 0x2 > [16-bit addr] > I/O Range 0x388 .. 0x388, alignment 0x1, len 0x4 > [16-bit addr] > TAG Start DF > Acceptable Configuration > IRQ: 5 7 9 10 - only one type
Re: openssh question
Warner Losh wrote: > > First, how does one enable TIS/SKEY authorization for ssh? It appears > that the frst step would be to add -DSKEY to the Makefile conditional > on something. Are there other steps? > Yes, there are other steps. openssh depends upon functions in the openbsd libskey that we do not have. These functions appear to have been added somewhere between our initial version of skey and openbsd's as they exist in openbsd's initial version, but not ours. The skey support in the openssh port has the exact same problems. That being said, if there is some demand for this, I could merge openbsd's libskey into ours and get the skey authentication working. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh strangeness in -current...
John Baldwin wrote: > > On 06-Mar-00 Kris Kennaway wrote: > > On Mon, 6 Mar 2000, Oliver Fromme wrote: > > > >> the ports (yeah, stupid me), to no avail. It complained about some > >> RSA library missing. > > > > Did you read the error message? Perhaps you should. Perhaps reporting it > > here would help someone to actually fix your problem instead of having to > > guess. > > I think you've kind of missed the point though, Kris. How many other people > are going to upgrade only to find that their previously working system is > now broken. We should at least mention this in UPDATING so people have a > ghost of a chance. > One possible source of breakage is not bringing over the existing server key. The key will need to be moved from /usr/local/etc to /etc/ssh. Did Warner include this with his changes to UPDATING about openssh in the base system (which I haven't seen yet). Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh strangeness in -current...
Warner Losh wrote: > + You will also need to enable openssh in /etc/rc.conf if you > + want to run the new servers. You may need to move your key > + and other config files from /usr/local/etc to /etc. Looks fine except config files go in /etc/ssh, not /etc. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in cvs ...
I am not seeing the problem with a standard build, but I am not building Kerberos. Looking at the makefiles, there is no mentioned of libRSAglue anyplace. The link command doesn't even imply the use of libRSAglue. Also, a buildworld should not be using libraries outside of the build environment. Don't bother building with MAKE_KERBEROS4=NO. All of the tests look at the variable being defined and not its value. You might try removing your object directory and doing a make cleandir twice to make sure nothing is left in source tree that shouldn't be there. Jim Bloom [EMAIL PROTECTED] Bush Doctor wrote: > > Out of da blue Kris Kennaway aka ([EMAIL PROTECTED]) said: > > On Thu, 9 Mar 2000, Bush Doctor wrote: > > > > > Is anyone else seeing this. cvsupped from 12:00 noon EST > > > > > > ... > > > > > > cc -O -pipe -I/usr/src/gnu/usr.bin/cvs/cvs -I/usr/src/gnu/usr.bin/cvs/cvs/../lib >-DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/cvs/cvs/../../../.. > > > /contrib/cvs/src -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib >-I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/diff -DHA > > > VE_KERBEROS -DHAVE_KRB_GET_ERR_TEXT -DENCRYPTION >-I/usr/obj/usr/src/i386/usr/include -o cvs add.o admin.o buffer.o checkin.o >checkout.o c > > > lassify.o client.o commit.o create_adm.o cvsrc.o diff.o edit.o entries.o error.o >expand_path.o fileattr.o filesubr.o find_names.o hardlink.o > > > hash.o history.o ignore.o import.o lock.o log.o login.o logmsg.o main.o >mkmodules.o modules.o myndbm.o no_diff.o parseinfo.o patch.o prepen > > > d_args.o rcs.o rcscmds.o recurse.o release.o remove.o repos.o root.o rtag.o >run.o scramble.o server.o status.o subr.o tag.o update.o vers_ts > > > .o version.o watch.o wrapper.o zlib.o >/usr/obj/usr/src/gnu/usr.bin/cvs/cvs/../lib/libcvs.a >/usr/obj/usr/src/gnu/usr.bin/cvs/cvs/../libdiff/ > > > libdiff.a -lgnuregex -lmd -lcrypt -lz -lkrb -lcrypto -lcom_err > > > /usr/lib/libRSAglue.so.1: undefined reference to `R_RandomUpdate' > > > > Did this come up as part of make world? It looks like you have a stale > > library. > It's occurring during a buildworld. If you're referring to libRSAglue > being stale it looks like that may be it. > > bantu.cl.msu.edu:dervish> ls -l /usr/lib/libR* > -r--r--r-- 1 root wheel 810 Feb 28 22:28 /usr/lib/libRSAglue.a > lrwxr-xr-x 1 root wheel 15 Jan 29 07:29 /usr/lib/libRSAglue.so -> >libRSAglue.so.1 > -r--r--r-- 1 root wheel5872 Jan 29 07:29 /usr/lib/libRSAglue.so.1 > -r--r--r-- 1 root wheel 868 Feb 28 22:28 /usr/lib/libRSAglue_p.a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More "ld-elf.so.1: assert failed" messages
NOTE: Take everything I say here as general info. I haven't used these thread packages, but have used others in the past. It should be called somewhere between the starting of the process and the creation of the second thread. There is no problem if there is only one thread. THREAD Create would be fine as long as it sets a variable accessible to all threads indicating dllockinit has been called. Another possible location would be a routine that initialize the multithreading for the process. This routine may not exist in all thread packages though. Jim Bloom [EMAIL PROTECTED] Juergen Lock wrote: > > In article <[EMAIL PROTECTED]> you write: > >In article <[EMAIL PROTECTED]>, > >Jordan K. Hubbard <[EMAIL PROTECTED]> wrote: > >> > The other possibility would be to fix the wine port so it calls > >> > dllockinit() to set up locking. I don't know for sure how hard that > >> > would be, but it's probably a feasible solution. > >> > >> To be honest, I'd be the most comfortable with this solution > > >... > >As far as I know, Wine is the only port that has problems with the > >version of the dynamic linker that's in -current at present. I've > >looked into adding the dllockinit() stuff to Wine, but could use > >some help from somebody who knows its internals better. > > Hm you could ask over in comp.emulators.ms-windows.wine... > > > I found > >the threads primitives, etc., but am not so sure where to place the > >dllockinit() call. > > When does it need to be called, just when starting a new thread? > (i have looked at the wine source before but never at ld-elf.so...) > And would this be the same on -stable and 4.0? Currently you > should be able to build a wine on a -stable box and it would still > run on 4.0 (well it wouldn't run _worse_ than on -stable), at least > thats the idea. > > Anyway if it should be called before a new thread becomes > runnable for the first the i think it could go in THREAD_Create > (in scheduler/thread.c), if it needs to be called from within > the new thread itself it looks like it should go in THREAD_Start > in the same source. > > HTH, > -- > Juergen Lock <[EMAIL PROTECTED]> > (remove dot foo from address to reply) > > 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: Feedback on 4.0-RC3 (mostly good! :)
John Reynolds wrote: > 1) There is a typo (spelling error) in one of the dialogs I was presented. I > was trying to force pilot error into the situation :) and got a dialog that > contained the following line: > > "You can also chose "No" at the next prompt and go back into the > installation menus to try and retry whichever operations failed." > > The word "chose" should be "choose." I'd supply a patch, but I only > installed kernel source :( > Also, this sentence should either have "try and" removed or replaced with "attempt to". Either of these is much better grammatically. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in cvs ...
Kris Kennaway wrote: > > On Thu, 9 Mar 2000, Bush Doctor wrote: > > > Again my libRSAglue libraries before the above were: > > bantu.cl.msu.edu:dervish> ls -l /usr/lib/libR* > > -r--r--r-- 1 root wheel 810 Feb 28 22:28 /usr/lib/libRSAglue.a > > lrwxr-xr-x 1 root wheel 15 Jan 29 07:29 /usr/lib/libRSAglue.so -> >libRSAglue.so.1 > > -r--r--r-- 1 root wheel5872 Jan 29 07:29 /usr/lib/libRSAglue.so.1 > > -r--r--r-- 1 root wheel 868 Feb 28 22:28 /usr/lib/libRSAglue_p.a > > This was very helpful - I've been able to replicate the problem by install > an old libRSAglue of this vintage. It still doesn't answer why on earth > make world is trying to link with it, but at least now I have something to > look at. Thanks! I looked into this problem a bit as well. I believe it is a build order and dependency problem that shouldn't exist. libkrb is built before libRSAglue and then the shared library is built with -LRSAglue which is only found in /usr/lib. kerberosIV/Makefile.inc has a line "LDADD+= -LRSAglue". This whole issue should not exist simply because libRSAglue is a dummy stub and there is no reson to link anything against it. The quick fix is to remove libRSAglue from the makefiles where it is used. The following makefiles need to have the references to RSAglue removed: usr.sbin/ppp/Makefile usr.sbin/pppd/Makefile secure/libexec/sshd/Makefile kerberosIV/Makefile.inc I don't know how to change ld (compile time?) so that it doesn't look in the standard locations for files during buildworld. That is what is required to guarantee this problem doesn't happen again. Kris, would you like patches or will you edit these yourself? Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in cvs ...
Jim Bloom wrote: > > The > following makefiles need to have the references to RSAglue removed: > > usr.sbin/ppp/Makefile > usr.sbin/pppd/Makefile > secure/libexec/sshd/Makefile > kerberosIV/Makefile.inc > Ignore secure/libexec/sshd/Makefile. That was left over from when I was trying to integrate OpenSSH into the base system before Mark's work was included. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sound driver
Ron 'The InSaNe One' Rosson wrote: > > I am running CURRENT as of last week. I seem to be only able to get my > sound to work when I use: > option PNPBIOS > device pcm0 > > Here is the dmesg output: > > unknown9: at port 0x800-0x807 on isa0 > sbc0: at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq > 1,5 on isa0 > pcm0: on sbc0 > unknown10: at port 0x201 on isa0 > > I would like to get rid of all the unknowns caused by the PNPBIOS > option. If anyone has any ideas I am game to try. Try adding "device joy" to your configuration file. The ESS0001 looks like a game/joystick port. Someone might need to add device ID to the driver though. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0R ?
The tag was laid down earlier today. Here is what my current kernel claims to be at the moment: FreeBSD 5.0-CURRENT #31: Mon Mar 13 10:59:41 EST 2000 Actually, there might be a couple fixes slipped in between now and the release, but 4.0R exists. You may cvsup with the tag RELENG_4 now if you like. Jim Bloom [EMAIL PROTECTED] Mike Tancsa wrote: > > I do follow current, but I must be blind if I missed it. What is the > latest date for 4.0R ? Will there be instead another Release Candidate and > more testing ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world: install-info: unrecognized option
Please read UPDATING for details on how to upgrade to 4.0 from earlier releases. The quick summary to deal with your problem is: make -DNOINFO installworld make installworld There are other problems you might bump into, so do your homework first. Jim Bloom [EMAIL PROTECTED] Rasmus Skaarup wrote: > > Hiya, > > I just cvsupped a couple of hours ago, after a successful build, the > install phase fails: > > ** snip snip ** > ===> lib/libcom_err/doc > install-info --quiet --defsection="Programming & development > tools." --defentry="* libcom_err: (com_err).A Common Error > Description Library for UNIX." com_err.info /usr/share/info/dir > install-info: unrecognized option `--defsection=Programming & development > tools.' > Try `install-info --help' for a complete list of options. > *** Error code 1 > > Stop. > > ** snip snip ** > > I'm running 3.4-STABLE, trying to cvsup to cvs-tag RELENG_4. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CMD640 and ATA drivers
And I have three machines which I was trying to use for testing -current and my firewall. These machines all have either a CMD640 or an RZ100 controller on the motherboard. (They seemed to be popular with the early Pentium machines.) The controllers seem reliable enough to use for extended periods as test machines. If it gets trashed because of a controller bug, I can simply reinstall and only lose the install time. I upgraded my firewall to an old Adaptec SCSI controller, but I don't care about data integrity on the other machines. Unfortunately, none of them are usable at the moment because of various bugs (panics on boot, not probing the hard drive, etc.). Jim Bloom [EMAIL PROTECTED] Soren Schmidt wrote: > > It worked until the latest newbus changes, I'm looking at it, but havn't > found anything obvious yet. > But seriously you want to get another ATA interface, the CMD640 is > _broken_ and no software can help that, you are playing russian > roulette with your data. Get a promise, abit or siig controller > and use that instead... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: possible simple install-info fix
Don't forget to test the case of cross platform installs. You can build on one
platform and install on another with the mounts having the target mounted on the
build machine or the source and object mounted on the target machine after the
build was done on a different architecture.
I believe this patch will not work in all cases. Maybe Marcel can shed some
more light on this issue.
Jim Bloom
[EMAIL PROTECTED]
Neil Blakey-Milner wrote:
>
> Hi,
>
> I was looking into fixing the install-info problem, and wondered if the
> solution is really as easy as it seems:
>
> cvs diff: Diffing src
> Index: src/Makefile.inc1
> ===
> RCS file: /home/ncvs/src/Makefile.inc1,v
> retrieving revision 1.141
> diff -u -r1.141 Makefile.inc1
> --- Makefile.inc1 2000/03/09 06:28:19 1.141
> +++ Makefile.inc1 2000/03/15 15:34:25
> @@ -183,7 +183,7 @@
> WMAKE= ${WMAKEENV} ${MAKE} -f Makefile.inc1
>
> # install stage
> -IMAKEENV= ${CROSSENV}
> +IMAKEENV= ${CROSSENV} INSTALLINFO="${WORLDTMP}/usr/bin/install-info"
> IMAKE= ${IMAKEENV} ${MAKE} -f Makefile.inc1
>
> USRDIRS= usr/bin usr/lib/compat/aout usr/games usr/libdata/ldscripts \
>
> I've done an installworld between -CURRENTs (where we wouldn't
> encounter the problem anyway) and it used the correct install-info.
>
> If anyone is willing to test an upgrade from 3.4 -> 4.0 with this
> fix, I'd appreciate it. Otherwise, I'll do it tomorrow.
>
> If we happen to slide tags and make a new release, this'd be great
> for cvsup upgrade path to the release.
>
> Neil
> --
> Neil Blakey-Milner
> [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: HEADS UP: sigset_t changes committed
I believe this must be fixed. At some point in time, there is going to be another change to the kernel such that some older version of the code cannot run on a new kernel. I believe this situation has occurred before. This will lead to a situation where a new kernel is required before the build and a new build is required before the new kernel is installed. We cannot have this paradox. Jim Bloom [EMAIL PROTECTED] Doug wrote: > > On Thu, 30 Sep 1999, Harold Gutch wrote: > > > Uhm, that's the way I see it being _right now_ as well. What I > > was thinking of, was that things would go smoother if you > > wouldn't upgrade _right now_, but in [insert some time in the > > near future here], as things would perhaps be "fixed" by then. > > There is no fix to make. If the binaries built by the current > sources cannot run unless the sigset_t stuff is in the kernel of the > machine that they are running on this problem will never be "fixed." > > Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup core dumps
My machine is dual boot and I don't have time to reboot now. (I need to get some sleep.) I'll provide what information I can quickly and will test things further tomorrow evening. I was seeing the core dumps from gui cvsup. My current was a couple different cvsup runs on Saturday and Sunday. I am using the static binary installed from the ports collection. I don't have a date or version right now, but seem to recall it being 16.0. As others have mentioned, running cvsup under truss works. I'll let you know more tomorrow night if there is anything I can add. Jim Bloom [EMAIL PROTECTED] John Polstra wrote: > > I've seen a few reports that CVSup has suddenly started dumping > core on a segmentation violation under -current, but I need more > information. For starters, I would like to know whether the static > binary (ports/net/cvsup-bin) works or not under the very latest > -current on the i386. Could somebody please check that and report > back to the list? I can't sacrifice my i386 -current machine to the > cause right now. > > Also, for those of you who are experiencing problems: Please state > as precisely as possible: > > - which vintage of -current are you running? > - what is the output from "cvsup -v"? > - is "cvsup" a static binary or is it dynamically linked? > - did you build it, or did you simply install a binary? > - if you built it, when did you build it? > > Note, you are going to have trouble getting much out of the core dumps > from the binaries, because they're a.out. I've placed an unstripped > ELF binary here if you'd like to help out by getting a stack trace: > > http://www.freebsd.org/~jdp/cvsup-16.0.gz > > The compressed file is about 2.3 MB in size. > > John > -- > John Polstra [EMAIL PROTECTED] > John D. Polstra & Co., Inc.Seattle, Washington USA > "No matter how cynical I get, I just can't keep up."-- Nora Ephron > > 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: Still waiting for xl driver reports
I keep seeing a watchdog timeout with my 3c905B-TX every time the machine boots. It seems to occur after everything has been probed and /etc/rc has completed; around the time I get my login banner. I am running the dhcp client to get my IP address. I don't pound on the network very much so I can't tell you how performance is. Jim Bloom Pierre Beyssac wrote: > > On Sun, Oct 10, 1999 at 04:59:34PM -0400, Bill Paul wrote: > > A while back I posted a message here saying that I'd changed the xl driver > > a bit to hopefully improve performance for 3c90xB and later adapters (i.e. > > the "cyclone," "hurricane" and "tornado" chipsets). I asked for people > > to report if the changes helped, hurt, made no difference or were totally > > broken. > > > > So far not one person has said so much as a word to me on this subject. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld hung up with lots of cron processes
cvsup again. You want to get version 1.134 of sys/vm/swap_pager.c. The fix for your problem was committed 4.5 hours later. Good luck trying to compile the kernel. I had hangs while linking the kernel as well as while trying to install a fixed one. Make sure you have a good backup of the kernel, I ended up with a zero byte kernel while trying to install the fixed one. Jim Bloom [EMAIL PROTECTED] Bob Bishop wrote: > > Hi, > > cvsup at Wed Mar 22 04:03:28 GMT 2000, this built without problems with -j8 > on my SMP box, but on a uniprocessor (-j4, eveything else the same) > something appears to have deadlocked. The machine is generally OK but the > build has hung and there are 57 cron processes hanging around (ps ax > follows). Any ideas? I'll keep it hanging around for a bit, let me know if > you want more info. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fd0: Debugger("d_iocmd botch") called.
Upgrade sys/vm/swap_pager.c to the current version. There was a bug there which
has been fixed.
Jim Bloom
[EMAIL PROTECTED]
FreeBSD mailing list wrote:
>
>
> /var/log/messages indicates:
> Mar 23 23:32:47 mrynet /kernel: Debugger("d_iocmd botch") called.
> Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0
>40 ST1 4 ST2 0
> cyl 0 hd 0 sec 2)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fd0: Debugger("d_iocmd botch") called.
I reproduced the problem and have attached a patch. It was the exact same problem as in swap_pager.c (assuming B_WRITE was 0). Hopefully phk will commit this fix shortly. Jim Bloom [EMAIL PROTECTED] \ FreeBSD mailing list wrote: > > I cvsup'd once more this morning... Nothing significant has changed since the > last one. > > For reference: > ttyp9:staylor@mrynet (4): grep \$FreeBSD /sys/vm/swap_pager.c > * $FreeBSD: src/sys/vm/swap_pager.c,v 1.134 2000/03/22 08:40:13 phk Exp $ > > Nonetheless, I built a new kernel using "config -r". No change in floppy operation. Index: sys/isa/fd.c === RCS file: /users/ncvs/src/sys/isa/fd.c,v retrieving revision 1.179 diff -u -r1.179 fd.c --- sys/isa/fd.c2000/03/20 11:28:39 1.179 +++ sys/isa/fd.c2000/03/24 20:20:53 @@ -2228,6 +2228,7 @@ BUF_LOCKINIT(bp); BUF_LOCK(bp, LK_EXCLUSIVE); bp->b_flags = B_PHYS | B_FORMAT; + bp->b_iocmd = BIO_WRITE; /* * calculate a fake blkno, so fdstrategy() would initiate a
Re: fd0: Debugger("d_iocmd botch") called.
FreeBSD mailing list wrote: > > This patch does indeed fix the writing of floppies. However, fdformat(1) > still fails as follows: That is very strange. My patch only applies to formatting floppies. It did not touch any routine used in writing a floppy. I have no idea at this time what is causing your other problems. I am unable to write to a floppy at this time. I'm not seeing any errors, but nothings is getting written. Jim Bloom [EMAIL PROTECTED] > > ttyp7:--ROOT--@mrynet (22): fdformat -f 1440 fd0.1440 > Format 1440K floppy `/dev/fd0.1440'? (y/n): y > Processing EE^C > > with /var/log/messages indicating: > Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 >40 ST1 4 ST2 0 > cyl 0 hd 0 sec 2) > Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 >40 ST1 4 ST2 0 > cyl 0 hd 0 sec 2) > Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 >44 ST1 > 4 ST2 0 cyl 0 hd 1 sec 2) > Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 >44 ST1 > 4 ST2 0 cyl 0 hd 1 sec 2) > Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 >40 ST1 4 ST2 0 > cyl 1 hd 0 sec 2) > Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 >40 ST1 4 ST2 0 > cyl 1 hd 0 sec 2) > (and continuing). > > Additionally, reading a floppy returns errors for any read: > (This is a freshly formatted floppy verified on other machines) > > ttyp7:--ROOT--@mrynet (7): dd if=/dev/rfd0.1440 | wc > dd: /dev/rfd0.1440: Input/output error > 0+0 records in > 0+0 records out > 0 bytes transferred in 2.395566 secs (0 bytes/sec) >0 0 0 > > with /var/log/messages indicating: > Mar 24 14:04:28 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40 ST1 >4 ST2 0 cyl 0 hd 0 > sec 2) > Mar 24 14:04:38 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40 ST1 >4 ST2 0 cyl 0 hd 0 > sec 2) > > Thanks, > -scott > -- > Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] > MRY Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA library problems
A similar patch was added for the USA version of RSA for the same basic reason. Your patch is almost correct. It should add the line: LDADD+= -L$[.OBJDIR]/../libcrypto -lcrypto Your version would reference the system crypto library and not the one being built as part of buildworld. Jim Bloom [EMAIL PROTECTED] Dirk Roehrdanz wrote: > > I had the same problem. "BN_mod_exp_mont" is in libcrypto,but isn't > visible from librsaINTL.so because libcrypto is loaded in conjunction > with the load of /usr/local/libexec/apache/libssl.so via dlopen() . > The man page to dlopen states " The symbols exported by objects added > to the address space by dlopen() can be accessed only through calls > to dlsym()". > I have solved the problem with the attached patch. It adds libcrypto > to the list of linked libs. > Maybe there is a better solution,who knows ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA library problems
Dirk Roehrdanz wrote:
>
> Thanks for the modification.
> I have replaced the "[]" with "{}" . A run of "make buildworld" with
> the patch finished without errors.
Sorry about that. I did it quickly and the font I was using has the characters
looking identical. Time to change fonts :-)
> The output of objdump --private-headers on the created librsaINTL.so.1
> libs under /usr/obj contains now the line "NEEDED libcrypto.so.1".
> Apache-modssl works now with encryption!
Good news. I was sure that would fix the problem.
>
> Should I file a pr with the patch ?
If you like. Hopefully someone will pick it up from the list sooner and commit
the patch. send-pr is the official channel for reporting bugs.
Jim Bloom
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patchkits: Was :Re: SMP changes and breaking kld object modulecompatibility
The RCS info stored in the binaries is insufficient for this purpose. There is no record of the versions of all included files. Changes to constants and/or macros would not be identifiable. Jim Bloom [EMAIL PROTECTED] Kris Kennaway wrote: > > On Tue, 25 Apr 2000, Brandon D. Valentine wrote: > > > The only way something like this is feasible is if the binaries > > themselves contain information about what version they are. In other > > words some sort of a header in the binary which contains the RCS version > > number the binary was compiled from so that whatever method you were > > You've never run ident(1), right? :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems building kernel with IPSEC_DEBUG
While compiling a kernel with recent code (cvsup 22:30 -0400 July 6), I had some undefined symbols. I traced the symbols to netkey/key_debug.c and found that it did not test IPSEC_DEBUG correctly. I have attached a patch below. Jim Bloom [EMAIL PROTECTED] Index: netkey/key_debug.c === RCS file: /users/ncvs/src/sys/netkey/key_debug.c,v retrieving revision 1.11 diff -u -r1.11 key_debug.c --- netkey/key_debug.c 2000/07/04 16:35:14 1.11 +++ netkey/key_debug.c 2000/07/07 03:26:30 @@ -33,6 +33,7 @@ #ifdef _KERNEL #include "opt_inet.h" #include "opt_inet6.h" +#include "opt_ipsec.h" #endif #include To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-20000706-SNAP boot floppy failure
This may or may not be related... A week ago, I tried to boot using the 0702 snapshot floppies and had problems as well. The error I received was something like "Can't open md1". This was after probing all of the devices, but before the install menu came up. Sorry if I don't have better details, but I was in a hurry to get things working and grabbed the 0602 snapshot which worked fine. I didn't record any of the details at that time. Jim Bloom [EMAIL PROTECTED] John DeBoskey wrote: > > Hi, > >In case anyone else it seeing this yet, or possibly > working on it, the 0706 snap boot floppy boots up > into sysinstall and then hangs. > >Switching to the debug screen yields: > > DEBUG: ioctl(3, TIOCCONS, NULL) = 0 (success) > DEBUG: Can't open PC-card controller /dev/card0. > >and that's it. > >I'll try to take a look at this later this evenning, or > in the morning. Any comments are appreciated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_event.c
I am having problems with "tail -f" hanging the machine. I don't know if this change is related, but I suspect that it might be. I commonly do a "tail -f" of my log file while doing a buildworld. As soon as I interrupted the tail, the machine hung. I then tried to figure out what was causing the problem. Eventually, I tracked the problem down to tail. The machine would respond to pings, but the keyboard was useless. It would not shutdown as well. One test I tried was to run tail -f under truss. This actually kept the machine somewhat usable. Top showed truss using 75% of the CPU and tail using the other 25%. System time was running over 80%. Truss reported that tail kept receiving the signal (indefinitely as far as I could tell) at a high rate of speed. I tried to get a kernel core dump several times by breaking into ddb, but I never had any luck. Here is the backtrace copied by hand: vec1(c0f8d540,1,bfbffa9c,0,c81b76c0) at vec1+0x2 kevent(c81b76c0,c8bd1f80,280f6b40,4,4) at kevent+0x152 syscall2(2f,2f,2f,4,4) at syscall2+0x1f1 Xinit0x80_syscall() at Xint0x80_syscall+0x25 My kernel and source tree both date from 20:00-22:00 EDT on July 28. I found the problem to be quite repeatable by simply going "tail -f file" (the file does not need to change) and then hitting an interrupt on the keyboard. Let me know if I can be of any assistance in tracking this problem down. I might try to spend some time tomorrow figuring out what is happening. Jim Bloom [EMAIL PROTECTED] Jonathan Lemon wrote: > > jlemon 2000/07/27 16:06:15 PDT > > Modified files: > sys/kern kern_event.c > Log: > Have kevent() automatically restart if interrupted by a signal. If this > is not desired, then the user can register an EV_SIGNAL filter to > explicitly catch a signal event. > > Change requested by: jayanth, ps, peter > "Why is kevent non-restartable after a signal?" > > Revision ChangesPath > 1.12 +3 -6 src/sys/kern/kern_event.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: keyboard problems with X
To resolve the problem with tail, rebuild your kernel with revision 1.11 of sys/kern/kern_event.c. 1.12 which was designed to make the kevent system restartable seems to keep the process from ever receiving the interrupt. I don't have a solution which solves both problems yet. Jim Bloom [EMAIL PROTECTED] Kenneth Wayne Culver wrote: > > I have, like when I'm running tail on something, and then I try to ctrl-c > out of it, the whole console locks solid, and I have to reboot. (although > if I was connected to an ethernet, I think I could probably ssh in and > reboot.) Also, as an unrelated problem in -CURRENT, I'm experiencing the > lockmgr problems that were reported earlier. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_event.c
I didn't have much time for testing, but backing out this change fixes the problem tail. For some reason, the signal never gets delivered to the process. The manual page states that the kevent processing is lower priority than signal handling and that the signal will get processed as normal before the event will will be logged. In fact, I witnessed a case where a SIGKILL would not kill the process after a SIGINT. Jim Bloom [EMAIL PROTECTED] Jim Bloom wrote: > > I am having problems with "tail -f" hanging the machine. I don't know if this > change is related, but I suspect that it might be. > > I commonly do a "tail -f" of my log file while doing a buildworld. As soon as I > interrupted the tail, the machine hung. I then tried to figure out what was > causing the problem. Eventually, I tracked the problem down to tail. The > machine would respond to pings, but the keyboard was useless. It would not > shutdown as well. One test I tried was to run tail -f under truss. This > actually kept the machine somewhat usable. Top showed truss using 75% of the > CPU and tail using the other 25%. System time was running over 80%. Truss > reported that tail kept receiving the signal (indefinitely as far as I could > tell) at a high rate of speed. > > I tried to get a kernel core dump several times by breaking into ddb, but I > never had any luck. Here is the backtrace copied by hand: > > vec1(c0f8d540,1,bfbffa9c,0,c81b76c0) at vec1+0x2 > kevent(c81b76c0,c8bd1f80,280f6b40,4,4) at kevent+0x152 > syscall2(2f,2f,2f,4,4) at syscall2+0x1f1 > Xinit0x80_syscall() at Xint0x80_syscall+0x25 > > My kernel and source tree both date from 20:00-22:00 EDT on July 28. > > I found the problem to be quite repeatable by simply going "tail -f file" (the > file does not need to change) and then hitting an interrupt on the keyboard. > > Let me know if I can be of any assistance in tracking this problem down. I > might try to spend some time tomorrow figuring out what is happening. > > Jim Bloom > [EMAIL PROTECTED] > > Jonathan Lemon wrote: > > > > jlemon 2000/07/27 16:06:15 PDT > > > > Modified files: > > sys/kern kern_event.c > > Log: > > Have kevent() automatically restart if interrupted by a signal. If this > > is not desired, then the user can register an EV_SIGNAL filter to > > explicitly catch a signal event. > > > > Change requested by: jayanth, ps, peter > > "Why is kevent non-restartable after a signal?" > > > > Revision ChangesPath > > 1.12 +3 -6 src/sys/kern/kern_event.c > > 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: cvs commit: src/sys/kern kern_event.c
I did a little more testing of this problem just now. A SIGKILL does not kill the process but will lock up the machine. Truss reports the SIGKILL being continuously sent to the process. If I break into DDB, and then panic, I get a panic "lockmgr: pid XXX, not exclusive lock holder 0 unlocking". The pid is for the tail command. Jim Bloom [EMAIL PROTECTED] Jim Bloom wrote: > > I didn't have much time for testing, but backing out this change fixes the > problem tail. For some reason, the signal never gets delivered to the process. > The manual page states that the kevent processing is lower priority than signal > handling and that the signal will get processed as normal before the event will > will be logged. > > In fact, I witnessed a case where a SIGKILL would not kill the process after a > SIGINT. > > Jim Bloom > [EMAIL PROTECTED] > > Jim Bloom wrote: > > > > I am having problems with "tail -f" hanging the machine. I don't know if this > > change is related, but I suspect that it might be. > > > > I commonly do a "tail -f" of my log file while doing a buildworld. As soon as I > > interrupted the tail, the machine hung. I then tried to figure out what was > > causing the problem. Eventually, I tracked the problem down to tail. The > > machine would respond to pings, but the keyboard was useless. It would not > > shutdown as well. One test I tried was to run tail -f under truss. This > > actually kept the machine somewhat usable. Top showed truss using 75% of the > > CPU and tail using the other 25%. System time was running over 80%. Truss > > reported that tail kept receiving the signal (indefinitely as far as I could > > tell) at a high rate of speed. > > > > I tried to get a kernel core dump several times by breaking into ddb, but I > > never had any luck. Here is the backtrace copied by hand: > > > > vec1(c0f8d540,1,bfbffa9c,0,c81b76c0) at vec1+0x2 > > kevent(c81b76c0,c8bd1f80,280f6b40,4,4) at kevent+0x152 > > syscall2(2f,2f,2f,4,4) at syscall2+0x1f1 > > Xinit0x80_syscall() at Xint0x80_syscall+0x25 > > > > My kernel and source tree both date from 20:00-22:00 EDT on July 28. > > > > I found the problem to be quite repeatable by simply going "tail -f file" (the > > file does not need to change) and then hitting an interrupt on the keyboard. > > > > Let me know if I can be of any assistance in tracking this problem down. I > > might try to spend some time tomorrow figuring out what is happening. > > > > Jim Bloom > > [EMAIL PROTECTED] > > > > Jonathan Lemon wrote: > > > > > > jlemon 2000/07/27 16:06:15 PDT > > > > > > Modified files: > > > sys/kern kern_event.c > > > Log: > > > Have kevent() automatically restart if interrupted by a signal. If this > > > is not desired, then the user can register an EV_SIGNAL filter to > > > explicitly catch a signal event. > > > > > > Change requested by: jayanth, ps, peter > > > "Why is kevent non-restartable after a signal?" > > > > > > Revision ChangesPath > > > 1.12 +3 -6 src/sys/kern/kern_event.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Possible bug in current?
Fixed with revision 1.14 sys/kern/kern_event.c. Update your kernel sources and the problem should go away. Jim Bloom [EMAIL PROTECTED] "Damon M. Conway" wrote: > > Damon Hammis wrote: > >Has anyone else stumbled across this bug in 5.0-CURRENT? Whenever I try > >to do a tail -f on a text file the system locks up and requires a hard > >reboot. > > > >Anyone else see anything similar? > > yes, there is a long discussion on -current about it right now. > > damon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PC Card hang
My laptop is hanging when I boot it after this commit. The system hangs when pccardd is started. If no cards are installed, the boot proceeds without a problem and the system hangs when the first card is inserted. I have attached my kernel configuration and dmesg output from a kernel checked out right before this commit. Please let me know if I can provide any further information or assistance. Thanks for you help Jim Bloom [EMAIL PROTECTED] Modified files: sys/pccard i82365.h pcic.c pcic_isa.c pcic_pci.c Log: o Try to do 3.3V support better for the 6722 and 6729/30. o Bite the bullet and create controller types for the 6729 and also for the 673x. Rename the 672x to 6722. o Define minimal extended register info (just register 0xa for reading VS[12]). # I think the last version may have broken 673x controllers, but this should # fix them. Tested on the 6722, but not the 6729. Ideas from: Chiharu Shibata-san's article in bsd-nomads:15866 Revision ChangesPath 1.23 +18 -5 src/sys/pccard/i82365.h 1.169 +32 -14src/sys/pccard/pcic.c 1.23 +3 -3 src/sys/pccard/pcic_isa.c 1.106 +5 -5 src/sys/pccard/pcic_pci.c machine i386 cpu I486_CPU cpu I586_CPU ident LAPTOP maxusers32 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INVARIANTS options INVARIANT_SUPPORT # options MUTEX_DEBUG options WITNESS options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG #debug for IP security options FFS #Berkeley Fast Filesystem options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console #optionsUSERCONFIG #boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extentions options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options IPFIREWALL #firewall options IPDIVERT#divert sockets options DDB #kernel debugger # Obsolete option # options MD_NSECT=1 device isa # Add PCI to work around broken ATA driver # devicepci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc device atkbd device psm device vga # syscons is the default console driver, resembling an SCO console device sc # Floating point support - do not disable. device npx # Power management support (see LINT for more options) device apm # Advanced Power Management # PCCARD (PCMCIA) support device card device pcic # Serial (COM) ports device sio # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi # Parallel port interface device # ISA Ethernet NICs. device ed device miibus # Pseudo devices - the number indicates how many units to allocated. device loop# Network loopback device ether # Ethernet support device sl 1 # Kernel SLIP device ppp 1 # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device pmtimer # Adjust system timer at wakeup time device random # for IPv6 device gif #IPv6 and IPv4 tunneling device faith #for IPv6 and IPv4 translation # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabli
Re: PC Card hang
A later kernel (possibly today's source) say that it is a 6722 instead of a 672x. Other changes in the dmesg output (copied by hand since the machine does not survive) are : pcic0: Autodected 3.3V card (once per card) pcic0: reset 1 int is 0 stat is cc (once per card, stat was df or ff before) pcic0: reset 2 int is 60 stat is cc pcic0: reset 3 int is 60 stat is cc The machine is an old AST Ascentia 810N. Jim Warner Losh wrote: > > In message <[EMAIL PROTECTED]> Jim Bloom writes: > : I have attached my kernel configuration and dmesg output from a kernel > : checked out right before this commit. Please let me know if I can > : provide any further information or assistance. > > What does one from right after say? It looks like you have a CLPD6722 > in your machine... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PC Card hang
I haven't built a new kernel since I had got it working (by fetching the version before the commit). I haven't noticed any commits that might have been related to fixing this but I'm a couple weeks behind on reading cvs-all. Jim Bloom "M. Warner Losh" wrote: > > From: Jim Bloom <[EMAIL PROTECTED]> > Subject: PC Card hang > Date: Tue, 27 Nov 2001 19:26:04 -0500 > > : My laptop is hanging when I boot it after this commit. The system hangs > : when pccardd is started. If no cards are installed, the boot proceeds > : without a problem and the system hangs when the first card is inserted. > ... > > : Modified files: > : sys/pccard i82365.h pcic.c pcic_isa.c pcic_pci.c > : Log: > : o Try to do 3.3V support better for the 6722 and 6729/30. > : o Bite the bullet and create controller types for the 6729 and also > ... > : Revision ChangesPath > : 1.23 +18 -5 src/sys/pccard/i82365.h > : 1.169 +32 -14src/sys/pccard/pcic.c > : 1.23 +3 -3 src/sys/pccard/pcic_isa.c > : 1.106 +5 -5 src/sys/pccard/pcic_pci.c > > Did this get resolved? > > Warner > > 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: PC Card hang
The chipset is reported as a 6722 by the newer kernels that do not work. I will forward the earlier e-mails to you. Jim Bloom "M. Warner Losh" wrote: > > OK. I'll keep that in mind. I'm in a bit if a time crunch until > after the first of the year. I can't seem to find where you told me > which bridge chipset you were using. Presumably it is a 6729/6730? > > Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build failure
Did you add "device miibus" to you kernel configuration? Jim Bloom [EMAIL PROTECTED] Paul Allenby wrote: > > Hi all > > >From sources cvsup'd about an hour ago, "make depend" complains: > > ../../dev/ed/if_ed_pccard.c:58: miibus_if.h: No such file or directory > > and fails. This is after deleting the old kernel build dir. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel link problems with ata driver
For the past couple weeks I have been unable to build a kernel for my laptop. I keep getting undefined symbols. The problem started with the split of the ata driver by different bus attachments. My laptop only has ISA and not PCI so I don't include PCI in the kernel config file. The errors and kernel configuration are included below. Jim Bloom [EMAIL PROTECTED] linking kernel ata-all.o: In function `ata_service': ata-all.o(.text+0x1332): undefined reference to `ata_dmastatus' ata-all.o: In function `ata_change_mode': ata-all.o(.text+0x1dc1): undefined reference to `ata_dmainit' ata-disk.o: In function `ad_attach': ata-disk.o(.text+0x36c): undefined reference to `ata_dmainit' ata-disk.o(.text+0x39d): undefined reference to `ata_dmainit' ata-disk.o: In function `ad_start': ata-disk.o(.text+0xa14): undefined reference to `ata_dmaalloc' ata-disk.o: In function `ad_transfer': ata-disk.o(.text+0xbf4): undefined reference to `ata_dmasetup' ata-disk.o(.text+0xd14): undefined reference to `ata_dmastart' ata-disk.o: In function `ad_interrupt': ata-disk.o(.text+0xf13): undefined reference to `ata_dmadone' ata-disk.o(.text+0x1029): undefined reference to `ata_dmainit' ata-disk.o(.text+0x1092): undefined reference to `ata_dmainit' ata-disk.o: In function `ad_service': ata-disk.o(.text+0x1518): undefined reference to `ata_dmastart' ata-disk.o: In function `ad_timeout': ata-disk.o(.text+0x177f): undefined reference to `ata_dmadone' ata-disk.o(.text+0x17b8): undefined reference to `ata_dmainit' ata-disk.o: In function `ad_reinit': ata-disk.o(.text+0x18fe): undefined reference to `ata_dmainit' ata-disk.o(.text+0x1929): undefined reference to `ata_dmainit' *** Error code 1 machine i386 cpu I486_CPU cpu I586_CPU ident LAPTOP maxusers32 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INVARIANTS options INVARIANT_SUPPORT # options MUTEX_DEBUG options WITNESS options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG #debug for IP security options FFS #Berkeley Fast Filesystem options MFS #Memory Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extentions options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options IPFIREWALL #firewall options IPDIVERT#divert sockets options DDB #kernel debugger # Obsolete option # options MD_NSECT=1 device isa # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc device atkbd device psm device vga # syscons is the default console driver, resembling an SCO console device sc # Floating point support - do not disable. device npx # Power management support (see LINT for more options) device apm # Advanced Power Management # PCCARD (PCMCIA) support device card device pcic # Serial (COM) ports device sio # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi # Parallel port interface device # ISA Ethernet NICs. device ed device miibus # Pseudo devices - the number indicates how many units to allocated. device loop# Network loopback device ether # Ethernet support device sl 1 # Kernel SLIP de
Re: panic: resource_list_alloc
Try "make reinstall". I have been doing quite a bit of this since my kernel panics before it ever gets all the way up. The last good kernel I have is about a month old. Actually, I moved /boot/kernel.old to another name in case I accidentally did an install instead of a reinstall. I don't want to leave my machine unable to boot. Jim Bloom [EMAIL PROTECTED] The Hermit Hacker wrote: > > doing so right now ... one quick/stupid question ... how does one > 'reinstall' a new kernel so that you don't lose the /boot/kernel.old (aka > backup that worked)? I've been moving files around before installing the > rebuilt kernel, but that doesn't sound very efficient ... :) > > thanks .. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: midi causes panic on boot? (update)
I get a slightly different backtrace, but was able to use my palm pilot as the
serial console. I have had this same problem for quit a while (about a month).
I suspect a locking issue related to Seigo Tanimura's commit on Feb 25. My last
cvsup was within the past 24 hours and the kernel was built in a clean
directory.
I can try to get more information if necessary.
Jim Bloom
[EMAIL PROTECTED]
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1a0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01c8006
stack pointer = 0x10:0xc04e66dc
frame pointer = 0x10:0xc04e66db>
trace
_mtx_lock_sleep(c0ecda08,0,c036d471,268) at _mtx_lock_sleep+0x29a
mpu_uartmode(c0ecda00) at mpu_uartmode+0x63
mpu_attach(c0ebd100,c0ebd100,c0ebd100,c0e67080,c04e675c) at mpu_attach+0x25
mpusbc_attach(c0ebd100,c0ebd100,c0ea5ac0,c036e926,1) at mpusbc_attach+0x19
device_probe_and_attach(c0ebd100) at device_probe_and_attach+0x9a
bus_generic_attach(c0ea2000,c0ebd080,c0ea5ac0,c0ea2000,c036e935) at
bus_generic_attach+0x16
sbc_attach(c0ea2000,c0eadb00,c0ea2000,7,0) at sbc_attach+0x3cc
device_probe_and_attach(c0ea2000,c0404c4c,c03f9030,4eb000,c0eadb00) at
device_probe_and_attach+0x9a
isa_probe_children(c0ea2980,c04e6ff8,c01b1f74,0,4e4c00) at
isa_probe_children+0x143
configure(0,4e4c00,4e4000,0,c01277d2) at configure+0x39
mi_startup() at mi_startup+0x68
begin() at begin+0x29
db> panic
panic: from debugger
Debugger("panic")
Stopped at _mtx_lock_sleep+0x29a: movl0x1a0(%edx),%eax
Szilveszter Adam wrote:
>
> Hello folks,
>
> I have tried it with today's -CURRENT, and as soon as I try to boot a
> kernel with the options (this has occured also earlier but wanted to make
> sure that I try today's sources first)
>
> device midi
> device seq
>
> (my sound card is a ISAPnP SB 64 AWE)
>
> I use device sbc too.
>
> the kernel still panics with Fatal Trap 12. I have Seigo Tanimura's
> fixes, and yet this still happens. I do not have a serial console, so here
> a short trace output transcribed:
>
> _mtx_lock_sleep
> mpu_uartmode
> mpu_attach
> mprobe_attach
> device_probe_and_attach
> bus_generic_attach
> sbc_attach
> device_probe_and_attach
> isa_probe_children
> configure
> mi_startup()
> begin()
>
> At the point of panic not even the swap partition is available yet so the
> machine does not dump. How can I force it?
>
> I would like to offer any and all help to anyone wanting to debug this; I
> can reproduce the problem at will and luckily no FS corruption occurs
> because the panic is so early on boot.:-)
>
> Of course, as soon as I omit the midi part, the kernel boots fine, and the
> sound card works too.
> --
> Regards:
>
> Szilveszter ADAM
> Szeged University
> Szeged Hungary
>
> 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
page fault in mpu.c
I finally tracked down the page fault I was seeing while probing the mpu.
The mutex was not being initialized before it was used. I have included a
patch below which fixes the problem. Will someone please review the style
and commit the fix.
Thanks.
Jim Bloom
[EMAIL PROTECTED]
Index: mpu.c
===
RCS file: /users/ncvs/src/sys/dev/sound/isa/mpu.c,v
retrieving revision 1.5
diff -u -r1.5 mpu.c
--- mpu.c 2001/03/14 07:29:46 1.5
+++ mpu.c 2001/03/27 02:20:29
@@ -358,6 +358,8 @@
DEB(printf("mpu: attaching.\n"));
+ mtx_init(&scp->mtx, "mpumid", MTX_DEF);
+
/* Allocate the resources, switch to uart mode. */
if (mpu_allocres(scp, dev) || mpu_uartmode(scp)) {
mpu_releaseres(scp, dev);
@@ -368,7 +370,6 @@
/* Fill the softc. */
scp->dev = dev;
- mtx_init(&scp->mtx, "mpumid", MTX_DEF);
scp->devinfo = devinfo = create_mididev_info_unit(MDT_MIDI, &mpu_op_desc,
&midisynth_op_desc);
/* Fill the midi info. */
@@ -751,6 +752,7 @@
bus_release_resource(dev, SYS_RES_IOPORT, scp->io_rid, scp->io);
scp->io = NULL;
}
+ mtx_destroy(&scp->mtx);
}
static device_method_t mpu_methods[] = {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Another broken buildworld
This is a pain. cvsup3 is the closest mirror to me. The only file I could find missing on cvsup3 was rsa_eay.c. Garrett, now that RSA has released the patent, would you be willing to add this file to the mirror on cvsup3? Jim Bloom [EMAIL PROTECTED] Kris Kennaway wrote: > > On Sun, 10 Sep 2000, Eric Hedberg wrote: > > > OK, fresh cvsup (blew away the old /usr/src, slurped down a new one this > > afternoon). > > Don't cvsup from cvsup3, it doesnt carry a full crypto mirror. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
There is a minor typo in the URL. The patches are at: http://people.freebsd.org/~imp/if_vx.patch Jim Bloom [EMAIL PROTECTED] Warner Losh wrote: > > Someone (I can't find who in my records, please let me know if it was > you so I can credit you in the commit message) sent out patches to > make the vx driver not use the pci compat shims. I just found it in > my home directory, applied it, tweaked things very minorly and it > builds and boots. Trouble is, I don't have a vortex to test with. It > also appears that there is no driver maintainer at this time, so I > thought I'd send it here. > > Please review my patches at > http://people/.freebsd.org/~imp/if_vx.patch > > I'd like to commit this in a few days. If you have a vortex board, > please give it a spin with these patches and let me know if there are > any problems. If you have any problems with the patches, let me > know. I'll commit this next weekend or so if there are no outstanding > issues by that time. > > I think this means lnc is the last one in the tree, but I could be > wrong about that. I didn't do an actual grep... > > Warner > > 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: AWE-64 no longer detected...
Mine seems to be detected just fine with a CVSUP on Sat Nov 11, 2000 at around 22:00 EST. The only error I get whiel trying to detect the card is: pci0: (vendor=0x11d1, dev=0x01f7) at 10.0 irq 9 I might submit a fix for this error at some point, but it doesn't affect anything. Jim Bloom [EMAIL PROTECTED] Glendon Gross wrote: > > Since my last cvsup, my Soundblaster AWE-64 card is no longer > detected. > > unknown: can't assign resources > unknown: can't assign resources > unknown0: at port 0x620-0x623 on isa0 > > Has anyone else seen this problem? Below is the full dmesg output. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problem building md module
While trying to build a new kernel today, I received errors relating to
vnode_if.h not existing. I have put the patch below which fixed the
problem for me. (Sorry if the patch does not apply because of cut and
paste errors, but it may easily be hand editted.)
Jim Bloom
[EMAIL PROTECTED]
Index: Makefile
===
RCS file: /users/ncvs/src/sys/modules/md/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- Makefile2000/09/02 19:17:10 1.7
+++ Makefile2000/12/31 18:35:36
@@ -2,7 +2,7 @@
.PATH: ${.CURDIR}/../../dev/md
KMOD= md
-SRCS= md.c opt_mfs.h opt_md.h
+SRCS= md.c opt_mfs.h opt_md.h vnode_if.h
NOMAN=
.include
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create a core dump. Here is a hand transcription of what I see. Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0270ad8 stack pointer = 0x10:0xc2fb4f50 frame pointer = 0x10:0xc2fb4f64 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (irq14:ata0) kernel: type 9 trap, code=0 Stopped at sw1b+0x77: ltr %si backtrace sw1b(4000) at sw1b+0x77 (note this is actually swtch()) ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 I don't have WITNESS or INVARIANTS at this time and don;t have a serial console so I can't capture the output. I can try adding these to my kernel and transcribe a little bit by hand. I can also send my kernel config and dmesg from a Nov kernel which boots. Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: > > On 05-Feb-01 Crist J. Clark wrote: > > I don't recall reports of trouble with recent CURRENT, but my CVSup > > from yesterday afternoon is panicing. Before I try too debug this, has > > anyone been getting these or knows what I might be missing? > > > > Boot messages and the panic info are attached. > > Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if > you can reproduce this? Also, compile the kernel with debug symbols. Then > type 'trace' at the db> prompt when it does to get a backtrace of where it blew > up. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
The line where I was having the trap is still within cpu_switch (line 236 of swtch.s). I added WITNESS and INVARIANTS to my kernel and I get a new panic. This time I see: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:918 panic() _mtx_assert(c031b6c0,9,c0290990,396,c043b100) at _mtx_assert+0x63 mi_switch(c031b6c0,0,c,c24bef08,c02681cd) at mi_switch+0x25 sched_ithd(e) at sched_ithd+0xd9 Xresume14() at Xresume14+0x8 --- interrupt, eip = 0xc02b0008, esp - 0xc2fbeee4, epb = 0xc2feed4 --- __set_sysinit_set_sym_sc_mem_sys_init(c0275020,c02b0008,286,c031b7230,0) at __set_sysinit_set_sym_sc_mem_sys_init+0x644 Jim Bloom [EMAIL PROTECTED] PS: Here is the original message. It was cut and pasted from the logs since your message is sitting in another OS on a dual boot machine. On 06-Feb-01 Jim Bloom wrote: > I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is > occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create > a > core dump. Here is a hand transcription of what I see. > > Mounting root from ufs:/dev/ad0s1a > pccard: card inserted, slot 0 > pccard: card inserted, slot 1 > kernel trap 9 with interrupts disabled > > Fatal trap 9: general protection fault while in kernel mode > instruction pointer = 0x8:0xc0270ad8 > stack pointer = 0x10:0xc2fb4f50 > frame pointer = 0x10:0xc2fb4f64 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 16 (irq14:ata0) > kernel: type 9 trap, code=0 > Stopped at sw1b+0x77: ltr %si > > backtrace > sw1b(4000) at sw1b+0x77 (note this is actually swtch()) Actually, this is beyond the end of cpu_switch I think. You are effectively off in lala land. > ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 This is either in the mtx_enter of Giant or in the interrupt handler itself. I'm betting an interrupt handler isn't being setup properly one way or another, and that the code is jumping through a bogus pointer and ending up in lala land executing random code. > fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d > fork_trampoline() at fork_trampoline+0x8 > > I don't have WITNESS or INVARIANTS at this time and don;t have a serial > console > so I can't capture the output. These help to capture bugs by doing extra checks though, and especially with current they are highly, highly, highly recommended right now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Here are the registers (subject to typing errors): cs 0xc2fb0008 ds 0xa10 es0x10 fs0x18 ss0x10 eax 0x12 ecx 0x20 edx 0xc00b8f00 ebx0x2 esp 0xc2fbee1c ebp 0xc2fbee28 esi 0x100 edi 0xc0290990 __set_sysctl_set_sym_sysctl__kern_fscale+0x4 eip 0xc0266fcc Debugger+44 efl 0x56 Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: > > On 06-Feb-01 Jim Bloom wrote: > > The line where I was having the trap is still within cpu_switch (line > > 236 of swtch.s). > > > > I added WITNESS and INVARIANTS to my kernel and I get a new panic. > > This time I see: > > > > kernel trap 12 with interrupts disabled > > panic: mutex sched lock recursed at ../../kern/kern_synch.c:918 > > > > panic() > > _mtx_assert(c031b6c0,9,c0290990,396,c043b100) at _mtx_assert+0x63 > > mi_switch(c031b6c0,0,c,c24bef08,c02681cd) at mi_switch+0x25 > > sched_ithd(e) at sched_ithd+0xd9 > > Xresume14() at Xresume14+0x8 > > --- interrupt, eip = 0xc02b0008, esp - 0xc2fbeee4, epb = 0xc2feed4 --- > > __set_sysinit_set_sym_sc_mem_sys_init(c0275020,c02b0008,286,c031b7230,0) > > at __set_sysinit_set_sym_sc_mem_sys_init+0x644 > > > > Jim Bloom > > [EMAIL PROTECTED] > > Hm, can you show the registers? I wonder if we are somehow running a > process that isn't fully created yet. Hmm, that shouldn't be a problem > looking at fork1().. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Which kernel do you want me to try this with? I have tried two different kernels with two different errors. (Both have been sent at different times in the past couple days.) The registers listed here from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for invariants), but the text segment was correct. Without debug, I get the trap 9. With debug, I get a trap 12 immediately followed by a panic with mutex shced lock recursion. I rebuilt the kernel with out the debugging and check the state of things. The code is correct and the esi register had the expected value. Jim Bloom [EMAIL PROTECTED] P.S. I am hitting the same problem Robert Watson mentioned. I don't have room for three kernels on the machine. John Baldwin wrote: > > On 06-Feb-01 Jim Bloom wrote: > > Here are the registers (subject to typing errors): > > > > cs0xc2fb0008 > > ds 0xa10 > > es 0x10 > > fs 0x18 > > ss 0x10 > > eax 0x12 > > ecx 0x20 > > edx 0xc00b8f00 > > ebx 0x2 > > esp 0xc2fbee1c > > ebp 0xc2fbee28 > > esi0x100 > > edi 0xc0290990 __set_sysctl_set_sym_sysctl__kern_fscale+0x4 > > eip 0xc0266fcc Debugger+44 > > efl 0x56 > > > > Jim Bloom > > [EMAIL PROTECTED] > > Erm, this doesn't look good: > > movl$GPROC0_SEL*8, %esi /* GSEL(entry, SEL_KPL) */ > ltr %si > > #define GPROC0_SEL 4 /* Task state process slot zero and up */ > > Thus, %esi should be 32 == 0x20, not 0x100. :( I have no clue why that is > screwed up, unless something is overwriting your code segment. Can you panic > it and do an x/i of sw1b+0x72? It should look something like this: > > 121: be 20 00 00 00 mov$0x20,%esi > 126: 0f 00 deltr%si To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
John Baldwin wrote: > > On 06-Feb-01 Jim Bloom wrote: > > Which kernel do you want me to try this with? I have tried two > > different kernels with two different errors. (Both have been sent at > > different times in the past couple days.) The registers listed here > > from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, > > MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for > > invariants), but the text segment was correct. > > You'll have to turn off WITNESS to get it to die in cpu_switch(), but you'll > want to leave the others on for now. I turned off WITNESS and still received the mutex error. A little reading of the code showed that mutex assertions are inclued with ifdef INVARIANTS. > > > Without debug, I get the trap 9. With debug, I get a trap 12 > > immediately followed by a panic with mutex shced lock recursion. > > > > I rebuilt the kernel with out the debugging and check the state of > > things. The code is correct and the esi register had the expected > > value. > > H. Ok, try with debugging minus WITNESS (and you don't want > MUTEX_DEBUG, that slows things down a _lot_). Then see if %esi is > still 0x100 instead of 0x20. If so, then check the instructions to make sure > they aren't hosed. With INVARIANTS turned off and WITNESS on, I received a trap 27 (stack fault) at sw1b+0x77. The instructions are fine and %esi was 0x20 as it should be. I won't worry about MUTEX_DEBUG being slow just yet. I am only around the start of /etc/rc when the machine dies. Do you have any other ideas on things that I can try to diagnose this problem? Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL ASM patch
I do plenty of build once and run on multiple machines. My biggest machine is a PII 40MHZ where I compile the world and kernels for a 486 laptop and P-60 Router/Firewall. I would not really want to compile the world on these slower machines over nfs. For my case, I guess I could rebuild only the ssl library for each machine properly tuned. For my small collection of machines, that wouldn't be too bad, but for larger sites it would be a problem. I could probably find some way to compile multiple version with buildworld and figure out the correct one to install with installworld. Jim Bloom [EMAIL PROTECTED] Peter Jeremy wrote: > > IMHO, the main market for this feature would be people who just do > binary installs - if you're doing a buildworld, you can tune to your > hardware[1]. If we wanted to just speed up OpenSSL on binary > installs, we could have processor-optimised variants of libssl.* > available as packages (tick the box that suits your processor if you > want the optimised library). > > [1] I don't think there's a lot of `build once, install on lots of > different hardware', though I could be wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Floppy Tape Driver.....
I used to run a 250Mb with extended length tapes (350Mb). That is still far short of the size of newer tape drives. Jim Bloom bl...@acm.org Poul-Henning Kamp wrote: > > In message , William Woods writes: > > >Yea yea, I know..but this was a gifyt for Christmass and I really dont > >have > >any extra $$ right nowso where is the floppy tape driver? > > Btw, if this is a new device, it is unlikely that the ft driver will support > it anyway, I don't think it ever came above the 80Mbyte tapes... > > -- > Poul-Henning Kamp FreeBSD coreteam member > p...@freebsd.org "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Really! strange uid value
I believe that (uid_t)-2 has a lot to do with the user nobody. That was the historical reason why the uid 65534 for chosen for nobody back when uid_t was only 16 bits. I would recommend that the default mapped uid for root be defined as 65534 instead of (uid_t)-2. This seems to make the most sense when trying to avoid user suprises. I would also suggest the default gid be changed similarly. (On Solaris 2.5.1, nobody is now uid 60001 with nobody4 as uid 65534 (for SunOS 4).) Jim Bloom bl...@acm.org Bruce Evans wrote: > > 4294967294 is just the default mapped uid for root. It is (uid_t)-2. > See mountd sources. It has nothing to do with user nobody or 65534, > except possibly on buggy clients that silently truncate it mod 65536. > Perhaps it is a bug to use (uid_t)-2 instead of 65534. For clients > with only 16-bit uid_t's you would want to keep all uids on the > server < 65536. > > Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Looks broken to me...
I get the same error. This is more to the error message which I have included below. I am doing a "make buildworld" after deleting everything in /usr/obj. Cvsup from freebsd3.freebsd.org at around 21:00 GMT. Jim Bloom bl...@acm.org c++ -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe -fno-for-scope -I/usr/src/gnu/usr.bin/groff/libgroff/../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARE_PCLOSE=1 -DHAVE_CC_OSFCN_H=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include -fno-for-scope -I/usr/obj/usr/src/tmp/usr/include -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc -o new.o In file included from /usr/obj/usr/src/tmp/usr/include/g++/osfcn.h:5, from /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include/posix.h:25, from /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc:24: /usr/obj/usr/src/tmp/usr/include/g++/std.h:23: stddef: No such file or directory *** Error code 1 Stop. David O'Brien wrote: > > > c++ -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe > > -fno-for-scope -I/usr/src/gnu/usr.bin/groff/libgroff/../include > > -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 > > -DHAVE_STDLIB_H=1 -DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 > > -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARE_PCLOSE=1 -DHAVE_CC_OSFCN_H=1 > > -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 > > -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DSYS_SIGLIST_DECLARED=1 > > -I/usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include > > -fno-for-scope -I/usr/obj/usr/src/tmp/usr/include -fno-rtti -fno-exceptions > > -c > > /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc > > -o new.o > > *** Error code 1 > > Did you get any other output? While ``make'' saw an error, ``c++'' > didn't report it for some reason. > > -- > -- David(obr...@nuxi.com -or- obr...@freebsd.org) > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Looks broken to me...
This seems to fix the problem. I got all the through buildworld and have installed the code. Man(1) seems to work fine, but I haven't done a major stress test of groff and the related programs. Jim Bloom bl...@acm.org David O'Brien wrote: > > > I've hit this one now too. > > I'm trying to duplicate the problem. > > My guess at the fix is to remove the "-DHAVE_CC_OSFCN_H=1\" line from > src/gnu/usr.bin/groff/Makefile.cfg. But I can't tell what other problems > this may cause. > > -- > -- David(obr...@nuxi.com -or- obr...@freebsd.org) > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: swap-related problems
A signal handler is not guaranteed to work. It must be written such that it does not require a new page of memory. Some possible problems here are the stack growing, writing on a new page in the data segment, etc. I'm not familiar enough with the VM system, but if you couldn't create a new swap page for a process, what would guarantee that the signal handler could get the pages it needs. Jim Bloom bl...@acm.org Mikhail Teterin wrote: > > If we are up to discussing the possible implementations, I'd suggest > that the system uses something other then SIGKILL to notify the > program it's time to pay for the over-commit speed and convenience. > I think, SIGBUS is appropriate, but I'm not sure. > > Anything a program can _catch_ and react upon, if its author chooses > to. > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Problems with ahc (2940U2W) and USB
Add me to the list of people seeing this problem. I have an ASUS P2B-S with onboard Adaptec 7890. I have been seeing the problem on and off since December of last year. One time it boots and the next time it doesn't. Once the disk is hung, the reset switch or power cycling are the only ways to unfreeze it. I have seen this problem mentioned on both freebsd-current and freebsd-scsi several times without a solution. I don't recall a link to USB being mentioned before. I'll try to post my dmesg output later this tonight. Jim Bloom bl...@acm.org Rick Whitesel wrote: > > Hi: > I am seeing the same thing on a ASUS P2B with a Adaptec 2940?? > controller. > > Rick > > - Original Message - > From: > To: > Sent: Wednesday, April 28, 1999 11:38 AM > Subject: Problems with ahc (2940U2W) and USB > > With the current sources, there seems to be a problem with the Adaptec > 2940U2W driver when using USB. > > Whenever I try to boot a kernel with the USB driver, the boot process > gets to the "Waiting 15 seconds for SCSI devices to settle" and stops. > If I compile a kernel with an nearly identical config, only the USB > driver has been commented out, it boots all right. > > My computer has a Spacewalker 661 mainboard, which is a 440BX based card. > The SCSI controller is an Adaptec 2940U2W. > > Kernels compiled before the integration of new-bus works fine. > > Now, this is not a critical situation for me, as I have no USB devices, > but I thought someone else would want this information. > > Anyone else experiencing this? > > -- > +---+ > Erik H. Bakke, Habatech AS | To be or not to be... | > E-Mail: e...@habatech.no| Is simply a question of binary logic. | > This message was sent by XFMail | | > +---+ > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Hang during boot with ahc (2940U2W)
Here is the dmesg output from a boot -v on my machine. I don't believe that I have ever had the USB ports configured in my kernel. They do have an IRQ allocated in the BIOS though. Jim Bloom bl...@acm.org Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #19: Sat Apr 10 14:19:12 EDT 1999 bl...@jbloom.ne.mediaone.net:/usr/src/sys/compile/JMB Calibrating clock(s) ... TSC clock: 400903902 Hz, i8254 clock: 1193167 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping=2 Features=0x183f9ff real memory = 134217728 (131072K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0032d000 - 0x07ffbfff, 130871296 bytes (31951 pages) config> pnp 1 0 os enable irq0 5 drq0 1 drq1 5 port0 0x220 port1 0x330 port2 0x388 config> pnp 1 1 os enable port0 0x200 config> pnp 1 2 os enable port0 0x620 port1 0xa20 port2 0xe20 config> ls Device port irq drq iomem iosize unit flags enab confl fdc0 0x3f0 6 2 0 00 0 Yes No wdc0 0x1f0 14-10 00 0xa0ffa0ff Yes No wdc1 0x170 15-10 01 0xa0ffa0ff Yes No atkbdc0 0x60 -1-10 00 0 Yes No atkbd0 0x 1 -10 00 0 Yes No psm0 0x 12-10 00 0 Yes No sc0 0x -1-10 00 0 Yes No sio0 0x3f8 4 -10 00 0x10 Yes No sio1 0x2f8 3 -10 01 0 Yes No ppc0 0x 7 -10 00 0 Yes No pca0 0x40 -1-10 00 0 Yes No vga0 0x -1-10 00 0 Yes Yes npx0 0xf0 13-10 00 0 Yes No apm0 0x -1-10 00 0x31 No No sb0 0x220 5 1 0 00 0 Yes No sbxvi0 0x -15 0 00 0 Yes No sbmidi0 0x330 -1-10 00 0 Yes No awe0 0x620 -1-10 00 0 Yes No opl0 0x388 -1-10 00 0 Yes No joy0 0x201 -1-10 00 0 Yes No CSN LDN conf en irqs drqs others (PnP devices) 1 0 OSY 5 0 1 5 port 0x220 0x330 0x388 1 1 OSY 0 0 0 0 port 0x200 1 2 OSY 0 0 0 0 port 0x620 0xa20 0xe20 config> quit avail memory = 127430656 (12K bytes) Found BIOS32 Service Directory header at 0xc00f9ce0 Entry = 0xf0550 (0xc00f0550) Rev = 0 Len = 1 PCI BIOS entry at 0x750 DMI header at 0xc00f5880 Version 2.0 Table at 0xf589a, 33 entries, 1079 bytes Other BIOS signatures found: ACPI: $PnP: 000fd110 Preloaded elf kernel "kernel" at 0xc0318000. Preloaded userconfig_script "/pnp.setup" at 0xc03180a8. Pentium Pro MTRR support enabled, default memory type is uncacheable GPL Math emulator present pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) Probing for devices on PCI bus 0: found-> vendor=0x8086, dev=0x7190, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 3, range 32, base e400, size 26 chip0: rev 0x02 on pci0.0.0 found-> vendor=0x8086, dev=0x7191, revid=0x02 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 chip1: rev 0x02 on pci0.1.0 found-> vendor=0x8086, dev=0x7110, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 chip2: rev 0x02 on pci0.4.0 found-> vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 4, range 32, base c800, size 4 ide_pci0: rev 0x01 on pci0.4.1 intel_piix_status: primary master sample = 5, master recovery = 4 intel_piix_status: primary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: primary slave sample = 3, slave recovery = 1 intel_piix_status: primary slave fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_
Re: oops: panic: bremfree: bp 0xc4206410 not locked
I believe the more interesting panic to debug is the first one here in mtrash_ctor and not the problem with syncing the disk after a panic. I have seen a few other panics in this routine posted to current over the last few weeks. Jim Bloom [EMAIL PROTECTED] Alex Zepeda wrote: > > I got this while the system was swapping quite a bit (silly Gtk+ > newsreader + supernews's huge retention == lots of memory used). > > FreeBSD blarf.homeip.net 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Wed Aug 14 00:39:15 PDT >2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ZIPPY_SMP_WITNESS i386 > > 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"... > panic: bremfree: bp 0xc4206410 not locked > panic messages: > --- > panic: Most recently used by none > > cpuid = 0; lapic.id = > > syncing disks... panic: bremfree: bp 0xc4206410 not locked > cpuid = 0; lapic.id = > Uptime: 1h20m25s > Dumping 127 MB > ata0: resetting devices .. > done > 16 32 48 64 80 96 112[CTRL-C to abort] > --- > #0 doadump () at ../../../kern/kern_shutdown.c:213 > 213 dumping++; > (kgdb) bt > #0 doadump () at ../../../kern/kern_shutdown.c:213 > #1 0xc022188d in boot (howto=260) at ../../../kern/kern_shutdown.c:345 > #2 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 > #3 0xc0255cf5 in bremfree (bp=0xc4206410) at ../../../kern/vfs_bio.c:633 > #4 0xc025bc84 in cluster_wbuild (vp=0xc21beb90, size=8192, start_lbn=12, > len=14) at ../../../kern/vfs_cluster.c:801 > #5 0xc0257454 in vfs_bio_awrite (bp=0xc4206410) > at ../../../kern/vfs_bio.c:1620 > #6 0xc02e1a51 in ffs_fsync (ap=0xc8a6fb48) at ../../../ufs/ffs/ffs_vnops.c:231 > #7 0xc02e104e in ffs_sync (mp=0xc1b1d600, waitfor=2, cred=0xc0bace80, > td=0xc03ed9c0) at vnode_if.h:545 > #8 0xc0265560 in sync (td=0xc03ed9c0, uap=0x0) > at ../../../kern/vfs_syscalls.c:129 > #9 0xc02214fa in boot (howto=256) at ../../../kern/kern_shutdown.c:254 > #10 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 > #11 0xc030210c in mtrash_ctor (mem=0xc2599400, size=0, arg=0x0) > at ../../../vm/uma_dbg.c:135 > #12 0xc0302178 in mtrash_fini (mem=0xc2599400, size=1024) > at ../../../vm/uma_dbg.c:186 > #13 0xc03003e5 in zone_drain (zone=0xc0b859c0) at ../../../vm/uma_core.c:646 > #14 0xc0300d1b in zone_foreach (zfunc=0xc0300148 ) > at ../../../vm/uma_core.c:1167 > #15 0xc0301c5a in uma_reclaim () at ../../../vm/uma_core.c:1980 > #16 0xc02fdb84 in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:653 > #17 0xc02fe9b1 in vm_pageout () at ../../../vm/vm_pageout.c:1439 > #18 0xc0212330 in fork_exit (callout=0xc02fe784 , arg=0x0, > frame=0xc8a6fd48) at ../../../kern/kern_fork.c:872 > (kgdb) quit > > 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: Trouble Building CURRENT on STABLE, cpp seg. fault
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
