Re: where to get -current pkgs?
On Fri, Oct 18, 2002 at 12:28:18AM +0200, Martin Blapp wrote: > > Hi, > > and OpenOffice packages for CURRENT will be available from > http://projects.imp.ch/openoffice as you already know ;-) > > I really really hope that portmgr will be able > to make at least a english openoffice package of > FreeBSD 5.0 RELEASE. I tried but it hit the maximum build length timeout on bento: I'll have to try harder. Kris msg45342/pgp0.pgp Description: PGP signature
Re: failure to make ORBit2 in CURRENT
On Thu, 2002-10-17 at 20:42, Daniel Flickinger wrote:
> Sent: Thu, 17 Oct 2002 05:25:36 +0200 Clement Laforet wrote:
>
> + On Thu, 17 Oct 2002 02:39:51 + (GMT)
> + Daniel Flickinger <[EMAIL PROTECTED]> wrote:
> +
> + > running CURRENT from slice at 1200 GMT 16 Oct 2002:
> + >
> + > system is Tyan 2642 SMP 1.2G w/SCSI-160s
> + >
> + > Configuring for Bison for ORBit2
> + >
> + > checking how to run the C preprocessor... /lib/cpp
> + > configure: error: C preprocessor "/lib/cpp" fails sanity check
> + > ===> Script "configure" failed unexpectedly.
> + > Please report the problem to [EMAIL PROTECTED] [maintainer] and attach
> + > the "/work/usr/ports/devel/bison/work/bison-1.35/config.log" including
> + > the output of the failure of your make command. Also, it might be a good
> + > idea to provide an overview of all packages installed on your system
> + > (e.g. an `ls /var/db/pkg`).
> +
> + Hu, It's working fine for me.
> + I'm not sure, but it seems to be a gcc 3.2 related problem (upgrading problem).
> + When did you update your sources ?
> + Did you remove all c++ stuff before installing world ?
>
> System is CURRENT as of 1200 GMT 17 Oct --12 hours ago.
>
> Everytime I do an installworld I use a shell command which
> makes sure I have a 100% clean set of installs and libs --no
> left over trash. Consistency may be the hobgobblin of little
> minds, but it sure beats fat-finger errors.
>
> Maybe it's too new? [g] --gcc has had two updates in the
> last two weeks.
>
> As to c++, if it's out of date, it's gone. I personally don't use
> c++ --it's supposedly reusable code for disposable programmers.
cpp is the C pre-processor. It should live in /usr/bin. I have never
seen this error before, and my -CURRENT machine (updated as of
yesterday) is building GNOME 2 ports just fine. I did a _full_ rebuild
of all ports after __sF, and everything but gnomelibs rebuilt without a
hitch. I subsequently committed a patch to fix it.
Honestly, I don't know where that /lib/cpp is coming from. The only way
I can reproduce your problem is to do:
# cd /usr/ports/devel/ORBit
# make CPP=/lib/cpp configure
So I'm wondering if you have CPP defined somewhere that is screwing with
make?
Joe
>
> #!/bin/bash
> #
> # 'installworld' shell command
> #
>
> TFLG="-j 4 -k -s"
> TDEF="NO_WERROR=YES TARGET_ARCH=i386 __MAKE_CONF=/dev/null"
> TOUT="NOGAMES=YES NO_FORTRAN=YES NO_SENDMAIL=YES NO_MAILWRAPPER=YES NOUUCP=YES"
>
> cleanup() {
> rm -rf ${DESTDIR}/usr/include.old >/dev/null 2>&1
> mv -f ${DESTDIR}/usr/include ${DESTDIR}/usr/include.old
> chflags -R noschg ${DESTDIR}/usr/lib
> if [ ! -d ${DESTDIR}/usr/lib/old ]; then
> mkdir ${DESTDIR}/usr/lib/old
> fi
> if [ ! -d ${DESTDIR}/usr/lib/compat ]; then
> mkdir ${DESTDIR}/usr/lib/compat
> fi
> mv -f ${DESTDIR}/usr/lib/lib*.so.* ${DESTDIR}/usr/lib/compat
> mv -f ${DESTDIR}/usr/lib/*.o ${DESTDIR}/usr/lib/old
> mv -f ${DESTDIR}/usr/lib/lib*.a ${DESTDIR}/usr/lib/old
> mv -f ${DESTDIR}/usr/lib/lib*.so ${DESTDIR}/usr/lib/old
> }
>
> # waste sendmail
>
> stomp() {
> cd ${DESTDIR}/usr/libexec
> rm -f sendmail/*
> cd ${DESTDIR}/usr/bin
> rm -f mailq newaliases
> ln -s ${DESTDIR}/usr/sbin/sendmail mailq
> ln -s ${DESTDIR}/usr/sbin/sendmail newaliases
> cd ${DESTDIR}/usr/sbin
> rm -f sendmail mailwrapper
> ln -s postmail sendmail
> }
>
> process() {
> cleanup >${CDATE}.installworld.${RDATE} 2>&1
> make $TFLG $TDEF $TOUT installworld >>${CDATE}.installworld.${RDATE} 2>&1
> rm -rf ${DESTDIR}/usr/include.old >/dev/null 2>&1
> stomp >>${CDATE}.installworld.${RDATE} 2>&1
> }
>
> read -p "Enter current date code as \"ymdd.hhmm\": " CDATE
> if [ -z "${CDATE}" ] ; then
> printf "! date required: enter date in format \"ymdd.hhmm\"\n"
> exit 3
> fi
>
> read -p "Enter release date code as \"ymdd.hhmm\": " RDATE
> if [ -z "${RDATE}" ] ; then
> printf "! date required: enter date in format \"ymdd.hhmm\"\n"
> exit 4
> fi
>
> read -p "Enter non-standard destination directory or RET: " DTARGET
> if [ -s "${DTARGET}" ] ; then
> export DESTDIR=${DTARGET}
> fi
>
> process &
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
--
PGP Key : http://www.marcuscom.com/pgp.asc
signature.asc
Description: This is a digitally signed message part
any recent changes related to MD_ROOT ?
Hi, on a freshly cvsupped source tree, i notice that picobsd images with a preloaded MD_ROOT cannot boot anymore: the kernel goes up to this stage: Mounting root from ufs:/dev/md0c setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> at which point you can proceed by specifying "ufs:md0" as the root path, and everything works fine. It certainly used to work (though i do not remember if the root path came out as md0c or just md0) up to a couple of months ago, roughly. Does this ring any bell on what might have changed more or less recently that affects this ? Who builds up the '/dev/md0c' name for the root filesystem ? thanks luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2988 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Remote GDB Trap 12 Fatal On Target
I am trying to get a remote gdb kernel debugging session and on the Target macine I get the following error: "Fatal trap 12: page fault while in kernel mode" .. fault vurtual address = 0x26 fault code= supervisor read, page not present" is anyone else getting this as well ?? There is a thread in -Current last June sometime, with the "fix" being to add the following line to the config file: Turns out the workaround is to use DISABLE_PG_G. Two things made me try this. One: In his commit of pmap.c and locore.s on 7/12 7:56 Peter had this to say: +-- |- Try and fix some very bogus PG_G and PG_PS interactions that were bad | enough to cause vm86 bios calls to break. vm86 depended on our existing ... |New option: DISABLE_PG_G - In case I missed something. -\ This did not fix the problem thought, any other ideas appreaciated!! Thanks: -- Glenn Gombert [EMAIL PROTECTED] "Never trust any operating system you don't have the source code for" -- http://fastmail.fm - The holy hand grenade of email services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: mtx_lock() of spin mutex
Lars Eggert wrote: Note that the panic message makes a lot more sense this time around: Argh; which I maybe should have included in the fist place. Typescript attached. Sorry, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute typescript Description: application/java-vm smime.p7s Description: S/MIME Cryptographic Signature
Re: panic: mtx_lock() of spin mutex
Lars Eggert wrote:
I'm tracking down a lock order reversal for hsu@, and just came across
this other locking panic twice in the last few hours.
Found a way to reproduce this at will (shell tab-completion on a
filename on an NFS-mounted file system), and managed to get a core dump.
Note that the panic message makes a lot more sense this time around:
panic: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0200
fault virtual address = 0x2887ff38
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0259253
stack pointer = 0x10:0xeb505c94
frame pointer = 0x10:0xeb505cc0
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 = 2720 (tcsh)
panic: from debugger
cpuid = 1; lapic.id = 0200
Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 1; lapic.id = 0200
instruction pointer = 0x8:0xc03d44ca
stack pointer = 0x10:0xeb505a0c
frame pointer = 0x10:0xeb505a18
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, IOPL = 0
current process = 2720 (tcsh)
panic: from debugger
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Uptime: 8m43s
pfs_vncache_unload(): 3 entries remaining
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
896 912 928 944 960 976 992 1008
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:224
224 dumpsys(&dumper);
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:224
#1 0xc027768e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:355
#2 0xc0277c87 in panic (fmt=0xc0413084 "from debugger")
at /usr/src/sys/kern/kern_shutdown.c:508
#3 0xc01507a2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc01505dc in db_command (last_cmdp=0xc047b5e0, cmd_table=0x0,
aux_cmd_tablep=0xc0472bfc, aux_cmd_tablep_end=0xc0472c00)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc015081a in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc01534c5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc03d4187 in kdb_trap (type=12, code=0, regs=0xeb505c54)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc03ec41c in trap_fatal (frame=0xeb505c54, eva=0)
at /usr/src/sys/i386/i386/trap.c:841
#9 0xc03ec16a in trap_pfault (frame=0xeb505c54, usermode=0, eva=680001336)
at /usr/src/sys/i386/i386/trap.c:760
#10 0xc03ebcce in trap (frame=
{tf_fs = -1068498920, tf_es = 16, tf_ds = -953876464, tf_edi =
-953858560, tf_esi = -965994304, tf_ebp = -347054912, tf_isp =
-347054976, tf_ebx = 680001280, tf_edx = -953876480, tf_ecx = 4, tf_eax
= -1, tf_trapno = 12, tf_err = 0, tf_eip = -1071279533, tf_cs = 8,
tf_eflags = 66178, tf_esp = -953858508, tf_ss = 0}) at
/usr/src/sys/i386/i386/trap.c:446
#11 0xc03d5938 in calltrap () at {standard input}:99
#12 0xc02584c3 in dup2 (td=0x0, uap=0x0)
at /usr/src/sys/kern/kern_descrip.c:174
#13 0xc03ec9f6 in syscall (frame=
{tf_fs = 47, tf_es = -65489, tf_ds = -1078001617, tf_edi = 4,
tf_esi = 135637504, tf_ebp = -1078036088, tf_isp = -347054732, tf_ebx =
-1, tf_edx = -1078037360, tf_ecx = 136105984, tf_eax = 90, tf_trapno =
12, tf_err = 2, tf_eip = 134842063, tf_cs = 31, tf_eflags = 646, tf_esp
= -1078037316, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1071
#14 0xc03d598d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
--
Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
panic: mtx_lock() of spin mutex
Hi,
I'm tracking down a lock order reversal for hsu@, and just came across
this other locking panic twice in the last few hours. I run with WITNESS
and WITNESS_SKIPSPIN, and have never seen this happen unless I set
debug.witness_ddb=1. The name of the mutex looks definitly fishy.
Let me knowif I can provide more information (tried to get a core dump,
but machine hung hard after typing "panic".)
panic: mtx_lock() of spin mutex $,J@4(J@^@^GN@^D @
/usr/src/sys/kern/kern_descrip.c:488
cpuid = 1; lapic.id = 0200
Debugger("panic")
Stopped at Debugger+0x5a: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c043d4b2,200,c043c6ef,eb519c70,1) at Debugger+0x5a
panic(c043c6ef,c04a2a74,c043a64f,1e8,eb519cb4) at panic+0x12f
_mtx_lock_flags(c04a2c34,0,c043a64f,1e8,c7238c00) at _mtx_lock_flags+0xa7
do_dup(c69fb9c0,1,,4,c69fba54) at do_dup+0xe6
dup2(c69fb9c0,eb519d10,c046443d,42d,c69fa3e8) at dup2+0x33
syscall(2f,2f,2f,4,815aa00) at syscall+0x406
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (90, FreeBSD ELF32, dup2), eip = 0x80986cf, esp =
0xbfbe74bc, ebp = 0xbfbe7988 ---
db> panic
panic: from debugger
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Lars
--
Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
alpha 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/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Thu Oct 17 15:10:50 PDT 2002 -- >>> Kernel build for GENERIC completed on Thu Oct 17 15:42:46 PDT 2002 -- >>> Kernel build for LINT started on Thu Oct 17 15:42:47 PDT 2002 -- ===> vinum "Makefile", line 4244: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/ahd_pci.c: In function `ahd_pci_map_registers': /h/des/src/sys/dev/aic7xxx/ahd_pci.c:173: warning: implicit declaration of function `bus_space_subregion' *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: where to get -current pkgs?
Hi, and OpenOffice packages for CURRENT will be available from http://projects.imp.ch/openoffice as you already know ;-) I really really hope that portmgr will be able to make at least a english openoffice package of FreeBSD 5.0 RELEASE. Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] Fix PT_IO ptrace(2) request
* De: Mark Kettenis <[EMAIL PROTECTED]> [ Data: 2002-10-17 ] [ Subjecte: Re: [PATCH] Fix PT_IO ptrace(2) request ] >Date: Wed, 16 Oct 2002 12:49:14 -0400 (EDT) >From: John Baldwin <[EMAIL PROTECTED]> > >On 14-Oct-2002 Mark Kettenis wrote: >> The new PT_IO ptrace(2) request doesn't work, since it doesn't release >> a lock. Since PT_IO is similar to PT_READ_D/PT_WRITE_D, I copied the >> PROC_UNLOCK from there and inserted in the same location. Patch, >> against version 1.103 of sys_process.c, attached. > >Good catch, I've committed it. Thanks! > > Thanks, I'll exploit the PT_IO stuff in the FSF GDB sources in the > near future. This probably means we can now use Poor Man's Debugger from OpenBSD, out of the box (cvs repo) with only minor mods. -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: where to get -current pkgs?
On Thu, Oct 17, 2002 at 10:45:16AM -0700, Julian Elischer wrote: > > What is the most 'up-to-date' place to find precompiled pkgs > for -current? http://bento.freebsd.org/errorlogs/packages-5-full/ http://bento.freebsd.org/errorlogs/packages-5-latest/ The latter is from the most recent build which may be still in progress, so it's "more up-to-date", but may not be complete. They are also distributed on FTP mirrors, but package sets are only uploaded to ftp-master at most every week or two, and not all FTP mirrors may carry the -current packages. Kris msg45332/pgp0.pgp Description: PGP signature
Re: [PATCH] Fix PT_IO ptrace(2) request
Date: Wed, 16 Oct 2002 12:49:14 -0400 (EDT) From: John Baldwin <[EMAIL PROTECTED]> On 14-Oct-2002 Mark Kettenis wrote: > The new PT_IO ptrace(2) request doesn't work, since it doesn't release > a lock. Since PT_IO is similar to PT_READ_D/PT_WRITE_D, I copied the > PROC_UNLOCK from there and inserted in the same location. Patch, > against version 1.103 of sys_process.c, attached. Good catch, I've committed it. Thanks! Thanks, I'll exploit the PT_IO stuff in the FSF GDB sources in the near future. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Page fault in swapout_procs
I just got the following panic on one of the gohan machines, running a
somewhat recent -current:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xa0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc035d0ab
stack pointer = 0x10:0xcd25ccc0
frame pointer = 0x10:0xcd25cce0
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 = 3 (vmdaemon)
kernel: type 12 trap, code=0
Stopped at swapout_procs+0x6b: incl0xa0(%esi)
db> Context switches not allowed in the debugger.
db> trace
swapout_procs(1,0,68,c0411018,0) at swapout_procs+0x6b
vm_daemon(0,cd25cd48,c03f1300,34b,0) at vm_daemon+0x6e
fork_exit(c036b560,0,cd25cd48) at fork_exit+0xaf
fork_trampoline() at fork_trampoline+0x17
The kernel was compiled on September 8:
FreeBSD 5.0-CURRENT #2: Sun Sep 8 01:53:39 PDT 2002
gdb on the core seems to have something slightly different to say about the backtrace:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xa0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc035d0ab
stack pointer = 0x10:0xcd25ccc0
frame pointer = 0x10:0xcd25cce0
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 = 3 (vmdaemon)
panic: from debugger
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc03999a4
stack pointer = 0x10:0xcd25ca48
frame pointer = 0x10:0xcd25ca54
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 3 (vmdaemon)
panic: from debugger
Uptime: 7h28m29s
Dumping 254 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at /local0/scratch/sys/kern/kern_shutdown.c:213
213 /local0/scratch/sys/kern/kern_shutdown.c: No such file or directory.
in /local0/scratch/sys/kern/kern_shutdown.c
(kgdb) bt
#0 doadump () at /local0/scratch/sys/kern/kern_shutdown.c:213
#1 0xc02422b5 in boot (howto=260) at /local0/scratch/sys/kern/kern_shutdown.c:345
#2 0xc02424e8 in panic () at /local0/scratch/sys/kern/kern_shutdown.c:493
#3 0xc0161e22 in db_panic () at /local0/scratch/sys/ddb/db_command.c:449
#4 0xc0161da2 in db_command (last_cmdp=0xc0427aa0, cmd_table=0xc03ccbc8,
aux_cmd_tablep=0xc0ee79c0,
aux_cmd_tablep_end=0x104) at /local0/scratch/sys/ddb/db_command.c:345
#5 0xc0161eb6 in db_command_loop () at /local0/scratch/sys/ddb/db_command.c:471
#6 0xc0164a8a in db_trap (type=12, code=0) at /local0/scratch/sys/ddb/db_trap.c:72
#7 0xc0399702 in kdb_trap (type=12, code=0, regs=0xcd25cc80) at
/local0/scratch/sys/i386/i386/db_interface.c:160
#8 0xc03a9a43 in trap_fatal (frame=0xcd25cc80, eva=0) at
/local0/scratch/sys/i386/i386/trap.c:841
#9 0xc03a9752 in trap_pfault (frame=0xcd25cc80, usermode=0, eva=160) at
/local0/scratch/sys/i386/i386/trap.c:760
#10 0xc03a927d in trap (frame=
{tf_fs = -853213160, tf_es = -1069350896, tf_ds = 16, tf_edi = 10, tf_esi =
0, tf_ebp = -853160736, tf_isp = -853160788, tf_ebx = -1025123020, tf_edx = 4, tf_ecx
= 1, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = -1070214997, tf_cs = 8,
tf_eflags = 66178, tf_esp = -1069298464, tf_ss = -1069486848}) at
/local0/scratch/sys/i386/i386/trap.c:446
#11 0xc039ae68 in calltrap () at {standard input}:98
#12 0xc036b5ce in vm_daemon () at /local0/scratch/sys/vm/vm_pageout.c:1476
#13 0xc022e72f in fork_exit (callout=0xc036b560 , arg=0x0, frame=0x0) at
/local0/scratch/sys/kern/kern_fork.c:851
Kris
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: RE: Dedicating an interrupt to a PC-Card slot
On Thu, 17 Oct 2002, Matthew Dillon wrote:
> :Doesn't sound like that fast an interrupt. The 16550 has a 16-byte
> :send and receive fifo. Set the rx interrupt @ 14, and the tx @ 2.
> :230400/8 = 28800 chars /s
> :28800 / 14 = 2057 interrupts / s. This should be well within reach
> :of a pentium-class machine.
>
> Not a good idea. If you set the rx fifo at 14 you will get fewer
> interrupts, sure, but you will also have less of a safety margin to
> process them before the rx fifo potentially overflows and you lose
> characters. This is why I changed the default fifo level from HIGH (14)
> to MEDH (8) a while back.
I still disagree with this change in -current.
> In anycase, anything less then 10,000 interrupts a second ought to be
> fine. The real problem is still going to be other things in the system
> causing enough interrupt latency to result in lost characters. The most
> common culprit is X windows doing big bitblits to the video card /
> video memory, and I think having a non-DMA IDE interface can also cause
> problems.
The real problems are probably fatal in -current, since the worst-case
interrupt latency is many milliseconds (e.g., for mii_tick()) and this
affects most non-fast interrupt handlers including siointr() in non-fast
mode because they are blocked by Giant. mii_tick() causes a similar
amount of latency in RELENG_4, but this only affects timeout routines
because interrupt priorities actually work in RELENG_4, at least in the
non-SMP case.
Non-DMA for IDE causes no problems for fast interrupt handlers, but
DMA does. Non-DMA for IDE causes much the same Giant locking problems
in -current as mii_tick() (but smaller). In RELENG_4, it causes latency
problems for most interrupt handlers except tty ones.
Try the following change to prevent siointr() being blocked by Giant.
This is untested, but should work, since siointr() works as a fast
interrupt handler and fast interrupt handlers aren't blocked by Giant.
%%%
Index: sio.c
===
RCS file: /home/ncvs/src/sys/dev/sio/sio.c,v
retrieving revision 1.382
diff -u -2 -r1.382 sio.c
--- sio.c 11 Oct 2002 20:22:20 - 1.382
+++ sio.c 17 Oct 2002 20:18:53 -
@@ -1117,5 +1146,6 @@
if (ret) {
ret = BUS_SETUP_INTR(device_get_parent(dev), dev,
-com->irqres, INTR_TYPE_TTY,
+com->irqres,
+INTR_TYPE_TTY | INTR_MPSAFE,
siointr, com, &com->cookie);
if (ret == 0)
%%%
Unfortunately, for this to work well, you need non-shared-interrupts
or only very lightweight interrupts that are not blocked by Giant
sharing the irq. This means no (active) sharing in practice, so it
may be as hard to configure as no sharing at all.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: I often have orphaned FDs in threaded programs...
On Thu, 17 Oct 2002, Juli Mallett wrote: > I have a program which shares a lot of (orphaned) FDs between threads, > and requesting a dump (SIGINFO) results in a core, because the FD owner > si NULL. Here's a diff from my local tree, for review: Actually, fd locking is not enabled anymore so that's why the table has null entries. I would recommend just deleting the printing of the owner altogether. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Dedicating an interrupt to a PC-Card slot
:Doesn't sound like that fast an interrupt. The 16550 has a 16-byte :send and receive fifo. Set the rx interrupt @ 14, and the tx @ 2. :230400/8 = 28800 chars /s :28800 / 14 = 2057 interrupts / s. This should be well within reach :of a pentium-class machine. Not a good idea. If you set the rx fifo at 14 you will get fewer interrupts, sure, but you will also have less of a safety margin to process them before the rx fifo potentially overflows and you lose characters. This is why I changed the default fifo level from HIGH (14) to MEDH (8) a while back. In anycase, anything less then 10,000 interrupts a second ought to be fine. The real problem is still going to be other things in the system causing enough interrupt latency to result in lost characters. The most common culprit is X windows doing big bitblits to the video card / video memory, and I think having a non-DMA IDE interface can also cause problems. At 230400 baud and 10 bits per character (one start, one stop bit), a fifo level of 14 gives you 2 character times of safety, or approximately 86uS. At a fifo level of 8 you have 8 character times of safety or approximately 347uS. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: where to get -current pkgs?
On Thu, Oct 17, 2002 at 01:01:59PM -0500, David W. Chapman Jr. wrote: > bento should have them but I dont' know how up to date it is. Bento is returning to 5-CURRENT builds in lieu of DP2 and hopefully 5.0-RELEASE, now that 4.7-RELEASE is out. I believe we will do 4-STABLE builds less frequently than 5-CURRENT for some time. In any case, the latest packages available publically are posted on the FTP mirrors, but also on bento (check the webpages). regards -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: where to get -current pkgs?
bento should have them but I dont' know how up to date it is. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
where to get -current pkgs?
What is the most 'up-to-date' place to find precompiled pkgs for -current? Specifically Mozilla but also others.. (I've looked around a bit but most -current places don't have packages...) Probably i should know this.. but I don't... Julian (rebuilding his machine) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Dedicating an interrupt to a PC-Card slot
> From: Kenneth P. Stox [mailto:stox@;imagescape.com] > > Well, I decided to have some fun and see if I could get a > Novatel Merlin > C-201 wireless modem running under FreeBSD. It seems I have run into a > bit of a roadblock. It appears that the C-201 will only speak, through > it's 16550 UART, at a speed of 230400. As such it need to have fast > interrupt support, which only seems possible with a dedicated > interrupt. Doesn't sound like that fast an interrupt. The 16550 has a 16-byte send and receive fifo. Set the rx interrupt @ 14, and the tx @ 2. 230400/8 = 28800 chars /s 28800 / 14 = 2057 interrupts / s. This should be well within reach of a pentium-class machine. 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.. -- >>> Kernel build for GENERIC started on Thu Oct 17 09:39:00 PDT 2002 -- >>> Kernel build for GENERIC completed on Thu Oct 17 10:23:13 PDT 2002 -- >>> Kernel build for LINT started on Thu Oct 17 10:23:14 PDT 2002 -- ===> xe "Makefile", line 5066: warning: duplicate script for target "geom_bsd.o" ignored "Makefile", line 5069: warning: duplicate script for target "geom_mbr.o" ignored "Makefile", line 5066: warning: duplicate script for target "geom_bsd.o" ignored "Makefile", line 5069: warning: duplicate script for target "geom_mbr.o" ignored ./aicasm: 877 instructions used ./aicasm: 686 instructions used "Makefile", line 5066: warning: duplicate script for target "geom_bsd.o" ignored "Makefile", line 5069: warning: duplicate script for target "geom_mbr.o" ignored /local0/scratch/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver is broken and is not compiled with LINT" In file included from /local0/scratch/des/src/sys/kern/kern_shutdown.c:71: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG In file included from /local0/scratch/des/src/sys/kern/subr_smp.c:48: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG /local0/scratch/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver is broken and is not compiled with LINT" mkdep: compile failed In file included from /local0/scratch/des/src/sys/i386/i386/autoconf.c:79: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG In file included from /local0/scratch/des/src/sys/i386/i386/critical.c:22: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG In file included from /local0/scratch/des/src/sys/i386/i386/machdep.c:112: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG In file included from /local0/scratch/des/src/sys/i386/i386/mp_machdep.c:71: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG In file included from /local0/scratch/des/src/sys/i386/i386/mpapic.c:37: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG In file included from /local0/scratch/des/src/sys/i386/i386/nexus.c:62: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG In file included from /local0/scratch/des/src/sys/i386/i386/pmap.c:107: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG In file included from /local0/scratch/des/src/sys/i386/i386/trap.c:86: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG In file included from /local0/scratch/des/src/sys/i386/isa/clock.c:78: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG In file included from /local0/scratch/des/src/sys/i386/isa/intr_machdep.c:64: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG /local0/scratch/des/src/sys/i386/isa/scd.c:3:2: warning: #warning "The scd driver is currently incompatible with GEOM" /local0/scratch/des/src/sys/i386/isa/stallion.c:57:2: warning: #warning "The stallion pci attachment is broken and not compiled" In file included from /local0/scratch/des/src/sys/i386/pci/pci_cfgreg.c:49: machine/smp.h:25:2: #error SMP not supported with CPU_DISABLE_CMPXCHG mkdep: compile failed *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/LINT. *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/LINT. *** 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
three lock order reversals
Hi, a general question first: Is there anything that would tell me which witness/lock warnings have been reported already? Or who to send witness/lock warnings to directly, without going through the list? Here's a bunch of warnigns I've been seeing: lock order reversal 1st 0xc9692000 vnode interlock (vnode interlock) @ /usr/src/sys/nfsclient/nfs_vnops.c:2629 2nd 0xc052ffc0 vm page queue mutex (vm page queue mutex) @ /usr/src/sys/vm/vm_kern.c:424 lock order reversal 1st 0xc0585ec0 spechash (spechash) @ /usr/src/sys/kern/vfs_subr.c:2748 2nd 0xc79c3de0 vnode interlock (vnode interlock) @ /usr/src/sys/kern/vfs_subr.c:2751 lock order reversal 1st 0xc6297bd4 xl0 (network driver) @ /usr/src/sys/pci/if_xl.c:1264 2nd 0xc0502140 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:317 (I also see the "usual" pcm lock warnigns, but sound under -current seems to be in a sorry state to begin with... ;-) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: wierd cpu usage numbers
I believe I have a related issue, not exactly the same, but similar... When I run vmstat, I notice that processes are always piling up and waiting for CPU time. This is odd, because my CPU is usually running about 70-80% free most times. IRQs look fine, and I have debugging off in the kernel. This has been happening on -CURRENT on my Inspiron 4000 laptop since about July-August. I usually update once a month or so. Everything else in vmstat looks fine... __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wierd cpu usage numbers
On Thu, 17 Oct 2002, Kenneth Culver wrote: > > This is a result of what's explained there. > > Nope, I have all that stuff turned off, and ide write caching turned on. > There's no way that's the reason. Ide write caching isn't even turned off by default as claimed in UPDATING. The entry 28-Feb-02 entry in UPDATING about rotted when the default was changed on 05-Mar-02. dma being turned off would expain large disk overheads but not large sys times, since they would be reported only as interrupt times. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wierd cpu usage numbers
No, not really, I checked top -S, and systat -vm, neither has interrupts going high, but even if interrupts were going really high, I would suspect that the intr % would increase not the system % Ken On Thu, 17 Oct 2002, Michael Lucas wrote: > On Thu, Oct 17, 2002 at 11:18:25AM -0400, Kenneth Culver wrote: > > > This is a result of what's explained there. > > > > Nope, I have all that stuff turned off, and ide write caching turned on. > > There's no way that's the reason. > > OK, then, it's something else. :-) > > Does, say, top -S show any interrupts going awry? > > ==ml > > -- > Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] > http://www.oreillynet.com/pub/q/Big_Scary_Daemons > >Absolute BSD: http://www.AbsoluteBSD.com/ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wierd cpu usage numbers
On Thu, Oct 17, 2002 at 11:18:25AM -0400, Kenneth Culver wrote: > > This is a result of what's explained there. > > Nope, I have all that stuff turned off, and ide write caching turned on. > There's no way that's the reason. OK, then, it's something else. :-) Does, say, top -S show any interrupts going awry? ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.AbsoluteBSD.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wierd cpu usage numbers
> This is a result of what's explained there. Nope, I have all that stuff turned off, and ide write caching turned on. There's no way that's the reason. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wierd cpu usage numbers
On Thu, Oct 17, 2002 at 11:03:04AM -0400, Kenneth Culver wrote: > Hi, > I was just compiling kde3 on my home pc, and I noticed some > interesting behavior. It seems that whenever there's ANY real heavy disk > activity, the "system" cpu usage % number (in top and in systat -vm) > skyrockets from 0.8% to around 50-70%. I was wondering which of the recent > changes could have caused this... also in systat, the increase of the > system % number seems to correspond with zfod, cow, and prcfr numbers > jumping. Any ideas? Please see the big friendly message in all capital letters in /usr/src/UPDATING: NOTE TO PEOPLE WHO THINK THAT 5.0-CURRENT IS SLOW: This is a result of what's explained there. ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.AbsoluteBSD.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Dedicating an interrupt to a PC-Card slot
Well, I decided to have some fun and see if I could get a Novatel Merlin C-201 wireless modem running under FreeBSD. It seems I have run into a bit of a roadblock. It appears that the C-201 will only speak, through it's 16550 UART, at a speed of 230400. As such it need to have fast interrupt support, which only seems possible with a dedicated interrupt. ACPI and NEWCARD assigns the same interrupt to both of the Cardbus bridges and to other PCI devices. Any suggestions how I might accomplish the assignment of a dedicated interrupt? BTW, this device does work under Linux, Windows 2000, and Windows 98SE. Thanks in advance, -Ken Stox [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wierd cpu usage numbers
Hi, I was just compiling kde3 on my home pc, and I noticed some interesting behavior. It seems that whenever there's ANY real heavy disk activity, the "system" cpu usage % number (in top and in systat -vm) skyrockets from 0.8% to around 50-70%. I was wondering which of the recent changes could have caused this... also in systat, the increase of the system % number seems to correspond with zfod, cow, and prcfr numbers jumping. Any ideas? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Ugly PATCH] Again: panic kmem_malloc(): dmesg and kernel config
Some info I did not include in the previous messages: dmesg output and kernel config. [terminus.stuyts.nl boot/kernel]26: dmesg 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: Sun Oct 6 01:50:54 CEST 2002 [EMAIL PROTECTED]:/var/obj/usr/src/sys/TERMINUS Preloaded elf kernel "/boot/kernel/kernel" at 0xc04dc000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 233864671 Hz CPU: Pentium II/Pentium II Xeon/Celeron (233.86-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping = 4 Features=0x80f9ff real memory = 67108864 (65536K bytes) avail memory = 59920384 (58516K bytes) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface Using $PIR table, 6 entries at 0xc00fdc00 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 atapci0: Busmastering DMA not supported ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0x6400-0x641f irq 11 at device 7.2 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 pci0: at device 7.3 (no driver attached) sym0: <875> port 0x6800-0x68ff mem 0xe800-0xe8000fff,0xe8001000-0xe80010ff irq 12 at device 11.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. xl0: <3Com 3c905-TX Fast Etherlink XL> port 0x6c00-0x6c3f irq 9 at device 13.0 on pci0 /usr/src/sys/vm/uma_core.c:1307: could sleep with "xl0" locked from /usr/src/sys/pci/if_xl.c:1264 /usr/src/sys/vm/uma_core.c:1307: could sleep with "xl0" locked from /usr/src/sys/pci/if_xl.c:1264 lock order reversal 1st 0xc0ba1bd4 xl0 (network driver) @ /usr/src/sys/pci/if_xl.c:1264 2nd 0xc03d2b00 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:318 /usr/src/sys/vm/uma_core.c:1307: could sleep with "xl0" locked from /usr/src/sys/pci/if_xl.c:1264 /usr/src/sys/vm/uma_core.c:1307: could sleep with "xl0" locked from /usr/src/sys/pci/if_xl.c:1264 /usr/src/sys/vm/uma_core.c:1307: could sleep with "xl0" locked from /usr/src/sys/pci/if_xl.c:1264 xl0: Ethernet address: 00:60:08:a5:d4:ff miibus0: on xl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto /usr/src/sys/vm/uma_core.c:1307: could sleep with "xl0" locked from /usr/src/sys/pci/if_xl.c:647 pci0: at device 15.0 (no driver attached) orm0: at iomem 0xc8000-0xcbfff,0xc-0xc7fff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: PRINTER ESCPL2,BDC lpt0: on ppbus0 lpt0: Interrupt-driven port sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to deny, logging unlimited Waiting 5 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. Mounting root from ufs:/dev/da0s1a da2 at sym0 bus 0 target 3 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da2: 3067MB (6281856 512 byte sectors: 255H 63S/T 391C) da1 at sym0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da1: 3090MB (6328861 512 byte sectors: 255H 63S/T 393C) da0 at sym0 bus 0 target 1 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) WARNING: / was not properly dismounted cd0 at sym0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted /var: mount pending error: blocks 4 files 1 /var: superblock summary recomputed acquiring duplicate lock of same type: "inp" 1st inp @ /usr/s
I often have orphaned FDs in threaded programs...
I have a program which shares a lot of (orphaned) FDs between threads,
and requesting a dump (SIGINFO) results in a core, because the FD owner
si NULL. Here's a diff from my local tree, for review:
%%%
Index: uthread_info.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_info.c,v
retrieving revision 1.21
diff -d -u -r1.21 uthread_info.c
--- uthread_info.c 13 Oct 2002 11:23:31 - 1.21
+++ uthread_info.c 17 Oct 2002 10:38:49 -
@@ -252,10 +252,16 @@
pthread->data.fd.fname,
pthread->data.fd.branch);
__sys_write(fd, s, strlen(s));
- snprintf(s, sizeof(s), "owner %pr/%pw\n",
- _thread_fd_table[pthread->data.fd.fd]->r_owner,
- _thread_fd_table[pthread->data.fd.fd]->w_owner);
- __sys_write(fd, s, strlen(s));
+ /*
+* XXX _thread_fd_table[pthread->data.fd.fd] often comes
+* up as NULL for me, bandaid it. Is this right?
+*/
+ if (_thread_fd_table[pthread->data.fd.fd] != NULL) {
+ snprintf(s, sizeof(s), "owner %pr/%pw\n",
+ _thread_fd_table[pthread->data.fd.fd]->r_owner,
+ _thread_fd_table[pthread->data.fd.fd]->w_owner);
+ __sys_write(fd, s, strlen(s));
+ }
break;
case PS_SIGWAIT:
snprintf(s, sizeof(s), "sigmask (hi)");
%%%
I think it's right to just print no owner, or possibly a no owner message,
in these cases. Comments?
--
Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve
Will break world for fulltime employment. | finger [EMAIL PROTECTED]
http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Whiter Teeth & Wild Eye Contacts - Great for Costumes
White Teeth and Scary Eyes for Halloween: 1) Crest "Professional" Whitestrips 42% More Effective Than the Crest Whitestrips Sold in Stores! http://click.linksynergy.com/fs-bin/click?id=ggnPCLh*yX0&offerid=42344.1074&type=4&subid=0 2) The Ultimate Addition to Any Costume...Halloween Contact Lenses. Change your look with Wild, Crazy, or Just Plain Scary Looking Eyes!! http://linktrack.freezefinds.com/cgi-bin/savings/linktrack/go.cgi?LensMartFYRuss 3) Go for Weeks Without Shaving! Kalo Inhibits Unwanted Hair Growth Permanently. http://www.herbalsensations.com/cgi-bin/af/b.cgi/6835/kalo.html 4) SAVE MONEY ON YOUR DIABETIC SUPPLIES and receive a FREE GLUCOSE METER with our first order of supplies. Medicare and most private insurance plans pay for your diabetic supplies. Take advantage of FREE home delivery, FREE training, and NO PAPERWORK. Must have medical insurance or Medicare. http://psstt.com/1/c/78842/76160/214101/214101 Offer Manager UNSUBSCRIBE INSTRUCTIONS: If you no longer wish to receive this newsletter, you can unsubscribe by going here: http://tilw.net/unsub.php?client=freeyankee&msgid=16100200012 and entering your email address. TRCK:freeyankee;Fxuuhqw*Iuhhevg!Ruj;1;
Re: [Ugly PATCH] Again: panic kmem_malloc()
Hello Alfred, On Wed, Oct 16, 2002 at 02:26:19PM -0700, Alfred Perlstein wrote: > * Ben Stuyts <[EMAIL PROTECTED]> [021016 14:05] wrote: > > > > No need to wait for tomorrow. :-) Just 1.5 hours later, vmstat -m says: > > > > < sem167344 2622K 2622K 167344 16,1024,4096 > > --- > > > sem235512 3687K 3687K 235512 16,1024,4096 > > > > So it looks indeed like sem is the problem, > > what does > sysctl -a | grep ^p10 > say? p1003_1b.asynchronous_io: 0 p1003_1b.mapped_files: 1 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 1 p1003_1b.realtime_signals: 0 p1003_1b.semaphores: 0 p1003_1b.fsync: 0 p1003_1b.shared_memory_objects: 1 p1003_1b.synchronized_io: 0 p1003_1b.timers: 0 p1003_1b.aio_listio_max: 0 p1003_1b.aio_max: 0 p1003_1b.aio_prio_delta_max: 0 p1003_1b.delaytimer_max: 0 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 0 p1003_1b.sem_nsems_max: 0 p1003_1b.sem_value_max: 0 p1003_1b.sigqueue_max: 0 p1003_1b.timer_max: 0 > My guess is that you don't have the module in question loaded. > > If you do, then why? (it's marked experimental) The only modules loaded are: [terminus.stuyts.nl boot/kernel]21: kldstat Id Refs AddressSize Name 13 0xc010 3daa00 kernel 21 0xc12fd000 2000 green_saver.ko > And why aren't these bug reports a lot more detailed? (meaing why > aren't you actually giving an hypothesys as to why the code is > broken?) I think it was Jeff Roberson hinting at that. I am only reporting a problem and I hope I can help fixing it. I have however no knowledge of the kernel internals, so forgive me for being too vague and let me know what more information you need. > *grumble* Sorry... Kind regards, Ben To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha 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/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Thu Oct 17 03:08:09 PDT 2002 -- >>> Kernel build for GENERIC completed on Thu Oct 17 03:36:02 PDT 2002 -- >>> Kernel build for LINT started on Thu Oct 17 03:36:02 PDT 2002 -- ===> vinum "Makefile", line 4244: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/ahd_pci.c: In function `ahd_pci_map_registers': /h/des/src/sys/dev/aic7xxx/ahd_pci.c:173: warning: implicit declaration of function `bus_space_subregion' *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM question
On Wed, 16 Oct 2002, walt wrote: > Bruce Evans wrote: > > On Wed, 16 Oct 2002, walt wrote: > > > >>Bruce Evans wrote: > >> > >> > >>>Don't use extended partitions directly. It is easy to > >>>make a mess by clobbering the pointers to the logical drive > >>>within them. > > >>I need to ask for clarification on this point. What do you > >>mean by 'directly'? > > > Just write to them using anything that doesn't understand that they > > are containers for logical drives. E.g., newfs would leave their > > Once again you leave me puzzled. 'newfs /dev/ad2s8' is exactly how > I formatted the partition and everything is working perfectly. /dev/ad2s8 isn't an extended partition. It is a logical drive within an extended partition. In FreeBSD, only primary extended partitions are exposed as devices. You probably have a layout something like: ad2s4: extended partition ad2s5: logical drive within ad2s4 [ad2s4X]: nameless extended partition within ad2s4 ad2s6: logical drive within ad2s4X [ad2s4XX]: nameless extended partition within ad2s4X ad2s7: logical drive within ad2s4XX [ad2s4XXX]: nameless extended partition within ad2s4XX ad2s8: logical drive within ad2s4XXX > In addition I see this on -CURRENT (with GEOM): > #disklabel ad2s8 > disklabel: ioctl DIOCGDINFO: Operation not supported by device > > and this on -STABLE (different machine): > # disklabel ad0s7 > disklabel: ioctl DIOCGDINFO: Invalid argument > > so (for me) disklabel does not work on extended/logical partitions. This behaviour is the same as for all slices except the whole disk slice. There is no label on them until you write one. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My Old X server vs -current libs
On Wed, 16 Oct 2002, Kris Kennaway wrote: > On Thu, Oct 17, 2002 at 02:08:41AM +1000, Bruce Evans wrote: > > > This only broke wine for me. wine is not packaged, so I have to build > > it locally. > > wine is packaged (when it compiles)..there's a 4.x package, for example. The package is of a new version, but I need to use an old version since the new version has different bugs which are more harmful for my main application. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
