stdio.h patch
Hi,
Does anyone object to the patch below? It fixes this warning when
compiling with -Wnested-externs and -D_THREAD_SAFE (am I the only
one who ever does that??)
/usr/include/stdio.h: In function `__getc_locked':
/usr/include/stdio.h:418: warning: nested extern declaration of `__isthreaded'
/usr/include/stdio.h: In function `__putc_locked':
/usr/include/stdio.h:430: warning: nested extern declaration of `__isthreaded'
The fix is to declare '__isthreaded' at the top level. My understanding
of things is that this should be OK because the name begins with two
underscores (but I could be wrong about that).
Also, it removes a bunch of backslash contiunations that are not needed.
FYI, this is not an issue in -current.
Thanks,
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
Index: stdio.h
===
RCS file: /home/ncvs/src/include/stdio.h,v
retrieving revision 1.24.2.2
diff -u -r1.24.2.2 stdio.h
--- stdio.h 5 Dec 2001 20:48:07 - 1.24.2.2
+++ stdio.h 22 Aug 2002 05:01:24 -
@@ -415,29 +415,28 @@
#else
#define _FLOCKFILE(x) flockfile(x)
#endif
-static __inline int\
-__getc_locked(FILE *_fp) \
-{ \
- extern int __isthreaded;\
- int _ret; \
- if (__isthreaded) \
- _FLOCKFILE(_fp);\
- _ret = getc_unlocked(_fp); \
- if (__isthreaded) \
- funlockfile(_fp); \
- return (_ret); \
+extern int __isthreaded;
+static __inline int
+__getc_locked(FILE *_fp)
+{
+ int _ret;
+ if (__isthreaded)
+ _FLOCKFILE(_fp);
+ _ret = getc_unlocked(_fp);
+ if (__isthreaded)
+ funlockfile(_fp);
+ return (_ret);
}
-static __inline int\
-__putc_locked(int _x, FILE *_fp) \
-{ \
- extern int __isthreaded;\
- int _ret; \
- if (__isthreaded) \
- _FLOCKFILE(_fp);\
- _ret = putc_unlocked(_x, _fp); \
- if (__isthreaded) \
- funlockfile(_fp); \
- return (_ret); \
+static __inline int
+__putc_locked(int _x, FILE *_fp)
+{
+ int _ret;
+ if (__isthreaded)
+ _FLOCKFILE(_fp);
+ _ret = putc_unlocked(_x, _fp);
+ if (__isthreaded)
+ funlockfile(_fp);
+ return (_ret);
}
#definegetc(fp)__getc_locked(fp)
#defineputc(x, fp) __putc_locked(x, fp)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: failure to build gcc in make world
On Thu, 22 Aug 2002, Jens Rehsack wrote: > Date: Thu, 22 Aug 2002 00:33:07 +0200 > From: Jens Rehsack <[EMAIL PROTECTED]> > To: Andrew McNaughton <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: failure to build gcc in make world > > > > Andrew McNaughton wrote: > > > > I've worked through this more thoroughly, but I still can't get a > > successful make buildworld. > > > > I've thoroughly checked my source tree. I've compared all files' > > checksums against a known good source tree on a different system which > > compiles correctly (it's a later freebsd running gcc 3). > > Something's wrong with my build environment. > > You use gcc v3 to compile 4.6-STABLE? gcc version 2.95.3 [FreeBSD] 20010315 (release) I'm upgrading from 4.3-STABLE. I could install a later gcc, but I'm a little wary of moving further from a standard setup unless there's an explanation of why it should matter. > > The bit that's failing checks to see if it's gcc compiling itself and does > > different things accordingly. I presume this is about avoiding linking > > the new gcc against the one that's about to get over-written. Somehow > > this check is going wrong. If I do `CC=gcc make buildworld` then it gets > > past this point, but it fails later on when building libg2c. > > > > Does anyone know what might be going wrong? > > > > On Fri, 21 Jun 2002, Jens Rehsack wrote: > > > > > Andrew McNaughton wrote: > > > > > > > > I've just brought my source tree up to sync with RELENG_4_6, and tried > > > > to do a make world. It fails with the following output: > > > > > > > > - > > > > cc -c -O -pipe -march=pentium > > > > -I/mnt/imac/andrew/src/gnu/lib/libgcc/../../../contrib/gcc/config > > > > -I/mnt/imac/andrew/src/gnu/lib/libgcc/../../../contrib/gcc -I. > > > > -fexceptions -DIN_GCC -D_PTHREADS -fPIC -DGTHREAD_USE_WEAK -DL_mulsi3 -o > > > > _mulsi3.o > > > > /mnt/imac/andrew/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc1.c > > > > /mnt/imac/andrew/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc1.c:244: > > > > `a' was not declared in this scope > > > > /mnt/imac/andrew/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc1.c:244: > > > > `b' was not declared in this scope > > > > /mnt/imac/andrew/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc1.c:245: > > > > syntax error before `long' > > > > *** Error code 1 > > > > > > > > Stop in /mnt/imac/andrew/src/gnu/lib/libgcc. > > > > *** Error code 1 > > > > > > > > Stop in /mnt/imac/andrew/src. > > > > *** Error code 1 > > > > > > > > Stop in /mnt/imac/andrew/src. > > > > *** Error code 1 > > > > > > > > Stop in /mnt/imac/andrew/src. > > > > > > > > - > > > > > > > > Does anyone recognise this? Can anyone tell me what is going wrong? > > > > > > If sth. like that hitting me, I usually delete all files which have sth. to do > > > with that and redo a cvsup. > > > > > > > If it's important, my system is currently running 4.3-RELEASE. > > > > > > > > Andrew McNaughton > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > > with "unsubscribe freebsd-stable" in the body of the message > > > > > > -- > > > L i W W W i Jens Rehsack > > > LW W W > > > L i W W W W i nnnLiWing IT-Services > > > L iW W W Wi n n g g > > > i W W i n n g gFriesenstraße 2 > > > 06112 Halle > > > g > > > g g > > > Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: <[EMAIL PROTECTED]> > > > Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ > > > > > -- > L i W W W i Jens Rehsack > LW W W > L i W W W W i nnnLiWing IT-Services > L iW W W Wi n n g g > i W W i n n g gFriesenstraße 2 > 06112 Halle > g > g g > Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: <[EMAIL PROTECTED]> > Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: mbuf usage - how do i track it down?
Wow.
Is this something that only started happening recently? How recent
-STABLE are you running?
On Wed, Aug 21, 2002 at 11:01:34PM +0100, Gavin Atkinson wrote:
> On Wed, 21 Aug 2002, Ian Dowse wrote:
> > In message <[EMAIL PROTECTED]>, Gavin
>Atkinson writes:
> > >So how do I find out what is actually allocating these mbufs. Something
> > >seems to be leaking them.
> > http://www.maths.tcd.ie/~iedowse/FreeBSD/minfo/
> > It does a pile of consistency checks and can dump mbuf contents
> > with the -x flag. Run it redirected to a file so that it gets
> > a resonably consistent snapshot of the system, and then examine
> > the file.
>
> OK, this is interesting. It looks like i end up with a loop in an mbuf
> chain.
>
> Chain 0xc0cee900
> 0xc0cee900 len 41 flags 0x002 type 1 next 0xc0e3ba00 prev 0x0
> 0xc0e3ba00 len 181 flags 0x002 type 1 next 0xc0cc9a00 prev 0xc0cee900
> 0xc0cc9a00 len 135 flags 0x002 type 1 next 0xc0dacc00 prev 0xc0e3ba00
> 0xc0dacc00 len 185 flags 0x002 type 1 next 0xc0dd9c00 prev 0xc0cc9a00
>
> 0xc0e50a00 len 144 flags 0x002 type 1 next 0xc0d16400 prev 0xc0e10900
> 0xc0d16400 len 236 flags 0x000 type 0 next 0xc0e45700 prev 0xc0e50a00
> 0xc0e45700 len 567 flags 0x003 type 0 next 0xc0e4f900 prev 0xc0da4f00
> 0xc0e4f900 len 16 flags 0x000 type 0 next 0xc0dd2b00 prev 0xc0e45700
> 0xc0dd2b00 len 40 flags 0x002 type 0 next 0xc0bd7600 prev 0xc0e4f900
> 0xc0bd7600 len 16 flags 0x000 type 8 next 0xc0dd2b00 prev 0xc0dd2b00
> 0xc0dd2b00 len 40 flags 0x002 type 0 next 0xc0bd7600 prev 0xc0e4f900
> 0xc0bd7600 len 16 flags 0x000 type 8 next 0xc0dd2b00 prev 0xc0dd2b00
>
> Running it again a while later, gets stuck in a different loop
> 0xc0f8ac00 len 203 flags 0x002 type 0 next 0xc0decb00 prev 0xc0f98e00
> 0xc0decb00 len 209 flags 0x002 type 1 next 0xc0f8ac00 prev 0xc0f8ac00
> 0xc0f8ac00 len 203 flags 0x002 type 0 next 0xc0decb00 prev 0xc0f98e00
> 0xc0decb00 len 209 flags 0x002 type 1 next 0xc0f8ac00 prev 0xc0f8ac00
> 0xc0f8ac00 len 203 flags 0x002 type 0 next 0xc0decb00 prev 0xc0f98e00
> 0xc0decb00 len 209 flags 0x002 type 1 next 0xc0f8ac00 prev 0xc0f8ac00
> 0xc0f8ac00 len 203 flags 0x002 type 0 next 0xc0decb00 prev 0xc0f98e00
> 0xc0decb00 len 209 flags 0x002 type 1 next 0xc0f8ac00 prev 0xc0f8ac00
>
> Running it again, i see other suspicious results
>
> 0xc107cf00 len 150 flags 0x002 type 1 next 0xc0fe3d00 prev 0xc104a400
> 0xc107d000 len 0 flags 0x000 type 0 next 0x0 prev 0xc107d100
> 0xc107d100 len 876824626 flags 0x5757 type 22839 next 0xc107d000 prev
>0xc107d200
> 0xc107d200 len 0 flags 0x77e7 type 0 next 0xc107d100 prev 0xc107d300
> 0xc107d300 len 539915361 flags 0x6369 type 27713 next 0xc107d200 prev
>0xc107d400
> 0xc107d400 len 13315 flags 0x000 type 0 next 0xc107d300 prev 0xc107d500
> 0xc107d500 len -4014831 flags 0x1fe7 type -12313 next 0xc107d400 prev
>0xc107d600
> 0xc107d600 len 1852994816 flags 0x000 type 58 next 0xc107d500 prev 0xc0e57e00
> 0xc107d700 len 208 flags 0x002 type 0 next 0xc0fee700 prev 0xc107c100
> 0xc107d800 len 37 flags 0x002 type 0 next 0xc0e72c00 prev 0xc1045f00
> 0xc107d900 len 16 flags 0x000 type 0 next 0xc104d300 prev 0xc0fd1200
>
> So i'm at a loss as to where to go from here. Assuming minfo works, i may
> be seeing mbuf chain corruption.
>
> I have also seen the fillowing panic, during times of low mbufs:
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0xc
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc0196db8
> stack pointer = 0x10:0xc97f0bf0
> frame pointer = 0x10:0xc97f0bfc
> 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 = 167 (natd)
> interrupt mask =
> trap number = 12
> panic: page fault
>
> #5 0xc02bd553 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 1,
> tf_esi = 0, tf_ebp = -914420740, tf_isp = -914420772,
> tf_ebx = -1058123776, tf_edx = -1, tf_ecx = -925641856, tf_eax = -1,
> tf_trapno = 12, tf_err = 0, tf_eip = -1072075336, tf_cs = 8,
> tf_eflags = 66050, tf_esp = -1058123776, tf_ss = 1})
> at /usr/src/sys/i386/i386/trap.c:466
> #6 0xc0196db8 in m_copydata (m=0x0, off=-1, len=1,
> cp=0xc0ee5070 ":sha1:UPA6SGRR2Z7Y3YSND2J3JYQTFPMKK5JI")
> at /usr/src/sys/kern/uipc_mbuf.c:863
> #7 0xc01e438c in tcp_output (tp=0xc8e11140)
> at /usr/src/sys/netinet/tcp_output.c:607
> #8 0xc01e325b in tcp_input (m=0xc0ee5000, off0=20, proto=6)
> at /usr/src/sys/netinet/tcp_input.c:2158
> #9 0xc01dcc73 in ip_input (m=0xc0ee5000)
> at /usr/src/sys/ne
fxp SCB timeout (an old theme?)
I tried a new 4.6-STABLE (cvsup'ed Aug 20) kernel today on one of our Intel SR1200 server platforms and got fxp SCB timeout immediately after the system was up with the new kernel: Aug 22 04:34:10 omega /kernel: fxp0: SCB timeout: 0x80 0x0 0x50 0x0 Aug 22 04:34:10 omega /kernel: fxp0: SCB timeout: 0x80 0x0 0x50 0x0 This is with src/sys/dev/fxp/if_fxp.c rev. 1.110.2.24 2002/08/09 02:04:20 luigi The same host was working happily before since Jun 26 with if_fxp.c rev. 1.110.2.19 Dmesg output follows: 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 4.6-STABLE #0: Tue Aug 20 19:45:25 MSD 2002 uitm@omega:/sys/compile/omega Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (1396.45-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff real memory = 2147221504 (2096896K bytes) avail memory = 2088456192 (2039508K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 3, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 Preloaded elf kernel "kernel" at 0xc02cd000. Pentium Pro MTRR support enabled Using $PIR table, 13 entries at 0xc00f3bb0 npx0: on motherboard npx0: INT 16 interface pcib1: on motherboard IOAPIC #1 intpin 11 -> irq 2 IOAPIC #1 intpin 10 -> irq 5 pci1: on pcib1 ahc0: port 0x2400-0x24ff mem 0xfebe-0xfebe0fff irq 2 at device 7.0 on pci1 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0x2000-0x20ff mem 0xfebf-0xfebf0fff irq 5 at device 7.1 on pci1 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs pcib0: on motherboard IOAPIC #1 intpin 5 -> irq 7 IOAPIC #1 intpin 4 -> irq 9 IOAPIC #1 intpin 2 -> irq 10 IOAPIC #0 intpin 10 -> irq 11 pci0: on pcib0 fxp0: port 0x1400-0x143f mem 0xfe7a-0xfe7b,0xfe7e-0xfe7e0fff irq 7 at device 3.0 on pci0 fxp0: Ethernet address 00:03:47:a4:f6:7f inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: port 0x1440-0x147f mem 0xfe76-0xfe77,0xfe78-0xfe780fff irq 9 at device 4.0 on pci0 fxp1: Ethernet address 00:03:47:a4:f6:80 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: at 12.0 irq 10 isab0: at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x410-0x413,0x3a0-0x3af,0-0x3,0-0x7,0-0x3,0-0x7 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pcib2: on motherboard pci2: on pcib2 pcib3: on motherboard pci3: on pcib3 pcib4: on motherboard pci4: on pcib4 orm0: at iomem 0xc-0xc7fff,0xc8000-0xc97ff,0xc9800-0xcafff,0xcb000-0xd0fff,0xe4000-0xe7fff on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 Waiting 15 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da0s1a -- Andrey Alekseyev. Zenon N.S.P. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc_r (-pthread) linking problem
Joe Marcus Clarke writes: > > I'm trying to link an application with a library (libpdel) that itself > > links against libc_r. However, the application fails to link: > > > > cc -O -pipe -D_THREAD_SAFE ... -pthread -o ... -L/usr/local/lib -lpdel -lexpat >-lssl -lcrypto -lcrypt > > lws_tmpl_misc.o: In function `lws_tf_crypt_hash': > > lws_tmpl_misc.o(.text+0x3c3): undefined reference to `__pthread_read' > > main.o: In function `main': > > main.o(.text+0x21c): undefined reference to `__pthread_sigwait' > > /usr/local/lib/libpdel.so: undefined reference to `pthread_yield_np' > > /usr/local/lib/libpdel.so: undefined reference to `__pthread_connect' > > /usr/local/lib/libpdel.so: undefined reference to `__pthread_accept' > > /usr/local/lib/libpdel.so: undefined reference to `__pthread_detach' > > /usr/local/lib/libpdel.so: undefined reference to `__pthread_poll' > > /usr/local/lib/libpdel.so: undefined reference to `__pthread_write' > > *** Error code 1 > > > > This is on FreeBSD 4.6-stable as of today. This works fine on FreeBSD 4.5. > > I think you need to recompile libpdel for -stable. This should fix your > problem. Those symbols don't even exist in -stable. I built libpdel on Ack! You're right.. must be brain-dead today.. libpdel hasn't been rebuilt since upgrading this particular machine to -stable. Thanks & sorry for the noise... -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: minor (been there forever) annoyance
On Wed, 21 Aug 2002, Mike Harding wrote: > Can somebody tell me why if I run 'systat' in an x-window and then > kill the window, systat chews up all the CPU? Is there any way to fix I only had a 30 second look but it seems that the problem is probably in keyboard.c. It calls getch in an infinite loop and doesn't test for a return value of ERR which is presumably what would be returned if stdin had disappeared. I only had a quick look though and there may be something else going wrong. I can't actually reproduce the behaviour here. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc_r (-pthread) linking problem
On Wed, 2002-08-21 at 19:00, Archie Cobbs wrote:
> Hi,
>
> I'm trying to link an application with a library (libpdel) that itself
> links against libc_r. However, the application fails to link:
>
> cc -O -pipe -D_THREAD_SAFE ... -pthread -o ... -L/usr/local/lib -lpdel -lexpat
>-lssl -lcrypto -lcrypt
> lws_tmpl_misc.o: In function `lws_tf_crypt_hash':
> lws_tmpl_misc.o(.text+0x3c3): undefined reference to `__pthread_read'
> main.o: In function `main':
> main.o(.text+0x21c): undefined reference to `__pthread_sigwait'
> /usr/local/lib/libpdel.so: undefined reference to `pthread_yield_np'
> /usr/local/lib/libpdel.so: undefined reference to `__pthread_connect'
> /usr/local/lib/libpdel.so: undefined reference to `__pthread_accept'
> /usr/local/lib/libpdel.so: undefined reference to `__pthread_detach'
> /usr/local/lib/libpdel.so: undefined reference to `__pthread_poll'
> /usr/local/lib/libpdel.so: undefined reference to `__pthread_write'
> *** Error code 1
>
> This is on FreeBSD 4.6-stable as of today. This works fine on FreeBSD 4.5.
>
> FYI, none of my code ever calls pthread_yield_np(), so I don't know
> where that symbol is coming from.
>
> Any ideas what the problem is?
I think you need to recompile libpdel for -stable. This should fix your
problem. Those symbols don't even exist in -stable. I built libpdel on
-stable with a bunch of other issues (i.e. -Werror caused a failure due
to a warning in stdio.h, and ${INCOWN}, ${INCGRP}, and ${INCMODE} don't
exist [they are now INCS*]). But, after getting it compiled and
installed:
/tmp 20:38 shumai marcus %582# cc -o xxx -L/usr/local/lib -lpdel
-pthread -lssl -lcrypto -lexpat xxx.c
/tmp 20:38 shumai marcus %583#
Joe
>
> Thanks,
> -Archie
>
> __
> Archie Cobbs * Packet Design * http://www.packetdesign.com
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message
>
signature.asc
Description: This is a digitally signed message part
Panic: vm_page_insert: already inserted
I've recently experienced this crash on 4.6.2-RELEASE. Relevant
information is appended to this email message. My question is: should
I submit a PR or try to troubleshoot my hardware?
--
Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED]
>>> The opinions expressed above are entirely my own <<<
Nasrudin was carrying home a piece of liver and the recipe for liver
pie. Suddenly a bird of prey swooped down and snatched the piece of
meat from his hand. As the bird flew off, Nasrudin called after it,
"Foolish bird! You have the liver, but what can you do with it without
the recipe?"
# gdb -k kernel.debug vmcore.0
GNU gdb 4.18 (FreeBSD)
...
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD at phsyical address 0x004fa000
initial pcb at physical address 0x00439120
panicstr: vm_page_insert: already inserted
panic messages:
---
panic: vm_page_insert: already inserted
...
#0 dumpsys () at ../../kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:487
#1 0xc01ebdd7 in boot (howto=256) at ../../kern/kern_shutdown.c:316
#2 0xc01ec215 in panic (fmt=0xc03b9ac0 "vm_page_insert: already inserted")
at ../../kern/kern_shutdown.c:595
#3 0xc030494d in vm_page_insert (m=0xc0b33e24, object=0xdebc9180, pindex=0)
at ../../vm/vm_page.c:374
#4 0xc0304e1c in vm_page_alloc (object=0xdebc9180, pindex=0, page_req=2) at
../../vm/vm_page.c:844
#5 0xc021324a in allocbuf (bp=0xd1b0ba74, size=1024) at
../../kern/vfs_bio.c:2511
#6 0xc0212e2a in getblk (vp=0xdeae9800, blkno=0, size=1024, slpflag=0,
slptimeo=0)
at ../../kern/vfs_bio.c:2286
#7 0xc0210d8e in bread (vp=0xdeae9800, blkno=0, size=1024, cred=0x0,
bpp=0xdf505e38)
at ../../kern/vfs_bio.c:508
#8 0xc02f1da0 in ffs_read (ap=0xdf505e9c) at ../../ufs/ufs/ufs_readwrite.c:273
#9 0xc02f8d06 in ufs_readdir (ap=0xdf505eec) at vnode_if.h:334
#10 0xc02f96e9 in ufs_vnoperate (ap=0xdf505eec) at
../../ufs/ufs/ufs_vnops.c:2422
#11 0xc021ed1b in getdirentries (p=0xdecf3c20, uap=0xdf505f80) at
vnode_if.h:769
#12 0xc0358739 in syscall2 (frame={tf_fs = -1070333905, tf_es = 47, tf_ds =
47, tf_edi = 134553824,
tf_esi = 134581888, tf_ebp = -1077937636, tf_isp = -548380716, tf_ebx =
672081412,
tf_edx = 134581888, tf_ecx = 134553824, tf_eax = 196, tf_trapno = 7,
tf_err = 2,
tf_eip = 671765424, tf_cs = 31, tf_eflags = 582, tf_esp = -1077937680,
tf_ss = 47})
at ../../i386/i386/trap.c:1167
#13 0xc03494e5 in Xint0x80_syscall ()
#14 0x280a1b36 in ?? ()
#15 0x280a1386 in ?? ()
#16 0x80496ce in ?? ()
#17 0x804b5d8 in ?? ()
#18 0x8049397 in ?? ()
(kgdb) up 3
#3 0xc030494d in vm_page_insert (m=0xc0b33e24, object=0xdebc9180, pindex=0)
at ../../vm/vm_page.c:374
374 panic("vm_page_insert: already inserted");
(kgdb) print m
$1 = 0x0
(kgdb) up
#4 0xc0304e1c in vm_page_alloc (object=0xdebc9180, pindex=0, page_req=2) at
../../vm/vm_page.c:844
844 vm_page_insert(m, object, pindex);
(kgdb) print m
$2 = 0xc0b33e24
(kgdb) print *m
$3 = {pageq = {tqe_next = 0xc0c96ba4, tqe_prev = 0xc0458310}, hnext = 0x0,
listq = {
tqe_next = 0xc0ea20ec, tqe_prev = 0xdee4a8b8}, object = 0xdee4a8a0, pindex
= 102,
phys_addr = 149848064, md = {pv_list_count = 0, pv_list = {tqh_first = 0x0,
tqh_last = 0xc0b33e48}},
queue = 0, flags = 1, pc = 8, wire_count = 0, hold_count = 0, act_count = 0
'\000', busy = 0 '\000',
valid = 0 '\000', dirty = 0 '\000'}
# uname -a
FreeBSD cdbuilder 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #0: Sat Aug 17 18:02:09
PDT 2002 unixwiz@cdbuilder:/usr/src/sys/compile/ARCHIVE i386
# 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 4.6.2-RELEASE #0: Sat Aug 17 18:27:38 PDT 2002
unixwiz@cdbuilder:/usr/src/sys/compile/DTE
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (797.42-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x686 Stepping = 6
Features=0x383f9ff
real memory = 535560192 (523008K bytes)
avail memory = 515907584 (503816K bytes)
Preloaded elf kernel "kernel" at 0xc04db000.
Pentium Pro MTRR support enabled
md0: Malloc disk
Using $PIR table, 10 entries at 0xc00f30f0
npx0: on motherboard
npx0: INT 16 interface
pcib0: on motherboard
pci0: on pcib0
pci0: at 1.0 irq 11
pcib1: at device 30.0 on pci0
pci1: on pcib1
fxp0: port 0xde80-0xdebf mem
0xff70-0xff7f,0xff8fd000-0xff8fdfff irq 3 at device 1.0 on pci1
fxp0: Ethernet address 00:d0:b7:e2:f4:45
inphy0: on miibus0
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci1: (vendor=0x1274, dev=0x1371) at 7.0 irq 9
ahc0: port 0xd400-0xd4ff mem
0xff8fe000-0xff8fefff irq 10 at device 9.0 on pci1
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
ahc1: port 0xd800-0xd8ff mem
0xff8ff000-0xff8f irq 9 at device 10.0 on pci1
aic7890/91: Ultra2 Wide Ch
libc_r (-pthread) linking problem
Hi, I'm trying to link an application with a library (libpdel) that itself links against libc_r. However, the application fails to link: cc -O -pipe -D_THREAD_SAFE ... -pthread -o ... -L/usr/local/lib -lpdel -lexpat -lssl -lcrypto -lcrypt lws_tmpl_misc.o: In function `lws_tf_crypt_hash': lws_tmpl_misc.o(.text+0x3c3): undefined reference to `__pthread_read' main.o: In function `main': main.o(.text+0x21c): undefined reference to `__pthread_sigwait' /usr/local/lib/libpdel.so: undefined reference to `pthread_yield_np' /usr/local/lib/libpdel.so: undefined reference to `__pthread_connect' /usr/local/lib/libpdel.so: undefined reference to `__pthread_accept' /usr/local/lib/libpdel.so: undefined reference to `__pthread_detach' /usr/local/lib/libpdel.so: undefined reference to `__pthread_poll' /usr/local/lib/libpdel.so: undefined reference to `__pthread_write' *** Error code 1 This is on FreeBSD 4.6-stable as of today. This works fine on FreeBSD 4.5. FYI, none of my code ever calls pthread_yield_np(), so I don't know where that symbol is coming from. Any ideas what the problem is? Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: failure to build gcc in make world
Andrew McNaughton wrote: > > I've worked through this more thoroughly, but I still can't get a > successful make buildworld. > > I've thoroughly checked my source tree. I've compared all files' > checksums against a known good source tree on a different system which > compiles correctly (it's a later freebsd running gcc 3). > Something's wrong with my build environment. You use gcc v3 to compile 4.6-STABLE? > The bit that's failing checks to see if it's gcc compiling itself and does > different things accordingly. I presume this is about avoiding linking > the new gcc against the one that's about to get over-written. Somehow > this check is going wrong. If I do `CC=gcc make buildworld` then it gets > past this point, but it fails later on when building libg2c. > > Does anyone know what might be going wrong? > > On Fri, 21 Jun 2002, Jens Rehsack wrote: > > > Andrew McNaughton wrote: > > > > > > I've just brought my source tree up to sync with RELENG_4_6, and tried > > > to do a make world. It fails with the following output: > > > > > > - > > > cc -c -O -pipe -march=pentium > > > -I/mnt/imac/andrew/src/gnu/lib/libgcc/../../../contrib/gcc/config > > > -I/mnt/imac/andrew/src/gnu/lib/libgcc/../../../contrib/gcc -I. > > > -fexceptions -DIN_GCC -D_PTHREADS -fPIC -DGTHREAD_USE_WEAK -DL_mulsi3 -o > > > _mulsi3.o > > > /mnt/imac/andrew/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc1.c > > > /mnt/imac/andrew/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc1.c:244: > > > `a' was not declared in this scope > > > /mnt/imac/andrew/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc1.c:244: > > > `b' was not declared in this scope > > > /mnt/imac/andrew/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc1.c:245: > > > syntax error before `long' > > > *** Error code 1 > > > > > > Stop in /mnt/imac/andrew/src/gnu/lib/libgcc. > > > *** Error code 1 > > > > > > Stop in /mnt/imac/andrew/src. > > > *** Error code 1 > > > > > > Stop in /mnt/imac/andrew/src. > > > *** Error code 1 > > > > > > Stop in /mnt/imac/andrew/src. > > > > > > - > > > > > > Does anyone recognise this? Can anyone tell me what is going wrong? > > > > If sth. like that hitting me, I usually delete all files which have sth. to do > > with that and redo a cvsup. > > > > > If it's important, my system is currently running 4.3-RELEASE. > > > > > > Andrew McNaughton > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-stable" in the body of the message > > > > -- > > L i W W W i Jens Rehsack > > LW W W > > L i W W W W i nnnLiWing IT-Services > > L iW W W Wi n n g g > > i W W i n n g gFriesenstraße 2 > > 06112 Halle > > g > > g g > > Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: <[EMAIL PROTECTED]> > > Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ > > -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: <[EMAIL PROTECTED]> Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: mbuf usage - how do i track it down?
On Wed, 21 Aug 2002, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Gavin Atkinson
>writes:
> >So how do I find out what is actually allocating these mbufs. Something
> >seems to be leaking them.
> http://www.maths.tcd.ie/~iedowse/FreeBSD/minfo/
> It does a pile of consistency checks and can dump mbuf contents
> with the -x flag. Run it redirected to a file so that it gets
> a resonably consistent snapshot of the system, and then examine
> the file.
OK, this is interesting. It looks like i end up with a loop in an mbuf
chain.
Chain 0xc0cee900
0xc0cee900 len 41 flags 0x002 type 1 next 0xc0e3ba00 prev 0x0
0xc0e3ba00 len 181 flags 0x002 type 1 next 0xc0cc9a00 prev 0xc0cee900
0xc0cc9a00 len 135 flags 0x002 type 1 next 0xc0dacc00 prev 0xc0e3ba00
0xc0dacc00 len 185 flags 0x002 type 1 next 0xc0dd9c00 prev 0xc0cc9a00
0xc0e50a00 len 144 flags 0x002 type 1 next 0xc0d16400 prev 0xc0e10900
0xc0d16400 len 236 flags 0x000 type 0 next 0xc0e45700 prev 0xc0e50a00
0xc0e45700 len 567 flags 0x003 type 0 next 0xc0e4f900 prev 0xc0da4f00
0xc0e4f900 len 16 flags 0x000 type 0 next 0xc0dd2b00 prev 0xc0e45700
0xc0dd2b00 len 40 flags 0x002 type 0 next 0xc0bd7600 prev 0xc0e4f900
0xc0bd7600 len 16 flags 0x000 type 8 next 0xc0dd2b00 prev 0xc0dd2b00
0xc0dd2b00 len 40 flags 0x002 type 0 next 0xc0bd7600 prev 0xc0e4f900
0xc0bd7600 len 16 flags 0x000 type 8 next 0xc0dd2b00 prev 0xc0dd2b00
Running it again a while later, gets stuck in a different loop
0xc0f8ac00 len 203 flags 0x002 type 0 next 0xc0decb00 prev 0xc0f98e00
0xc0decb00 len 209 flags 0x002 type 1 next 0xc0f8ac00 prev 0xc0f8ac00
0xc0f8ac00 len 203 flags 0x002 type 0 next 0xc0decb00 prev 0xc0f98e00
0xc0decb00 len 209 flags 0x002 type 1 next 0xc0f8ac00 prev 0xc0f8ac00
0xc0f8ac00 len 203 flags 0x002 type 0 next 0xc0decb00 prev 0xc0f98e00
0xc0decb00 len 209 flags 0x002 type 1 next 0xc0f8ac00 prev 0xc0f8ac00
0xc0f8ac00 len 203 flags 0x002 type 0 next 0xc0decb00 prev 0xc0f98e00
0xc0decb00 len 209 flags 0x002 type 1 next 0xc0f8ac00 prev 0xc0f8ac00
Running it again, i see other suspicious results
0xc107cf00 len 150 flags 0x002 type 1 next 0xc0fe3d00 prev 0xc104a400
0xc107d000 len 0 flags 0x000 type 0 next 0x0 prev 0xc107d100
0xc107d100 len 876824626 flags 0x5757 type 22839 next 0xc107d000 prev
0xc107d200
0xc107d200 len 0 flags 0x77e7 type 0 next 0xc107d100 prev 0xc107d300
0xc107d300 len 539915361 flags 0x6369 type 27713 next 0xc107d200 prev
0xc107d400
0xc107d400 len 13315 flags 0x000 type 0 next 0xc107d300 prev 0xc107d500
0xc107d500 len -4014831 flags 0x1fe7 type -12313 next 0xc107d400 prev
0xc107d600
0xc107d600 len 1852994816 flags 0x000 type 58 next 0xc107d500 prev 0xc0e57e00
0xc107d700 len 208 flags 0x002 type 0 next 0xc0fee700 prev 0xc107c100
0xc107d800 len 37 flags 0x002 type 0 next 0xc0e72c00 prev 0xc1045f00
0xc107d900 len 16 flags 0x000 type 0 next 0xc104d300 prev 0xc0fd1200
So i'm at a loss as to where to go from here. Assuming minfo works, i may
be seeing mbuf chain corruption.
I have also seen the fillowing panic, during times of low mbufs:
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0196db8
stack pointer = 0x10:0xc97f0bf0
frame pointer = 0x10:0xc97f0bfc
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 = 167 (natd)
interrupt mask =
trap number = 12
panic: page fault
#5 0xc02bd553 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 1,
tf_esi = 0, tf_ebp = -914420740, tf_isp = -914420772,
tf_ebx = -1058123776, tf_edx = -1, tf_ecx = -925641856, tf_eax = -1,
tf_trapno = 12, tf_err = 0, tf_eip = -1072075336, tf_cs = 8,
tf_eflags = 66050, tf_esp = -1058123776, tf_ss = 1})
at /usr/src/sys/i386/i386/trap.c:466
#6 0xc0196db8 in m_copydata (m=0x0, off=-1, len=1,
cp=0xc0ee5070 ":sha1:UPA6SGRR2Z7Y3YSND2J3JYQTFPMKK5JI")
at /usr/src/sys/kern/uipc_mbuf.c:863
#7 0xc01e438c in tcp_output (tp=0xc8e11140)
at /usr/src/sys/netinet/tcp_output.c:607
#8 0xc01e325b in tcp_input (m=0xc0ee5000, off0=20, proto=6)
at /usr/src/sys/netinet/tcp_input.c:2158
#9 0xc01dcc73 in ip_input (m=0xc0ee5000)
at /usr/src/sys/netinet/ip_input.c:821
#10 0xc01d605b in div_output (so=0xc8d3ce40, m=0xc0ee5000, sin=0xc1ac2650,
control=0x0) at /usr/src/sys/netinet/ip_divert.c:327
#11 0xc01d61fb in div_send (so=0xc8d3ce40, flags=0, m=0xc0ee5000,
nam=0xc1ac2650, control=0x0, p=0xc874b380)
at /usr/src/sys/netinet/ip_divert.c:440
#12 0xc01990db in sosend (so=0
Re: upgrade with smmsp user is breaking things...
It would seem that I missed a bunch of configuration jargon in /etc/defaults/rc.conf when I ran mergemaster. (Along with /etc/mail/submit.cf and /etc/rc.sendmail) Everything seems to be working again. A big "Thank You!" to everyone who posted and emailed me! This list is much appreciated. Matthias To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: upgrade with smmsp user is breaking things...
On Wed, Aug 21, 2002 at 01:48:00PM -0400, Matthias Trevarthan wrote: > > Yes. I gathered that after a bit of research. > > I chmoded my mqueue directory to 777. That seems to have taken care of the > problem temporarily, but it's not a permanent fix. drwxrwx--- 2 smmsp smmsp 512 21 aug 03:03 clientmqueue/ drwxr-xr-x 2 root daemon 512 21 aug 03:04 mqueue/ This is what I got on my 4.6.2. -- Morten Rodal // // PGP ID 2D75595B // 22DE D67A 1AEA EF94 872A 9384 6D67 B50B 2D75 595B // msg48962/pgp0.pgp Description: PGP signature
Re: upgrade with smmsp user is breaking things...
Another error from the sendmail uucp user: Aug 21 13:34:46 agape sendmail[3084]: g7LHYkM5003083: SYSERR(uucp): openmailer: insufficient privileges to change gid, RunAsUid=6, new_gid=0, gid=6, egid=25 Aug 21 13:34:46 agape sendmail[3085]: g7LHYkM5003083: SYSERR(uucp): openmailer: insufficient privileges to change gid, RunAsUid=6, new_gid=0, gid=6, egid=25 On Wednesday 21 August 2002 01:48 pm, Matthias Trevarthan wrote: > Yes. I gathered that after a bit of research. > > I chmoded my mqueue directory to 777. That seems to have taken care of the > problem temporarily, but it's not a permanent fix. > > Matthias > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
