Re: CVSup core dumps
On Tue, Oct 05, 1999 at 08:33:54AM +0200, Mark Murray <[EMAIL PROTECTED]> 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. > > The static binary seems to be OK an a 3-day-old CURRENT. And as opposite, the cvsup 16.0 static a.out binary, downloaded a day ago from ftp.freebsd.org dumps reliably core for me. I'm sorry, can't provide any info yet because it's my home machine. The machine runs also 3 day old -current, perhaps with deviation of some 12 hours or so, can't remember. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup core dumps
> 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. The static binary seems to be OK an a 3-day-old CURRENT. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my make world is broken !
> > > 3: *always* build (or try to) and install a new kernel before a > > >make world as that's a lot easier to back out of. > > > > This badly bites the bum of anyone who uses KLD's regularly. > > 4: Don't use modules in -current unless you know what you are doing. > This normally means not using modules in -current except for ones > that you are developing. Sure. This either needs spelling out, or it needs better automation so as to "work as expected". M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org 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: Recent kernel hangs during boot with pnp sio.
On Mon, 4 Oct 1999, Timo Geusch wrote: > If you're interested I can send you the source code for the driver but it is > not clear if it works on -current at the moment as I haven't updated for > some time. Send it here as I'm working on if_ep in some fashion. Someone find me a verified PnP 3c509 too. I'll pay shipping and $10 for one. I've got a normal 3c509 and a 3c579 in transit and a 3c529 in use. I'd be interested in a 3c589 for testing purposes but at this point it would be of little use has I've not yet put my hands on a ISA to PCMCIA reader. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Fri, Oct 01, 1999 at 03:36:11PM -0400, Daniel Eischen wrote: > But this still doesn't entirely solve the problem. You still have > to build and install a new kernel before installing the world. Of course! Installing the world _is_ upgrading your operating system. I don't see anyone suggesting that ELF applications should work on kernels that only support a.out binaries. Neither should programs that use 64-bit file offsets work on kernels that predate that change. (Note that this is entirely different from the issue of being able to use such a system to _build_ the new world.) > While this is typically what most -current folks do anyways, it > still prevents backing up to a previous kernel after the install > world. Yes. That's what backup tapes are for. If you're going to nuke your entire operating system, you'd better be ready to recover from tores. > It seems like libc should be built to be compatible with the kernel > that is currently running. After installing world and testing the > new kernel, a subsequent make world (or some other target to get > just the libs) can be done to make the libs use the new syscalls. > I like to keep old known working kernels around just in case there > are some serious bugs with the current one. Once a kernel has > proven itself somewhat stable, you can then upgrade the libs. Or, you could do it the sensible way: upgrade the kernel to support the new syscalls, and test it for a while _before_ building and installing a world that depends on it. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup core dumps
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
Re: New CVSup mirror sites
In article <[EMAIL PROTECTED]>, Chad R. Larson <[EMAIL PROTECTED]> wrote: > > John, do you have usage statistics broken out for each server? I don't, but I wish I did. It would be an interesting project for somebody to write tools that could analyze the cvsupd log files to get information like that. Wolfram Schneider's "cvsup2httplog" script in the contrib area of the CVSup source distribution might be a good start toward that. Unfortunately I don't have time to work on it. 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
Re: A record?
Mark Newton wrote: > A similar box which I rebooted (for an upgrade from 2.2.5 to 3.2) about > a fortnight ago: > > 3:38PM up 471 days, 5:59, 1 user, load averages: 0.00, 0.02, 0.00 > > ... and, before this thread gets completely out of control, I direct > posters to http://uptime.viper.net.au (warning: if you're easily offended, > don't bother). Using options HZ (without a value) you can make any system run as fast as it can, one p100 was elapsing days in 20 minutes.. i had its uptime around 1100days in about 2 weeks.. so nerr my dick is bigger than yours ;) P.S nothing BAD happened over the year 2000 ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A record?
Mark Murray wrote: > > 7:46PM up 375 days, 20:09, 2 users, load averages: 0.00, 0.01, 0.00 > > FreeBSD xx.xxx.xxx 2.2.6-STABLE FreeBSD 2.2.6-STABLE #0: Tue May 5 >15:51:34 SAST 1998 [EMAIL PROTECTED]:/usr/src/sys/compile/XXX i38 > 6 > > This box was used as a shell server for more than a year; it was > hardened for shell use, and served us admirably. We recently (with > some sadness) closed down the shell service, but the actual box > will live in some other (staff-serving) incarnation. A similar box which I rebooted (for an upgrade from 2.2.5 to 3.2) about a fortnight ago: 3:38PM up 471 days, 5:59, 1 user, load averages: 0.00, 0.02, 0.00 ... and, before this thread gets completely out of control, I direct posters to http://uptime.viper.net.au (warning: if you're easily offended, don't bother). - mark Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my make world is broken !
> > 3: *always* build (or try to) and install a new kernel before a > >make world as that's a lot easier to back out of. > > This badly bites the bum of anyone who uses KLD's regularly. 4: Don't use modules in -current unless you know what you are doing. This normally means not using modules in -current except for ones that you are developing. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld broken?
Hi Guido, > I have a 3.3.-stable system and somehow I cannot make buildworld > a current tree. > The porblem is: > cc -c -I/alt/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config >-I/alt/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC >-I/usr/obj/alt/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o >/alt/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c > *** Signal 12 There have been some major changes in the '-current' tree allowing more than 32 signals. These changes were documented (very well) in a 'HEADS-UP' by Marcel when he committed his changes. I've included that HEADS-UP for your reference below. There is a long thread of discussions on -current about these changes. Check the archives for details. In particular, you'll find that it is necessary to build the kernel and *BOOT* the new kernel before a make world. There is continuing work being done on these changes. > This system has been running and compilig a lot of other FreeBSD versions > in the last 3 years, and has never had any memory problems at all. It is not a memory problem. It is a change in the signalling mechanism of the kernel. > Is this a known problem? Yes, and it is well documented in the -current mailing lists. Mike Kennett ([EMAIL PROTECTED]) -Included: To: [EMAIL PROTECTED] Date: Wed, 29 Sep 1999 17:29:40 +0200 From: Marcel Moolenaar <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Subject: HEADS UP: sigset_t changes committed Sender: [EMAIL PROTECTED] I just finished committing the sigset_t changes I worked on for the last 5 weeks. Before attempting to build world, you must make and install a new kernel. The new kernel will contain new syscalls that are needed during build world. doscmd is currently not being build because it needs fixing first. Alpha users are invited to test the changes since I've not been able to do that myself. I've done all I possibly could do to make this a success. I've attached the commit logs for everyone to see. Please report problems as soon as possible. Thanks, sigset_t change (part 1 of 5) - Rename sigaction, sigprocmask, sigpending and sigsuspend to osigaction, osigprocmask, osigpending and osigsuspend (resp) and add new syscalls for them to support the new sisgset_t without breaking existing binaries. Change the prototype of sigaltstack to use the typedef stack_t instead of struct sigaltstack to reflect that it is SUSv2 compliant. Also, rename sigreturn to osigreturn and add a new syscall to support the modified stackframe. The change is caused by sigreturn operating on ucontext_t now and the fact that siginfo_t has been updated to conform to SUSv2. sigset_t change (part 2 of 5) - The core of the signalling code has been rewritten to operate on the new sigset_t. No methodological changes have been made. Most references to a sigset_t object are through macros (see signalvar.h) to create a level of abstraction and to provide a basis for further improvements. The NSIG constant has not been changed to reflect the maximum number of signals possible. The reason is that it breaks programs (especially shells) which assume that all signals have a non-null name in sys_signame. See src/bin/sh/trap.c for an example. Instead _SIG_MAXSIG has been introduced to hold the maximum signal possible with the new sigset_t. struct sigprop has been moved from signalvar.h to kern_sig.c because a) it is only used there, and b) access must be done though function sigprop(). The latter because the table doesn't holds properties for all signals, but only for the first NSIG signals. signal.h has been reorganized to make reading easier and to add the new and/or modified structures. The "old" structures are moved to signalvar.h to prevent namespace polution. Especially the coda filesystem suffers from the change, because it contained lines like (p->p_sigmask == SIGIO), which is easy to do for integral types, but not for compound types. NOTE: kdump (and port linux_kdump) must be recompiled. Thanks to Garrett Wollman and Daniel Eischen for pressing the importance of changing sigreturn as well. sigset_t change (part 3 of 5) - By introducing a new sigframe so that the signal handler operates on the new siginfo_t and on ucontext_t instead of sigcontext, we now need two version of sendsig and sigreturn. A flag in struct proc determines whether the process expects an old sigframe or a new sigframe. The signal trampoline handles which sigreturn to call. It does this by testing for a magic cookie in the frame. The alpha uses osigreturn to implement longjmp. This means that osigreturn is not only used for compatibility with existing binaries. To handle the new sigset_t, setjmp saves it in sc_reserved (see NOTE). the struct sigframe has been moved from frame.h to sigframe.h to handle the complex header dependencies that was caused by the new sigframe. NOTE: For the i386,
Re: new signal stuff breaks libc_r?
replying to my own message but I think I found a solution...
It seems that something was stale in /usr/include, I was able to
fix the problem by:
rm -rf /usr/include/*
cd /usr/src
make includes
cd /usr/src/lib/libc_r
make
make install
funny part is that two successive make worlds didn't seem to work, but
this did.
*shrug*
sorry for the noise,
-Alfred
On Mon, 4 Oct 1999, Alfred Perlstein wrote:
>
> On Mon, 4 Oct 1999, Marcel Moolenaar wrote:
>
> > Alfred Perlstein wrote:
> > >
> > > Since the signal changes...
> > >
> > > I'm finding that it _seems_ since libc_r isn't including something
> > > that properly defines __inline to inline that i'm getting unresolved
> > > symbols when linking or running programs that depend on libc_r.
> > >
> > > Anyone else getting this?
> > >
> > > compiling a void main(void){} with -pthread will barf for me,
> > > using -static I'm able to see which files are missing which
> > > inlines.
> >
> > This isn't a problem report I can deal with. Please be very explicit.
>
> I think it's something I may have broken somehow, but i'm not
> exactly sure:
>
> ~ % cat t.c
> #include
>
> int main(void) {
>
> printf("hello world.\n");
>
> }
>
> .(14:17:52)(bright@thumper)
> ~ % gcc -static t.c -pthread
> /usr/lib/libc_r.a(uthread_sig.o): In function `_dispatch_signals':
> /home/src/lib/libc_r/uthread/uthread_sig.c(.text+0xf05): undefined reference to
>`__sigisempty'
>
> For some reason it looks like __inline is being defined like:
>
> #define __inline
>
> so that when signalvar.h is included the inlines for __sigisempty
> aren't getting the "inline_ prefix and are assumed to be somewhere
> else.
>
> I asked phk about it and he's not having the problem with a recent
> -current so I'll be futzing around searching for the reason this
> is happening.
>
> I just deleted my source tree and I'm going to re-check it out,
> maybe something got corrupted?
>
> -Alfred
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
make buildworld broken?
Hi, I have a 3.3.-stable system and somehow I cannot make buildworld a current tree. The porblem is: cc -c -I/alt/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/alt/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/alt/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /alt/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Signal 12 Stop in /alt/usr/src/gnu/lib/libgcc. *** Error code 1 This system has been running and compilig a lot of other FreeBSD versions in the last 3 years, and has never had any memory problems at all. IIRC a couple of days ago a buildworld worked (but I had to reinstall due to a different disksetup) Is this a known problem? -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: rebirth of sigcontext
Hi, I just committed the sigcontext changes. sigreturn can now again be called with an argument of type sigcontext but also with an argument of type ucontext_t. Also, signal handlers can define their third argument to be both of type struct sigcontext* and ucontext_t*. This should fix the source incompatibility introduced by the sigset_t changes. Alpha users are again advised to take precaution. Not that I expect filesystem crashes, but simply because I can't test those changes. Maybe in the future... NOTE: Recompilation of doscmd is required. For your convenience, the commit log message: Re-introduction of sigcontext. struct sigcontext and ucontext_t/mcontext_t are defined in such a way that both (ie struct sigcontext and ucontext_t) can be passed on to sigreturn. The signal handler is still given a ucontext_t for maximum flexibility. For backward compatibility sigreturn restores the state for the alternate signal stack from sigcontext.sc_onstack and not from ucontext_t.uc_stack. A good way to determine which value the application has set and thus which value to use, is still open for discussion. NOTE: This change should only affect those binaries that use sigcontext and/or ucontext_t. In the source tree itself this is only doscmd. Recompilation is required for those applications. This commit also fixes a lot of style bugs without hopefully adding new ones. NOTE: struct sigaltstack.ss_size now has type size_t again. For some reason I changed that into unsigned int. Parts submitted by: bde sigaltstack bug found by: bde -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation
Chuck Robey wrote: > > I just tried to use my copy of WordPerfect 8 to decode an rtf document, > like I've done before the signal change, and boy was I surprised. The > machine locked up for 10 seconds, then spontaneously rebooted. > > Anyone else have this experience with Linux emulation? Some reports of crashes have come to me, but none contained the necessary information or simply weren't reproducable. If you think there's something wrong and you want me to take a look at it, you'll have to give me something to work on. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my make world is broken !
On Thu, 30 Sep 1999, Juan Amado Becerril Castillo wrote: > Suggestions ??? Not mail the list 3 f'ing times, to start. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netscape core dump, happily :-)
I am running FreeBSD 4.0. I have been seeing the empty core files from netscape 4.61 and (as of last night) 4.7 for at least a week. I use fvwm2 and afterstep-devel. The behavior seems to be independant of the window manager. I rebuilt all my ports (including X and new X aout files) with the new kernel and world as of Saturday, but this has had no effect. Mostly this behavior is anoying, although occasionally I will see a crash when I try to read mail. Things seem a little stabler with netscape in linux emulation mode, but I haven't kept track closely enough to tell. -- George ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...
: Excuse my intrusion, but could you be so kind to tell me whether you had :the time to build patches for these MMAP-related freezes ? If not could :you recommend me some workarounds ? : : I have a -stable production server that keeps (solidly) blocking pretty :often (I don't get over 3 days uptimes). If you need details just let me :know. : :> -Matt :> Matthew Dillon :> <[EMAIL PROTECTED]> : Thanks, : Ady (@warpnet.ro) Well, your lockups may or may not be related to the remaining mmap problems. They could be related to the swap fragmentation problems in stable, or they could be related to something else entirely. In order to determine the cause of your lockup problems, some additional information is necessary. The easiest way to get the information is to enable DDB and kernel core dumps so you can panic the machine from the console and get a core. Once you have the core 'cd /var/crash; ps -M vmcore.X -N kernel.X' (where X is the latest dump number) can be used to determine what the processes were doing when they locked up. The two most common VM-related lockups in -stable are: (1) swap metadata fragmentation due to paging in the face of large running processes (system runs out of KVM), and (2) write()ing the mmap'd area of one file descriptor to another. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Linux emulation
I just tried to use my copy of WordPerfect 8 to decode an rtf document, like I've done before the signal change, and boy was I surprised. The machine locked up for 10 seconds, then spontaneously rebooted. Anyone else have this experience with Linux emulation? Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my make world is broken !
Mark Murray wrote: > > 3: *always* build (or try to) and install a new kernel before a > >make world as that's a lot easier to back out of. > > This badly bites the bum of anyone who uses KLD's regularly. > > I suspect that _now_ is the time to try to make thes build at > kernel build time, and also move to some subdirectory that is > not nuked straight away. Hmm.. You've got me thinking now... Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: malloc type lacks magic
Andre, I had the same problem with my laptop and what worked for me was to boot it in single user with my old kernel, fsck all disk partitions, mount all partitions -w including root with -u -w, make a new kernel, reboot again in single user and remount everything and make world. I was then ok, but I still cvsuped and made a new worldand kernel just for good measure after everything was working :-) I did that Friday and have had good builds Saturday, Sunday and today. provecho, ed Andre Oppermann wrote: > Hello > > It looks like I fucked my -current box up during the sig_t changes. > I tried made a new kernel before make world but after ifconfig'ing > the network interfaces it panics with: > > panic: malloc type lacks magic > > Making a new world is of course not possible because of the sig_t > changes. > > Any ideas what is going wrong? I'm a little bit lost at this. > > Thanks > -- > Andre > > 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: my make world is broken !
Juan Amado Becerril Castillo wrote: > > Suggestions ??? Sure. Read the mailing list you are posting to. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it done unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...
On Mon, 4 Oct 1999, Adrian Penisoara wrote:
>
> Excuse my intrusion, but could you be so kind to tell me whether you had
> the time to build patches for these MMAP-related freezes ? If not could
> you recommend me some workarounds ?
doubling the ram from 384 -> 768 meg appears to have fixed it for mme...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: A record?
> 7:46PM up 375 days, 20:09, 2 users, load averages: 0.00, 0.01, 0.00 > FreeBSD xx.xxx.xxx 2.2.6-STABLE FreeBSD 2.2.6-STABLE #0: Tue May 5 15:51:34 >SAST 1998 [EMAIL PROTECTED]:/usr/src/sys/compile/XXX i38 6 This box was used as a shell server for more than a year; it was hardened for shell use, and served us admirably. We recently (with some sadness) closed down the shell service, but the actual box will live in some other (staff-serving) incarnation. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my make world is broken !
> 3: *always* build (or try to) and install a new kernel before a >make world as that's a lot easier to back out of. This badly bites the bum of anyone who uses KLD's regularly. I suspect that _now_ is the time to try to make thes build at kernel build time, and also move to some subdirectory that is not nuked straight away. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my make world is broken !
And *don't* post the same thing three times to the lists unless you want to find yourself filtered out! Juan Amado Becerril Castillo wrote: > Suggestions ??? > > -- > >>> elf make world started on Thu Sep 30 09:23:09 CDT 1999 > -- > > -- > >>> Cleaning up the temporary elf build tree > -- > mkdir -p /usr/obj/usr/src/tmp > chflags -R noschg /usr/obj/usr/src/tmp/ > rm -rf /usr/obj/usr/src/tmp > > -- > >>> Making make > -- > mkdir -p /usr/obj/usr/src/tmp/usr/bin /usr/obj/usr/src/tmp/make > ( cd /usr/src/usr.bin/make; MAKEOBJDIRPREFIX=""; unset > MAKEOBJDIRPREFIX; > BISON_SIMPLE=/usr/obj/usr/src/tmp/usr/share/misc/bison.simple > COMPILER_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/obj/usr/src/tmp/usr/bin > > --- > cut > --- > > ===> c++filt > /usr/obj/usr/src/gnu/usr.bin/cc/c++filt created for > /usr/src/gnu/usr.bin/cc/c++filt > ===> doc > /usr/obj/usr/src/gnu/usr.bin/cc/doc created for > /usr/src/gnu/usr.bin/cc/doc > ===> f77 > /usr/obj/usr/src/gnu/usr.bin/cc/f77 created for > /usr/src/gnu/usr.bin/cc/f77 > ===> f771 > /usr/obj/usr/src/gnu/usr.bin/cc/f771 created for > /usr/src/gnu/usr.bin/cc/f771 > ===> f77doc > /usr/obj/usr/src/gnu/usr.bin/cc/f77doc created for > /usr/src/gnu/usr.bin/cc/f77doc > cd /usr/src/gnu/lib/libgcc; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD > -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend; > /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC > -DNOPROFILE -DNOSHARED all; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD > -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -B install; > /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPROFILE > -DNOSHARED -B cleandir obj > rm -f .depend /usr/obj/usr/src/gnu/lib/libgcc/GPATH > /usr/obj/usr/src/gnu/lib/libgcc/GRTAGS > /usr/obj/usr/src/gnu/lib/libgcc/GSYMS > /usr/obj/usr/src/gnu/lib/libgcc/GTAGS > echo '#include ' > config.h > echo '#include ' >> config.h > echo '#include "i386/xm-i386.h"' > tconfig.h > echo '#include "i386/i386.h"' > tm.h > echo '#include "i386/att.h"' >> tm.h > echo '#include "i386/freebsd.h"' >> tm.h > echo '#include "i386/perform.h"' >> tm.h > cc -c -O -pipe > -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config > -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions > -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o > /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c > *** Signal 12 > > Stop in /usr/src/gnu/lib/libgcc. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my make world is broken !
Juan Amado Becerril Castillo wrote: > Suggestions ??? 1: Read freebsd-current and it would have told you! 2: Build a new kernel first before 'make world'. 3: *always* build (or try to) and install a new kernel before a make world as that's a lot easier to back out of. [..] > echo '#include "i386/freebsd.h"' >> tm.h > echo '#include "i386/perform.h"' >> tm.h > cc -c -O -pipe > -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config > -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions > -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o > /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c > *** Signal 12 > > Stop in /usr/src/gnu/lib/libgcc. > *** Error code 1 Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new signal stuff breaks libc_r?
On Mon, 4 Oct 1999, Marcel Moolenaar wrote:
> Alfred Perlstein wrote:
> >
> > Since the signal changes...
> >
> > I'm finding that it _seems_ since libc_r isn't including something
> > that properly defines __inline to inline that i'm getting unresolved
> > symbols when linking or running programs that depend on libc_r.
> >
> > Anyone else getting this?
> >
> > compiling a void main(void){} with -pthread will barf for me,
> > using -static I'm able to see which files are missing which
> > inlines.
>
> This isn't a problem report I can deal with. Please be very explicit.
I think it's something I may have broken somehow, but i'm not
exactly sure:
~ % cat t.c
#include
int main(void) {
printf("hello world.\n");
}
.(14:17:52)(bright@thumper)
~ % gcc -static t.c -pthread
/usr/lib/libc_r.a(uthread_sig.o): In function `_dispatch_signals':
/home/src/lib/libc_r/uthread/uthread_sig.c(.text+0xf05): undefined reference to
`__sigisempty'
For some reason it looks like __inline is being defined like:
#define __inline
so that when signalvar.h is included the inlines for __sigisempty
aren't getting the "inline_ prefix and are assumed to be somewhere
else.
I asked phk about it and he's not having the problem with a recent
-current so I'll be futzing around searching for the reason this
is happening.
I just deleted my source tree and I'm going to re-check it out,
maybe something got corrupted?
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
[Patches avail?] Re: MMAP() in STABLE/CURRENT ...
Hi,
On Mon, 14 Jun 1999, Matthew Dillon wrote:
>
> :>
> :> David, can you email this program to me please?
> :>
> :> Also, which FreeBSD release does this occur on?
> :>
> :> I've got about 6 mmap-related bugs on my plate at the moment. 3 of them
> :> have been identified ( that is, I know why they deadlock the machine ),
> :> but none have been fixed yet.
> :
> :Matt, I'll volunteer myself as a tester for this code under 3.2-STABLE,
> :when you have it ready...
> :
> :Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> :Systems Administrator @ hub.org
> :primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
>
> I'll let the lists know when patches are available. It may be a while
> (like a week), I still have a lot of catching-up to do after being at
> USENIX all last week and my commit privs still need to be resolved.
>
Excuse my intrusion, but could you be so kind to tell me whether you had
the time to build patches for these MMAP-related freezes ? If not could
you recommend me some workarounds ?
I have a -stable production server that keeps (solidly) blocking pretty
often (I don't get over 3 days uptimes). If you need details just let me
know.
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
Thanks,
Ady (@warpnet.ro)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: maxphys = 0??
You need to move your sources further forward. In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" writes: >A kernel from this weekend's sources is showing this warning message >at boot: > >WARNING: #ad/0x30005 maxphys = 0 ??WARNING: #ad/0x30004 maxphys = 0 >?? > >These are: > >brw-r- 1 root operator 30, 0x00030004 Apr 6 11:48 ad0s2e >brw-r- 1 root operator 30, 0x00030005 Apr 6 11:48 ad0s2f > >I had a crash during an overnight make world with this kernel, but I >haven't been able to reproduce the crash. > >>From the source code, it would seem the message is harmless. >Nevertheless, it's a warning message, so I suppose I'm being warning >about something. Why does it show this message for ad0s2[ef] but not >for the other partitions? How do I "correct" the problem? Anyone >wants me to provide any kind of further information? > >-- >Daniel C. Sobral (8-DCS) >[EMAIL PROTECTED] >[EMAIL PROTECTED] > > Rule 69: Do unto other's code as you'd have it done unto yours > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
maxphys = 0??
A kernel from this weekend's sources is showing this warning message at boot: WARNING: #ad/0x30005 maxphys = 0 ??WARNING: #ad/0x30004 maxphys = 0 ?? These are: brw-r- 1 root operator 30, 0x00030004 Apr 6 11:48 ad0s2e brw-r- 1 root operator 30, 0x00030005 Apr 6 11:48 ad0s2f I had a crash during an overnight make world with this kernel, but I haven't been able to reproduce the crash. >From the source code, it would seem the message is harmless. Nevertheless, it's a warning message, so I suppose I'm being warning about something. Why does it show this message for ad0s2[ef] but not for the other partitions? How do I "correct" the problem? Anyone wants me to provide any kind of further information? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it done unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world trouble
Anybody can help me, how I can fix this ! Thanks. ===> c++filt /usr/obj/usr/src/gnu/usr.bin/cc/c++filt created for /usr/src/gnu/usr.bin/cc/c++filt ===> doc /usr/obj/usr/src/gnu/usr.bin/cc/doc created for /usr/src/gnu/usr.bin/cc/doc ===> f77 /usr/obj/usr/src/gnu/usr.bin/cc/f77 created for /usr/src/gnu/usr.bin/cc/f77 ===> f771 /usr/obj/usr/src/gnu/usr.bin/cc/f771 created for /usr/src/gnu/usr.bin/cc/f771 ===> f77doc /usr/obj/usr/src/gnu/usr.bin/cc/f77doc created for /usr/src/gnu/usr.bin/cc/f77doc cd /usr/src/gnu/lib/libgcc; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED all; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -B install; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPROFILE -DNOSHARED -B cleandir obj rm -f .depend /usr/obj/usr/src/gnu/lib/libgcc/GPATH /usr/obj/usr/src/gnu/lib/libgcc/GRTAGS /usr/obj/usr/src/gnu/lib/libgcc/GSYMS /usr/obj/usr/src/gnu/lib/libgcc/GTAGS echo '#include ' > config.h echo '#include ' >> config.h echo '#include "i386/xm-i386.h"' > tconfig.h echo '#include "i386/i386.h"' > tm.h echo '#include "i386/att.h"' >> tm.h echo '#include "i386/freebsd.h"' >> tm.h echo '#include "i386/perform.h"' >> tm.h cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Signal 12 Stop in /usr/src/gnu/lib/libgcc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
my make world is broken !
Suggestions ??? -- >>> elf make world started on Thu Sep 30 09:23:09 CDT 1999 -- -- >>> Cleaning up the temporary elf build tree -- mkdir -p /usr/obj/usr/src/tmp chflags -R noschg /usr/obj/usr/src/tmp/ rm -rf /usr/obj/usr/src/tmp -- >>> Making make -- mkdir -p /usr/obj/usr/src/tmp/usr/bin /usr/obj/usr/src/tmp/make ( cd /usr/src/usr.bin/make; MAKEOBJDIRPREFIX=""; unset MAKEOBJDIRPREFIX; BISON_SIMPLE=/usr/obj/usr/src/tmp/usr/share/misc/bison.simple COMPILER_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/obj/usr/src/tmp/usr/bin --- cut --- ===> c++filt /usr/obj/usr/src/gnu/usr.bin/cc/c++filt created for /usr/src/gnu/usr.bin/cc/c++filt ===> doc /usr/obj/usr/src/gnu/usr.bin/cc/doc created for /usr/src/gnu/usr.bin/cc/doc ===> f77 /usr/obj/usr/src/gnu/usr.bin/cc/f77 created for /usr/src/gnu/usr.bin/cc/f77 ===> f771 /usr/obj/usr/src/gnu/usr.bin/cc/f771 created for /usr/src/gnu/usr.bin/cc/f771 ===> f77doc /usr/obj/usr/src/gnu/usr.bin/cc/f77doc created for /usr/src/gnu/usr.bin/cc/f77doc cd /usr/src/gnu/lib/libgcc; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED all; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -B install; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPROFILE -DNOSHARED -B cleandir obj rm -f .depend /usr/obj/usr/src/gnu/lib/libgcc/GPATH /usr/obj/usr/src/gnu/lib/libgcc/GRTAGS /usr/obj/usr/src/gnu/lib/libgcc/GSYMS /usr/obj/usr/src/gnu/lib/libgcc/GTAGS echo '#include ' > config.h echo '#include ' >> config.h echo '#include "i386/xm-i386.h"' > tconfig.h echo '#include "i386/i386.h"' > tm.h echo '#include "i386/att.h"' >> tm.h echo '#include "i386/freebsd.h"' >> tm.h echo '#include "i386/perform.h"' >> tm.h cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Signal 12 Stop in /usr/src/gnu/lib/libgcc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
my make world is broken !
Suggestions ??? -- >>> elf make world started on Thu Sep 30 09:23:09 CDT 1999 -- -- >>> Cleaning up the temporary elf build tree -- mkdir -p /usr/obj/usr/src/tmp chflags -R noschg /usr/obj/usr/src/tmp/ rm -rf /usr/obj/usr/src/tmp -- >>> Making make -- mkdir -p /usr/obj/usr/src/tmp/usr/bin /usr/obj/usr/src/tmp/make ( cd /usr/src/usr.bin/make; MAKEOBJDIRPREFIX=""; unset MAKEOBJDIRPREFIX; BISON_SIMPLE=/usr/obj/usr/src/tmp/usr/share/misc/bison.simple COMPILER_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/obj/usr/src/tmp/usr/bin --- cut --- ===> c++filt /usr/obj/usr/src/gnu/usr.bin/cc/c++filt created for /usr/src/gnu/usr.bin/cc/c++filt ===> doc /usr/obj/usr/src/gnu/usr.bin/cc/doc created for /usr/src/gnu/usr.bin/cc/doc ===> f77 /usr/obj/usr/src/gnu/usr.bin/cc/f77 created for /usr/src/gnu/usr.bin/cc/f77 ===> f771 /usr/obj/usr/src/gnu/usr.bin/cc/f771 created for /usr/src/gnu/usr.bin/cc/f771 ===> f77doc /usr/obj/usr/src/gnu/usr.bin/cc/f77doc created for /usr/src/gnu/usr.bin/cc/f77doc cd /usr/src/gnu/lib/libgcc; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED all; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -B install; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPROFILE -DNOSHARED -B cleandir obj rm -f .depend /usr/obj/usr/src/gnu/lib/libgcc/GPATH /usr/obj/usr/src/gnu/lib/libgcc/GRTAGS /usr/obj/usr/src/gnu/lib/libgcc/GSYMS /usr/obj/usr/src/gnu/lib/libgcc/GTAGS echo '#include ' > config.h echo '#include ' >> config.h echo '#include "i386/xm-i386.h"' > tconfig.h echo '#include "i386/i386.h"' > tm.h echo '#include "i386/att.h"' >> tm.h echo '#include "i386/freebsd.h"' >> tm.h echo '#include "i386/perform.h"' >> tm.h cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Signal 12 Stop in /usr/src/gnu/lib/libgcc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Issues with xl0
WARNING: the following reply contains Extreme Ranting which may be too intense for young audiences. Those not wishing to experience Extreme Ranting should #define NO_EXTREME_RANTING. Of all the gin joints in all the towns in all the world, Bryan Bursey had to walk into mine and say: > I attempted to move from -STABLE to -CURRENT last night, but without any > luck. I decided to start with a current snapshot (19990928), but was > unable to install using the floppies provided on releng3.freebsd.org. #ifndef NO_EXTREME_RANTING But the exact reason why you were unable to install is a secret, right? Clearly the details of the failure would be of no use to anyone, so you chose not to share them, yes? How many times do I have to say it: "it didn't work," "it failed," "I couldn't make it do blah" and similar vague descriptions don't help anybody. Don't start in with a vague statement about a problem and then expect to be asked for more details later: give the details first! It saves a lot of time! #endif > Thinking it might have been a floppy issue, #ifndef NO_EXTREME_RANTING It may as well have been an arthritis issue for all we know. #endif > I used my 3.3-STABLE floppies > and simply changed the install options so that I'd get 4.0. This worked > until I restarted my machine at the end of the install. It came back up > ok, but I was again unable to connect to the network. This is too vague. You're leaving out a ton of details, like: did you even see the xl0 probe messages in the kernel. You know, basic stuff which nobody else will know since we're not able to see over your shoulder. > Can anyone tell me if there are known issues with the xl0 driver in 4.0, > or if it has been superceded by another driver which works with 3Com > 3C900B. #ifndef NO_EXTREME_RANTING No no no. *You* tell *us* if there are any issues! *You* tell *us* if you're having any problems! And then *you* tell *us* in explicit detail what they are! How hard is it to understand that! No, there isn't any other driver. But because you didn't make eves the slightest effort to explain your problem, I can't begin to even help you. #endif You didn't specify which 3c900B card you have: there are several of them with different media options: - 3c900B-FL 10baseFL fiber-optic - 3c900B-TPO 10baseT "Twisted Pair Only" - 3c900B-TPC 10baseT and 10base2 "Twisted Pair and Coax" - 3c900B-COMBO 10baseT, 10base2 and 10base5 (AUI) #ifndef NO_EXTREME_RANTING If you'd bothered to watch what happens when the kernel boots, you would have been able to tell whether or not the 3c900B card was detected (and I know it was in spite of your unwillingless to say so). You would also have been able to tell what media was selected (10baseT, 10base5 or 10base2, depending a bit on exactly which model card you have, which you also didn't tell us). Then had you bothered to rub two brain cells together, you might have been able to tell if maybe the default media selection read from the EEPROM was incorrect and possibly tried to use ifconfig to set it correctly. #endif If you have a TPO or FL adapter, then there's only one media choice, and the driver should have selected it properly. If you have a TPC or a COMBO adapter, then somebody may have fiddled with the 3C90XCFG.EXE utility and selected the wrong default media in the EEPROM. The driver will only use what the EEPROM says; it doesn't autoprobe. If you used the 3C90XCFG.EXE utility to select the "auto" choice, then the driver will pick a reasonable default and expect you to be clever enough to change it with ifconfig if the choice is wrong. For example, for a COMBO card, it will choose 10baseT. If you don't like 10baseT, you can do the following: # ifconfig xl0 media 10base2/BNC # ifconfig xl0 media 10base5/AUI Or if you really want 10baseT: # ifconfig xl0 media 10baseT/UTP If you want to use this setting during the install, then enter the media option command in the box that says "extra options to ifconfig" in the TCP/IP configuration screen (i.e. "media 10base2/BNC"). > Thanks for any help (or other random thoughts). #ifndef NO_EXTREME_RANTING You want random thoughts? Fine: I wish it would stop raining, I hope the Mets make it to the playoffs, my shoes are too tight, you're ugly and your mother dresses you funny. I know what you're thinking: "why is he being so nasty?" Because I can't stand it when people expect me to play the "minimum information" game, and you are by no means the first. Some people may be able to read a chewing gum wrapper and divine the secrets of the universe, but I'm not one of them. #endif -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I w
Why Adaptec 1540 bombing?
Anyone in the current folks know why I might be getting problems with FreeBSD on an Adaptec 1540 controller? The machine works fine on 2.2.8 and 2.2.6, but dies a horrible screeching halt when installing 3.3 or 4.0. It literally just locks up solid when 3.3 or 4.0 probes the machine during the install. No messages, no nothing. Using an IDE controller works fine. The blue screen with the grey probing window comes up and then the machine freezes, as if the probing got stuck somewhere. The machine is an Intel 486/33 with 485 cache board, 32 megs ram, Adaptec 1540 or generic IDE controller. It is a long shot, but I am curious if anyone knows of any problems in using the Adaptec 1540A on 3.x or 4.x machines? Any insights or suggestions are appreciated. Thanks Bob To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current Uncompilable? Attn: Greg Lehey
Greg, thanks for your help, no i didn't get the heads up because i just got onto the current list, but i should get them now if any occur. I'll try building current again Thanks Bill [EMAIL PROTECTED] - Original Message - From: Greg Lehey <[EMAIL PROTECTED]> To: Bill A. K. <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 1:04 AM Subject: Re: Current Uncompilable? Attn: Greg Lehey > [Format recovered--see http://www.lemis.com/email/email-format.html] > > On Sunday, 3 October 1999 at 23:47:24 -0400, Bill A. K. wrote: > > On Sunday, October 03, 1999 8:54 PM, Greg Lehey <[EMAIL PROTECTED]> wrote: > > > >> On Sunday, 3 October 1999 at 19:51:21 -0400, Bill A. K. wrote: > >>> Hi Everybody, > >>> my -current dosen't want to build today. it's failing with a > >>> signal 12 on libgcc1.c (or could it be libgccl.c)? Anybody else > >>> have these problems today? As of about 30-45 minutes ago when I > >>> tried CVsuping again, there was so changes to the libs or > >>> anything that I think could be this. > >> > >> Have you built a new kernel first? > > > > Greg, > > Thanks, I'll try that.However I was under the impression > > that I am supposed to make the world first..has this changed > > recently? > > Yes. Didn't you read the HEADS UP from Marcel Moolenaar a few days > ago? > > > I was following the instructions on how to make the world/ how to > > stay current in the handbook. I believe the make world document is > > based directly on "Making the World Your Own" (it is just about > > identical). > > Well, one of the things about how to stay current is to read the > messages posted on -CURRENT, especially if they have a subject line > like "HEADS UP: sigset_t changes committed". > > > Just to review the steps: > > > > i'm running 3.2-RELEASE > > > > i cvsup to 4.0-CURRENT > > > > i build a new kernel from the new 4.0 sources. > > > > i install the kernel and reboot > > > > i make and install the world > > > > Please let me know if this is correct. > > You might have trouble upgrading at all. You've certainly chosen an > unlucky time to upgrade to -CURRENT. At the moment you're supposed to > build a new kernel first so that it understands the new signal system > calls. Try it and see what it says. > > > P.S. Is your lemis.com mail system set to reject mail from @yahoo.com > > addresses? > > Yes. It also says why: > > Oct 4 13:05:00 freebie sendmail[51972]: NAA51972: ruleset=check_mail, arg1=<[EMAIL PROTECTED]>, relay=www.keycomp.net [207.44.1.33], reject=550 <[EMAIL PROTECTED]>... Mail rejected. See http://www.lemis.com/dontspam.html > > Greg > -- > When replying to this message, please take care not to mutilate the > original text. > For more information, see http://www.lemis.com/email.html > See complete headers for address, home page and phone numbers > finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic(8) implementation...
While testing the new swopen() routine I found this panic(8) implementation on -current: hexdump -C < /dev/drum -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Heads up!
And the crowd goes wild! Nick > > We have now come so far that we can start to kill cdevsw_add() > calls and rely on make_dev() for most of the device drivers. > > Later today I will add a "nagging printf", which will trigger when > a device is opened, which wasn't registered by the device driver > with make_dev(). It will only trigger once per driver per boot. > > If you see messages along the line of: > > WARNING: driver foo should register devices with make_dev() > > Please let me and the drivers maintainer know. > > Disk drivers will still be treated slightly special treatment, so > they will be exempt from this warning for now. > > Background Information: > > This is all part of the long push for DEVFS, before DEVFS can become > a reality, we need all dev_t's to be created specifically with > make_dev() so their name is available to DEVFS. > > > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: malloc type lacks magic
Hello It looks like I fucked my -current box up during the sig_t changes. I tried made a new kernel before make world but after ifconfig'ing the network interfaces it panics with: panic: malloc type lacks magic Making a new world is of course not possible because of the sig_t changes. Any ideas what is going wrong? I'm a little bit lost at this. Thanks -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernel hangs during boot with pnp sio.
It seems Timo Geusch wrote: > On Fri, Oct 01, 1999 at 02:32:11PM +0200, Soren Schmidt wrote: > > Hmm, I also have severe problems with the PnP stuff and my 3C509 > > cards, it just wont work as the pnp code finds and allocates > > adresses for the card, but the card probe doesn't pick them up... > > Soren, > AFAIK the ep driver does not interact with PnP, does it? Those cards do have > two different methods for detecting the parameters, one of which is PnP. > If the driver hasn't changed much in the last two-three months is doesn't know > about PnP at all. PnP-like config entries used to work via the old 3Com- > specific configuration mechanism. Correct, but if one has pnp0 in the kernel it doesn work no matter how you config it (or at least I cannot get it to work).. > I do have an updated/changed driver that uses Pnp to configure the card but I > am not able to work on it until mid next week. Also it exposes problems > which I believe are in my changes or side-effects from the apparent buggyness > of the original driver. > If you're interested I can send you the source code for the driver but it is > not clear if it works on -current at the moment as I haven't updated for > some time. Sure, I can try it out here, and maybe help a little (time permitting)... -Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Heads up!
In message <[EMAIL PROTECTED]>, Darren Reed writes : >In some email I received from Poul-Henning Kamp, sie wrote: >> >> >> We have now come so far that we can start to kill cdevsw_add() >> calls and rely on make_dev() for most of the device drivers. >[...] > >Is that make_dev() meant to make makedev() or is that a part of the >transition you're helping along here ? Wonderfully distinct names... make_dev() basically does a makedev() and registers the name and cdevsw on the dev_t. In addtion it transports the uid, gid and mode args to DEVFS if available. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Heads up!
In some email I received from Poul-Henning Kamp, sie wrote: > > > We have now come so far that we can start to kill cdevsw_add() > calls and rely on make_dev() for most of the device drivers. [...] Is that make_dev() meant to make makedev() or is that a part of the transition you're helping along here ? Wonderfully distinct names... Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernel hangs during boot with pnp sio.
On Fri, Oct 01, 1999 at 02:32:11PM +0200, Soren Schmidt wrote: > Hmm, I also have severe problems with the PnP stuff and my 3C509 > cards, it just wont work as the pnp code finds and allocates > adresses for the card, but the card probe doesn't pick them up... Soren, AFAIK the ep driver does not interact with PnP, does it? Those cards do have two different methods for detecting the parameters, one of which is PnP. If the driver hasn't changed much in the last two-three months is doesn't know about PnP at all. PnP-like config entries used to work via the old 3Com- specific configuration mechanism. I do have an updated/changed driver that uses Pnp to configure the card but I am not able to work on it until mid next week. Also it exposes problems which I believe are in my changes or side-effects from the apparent buggyness of the original driver. If you're interested I can send you the source code for the driver but it is not clear if it works on -current at the moment as I haven't updated for some time. Timo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Heads up!
We have now come so far that we can start to kill cdevsw_add() calls and rely on make_dev() for most of the device drivers. Later today I will add a "nagging printf", which will trigger when a device is opened, which wasn't registered by the device driver with make_dev(). It will only trigger once per driver per boot. If you see messages along the line of: WARNING: driver foo should register devices with make_dev() Please let me and the drivers maintainer know. Disk drivers will still be treated slightly special treatment, so they will be exempt from this warning for now. Background Information: This is all part of the long push for DEVFS, before DEVFS can become a reality, we need all dev_t's to be created specifically with make_dev() so their name is available to DEVFS. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Issues with xl0
On Sun, 03 Oct 1999 08:09:49 -0300, Bryan Bursey wrote: > Can anyone tell me if there are known issues with the xl0 driver in 4.0, > or if it has been superceded by another driver which works with 3Com > 3C900B. That's a pretty broad question. I know that lots of people use the xl0 driver in CURRENT quite happily. To me, it sounds more like you used a mismatched sysinstall to try to install FreeBSD. This is known to be problematic, because there are new things in later releases that older sysinstall's didn't know about. You'll want to look at your netowkr configuration in /etc/rc.conf. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernel hangs during boot with pnp sio.
On Sun, 3 Oct 1999, Daniel Eischen wrote: > Doug Rabson wrote: > > I looked at you pnpinfo again and I think this change might be better. It > > accepts the cards description instead of overriding it and adds another ID > > for SUP2080 which your card is compatible with. I also removed the bogus > > descriptions for the USR3031 since the pnpinfo for that also supplies a > > reasonable description. > > Kurt D. Zeilenga wrote: > > I provided a patch for the USR2030 that likely could be > > committed at the same time. See kern/13983. > > OK, I committed both of these changes. Thanks to you both. > I'll look at closing PR kern/13983. Thanks for picking this up Dan. I'm glad we got your system working. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new signal stuff breaks libc_r?
Alfred Perlstein wrote:
>
> Since the signal changes...
>
> I'm finding that it _seems_ since libc_r isn't including something
> that properly defines __inline to inline that i'm getting unresolved
> symbols when linking or running programs that depend on libc_r.
>
> Anyone else getting this?
>
> compiling a void main(void){} with -pthread will barf for me,
> using -static I'm able to see which files are missing which
> inlines.
This isn't a problem report I can deal with. Please be very explicit.
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
