Re: Stop in /usr/src/sys/modules/harp
I have commited the missing file just now. Sorry for that. harti On Mon, 21 Jul 2003, Xaos wrote: X>-BEGIN PGP SIGNED MESSAGE- X>Hash: SHA1 X> X>I keep getting this error when compiling a freshly cvsup'd source. 5.1-Current X> X>/usr/src/sys/dev/harp/if_harp.c:128: `VENDAPI_FORE_2' undeclared here (not in X>a function) X>/usr/src/sys/dev/harp/if_harp.c:128: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for X>`map_devs[2].api') X>/usr/src/sys/dev/harp/if_harp.c:128: `DEV_FORE_HE155' undeclared here (not in X>a function) X>/usr/src/sys/dev/harp/if_harp.c:128: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for X>`map_devs[2].dev') X>/usr/src/sys/dev/harp/if_harp.c:128: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for X>`map_devs[2]') X>/usr/src/sys/dev/harp/if_harp.c:130: `VENDAPI_FORE_2' undeclared here (not in X>a function) X>/usr/src/sys/dev/harp/if_harp.c:130: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for X>`map_devs[3].api') X>/usr/src/sys/dev/harp/if_harp.c:130: `DEV_FORE_HE622' undeclared here (not in X>a function) X>/usr/src/sys/dev/harp/if_harp.c:130: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for X>`map_devs[3].dev') X>/usr/src/sys/dev/harp/if_harp.c:130: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for X>`map_devs[3]') X>/usr/src/sys/dev/harp/if_harp.c:132: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:132: (near initialization for X>`map_devs[4]') X>/usr/src/sys/dev/harp/if_harp.c:134: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:134: (near initialization for X>`map_devs[5]') X>/usr/src/sys/dev/harp/if_harp.c:136: `DEV_FORE_LE25' undeclared here (not in a X>function) X>/usr/src/sys/dev/harp/if_harp.c:136: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:136: (near initialization for X>`map_devs[6].dev') X>/usr/src/sys/dev/harp/if_harp.c:136: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:136: (near initialization for X>`map_devs[6]') X>/usr/src/sys/dev/harp/if_harp.c:138: `DEV_FORE_LE155' undeclared here (not in X>a function) X>/usr/src/sys/dev/harp/if_harp.c:138: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:138: (near initialization for X>`map_devs[7].dev') X>/usr/src/sys/dev/harp/if_harp.c:138: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:138: (near initialization for X>`map_devs[7]') X>/usr/src/sys/dev/harp/if_harp.c:140: `DEV_IDT_25' undeclared here (not in a X>function) X>/usr/src/sys/dev/harp/if_harp.c:140: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:140: (near initialization for X>`map_devs[8].dev') X>/usr/src/sys/dev/harp/if_harp.c:140: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:140: (near initialization for X>`map_devs[8]') X>/usr/src/sys/dev/harp/if_harp.c:142: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:142: (near initialization for X>`map_devs[9]') X>/usr/src/sys/dev/harp/if_harp.c:144: `VENDAPI_IDT_2' undeclared here (not in a X>function) X>/usr/src/sys/dev/harp/if_harp.c:144: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for X>`map_devs[10].api') X>/usr/src/sys/dev/harp/if_harp.c:144: `DEV_IDTABR_25' undeclared here (not in a X>function) X>/usr/src/sys/dev/harp/if_harp.c:144: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for X>`map_devs[10].dev') X>/usr/src/sys/dev/harp/if_harp.c:144: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for X>`map_devs[10]') X>/usr/src/sys/dev/harp/if_harp.c:146: `VENDAPI_IDT_2' undeclared here (not in a X>function) X>/usr/src/sys/dev/harp/if_harp.c:146: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:146: (near initialization for X>`map_devs[11].api') X>/usr/src/sys/dev/harp/if_harp.c:146: `DEV_IDTABR_155' undeclared here (not in X>a function) X>/usr/src/sys/dev/harp/if_harp.c:146: initializer element is not X>constant/usr/src/sys/dev/harp/if_harp.c:146: (near initialization for X>`map_devs X> X>- -Tom X>- -- X>"Death is merciful, for there is no return X>therefrom, but with him who has come back X>out of the nethermost chambers of night, X>haggard and knowing, peace rests nevermore" X>- -Lovecraft X>-BEGIN PGP SIGNATURE- X>Version: GnuPG v1.2.2 (FreeBSD) X> X>iD8DBQE/HKwQ4yFLRHBUZMwRAtAKAKC+DXMotlpa/s7c5R50WfvFneQ/HQCgkH9e X>w/az+o+YtNHT95L9apqLPq8= X>=Kewt X>-END PGP SIGNATURE- X> X>___ X>[EMAIL PROTECTED] mailing list X>http://lists.freebsd.org/mailman/listinfo/freebsd-current X>To unsubscribe, send any mail to "
Re: [-CURRENT tinderbox] failure on i386/i386
Dag-Erling Smørgrav wrote: > Peter Wemm <[EMAIL PROTECTED]> writes: > > Hmm. I thought it was gzip that was dying. Looks like its make instead, and > > is rather consistent. > > "told you so" > > > So, who has been messing with make(1) lately? > > I believe that the problem is in the kernel, not in make(1); it just > happens to be triggered by make(1) because it is a big (if not the > biggest) vfork(2) consumer. It's pretty evil, too. It makes all sorts of system calls that it ought not to be making (i.e. it's permitted to call execve(2) or _exit(2), and that's all, period: all other system calls have undefined behaviour, according to the standards). It's really *very* tempting to set up a "vfork(2) system call table" that has only those two system calls in it, and returns "ENOSYS" for everything else, to catch the idiots who think that "vfork() is just like fork(), only faster". Most likely, it's hitting a race in dup2(2) or write(2) or close(2) or one of the other system calls it calls between the vfork(2) and the execve(2)/_exit(2). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on i386/pc98
Sorry, I failed to commit one of the files. Should work now. harti On Mon, 21 Jul 2003, Tinderbox wrote: T>TB --- 2003-07-21 19:01:13 - starting CURRENT tinderbox run for i386/pc98 T>TB --- 2003-07-21 19:01:13 - checking out the source tree T>TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 T>TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src T>TB --- 2003-07-21 19:03:15 - building world T>TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src T>TB --- /usr/bin/make -B buildworld T Rebuilding the temporary build tree T stage 1: legacy release compatibility shims T stage 1: bootstrap tools T stage 2: cleaning up the object tree T stage 2: rebuilding the object tree T stage 2: build tools T stage 3: cross tools T stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include T stage 4: building libraries T stage 4: make dependencies T stage 4: building everything.. T>TB --- 2003-07-21 20:02:20 - building generic kernel T>TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src T>TB --- /usr/bin/make buildkernel KERNCONF=GENERIC T Kernel build for GENERIC started on Mon Jul 21 20:02:20 GMT 2003 T>[...] T>/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: initializer element is not constant T>/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: (near initialization for `map_devs[13].dev') T>/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: initializer element is not constant T>/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: (near initialization for `map_devs[13]') T>/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c: In function `harp_attach': T>/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: `MEDIA_UTP25' undeclared (first use in this function) T>/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: (Each undeclared identifier is reported only once T>/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: for each function it appears in.) T>*** Error code 1 T> T>Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/harp. T>*** Error code 1 T> T>Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules. T>*** Error code 1 T> T>Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. T>*** Error code 1 T> T>Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. T>*** Error code 1 T> T>Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. T>TB --- 2003-07-21 20:09:36 - /usr/bin/make returned exit code 1 T>TB --- 2003-07-21 20:09:36 - ERROR: failed to build generic kernel T>TB --- 2003-07-21 20:09:36 - tinderbox aborted T> T>___ T>[EMAIL PROTECTED] mailing list T>http://lists.freebsd.org/mailman/listinfo/freebsd-current T>To unsubscribe, send any mail to "[EMAIL PROTECTED]" T> -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
Hi Thanks for your response, I do not have PAE enabled... I've been hesitant of turning it on, I'm not sure if it's too stable, I noticed that the asr driver is in the nodriver list in the PAE kernel config file and I use the asr driver for my Adaptec 2015S raid card. If you think its safe to enable PAE with my current setup, please let me know, I do have 2 more gig's of ram in this particular box that I'd like to enable if it doesn't compromise system stability. I will re-compile the kernel with the kern_malloc.c as you suggested, however I see that 1.126 fixes a PAE issue, so I'm not sure if that's going to help me out much. Where can I get information on how to get my kernel to provide a stack trace? I have done little of this type of troubleshooting, but would like to provide as much info before I'm forced to revert to 4.8-R in hopes to return stability to our system. If the new kernel with the updated kern_malloc.c doesn't help, I'll look at increasing the values you suggested. Thanks for the info, and I'll keep you posted with what I find. Thanks again, Stephane Raimbault - Original Message - From: "Bosko Milekic" <[EMAIL PROTECTED]> Newsgroups: mailing.freebsd.current Sent: Monday, July 21, 2003 16:36 Subject: Re: FreeBSD 5.1-R kernel panic > > On Mon, Jul 21, 2003 at 03:01:24PM -0600, Stephane Raimbault wrote: > > I'm running FreeBSD 5.1-RELEASE with the SMP kernel and ran across the > > following kernel panic. > > > > panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated > > > > I'm trying to figure out what could be causing this, what kind of > > information that I could provide to this group (or other group?) to see if > > this is a bug in FreeBSD that needs to be looked into? > > > > The box is basically a busy apache server... the kernel panic seemed to > > occur during the periodic daily was running. It seems to complete the > > 440.status-mailq part of periodic daily , but doesn't do > > 450.status-security. > > > > This isn't the first time the box has crashed at aprox. 3:01 am (when daily > > runs)... however this is the first time I've seend the kernel panic message > > quoted above in the /var/run/dmesg.boot file. > > > > I have attached the entire /var/run/dmesg.boot file to this message. > > > > What can I do to assist in identifiying and resolving this problem? > > > > Thanks, > > Stephane Raimbault. > > Just a few things: > > 1) Do you have PAE enabled? > > 2) Can you upgrade to src/sys/kern/kern_malloc.c version 1.126 or > upgrade to HEAD? > > If you have PAE enabled and (2) does not fix your problem, then please > post a stack trace that resulted in the panic. You also have a lot of > RAM so if (2) above does not fix your problem, try setting the > kern.vm.kmem.size bootable to approximately 350,000,000 or so (even > 400,000,000 is OK as long as NMBCLUSTERS is not too-too high). > > -- > Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] > TECHNOkRATIS Consulting Services * http://www.technokratis.com/ > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-07-22 04:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-22 04:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-22 04:02:19 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-07-22 05:06:23 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Jul 22 05:06:24 GMT 2003 [...] awk -f /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/alpha/clock_if.m -h awk -f /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/pci/alphapci_if.m -h awk -f /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/dec/mcclock_if.m -h if [ -f .olddep ]; then mv .olddep .depend; fi rm -f .newdep /home/des/tinderbox/CURRENT/alpha/alpha/obj/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/make.i386/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 -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/eisa/eisaconf.c:34:22: opt_eisa.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-07-22 05:07:21 - /usr/bin/make returned exit code 1 TB --- 2003-07-22 05:07:21 - ERROR: failed to build generic kernel TB --- 2003-07-22 05:07:21 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
any one running a rtl8201 phy tranceiver nic
If so could some one point me in the right direction for the right driver. thx ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stop in /usr/src/sys/modules/harp
On Mon, Jul 21, 2003 at 11:14:24PM -0400, Xaos wrote: > I keep getting this error when compiling a freshly cvsup'd source. 5.1-Current > > /usr/src/sys/dev/harp/if_harp.c:128: `VENDAPI_FORE_2' undeclared here (not in Me too. I decided to wait a few hours and see if it's been fixed. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Does linux-sun-jdk_1.4.2 work?
On Mon, 2003-07-21 at 22:35, Adam Migus wrote: > Perhaps you should try writing a port yourself before > you judge others on whether or not their ports are > released too early or not. > When you get your foot out of your mouth also try using > your full name in your email address too so people can > use it when calling you a pompous ass. I wouldn't want > people getting us confused... Eh, there's no need to flaming here. I never said maintaining Java on FreeBSD was easy. I said that Java support on FreeBSD is dodgy, which is really a well-known public fact, for anyone that's ever done any reading on the subject. In fact, when the core developers give a public interview, this is frequently a topic of discussion. Perhaps you should try working with Java 1.4.x on FreeBSD before you assume something about me that's highly inaccurate. I think you'll find very quickly that it doesn't work nicely unless the process is running as root. -- Adam <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
On Tue, Jul 22, 2003 at 12:18:31AM +0100, Bruce Cran wrote: > On Mon, Jul 21, 2003 at 06:43:11PM +, Bosko Milekic wrote: > > > > > > On Mon, Jul 21, 2003 at 06:24:07PM -0400, Mik Firestone wrote: > > > For what it is worth, I am having the exact same problem. I cvsup'd and > > > builtworld on Sunday, July 20, and my machine has been crashing about every > > > half-hour since. It starts slowing down, the load average begins to > > > climb until it eventually grinds to a halt. If I wait long enough, I > > > will see the same panic Stephane saw. > > > > > > Doing a ps -auxw shows that usb0 is using the vast majority of the CPU > > > time before the grinding halt. I have tried leaving the machine in > > > multi-user and sigle-user mode with the same results. I have attempted > > > to compile a new kernel that does not have the USB stuff compiled in, > > > but my machine won't stay running long enough. > > > > > > I do have the debugger compiled in, but I do not know enough of what I > > > am doing to provide reasonable information to the list. If somebody > > > can tell me the commands to run in the debugger, I will let my machine > > > panic again and grab that data. > > > > > > Mik > > > > Does reverting to pre-July 20 get rid of your problem? Note that the > > originator of the first Email mentionned that he is running what > > appeared to be stock 5.1-RELEASE, which may or may not be related to > > what you're seeing. > > > > If reverting to pre-July 20 gets rid of your problem, perhaps we can > > figure out what commit triggered this behavior for you. Also, do you > > have PAE enabled? > > > > It sounds like the same or similar problem reported in the 'USB crappiness' > thread - the system slows down, and then any command crashes the system with > the error about kmem. I posted a backtrace to the problem in usb_mem.c, and > the developer has posted a temporary fix - it was a problem with bus_dma, > it was allocating too much memory and running out of kernel memory. > > If the kernel debugger is compiled in, the system should drop to the db> > prompt when it panics. Type 'tr' and post the results it gives. This > panic appears to stop memory dumps working, otherwise you could set the > dumpdev variable in rc.conf also get > the source listing of where the problem occurs: the FreeBSD Developers Handbook > has more information. > > -- > Bruce Cran > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" Thanks! I found the thread in the archives and applied the patch. My machine is now up and seems to be much happier. Mik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Stop in /usr/src/sys/modules/harp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I keep getting this error when compiling a freshly cvsup'd source. 5.1-Current /usr/src/sys/dev/harp/if_harp.c:128: `VENDAPI_FORE_2' undeclared here (not in a function) /usr/src/sys/dev/harp/if_harp.c:128: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for `map_devs[2].api') /usr/src/sys/dev/harp/if_harp.c:128: `DEV_FORE_HE155' undeclared here (not in a function) /usr/src/sys/dev/harp/if_harp.c:128: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for `map_devs[2].dev') /usr/src/sys/dev/harp/if_harp.c:128: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for `map_devs[2]') /usr/src/sys/dev/harp/if_harp.c:130: `VENDAPI_FORE_2' undeclared here (not in a function) /usr/src/sys/dev/harp/if_harp.c:130: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for `map_devs[3].api') /usr/src/sys/dev/harp/if_harp.c:130: `DEV_FORE_HE622' undeclared here (not in a function) /usr/src/sys/dev/harp/if_harp.c:130: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for `map_devs[3].dev') /usr/src/sys/dev/harp/if_harp.c:130: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for `map_devs[3]') /usr/src/sys/dev/harp/if_harp.c:132: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:132: (near initialization for `map_devs[4]') /usr/src/sys/dev/harp/if_harp.c:134: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:134: (near initialization for `map_devs[5]') /usr/src/sys/dev/harp/if_harp.c:136: `DEV_FORE_LE25' undeclared here (not in a function) /usr/src/sys/dev/harp/if_harp.c:136: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:136: (near initialization for `map_devs[6].dev') /usr/src/sys/dev/harp/if_harp.c:136: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:136: (near initialization for `map_devs[6]') /usr/src/sys/dev/harp/if_harp.c:138: `DEV_FORE_LE155' undeclared here (not in a function) /usr/src/sys/dev/harp/if_harp.c:138: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:138: (near initialization for `map_devs[7].dev') /usr/src/sys/dev/harp/if_harp.c:138: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:138: (near initialization for `map_devs[7]') /usr/src/sys/dev/harp/if_harp.c:140: `DEV_IDT_25' undeclared here (not in a function) /usr/src/sys/dev/harp/if_harp.c:140: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:140: (near initialization for `map_devs[8].dev') /usr/src/sys/dev/harp/if_harp.c:140: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:140: (near initialization for `map_devs[8]') /usr/src/sys/dev/harp/if_harp.c:142: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:142: (near initialization for `map_devs[9]') /usr/src/sys/dev/harp/if_harp.c:144: `VENDAPI_IDT_2' undeclared here (not in a function) /usr/src/sys/dev/harp/if_harp.c:144: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for `map_devs[10].api') /usr/src/sys/dev/harp/if_harp.c:144: `DEV_IDTABR_25' undeclared here (not in a function) /usr/src/sys/dev/harp/if_harp.c:144: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for `map_devs[10].dev') /usr/src/sys/dev/harp/if_harp.c:144: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for `map_devs[10]') /usr/src/sys/dev/harp/if_harp.c:146: `VENDAPI_IDT_2' undeclared here (not in a function) /usr/src/sys/dev/harp/if_harp.c:146: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:146: (near initialization for `map_devs[11].api') /usr/src/sys/dev/harp/if_harp.c:146: `DEV_IDTABR_155' undeclared here (not in a function) /usr/src/sys/dev/harp/if_harp.c:146: initializer element is not constant/usr/src/sys/dev/harp/if_harp.c:146: (near initialization for `map_devs - -Tom - -- "Death is merciful, for there is no return therefrom, but with him who has come back out of the nethermost chambers of night, haggard and knowing, peace rests nevermore" - -Lovecraft -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/HKwQ4yFLRHBUZMwRAtAKAKC+DXMotlpa/s7c5R50WfvFneQ/HQCgkH9e w/az+o+YtNHT95L9apqLPq8= =Kewt -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Does linux-sun-jdk_1.4.2 work?
Adam said: > On Mon, 2003-07-21 at 08:55, Yamada Ken Takeshi wrote: >> I have the followinacquirer and cannot compile jdk14 >> on FreeBSD-current, July 20th. cvsup'ed with the >> latest >> linux_base. >> >> Is is unique to me alone? >> >> tyd3# /usr/local/linux-sun-jdk1.4.2/bin/java -version >> # >> # HotSpot Virtual Machine Error, Internal Error >> # Please report this error at >> # http://java.sun.com/cgi-bin/bugreport.cgi >> # >> # Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 >> mixed mode) >> # >> # Error ID: 4F533F4C494E55580E43505001C9 >> # >> >> Heap at VM Abort: >> Heap > > It happens to me too. Looks like this port was released > too quickly. > Java on FreeBSD is always a bit dodgy, it seems. > > -- > Adam <[EMAIL PROTECTED]> > Actually it's trying to aquire a lock on a file in the linux proc filesystem which is most likely failing because you have the Linux proc file system mounted read-only. Try mounting it read-write... Hm... [EMAIL PROTECTED]:ttyp0:amigus$ grep -ci [EMAIL PROTECTED] /src/freebsd/ports/INDEX 0 [EMAIL PROTECTED]:ttyp0:amigus$ Perhaps you should try writing a port yourself before you judge others on whether or not their ports are released too early or not. When you get your foot out of your mouth also try using your full name in your email address too so people can use it when calling you a pompous ass. I wouldn't want people getting us confused... Regards, -- Adam Migus - Research Scientist Network Associates Laboratories (http://www.nailabs.com) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on i386/i386
Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= wrote: > Peter Wemm <[EMAIL PROTECTED]> writes: > > Hmm. I thought it was gzip that was dying. Looks like its make instead, a= > nd > > is rather consistent. > > "told you so" > > > So, who has been messing with make(1) lately? > > I believe that the problem is in the kernel, not in make(1); it just > happens to be triggered by make(1) because it is a big (if not the > biggest) vfork(2) consumer. For a minute I had a horrible thought that it might have been a consequence of the lazy switch stuff. But the kernel on cueball predates the turn-on and doesn't have the options enabled. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP and setrunnable()- scheduler 4bsd
On Tue, 22 Jul 2003, Andy Farkas wrote: > > Mr Wolf, > > Heh, you noticed :) > > > > Currently (cpu_idle_hlt=1) the load is fluctuating between 2.20 and 3.60 > > > every few minutes! (xload looks like a graph of a sinewave) > > > > > > If I set cpu_idle_hlt back to 0 the load goes back to a steady 3.80 where > > > it should be. > > > > define "should". > > When all 3 seti's get their "normal" 95% cpu time: the change MAY do what you want but it 'may not' you'll need to try it to see.. :-/ > > 32531 setiathome 139 15 16536K 15520K *Giant 1 60.9H 95.85% 95.85% setiathome > 32533 setiathome 139 15 16856K 16032K CPU3 3 61.0H 95.65% 95.65% setiathome > 32532 setiathome 139 15 15524K 14912K CPU2 2 60.8H 95.51% 95.51% setiathome > 54738 andyf 1320 3084K 2140K *Giant 0 64:54 83.84% 83.84% ssh >12 root -160 0K12K RUN2 133.4H 3.81% 3.81% idle: cpu2 >13 root -160 0K12K RUN1 131.7H 3.47% 3.47% idle: cpu1 >14 root -160 0K12K CPU0 0 130.8H 3.37% 3.37% idle: cpu0 >11 root -160 0K12K RUN3 135.2H 2.88% 2.88% idle: cpu3 > > As opposed to "abnormal" when cpu_idle_hlt=1: > > 32533 setiathome 139 15 15828K 15000K CPU1 2 61.0H 89.40% 89.40% setiathome > 32532 setiathome 139 15 16552K 15660K *Giant 2 60.8H 88.18% 88.18% setiathome > 54738 andyf 1300 3084K 2140K select 2 68:54 75.78% 75.78% ssh >13 root -160 0K12K RUN1 131.7H 29.05% 29.05% idle: cpu1 >12 root -160 0K12K CPU2 2 133.4H 28.08% 28.08% idle: cpu2 >11 root -160 0K12K CPU3 3 135.2H 27.83% 27.83% idle: cpu3 >14 root -160 0K12K RUN0 130.8H 26.37% 26.37% idle: cpu0 > 32531 setiathome 131 15 15640K 14976K *Giant 2 61.0H 20.51% 20.51% setiathome > > > -- > > :{ [EMAIL PROTECTED] > > Andy Farkas > System Administrator >Speednet Communications > http://www.speednet.com.au/ > > > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP and setrunnable()- scheduler 4bsd
> Mr Wolf, Heh, you noticed :) > > Currently (cpu_idle_hlt=1) the load is fluctuating between 2.20 and 3.60 > > every few minutes! (xload looks like a graph of a sinewave) > > > > If I set cpu_idle_hlt back to 0 the load goes back to a steady 3.80 where > > it should be. > > define "should". When all 3 seti's get their "normal" 95% cpu time: 32531 setiathome 139 15 16536K 15520K *Giant 1 60.9H 95.85% 95.85% setiathome 32533 setiathome 139 15 16856K 16032K CPU3 3 61.0H 95.65% 95.65% setiathome 32532 setiathome 139 15 15524K 14912K CPU2 2 60.8H 95.51% 95.51% setiathome 54738 andyf 1320 3084K 2140K *Giant 0 64:54 83.84% 83.84% ssh 12 root -160 0K12K RUN2 133.4H 3.81% 3.81% idle: cpu2 13 root -160 0K12K RUN1 131.7H 3.47% 3.47% idle: cpu1 14 root -160 0K12K CPU0 0 130.8H 3.37% 3.37% idle: cpu0 11 root -160 0K12K RUN3 135.2H 2.88% 2.88% idle: cpu3 As opposed to "abnormal" when cpu_idle_hlt=1: 32533 setiathome 139 15 15828K 15000K CPU1 2 61.0H 89.40% 89.40% setiathome 32532 setiathome 139 15 16552K 15660K *Giant 2 60.8H 88.18% 88.18% setiathome 54738 andyf 1300 3084K 2140K select 2 68:54 75.78% 75.78% ssh 13 root -160 0K12K RUN1 131.7H 29.05% 29.05% idle: cpu1 12 root -160 0K12K CPU2 2 133.4H 28.08% 28.08% idle: cpu2 11 root -160 0K12K CPU3 3 135.2H 27.83% 27.83% idle: cpu3 14 root -160 0K12K RUN0 130.8H 26.37% 26.37% idle: cpu0 32531 setiathome 131 15 15640K 14976K *Giant 2 61.0H 20.51% 20.51% setiathome -- :{ [EMAIL PROTECTED] Andy Farkas System Administrator Speednet Communications http://www.speednet.com.au/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on i386/i386
Peter Wemm <[EMAIL PROTECTED]> writes: > Hmm. I thought it was gzip that was dying. Looks like its make instead, and > is rather consistent. "told you so" > So, who has been messing with make(1) lately? I believe that the problem is in the kernel, not in make(1); it just happens to be triggered by make(1) because it is a big (if not the biggest) vfork(2) consumer. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP and setrunnable()- scheduler 4bsd
On Tue, 22 Jul 2003, Andy Farkas wrote: > On Wed, 9 Jul 2003, Terry Lambert wrote: > > Andy Farkas wrote: > > > On Tue, 8 Jul 2003, Julian Elischer wrote: > > > > It looks tp me that if we make a thread runnable > > > > and there is a processor in the idle loop, the idle processor should be > > > > kicked in some way to make it go get the newly runnable thread. > > > > > > Is this what's happenning to me an my setiathomes? > > > > The command: > > > > sysctl machdep.cpu_idle_hlt > > > > will tell you. If it says 1, then it may be the problem. If it > > says 0, then it's not the problem. You can explicitly set it to > > zero to disable halting in the idle loop. If you do this, your > > machine is likely to run ~20% hotter (depending on the CPU type), > > since HLT'ing an idle CPU tends to cool it off. > > > > If this fixes your problem, then it's likely that what's happening > > is that one or more of your CPU's are being idled until the clock > > or some other interrupt fires, at which point in time your setiathome > > processes are probably not the highest priority, as other things with > > higher priority have gotten in the run queue ahead of them. > > > > If this is the case, then Julian's suggested fix of an IPI to one or > > more idle CPU's when a process becomes ready-to-run will most likely > > be necessary to avoid this situation. > > Well, looks like machdep.cpu_idle_hlt affects the 4bsd scheduler. > > Julian, have your patches at http://www.freebsd.org/~julian/it.diff been > incorporated yet? SHould I try them? Mr Wolf, They are not incorporated.. you may try them (but I didn't see much difference) I would like to readress the issue some time. > > hummer# sysctl -a | grep kern.ver > kern.version: FreeBSD 5.1-RELEASE #0: Thu Jun 26 01:57:42 EST 2003 > hummer# sysctl -a | grep cpu > kern.threads.virtual_cpu: 4 > kern.ccpu: 1948 <--- whats this? no idea > kern.smp.cpus: 4 > hw.ncpu: 4 > machdep.cpu_idle_hlt: 0 > machdep.hlt_cpus: 0 > hummer# > hummer# vmstat -c 12 -w 10 > procs memory pagedisks faults cpu > r b w avmfre flt re pi po fr sr ad0 am0 in sy cs us sy id > 1 1 3 124804 20792 99 0 0 0 131 20 0 0 3620 544 33 3 64 > 2 1 2 125240 32460 197 0 0 0 358 258 0 1 3650 2161 67 26 7 > 2 1 2 124728 32204 214 0 0 0 249 0 0 1 3820 1280 72 23 5 > 1 1 3 124112 29652 257 0 0 0 247 0 3 1 4140 1571 70 25 5 > 3 1 1 124624 26020 236 0 0 0 297 0 0 1 3730 1367 70 24 7 > 2 1 2 124792 25464 222 0 0 0 266 0 2 1 4080 1308 72 24 4 > 3 1 1 123764 25172 203 0 0 0 227 0 0 1 3800 1053 72 23 5 > 3 1 2 124164 22004 229 0 0 0 264 0 0 1 3710 1164 72 25 3 > 3 1 2 124796 20232 208 0 0 0 262 0 1 1 3830 1269 72 23 5 > 3 1 1 123768 20448 225 0 0 0 252 0 0 1 3740 1306 72 25 3 > 3 1 0 122736 33736 214 0 0 0 458 194 0 1 3630 1341 72 24 4 > 3 1 1 123380 32008 236 0 0 0 222 0 2 1 4050 1430 72 25 4 > hummer# > hummer# sysctl machdep.cpu_idle_hlt=1 > machdep.cpu_idle_hlt: 0 -> 1 > hummer# vmstat -c 12 -w 10 > procs memory pagedisks faults cpu > r b w avmfre flt re pi po fr sr ad0 am0 in sy cs us sy id > 2 1 1 124760 20848 99 0 0 0 131 20 0 0 3620 544 33 3 64 > 1 1 3 123948 20844 157 0 0 0 191 0 0 1 3850 1142 51 21 28 > 2 1 2 124408 20472 134 0 0 0 176 0 0 1 3720 1118 48 22 30 > 2 1 1 124992 18800 179 0 0 0 181 0 1 2 3940 1147 49 20 31 > 2 2 3 123792 31228 162 0 0 0 367 196 0 1 3780 48 21 30 > 1 1 4 124348 30048 175 0 0 0 169 0 0 1 3680 1084 51 22 27 > 2 0 4 18 29140 142 0 0 0 193 0 1 2 3990 1056 53 21 26 > 2 1 2 124688 25324 176 0 0 0 135 0 0 1 3700 1138 47 21 31 > 2 1 1 122632 26572 136 0 0 0 209 0 0 1 3740 1110 50 21 30 > 2 1 2 122288 26036 162 0 0 0 193 0 1 2 3840 1152 49 22 29 > 2 1 2 122288 25204 136 0 0 0 157 0 0 1 3690 1101 50 21 29 > 2 1 2 122700 23720 172 0 0 0 183 0 0 1 3760 1123 48 21 31 > > Currently (cpu_idle_hlt=1) the load is fluctuating between 2.20 and 3.60 > every few minutes! (xload looks like a graph of a sinewave) > > If I set cpu_idle_hlt back to 0 the load goes back to a steady 3.80 where > it should be. define "should". > > -- > > :{ [EMAIL PROTECTED] > > Andy Farkas > System Administrator >Speednet Communications > http://www.speednet.com.au/ > > > > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail
Re: SMP and setrunnable()- scheduler 4bsd
On Wed, 9 Jul 2003, Terry Lambert wrote: > Andy Farkas wrote: > > On Tue, 8 Jul 2003, Julian Elischer wrote: > > > It looks tp me that if we make a thread runnable > > > and there is a processor in the idle loop, the idle processor should be > > > kicked in some way to make it go get the newly runnable thread. > > > > Is this what's happenning to me an my setiathomes? > > The command: > > sysctl machdep.cpu_idle_hlt > > will tell you. If it says 1, then it may be the problem. If it > says 0, then it's not the problem. You can explicitly set it to > zero to disable halting in the idle loop. If you do this, your > machine is likely to run ~20% hotter (depending on the CPU type), > since HLT'ing an idle CPU tends to cool it off. > > If this fixes your problem, then it's likely that what's happening > is that one or more of your CPU's are being idled until the clock > or some other interrupt fires, at which point in time your setiathome > processes are probably not the highest priority, as other things with > higher priority have gotten in the run queue ahead of them. > > If this is the case, then Julian's suggested fix of an IPI to one or > more idle CPU's when a process becomes ready-to-run will most likely > be necessary to avoid this situation. Well, looks like machdep.cpu_idle_hlt affects the 4bsd scheduler. Julian, have your patches at http://www.freebsd.org/~julian/it.diff been incorporated yet? SHould I try them? hummer# sysctl -a | grep kern.ver kern.version: FreeBSD 5.1-RELEASE #0: Thu Jun 26 01:57:42 EST 2003 hummer# sysctl -a | grep cpu kern.threads.virtual_cpu: 4 kern.ccpu: 1948 <--- whats this? kern.smp.cpus: 4 hw.ncpu: 4 machdep.cpu_idle_hlt: 0 machdep.hlt_cpus: 0 hummer# hummer# vmstat -c 12 -w 10 procs memory pagedisks faults cpu r b w avmfre flt re pi po fr sr ad0 am0 in sy cs us sy id 1 1 3 124804 20792 99 0 0 0 131 20 0 0 3620 544 33 3 64 2 1 2 125240 32460 197 0 0 0 358 258 0 1 3650 2161 67 26 7 2 1 2 124728 32204 214 0 0 0 249 0 0 1 3820 1280 72 23 5 1 1 3 124112 29652 257 0 0 0 247 0 3 1 4140 1571 70 25 5 3 1 1 124624 26020 236 0 0 0 297 0 0 1 3730 1367 70 24 7 2 1 2 124792 25464 222 0 0 0 266 0 2 1 4080 1308 72 24 4 3 1 1 123764 25172 203 0 0 0 227 0 0 1 3800 1053 72 23 5 3 1 2 124164 22004 229 0 0 0 264 0 0 1 3710 1164 72 25 3 3 1 2 124796 20232 208 0 0 0 262 0 1 1 3830 1269 72 23 5 3 1 1 123768 20448 225 0 0 0 252 0 0 1 3740 1306 72 25 3 3 1 0 122736 33736 214 0 0 0 458 194 0 1 3630 1341 72 24 4 3 1 1 123380 32008 236 0 0 0 222 0 2 1 4050 1430 72 25 4 hummer# hummer# sysctl machdep.cpu_idle_hlt=1 machdep.cpu_idle_hlt: 0 -> 1 hummer# vmstat -c 12 -w 10 procs memory pagedisks faults cpu r b w avmfre flt re pi po fr sr ad0 am0 in sy cs us sy id 2 1 1 124760 20848 99 0 0 0 131 20 0 0 3620 544 33 3 64 1 1 3 123948 20844 157 0 0 0 191 0 0 1 3850 1142 51 21 28 2 1 2 124408 20472 134 0 0 0 176 0 0 1 3720 1118 48 22 30 2 1 1 124992 18800 179 0 0 0 181 0 1 2 3940 1147 49 20 31 2 2 3 123792 31228 162 0 0 0 367 196 0 1 3780 48 21 30 1 1 4 124348 30048 175 0 0 0 169 0 0 1 3680 1084 51 22 27 2 0 4 18 29140 142 0 0 0 193 0 1 2 3990 1056 53 21 26 2 1 2 124688 25324 176 0 0 0 135 0 0 1 3700 1138 47 21 31 2 1 1 122632 26572 136 0 0 0 209 0 0 1 3740 1110 50 21 30 2 1 2 122288 26036 162 0 0 0 193 0 1 2 3840 1152 49 22 29 2 1 2 122288 25204 136 0 0 0 157 0 0 1 3690 1101 50 21 29 2 1 2 122700 23720 172 0 0 0 183 0 0 1 3760 1123 48 21 31 Currently (cpu_idle_hlt=1) the load is fluctuating between 2.20 and 3.60 every few minutes! (xload looks like a graph of a sinewave) If I set cpu_idle_hlt back to 0 the load goes back to a steady 3.80 where it should be. -- :{ [EMAIL PROTECTED] Andy Farkas System Administrator Speednet Communications http://www.speednet.com.au/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
On Mon, Jul 21, 2003 at 06:43:11PM +, Bosko Milekic wrote: > > > On Mon, Jul 21, 2003 at 06:24:07PM -0400, Mik Firestone wrote: > > For what it is worth, I am having the exact same problem. I cvsup'd and > > builtworld on Sunday, July 20, and my machine has been crashing about every > > half-hour since. It starts slowing down, the load average begins to > > climb until it eventually grinds to a halt. If I wait long enough, I > > will see the same panic Stephane saw. > > > > Doing a ps -auxw shows that usb0 is using the vast majority of the CPU > > time before the grinding halt. I have tried leaving the machine in > > multi-user and sigle-user mode with the same results. I have attempted > > to compile a new kernel that does not have the USB stuff compiled in, > > but my machine won't stay running long enough. > > > > I do have the debugger compiled in, but I do not know enough of what I > > am doing to provide reasonable information to the list. If somebody > > can tell me the commands to run in the debugger, I will let my machine > > panic again and grab that data. > > > > Mik > > Does reverting to pre-July 20 get rid of your problem? Note that the > originator of the first Email mentionned that he is running what > appeared to be stock 5.1-RELEASE, which may or may not be related to > what you're seeing. > > If reverting to pre-July 20 gets rid of your problem, perhaps we can > figure out what commit triggered this behavior for you. Also, do you > have PAE enabled? > It sounds like the same or similar problem reported in the 'USB crappiness' thread - the system slows down, and then any command crashes the system with the error about kmem. I posted a backtrace to the problem in usb_mem.c, and the developer has posted a temporary fix - it was a problem with bus_dma, it was allocating too much memory and running out of kernel memory. If the kernel debugger is compiled in, the system should drop to the db> prompt when it panics. Type 'tr' and post the results it gives. This panic appears to stop memory dumps working, otherwise you could set the dumpdev variable in rc.conf also get the source listing of where the problem occurs: the FreeBSD Developers Handbook has more information. -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
On Mon, Jul 21, 2003 at 06:24:07PM -0400, Mik Firestone wrote: > For what it is worth, I am having the exact same problem. I cvsup'd and > builtworld on Sunday, July 20, and my machine has been crashing about every > half-hour since. It starts slowing down, the load average begins to > climb until it eventually grinds to a halt. If I wait long enough, I > will see the same panic Stephane saw. > > Doing a ps -auxw shows that usb0 is using the vast majority of the CPU > time before the grinding halt. I have tried leaving the machine in > multi-user and sigle-user mode with the same results. I have attempted > to compile a new kernel that does not have the USB stuff compiled in, > but my machine won't stay running long enough. > > I do have the debugger compiled in, but I do not know enough of what I > am doing to provide reasonable information to the list. If somebody > can tell me the commands to run in the debugger, I will let my machine > panic again and grab that data. > > Mik Does reverting to pre-July 20 get rid of your problem? Note that the originator of the first Email mentionned that he is running what appeared to be stock 5.1-RELEASE, which may or may not be related to what you're seeing. If reverting to pre-July 20 gets rid of your problem, perhaps we can figure out what commit triggered this behavior for you. Also, do you have PAE enabled? -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-07-21 21:33:41 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-07-21 21:33:41 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-21 21:35:42 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-07-21 22:32:13 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Jul 21 22:32:13 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:150: error: initializer element is not constant /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:150: error: (near initialization for `map_devs[13].dev') /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:150: error: initializer element is not constant /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:150: error: (near initialization for `map_devs[13]') /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c: In function `harp_attach': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:412: error: `MEDIA_UTP25' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:412: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:412: error: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/harp. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-07-21 22:38:29 - /usr/bin/make returned exit code 1 TB --- 2003-07-21 22:38:29 - ERROR: failed to build generic kernel TB --- 2003-07-21 22:38:29 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
On Mon, Jul 21, 2003 at 03:01:24PM -0600, Stephane Raimbault wrote: > I'm running FreeBSD 5.1-RELEASE with the SMP kernel and ran across the > following kernel panic. > > panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated > > I'm trying to figure out what could be causing this, what kind of > information that I could provide to this group (or other group?) to see if > this is a bug in FreeBSD that needs to be looked into? > > The box is basically a busy apache server... the kernel panic seemed to > occur during the periodic daily was running. It seems to complete the > 440.status-mailq part of periodic daily , but doesn't do > 450.status-security. > > This isn't the first time the box has crashed at aprox. 3:01 am (when daily > runs)... however this is the first time I've seend the kernel panic message > quoted above in the /var/run/dmesg.boot file. > > I have attached the entire /var/run/dmesg.boot file to this message. > > What can I do to assist in identifiying and resolving this problem? > > Thanks, > Stephane Raimbault. Just a few things: 1) Do you have PAE enabled? 2) Can you upgrade to src/sys/kern/kern_malloc.c version 1.126 or upgrade to HEAD? If you have PAE enabled and (2) does not fix your problem, then please post a stack trace that resulted in the panic. You also have a lot of RAM so if (2) above does not fix your problem, try setting the kern.vm.kmem.size bootable to approximately 350,000,000 or so (even 400,000,000 is OK as long as NMBCLUSTERS is not too-too high). -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
For what it is worth, I am having the exact same problem. I cvsup'd and builtworld on Sunday, July 20, and my machine has been crashing about every half-hour since. It starts slowing down, the load average begins to climb until it eventually grinds to a halt. If I wait long enough, I will see the same panic Stephane saw. Doing a ps -auxw shows that usb0 is using the vast majority of the CPU time before the grinding halt. I have tried leaving the machine in multi-user and sigle-user mode with the same results. I have attempted to compile a new kernel that does not have the USB stuff compiled in, but my machine won't stay running long enough. I do have the debugger compiled in, but I do not know enough of what I am doing to provide reasonable information to the list. If somebody can tell me the commands to run in the debugger, I will let my machine panic again and grab that data. Mik On Mon, Jul 21, 2003 at 03:01:24PM -0600, Stephane Raimbault wrote: > I'm running FreeBSD 5.1-RELEASE with the SMP kernel and ran across the > following kernel panic. > > panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated > > I'm trying to figure out what could be causing this, what kind of > information that I could provide to this group (or other group?) to see if > this is a bug in FreeBSD that needs to be looked into? > > The box is basically a busy apache server... the kernel panic seemed to > occur during the periodic daily was running. It seems to complete the > 440.status-mailq part of periodic daily , but doesn't do > 450.status-security. > > This isn't the first time the box has crashed at aprox. 3:01 am (when daily > runs)... however this is the first time I've seend the kernel panic message > quoted above in the /var/run/dmesg.boot file. > > I have attached the entire /var/run/dmesg.boot file to this message. > > What can I do to assist in identifiying and resolving this problem? > > Thanks, > Stephane Raimbault. > %cat /var/run/dmesg.boot > 76.232.138 in via em0 > panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated > cpuid = 0; lapic.id = > boot() called on cpu#0 > > syncing disks, buffers remaining... 7154 7154 7153 7153 7153 7153 7154 7152 7152 > 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 > 7152 > Copyright (c) 1992-2003 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.1-RELEASE #0: Fri Jun 20 18:36:54 MDT 2003 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SRV2 > Preloaded elf kernel "/boot/kernel/kernel" at 0xc06ef000. > Preloaded elf module "/boot/kernel/ipfw.ko" at 0xc06ef2e4. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06ef390. > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 2399328676 Hz > CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 > > Features=0xbfebfbff > Hyperthreading: 2 logical CPUs > real memory = 4160225280 (3967 MB) > avail memory = 4045828096 (3858 MB) > Programming 24 pins in IOAPIC #0 > IOAPIC #0 intpin 2 -> irq 0 > Programming 24 pins in IOAPIC #1 > Programming 24 pins in IOAPIC #2 > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 > cpu1 (AP): apic id: 6, version: 0x00050014, at 0xfee0 > cpu2 (AP): apic id: 1, version: 0x00050014, at 0xfee0 > cpu3 (AP): apic id: 7, version: 0x00050014, at 0xfee0 > io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 > io1 (APIC): apic id: 3, version: 0x00178020, at 0xfec8 > io2 (APIC): apic id: 4, version: 0x00178020, at 0xfec80400 > Pentium Pro MTRR support enabled > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > pcibios: BIOS version 2.10 > Using $PIR table, 24 entries at 0xc00fde40 > acpi0: power button is handled as a fixed feature programming model. > Timecounter "ACPI-fast" frequency 3579545 Hz > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_cpu0: on acpi0 > acpi_cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > IOAPIC #0 intpin 16 -> irq 2 > IOAPIC #0 intpin 19 -> irq 10 > IOAPIC #0 intpin 18 -> irq 11 > pcib1: at device 2.0 on pci0 > pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.HLB_ - AE_NOT_FOUND > pci1: on pcib1 > pci1: at device 28.0 (no driver attached) > pcib2: at device 29.0 on pci1 > pci2: on pcib2 > IOAPIC #2 intpin 6 -> irq 16 > IOAPIC #2 intpin 7 -> irq 17 > em0: port 0x3000-0x303f mem > 0xf820-0xf821 irq 16 at device 3.0 on pci2 > em0: Speed:100 Mbps Duplex:Half > em1: port 0x3040-0x307f mem > 0xf822-0xf823 irq 17 at device 3.1 on pci2 > em1: Speed:1000 Mbps Duplex:Full > pci1: at device 30.0 (no driver attached) > pcib3: at device 31.0 on pci1 > pci3: o
Re: Does linux-sun-jdk_1.4.2 work?
I still get # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode) # # Error ID: 4F533F4C494E55583F491418160E43505002EF # Heap at VM Abort: Heap (and here it hangs, and I kill -9 from another window) And I do have linprocfs mounted. -Charlie On Mon, Jul 21, 2003 at 05:37:36PM +0200, Florian Smeets wrote: > Adam wrote: > >On Mon, 2003-07-21 at 08:55, Yamada Ken Takeshi wrote: > > > >>tyd3# /usr/local/linux-sun-jdk1.4.2/bin/java -version > >># > >># HotSpot Virtual Machine Error, Internal Error > >># Please report this error at > >># http://java.sun.com/cgi-bin/bugreport.cgi > >># > >># Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode) > >># > >># Error ID: 4F533F4C494E55580E43505001C9 > >># > >> > >>Heap at VM Abort: > >>Heap > > > > > >It happens to me too. Looks like this port was released too quickly. > >Java on FreeBSD is always a bit dodgy, it seems. > > > Hi, > > try mounting linprocfs(5) that seemed to solved the problem for me. > > regards, > flo > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-java > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Charles Andersoncaa at columbus dot rr dot com No quote, no nothin' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on i386/i386
Mark Murray wrote: > Peter Wemm writes: > > Tinderbox wrote: > > > > > gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls /c > > at > > gets.3 > catgets.3.gz > > > Segmentation fault (core dumped) > > > *** Error code 139 > > > > These false alarms are wearing a bit thin. Is there a problem with the > > tinderbox build machine perhaps? > > My home box is doing it too. as(1) blowing up "randomly". No usable core > dumps. :-(. Hmm. I thought it was gzip that was dying. Looks like its make instead, and is rather consistent. > grep dump /var/log/messages Jul 20 14:14:52 cueball kernel: pid 34706 (make), uid 722: exited on signal 11 (core dumped) Jul 20 14:56:35 cueball kernel: pid 16740 (make), uid 722: exited on signal 11 (core dumped) Jul 20 18:32:07 cueball kernel: pid 6784 (make), uid 722: exited on signal 11 (core dumped) Jul 21 00:43:54 cueball kernel: pid 85754 (make), uid 722: exited on signal 11 (core dumped) Jul 21 15:01:12 cueball kernel: pid 51790 (make), uid 722: exited on signal 10 (core dumped) So, who has been messing with make(1) lately? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on ia64/ia64
TB --- 2003-07-21 20:09:36 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-07-21 20:09:36 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-21 20:11:47 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-07-21 21:23:38 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Jul 21 21:23:38 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:150: error: initializer element is not constant /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:150: error: (near initialization for `map_devs[13].dev') /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:150: error: initializer element is not constant /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:150: error: (near initialization for `map_devs[13]') /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c: In function `harp_attach': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:412: error: `MEDIA_UTP25' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:412: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:412: error: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules/harp. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-07-21 21:33:40 - /usr/bin/make returned exit code 1 TB --- 2003-07-21 21:33:40 - ERROR: failed to build generic kernel TB --- 2003-07-21 21:33:40 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
msdosfs causes system panic under CURRENT and on 4.8-RELEASE
I have an image of floppy disk formatted under win2k that causes system panic under CURRENT and on 4.8-RELEASE. This hapens after I mount the image (via vnode or directly from floppy) and do 'ls' of one of directories on the image. If somebody wants to fix the bug - send me an e-mail and I will send the image. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 5.1-R kernel panic
I'm running FreeBSD 5.1-RELEASE with the SMP kernel and ran across the following kernel panic. panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated I'm trying to figure out what could be causing this, what kind of information that I could provide to this group (or other group?) to see if this is a bug in FreeBSD that needs to be looked into? The box is basically a busy apache server... the kernel panic seemed to occur during the periodic daily was running. It seems to complete the 440.status-mailq part of periodic daily , but doesn't do 450.status-security. This isn't the first time the box has crashed at aprox. 3:01 am (when daily runs)... however this is the first time I've seend the kernel panic message quoted above in the /var/run/dmesg.boot file. I have attached the entire /var/run/dmesg.boot file to this message. What can I do to assist in identifiying and resolving this problem? Thanks, Stephane Raimbault. %cat /var/run/dmesg.boot 76.232.138 in via em0 panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated cpuid = 0; lapic.id = boot() called on cpu#0 syncing disks, buffers remaining... 7154 7154 7153 7153 7153 7153 7154 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RELEASE #0: Fri Jun 20 18:36:54 MDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SRV2 Preloaded elf kernel "/boot/kernel/kernel" at 0xc06ef000. Preloaded elf module "/boot/kernel/ipfw.ko" at 0xc06ef2e4. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06ef390. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2399328676 Hz CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 4160225280 (3967 MB) avail memory = 4045828096 (3858 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 6, version: 0x00050014, at 0xfee0 cpu2 (AP): apic id: 1, version: 0x00050014, at 0xfee0 cpu3 (AP): apic id: 7, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 io1 (APIC): apic id: 3, version: 0x00178020, at 0xfec8 io2 (APIC): apic id: 4, version: 0x00178020, at 0xfec80400 Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 24 entries at 0xc00fde40 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 IOAPIC #0 intpin 16 -> irq 2 IOAPIC #0 intpin 19 -> irq 10 IOAPIC #0 intpin 18 -> irq 11 pcib1: at device 2.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.HLB_ - AE_NOT_FOUND pci1: on pcib1 pci1: at device 28.0 (no driver attached) pcib2: at device 29.0 on pci1 pci2: on pcib2 IOAPIC #2 intpin 6 -> irq 16 IOAPIC #2 intpin 7 -> irq 17 em0: port 0x3000-0x303f mem 0xf820-0xf821 irq 16 at device 3.0 on pci2 em0: Speed:100 Mbps Duplex:Half em1: port 0x3040-0x307f mem 0xf822-0xf823 irq 17 at device 3.1 on pci2 em1: Speed:1000 Mbps Duplex:Full pci1: at device 30.0 (no driver attached) pcib3: at device 31.0 on pci1 pci3: on pcib3 IOAPIC #1 intpin 6 -> irq 18 asr0: mem 0xfc00-0xfdff,0xfb00-0xfbff,0xf830-0xf83f irq 18 at device 3.0 on pci3 asr0: major=154 asr0: ADAPTEC 2015S FW Rev. 3B05, 2 channel, 256 CCBs, Protocol I2O uhci0: port 0x2000-0x201f irq 2 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x2020-0x203f irq 10 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2040-0x205f irq 11 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pcib4: at device 30.0 on pci0 pci4: on pcib4 pci4: at device 1.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x2060-0x206f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 mem 0xf800-0xf80003ff irq 0 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 o
Re: Buildworld fails in 5.1
On Mon, Jul 21, 2003 at 09:46:03AM -0700, Tim Kientzle wrote: > Gordon Tetlow wrote: > >On Mon, Jul 21, 2003 at 09:36:37AM -0700, Tim Kientzle wrote: > >>Hmmm... Is that what .ORDER is for? To work around a > >>parallel make that gratuitously rebuilds things? > > > >Right it serializes build dependencies. The problem with crunchgen ... > > I would argue "the problem with make"... ;-) I think it's pretty > clear that It is not clear. > a b c: foo > buildabc > > does not require that 'buildabc' be run three times. The above is short hand for a: foo buildabc b: foo buildabc c: foo buildabc make in no way knows that buildabc produces 3 things and not a single one. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-07-21 19:01:13 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-07-21 19:01:13 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-21 19:03:15 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-07-21 20:02:20 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Jul 21 20:02:20 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: initializer element is not constant /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: (near initialization for `map_devs[13].dev') /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: initializer element is not constant /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: (near initialization for `map_devs[13]') /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c: In function `harp_attach': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: `MEDIA_UTP25' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/harp. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-07-21 20:09:36 - /usr/bin/make returned exit code 1 TB --- 2003-07-21 20:09:36 - ERROR: failed to build generic kernel TB --- 2003-07-21 20:09:36 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-07-21 18:19:35 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-07-21 18:19:35 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-21 18:21:29 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/ttyname.3 > ttyname.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/tzset.3 > tzset.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/ualarm.3 > ualarm.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/ucontext.3 > ucontext.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/ulimit.3 > ulimit.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/uname.3 > uname.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/unvis.3 > unvis.3.gz Bus error (core dumped) *** Error code 138 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-07-21 19:01:12 - /usr/bin/make returned exit code 1 TB --- 2003-07-21 19:01:12 - ERROR: failed to build world TB --- 2003-07-21 19:01:12 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kmem_mmap_toosmall -- repeatable panic
Hello! I tried to create a cscope's database with about 6200 files listed in the cscope.files. The entire tree (including the cscope.files) is mounted over NFS from a Solaris server. The July 11th kernel would just crash, today's one is more intelligent: kmem_malloc(4096): kmem_mmap_too_small: 275251200 total allocated The machine has 1Gb of RAM and 512Mb of swap... -mi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Annoucning DragonFly BSD!
Kris Kennaway wrote: > On Thu, Jul 17, 2003 at 03:29:12PM +0300, Maxim Sobolev wrote: > > No, everything seems real - at least Matt replies to e-mails > > sent to him on this topic. There is also a live nntp server > > up and running @ dragonflybsd.org, I saw Matt and Terry Lambert > > discussing kernel things this morning there. I doubt that somebody > > will be able to impersonate both Matt and Terry. :)) > > A Markov chain script could do a fairly passable impersonation of the > latter. 8^p. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld fails in 5.1
On Mon, Jul 21, 2003 at 09:46:03AM -0700, Tim Kientzle wrote: > > I would argue "the problem with make"... ;-) I think it's pretty > clear that > > a b c: foo > buildabc > > does not require that 'buildabc' be run three times. It's a common perception and one that's wrong. a b c: d foo is a shorthand for a: d foo b: d foo c: d foo Since most make variants only look at the timestamp one can avoid building a, b, and c thrice by enforcing an ordering. Make variants like clearmake may not be tricked that easily, because they keep track of much more. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
yesterday's ACPI not working -> patch
Hi, i cvsuped around monday morning, and after building / installing, my kernel said every second or so : Jul 17 09:48:01 syrenna kernel: ACPI-0438: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE Jul 17 09:48:01 syrenna kernel: ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BIF] (Node 0xc3ccc760), AE_NO_HARDWARE_RESPONSE Jul 17 09:48:01 syrenna kernel: ACPI-0438: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE Jul 17 09:48:01 syrenna kernel: ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.AC0_._PSR] (Node 0xc3ccc660), AE_NO_HARDWARE_RESPONSE note that before upgrading, it was saying: Jul 16 16:44:22 syrenna kernel: ACPI-0432: *** Error: Handler for [EmbeddedControl] returned AE_ERROR Jul 16 16:44:22 syrenna kernel: ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.AC0_._PSR] (Node 0xc3ccb660), AE_ERROR Jul 16 16:44:22 syrenna kernel: ACPI-0432: *** Error: Handler for [EmbeddedControl] returned AE_ERROR Jul 16 16:44:22 syrenna kernel: ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BST] (Node 0xc3ccb720), AE_ERROR and now with my patch (taken from a recent mail from Nate) it is OK. THE PATCH : i just changed line 662 : 1000 -> 1. as i read in other mails, it should already been changed to 5000 or so. just to make you notice i had the problem too. note that i use a custom DSDT (the original worked only with windows, and i found a page related to linux which has inspired my hack on the dsdt). KERNEL, dmesg, modified DSDT, and other informations (description of the machine) are to be found at: http://www.deep-ocean.net/~olive/freebsd/syrenna/ best regards to the -CURRENT team, Olivier Cortes ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make release of CURRENT on 4.7 broken again ?
On Mon, Jul 21, 2003 at 06:08:43PM +0300, Ruslan Ermilov wrote: > On Mon, Jul 21, 2003 at 02:13:45PM +0300, Andrey Elperin wrote: > > On Sun, Jul 20, 2003 at 02:44:23PM +0300, Ruslan Ermilov wrote: > > > > A few days ago I've noticed such messages in CURRENT buildlog (on 4.7 > > > > box, building without -j) : > > > > > > > > cc -Os -pipe -c chown_stub.c > > > > ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o > > > > crunchide -k _crunched_chown_stub chown.lo > > > > echo "int _crunched_chroot_stub(int argc, char **argv, char **envp){return > > > > main(argc,argv,envp);}" >chroot_stub.c > > > > cc -Os -pipe -c chroot_stub.c > > > > ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o > > > > crunchide -k _crunched_chroot_stub chroot.lo > > > > cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo > > > > echo.lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo > > > > sync.lo bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo > > > > mount_cd9660.lo mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo > > > > ftp.lo telnet.lo vi.lo chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses > > > > -lutil > > > > *** Error code 1 > > > > > > > > Stop in /usr/obj/usr/src/release/fixit_crunch. > > > > *** Error code 1 > > > > > > > I have committed a fix for this to src/bin/ed/ a few minutes ago. > > > > Hmm. But I got the same error during last release building (this night). > > > The "make -j" buildworld is currently broken by the recent changes > to kerberos5/, and the issue is being worked out. The breakage is > mostly visible in the "4.x doing the build of 5.x" case, because > the latter has /usr/include/roken.h and hides the building bug. > At the moment, I'm retesting the snapshot build of 5.x on my 4.x > SMP box without -j. I will follow up with what I get. > Yes, I can see the breakage: : crunchide -k _crunched_vi_stub vi.lo : echo "int _crunched_chown_stub(int argc, char **argv, char **envp){return main(a : rgc,argv,envp);}" >chown_stub.c : cc -Os -pipe -c chown_stub.c : ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o : crunchide -k _crunched_chown_stub chown.lo : echo "int _crunched_chroot_stub(int argc, char **argv, char **envp){return main( : argc,argv,envp);}" >chroot_stub.c : cc -Os -pipe -c chroot_stub.c : ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o : crunchide -k _crunched_chroot_stub chroot.lo : cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo echo : .lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo sync.lo b : sdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo mount_msd : osfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo chown.lo : chroot.lo -ledit -lgeom -lkvm -lm -lncurses -lutil : telnet.lo: In function `display': : telnet.lo(.text+0x122e): undefined reference to `EncryptStatus' : telnet.lo: In function `status': : telnet.lo(.text+0x1e85): undefined reference to `encrypt_display' : ... : : telnet.lo(.data+0xaa0): undefined reference to `EncryptStatus' : *** Error code 1 : : Stop in /usr/obj/usr/src/release/fixit_crunch. : *** Error code 1 : : Stop in /usr/src/release. I believe Mark has committed a fix for this today (commit log is attached). Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer --- Begin Message --- markm 2003/07/20 16:29:46 PDT FreeBSD src repository Modified files: lib/libtelnetMakefile libexec/telnetd Makefile usr.bin/telnet Makefile Log: Test correct macro for "without crypto" option(s). Revision ChangesPath 1.16 +1 -1 src/lib/libtelnet/Makefile 1.21 +1 -1 src/libexec/telnetd/Makefile 1.23 +1 -1 src/usr.bin/telnet/Makefile --- End Message --- pgp0.pgp Description: PGP signature
Re: putting /dev/lpt in polling mode in boot time.
Evan Dower wrote: > >From: "Andrew Lankford" <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: <[EMAIL PROTECTED]> > >Subject: Re: putting /dev/lpt in polling mode in boot time. > >Date: Sun, 20 Jul 2003 15:40:21 -0600 > > > >Before anyone corrects me, yes, the man page says bit 5 controls polling, > >0x20. My question stands. > > I may be smoking crack, but isn't it: > bit 5 = 0001 = 0x10 ? > bit 6 = 0010 = 0x20 ? > E Not if you start counting at 0. 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld fails in 5.1
At 9:46 AM -0700 7/21/03, Tim Kientzle wrote: Gordon Tetlow wrote: On Mon, Jul 21, 2003, Tim Kientzle wrote: Hmmm... Is that what .ORDER is for? To work around a parallel make that gratuitously rebuilds things? Right it serializes build dependencies. The problem with crunchgen ... I would argue "the problem with make"... ;-) I think it's pretty clear that a b c: foo buildabc does not require that 'buildabc' be run three times. Make should be able to note that 'buildabc' was already spawned for 'a' and just add 'b' and 'c' to the wait list for that operation, rather than running additional copies. It may not be quite that simple, when it gets to splitting apart the make rules to build things in parallel. I tracked down two problems with parallel builds, and in both cases make was "doing the right thing", given the rules that it was working with. On the other hand, I'm certainly no expert when it comes to writing makefiles for parallel builds. In any case, the suggested change did not solve the problem for me, when doing a make -j5 buildworld. I still get the failure with: make: don't know how to make /usr/obj/usr/src/rescue/rescue//usr/src/sbin/dhclie nt/client/clparse.o. Stop If there's some other way I should run the buildworld to generate a more helpful output, let me know. The failure seems to be 100% reproducible on my machine, at least if I start out by removing all of /usr/obj/usr/src. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-07-21 16:00:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-21 16:00:00 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-21 16:02:08 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-07-21 17:06:23 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Jul 21 17:06:23 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:150: error: initializer element is not constant /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:150: error: (near initialization for `map_devs[13].dev') /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:150: error: initializer element is not constant /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:150: error: (near initialization for `map_devs[13]') /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c: In function `harp_attach': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:412: error: `MEDIA_UTP25' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:412: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:412: error: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/modules/harp. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-07-21 17:14:14 - /usr/bin/make returned exit code 1 TB --- 2003-07-21 17:14:14 - ERROR: failed to build generic kernel TB --- 2003-07-21 17:14:14 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: src/bin/ed/re.c: warning: declaration of `exp' shadows a globaldeclaration
On Tue, Jul 15, 2003 at 07:59:43AM +0200, Harti Brandt wrote: > On Tue, 15 Jul 2003, Jun Kuriyama wrote: > JK>With new gcc and -Wshadow, src/bin/ed/re.c shows this warning: > JK> > JK>cc -Wshadow -c re.c > JK>re.c: In function `get_compiled_pattern': > JK>re.c:44: warning: declaration of `exp' shadows a global declaration > JK>:0: warning: shadowed declaration is here > JK> > JK>It seems local variable exp is conflicted with exp(3) declaration. I > JK>don't know what name should be used... > > I would call this a compiler bug. It shouldn't declare exp(3) when you > don't include math.h. As I understand the standard the names in math.h are > only reserved when you include math.h. I remember that an earlier version > of gcc had this bug, that was fixed then. Probably they unfixed it again. > > What's the chance of getting this fixed? There is a discussion on the [EMAIL PROTECTED] mailing list, but they are having a hard time agreeing there is a bug here. FreeBSD's GCC problems have a better chance of getting fixed if those that experience and understand the bug would participate in related discussions on the GCC mailing lists. The Linux and Solaris community has no problem doing this -- for some reason the BSD communities expects the poor guy doing the GCC imports to be the single voice for BSD. :-( -- -- David([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld fails in 5.1
Gordon Tetlow wrote: On Mon, Jul 21, 2003 at 09:36:37AM -0700, Tim Kientzle wrote: Hmmm... Is that what .ORDER is for? To work around a parallel make that gratuitously rebuilds things? Right it serializes build dependencies. The problem with crunchgen ... I would argue "the problem with make"... ;-) I think it's pretty clear that a b c: foo buildabc does not require that 'buildabc' be run three times. Make should be able to note that 'buildabc' was already spawned for 'a' and just add 'b' and 'c' to the wait list for that operation, rather than running additional copies. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld fails in 5.1
On Mon, Jul 21, 2003 at 09:36:37AM -0700, Tim Kientzle wrote: > Gordon Tetlow wrote: > >It seems that the $(OUTPUTS) target (which has 3 components) causes > >this particular error. > > > >+.ORDER: $(OUTPUTS) > > $(OUTPUTS): $(CONF) > >MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m $(OUTMK) -c $(OUTC) > >\ > >$(CONF) > > Hmmm... Is that what .ORDER is for? To work around a > parallel make that gratuitously rebuilds things? Right it serializes build dependencies. The problem with crunchgen is that a single command makes all of the OUTPUTS, so normally make will spawn off the same command 3 times in parallel (which seems to cause problems). To get around it, make it so you each of the OUTPUTS is built in order and what occurs is a single crunchgen invocation that the sees that the other OUTPUT targets are up-to-date and then contintues along. > >After doing that, I run into a problem with clparse.o from the dhclient > >build. I think I might have a solution for that, but I'm too tired > >right now to think straight. I'll look at it tomorrow. > > > A-ha! I've known that dhclient was a problem, but the > above gives me an idea. I wonder if the following helps? I'll give it a whirl. -gordon pgp0.pgp Description: PGP signature
Re: Buildworld fails in 5.1
Gordon Tetlow wrote: It seems that the $(OUTPUTS) target (which has 3 components) causes this particular error. +.ORDER: $(OUTPUTS) $(OUTPUTS): $(CONF) MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m $(OUTMK) -c $(OUTC) \ $(CONF) Hmmm... Is that what .ORDER is for? To work around a parallel make that gratuitously rebuilds things? After doing that, I run into a problem with clparse.o from the dhclient build. I think I might have a solution for that, but I'm too tired right now to think straight. I'll look at it tomorrow. A-ha! I've known that dhclient was a problem, but the above gives me an idea. I wonder if the following helps? Tim Index: sbin/dhclient//Makefile === RCS file: /usr/cvs/FreeBSD-CVS/src/sbin/dhclient/Makefile,v retrieving revision 1.20 diff -u -r1.20 Makefile --- sbin/dhclient/Makefile 29 Jun 2003 18:46:17 - 1.20 +++ sbin/dhclient/Makefile 21 Jul 2003 16:34:22 - @@ -52,6 +52,8 @@ # though, so we must run ``make all'' instead when we are asked to # generate an individual object file. +.ORDER: $(OBJS) + # Note: Must have some commands here to override the default build action ${OBJS}: all @true ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpcinfo
On Fri, 18 Jul 2003 02:14:18 +0200 Pawel Worach <[EMAIL PROTECTED]> wrote: > Danny Braniss wrote: > > I just run rpcinfo: > > > > # rpcinfo > > rpcinfo: can't contact rpcbind: RPC: Port mapper failure - RPC: Success > > > > :=) > This really belongs in questions@, make sure you have rpcbind_enable="YES" in > rc.conf I think he is amused about the use of "failure" and "Success" in the same error message. Bye, Alexander. -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Mon, 21 Jul 2003, Noriyoshi Kawano wrote: > I have similar problem. > disable re-route interrupts. > It's works fine. > > --- /sys/dev/pci/pci.c.orig Tue Jul 1 23:08:32 2003 > +++ /sys/dev/pci/pci.cMon Jul 21 11:04:55 2003 > @@ -800,7 +800,7 @@ > } > > if (cfg->intpin > 0 && PCI_INTERRUPT_VALID(cfg->intline)) { > -#if defined(__ia64__) || (defined(__i386__) && !defined(SMP)) > +#if defined(__ia64__) > /* >* Try to re-route interrupts. Sometimes the BIOS or >* firmware may leave bogus values in these registers. Thanks. This works fine. Is there any "global" solution to the problem so that I won't need to patch again the time 5.2R comes out ? -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Does linux-sun-jdk_1.4.2 work?
Adam wrote: On Mon, 2003-07-21 at 08:55, Yamada Ken Takeshi wrote: tyd3# /usr/local/linux-sun-jdk1.4.2/bin/java -version # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode) # # Error ID: 4F533F4C494E55580E43505001C9 # Heap at VM Abort: Heap It happens to me too. Looks like this port was released too quickly. Java on FreeBSD is always a bit dodgy, it seems. Hi, try mounting linprocfs(5) that seemed to solved the problem for me. regards, flo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make release of CURRENT on 4.7 broken again ?
On Mon, Jul 21, 2003 at 02:13:45PM +0300, Andrey Elperin wrote: > On Sun, Jul 20, 2003 at 02:44:23PM +0300, Ruslan Ermilov wrote: > > > A few days ago I've noticed such messages in CURRENT buildlog (on 4.7 > > > box, building without -j) : > > > > > > cc -Os -pipe -c chown_stub.c > > > ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o > > > crunchide -k _crunched_chown_stub chown.lo > > > echo "int _crunched_chroot_stub(int argc, char **argv, char **envp){return > > > main(argc,argv,envp);}" >chroot_stub.c > > > cc -Os -pipe -c chroot_stub.c > > > ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o > > > crunchide -k _crunched_chroot_stub chroot.lo > > > cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo > > > echo.lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo > > > sync.lo bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo > > > mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo > > > chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses > > > -lutil > > > *** Error code 1 > > > > > > Stop in /usr/obj/usr/src/release/fixit_crunch. > > > *** Error code 1 > > > > > I have committed a fix for this to src/bin/ed/ a few minutes ago. > > Hmm. But I got the same error during last release building (this night). > The "make -j" buildworld is currently broken by the recent changes to kerberos5/, and the issue is being worked out. The breakage is mostly visible in the "4.x doing the build of 5.x" case, because the latter has /usr/include/roken.h and hides the building bug. At the moment, I'm retesting the snapshot build of 5.x on my 4.x SMP box without -j. I will follow up with what I get. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Does linux-sun-jdk_1.4.2 work?
On Mon, 2003-07-21 at 08:55, Yamada Ken Takeshi wrote: > I have the following error and cannot compile jdk14 > on FreeBSD-current, July 20th. cvsup'ed with the latest > linux_base. > > Is is unique to me alone? > > tyd3# /usr/local/linux-sun-jdk1.4.2/bin/java -version > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode) > # > # Error ID: 4F533F4C494E55580E43505001C9 > # > > Heap at VM Abort: > Heap It happens to me too. Looks like this port was released too quickly. Java on FreeBSD is always a bit dodgy, it seems. -- Adam <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP problem with uma_zalloc
On Mon, 21 Jul 2003, Bosko Milekic wrote: BM> A. Given the explanation, the small size of the limits makes a BM> lot more sense now. Previously, the limit probably enforced the BM> actual number of cached (pre-allocated) items in the pool. So, it was BM> more than just a "limit," it was a cache size parameter. That is BM> probably why its size was kept relatively small. In the zone setting, BM> the limit can easily be made larger or removed altogether (if there is BM> no danger of that structure consuming all of kernel memory). No, there isn't. VCCs are usually limited by the interface card to a couple of thousand. BM>> How do you think about adding a paragraph for uma_zone_set_max to the man BM>> page?: BM>> BM>> An upper limit of items in the zone can be specified with a call to BM>> uma_zone_set_max. This limits the total number of items which includes: BM>> allocated items, free items and free items in the per-cpu caches. On BM>> systems with more than one CPU it may not be possible to allocate the BM>> specified number of items, because all of the remaining free items may BM>> be in the caches of the other CPUs when the limit is hit. BM> BM> Given that it has obviously led to confusion, this sort of change to BM> the man page would be encouraging. BM> BM> Perhaps you would also ammend to it the purpose of uma_zone_set_max(), BM> as it currently stands: BM> BM> "The purpose of uma_zone_set_max() is to limit the maximum BM> amount of memory that the system can dedicate toward the zone BM> specified by the 'zone' argument." BM> BM> Would you like to commit the change? Ok, I'll commit it. Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld fails in 5.1
At 12:34 AM -0400 7/21/03, Garance A Drosihn wrote: I do know that buildworld finishes OK if I define NORESCUE. Right now I am running a buildworld that does not specify -j, and I'll see if that completes OK. The buildworld without -j did successfully complete. I have added that logfile to the lines in ~gad/rescueb if anyone wants to look at them. All of these builds were with -current as of Friday. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP problem with uma_zalloc
On Mon, Jul 21, 2003 at 03:47:54PM +0200, Harti Brandt wrote: > On Mon, 21 Jul 2003, Bosko Milekic wrote: [...] > BM> It sounds to me like your example is really not the general-case one. > BM> Basically, you're using a zone capped off at 1 page. Currently in > BM> UMA, this is the size of the slab. So, basically, you have this whole > BM> zone (with all associated overhead) so as to serve a maximum of only > BM> one slab. This defeats most of the assumptions made when the zone is > BM> created with PCPU caches. The zone maximum exists to prevent more > BM> than the specified amount of resources to be allocated toward the > BM> given zone; I don't think that the intention was "to ensure that if > BM> the maximum items aren't allocated, there will always be one > BM> available," despite the fact that that is the effective behavior on > BM> UP. > BM> > BM> The solution to your really small zone problem is to either make the > BM> zone bigger, or to hack at UMA to export the UMA_ZONE_INTERNAL API > BM> properly so that you can skip the pcpu caches for all allocations and > BM> go straight to the zone. I'd suggest that you make the zone bigger, > BM> unless there's a Really Good reason not to. > > I think I take two paths: for stuffs like VCC where there may be a large > number I will just remove the limit. The limits were a leftover when the > ATM code had its own memory pool code. For stuff where there is a high > probability that only a handful (usually 1 or 2) of them will be allocated > (network interfaces) I will try to make it to use malloc(). A. Given the explanation, the small size of the limits makes a lot more sense now. Previously, the limit probably enforced the actual number of cached (pre-allocated) items in the pool. So, it was more than just a "limit," it was a cache size parameter. That is probably why its size was kept relatively small. In the zone setting, the limit can easily be made larger or removed altogether (if there is no danger of that structure consuming all of kernel memory). > How do you think about adding a paragraph for uma_zone_set_max to the man > page?: > > An upper limit of items in the zone can be specified with a call to > uma_zone_set_max. This limits the total number of items which includes: > allocated items, free items and free items in the per-cpu caches. On > systems with more than one CPU it may not be possible to allocate the > specified number of items, because all of the remaining free items may > be in the caches of the other CPUs when the limit is hit. Given that it has obviously led to confusion, this sort of change to the man page would be encouraging. Perhaps you would also ammend to it the purpose of uma_zone_set_max(), as it currently stands: "The purpose of uma_zone_set_max() is to limit the maximum amount of memory that the system can dedicate toward the zone specified by the 'zone' argument." Would you like to commit the change? > Regards, > harti > > -- > harti brandt, > http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private > [EMAIL PROTECTED], [EMAIL PROTECTED] Cheers, -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP problem with uma_zalloc
On Mon, 21 Jul 2003, Bosko Milekic wrote: BM> BM>On Mon, Jul 21, 2003 at 09:03:00AM +0200, Harti Brandt wrote: BM>> On Sat, 19 Jul 2003, Bosko Milekic wrote: BM>> BM>> BM> BM>> BM>On Sat, Jul 19, 2003 at 08:31:26PM +0200, Lara & Harti Brandt wrote: BM>> BM>[...] BM>> BM>> Well the problem is, that nothing is starved. I have an idle machine and BM>> BM>> a zone that I have limited to 60 or so items. When allocating the 2nd BM>> BM>> item I get block on the zone limit. Usually I get unblocked whenever I BM>> BM>> free an item. This will however not happen, because I have neither BM>> BM>> reached the limit nor is there memory pressure in the system to which I BM>> BM>> could react. I simply may be blocked forever. BM>> BM> BM>> BM> UMA_ZFLAG_FULL is set on the zone prior to the msleep(). This means BM>> BM> that the next free will result in your wakeup, as the next free will BM>> BM> be sent to the zone internally, and not the pcpu cache. BM>> BM>> But there is no free to come. To explain where we have the problem: BM>> BM>> the HARP ATM code uses a zone in the IP code to allocate control blocks BM>> for VCCs. The zone is limited to 100 items which evaluates to 1 page. BM>> When I start an interface, first the signalling vcc=5 is opened. This BM>> allocates one item from the zone, all the other items go into the CPU BM>> cache. Next I start ILMI. ILMI tries to open its vcc=16. While this works BM>> on UP machines (the zone allocator will find a free item in the CPU BM>> cache), on my 2-proc machine half of the time ILMI gets blocked on the BM>> zonelimit. And it blocks there forever, because, of course nobody is going BM>> to free the one and only allocated item. On a four processor machine the BM>> blocking probability will be 75%. BM>> BM>> So in order to be able to get out N items from a zone (given that there is BM>> no shortage of memory) one has to set the limit to N + nproc * BM>> items_per_allocation, which one cannot do because he doesn't know BM>> items_per_allocation. BM> BM> It sounds to me like your example is really not the general-case one. BM> Basically, you're using a zone capped off at 1 page. Currently in BM> UMA, this is the size of the slab. So, basically, you have this whole BM> zone (with all associated overhead) so as to serve a maximum of only BM> one slab. This defeats most of the assumptions made when the zone is BM> created with PCPU caches. The zone maximum exists to prevent more BM> than the specified amount of resources to be allocated toward the BM> given zone; I don't think that the intention was "to ensure that if BM> the maximum items aren't allocated, there will always be one BM> available," despite the fact that that is the effective behavior on BM> UP. BM> BM> The solution to your really small zone problem is to either make the BM> zone bigger, or to hack at UMA to export the UMA_ZONE_INTERNAL API BM> properly so that you can skip the pcpu caches for all allocations and BM> go straight to the zone. I'd suggest that you make the zone bigger, BM> unless there's a Really Good reason not to. I think I take two paths: for stuffs like VCC where there may be a large number I will just remove the limit. The limits were a leftover when the ATM code had its own memory pool code. For stuff where there is a high probability that only a handful (usually 1 or 2) of them will be allocated (network interfaces) I will try to make it to use malloc(). How do you think about adding a paragraph for uma_zone_set_max to the man page?: An upper limit of items in the zone can be specified with a call to uma_zone_set_max. This limits the total number of items which includes: allocated items, free items and free items in the per-cpu caches. On systems with more than one CPU it may not be possible to allocate the specified number of items, because all of the remaining free items may be in the caches of the other CPUs when the limit is hit. Regards, harti BM> BM> In mb_alloc (for mbufs) I had implemented something that in this sort BM> of scenario would dip into the other caches and transfer over what I BM> called a "bucket" to the current cpu cache. Although in this BM> scenario, it seems like that sort of solution would do what you want, BM> some more thought into its behavior reveals that in fact it pessimizes BM> the situation. To give you a better idea, let's consider what happens BM> in this specific scenario, where a "bucket" would be all of a page. BM> The allocator would make an attempt to allocate from its pcpu cache BM> but would find it empty, so it would then attempt to steal a bucket BM> from the second cpu's cache. There, it would find the bucket, move it BM> to its cpu's cache, and grab an item from it. However, a thread on BM> the second cpu may then attempt to grab an item, and the bucket will BM> just ping-pong from pcpu cache to pcpu cache; the problem that the BM> allocator was trying to solve for such really small zones was in f
Re: Does linux-sun-jdk_1.4.2 work?
There are indeed more problems with that JDK 1.4.2. Please try on freebsd-java instead of ports-committers... Ernst On Monday 21 July 2003 14:55, Yamada Ken Takeshi wrote: > I have the following error and cannot compile jdk14 > on FreeBSD-current, July 20th. cvsup'ed with the latest > linux_base. > > Is is unique to me alone? > > tyd3# /usr/local/linux-sun-jdk1.4.2/bin/java -version > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode) > # > # Error ID: 4F533F4C494E55580E43505001C9 > # > > Heap at VM Abort: > Heap ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP problem with uma_zalloc
On Mon, Jul 21, 2003 at 09:03:00AM +0200, Harti Brandt wrote: > On Sat, 19 Jul 2003, Bosko Milekic wrote: > > BM> > BM>On Sat, Jul 19, 2003 at 08:31:26PM +0200, Lara & Harti Brandt wrote: > BM>[...] > BM>> Well the problem is, that nothing is starved. I have an idle machine and > BM>> a zone that I have limited to 60 or so items. When allocating the 2nd > BM>> item I get block on the zone limit. Usually I get unblocked whenever I > BM>> free an item. This will however not happen, because I have neither > BM>> reached the limit nor is there memory pressure in the system to which I > BM>> could react. I simply may be blocked forever. > BM> > BM> UMA_ZFLAG_FULL is set on the zone prior to the msleep(). This means > BM> that the next free will result in your wakeup, as the next free will > BM> be sent to the zone internally, and not the pcpu cache. > > But there is no free to come. To explain where we have the problem: > > the HARP ATM code uses a zone in the IP code to allocate control blocks > for VCCs. The zone is limited to 100 items which evaluates to 1 page. > When I start an interface, first the signalling vcc=5 is opened. This > allocates one item from the zone, all the other items go into the CPU > cache. Next I start ILMI. ILMI tries to open its vcc=16. While this works > on UP machines (the zone allocator will find a free item in the CPU > cache), on my 2-proc machine half of the time ILMI gets blocked on the > zonelimit. And it blocks there forever, because, of course nobody is going > to free the one and only allocated item. On a four processor machine the > blocking probability will be 75%. > > So in order to be able to get out N items from a zone (given that there is > no shortage of memory) one has to set the limit to N + nproc * > items_per_allocation, which one cannot do because he doesn't know > items_per_allocation. It sounds to me like your example is really not the general-case one. Basically, you're using a zone capped off at 1 page. Currently in UMA, this is the size of the slab. So, basically, you have this whole zone (with all associated overhead) so as to serve a maximum of only one slab. This defeats most of the assumptions made when the zone is created with PCPU caches. The zone maximum exists to prevent more than the specified amount of resources to be allocated toward the given zone; I don't think that the intention was "to ensure that if the maximum items aren't allocated, there will always be one available," despite the fact that that is the effective behavior on UP. The solution to your really small zone problem is to either make the zone bigger, or to hack at UMA to export the UMA_ZONE_INTERNAL API properly so that you can skip the pcpu caches for all allocations and go straight to the zone. I'd suggest that you make the zone bigger, unless there's a Really Good reason not to. In mb_alloc (for mbufs) I had implemented something that in this sort of scenario would dip into the other caches and transfer over what I called a "bucket" to the current cpu cache. Although in this scenario, it seems like that sort of solution would do what you want, some more thought into its behavior reveals that in fact it pessimizes the situation. To give you a better idea, let's consider what happens in this specific scenario, where a "bucket" would be all of a page. The allocator would make an attempt to allocate from its pcpu cache but would find it empty, so it would then attempt to steal a bucket from the second cpu's cache. There, it would find the bucket, move it to its cpu's cache, and grab an item from it. However, a thread on the second cpu may then attempt to grab an item, and the bucket will just ping-pong from pcpu cache to pcpu cache; the problem that the allocator was trying to solve for such really small zones was in fact still there - because of the general assumptions made in the design with respect to the size of most zones that it dealt with - only instead of failing the allocation, it was pessimizing it. > harti Regards, -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Does linux-sun-jdk_1.4.2 work?
I have the following error and cannot compile jdk14 on FreeBSD-current, July 20th. cvsup'ed with the latest linux_base. Is is unique to me alone? tyd3# /usr/local/linux-sun-jdk1.4.2/bin/java -version # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode) # # Error ID: 4F533F4C494E55580E43505001C9 # Heap at VM Abort: Heap ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dhclient -n option does not work
from dhclient(8): The DHCP client can be directed not to attempt to configure any interfaces using the -n flag. this does not seem to work, my interface gets configured, resolv.conf written. can anyone confirm this? what sort of action should be taken to fix this? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make release of CURRENT on 4.7 broken again ?
On Sun, Jul 20, 2003 at 02:44:23PM +0300, Ruslan Ermilov wrote: > > A few days ago I've noticed such messages in CURRENT buildlog (on 4.7 > > box, building without -j) : > > > > cc -Os -pipe -c chown_stub.c > > ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o > > crunchide -k _crunched_chown_stub chown.lo > > echo "int _crunched_chroot_stub(int argc, char **argv, char **envp){return > > main(argc,argv,envp);}" >chroot_stub.c > > cc -Os -pipe -c chroot_stub.c > > ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o > > crunchide -k _crunched_chroot_stub chroot.lo > > cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo > > echo.lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo sync.lo > > bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo > > mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo > > chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses > > -lutil > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/release/fixit_crunch. > > *** Error code 1 > > > I have committed a fix for this to src/bin/ed/ a few minutes ago. Hmm. But I got the same error during last release building (this night). > Cheers, > -- > Ruslan ErmilovSysadmin and DBA, > [EMAIL PROTECTED] Sunbay Software Ltd, > [EMAIL PROTECTED] FreeBSD committer -- Andrey Elperin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
Hi, I have similar problem. disable re-route interrupts. It's works fine. --- /sys/dev/pci/pci.c.orig Tue Jul 1 23:08:32 2003 +++ /sys/dev/pci/pci.c Mon Jul 21 11:04:55 2003 @@ -800,7 +800,7 @@ } if (cfg->intpin > 0 && PCI_INTERRUPT_VALID(cfg->intline)) { -#if defined(__ia64__) || (defined(__i386__) && !defined(SMP)) +#if defined(__ia64__) /* * Try to re-route interrupts. Sometimes the BIOS or * firmware may leave bogus values in these registers. At Mon, 21 Jul 2003 10:40:09 +0200 (CEST), Bjoern A. Zeeb wrote: > > Hi, > > while booting a 5.1REL kernel on that machine is fine, booting HEAD > results in... > > --- cut --- > Copyright (c) 1992-2003 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.1-CURRENT #0: Mon Jul 21 08:13:36 UTC 2003 > [EMAIL PROTECTED]:/u2/src/obj/u2/src/HEAD/src/sys/HAUKI-20030718-01 > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0593000. > Preloaded elf module "/boot/kernel/linux.ko" at 0xc05930d8. > Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc0593184. > Preloaded elf module "/boot/kernel/snd_ich.ko" at 0xc0593230. > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 996768803 Hz > CPU: Intel Pentium III (996.77-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x686 Stepping = 6 > > Features=0x383fbff > real memory = 536870912 (512 MB) > avail memory = 515473408 (491 MB) > Pentium Pro MTRR support enabled > npx0: on motherboard > npx0: INT 16 interface > pcibios: BIOS version 2.10 > Using $PIR table, 10 entries at 0xc00e8790 > pcib0: at pcibus 0 on motherboard > pci0: on pcib0 > pci_cfgintr: 0:31 INTD BIOS irq 10 > pci_cfgintr: 0:31 INTB BIOS irq 11 > agp0: mem 0x4800-0x4bff at > device 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x240 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0395ab4 > stack pointer = 0x10:0xc05b5836 > frame pointer = 0x10:0xc05b587a > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > kernel: type 12 trap, code=0 > Stopped at trap+0x414: testb $0x10,0x240(%eax) > db> x 0xc0395ab4 > trap+0x414: 24080f6 > db> trace > trap(b0018,58c00010,c05b0010,c150050a,c039d82d) at trap+0x414 > calltrap() at calltrap+0x5 > --- trap 0x9, eip = 0xc00e8a14, esp = 0xc05b58c2, ebp = 0xc05b58f4 --- > kernbase(c0381ece,8,c05b5940,0,1) at 0xc00e8a14 > (null)(50a,c05b596c,c039d82d,c1507700,c1507500) at 0x80246 > db> panic > panic: from debugger > Debugger("panic") > > > Fatal trap 3: breakpoint instruction fault while in kernel mode > instruction pointer = 0x8:0xc0384734 > stack pointer = 0x10:0xc05b55b6 > frame pointer = 0x10:0xc05b55c2 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= IOPL = 0 > current process = 0 (swapper) > Stopped at trap+0x414: testb $0x10,0x240(%eax) > db> reset > --- cut --- > > done a gdb -k kernel.debug I get this: > > --- cut --- > (kgdb) l *0xc0395ab4 > 0xc0395ab4 is in trap (/u2/src/HEAD/src/sys/i386/i386/trap.c:472). > 467 break; > 468 > 469 /* FALL THROUGH */ > 470 > 471 case T_SEGNPFLT:/* segment not present fault */ > 472 if (PCPU_GET(curpcb)->pcb_flags & PCB_VM86CALL) > 473 break; > 474 > 475 /* > 476 * Invalid %fs's and %gs's can be created using > (kgdb) q > --- cut --- > > Any ideas ? Anything I might try ? > > PS: though calling panic I do not get crashdumps. > > -- > Greetings > > Bjoern A. Zeebbzeeb at Zabbadoz dot NeT > 56 69 73 69 74http://www.zabbadoz.net/ > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld fails in 5.1
On Fri, Jul 18, 2003 at 11:39:53AM -0700, Tim Kientzle wrote: > > I wrote the /rescue stuff and a lot of people have > reported that it breaks parallel builds, but I haven't yet > come up with anything. (In part, because I haven't yet > managed to reproduce it. ) > > A couple of things look odd about this: > > 1) You should not be building 'rescue.mk' twice. >That could be the problem right there, if the rescue.mk >makefile is getting rebuilt (overwritten) while another >build thread is using it. The dependencies in >rescue/rescue/Makefile look right to me, but I >could be missing something. It seems that the $(OUTPUTS) target (which has 3 components) causes this particular error. It can be easily avoided with the following patch (against an older version of src/rescue/rescue/Makefile, should be fine): (Whitespace is probably messed up) //depot/user/gordon/dynamic/src/rescue/rescue/Makefile#7 - /home/gtetlow/p4 /dynamic/src/rescue/rescue/Makefile @@ -244,6 +244,7 @@ .endfor +.ORDER: $(OUTPUTS) $(OUTPUTS): $(CONF) MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m $(OUTMK) -c $(OUTC) \ $(CONF) After doing that, I run into a problem with clparse.o from the dhclient build. I think I might have a solution for that, but I'm too tired right now to think straight. I'll look at it tomorrow. -gordon pgp0.pgp Description: PGP signature
Fatal trap 12: page fault while in kernel mode
Hi, while booting a 5.1REL kernel on that machine is fine, booting HEAD results in... --- cut --- Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Mon Jul 21 08:13:36 UTC 2003 [EMAIL PROTECTED]:/u2/src/obj/u2/src/HEAD/src/sys/HAUKI-20030718-01 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0593000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc05930d8. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc0593184. Preloaded elf module "/boot/kernel/snd_ich.ko" at 0xc0593230. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 996768803 Hz CPU: Intel Pentium III (996.77-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383fbff real memory = 536870912 (512 MB) avail memory = 515473408 (491 MB) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00e8790 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci_cfgintr: 0:31 INTD BIOS irq 10 pci_cfgintr: 0:31 INTB BIOS irq 11 agp0: mem 0x4800-0x4bff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x240 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0395ab4 stack pointer = 0x10:0xc05b5836 frame pointer = 0x10:0xc05b587a code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped at trap+0x414: testb $0x10,0x240(%eax) db> x 0xc0395ab4 trap+0x414: 24080f6 db> trace trap(b0018,58c00010,c05b0010,c150050a,c039d82d) at trap+0x414 calltrap() at calltrap+0x5 --- trap 0x9, eip = 0xc00e8a14, esp = 0xc05b58c2, ebp = 0xc05b58f4 --- kernbase(c0381ece,8,c05b5940,0,1) at 0xc00e8a14 (null)(50a,c05b596c,c039d82d,c1507700,c1507500) at 0x80246 db> panic panic: from debugger Debugger("panic") Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc0384734 stack pointer = 0x10:0xc05b55b6 frame pointer = 0x10:0xc05b55c2 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= IOPL = 0 current process = 0 (swapper) Stopped at trap+0x414: testb $0x10,0x240(%eax) db> reset --- cut --- done a gdb -k kernel.debug I get this: --- cut --- (kgdb) l *0xc0395ab4 0xc0395ab4 is in trap (/u2/src/HEAD/src/sys/i386/i386/trap.c:472). 467 break; 468 469 /* FALL THROUGH */ 470 471 case T_SEGNPFLT:/* segment not present fault */ 472 if (PCPU_GET(curpcb)->pcb_flags & PCB_VM86CALL) 473 break; 474 475 /* 476 * Invalid %fs's and %gs's can be created using (kgdb) q --- cut --- Any ideas ? Anything I might try ? PS: though calling panic I do not get crashdumps. -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: telnet build fails without openssl...
Anti writes: > buildworld fails at telnet if you build with NOCRYPT and NO_OPENSSL -- > telnet stuff is looking for NO_CRYPTO to disable this, which isn't > documented anywhere... Thanks! This should be fixed now. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on i386/i386
Peter Wemm writes: > Tinderbox wrote: > > > gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/c > at > gets.3 > catgets.3.gz > > Segmentation fault (core dumped) > > *** Error code 139 > > These false alarms are wearing a bit thin. Is there a problem with the > tinderbox build machine perhaps? My home box is doing it too. as(1) blowing up "randomly". No usable core dumps. :-(. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP problem with uma_zalloc
On Sat, 19 Jul 2003, Bosko Milekic wrote: BM> BM>On Sat, Jul 19, 2003 at 08:31:26PM +0200, Lara & Harti Brandt wrote: BM>[...] BM>> Well the problem is, that nothing is starved. I have an idle machine and BM>> a zone that I have limited to 60 or so items. When allocating the 2nd BM>> item I get block on the zone limit. Usually I get unblocked whenever I BM>> free an item. This will however not happen, because I have neither BM>> reached the limit nor is there memory pressure in the system to which I BM>> could react. I simply may be blocked forever. BM> BM> UMA_ZFLAG_FULL is set on the zone prior to the msleep(). This means BM> that the next free will result in your wakeup, as the next free will BM> be sent to the zone internally, and not the pcpu cache. But there is no free to come. To explain where we have the problem: the HARP ATM code uses a zone in the IP code to allocate control blocks for VCCs. The zone is limited to 100 items which evaluates to 1 page. When I start an interface, first the signalling vcc=5 is opened. This allocates one item from the zone, all the other items go into the CPU cache. Next I start ILMI. ILMI tries to open its vcc=16. While this works on UP machines (the zone allocator will find a free item in the CPU cache), on my 2-proc machine half of the time ILMI gets blocked on the zonelimit. And it blocks there forever, because, of course nobody is going to free the one and only allocated item. On a four processor machine the blocking probability will be 75%. So in order to be able to get out N items from a zone (given that there is no shortage of memory) one has to set the limit to N + nproc * items_per_allocation, which one cannot do because he doesn't know items_per_allocation. harti BM>> That makes the limit feature for zones rather useless, because I cannot BM>> predict how many of the items I can really allocate (this depends on the BM>> number of processors, the page size and the configuration of UMA itself). BM>> BM>> Perhaps we could make the behaviour dependent on the maximum number of BM>> items. When it is rather low (a couple of pages worth) and I would block BM>> on the zone limit and I have free items in another CPU's cache then BM>> drain one of the caches. BM>> BM>> Or I could simply remove the limits. BM>> BM>> BM>> harti BM>> BM>> BM>> BM> BM> -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"