Re: make buildworld crashing
On 2002-07-29 20:15 +, karl agee wrote: I just updated my source and running make buildworld crashes here: cd /usr/src/usr.bin/makewhatis; make DIRPRFX=usr.bin/makewhatis/ obj; make DIRPRFX=usr.bin/makewhatis/ depend; make DIRPRFX=usr.bin/makewhatis/ all; make DIRPRFX=usr.bin/makewhatis/ DESTDIR=/usr/obj/usr/src/i386 install /usr/obj/usr/src/i386/usr/src/usr.bin/makewhatis created for /usr/src/usr.bin/makewhatis make: don't know how to make bsd.README. Stop *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. cd /usr/src/share/mk make install I believe (hope?) that fixes it. -- Munish Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD low power hacks
Michael Nottebrock writes: The following is an OpenPGP/MIME signed message created by Enigmail/Mozilla, following RFC 2440 and RFC 2015 --enig8A086DA17DCB77CC40984CC4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've been wondering lately why my AthlonTB runs at a quite high idle-temperature and I came across this page: http://vcool.occludo.net/VC_Theory.html Does someone feel like getting something similar into our kernel? If you have a VIA KT266A chipset then you can do something like this: # turn on HALT bit in register 0x95 of the KT266a - CPU runs much cooler # NOTE: the register had 0x1c when I checked it echo Enable halt bit in KT266A /usr/sbin/pciconf -w -b pci0:0:0 0x95 0x1e which I have in /etc/rc.local. My Athlon runs about 15 C cooler with this. Bit 1 of register 0x95 controls idling of the CPU. Here's a step-by-step description: Do the following as root: 1) pciconf -l -v this lists all the PCI chipsets found at boot time. I see agp0@pci0:0:0: class=0x06 card=0x30991106 chip=0x30991106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8366/A Apollo KT266/A,KT333 CPU to PCI Bridge' class= bridge subclass = HOST-PCI So I have a KT266(A) at pci0:0:0 2) pciconf -r -b pci0:0:0 0x95 0x1c Bit 1 isn't set 3) pciconf -w -b pci0:0:0 0x95 0x1e turns on bit 1. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing INET6 does stop the crashes.
Hi,
Tue, 30 Jul 2002 02:12:41 +0900,
Hajimu UMEMOTO [EMAIL PROTECTED] said:
wa1ter Yes, it stops the crashes. If I set v6only = 0 then the machine
wa1ter works normally; if set to 1 then I get connection refused from
wa1ter any server I try to connect to. Is that normal v6only behavior?
ume It is expected behaivior. However, I realized that Mozilla still has
ume the problem that IPv4-mapped IPv6 address is used to connect to IPv4
ume site. It should be fixed by Mozilla side. I heared that NetBSD
ume pkgsrc has a workaround to this problem:
ume
http://cvsweb.no.netbsd.org/bsdweb.cgi/pkgsrc/www/mozilla/patches/patch-be?rev=1.8content-type=text/x-cvsweb-markup
ume Our port should have it, too.
This patch is for ports/www/mozilla, and enables IPv4-mapped IPv6
address per socket basis. Please try it.
Sincerely,
Index: nsprpub/pr/src/pthreads/ptio.c
diff -u nsprpub/pr/src/pthreads/ptio.c.orig nsprpub/pr/src/pthreads/ptio.c
--- nsprpub/pr/src/pthreads/ptio.c.orig Fri Apr 12 03:14:39 2002
+++ nsprpub/pr/src/pthreads/ptio.c Tue Jul 30 18:52:11 2002
@@ -3414,6 +3414,17 @@
if (osfd == -1) pt_MapError(_PR_MD_MAP_SOCKET_ERROR, errno);
else
{
+#if (defined(_PR_INET6_PROBE) || defined(_PR_INET6)) \
+ defined(__FreeBSD__) defined(IPV6_V6ONLY)
+ if (domain == PR_AF_INET6) {
+ int opt = 0;
+ if (setsockopt(osfd, IPPROTO_IPV6, IPV6_V6ONLY,
+ opt, sizeof(opt))) {
+close(osfd);
+return NULL;
+ }
+ }
+#endif
fd = pt_SetMethods(osfd, ftype, PR_FALSE, PR_FALSE);
if (fd == NULL) close(osfd);
}
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
ASUS/P3BF: _SB_.LNKB - AE_BAD_DATA
What does this mean? acpi0: ASUS P3B_Fon motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz can't fetch resources for \\_SB_.LNKB - AE_BAD_DATA acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: Most recently used by kqueue
Hi
System was generated Sunday evening (without INET6 option in kernel
config). At the time of the panic
I was running mozilla, xmms, and gkrellm. I hope the attachment is of
some use.
--
Regards
Peter
As always the organisation disavows knowledge of this email
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Script started on Tue Jul 30 20:14:40 2002
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bremfree: bp 0xc686fe48 not locked
panic messages:
---
panic: Most recently used by kqueue
syncing disks... panic: bremfree: bp 0xc686fe48 not locked
Uptime: 42m24s
pfs_vncache_unload(): 1 entries remaining
Dumping 255 MB
ata1: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:213
213 dumping++;
(kgdb) where
#0 doadump () at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:213
#1 0xc028895a in boot (howto=260)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:345
#2 0xc0288b19 in panic ()
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:493
#3 0xc02ba889 in bremfree (bp=0xc686fe48)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/vfs_bio.c:633
#4 0xc02bbffa in vfs_bio_awrite (bp=0xc686fe48)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/vfs_bio.c:1627
#5 0xc0262950 in spec_fsync (ap=0xd00279dc)
at /mnt/aux3/cvs/freebsd/usr/src/sys/fs/specfs/spec_vnops.c:406
#6 0xc026253f in spec_vnoperate (ap=0x0)
at /mnt/aux3/cvs/freebsd/usr/src/sys/fs/specfs/spec_vnops.c:124
#7 0xc03584ed in ffs_sync (mp=0xc185c800, waitfor=2, cred=0xc0ef5e00, td=0xc046b6a0)
at vnode_if.h:463
#8 0xc02c9670 in sync (td=0xc046b6a0, uap=0x0)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/vfs_syscalls.c:127
#9 0xc0288601 in boot (howto=256)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:254
#10 0xc0288b19 in panic ()
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:493
#11 0xc0376bfc in mtrash_ctor (mem=0xc1cff700, size=0, arg=0x0)
at /mnt/aux3/cvs/freebsd/usr/src/sys/vm/uma_dbg.c:135
#12 0xc0375b57 in uma_zalloc_arg (zone=0xc0ecf140, udata=0x0, flags=1)
at /mnt/aux3/cvs/freebsd/usr/src/sys/vm/uma_core.c:1358
#13 0xc027fbd4 in malloc (size=4, type=0xc04783c0, flags=0)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_malloc.c:171
#14 0xc02debac in rt_msg2 (type=14, rtinfo=0xd0027b44, cp=0x0, w=0xd0027b94)
at /mnt/aux3/cvs/freebsd/usr/src/sys/net/rtsock.c:690
#15 0xc02df0f0 in sysctl_iflist (af=0, w=0xd0027b94)
at /mnt/aux3/cvs/freebsd/usr/src/sys/net/rtsock.c:954
#16 0xc02df309 in sysctl_rtsock (oidp=0xc04784e0, arg1=0xd0027cbc, arg2=4,
req=0xd0027c08) at /mnt/aux3/cvs/freebsd/usr/src/sys/net/rtsock.c:1032
#17 0xc028f7b1 in sysctl_root (oidp=0x0, arg1=0xd0027cb4, arg2=6, req=0xd0027c08)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_sysctl.c:1104
#18 0xc028f980 in userland_sysctl (td=0x0, name=0xd0027cb4, namelen=6,
old=0xd0027c60, oldlenp=0xa, inkernel=0, new=0xd0027c30, newlen=0,
retval=0xd0027cb0) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_sysctl.c:1202
#19 0xc028f845 in __sysctl (td=0xc17fef00, uap=0xd0027d14)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_sysctl.c:1141
#20 0xc039f134 in syscall (frame=
{tf_fs = 47, tf_es = 135331887, tf_ds = -1078001617, tf_edi = 6, tf_esi =
135884800, tf_ebp = -1077938100, tf_isp = -805143180, tf_ebx = 676064028, tf_edx =
135005808, tf_ecx = -1077938024, tf_eax = 202, tf_trapno = 22, tf_err = 2, tf_eip =
675666455, tf_cs = 31, tf_eflags = 658, tf_esp = -1077938160, tf_ss = 47})
at /mnt/aux3/cvs/freebsd/usr/src/sys/i386/i386/trap.c:1050
#21 0xc03925cd in syscall_with_err_pushed () at {standard input}:128
---Can't read userspace from dump, or kernel process---
(kgdb) up 11
#11 0xc0376bfc in mtrash_ctor (mem=0xc1cff700, size=0, arg=0x0)
at /mnt/aux3/cvs/freebsd/usr/src/sys/vm/uma_dbg.c:135
135 panic(Most recently used by %s\n, (*ksp == NULL)?
(kgdb) l
130
131 for (p = mem; cnt 0; cnt--, p++)
132 if (*p != uma_junk) {
133 printf(Memory modified after free %p(%d)\n,
134 mem, size);
135 panic(Most recently used by %s\n, (*ksp == NULL)?
136 none : (*ksp)-ks_shortdesc);
137 }
138 }
139
(kgdb) p uma_junk
$1 = 3735929054
(kgdb) p *(u_int32_t *)mem
$2 = 3735929054
(kgdb) p *(u_int32_t *)mem[1@(mem + 4)
$3 = 3735929054
Re: minor OPIE + telnet nit
David O'Brien [EMAIL PROTECTED] writes: What I type for the password is not echoed. Yeah, thanks. I'll fix it ASAP. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: minor OPIE + telnet nit
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: David O'Brien [EMAIL PROTECTED] writes: What I type for the password is not echoed. Yeah, thanks. I'll fix it ASAP. See revision 1.23 of src/lib/libpam/modules/pam_opie/pam_opie.c. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
when will be MFC src/contrib/smbfs?
At 23 July 2002 in -CURRENT was imported new version of smbfs: 22.07.2002 1.4.5 (bug fix only) - Some iconv libraries may refuse to recode some characters. This caused problems with translation between server and local charsets. That bugfix realy important to correct work with cyrillic letters in filenames on smbfs. So, when will be MFC src/contrib/smbfs? -- Vitaly Markitantov mailto: [EMAIL PROTECTED] icq: 117438950 phone: (062)332-23-90 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
`ld -R' is broken in -current
Hi, It appears that `ld -R' is broken in -current. Small test case illustrating the problem could be found here: http://people.freebsd.org/~sobomax/ld,-R.tar. The test case works in -stable, but not in -current. Please fix. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: install -d -C (was: Re: cvs commit: src/share/man/man5 make.conf.5 src/share/examples/etc make.conf)
On Tue, Jul 30, 2002 at 06:21:17AM +1000, Bruce Evans wrote:
On Mon, 29 Jul 2002, Ruslan Ermilov wrote:
On Fri, Jul 19, 2002 at 10:55:56PM +1000, Bruce Evans wrote:
On Fri, 19 Jul 2002, Ruslan Ermilov wrote:
OTOH, if we go this way we can get rid of ugly ${COPY} completely.
I'd like to get rid of it too. But not in RELENG_4. -c has been the default
for long enough now in -current. As you know, there are various problems
in using the correctly named variable for install(1)'s flags (INSTALLFLAGS)
to actually hold install's flags in a general way (mainly, this variable
already exists and is used in a non-general way). However, the old hack
of putting the flags in the same variable as the command still works well
except for the -[Cp] vs -d conflict. This depends on the flags not being
order-dependent.
OK, -[CpS] are now ignored with -d, and I've dropped support for COPY.
I have a question. Why COPY can't be removed from RELENG_4 as well?
Ports that use COPY (there are many of them) will see it as an empty
string.
-c hasn't been the default for so long in RELENG_4, so I think the change
has too lrge a risk/reward ratio.
Can you envision any breakage caused by me removing COPY?=-c from
RELENG_4's bsd.own.mk? We bootstrap install(1), so it's in my
opinion safe to assume that on a system without COPY in bsd.own.mk
install(1) copies files by default, no? bsd.port.mk and many
ports that use ${COPY} will substitute an empty string. If you
disagree, what do you propose? Remove any usages of COPY from
src/ and leave its definition in bsd.own.mk? What purpose would
it serve then?
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg41525/pgp0.pgp
Description: PGP signature
NIS and getpwent(3)
[Sorry for x-posting, not sure where this is more relevant.] Hi! I have hit the following nasty problem with /etc/periodic/daily/300.calendar while using NIS. We have our NIS database distributed with all shells switched off to /sbin/nologin, and overriding shells as necessary on machines where we need it. Something like this: +ru:/bin/tcsh +: When calendar(1)'s -a option is in use, the code traverses the list of all users in the getpwent(3) cycle, checks to see if the user has a valid calendar file, and if so, mails him the current entries (if there are). The problem is that the ru entry is reported by getpwent(3) twice, first with /bin/tcsh shell, and second with the /sbin/nologin shell. The net effect is that you get your calendar mail twice. Is this the correct behavior of getpwent(3), and then what do we do with calendar(1), or getpwent(3) is in trouble? (I've checked that on both 4.x and 5.0.) Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg41526/pgp0.pgp Description: PGP signature
Crash -CURRENT BOX while jdk-p7 with gdb
I got a problem with jdk-p7+XIM input server. I try to use gdb to find out. But if I run gdb on X11, -CURRENT(07/29) box will crash immediately: gdb file /usr/local/jdk1.3.1/bin/i386/green_threads/java_g gdb run -version panic: blockable sleep lock (sleep mutex) sellck @ ../../../kern/sys_generic.c:1178 Debugger(panic) Stopped at Debugger+0x45: xchgl %ebx, in_Debugger.0 dbtr Debugger(c043bffc) at Debugger+0x45 Panic(.) at panic+0x7c witness_lock(...) at witness_lock+0x7f _mtx_lock_flags(...) at _mxt_lock_flags+0x6b selwakeup(...) at selwakeup+0x1e ptcwakeup(...) at ptcwakeup+0x23 ptsstart(...) at ptsstart+0x2c ttstart(...) at ttstart+0x16 tputchar(...) at tputchar+0x35 putchar(...) at putchar+0x55 kvprintf(...) at kvprintf+0x77 printf(...) at printf+0x43 userret(...) at userret+0xd9 ast(...) at ast+02b5 doreti_ast() at doreti_ast+0x1a On text console, -CURRENT box will not crash. and I got msg: gdb file /usr/local/jdk1.3.1/bin/i386/green_threads/java_g gdb run -version lock order reversal 1st 0xc44e0180 pipe mutex (pipe mutex) @ ../../../kern/sys_pipe.c:451 2nd 0xc04af6c0 sigio lock (sigio lock) @ ../../../kern/kern_sig.c:2014 failed to set signal flags properlyt for ast() failed to set signal flags properlyt for ast() failed to set signal flags properlyt for ast() failed to set signal flags properlyt for ast() failed to set signal flags properlyt for ast() failed to set signal flags properlyt for ast() failed to set signal flags properlyt for ast() I comment printf in function userret in file /usr/src/sys/kern/subr_trap.c the box does not crash now. so It is not safe for using printf in /usr/src/sys/kern/subr_trap.c ? --hwh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Ugly fix patchset7 + XIM server(was: patchset 7 crash under -CURRENT+ chinese XIM Server.)
Huang wen hui дµÀ: Hi, I install JDK1.3.1-p7 + hostspot( compiler1) under -CURRENT(2002/07/27). and use chinput as XIM Server. jdk works fine under -STABLE or -CURRENT without starting XIM Server. but crash quickly under -CURRENT + chinese XIM Server. hotspot vm also crash. I recompile open-motif before build jdk. %java_g -jar /usr/local/jdk1.3.1/demo/jfc/Notepad/Notepad.jar SIGBUS 10* bus error Full thread dump Classic VM (1.3.1-p7-root-020727-22:30, green threads): AWT-Motif (TID:0x28eecfa0, sys_thread_t:0x8407080, state:MW) prio=6 at sun.awt.motif.MToolkit.run(Native Method) at java.lang.Thread.run(Thread.java:484) SunToolkit.PostEventQueue-0 (TID:0x28eecb90, sys_thread_t:0x83d9680, state:CW) prio=6 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at sun.awt.PostEventQueue.run(SunToolkit.java:491) AWT-EventQueue-0 (TID:0x28eecbb8, sys_thread_t:0x83d9480, state:CW) prio=6 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at java.awt.EventQueue.getNextEvent(EventQueue.java:260) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:106) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:98) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) Finalizer (TID:0x28ebf530, sys_thread_t:0x80d9080, state:CW) prio=8 at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:108) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:123) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:162) Reference Handler (TID:0x28ebf308, sys_thread_t:0x8096480, state:CW) prio=10 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:110) Signal dispatcher (TID:0x28ebf338, sys_thread_t:0x8096280, state:CW) prio=5 main (TID:0x28ebf2f0, sys_thread_t:0x8054080, state:R) prio=5 at sun.awt.motif.MToolkit.loadSystemColors(Native Method) at java.awt.SystemColor.updateSystemColors(SystemColor.java:342) at java.awt.SystemColor.clinit(SystemColor.java:335) at sun.awt.motif.MWindowPeer.init(MWindowPeer.java:109) at sun.awt.motif.MFramePeer.init(MFramePeer.java:53) at sun.awt.motif.MToolkit.createFrame(MToolkit.java:138) at java.awt.Frame.addNotify(Frame.java:353) at javax.swing.plaf.metal.BumpBuffer.createComponent(MetalBumps.java:209) at javax.swing.plaf.metal.BumpBuffer.init(MetalBumps.java:147) at javax.swing.plaf.metal.MetalBumps.createBuffer(MetalBumps.java:61) at javax.swing.plaf.metal.MetalBumps.setBumpColors(MetalBumps.java:96) at javax.swing.plaf.metal.MetalBumps.init(MetalBumps.java:53) at javax.swing.plaf.metal.MetalScrollBarUI.installDefaults(MetalScrollBarUI.java:80) at javax.swing.plaf.basic.BasicScrollBarUI.installUI(BasicScrollBarUI.java:98) at javax.swing.JComponent.setUI(JComponent.java:322) at javax.swing.JScrollBar.updateUI(JScrollBar.java:189) at javax.swing.JScrollBar.init(JScrollBar.java:140) at javax.swing.JScrollBar.init(JScrollBar.java:155) at javax.swing.JScrollPane$ScrollBar.init(JScrollPane.java:635) at javax.swing.JScrollPane.createVerticalScrollBar(JScrollPane.java:780) at javax.swing.JScrollPane.init(JScrollPane.java:242) at javax.swing.JScrollPane.init(JScrollPane.java:290) at Notepad.init(Notepad.java:95) at Notepad.main(Notepad.java:128) Monitor Cache Dump: sun.awt.PostEventQueue@28EECB90/29059548: unowned Waiting to be notified: SunToolkit.PostEventQueue-0 (0x83d9680) java.lang.Class@28ED7258/28F350B0: owner main (0x8054080) 1 entry Waiting to enter: AWT-Motif (0x8407080) java.lang.ref.Reference$Lock@28EBF318/28EF53F8: unowned Waiting to be notified: Reference Handler (0x8096480) java.awt.EventQueue@28EECC58/290590C8: unowned Waiting to be notified: AWT-EventQueue-0 (0x83d9480) java.lang.ref.ReferenceQueue$Lock@28EBF5B8/28EF5948: unowned Waiting to be notified: Finalizer (0x80d9080) java.awt.Component$AWTTreeLock@28ECA2E0/28F41470: owner main (0x8054080) 1 entry Registered Monitor Dump: utf8 hash table: unowned JNI pinning lock: unowned JNI global reference lock: unowned BinClass lock: unowned Class linking lock: unowned System class loader lock: unowned Code rewrite lock: unowned Heap lock: unowned Monitor cache lock: owner main (0x8054080) 1 entry Dynamic loading lock: unowned Monitor IO lock: unowned User signal monitor: unowned Waiting to be notified: Signal dispatcher (0x8096280) Child death monitor: unowned I/O monitor: unowned Alarm monitor: unowned Waiting to be notified: unknown thread (0x8054280) Thread queue lock: owner main (0x8054080) 1 entry Monitor registry: owner main (0x8054080) 1 entry SIGABRT 6* abort (generated by abort(3) routine) Full thread dump Classic VM (1.3.1-p7-root-020727-22:30, green threads): AWT-Motif (TID:0x28eecfa0, sys_thread_t:0x8407080, state:MW) prio=6 at sun.awt.motif.MToolkit.run(Native Method) at
Re: AMD low power hacks
Just confirmed this works on the KT333 as well. Aaron On Tuesday 30 July 2002 03:00 am, Gary Jennejohn wrote: Michael Nottebrock writes: The following is an OpenPGP/MIME signed message created by Enigmail/Mozilla, following RFC 2440 and RFC 2015 --enig8A086DA17DCB77CC40984CC4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've been wondering lately why my AthlonTB runs at a quite high idle-temperature and I came across this page: http://vcool.occludo.net/VC_Theory.html Does someone feel like getting something similar into our kernel? If you have a VIA KT266A chipset then you can do something like this: # turn on HALT bit in register 0x95 of the KT266a - CPU runs much cooler # NOTE: the register had 0x1c when I checked it echo Enable halt bit in KT266A /usr/sbin/pciconf -w -b pci0:0:0 0x95 0x1e which I have in /etc/rc.local. My Athlon runs about 15 C cooler with this. Bit 1 of register 0x95 controls idling of the CPU. Here's a step-by-step description: Do the following as root: 1) pciconf -l -v this lists all the PCI chipsets found at boot time. I see agp0@pci0:0:0: class=0x06 card=0x30991106 chip=0x30991106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8366/A Apollo KT266/A,KT333 CPU to PCI Bridge' class= bridge subclass = HOST-PCI So I have a KT266(A) at pci0:0:0 2) pciconf -r -b pci0:0:0 0x95 0x1c Bit 1 isn't set 3) pciconf -w -b pci0:0:0 0x95 0x1e turns on bit 1. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Crash -CURRENT BOX while jdk-p7 with gdb
On Wed, 31 Jul 2002, Huang wen hui wrote: I got a problem with jdk-p7+XIM input server. I try to use gdb to find out. But if I run gdb on X11, -CURRENT(07/29) box will crash immediately: gdb file /usr/local/jdk1.3.1/bin/i386/green_threads/java_g gdb run -version panic: blockable sleep lock (sleep mutex) sellck @ ../../../kern/sys_generic.c:1178 Debugger(panic) Stopped at Debugger+0x45: xchgl %ebx, in_Debugger.0 dbtr Debugger(c043bffc) at Debugger+0x45 Panic(.) at panic+0x7c witness_lock(...) at witness_lock+0x7f _mtx_lock_flags(...) at _mxt_lock_flags+0x6b selwakeup(...) at selwakeup+0x1e ptcwakeup(...) at ptcwakeup+0x23 ptsstart(...) at ptsstart+0x2c ttstart(...) at ttstart+0x16 tputchar(...) at tputchar+0x35 putchar(...) at putchar+0x55 kvprintf(...) at kvprintf+0x77 printf(...) at printf+0x43 userret(...) at userret+0xd9 ast(...) at ast+02b5 doreti_ast() at doreti_ast+0x1a On text console, -CURRENT box will not crash. and I got msg: gdb file /usr/local/jdk1.3.1/bin/i386/green_threads/java_g gdb run -version lock order reversal 1st 0xc44e0180 pipe mutex (pipe mutex) @ ../../../kern/sys_pipe.c:451 2nd 0xc04af6c0 sigio lock (sigio lock) @ ../../../kern/kern_sig.c:2014 failed to set signal flags properlyt for ast() failed to set signal flags properlyt for ast() failed to set signal flags properlyt for ast() failed to set signal flags properlyt for ast() failed to set signal flags properlyt for ast() failed to set signal flags properlyt for ast() failed to set signal flags properlyt for ast() I comment printf in function userret in file /usr/src/sys/kern/subr_trap.c the box does not crash now. so It is not safe for using printf in /usr/src/sys/kern/subr_trap.c ? No, since printf itself is broken. The TIOCCONS ioctl is broken in all cases and the syscons console driver is broken in some cases. Don't use xconsole or anything else that uses the TIOCCONS ioctl. Commenting out the printf is as good a workaround as any. Some printfs in mi_switch() are still commented out because of this bug. Try the following patch for fixing the problem reported by the printf. %%% Index: kern_sig.c === RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v retrieving revision 1.175 diff -u -2 -r1.175 kern_sig.c --- kern_sig.c 10 Jul 2002 06:31:35 - 1.175 +++ kern_sig.c 21 Jul 2002 01:25:04 - @@ -1634,4 +1609,5 @@ if (SIGISMEMBER(p-p_sigmask, sig)) continue; + signotify(p); } %%% Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NIS and getpwent(3)
In the last episode (Jul 30), Ruslan Ermilov said: [Sorry for x-posting, not sure where this is more relevant.] I have hit the following nasty problem with /etc/periodic/daily/300.calendar while using NIS. We have our NIS database distributed with all shells switched off to /sbin/nologin, and overriding shells as necessary on machines where we need it. Something like this: +ru:/bin/tcsh +: The problem is that the ru entry is reported by getpwent(3) twice, first with /bin/tcsh shell, and second with the /sbin/nologin shell. The net effect is that you get your calendar mail twice. Is this the correct behavior of getpwent(3), and then what do we do with calendar(1), or getpwent(3) is in trouble? (I've checked that on both 4.x and 5.0.) It looks like the correct behaviour. The nsswitch.conf manpage on FreeBSD actually mentions the possibility of duplication, and I've seen it on BSD, Tru64, Solaris, and Linux. The Solaris manpages for getpwnam and nsswitch.conf say that getpwent+nswwitch is inefficient and is discouraged, but they don't suggest any alternatives. http://docs.sun.com/?q=getpwentp=/doc/816-0213/6m6ne381va=view http://docs.sun.com/?q=getpwentp=/doc/816-0219/6m6njqbafa=view I guess the best solution would be to keep a list of uids that have already been processed by calendar, and ignore duplicates. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
portmap
i have problem with mountd, and i think that is portmap problem i upgrade from 4.5 to 5.0 and portmap haven't found new, and source for portmap haven't found too i need your help mountd write this logs: Jul 30 21:18:25 kripel mountd[16350]: can't register UDP RPCMNT_VER1 service Jul 30 21:18:25 kripel mountd[16350]: can't register UDP RPCMNT_VER3 service Jul 30 21:18:25 kripel mountd[16350]: can't register TCP RPCMNT_VER1 service Jul 30 21:18:25 kripel mountd[16350]: can't register TCP RPCMNT_VER3 service Jul 30 21:18:25 kripel mountd[16350]: can't register UDP6 RPCMNT_VER1 service Jul 30 21:18:25 kripel mountd[16350]: can't register UDP6 RPCMNT_VER3 service Jul 30 21:18:25 kripel mountd[16350]: can't register TCP6 RPCMNT_VER1 service Jul 30 21:18:25 kripel mountd[16350]: can't register TCP6 RPCMNT_VER3 service Jul 30 21:18:25 kripel mountd[16350]: could not create any services -- -- bye R.R.K.K. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: portmap
Hi! On Tue, Jul 30, 2002 at 09:52:26PM +0200, Radko Keves wrote: i upgrade from 4.5 to 5.0 and portmap haven't found new, and source for portmap haven't found too RPC-to-TCP/UDP port mapper now called 'rpcbind'. i need your help You really should run 'mergemaster' after such an upgrade. Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make buildworld crashing
On Tue, 2002-07-30 at 00:28, Munish Chopra wrote: cd /usr/src/share/mk make install I believe (hope?) that fixes it. Barfed in the same place. 8-( here's the output: su-2.05a# cd /usr/src/share/mk make install date '+%Y%m%d' /var/db/port.mkversion install -o root -g wheel -m 444 bsd.README bsd.cpu.mk bsd.dep.mk bsd.doc.mk bsd.files.mk bsd.incs.mk bsd.info.mk bsd.init.mk bsd.kern.mk bsd.kmod.mk bsd.lib.mk bsd.libnames.mk bsd.links.mk bsd.man.mk bsd.nls.mk bsd.obj.mk bsd.own.mk bsd.port.mk bsd.port.post.mk bsd.port.pre.mk bsd.port.subdir.mk bsd.prog.mk bsd.subdir.mk bsd.sys.mk sys.mk /usr/share/mk then I ran make buildworld and it crashed as before. maybe I'll update my source later today and try it again. --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 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/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === sbin/fsck_ffs cc1: warnings being treated as errors /local0/scratch/des/src/sys/ufs/ffs/ffs_subr.c: In function `ffs_isblock': /local0/scratch/des/src/sys/ufs/ffs/ffs_subr.c:237: warning: implicit declaration of function `panic' *** Error code 1 Stop in /local0/scratch/des/src/sbin/fsck_ffs. *** Error code 1 Stop in /local0/scratch/des/src/sbin. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
