Re: nfs_inactive() bug? -> panic: lockmgr: locking against myself
In message <[EMAIL PROTECTED]>, Don Lewis writes:
>
>A potentially better solution just occurred to me. It looks like it
>would be better if vrele() waited to decrement v_usecount until *after*
>the call to VOP_INACTIVE() (and after the call to VI_LOCK()). If that
>were done, nfs_inactive() wouldn't need to muck with v_usecount at all.
I've looked at this before; I think some filesystems (ufs anyway)
depend on v_usecount being 0 when VOP_INACTIVE() is called. The
patch I have had lying around for quite a while is below. It adds
a vnode flag to avoid recursion into the last-reference handling
code in vrele/vput, which is the real problem.
It also guarantees that a vnode will not be recycled during
VOP_INACTIVE(), so the nfs code no longer needs to hold an extra
reference in the first place. The flag manipulation code got a bit
messy after Jeff's vnode flag splitting work, so the patch could
probably be improved.
Whatever way this is done, we should try to avoid adding more hacks
to the nfs_inactive() code anyway.
Ian
Index: sys/vnode.h
===
RCS file: /home/iedowse/CVS/src/sys/sys/vnode.h,v
retrieving revision 1.206
diff -u -r1.206 vnode.h
--- sys/vnode.h 1 Sep 2002 20:37:21 - 1.206
+++ sys/vnode.h 11 Sep 2002 11:06:46 -
@@ -220,6 +220,7 @@
#defineVI_DOOMED 0x0080 /* This vnode is being recycled */
#defineVI_FREE 0x0100 /* This vnode is on the freelist */
#defineVI_OBJDIRTY 0x0400 /* object might be dirty */
+#defineVI_INACTIVE 0x0800 /* VOP_INACTIVE is in progress */
/*
* XXX VI_ONWORKLST could be replaced with a check for NULL list elements
* in v_synclist.
@@ -377,14 +378,14 @@
/* Requires interlock */
#defineVSHOULDFREE(vp) \
- (!((vp)->v_iflag & (VI_FREE|VI_DOOMED)) && \
+ (!((vp)->v_iflag & (VI_FREE|VI_DOOMED|VI_INACTIVE)) && \
!(vp)->v_holdcnt && !(vp)->v_usecount && \
(!(vp)->v_object || \
!((vp)->v_object->ref_count || (vp)->v_object->resident_page_count)))
/* Requires interlock */
#define VMIGHTFREE(vp) \
- (!((vp)->v_iflag & (VI_FREE|VI_DOOMED|VI_XLOCK)) && \
+ (!((vp)->v_iflag & (VI_FREE|VI_DOOMED|VI_XLOCK|VI_INACTIVE)) && \
LIST_EMPTY(&(vp)->v_cache_src) && !(vp)->v_usecount)
/* Requires interlock */
Index: nfsclient/nfs_node.c
===
RCS file: /home/iedowse/CVS/src/sys/nfsclient/nfs_node.c,v
retrieving revision 1.55
diff -u -r1.55 nfs_node.c
--- nfsclient/nfs_node.c11 Jul 2002 17:54:58 - 1.55
+++ nfsclient/nfs_node.c11 Sep 2002 11:06:46 -
@@ -289,21 +289,7 @@
} else
sp = NULL;
if (sp) {
- /*
-* We need a reference to keep the vnode from being
-* recycled by getnewvnode while we do the I/O
-* associated with discarding the buffers unless we
-* are being forcibly unmounted in which case we already
-* have our own reference.
-*/
- if (ap->a_vp->v_usecount > 0)
- (void) nfs_vinvalbuf(ap->a_vp, 0, sp->s_cred, td, 1);
- else if (vget(ap->a_vp, 0, td))
- panic("nfs_inactive: lost vnode");
- else {
- (void) nfs_vinvalbuf(ap->a_vp, 0, sp->s_cred, td, 1);
- vrele(ap->a_vp);
- }
+ (void)nfs_vinvalbuf(ap->a_vp, 0, sp->s_cred, td, 1);
/*
* Remove the silly file that was rename'd earlier
*/
Index: kern/vfs_subr.c
===
RCS file: /home/iedowse/CVS/src/sys/kern/vfs_subr.c,v
retrieving revision 1.401
diff -u -r1.401 vfs_subr.c
--- kern/vfs_subr.c 5 Sep 2002 20:46:19 - 1.401
+++ kern/vfs_subr.c 11 Sep 2002 11:06:46 -
@@ -829,7 +829,8 @@
for (count = 0; count < freevnodes; count++) {
vp = TAILQ_FIRST(&vnode_free_list);
- KASSERT(vp->v_usecount == 0,
+ KASSERT(vp->v_usecount == 0 &&
+ (vp->v_iflag & VI_INACTIVE) == 0,
("getnewvnode: free vnode isn't"));
TAILQ_REMOVE(&vnode_free_list, vp, v_freelist);
@@ -1980,8 +1981,8 @@
KASSERT(vp->v_writecount < vp->v_usecount || vp->v_usecount < 1,
("vrele: missed vn_close"));
- if (vp->v_usecount > 1) {
-
+ if (vp->v_usecount > 1 ||
+ ((vp->v_iflag & VI_INACTIVE) && vp->v_usecount == 1)) {
vp->v_usecount--;
VI_UNLOCK(vp);
@@ -1991,13 +1992,20 @@
if (vp->v_usecount == 1) {
vp->v_usecount--;
/*
-* We must call VOP_INACTIVE with the node l
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/var/tmp/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Sep 11 06:11:26 PDT 2002 -- >>> Kernel build for GENERIC completed on Wed Sep 11 07:16:38 PDT 2002 -- >>> Kernel build for LINT started on Wed Sep 11 07:16:40 PDT 2002 -- ===> vinum ./aicasm: 877 instructions used ./aicasm: 658 instructions used In file included from /var/tmp/des/src/sys/dev/dgb/dgb.c:89: /var/tmp/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /var/tmp/des/src/sys/dev/dgb/dgb.c:92:2: #error "The dgb device requires the old isa compatibility shims" /var/tmp/des/src/sys/dev/iicbus/iic.c:42:25: machine/iic.h: No such file or directory /var/tmp/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver is broken and is not compiled with LINT" /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:80:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:81:33: machine/physio_proc.h: No such file or directory In file included from /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:86: /var/tmp/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/ncv/ncr53c500_pccard.c:55:27: machine/dvcfg.h: No such file or directory In file included from /var/tmp/des/src/sys/dev/ncv/ncr53c500_pccard.c:63: /var/tmp/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/nsp/nsp.c:80:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/nsp/nsp.c:81:33: machine/physio_proc.h: No such file or directory /var/tmp/des/src/sys/dev/nsp/nsp_pccard.c:52:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/smbus/smb.c:41:25: machine/smb.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30.c:78:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30.c:79:33: machine/physio_proc.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30_pccard.c:57:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30_isa.c:65:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/usb/ukbd.c:419:21: ukbdmap.h: No such file or directory In file included from /var/tmp/des/src/sys/dev/wl/if_wl.c:218: /var/tmp/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /var/tmp/des/src/sys/dev/wl/if_wl.c:224:35: machine/if_wl_wavelan.h: No such file or directory /var/tmp/des/src/sys/dev/wl/if_wl.c:227:2: #error "The wl device requires the old isa compatibility shims" /var/tmp/des/src/sys/kern/subr_prof.c:62:30: machine/asmacros.h: No such file or directory /var/tmp/des/src/sys/kern/subr_prof.c:232:2: #error /var/tmp/des/src/sys/kern/subr_prof.c:243:2: #error /var/tmp/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver is broken and is not compiled with LINT" /var/tmp/des/src/sys/pci/simos.c:57:2: #error "The simos device requires the old pci compatibility shims" /var/tmp/des/src/sys/dev/syscons/syscons.c:117:18: font.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /var/tmp/des/obj/var/tmp/des/src/sys/LINT. *** Error code 1 Stop in /var/tmp/des/obj/var/tmp/des/src/sys/LINT. *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel from latest cvsup refuses to boot. - hangs
Hi Folks, I am still unable to boot into the kernel from the latest cvsup. I did a "make buildworld and make kernel" and when I try to "boot -vs", it goes on to register procfs and then hangs at this stagethis is what it finally prints...and freezes Timecounters tick every 10.000 msec bpf: lo0 attached. I have booted from an older kernel I had. System Info -- FreeBSD 5.0-CURRENT #0: Thu Aug 8 21:48:49 IST 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel.sogood/kernel" at 0xc05ad000. Timecounter "i8254" frequency 119s182 Hz Timecounter "TSC" frequency 996769586 Hz CPU: Pentium III/Pentium III Xeon/Celeron (996n77-MHz 686-class CPU) Origin } "GenuineIntel"` Id = 0868a Stepping = 10 Features=0x383fbff Anyone else experiencing this ? TIA Regards Sid To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Any problems with increaseing the dump(8) block size?
I'd like to make this commit to get better performance on today's streaming tape drives. It seems my DLT drive doesn't stream well with the default block size of '10'. Index: include/protocols/dumprestore.h === RCS file: /home/ncvs/src/include/protocols/dumprestore.h,v retrieving revision 1.10 diff -u -r1.10 dumprestore.h --- include/protocols/dumprestore.h 17 Jul 2002 02:03:19 - 1.10 +++ include/protocols/dumprestore.h 19 Jul 2002 05:30:39 - @@ -56,7 +56,7 @@ * or TS_ADDR record. Note that it must be a power of two. */ #define TP_BSIZE 1024 -#define NTREC 10 +#define NTREC 64 #define HIGHDENSITYTREC32 #define TP_NINDIR (TP_BSIZE/2) #define LBLSIZE16 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locking problems in exec
On 11-Sep-2002 Don Lewis wrote: > On 10 Sep, Don Lewis wrote: >> On 10 Sep, Nate Lawson wrote: >> >>> I'm not sure why fdcheckstd() and setugidsafety() couldn't both happen >>> before grabbing the proc lock. Dropping locks in the middle or >>> pre-allocating should always be a last resort. >> >> That is ok as long as there aren't other threads that can mess things up >> after fdcheckstd() and setugidsafety() have done their thing. > > It looks like threads aren't a problem because of the call to > thread_single() at the top of execve(). Ptrace() is still a potential > problem, so we can't call fdcheckstd() and setugidsafety() until after > credential_changing has been calculated, setsugid() has been called and > tracing has been disabled, all of which are done after proc lock has > been grabbed. > > It also looks like we should pre-allocate newprocsig instead of > temporarily dropping the lock. We used to do that but backed it out because it wasn't deemed to be that necessary. If you have a demonstrable problematic race condition that this fixes then it might be a good idea. However, allocating stuff we don't need isn't but so great either. I think ptrace(2) is not an issue because ptrace(2) won't attach to a P_INEXEC process IIRC. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any problems with increaseing the dump(8) block size?
No. Don't change this- people are very well attuned to using an argument to change it and all your change will do is catch the unwary and possibly break binary compat on apps that define records based off of NTREC. On Wed, 11 Sep 2002, David O'Brien wrote: > I'd like to make this commit to get better performance on today's > streaming tape drives. It seems my DLT drive doesn't stream well with > the default block size of '10'. > > > Index: include/protocols/dumprestore.h > === > RCS file: /home/ncvs/src/include/protocols/dumprestore.h,v > retrieving revision 1.10 > diff -u -r1.10 dumprestore.h > --- include/protocols/dumprestore.h 17 Jul 2002 02:03:19 - 1.10 > +++ include/protocols/dumprestore.h 19 Jul 2002 05:30:39 - > @@ -56,7 +56,7 @@ > * or TS_ADDR record. Note that it must be a power of two. > */ > #define TP_BSIZE 1024 > -#define NTREC10 > +#define NTREC64 > #define HIGHDENSITYTREC 32 > #define TP_NINDIR(TP_BSIZE/2) > #define LBLSIZE 16 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Call for testers for mlx(4) patch
Can people please test the following patch also available at
http://www.FreeBSD.org/~jhb/patches/mlx.patch
It fixes problems when using older Mylex controllers in Alphas,
but I'd like to make sure it doesn't break mlx(4) for other
folks before committing. Mike Smith has given the patch a once
over as well. Thanks.
Index: dev/mlx/mlx_disk.c
===
RCS file: /usr/cvs/src/sys/dev/mlx/mlx_disk.c,v
retrieving revision 1.22
diff -u -r1.22 mlx_disk.c
--- dev/mlx/mlx_disk.c 12 Sep 2001 08:37:08 - 1.22
+++ dev/mlx/mlx_disk.c 9 Sep 2002 14:22:52 -
@@ -264,11 +264,15 @@
/*
* Set maximum I/O size to the lesser of the recommended maximum and the practical
- * maximum.
+ * maximum except on v2 cards where the maximum is set to 8 pages.
*/
-s1 = sc->mlxd_controller->mlx_enq2->me_maxblk * MLX_BLKSIZE;
-s2 = (sc->mlxd_controller->mlx_enq2->me_max_sg - 1) * PAGE_SIZE;
-dsk->si_iosize_max = imin(s1, s2);
+if (sc->mlxd_controller->mlx_iftype == MLX_IFTYPE_2)
+ dsk->si_iosize_max = 8 * PAGE_SIZE;
+else {
+ s1 = sc->mlxd_controller->mlx_enq2->me_maxblk * MLX_BLKSIZE;
+ s2 = (sc->mlxd_controller->mlx_enq2->me_max_sg - 1) * PAGE_SIZE;
+ dsk->si_iosize_max = imin(s1, s2);
+}
return (0);
}
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel from latest cvsup refuses to boot. - hangs
It's probably a device driver probe problem although it's impossible to tell without more info. Enable options DDB, boot -vs, wait for the hang. Hit CTRL-ALT-ESC to go into DDB and type tr to get a backtrace. Copy the trace info (serial console is best for this). Hit c for continue, wait, repeat. Chances are you'll still be at the same backtrace. If so, then this is the code that's hanging. -Nate On Thu, 12 Sep 2002, Sid Carter wrote: > Hi Folks, > > I am still unable to boot into the kernel from the latest cvsup. > > I did a "make buildworld and make kernel" and when I try to "boot -vs", > it goes on to register procfs and then hangs at this stagethis is > what it finally prints...and freezes > > Timecounters tick every 10.000 msec > bpf: lo0 attached. > > I have booted from an older kernel I had. > > System Info > -- > FreeBSD 5.0-CURRENT #0: Thu Aug 8 21:48:49 IST 2002 > root@calvin:/usr/obj/usr/src/sys/GENERIC > Preloaded elf kernel "/boot/kernel.sogood/kernel" at 0xc05ad000. > Timecounter "i8254" frequency 119s182 Hz > Timecounter "TSC" frequency 996769586 Hz > CPU: Pentium III/Pentium III Xeon/Celeron (996n77-MHz 686-class CPU) > Origin } "GenuineIntel"` Id = 0868a Stepping = 10 > > Features=0x383fbff OV,P\M-AT,PSE36,MMX,FXSR,SSE> > > Anyone else experiencing this ? > > TIA > Regards > Sid > > > > > > 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: alpha tinderbox failure
JKH task: go through conf/NOTES and move devices that don't (or could never) build on alpha to i386/conf/NOTES. At the end of this, LINT should build on alpha and i386. BTW, I would think there should be a pc98/conf/NOTES that most stuff moved out of the global notes should go into as well as i386. Anyone up for this? -Nate On Wed, 11 Sep 2002, Dag-Erling Smorgrav wrote: > -- > >>> 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/var/tmp/des/src/alpha/usr/include > -- > >>> stage 4: building libraries > -- > >>> stage 4: make dependencies > -- > >>> stage 4: building everything.. > -- > >>> Kernel build for GENERIC started on Wed Sep 11 06:11:26 PDT 2002 > -- > >>> Kernel build for GENERIC completed on Wed Sep 11 07:16:38 PDT 2002 > -- > >>> Kernel build for LINT started on Wed Sep 11 07:16:40 PDT 2002 > -- > ===> vinum > ./aicasm: 877 instructions used > ./aicasm: 658 instructions used > In file included from /var/tmp/des/src/sys/dev/dgb/dgb.c:89: > /var/tmp/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file >or directory > /var/tmp/des/src/sys/dev/dgb/dgb.c:92:2: #error "The dgb device requires the old isa >compatibility shims" > /var/tmp/des/src/sys/dev/iicbus/iic.c:42:25: machine/iic.h: No such file or directory > /var/tmp/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver is >broken and is not compiled with LINT" > /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:80:27: machine/dvcfg.h: No such file or >directory > /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:81:33: machine/physio_proc.h: No such file >or directory > In file included from /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:86: > /var/tmp/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or >directory > /var/tmp/des/src/sys/dev/ncv/ncr53c500_pccard.c:55:27: machine/dvcfg.h: No such file >or directory > In file included from /var/tmp/des/src/sys/dev/ncv/ncr53c500_pccard.c:63: > /var/tmp/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or >directory > /var/tmp/des/src/sys/dev/nsp/nsp.c:80:27: machine/dvcfg.h: No such file or directory > /var/tmp/des/src/sys/dev/nsp/nsp.c:81:33: machine/physio_proc.h: No such file or >directory > /var/tmp/des/src/sys/dev/nsp/nsp_pccard.c:52:27: machine/dvcfg.h: No such file or >directory > /var/tmp/des/src/sys/dev/smbus/smb.c:41:25: machine/smb.h: No such file or directory > /var/tmp/des/src/sys/dev/stg/tmc18c30.c:78:27: machine/dvcfg.h: No such file or >directory > /var/tmp/des/src/sys/dev/stg/tmc18c30.c:79:33: machine/physio_proc.h: No such file >or directory > /var/tmp/des/src/sys/dev/stg/tmc18c30_pccard.c:57:27: machine/dvcfg.h: No such file >or directory > /var/tmp/des/src/sys/dev/stg/tmc18c30_isa.c:65:27: machine/dvcfg.h: No such file or >directory > /var/tmp/des/src/sys/dev/usb/ukbd.c:419:21: ukbdmap.h: No such file or directory > In file included from /var/tmp/des/src/sys/dev/wl/if_wl.c:218: > /var/tmp/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file >or directory > /var/tmp/des/src/sys/dev/wl/if_wl.c:224:35: machine/if_wl_wavelan.h: No such file or >directory > /var/tmp/des/src/sys/dev/wl/if_wl.c:227:2: #error "The wl device requires the old >isa compatibility shims" > /var/tmp/des/src/sys/kern/subr_prof.c:62:30: machine/asmacros.h: No such file or >directory > /var/tmp/des/src/sys/kern/subr_prof.c:232:2: #error > /var/tmp/des/src/sys/kern/subr_prof.c:243:2: #error > /var/tmp/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver is >broken and is not compiled with LINT" > /var/tmp/des/src/sys/pci/simos.c:57:2: #error "The simos device requires the old pci >compatibility shims" > /var/tmp/des/src/sys/dev/syscons/syscons.c:117:18: font.h: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /var/tmp/des/obj/var/tmp/des/src/sys/LINT. > *** Error code 1 > > Stop in /var/tmp/des
Re: alpha tinderbox failure
On 11-Sep-2002 Nate Lawson wrote: > JKH task: go through conf/NOTES and move devices that don't (or could > never) build on alpha to i386/conf/NOTES. At the end of this, LINT should > build on alpha and i386. I already did this before when I first created sys/alpha/conf/NOTES. It did build at one time. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
libiconv broken
updated this morning (08.00 CET) to latest current (from GCC 3.1.1 to
GCC 3.2) everything runs smoothly.
But libiconv seems to break:
cc -I. -I. -I../include -I./../include -O -pipe -march=pentium3 -c
./iconv.c -fPIC -DPIC -o .libs/iconv.lo
In file included from gbk.h:64,
from converters.h:202,
from iconv.c:67:
gbkext1.h: In function `gbkext1_mbtowc':
gbkext1.h:852: unrecognizable insn:
(insn 157 155 159 (set (reg:QI 78)
(const_int 128 [0x80])) -1 (nil)
(nil))
gbkext1.h:852: Internal compiler error in extract_insn, at recog.c:2150
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
*** Error code 1
Stop in /usr/ports/converters/libiconv/work/libiconv-1.8/lib.
*** Error code 1
===> Cleaning for libtool-1.3.4_4
===> Cleaning for libiconv-1.8_1
===> Extracting for libiconv-1.8_1
>> Checksum OK for libiconv-1.8.tar.gz.
===> libiconv-1.8_1 depends on executable: libtool - found
===> Patching for libiconv-1.8_1
===> Applying FreeBSD patches for libiconv-1.8_1
===> Configuring for libiconv-1.8_1
configure: WARNING: you should use --build, --host, --target
checking whether make sets ${MAKE}... yes
checking for i386-portbld-freebsd5.0-gcc... cc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix...
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking how to run the C preprocessor... cc -E
checking whether cc needs -traditional... no
checking for ranlib... ranlib
checking for a BSD compatible install... /usr/bin/install -c -o root -g wheel
checking how to copy files... cp -p
checking how to make hard links... ln
checking whether ln -s works... yes
checking build system type... i386-portbld-freebsd5.0
checking host system type... i386-portbld-freebsd5.0
checking for AIX... no
checking for minix/config.h... no
checking for strerror in -lcposix... no
checking for ld used by GCC... /usr/libexec/elf/ld
checking if the linker (/usr/libexec/elf/ld) is GNU ld... yes
checking for /usr/libexec/elf/ld option to reload object files... -r
checking for BSD-compatible nm... nm
checking how to recognise dependant libraries... pass_all
checking command to parse nm output... ok
checking for dlfcn.h... yes
checking for i386-portbld-freebsd5.0-ranlib... (cached) ranlib
checking for i386-portbld-freebsd5.0-strip... no
checking for strip... strip
checking for objdir... .libs
checking for cc option to produce PIC... -fPIC
checking if cc PIC flag -fPIC works... yes
checking if cc static flag -static works... yes
checking if cc supports -c -o file.o... yes
checking if cc supports -c -o file.lo... yes
checking if cc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/libexec/elf/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... freebsd5.0 ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether -lc should be explicitly linked in... yes
creating libtool
checking host system type... i386-unknown-freebsdelf5.0
checking for ranlib... ranlib
checking whether we are using GNU C... yes
checking for object suffix... o
checking for executable suffix... no
checking for cc option to produce PIC... -fPIC
checking if cc PIC flag -fPIC works... yes
checking if cc supports -c -o file.o... yes
checking if cc supports -c -o file.lo... yes
checking if cc supports -fno-rtti -fno-exceptions ... yes
checking if cc static flag -static works... -static
checking whether ln -s works... yes
checking for ld used by GCC... /usr/libexec/elf/ld
checking if the linker (/usr/libexec/elf/ld) is GNU ld... yes
checking whether the linker (/usr/libexec/elf/ld) supports shared libraries... yes
checking for BSD-compatible nm... /usr/bin/nm -B
checking command to parse /usr/bin/nm -B output... ok
checking how to hardcode library paths into programs... immediate
checking for /usr/libexec/elf/ld option to reload object files... -r
checking dynamic linker characteristics... freebsdelf5.0 ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for objdir... .libs
creating libtool
checking for ld used by GCC... /usr/libexec/elf/ld
checking if the linker (/usr/libexec/elf/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... no, consider installing GNU libiconv
checking for msgfmt... no
checking for gmsgfmt... :
checking for xgettext... no
checking for msgmerge... no
checking whether NLS is reques
GENERIC kernel panic on boot with latest -current Septembet 11, 2002due to /usr/src/sys/kern/kern_acct.c v 1.49
Revelent info:
* $FreeBSD: src/sys/kern/kern_acct.c,v 1.49 2002/09/11 04:10:41 arr Exp $
Console output...
Starting syslogd.
Sep 11 12:35:51 bigbang syslogd: kernel boot file is /boot/kernel/kernel
Starting named.
Starting ntpdate.
Turning on accounting.
recursed on non-recursive lock (sleep mutex) accounting @
/usr/src/sys/kern/kern_acct.c:343
first acquired @ /usr/src/sys/kern/kern_acct.c:160
panic: recurse
Debugger("panic")
Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c0434fbc) at Debugger+0x45
panic(c0438e88,0,c690f6f0,da68cb18,c02bb3ef) at panic+0x7c
witness_lock(c04e9ce0,8,c0431166,157,0) at witness_lock+0x305
_mtx_lock_flags(c04e9ce0,0,c0431166,157) at _mtx_lock_flags+0x7f
acctwatch(0,c04e9ca0,0,c159e200) at acctwatch+0x1f
acct(c15a16c0,da68cd14,1,1,296) at acct+0x1c9
syscall(2f,2f,2f,bfbffdd0,bfbffdd4) at syscall+0x243
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (51, FreeBSD ELF32, acct), eip = 0x280a5d17, esp = 0xbfbffd6c,
ebp = 0xbfbffd88 ---
db>
output with boot -v
Starting syslogd.
Sep 11 13:05:50 bigbang syslogd: kernel boot file is /boot/kernel/kernel
Started named.
Starting ntpdate.
Turning on accounting.
recursed on non-recursive lock (sleep mutex) accounting @
/usr/src/sys/kern/kern_acct.c:343
first acquired @ /usr/src/sys/kern/kern_acct.c:160
panic: recurse
Debugger("panic")
Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0
db>
Cheers,
Vince - [EMAIL PROTECTED] - Vice President __
Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ]
WurldLink Corporation / / / / | / | __] ]
San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ]
HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[]
Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC kernel panic on boot with latest -current Septembet 11,2002 due to /usr/src/sys/kern/kern_acct.c v 1.49
This is being worked on. See msg thread in cvs-all, starting with: <[EMAIL PROTECTED]>. You can back out the change (1.49) if you need to get running. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
reppetead crashs
Hi guys,
I've got today a lot of repetead crash on my -CURRENT notebook when
I do a ftp transfer. I've use ncftp3 and when it hang, I do a CTRL-Z
and after this I do a "kill %%".
I've under the gnome, using a current as of :
eagle bushmills:~>uname -a
FreeBSD bushmills.intra.thorm.net 5.0-CURRENT FreeBSD 5.0-CURRENT #8: Tue Sep 10
20:49:42 CEST 2002
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/bushmills i386
I'm on a Dell Inspiron 8200 with 512Mb RAM + 40Go Disk + a ATI GeForce4 64Mb +
NetGear Wireless MA401 PCCard
I've attached the result of the boot -v in my /var/log/message just
Hope this can be usefull
--
Sebastien Gioria gioria@{FreeBSD,FreeBSD-FR}.ORG
French FreeBSD User Grouphttp://www.FreeBSD-FR.ORG
FreeBSD committer http://www.FreeBSD.ORG
*-> FreeBSD + RollerBlade + Scuba Diving; What need you more ? <-*
Sep 11 22:13:55 bushmills syslogd: kernel boot file is /boot/kernel/kernel
Sep 11 22:13:55 bushmills kernel: Copyright (c) 1992-2002 The FreeBSD Project.
Sep 11 22:13:55 bushmills kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989,
1991, 1992, 1993, 1994
Sep 11 22:13:55 bushmills kernel: The Regents of the University of California. All
rights reserved.
Sep 11 22:13:55 bushmills kernel: FreeBSD 5.0-CURRENT #8: Tue Sep 10 20:49:42 CEST 2002
Sep 11 22:13:55 bushmills kernel:
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/bushmills
Sep 11 22:13:55 bushmills kernel: Preloaded elf kernel "/boot/kernel/kernel" at
0xc05ce000.
Sep 11 22:13:55 bushmills kernel: Preloaded elf module "/boot/kernel/acpi.ko" at
0xc05ce0b4.
Sep 11 22:13:55 bushmills kernel: Calibrating clock(s) ... TSC clock: 1595295500 Hz,
i8254 clock: 1193185 Hz
Sep 11 22:13:55 bushmills kernel: CLK_USE_I8254_CALIBRATION not specified - using
default frequency
Sep 11 22:13:55 bushmills kernel: Timecounter "i8254" frequency 1193182 Hz
Sep 11 22:13:55 bushmills kernel: CLK_USE_TSC_CALIBRATION not specified - using old
calibration method
Sep 11 22:13:55 bushmills kernel: Timecounter "TSC" frequency 1595301708 Hz
Sep 11 22:13:55 bushmills kernel: CPU: Pentium 4 (1595.30-MHz 686-class CPU)
Sep 11 22:13:55 bushmills kernel: Origin = "GenuineIntel" Id = 0xf24 Stepping = 4
Sep 11 22:13:55 bushmills kernel:
Features=0x3febf9ff
Sep 11 22:13:55 bushmills kernel: real memory = 536748032 (524168K bytes)
Sep 11 22:13:55 bushmills kernel: Physical memory chunk(s):
Sep 11 22:13:55 bushmills kernel: 0x1000 - 0x0009efff, 647168 bytes (158 pages)
Sep 11 22:13:55 bushmills kernel: 0x005f5000 - 0x1ffd9fff, 530468864 bytes (129509
pages)
Sep 11 22:13:55 bushmills kernel: avail memory = 514527232 (502468K bytes)
Sep 11 22:13:55 bushmills kernel: bios32: Found BIOS32 Service Directory header at
0xc00ffe80
Sep 11 22:13:55 bushmills kernel: bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1
Sep 11 22:13:55 bushmills kernel: pcibios: PCI BIOS entry at 0xf+0xbfee
Sep 11 22:13:55 bushmills kernel: pnpbios: Found PnP BIOS data at 0xc00fe2d0
Sep 11 22:13:55 bushmills kernel: pnpbios: Entry = f:e2f4 Rev = 1.0
Sep 11 22:13:55 bushmills kernel: pnpbios: Event flag at 4b4
Sep 11 22:13:55 bushmills kernel: Other BIOS signatures found:
Sep 11 22:13:55 bushmills kernel: null:
Sep 11 22:13:55 bushmills kernel: random:
Sep 11 22:13:55 bushmills kernel: mem:
Sep 11 22:13:55 bushmills kernel: pci_open(1): mode 1 addr port (0x0cf8) is 0x80010064
Sep 11 22:13:55 bushmills kernel: pci_open(1a): mode1res=0x8000 (0x8000)
Sep 11 22:13:55 bushmills kernel: pci_cfgcheck: device 0 [class=06] [hdr=00] is
there (id=1a308086)
Sep 11 22:13:55 bushmills kernel: Using $PIR table, 11 entries at 0xc00fbb90
Sep 11 22:13:55 bushmills kernel: PCI-Only Interrupts: none
Sep 11 22:13:55 bushmills kernel: Location Bus Device Pin Link IRQs
Sep 11 22:13:55 bushmills kernel: embedded0 29A 0x60 3 4 5 6 7 9 10 11 12
14 15
Sep 11 22:13:55 bushmills kernel: embedded0 29B 0x63 3 4 5 6 7 9 10 11 12
14 15
Sep 11 22:13:55 bushmills kernel: embedded0 29C 0x62 3 4 5 6 7 9 10 11 12
14 15
Sep 11 22:13:55 bushmills kernel: embedded0 29D 0x63 3 4 5 6 7 9 10 11 12
14 15
Sep 11 22:13:55 bushmills kernel: embedded0 30A 0x60 3 4 5 6 7 9 10 11 12
14 15
Sep 11 22:13:55 bushmills kernel: embedded0 30B 0x61 3 4 5 6 7 9 10 11 12
14 15
Sep 11 22:13:55 bushmills kernel: embedded0 30C 0x62 3 4 5 6 7 9 10 11 12
14 15
Sep 11 22:13:55 bushmills kernel: embedded0 30D 0x63 3 4 5 6 7 9 10 11 12
14 15
Sep 11 22:13:55 bushmills kernel: embedded0 31A 0x62 3 4 5 6 7 9 10 11 12
14 15
Sep 11 22:13:55 bushmills kernel: embedded0 31B 0x61 3 4 5 6 7 9 10 11 12
14 15
Sep 11 22:13:55 bushmills kernel: embedded10A 0x60 3 4 5 6 7 9 10 11 12
14 15
Sep 11 22:13:55 bushmills kernel: embedded20A 0x62 3 4 5 6 7 9 10 11 12
14 15
Sep 11 22:13:55 bushmills kernel:
panic: bad pte
Hi all,
This is current from yesterday.
I get all the time the same panics while building openoffice
on my PIV machine. Some are due the fg/bg issue.
My machine panics instantly if I have a sleeping openoffice
build and try it to invoke it again with fg.
But this one here happened during compile ... It's the first
time for this one.
Before gcc3.2 came in, I never had _that_ many panics. Current
seems to be in a very bad shape today.
If you like to see this, please build openoffice and see Current
crash ... Yes - openoffice is the ultimative regression tool.
My box survives buildworlds with -l 100, but not a simple openoffice
build.
#10 0xc01ed998 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:479
#11 0xc02fe2a5 in pmap_remove_pages (pmap=0xc1f97e04, sva=0, eva=3217031168)
at /usr/src/sys/i386/i386/pmap.c:2946
#12 0xc01d91f6 in exit1 (td=0xcc51e600, rv=0) at vm_map.h:226
#13 0xc01d8d64 in exit1 (td=0xcc51e600, rv=-391697172)
at /usr/src/sys/kern/kern_exit.c:112
---Type to continue, or q to quit---
#14 0xc0300944 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077938328, tf_esi = -10779
38312, tf_ebp = -1077938536, tf_isp = -391697036, tf_ebx = 3, tf_edx = 134581045
, tf_ecx = 1, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 134703471, tf_cs
= 31, tf_eflags = 662, tf_esp = -1077938676, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#15 0xc02f384d in Xint0x80_syscall () at {standard input}:140
(kgdb) frame 11
#11 0xc02fe2a5 in pmap_remove_pages (pmap=0xc1f97e04, sva=0, eva=3217031168)
at /usr/src/sys/i386/i386/pmap.c:2946
2946panic("bad pte");
(kgdb) list
2941tpte = *pte;
2942
2943if (tpte == 0) {
2944printf("TPTE at %p IS ZERO @ VA %08x\n",
2945pte, pv->pv_va);
2946panic("bad pte");
2947}
2948
2949/*
2950 * We cannot remove wired pages from a process' mapping at this time
(kgdb) p pte
$1 = (pt_entry_t *) 0xbfc20370
(kgdb) p tpte
$2 = 0
(kgdb) p pv->pv_va
$3 = 135118848
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: Locking problems in exec
On 11 Sep, John Baldwin wrote:
>
> On 11-Sep-2002 Don Lewis wrote:
>> On 10 Sep, Don Lewis wrote:
>>> On 10 Sep, Nate Lawson wrote:
>>>
I'm not sure why fdcheckstd() and setugidsafety() couldn't both happen
before grabbing the proc lock. Dropping locks in the middle or
pre-allocating should always be a last resort.
>>>
>>> That is ok as long as there aren't other threads that can mess things up
>>> after fdcheckstd() and setugidsafety() have done their thing.
>>
>> It looks like threads aren't a problem because of the call to
>> thread_single() at the top of execve(). Ptrace() is still a potential
>> problem, so we can't call fdcheckstd() and setugidsafety() until after
>> credential_changing has been calculated, setsugid() has been called and
>> tracing has been disabled, all of which are done after proc lock has
>> been grabbed.
>>
>> It also looks like we should pre-allocate newprocsig instead of
>> temporarily dropping the lock.
>
> We used to do that but backed it out because it wasn't deemed to be
> that necessary. If you have a demonstrable problematic race condition
> that this fixes then it might be a good idea. However, allocating
> stuff we don't need isn't but so great either.
I haven't observed any problems with the procsig stuff, but it sure hit
me in the eye when I was scanning the code to see if the fdcheckfd()
could be done before grabbing the proc lock. The mp_fixme() suggests to
me that the entire if block is going to be protected by its own lock
sometime in the future:
PROC_LOCK(p);
mp_fixme("procsig needs a lock");
if (p->p_procsig->ps_refcnt > 1) {
oldprocsig = p->p_procsig;
PROC_UNLOCK(p);
MALLOC(newprocsig, struct procsig *, sizeof(struct procsig),
M_SUBPROC, M_WAITOK);
bcopy(oldprocsig, newprocsig, sizeof(*newprocsig));
newprocsig->ps_refcnt = 1;
oldprocsig->ps_refcnt--;
PROC_LOCK(p);
p->p_procsig = newprocsig;
if (p->p_sigacts == &p->p_uarea->u_sigacts)
panic("shared procsig but private sigacts?");
p->p_uarea->u_sigacts = *p->p_sigacts;
p->p_sigacts = &p->p_uarea->u_sigacts;
}
We probably won't want to hold the lock across the call to MALLOC(), and
dropping the lock and possibly blocking, giving ps_refcnt the
opportunity to change behind our back, doesn't seem wise. Copying a
shared object and manipulating its reference count while it is unlocked
doesn't sound wise either. We may be protected in other ways at the
moment, but this code suggests to me that this won't always be the case.
> I think ptrace(2)
> is not an issue because ptrace(2) won't attach to a P_INEXEC process
> IIRC.
I think you're correct, but we still can't call fdcheckstd() before we
know that we are doing the set-id case, and that decision is made after
we've grabbed the proc lock. Do you think it is reasonable to
temporarily drop the proc lock for the fdcheckstd() call?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: libiconv broken
On Wed, Sep 11, 2002 at 09:48:04PM +0200, John Angelmo wrote: > updated this morning (08.00 CET) to latest current (from GCC 3.1.1 to > GCC 3.2) everything runs smoothly. > > But libiconv seems to break: There was a patch posted about a week ago for this. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bad pte
I haven't been paying much attention to the issues lately... BUT...
I have the same problem on my p3. But it's not just during the openoffice
built.. It occurrs at other times too. Unfortunately it seems to be a hard
freeze because I don't get any dumps (or maybe its breaking to ddb and I
need to panic it myself).
I *thought* it was a problem with suspending a process that had children,
but I did some suspending today and had no problems.
On Wed, 11 Sep 2002, Martin Blapp wrote:
>
> Hi all,
>
> This is current from yesterday.
>
> I get all the time the same panics while building openoffice
> on my PIV machine. Some are due the fg/bg issue.
>
> My machine panics instantly if I have a sleeping openoffice
> build and try it to invoke it again with fg.
>
> But this one here happened during compile ... It's the first
> time for this one.
>
> Before gcc3.2 came in, I never had _that_ many panics. Current
> seems to be in a very bad shape today.
>
> If you like to see this, please build openoffice and see Current
> crash ... Yes - openoffice is the ultimative regression tool.
> My box survives buildworlds with -l 100, but not a simple openoffice
> build.
>
> #10 0xc01ed998 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:479
> #11 0xc02fe2a5 in pmap_remove_pages (pmap=0xc1f97e04, sva=0, eva=3217031168)
> at /usr/src/sys/i386/i386/pmap.c:2946
> #12 0xc01d91f6 in exit1 (td=0xcc51e600, rv=0) at vm_map.h:226
> #13 0xc01d8d64 in exit1 (td=0xcc51e600, rv=-391697172)
> at /usr/src/sys/kern/kern_exit.c:112
> ---Type to continue, or q to quit---
> #14 0xc0300944 in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077938328, tf_esi = -10779
> 38312, tf_ebp = -1077938536, tf_isp = -391697036, tf_ebx = 3, tf_edx = 134581045
> , tf_ecx = 1, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 134703471, tf_cs
> = 31, tf_eflags = 662, tf_esp = -1077938676, tf_ss = 47})
> at /usr/src/sys/i386/i386/trap.c:1050
> #15 0xc02f384d in Xint0x80_syscall () at {standard input}:140
>
> (kgdb) frame 11
> #11 0xc02fe2a5 in pmap_remove_pages (pmap=0xc1f97e04, sva=0, eva=3217031168)
> at /usr/src/sys/i386/i386/pmap.c:2946
> 2946panic("bad pte");
> (kgdb) list
> 2941tpte = *pte;
> 2942
> 2943if (tpte == 0) {
> 2944printf("TPTE at %p IS ZERO @ VA %08x\n",
> 2945pte, pv->pv_va);
>
> 2946panic("bad pte");
> 2947}
> 2948
> 2949/*
> 2950 * We cannot remove wired pages from a process' mapping at this time
>
> (kgdb) p pte
> $1 = (pt_entry_t *) 0xbfc20370
> (kgdb) p tpte
> $2 = 0
> (kgdb) p pv->pv_va
> $3 = 135118848
>
> 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
>
--
_ __ ___ ___ ___ ___
Wesley N Morgan _ __ ___ | _ ) __| \
[EMAIL PROTECTED] _ __ | _ \._ \ |) |
FreeBSD: The Power To Serve _ |___/___/___/
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: bad pte
Hi, A method to crash current is the following: cd /usr/ports/editors/openoffice make extract# does use about 500M diskspace rm -rfd work# removes everything make# create it again I had more panics when I started this during fsck_ufs was validating my /usr disk (soft updates, post fsck check) 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
Softupdate panic: softdep_update_inodeblock: update failed
I just got thisone ... This is CURRENT from 2 hours ago.
Dammnit. Is this mem corruption ?
#10 0xc01edb18 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:479
#11 0xc02b3539 in softdep_update_inodeblock (ip=0xce432300, bp=0xd878cc84,
waitfor=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4672
#12 0xc02a7648 in ffs_update (vp=0xcedaede0, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:109
#13 0xc02bce8c in ufs_inactive (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_inode.c:121
#14 0xc02c354b in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2724
#15 0xc02322ed in vrele (vp=0xcedaede0) at vnode_if.h:906
#16 0xc023af4d in vn_close (vp=0xcedaede0, flags=0, file_cred=0x0, td=0x0)
at /usr/src/sys/kern/vfs_vnops.c:319
#17 0xc023bc62 in vn_closefile (fp=0x0, td=0xcc383e40)
at /usr/src/sys/kern/vfs_vnops.c:884
#18 0xc01d49db in fdrop_locked (fp=0xcc361ca8, td=0xcc383e40) at file.h:256
#19 0xc01d46f5 in fdrop (fp=0xcc361ca8, td=0xcc383e40)
at /usr/src/sys/kern/kern_descrip.c:1637
#20 0xc01d46ab in closef (fp=0xcc361ca8, td=0xcc3
at /usr/src/sys/kern/kern_descrip.c:1623
#21 0xc01d309b in close (td=0xcc383e40, uap=0x0)
at /usr/src/sys/kern/kern_descrip.c:832
#22 0xc03008b4 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 672319120, tf_eb
p = -1077943144, tf_isp = -391561868, tf_ebx = 672240892, tf_edx = 24, tf_ecx =
0, tf_eax = 6, tf_trapno = 12, tf_err = 2, tf_eip = 671844223, tf_cs = 31, tf_ef
lags = 518, tf_esp = -1077943172, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#23 0xc02f36cd in Xint0x80_syscall () at {standard input}:140
(kgdb) list
4667FREE_LOCK(&lk);
4668if (gotit &&
4669(error = BUF_WRITE(inodedep->id_buf)) != 0)
4670softdep_error("softdep_update_inodeblock: bwrite", error
);
4671if ((inodedep->id_state & DEPCOMPLETE) == 0)
4672panic("softdep_update_inodeblock: update failed");
4673}
4674
4675/*
4676 * Merge the a new inode dependency list (such as id_newinoupdt) into an
(kgdb) p inodedep->id_state
There is no member named id_state.
type = struct inodedep {
struct worklist id_list;
struct {
struct inodedep *le_next;
struct inodedep **le_prev;
} id_hash;
struct fs *id_fs;
ino_t id_ino;
nlink_t id_nlinkdelta;
struct {
struct inodedep *le_next;
struct inodedep **le_prev;
} id_deps;
struct buf *id_buf;
long int id_savedextsize;
off_t id_savedsize;
struct workhead id_pendinghd;
struct workhead id_bufwait;
struct workhead id_inowait;
struct allocdirectlst id_inoupdt;
struct allocdirectlst id_newinoupdt;
struct allocdirectlst id_extupdt;
struct allocdirectlst id_newextupdt;
union {
(kgdb) p gotit
$6 = -834460928
(kgdb) p inodedep->id_buf
---Can't read userspace from dump, or kernel process---
(kgdb) p inodedep
$7 = (struct inodedep *) 0x0
Huh. What's going on here ?
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: Softupdate panic: softdep_update_inodeblock: update failed
> I just got thisone ... This is CURRENT from 2 hours ago. > > Dammnit. Is this mem corruption ? > If I were you I'd start swapping memory modules, because I'm not having any trouble with -CURRENT and I havn't seen anyone else having trouble. Did you compile your kernel with any wierd optimizations? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Softupdate panic: softdep_update_inodeblock: update failed
Hi, > If I were you I'd start swapping memory modules, because I'm not having Already did that. I even used ECC ram. > any trouble with -CURRENT and I havn't seen anyone else having trouble. Did you try to build a huge project ? If I don't compile anything big and load the machine it works perfectly. > Did you compile your kernel with any wierd optimizations? No. And this system works perfectly before after I turned on PG_G. The instability began after gcc3.2 import. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Softupdate panic: softdep_update_inodeblock: update failed
It may not be memory corruption. I get this panic on various versions of STABLE on different pieces of hardware. See 42235 and 42277. -Kip --- Martin Blapp <[EMAIL PROTECTED]> wrote: > > Hi, > > > If I were you I'd start swapping memory modules, > because I'm not having > > Already did that. I even used ECC ram. > > > any trouble with -CURRENT and I havn't seen anyone > else having trouble. > > Did you try to build a huge project ? If I don't > compile anything big > and load the machine it works perfectly. > > > Did you compile your kernel with any wierd > optimizations? > > No. > > And this system works perfectly before after I > turned on PG_G. > > The instability began after gcc3.2 import. > > Martin > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of > the message > > __ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Softupdate panic: softdep_update_inodeblock: update failed
Oh ok, wierd... I've only tried (unsuccessfully, the compiler errors out) kde3, and some make worlds and stuff. I guess that's not strenuous enough. Ken On Thu, 12 Sep 2002, Martin Blapp wrote: > > Hi, > > > If I were you I'd start swapping memory modules, because I'm not having > > Already did that. I even used ECC ram. > > > any trouble with -CURRENT and I havn't seen anyone else having trouble. > > Did you try to build a huge project ? If I don't compile anything big > and load the machine it works perfectly. > > > Did you compile your kernel with any wierd optimizations? > > No. > > And this system works perfectly before after I turned on PG_G. > > The instability began after gcc3.2 import. > > Martin > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Compiling mail/courier with current/new gcc3.2 w/patch
I am using current with a patched gcc3.2. The patched gcc was used to make world (cvsup - patch gcc - make world) I get the following when trying to compile ports/mail/courier. gmake[1]: Entering directory `/usr/ports/mail/courier/work/courier-0.39.3/afx' c++ -I.. -I./.. -Wall -O -pipe -L/usr/local/lib -o testafxpipe testafxpipe.o libafx.a /usr/libexec/elf/ld: testafxpipe: Not enough room for program headers (allocated 6, need 7) /usr/libexec/elf/ld: final link failed: Bad value gmake[1]: *** [testafxpipe] Error 1 gmake[1]: Leaving directory `/usr/ports/mail/courier/work/courier-0.39.3/afx' gmake: *** [all-recursive] Error 1 *** Error code 2 Stop in /usr/ports/mail/courier. *** Error code 1 If this is just a port and not a compiler issue, please let me know and I'll fill out a pr. Thanks, ed -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Softupdate panic: softdep_update_inodeblock: update failed
Kenneth Culver wrote: > Oh ok, wierd... I've only tried (unsuccessfully, the compiler errors out) > kde3, and some make worlds and stuff. I guess that's not strenuous enough. kde3 compiled okay for me with Alexander Kabaev's gcc patch posted to this ML. Regards, -- Michael Nottebrock "And the reasons? There are no reasons." msg42906/pgp0.pgp Description: PGP signature
Re: Compiling mail/courier with current/new gcc3.2 w/patch
Quoting Edwin Culp <[EMAIL PROTECTED]>: | I am using current with a patched gcc3.2. The patched gcc was used to | make world (cvsup - patch gcc - make world) I get the following when | trying to compile ports/mail/courier. | | gmake[1]: Entering directory | `/usr/ports/mail/courier/work/courier-0.39.3/afx' | c++ -I.. -I./.. -Wall -O -pipe -L/usr/local/lib -o testafxpipe | testafxpipe.o | libafx.a | /usr/libexec/elf/ld: testafxpipe: Not enough room for program headers | (allocated | 6, need 7) | /usr/libexec/elf/ld: final link failed: Bad value | gmake[1]: *** [testafxpipe] Error 1 | gmake[1]: Leaving directory | `/usr/ports/mail/courier/work/courier-0.39.3/afx' | gmake: *** [all-recursive] Error 1 | *** Error code 2 | | Stop in /usr/ports/mail/courier. | *** Error code 1 | | If this is just a port and not a compiler issue, please let me know and | I'll fill out a pr. | | Thanks, | | ed Oops, I just got it to compile on an almost identical machine, today's current same patched compiler, identical kernel config, etc. etc. Now I'm really confused. ed 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/var/tmp/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Sep 11 18:20:24 PDT 2002 -- >>> Kernel build for GENERIC completed on Wed Sep 11 19:25:20 PDT 2002 -- >>> Kernel build for LINT started on Wed Sep 11 19:25:21 PDT 2002 -- ===> vinum ./aicasm: 877 instructions used ./aicasm: 658 instructions used In file included from /var/tmp/des/src/sys/dev/dgb/dgb.c:89: /var/tmp/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /var/tmp/des/src/sys/dev/dgb/dgb.c:92:2: #error "The dgb device requires the old isa compatibility shims" /var/tmp/des/src/sys/dev/iicbus/iic.c:42:25: machine/iic.h: No such file or directory /var/tmp/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver is broken and is not compiled with LINT" /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:80:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:81:33: machine/physio_proc.h: No such file or directory In file included from /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:86: /var/tmp/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/ncv/ncr53c500_pccard.c:55:27: machine/dvcfg.h: No such file or directory In file included from /var/tmp/des/src/sys/dev/ncv/ncr53c500_pccard.c:63: /var/tmp/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/nsp/nsp.c:80:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/nsp/nsp.c:81:33: machine/physio_proc.h: No such file or directory /var/tmp/des/src/sys/dev/nsp/nsp_pccard.c:52:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/smbus/smb.c:41:25: machine/smb.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30.c:78:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30.c:79:33: machine/physio_proc.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30_pccard.c:57:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30_isa.c:65:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/usb/ukbd.c:419:21: ukbdmap.h: No such file or directory In file included from /var/tmp/des/src/sys/dev/wl/if_wl.c:218: /var/tmp/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /var/tmp/des/src/sys/dev/wl/if_wl.c:224:35: machine/if_wl_wavelan.h: No such file or directory /var/tmp/des/src/sys/dev/wl/if_wl.c:227:2: #error "The wl device requires the old isa compatibility shims" /var/tmp/des/src/sys/kern/subr_prof.c:62:30: machine/asmacros.h: No such file or directory /var/tmp/des/src/sys/kern/subr_prof.c:232:2: #error /var/tmp/des/src/sys/kern/subr_prof.c:243:2: #error /var/tmp/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver is broken and is not compiled with LINT" /var/tmp/des/src/sys/pci/simos.c:57:2: #error "The simos device requires the old pci compatibility shims" /var/tmp/des/src/sys/dev/syscons/syscons.c:117:18: font.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /var/tmp/des/obj/var/tmp/des/src/sys/LINT. *** Error code 1 Stop in /var/tmp/des/obj/var/tmp/des/src/sys/LINT. *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any problems with increaseing the dump(8) block size?
In the last episode (Sep 11), David O'Brien said: > I'd like to make this commit to get better performance on today's > streaming tape drives. It seems my DLT drive doesn't stream well > with the default block size of '10'. Only if we also raise dd's and tar's default blocksizes to 64k as well :) How about raising BUFSIZE (no smiley)? Tru64 and Linux both have an 8k stdio buffer. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel from latest cvsup refuses to boot. - hangs
On Thu, Sep 12, 2002 at 02:46:12AM +0530, Sid Carter wrote: > Hi Folks, > > I am still unable to boot into the kernel from the latest cvsup. [...] > System Info > -- [...] > CPU: Pentium III/Pentium III Xeon/Celeron (996n77-MHz 686-class CPU) ^ > Origin } "GenuineIntel"` Id = 0868a Stepping = 10 ^ ^ Check your optimisation flags -- it looks like the code that's been generated for kvprintf() (?) is incorrect, although I've only seen this happen in userland with vfprintf() and CFLAGS=-O2 before. Tim 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 Wed Sep 11 21:55:22 PDT 2002 -- ===> xe linking kernel.debug if_ethersubr.o: In function `ether_ipfw_chk': /local0/scratch/des/src/sys/net/if_ethersubr.c:466: undefined reference to `fw_one_pass' *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** 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
