a gcc3.1 bug ?
hi,
I used gcc3.1 from ports to compile jdk1.3.1-p7 hotspot, I got problem
in compiing /usr/src/lib/libc_r/uthread/pthread_private.h :
-
/* Default thread attributes: */
SCLASS struct pthread_attr pthread_attr_default
--947
#ifdef GLOBAL_PTHREAD_PRIVATE
= { SCHED_RR, 0, TIMESLICE_USEC, PTHREAD_DEFAULT_PRIORITY,
PTHREAD_CREATE_RUNNING, PTHREAD_CREATE_JOINABLE, NULL, NULL, NULL,
PTHREAD_STACK_DEFAULT, -1 };
#else
;
#endif
/* Default mutex attributes: */
SCLASS struct pthread_mutex_attr pthread_mutexattr_default
#ifdef GLOBAL_PTHREAD_PRIVATE
= { PTHREAD_MUTEX_DEFAULT, PTHREAD_PRIO_NONE, 0, 0 };
#else
;
#endif
/* Default condition variable attributes: */
SCLASS struct pthread_cond_attr pthread_condattr_default
#ifdef GLOBAL_PTHREAD_PRIVATE
= { COND_TYPE_FAST, 0 };
#else
;
#endif
-
Compiling
/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/../../src/os_cpu/linux_i486/vm/os_linux_i486.cpp
In file included from
/usr/ports/java/jdk13/work/hotspot1.3.1/src/os_cpu/linux_i486/vm/os_linux_i486.cpp:41:
/usr/src/lib/libc_r/uthread/pthread_private.h:947: parse error before
`__null'
/usr/src/lib/libc_r/uthread/pthread_private.h:957: parse error before
`__null'
/usr/src/lib/libc_r/uthread/pthread_private.h:965: parse error before
`__null'
gmake[2]: *** [os_linux_i486.o] Error 1
gmake[2]: Leaving directory
`/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg'
gmake[1]: *** [the_vm] Error 2
gmake[1]: Leaving directory
`/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg'
gmake: *** [jvmgcore] Error 2
but if I change pthread_attr pthread_attr_default to other name, the
compiler will pass.
Does gcc31 have bug ?
--hwh
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
firewall support?
is firewall support built into the -current kernel or does it need to be compiled in? --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: a gcc3.1 bug ?
On Sun, Jul 28, 2002 at 02:40:15PM +0800, Huang wen hui wrote: hi, I used gcc3.1 from ports to compile jdk1.3.1-p7 hotspot, I got problem in compiing /usr/src/lib/libc_r/uthread/pthread_private.h : While I - unfortunately - do not know the solution to your problem, I would like to report that I compiled the jdk with the new patchset just yesterday on my week-old -CURRENT and it worked ok. However, I always clean out /usr/include before installworld, so there may be no stale header files there. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewall support?
On Sat, Jul 27, 2002 at 11:59:01PM -0700, karl agee wrote: is firewall support built into the -current kernel or does it need to be compiled in? --karl It is not in GENERIC, but you can always either compile it in, or load it from a module by editing /boot/loader.conf. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: KSE: not on run queue
On Sat, 27 Jul 2002, Julian Elischer wrote: On Sun, 28 Jul 2002, Gavin Atkinson wrote: Had this panic twice with current -current on an uniprocessor machine and kernel. Dumps still don't work... Both occurances, i had an ssh running, a portupgrade in progress, and the dnetc client running in the background. how new is the kernel? When you created it did you make sure you deleted all .o files first? Source was supped 26th july 1am (gmt). Kernel and world were built at the same time with make clean buildworld buildkernel. I was running portupgrade -RaO at the time, and two of the three panics were at the same point - after portupgrade has performed the pre-build clean, and has printed: --- Upgrading 'xxx' to 'xxx' (xxx) --- Building '/usr/ports/xxx' panic:... (xxx was gnomevfs the first time, and sawfish the second) I'll check it in a while but the fact that only you cave sen thid does suggest that maybe you have some mixed versions or something I will blow away the whole /usr/obj and recompile with fresh source. Thanks Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- === lib/libc ... /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:88: structure has no member named `highpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:88: structure has no member named `lowpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:116: structure has no member named `highpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:116: structure has no member named `lowpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c: In function `_mcleanup': /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:195: structure has no member named `lowpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:196: structure has no member named `highpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:207: structure has no member named `lowpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c: In function `moncontrol': /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:240: structure has no member named `lowpc' *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/lib/libc. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/lib. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: a gcc3.1 bug ?
On Sun, Jul 28, 2002 at 02:40:15PM +0800, Huang wen hui wrote: /usr/src/lib/libc_r/uthread/pthread_private.h:947: parse error before `__null' /usr/src/lib/libc_r/uthread/pthread_private.h:957: parse error before `__null' /usr/src/lib/libc_r/uthread/pthread_private.h:965: parse error before `__null' gmake[2]: *** [os_linux_i486.o] Error 1 gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake[1]: *** [the_vm] Error 2 gmake[1]: Leaving directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake: *** [jvmgcore] Error 2 but if I change pthread_attr pthread_attr_default to other name, the compiler will pass. Does gcc31 have bug ? Nope, #undef that symbol. And try again. I can't remember exactly what the line is but repeat for all three places. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: a gcc3.1 bug ?
On Sun, Jul 28, 2002 at 02:40:15PM +0800, Huang wen hui wrote: /usr/ports/java/jdk13/work/hotspot1.3.1/src/os_cpu/linux_i486/vm/os_linux_i486.cpp:41: /usr/src/lib/libc_r/uthread/pthread_private.h:947: parse error before `__null' /usr/src/lib/libc_r/uthread/pthread_private.h:957: parse error before `__null' /usr/src/lib/libc_r/uthread/pthread_private.h:965: parse error before `__null' ... but if I change pthread_attr pthread_attr_default to other name, the compiler will pass. Does gcc31 have bug ? Revisited Do it like this: #undef pthread_attr_default #undef pthread_mutexattr_default #undef pthread_condattr_default #include uthread/pthread_private.h before the header files is included. I'm a bit surprised that my changes to those source files (HotSpot) weren't included in the latest release. Building it otherwise is just going to be pure hell. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: One more -CURRENT panic for collection
On 28-Jul-2002 Alexander Kabaev wrote:
#14 0xc03704e8 in calltrap () at {standard input}:98
#15 0xc02212b5 in _mtx_lock_sleep (m=0x24, opts=0, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:598
#16 0xc02b7b4d in tcp_timer_2msl (xtp=0xc31ee590)
at /usr/src/sys/netinet/tcp_timer.c:212
#17 0xc023338b in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:187
#18 0xc02198fc in ithread_loop (arg=0xc1593900)
at /usr/src/sys/kern/kern_intr.c:535
#19 0xc0218e1d in fork_exit (callout=0xc0219788 ithread_loop,
arg=0xc1593900, frame=0xd4a5fd48) at /usr/src/sys/kern/kern_fork.c:861
Hmm, INP_INFO_WLOCK() at the same place as an earlier panic. Do you have
the actual panic messages?
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
A fix of recent bugs in swapping in/out a process
If you are having a trouble of a broken thread state (eg a thread with TDS_RUNQ on no run queue) or a mysterious page fault on a kernel memory (probably in mi_switch()), you may want to try my patch at: http://people.FreeBSD.org/~tanimura/patches/procswap.diff.gz In a nutshell, this patch fixes three bugs: 1. a thread with TDS_RUNQ on no run queue. This is due to wakeup() and wakeup_one() setting the state to a thread to TDS_RUNQ even if the thread has been swapped out. As a thread being or having been swapped out cannot be scheduled immediately, introduce a new thread state TDS_SWAPPED to note that. 2. a possible race condition for multiple threads to swap in a single process. Since faultin() may block (and likely to do so) without leaving any flags for a process being swapped in, more than one threads can call faultin() for the same process. Avoid this by adding a new process state flag PS_SWAPPINGIN to a process being swapped in. 3. a running thread being swapped out. Swapout_procs() and swapout() do not check the states of the threads in a process about to be swapped out. This causes the pcb and the kernel stack of a running thread being unmapped, resulting in a page fault in cpu_switch(). Do not swap out a process unless all of its threads are either in a run queue or sleeping. Eventually, it may become our option to swap out only threads that are safe to do so. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
location of setkey in /etc/rc.d/ipsec
Hi,
I found that setup of IPsec doesn't work correctly if you are using
/etc/rc.d/. While NetBSD has setkey in /sbin, FreeBSD has it in
/usr/sbin. However, the location is hardcoded in /etc/rc.d/ipsec.
Here is a patch.
It may be a time to consider to move setkey into /sbin as NetBSD did.
Sincerely,
--- etc/rc.d/ipsec.orig Fri Jun 14 17:30:58 2002
+++ etc/rc.d/ipsec Mon Jul 29 00:03:28 2002
@@ -45,7 +45,7 @@
ipsec_start()
{
echo Installing ipsec manual keys/policies.
- /sbin/setkey -f $ipsec_file
+ setkey -f $ipsec_file
}
ipsec_stop()
@@ -56,16 +56,16 @@
# it is very questionable to do this during shutdown session, since
# it can hang any of remaining IPv4/v6 session.
#
- /sbin/setkey -F
- /sbin/setkey -FP
+ setkey -F
+ setkey -FP
}
ipsec_reload()
{
echo Reloading ipsec manual keys/policies.
- /sbin/setkey -F
- /sbin/setkey -FP
- /sbin/setkey -f $ipsec_file
+ setkey -F
+ setkey -FP
+ setkey -f $ipsec_file
}
load_rc_config $name
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- === lib/libc ... /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:88: structure has no member named `highpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:88: structure has no member named `lowpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:116: structure has no member named `highpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:116: structure has no member named `lowpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c: In function `_mcleanup': [...] DES, there wasn't enough context on this to solve the problem. Maybe the URL to the complete log should be appended to the message. I just committed a fix for this problem. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: a gcc3.1 bug ?
On Sun, Jul 28, 2002 at 03:11:01AM -0700, Bill Huey wrote: On Sun, Jul 28, 2002 at 02:40:15PM +0800, Huang wen hui wrote: /usr/ports/java/jdk13/work/hotspot1.3.1/src/os_cpu/linux_i486/vm/os_linux_i486.cpp:41: /usr/src/lib/libc_r/uthread/pthread_private.h:947: parse error before `__null' /usr/src/lib/libc_r/uthread/pthread_private.h:957: parse error before `__null' /usr/src/lib/libc_r/uthread/pthread_private.h:965: parse error before `__null' ... but if I change pthread_attr pthread_attr_default to other name, the compiler will pass. Does gcc31 have bug ? Revisited Do it like this: #undef pthread_attr_default #undef pthread_mutexattr_default #undef pthread_condattr_default #include uthread/pthread_private.h before the header files is included. I'm a bit surprised that my changes to those source files (HotSpot) weren't included in the latest release. Building it otherwise is just going to be pure hell. The patchset matches what is in the repository. Are you sure you've committed these changes? -- Greg Lewis Email : [EMAIL PROTECTED] Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic with KSE
Hi, I sometimes get a panic with KSE. panic: KSE not on run queue syncing disks... panic: bremfree: bp 0xc4014908 not locked Uptime: 53m5s Terminate ACPI This usally happends when I try to build two differnt kernels, one based on OLDCARD and the other on NEWCARD, concurrently on differnt xterms sessions. I've attached dmesg file. Hope this helps, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #5: Fri Jul 26 01:19:31 JST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/JKPC11 Preloaded elf kernel /boot/kernel/kernel at 0xc054e000. Preloaded elf module /boot/kernel/acpi.ko at 0xc054e0a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 595574627 Hz CPU: Pentium III/Pentium III Xeon/Celeron (595.57-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 134152192 (131008K bytes) avail memory = 124424192 (121508K bytes) Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00fdf50 npx0: math processor on motherboard npx0: INT 16 interface acpi0: SONY Z3 on motherboard Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xfcb0-0xfcbf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xfc60-0xfc7f at device 7.2 on pci0 acpi_pcib0: possible interrupts: 9 acpi_pcib0: routed interrupt 9 via \\_SB_.LNKD usb0: Intel 82371AB/EB (PIIX4) USB controller 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 uhub1: Philips Semiconductors hub, class 9/0, rev 1.10/1.10, addr 2 uhub1: 3 ports with 3 removable, self powered umass0: Sony USB Memory Stick Slot, rev 1.10/1.31, addr 3 pci0: bridge, PCI-unknown at device 7.3 (no driver attached) pci0: serial bus, FireWire at device 8.0 (no driver attached) pcm0: Yamaha DS-1E (YMF744) mem 0xfecf-0xfecf7fff irq 9 at device 9.0 on pci0 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0:fake locked from ../../../dev/sound/pcm/channel.c:677 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0:fake locked from ../../../dev/sound/pcm/channel.c:677 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0:fake locked from ../../../dev/sound/pcm/channel.c:677 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0:fake locked from ../../../dev/sound/pcm/channel.c:677 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134 ../../../vm/uma_core.c:1332: could sleep with pcm0 locked from ../../../dev/sound/pcm/sound.c:134
Re: A fix of recent bugs in swapping in/out a process
Date: Sun, 28 Jul 2002 21:51:57 +0900 From: Seigo Tanimura [EMAIL PROTECTED] If you are having a trouble of a broken thread state (eg a thread with TDS_RUNQ on no run queue) or a mysterious page fault on a kernel memory (probably in mi_switch()), you may want to try my patch at: http://people.FreeBSD.org/~tanimura/patches/procswap.diff.gz I was having this kind of trouble with my (UP) laptop, but not my (SMP) build machine. However, the laptop may also be having some hardware issues, so I didn't press the issue But after getting another panic after trying to reboot after installing today's -CURRENT on the laptop, I applied that patch, and so far, things seem better. What I did: * Fetched the patch unzipped it. * cd /usr/src/sys patch -p6 ~/PATCHES/procswap.diff (I actually ran patch -C first, to verify that things looked good.) * cd /usr/src make kernel KERNCONF=LAPTOP_30W * reboot (after a few syncs, in case that might help). * cd /usr/src date make installworld date \ mergemaster -u 0022 -i date df -k (I.e., re-do the make installworld mergemaster steps from the install where I had a panic on reboot, both to have some assurance that files I'd rather have didn't get truncated, and to serve as a first- order test of the patched code.) * reboot * Run a few tests. So far, so good. Thanks! Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between Microsoft and the discipline of systems administration, since they have nothing in common. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: A fix of recent bugs in swapping in/out a process
On Sun, 28 Jul 2002, Seigo Tanimura wrote: If you are having a trouble of a broken thread state (eg a thread with TDS_RUNQ on no run queue) or a mysterious page fault on a kernel memory (probably in mi_switch()), you may want to try my patch at: http://people.FreeBSD.org/~tanimura/patches/procswap.diff.gz I applied this patch a few hours ago and have not had a panic since, even though the box has been used a lot and has been swapping a lot. It looks like this has fixed my problem. Thanks! gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: a gcc3.1 bug ?
On Mon, Jul 29, 2002 at 01:43:21AM +0930, Greg Lewis wrote: The patchset matches what is in the repository. Are you sure you've committed these changes? I missed that changed some how, it's now commited. ;) bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current now really bad
I cvsup'd and built last night around midnight and now I can reliably induce a freeze by firing up X and trying to load a page in mozilla (firing up mozilla doesn't do it, but the first page i try to load kills it). I get no crash dumps, and have to physically power the machine down. Attatched is a dmesg from my machine. I'm running: Mozilla 1.0 Release Candidate 2 XFree86 Version 4.2.0 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 January 2002 sawfish version 1.0.1 I'm not sure how to find my gnome version... Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #9: Sun Jul 28 00:46:20 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP Preloaded elf kernel /boot/kernel/kernel at 0xc04ae000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04ae0a8. Timecounter i8254 frequency 1193182 Hz CPU: AMD Athlon(TM) XP 1600+ (1400.06-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 536788992 (524208K bytes) avail memory = 515735552 (503648K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2,version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled Using $PIR table, 9 entries at 0xc00f1370 npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7M266-D on motherboard acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 5.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: AMD 768 ATA100 controller port 0xd800-0xd80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: bridge, PCI-unknown at device 7.3 (no driver attached) ahc0: Adaptec 3960D Ultra160 SCSI adapter port 0xd400-0xd4ff mem 0xed80-0xed800fff irq 10 at device 9.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: Adaptec 3960D Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xed00-0xed000fff irq 5 at device 9.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs pcib2: PCI-PCI bridge at device 16.0 on pci0 pci2: PCI bus on pcib2 fxp0: Intel Pro 10/100B/100+ Ethernet port 0xb800-0xb83f mem 0xeb80-0xeb8f,0xec00-0xec000fff irq 10 at device 6.0 on pci2 fxp0: Ethernet address 00:90:27:bc:09:95 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: multimedia, audio at device 8.0 (no driver attached) pci2: input device at device 8.1 (no driver attached) ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse Explorer, device ID 4 orm0: Option ROMs at iomem 0xd8000-0xd8fff,0xc-0xcc7ff on isa0 fdc0: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 12949MB IBM-DJNA-371350 [26310/16/63] at ata0-master UDMA66 acd0: DVD-ROM CREATIVEDVD8400E at ata1-master PIO4 Mounting root from ufs:/dev/ad0s1a SMP: AP CPU #1 Launched! cd0 at ahc0 bus 0 target 4 lun 0 cd0: PLEXTOR CD-R PX-W1210S 1.01 Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY,
Re: -current now really bad
On Sun, 2002-07-28 at 16:24, Lamont Granquist wrote: I cvsup'd and built last night around midnight and now I can reliably induce a freeze by firing up X and trying to load a page in mozilla (firing up mozilla doesn't do it, but the first page i try to load kills it). I get no crash dumps, and have to physically power the machine down. uh oh, I'm downloading -current source right_now... 8-( --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current now really bad
On Sun, Jul 28, 2002 at 04:24:41PM -0700, Lamont Granquist wrote: I cvsup'd and built last night around midnight and now I can reliably induce a freeze by firing up X and trying to load a page in mozilla (firing up mozilla doesn't do it, but the first page i try to load kills it). I get no crash dumps, and have to physically power the machine down. Attatched is a dmesg from my machine. I'm running: Mozilla 1.0 Release Candidate 2 XFree86 Version 4.2.0 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 January 2002 sawfish version 1.0.1 I'm not sure how to find my gnome version... Do you have INET6 defined in your kernel config? If so, take it out and build a new kernel. This fixed very simialr problems that I was having. I posted details to this list a few days ago and was met with silence =-( Scott Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #9: Sun Jul 28 00:46:20 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP Preloaded elf kernel /boot/kernel/kernel at 0xc04ae000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04ae0a8. Timecounter i8254 frequency 1193182 Hz CPU: AMD Athlon(TM) XP 1600+ (1400.06-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 536788992 (524208K bytes) avail memory = 515735552 (503648K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2,version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled Using $PIR table, 9 entries at 0xc00f1370 npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7M266-D on motherboard acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 5.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: AMD 768 ATA100 controller port 0xd800-0xd80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: bridge, PCI-unknown at device 7.3 (no driver attached) ahc0: Adaptec 3960D Ultra160 SCSI adapter port 0xd400-0xd4ff mem 0xed80-0xed800fff irq 10 at device 9.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: Adaptec 3960D Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xed00-0xed000fff irq 5 at device 9.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs pcib2: PCI-PCI bridge at device 16.0 on pci0 pci2: PCI bus on pcib2 fxp0: Intel Pro 10/100B/100+ Ethernet port 0xb800-0xb83f mem 0xeb80-0xeb8f,0xec00-0xec000fff irq 10 at device 6.0 on pci2 fxp0: Ethernet address 00:90:27:bc:09:95 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: multimedia, audio at device 8.0 (no driver attached) pci2: input device at device 8.1 (no driver attached) ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse Explorer, device ID 4 orm0: Option ROMs at iomem 0xd8000-0xd8fff,0xc-0xcc7ff on isa0 fdc0: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 12949MB IBM-DJNA-371350 [26310/16/63] at ata0-master UDMA66 acd0:
I did not send dozens of QUIT messages
This is either a problem with linux-netscape on -current, or a problem with the mta at Verio (on FBSD of course). Sorry for the inconvenience. I hope it isn't at Verio, or there will be another 30 messages. Rob. -- - The Numeric Python EM Project www.pythonemproject.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
re current errata info for os-4.2
How do I the curent errata text data for my version-4.2 of freebsd? thanks C Hurst
Removing INET6 does stop the crashes.
After reading Scott Long's recent post I tried removing INET6 from my kernel config and the crashes due to mozilla are now definitely gone. The question remains, I suppose, whether there are other programs that will still trigger the same kernel bug in a different way, or whether the bug truly is in the INET6 code. I do know I was never trying to connect to any ipv6 site during the crashes, which seems a bit suspicious. If Seigo Tanimura's recent swapping patch also fixes the crashing (I haven't yet tried it) then perhaps the INET6 thing is just a red herring--but for now it seems okay to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing INET6 does stop the crashes.
Yeah, removing INET6 seems to make it much more stable for me as well. On Sun, 28 Jul 2002, walt wrote: After reading Scott Long's recent post I tried removing INET6 from my kernel config and the crashes due to mozilla are now definitely gone. The question remains, I suppose, whether there are other programs that will still trigger the same kernel bug in a different way, or whether the bug truly is in the INET6 code. I do know I was never trying to connect to any ipv6 site during the crashes, which seems a bit suspicious. If Seigo Tanimura's recent swapping patch also fixes the crashing (I haven't yet tried it) then perhaps the INET6 thing is just a red herring--but for now it seems okay to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
net.inet6.ip6.v6only = 0 also stops the crashes.
Well, being a bit suspicious, I put INET6 back in the kernel and tried it again. What I find is that the crashes stop as long as net.inet6.ip6.ip6only is set to zero. When I set it to one the crashes continue as before: When trying to fetch mail with mozilla I get error messages that the connections to my pop3 and imap servers are refused; the screen then freezes up and the machine reboots spontaneously. Naddy Weisgerber seems to be implying in the ports mailing list that the default value of ip6only has recently changed to 1. If this change happened on July 25, as I suspect, then perhaps this is not a new bug at all, but has just been unmasked by the new default value of ip6only? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic with KSE
I think this has just been found and fixed by: Seigo Tanimura [EMAIL PROTECTED], (CC'd) his fix is at: http://people.FreeBSD.org/~tanimura/patches/procswap.diff.gz please try it! let us know if it fixes your problem. On Mon, 29 Jul 2002, Munehiro Matsuda wrote: Hi, I sometimes get a panic with KSE. panic: KSE not on run queue syncing disks... panic: bremfree: bp 0xc4014908 not locked Uptime: 53m5s Terminate ACPI This usally happends when I try to build two differnt kernels, one based on OLDCARD and the other on NEWCARD, concurrently on differnt xterms sessions. I've attached dmesg file. Hope this helps, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Mike Barcroft [EMAIL PROTECTED] writes: DES, there wasn't enough context on this to solve the problem. I don't really see what more you need. What's missing? The first line and cause of the subsequent errors: In file included from /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:43: /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include/sys/gmon.h:168: syntax error before uintfptr_t Since when I see: /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:86: structure has no member named `lowpc' /usr/home/des/tinderbox/sparc64/src/lib/libc/gmon/gmon.c:87: structure has no member named `highpc' ...it doesn't immediately occur to me that the reason those members don't exist is because of a syntax error. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Mike Barcroft [EMAIL PROTECTED] writes: Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Mike Barcroft [EMAIL PROTECTED] writes: DES, there wasn't enough context on this to solve the problem. I don't really see what more you need. What's missing? The first line and cause of the subsequent errors: Ah, looks like a bug in whereintheworld. It's not supposed to truncate error messages. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Ah, looks like a bug in whereintheworld. It's not supposed to truncate error messages. I've hacked whereintheworld to print everything since the last '===' in case of an error, rather than just the last ten lines. If anyone is interested it's in ~des/bin on freefall. I've already updated the copy on bowie, so the sparc64 builds should be fine now. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re current errata info for os-4.2
In the last episode (Jul 28), MR. C. WILLIAM HURST said: How do I the curent errata text data for my version-4.2 of freebsd? thanks There were no errata for 4.2 at the time 4.3 was released. You can probably consider all security advisories for 4.[3456] to apply to 4.2, though: http://www.freebsd.org/releases/4.3R/errata.html http://www.freebsd.org/releases/4.4R/errata.html http://www.freebsd.org/releases/4.5R/errata.html http://www.freebsd.org/releases/4.6R/errata.html -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Ah, looks like a bug in whereintheworld. It's not supposed to truncate error messages. I've hacked whereintheworld to print everything since the last '===' in case of an error, rather than just the last ten lines. If anyone is interested it's in ~des/bin on freefall. I've already updated the copy on bowie, so the sparc64 builds should be fine now. Thanks. Do you want to increase the tinderbox to run twice a day? Not many people are using the system since a sparc64 was added to the cluster. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: where's perl???
Steve Kargl wrote: On Fri, Jul 26, 2002 at 03:41:59PM -0400, Garance A Drosihn wrote: At 12:01 PM +0200 7/26/02, Michael Nottebrock wrote: That said though, it would be good to have something a little smarter than a blind find|rm which did find old files, and move them out of the way. [move, not remove -- just in case it picks the wrong files!] rm(1) does take a -i option. Perhaps a note in UPDATING about how to remove the system perl and replace it with the port would be useful. -- 3D Research Associate+61 8 8302 3669 School of Computer and Information Science Room D1-07, Levels Campus University of South AustraliaMawson Lakes Blvd. [EMAIL PROTECTED] South Australia, 5095 F00D C83D 5F7E 5561 DF91 B74D E602 CAA3 4842 B5B4 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
