Re: mount_mfs (Re: smbfs)
My take on it is that having a script that you can feed parameters and have it create a nice memory disk for you would be a cool thing, and since you'd have to put effectively the same commands into rc (or wherever) the "bloat" would be minimal. So, if someone wants to send me the stuff, either the script, or the rc bits, I'll bang it into shape and commit it. Howwzzat? -- I need someone really bad. Are you really bad? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vm_pager_(de)allocate and vm_mtx
In message <[EMAIL PROTECTED]>, Dima Dorfman write
s:
>Alfred Perlstein <[EMAIL PROTECTED]> writes:
>> * Dima Dorfman <[EMAIL PROTECTED]> [010525 22:22] wrote:
>> > Is there a reason vm_pager_allocate acquires vm_mtx itself if
>> > necessary but vm_pager_deallocate does not? At the moment, detaching
>> > an md(4) disk will panic the system with a failed mtx_assert in
>> > vm_pager_deallocate. This can be fixed one of two ways:
>> > vm_pager_deallocate could be made to deal with vm_mtx itself like
>> > vm_pager_allocate does, or md(4) and any other drivers which call
>> > vm_pager_deallocate can be fixed to acquire vm_mtx. So which will it
>> > be? I'll supply patches for either case.
>>
>> Usually fixing the caller is better as it will catch people that
>> expect vm state to remain unchanged across several calls.
>
>Patch to fix md(4) attached. Look okay?
Looks fine, go ahead and commit.
Poul-Henning
>
> Dima Dorfman
> [EMAIL PROTECTED]
>
>Index: md.c
>===
>RCS file: /stl/src/FreeBSD/src/sys/dev/md/md.c,v
>retrieving revision 1.33
>diff -u -r1.33 md.c
>--- md.c 2001/05/21 18:52:00 1.33
>+++ md.c 2001/05/26 05:48:57
>@@ -711,8 +711,11 @@
> (void)vn_close(sc->vnode, sc->flags & MD_READONLY ? FREAD :
>(FREAD|FWRITE), sc->cred, p);
> if (sc->cred != NULL)
> crfree(sc->cred);
>- if (sc->object != NULL)
>+ if (sc->object != NULL) {
>+ mtx_lock(&vm_mtx);
> vm_pager_deallocate(sc->object);
>+ mtx_unlock(&vm_mtx);
>+ }
> if (sc->secp != NULL) {
> for (u = 0; u < sc->nsect; u++)
> if ((uintptr_t)sc->secp[u] > 255)
>@@ -763,17 +766,20 @@
>* Note the truncation.
>*/
>
>+ mtx_lock(&vm_mtx);
> sc->secsize = PAGE_SIZE;
> sc->nsect = mdio->md_size / (PAGE_SIZE / DEV_BSIZE);
> sc->object = vm_pager_allocate(OBJT_SWAP, NULL, sc->secsize *
>(vm_offset_t)sc->nsect, VM_PROT_DEFAULT, 0);
> if (mdio->md_options & MD_RESERVE) {
> if (swap_pager_reserve(sc->object, 0, sc->nsect) < 0) {
> vm_pager_deallocate(sc->object);
>+ mtx_unlock(&vm_mtx);
> sc->object = NULL;
> mddestroy(sc, mdio, p);
> return(EDOM);
> }
> }
>+ mtx_unlock(&vm_mtx);
> error = mdsetcred(sc, p->p_ucred);
> if (error)
> mddestroy(sc, mdio, p);
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
buildworld
i'm having trouble upgrading my freebsd 4. it was frequently patched due to troubles with poll(2) and ipfilter. a few days ago i cvsup'ed to tag=., but the build failed at various stages. my gaol at the beginning was only to upgrade for reconfiguring the kernel, as i will be getting DSL soon and needed a few network twists, but when each and every attempt to get a kernel build failed i went for a make world. now i went back to RELENG_4, but the system seems to be a mess, i get too many errors. i'd be willing to merge the kernel changes later and doing it manually, but at present i've got the complete RELENG_4 sources in a vergin state right after cvsup(?), and the builds fail miserably. the errors and the local modification dates on the files seem to indicate that cvsup did not install the latest headers. where do i start the build, ie. which targets must be done before buildworld to have it start in a known state? clemens fischer ps: please Cc: me, i'm not on the list. thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic: spin lock shed lock hold by ... for >5 seconds
Hi, I get the above panic when just running aviplay (/usr/ports/graphics/avifile) or wine. Since both programs use USER_LDT functions I suspect a problem there in the kernel. The kernel is the latest -current. I get no kernel-dump because the panic seems to loop (in conjunction with some lockmgr: panics...) But it's too easy to reproduce anyway... Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vm_pager_(de)allocate and vm_mtx
Alfred Perlstein wrote: > * Dima Dorfman <[EMAIL PROTECTED]> [010525 22:22] wrote: > > Is there a reason vm_pager_allocate acquires vm_mtx itself if > > necessary but vm_pager_deallocate does not? At the moment, detaching > > an md(4) disk will panic the system with a failed mtx_assert in > > vm_pager_deallocate. This can be fixed one of two ways: > > vm_pager_deallocate could be made to deal with vm_mtx itself like > > vm_pager_allocate does, or md(4) and any other drivers which call > > vm_pager_deallocate can be fixed to acquire vm_mtx. So which will it > > be? I'll supply patches for either case. > > Usually fixing the caller is better as it will catch people that > expect vm state to remain unchanged across several calls. It is a bit late now, but if we're going to push this to callers, I wish we had set up VM_LOCK() and VM_UNLOCK() macros or something so that we dont have to deal with fallout if something there changes (or gets conditionalized). At least use the macros outside of the vm/* and pmap.c files... On the same train of thought, perhaps GIANT_LOCK() and GIANT_UNLOCK() might have been an idea too. It would certainly have changed the code impact when the mutex api changed last time. It also gives us better 4.x porting targets because we can provide stub (do nothing) GIANT_LOCK()/UNLOCK() macros on 4.x. OK, we could do the same for mtx_lock()/unlock() too but I think the macros give us more flexability should we want to globally change the giant lock implementation at some point (or even locally add instrumentation for testing or whatever). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld
clemensF wrote: > > i'm having trouble upgrading my freebsd 4. it was frequently patched due > to troubles with poll(2) and ipfilter. a few days ago i cvsup'ed to tag=., That would have brought your sources to 5-Current, not 4-Stable. > but the build failed at various stages. That would be expected. > my gaol at the beginning was only > to upgrade for reconfiguring the kernel, FreeBSD isn't linux, we don't do "kernel only" updates. You should really spend some time reading the FreeBSD Handbook on the web, especially the sections about updating your system. Meanwhile, your best bet is probably to install a -stable snapshot. That should get you the updates you need, and bring your system to the point where you will be able to do complete source upgrades again. Take a look at ftp://releng4.freebsd.org/pub/FreeBSD/snapshots/i386/ Good luck, Doug -- I need someone really bad. Are you really bad? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic: spin lock shed lock hold by ... for >5 seconds
On Sat, May 26, 2001 at 11:04:24AM +0200, Michael Reifenberger wrote: > Hi, > I get the above panic when just running aviplay (/usr/ports/graphics/avifile) or >wine. > Since both programs use USER_LDT functions I suspect a problem there in the kernel. > The kernel is the latest -current. > I get no kernel-dump because the panic seems to loop (in conjunction with some > lockmgr: panics...) > But it's too easy to reproduce anyway... I had a panic when I ran avifile earlier tonight. Since I was in X I couldn't catch the details, but it sounds like it might be the same one. Kris PGP signature
recursed on non-recursive lock
I finally got this much. I hope it helps.
lock order reversal
1st 0xc03af0a0 mntvnode @ ../../ufs/ffs/ffs_vnops.c:1007
2nd 0xc8b539cc vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:1016
recursed on non-recursive lock (sleep mutex) vm @ ../../ufs/ufs/ufs_readwrite.c:420
first acquired @ ../../vm/vnode_pager.c:912
panic:recurse
Debugger ("panic")
Stopped at Debugger+0x45: pushl %ebx
db> t
Debugger(c0310767b) at Debugger+0x45
panic(c0313348,c81b9cb8,a0,10,0) at panic+0x70
witness_lock(c03b3f20,8,c03263b6,1a4) at witness_lock+0x356
ffs_write(c81b9ca4) at ffs_write+0xba
vnode_pager_generic_putpages(c8c31d00,c81b9ddc,1,0,c81b9d74) at
vnode_pager_generic_putpages+0x19c
vop_stdputpages(c81b9d28,c81b9d0c,c02a7f9d,c81b9d28,c81b9d48) at vop_stdputpages+0x1f
vop_defaultop(c81b9d28,c81b9d48,c02c5c3d,c81b9d28,0) at vop_defaultop+0x15
ufs_vnoperate(c81b9d28) at ufs_vnoperate+0x15
vnode_pager_putpages(c8c4b360,c81b9ddc,10,0,c81b9d74,c03b3f20,1,c0329ffa,91) at
vnode_pager_putpages+0x1ad
vm_pageout_flush(c81b9ddc,10,0,c09d3b7c,c0a0d638) at vm_pageout_flush+0x12c
vm_object_page_clean(c8c4b360,0,0,4) at vm_object_page_clean+0x434
vfs_msync(c0eeb200,2,c81ae440,c7b9b200,c0e8b194) at vfs_msync+02x34
sync_fsync(c81b9f5c) at sync_fsync+0x17c
sched_sync(0,c81b9fa8) at sched_sync+0x16c
fork_exit(c01d330c,0,c81b9fa8) at fork_exit+0xb6
fork_trampoline() at fork_trampoline+0x8
db> show registers
cs 0x8
ds 0x10
es 0x10
fs 0x18
ss 0x10
eax 0x12
ecx 0xc03a7c00 main_console.518
edx 0xc033074f db_lengths+0x1d7
ebx 0x202
esp 0xc81b9bc8
ebp 0xc81b9bd4
esi 0x100
edi 0xc0386ccc
eip 0xc02daa39 Debugger+0x45
efl 0x46
Debugger+0x45: pushl %ebx
db> show locks
exclusive (sleep mutex) vm (oxc03b3f20) locked @ ../../vm/vnode_pager.c:912
exclusive (sleep mutex) Giant (0xc03b4b00) locked @ ../../kern/vfs_subr.c:1027
db> c
syncing disks... panic: mutex vm owned at ../../kern/vfs_bio.c:2990
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db> c
Uptime: 37s
dumping to dev ad0s1b, offset 280744
dump ata0: resetting devices ..
--
Michael D. Harnois[EMAIL PROTECTED]
Redeemer Lutheran Church Washburn, Iowa
Wise men talk because they have something to say;
fools, because they have to say something. -- Plato
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mount_mfs (Re: smbfs)
On Fri, May 25, 2001 at 10:44:37PM -0700, Dima Dorfman wrote: > Kris Kennaway <[EMAIL PROTECTED]> writes: > > On Fri, May 25, 2001 at 04:26:48PM +0200, Sheldon Hearn wrote: > > > I still don't see why an rc.conf knob specifically for /tmp isn't > > > sufficient. That's what people want this for. Others can read the > > > excellent documentation supplied in mdconfig(8), which is appropriately > > > cross-referenced from md(4), which is the manual page for the device > > > concerned. Logical, orthogonal and pretty damn easy, when you look at > > > the EXAMPLES section. :-) > > How about make a port of out the mount_mfs compatible program and > committing your (Sheldon's) /tmp rc.conf patch? Those who only need > /tmp (and as you say, this is the majority) have what they need, we > don't have [needless] stuff in the base system, and those who need > something that pretends to be mount_mfs can get that from the ports. > Does this sound good? My vote would be to have the mount_mfs script/program in the base system, even if it has nothing to do with mfs, as long as it do what the old mount_mfs program did. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: amd feature request (Re: AMD config file question.)
mi> Heh. That was a feature request only. I don't even know the details of mi> NFS, much less SMB. Sorry, Since amd is not FreeBSD specfic product, how 'bout sending your request to the am-utils developers? -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
worklist_remove panic
No dump (dumps seem to have been broken for about a month now), but a
stacktrace from DDB:
kernel: type 12 trap, code=0
Stopped at worklist_remove+0x1c: cmpw$0,0xa(%ecx)
db> trace
worklist_remove(deadc0de) at worklist_remove+0x1c
free_diradd(deadc0de) at free_diradd+0x26
free_newdirblk(c2e45cd0) at free_newdirblk+0x32
handle_written_inodeblock(c287b200,c6323480) at handle_written_inodeblock+0x2b2
softdep_disk_write_complete(c6323480) at softdep_disk_write_complete+0x6a
bufdone(c6323480,cf2c7f54,c014de93,c6323480,c258b280) at bufdone+0x101
bufdonebio(c6323480) at bufdonebio+0xe
ad_interrupt(c2c5f940,c2564300,cf2c7f7c,c01ba6e4,c258b280) at ad_interrupt+0x3ef
ata_intr(c258b280) at ata_intr+0xae
ithread_loop(c258b200,cf2c7fa8) at ithread_loop+0x424
fork_exit(c01ba2c0,c258b200,cf2c7fa8) at fork_exit+0xf4
fork_trampoline() at fork_trampoline+0x8
db> panic
panic: from debugger
Debugger("panic")
Stopped at worklist_remove+0x1c: cmpw$0,0xa(%ecx)
db>
panic: from debugger
Uptime: 1d0h12m13s
dumping to dev ad0b, offset 131104
dump ata0: resetting devices .. panic: witness_restore: lock (sleep mutex) Giant not
locked
Uptime: 1d0h12m13s
Dump already in progress, bailing...
Automatic reboot in 15 seconds - press a key on the console to abort
des@des ~% gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) exec-file /boot/kernel/kernel
(kgdb) symbol-file /sys/compile/DES/kernel.debug
Reading symbols from /sys/compile/DES/kernel.debug...done.
(kgdb) l *(worklist_remove+0x1c)
0xc0261750 is in worklist_remove (../../ufs/ffs/ffs_softdep.c:432).
427 struct worklist *item;
428 {
429
430 if (lk.lkt_held == -1)
431 panic("worklist_remove: lock not held");
432 if ((item->wk_state & ONWORKLIST) == 0) {
433 FREE_LOCK(&lk);
434 panic("worklist_remove: not on list");
435 }
436 item->wk_state &= ~ONWORKLIST;
(kgdb) l *(free_diradd+0x26)
0xc02640fa is in free_diradd (../../ufs/ffs/ffs_softdep.c:2601).
2596#ifdef DEBUG
2597if (lk.lkt_held == -1)
2598panic("free_diradd: lock not held");
2599#endif
2600WORKLIST_REMOVE(&dap->da_list);
2601LIST_REMOVE(dap, da_pdlist);
2602if ((dap->da_state & DIRCHG) == 0) {
2603pagedep = dap->da_pagedep;
2604} else {
2605dirrem = dap->da_previous;
(kgdb) l *(free_newdirblk+0x32)
0xc026345e is in free_newdirblk (../../ufs/ffs/ffs_softdep.c:2033).
2028 */
2029pagedep = newdirblk->db_pagedep;
2030pagedep->pd_state &= ~NEWBLOCK;
2031if ((pagedep->pd_state & ONWORKLIST) == 0)
2032while ((dap = LIST_FIRST(&pagedep->pd_pendinghd)) != NULL)
2033free_diradd(dap);
2034/*
2035 * If no dependencies remain, the pagedep will be freed.
2036 */
2037for (i = 0; i < DAHASHSZ; i++)
After this panic, fsck complained of bad superblocks on all file
systems.
By the way, fsck is intolerably slow these days: more than twenty
minutes for 'fsck -y' of a 5.5 GB filesystem (roughly 380,000 files)
on a recent and far from sluggish IBM IDE drive. Most (nearly all) of
that time is spent in phase 2.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: worklist_remove panic
On Sat, May 26, 2001 at 09:25:32PM +0200, Dag-Erling Smorgrav wrote: > No dump (dumps seem to have been broken for about a month now), but a > stacktrace from DDB: Crashdumps have been working for me recently, (apart from the fact that they overrun the end of my swap partition by 64k and clobber the superblock of my /var partition). David. 22:09# ls -l /var/crash/vmcore.9 -rw--- 1 root wheel 134152192 May 24 21:17 /var/crash/vmcore.9 22:10# strings /var/crash/kernel.9 | fgrep May May 20 2001 @(#)FreeBSD 5.0-CURRENT #23: Mon May 21 19:58:56 BST 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mutex panic
hello, world\n
my system cvsupped around May 25 reliably causes a panic when I
$ cp /cdrom/distfiles/somefiles /tmp
I've written down the message from the debugger:
/usr/src/sys/kern_synch.c:385: sleeping with "vm" locked
from /usr/src/sys/vm/vm_pager.c: 428
panic: sleeping process owns a mutex
Debugger("panic")
>trace
Debugger(...)
panic()
propagate_priority()
_mtx_lock_sleep()
ffs_write()
vn_write()
writev()
syscall()
syscall_with_err_pushed()
Anything else I can do to track this down?
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
'make includes' ownership patch
Shouldn't the includes/Makefile be installing headers using
INCOWN/INCGRP instead of BINOWN/BINGRP? I ran into this when trying
to do a 'make includes' as a normal user.
Kris
Index: include/Makefile
===
RCS file: /home/ncvs/src/include/Makefile,v
retrieving revision 1.142
diff -u -r1.142 Makefile
--- include/Makefile2001/05/26 11:57:29 1.142
+++ include/Makefile2001/05/26 21:57:34
@@ -78,15 +78,15 @@
beforeinstall: ${SHARED}
@rm -f ${DESTDIR}/usr/include/timepps.h
cd ${.CURDIR}; \
- ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \
+ ${INSTALL} -C -o ${INCOWN} -g ${INCGRP} -m 444 \
${FILES} ${DESTDIR}/usr/include
cd ${.CURDIR}/arpa; \
- ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \
+ ${INSTALL} -C -o ${INCOWN} -g ${INCGRP} -m 444 \
${ARPAFILES} ${DESTDIR}/usr/include/arpa
cd ${.CURDIR}/protocols; \
- ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \
+ ${INSTALL} -C -o ${INCOWN} -g ${INCGRP} -m 444 \
${PROTOFILES} ${DESTDIR}/usr/include/protocols
- ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \
+ ${INSTALL} -C -o ${INCOWN} -g ${INCGRP} -m 444 \
${.OBJDIR}/osreldate.h \
${DESTDIR}/usr/include
.for i in ${LFILES}
@@ -109,12 +109,12 @@
-p ${DESTDIR}/usr/include
.for i in ${LDIRS} ${LSUBDIRS}
cd ${.CURDIR}/../sys; \
- ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 $i/*.h \
+ ${INSTALL} -C -o ${INCOWN} -g ${INCGRP} -m 444 $i/*.h \
${DESTDIR}/usr/include/$i
.endfor
.if exists(${.CURDIR}/../sys/${MACHINE_ARCH}/include)
cd ${.CURDIR}/../sys/${MACHINE_ARCH}/include; \
- ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 *.h \
+ ${INSTALL} -C -o ${INCOWN} -g ${INCGRP} -m 444 *.h \
${DESTDIR}/usr/include/machine
.endif
.for i in ${SFILES}
PGP signature
Re: Date for a working -current?
On Thu, May 24, 2001 at 04:56:41PM -0600, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Joseph Koshy writes: > : I'm in the processing of bring a 5-current system of Oct 2000 vintage > : more upto-date. > > May 18th, 2001 12:00:00 is what I've been using. One must be careful posting something like this -- it isn't timezone clean. To get just before Afred's VM commit you can use -D '2001-05-19 01:27:00 UTC' -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'make includes' ownership patch
On Sat, May 26, 2001 at 02:59:22PM -0700, Kris Kennaway wrote: > Shouldn't the includes/Makefile be installing headers using > INCOWN/INCGRP instead of BINOWN/BINGRP? I ran into this when trying > to do a 'make includes' as a normal user. Oops, hit send too soon; more changes are required of the same form. Before I go to the trouble of doing those, I might as well get confirmation whether this is the right thing to do. Kris PGP signature
Re: worklist_remove panic
David Malone wrote: > On Sat, May 26, 2001 at 09:25:32PM +0200, Dag-Erling Smorgrav wrote: > > No dump (dumps seem to have been broken for about a month now), but a > > stacktrace from DDB: > > Crashdumps have been working for me recently, (apart from the fact > that they overrun the end of my swap partition by 64k and clobber > the superblock of my /var partition). Check your disk label. I got burned a few months back on a fairly old install where I created swap first, then root. This causes the swap partition to start at sector 0, with root straight after. For some reason, sysinstall or the kernel decided to += 64k on the start address of the swap partition (to avoid swap clobbering the fdisk, bootblocks, etc at the start of the disk), but neglected to remove 64k from the size. So, when I finally crashed the box with dumps enabled, it took out the first 64k of my root filesystem. I never found the code that made this change. Either it is well hidden, or got removed a while back. This machine was installed from a 4.0-SNAP from some time before march 1999. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Q) lock order reversal
Hi! With recent -current kernel, I get message below with P3@800Mhz X 2 when booting up. What is wrong? lock order reversal 1st 0xc04d4ac0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c 1007 2nd 0xdb3001ac vnode interlock @ ../../ufs/ffs/ffs_vfsops.c 1016 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Boot time memory issue
Valentin Nechayev wrote: > > Sun, May 20, 2001 at 19:53:29, barry (Barry Lustig) wrote about "Boot time memory >issue": > > Do verbose boot (`boot -v') with large SC_HISTORY_SIZE (1000 at least, > 2000 at most), and after boot check for "SMAP ..." lines at the very > beginning of the kernel boot log at /dev/console. (They are not written > to log viewable with dmesg.) Another way is to use serial console. > With this SMAP lines one can say more concrete diagnosis. Here are the SMAP lines: SMAP type=01 base= len= 0009f800 SMAP type=02 base= 0009f800 len= 0800 SMAP type=02 base= 000e8400 len= 00017c00 SMAP type=01 base= 0010 len= 13ef SMAP type=03 base= 13ff len= f800 SMAP type=04 base= 13fff800 len= 0800 SMAP type=02 base= fff8 len= 0008 Too many holes in the physical address space, giving up > > > I was curious whether the memory limitation on the Sony VAIO Z505 > > machines was an actual hardware limitation or a marketing issue. I just > > tried adding a 256MB module to my machine. The BIOS seemed to mostly > > recognize it. > > It did see 320MB of RAM, but had problems when testing all of it. > > Current (from > > a couple of weeks ago) boots, but gives me: > > Too many holes in the physical address space, giving up > > > > and comes up showing 64MB of RAM. Is this something that can be worked > > around, or have I run up against an actual hardware limit on the > > machine? > > /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Boot time memory issue
> Valentin Nechayev wrote: > > > > Sun, May 20, 2001 at 19:53:29, barry (Barry Lustig) wrote about "Boot time memory >issue": > > > > Do verbose boot (`boot -v') with large SC_HISTORY_SIZE (1000 at least, > > 2000 at most), and after boot check for "SMAP ..." lines at the very > > beginning of the kernel boot log at /dev/console. (They are not written > > to log viewable with dmesg.) Another way is to use serial console. > > With this SMAP lines one can say more concrete diagnosis. > > Here are the SMAP lines: > > SMAP type=01 base= len= 0009f800 > SMAP type=02 base= 0009f800 len= 0800 > SMAP type=02 base= 000e8400 len= 00017c00 > SMAP type=01 base= 0010 len= 13ef > SMAP type=03 base= 13ff len= f800 > SMAP type=04 base= 13fff800 len= 0800 > SMAP type=02 base= fff8 len= 0008 > Too many holes in the physical address space, giving up Can you try changing the declaration of phys_avail at the top of sys/i386/i386/machdep.c from: vm_offset_t phys_avail[10]; to vm_offset_t phys_avail[100]; -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recursed on non-recursive lock
On Sat, 2001/05/26 at 11:07:36 -0500, Michael Harnois wrote:
> I finally got this much. I hope it helps.
>
> lock order reversal
> 1st 0xc03af0a0 mntvnode @ ../../ufs/ffs/ffs_vnops.c:1007
> 2nd 0xc8b539cc vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:1016
>
> recursed on non-recursive lock (sleep mutex) vm @ ../../ufs/ufs/ufs_readwrite.c:420
> first acquired @ ../../vm/vnode_pager.c:912
> panic:recurse
> Debugger ("panic")
> Stopped at Debugger+0x45: pushl %ebx
> db> t
> Debugger(c0310767b) at Debugger+0x45
> panic(c0313348,c81b9cb8,a0,10,0) at panic+0x70
> witness_lock(c03b3f20,8,c03263b6,1a4) at witness_lock+0x356
> ffs_write(c81b9ca4) at ffs_write+0xba
> vnode_pager_generic_putpages(c8c31d00,c81b9ddc,1,0,c81b9d74) at
>vnode_pager_generic_putpages+0x19c
> vop_stdputpages(c81b9d28,c81b9d0c,c02a7f9d,c81b9d28,c81b9d48) at vop_stdputpages+0x1f
> vop_defaultop(c81b9d28,c81b9d48,c02c5c3d,c81b9d28,0) at vop_defaultop+0x15
> ufs_vnoperate(c81b9d28) at ufs_vnoperate+0x15
> vnode_pager_putpages(c8c4b360,c81b9ddc,10,0,c81b9d74,c03b3f20,1,c0329ffa,91) at
>vnode_pager_putpages+0x1ad
> [...]
I can relatively reliable reproduce this panic here...
The problem appears to be that the vm_mtx is held when VOP_WRITE is
called in vnode_pager_generic_putpages
(sys/vm/vnode_pager.c:999). This may try to grab the vm_mtx (e.g. the
ufs implementation in sys/ufs/ufs/ufs_readwrite.c), so you end up with
a recursion on the lock. Even if it wouldn't recurse, VOP_WRITE can
AFAIK block, so there is a potential for other panics, too.
The attached patch just unlocks vm_mtx before this call and reacquires
the it when it's done. This works for me, and I think it theoretically
should be safe because all relevant parts are under Giant again for
now; YMMV, it might cause other panics or corruption, so you've been
warned ;)
- thomas
Index: sys/vm/vnode_pager.c
===
RCS file: /home/ncvs/src/sys/vm/vnode_pager.c,v
retrieving revision 1.130
diff -u -r1.130 vnode_pager.c
--- sys/vm/vnode_pager.c2001/05/23 22:51:23 1.130
+++ sys/vm/vnode_pager.c2001/05/27 01:07:19
@@ -996,7 +996,9 @@
auio.uio_rw = UIO_WRITE;
auio.uio_resid = maxsize;
auio.uio_procp = (struct proc *) 0;
+ mtx_unlock(&vm_mtx);
error = VOP_WRITE(vp, &auio, ioflags, curproc->p_ucred);
+ mtx_lock(&vm_mtx);
cnt.v_vnodeout++;
cnt.v_vnodepgsout += ncount;
Re: Boot time memory issue
Mike Smith wrote: > > > Here are the SMAP lines: > > > > SMAP type=01 base= len= 0009f800 > > SMAP type=02 base= 0009f800 len= 0800 > > SMAP type=02 base= 000e8400 len= 00017c00 > > SMAP type=01 base= 0010 len= 13ef > > SMAP type=03 base= 13ff len= f800 > > SMAP type=04 base= 13fff800 len= 0800 > > SMAP type=02 base= fff8 len= 0008 > > Too many holes in the physical address space, giving up > > Can you try changing the declaration of phys_avail at the top of > sys/i386/i386/machdep.c from: > > vm_offset_t phys_avail[10]; > > to > > vm_offset_t phys_avail[100]; > Did that and got the same error. I put a printf just before the pa_indx++ in machdep.c and watched it increment by 2's all the way up to 100. Any other ideas? barry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recursed on non-recursive lock
On Sun, 27 May 2001 03:59:20 +0200, Thomas Moestl <[EMAIL PROTECTED]> said: > The attached patch just unlocks vm_mtx before this call and > reacquires the it when it's done. This works for me Me, too. So far, at least ... uptime 25 minutes, swapping, X running, none of which I could do before ... thanks! > > lock order reversal I still have this little booger ... is it significant? -- Michael D. Harnois[EMAIL PROTECTED] Redeemer Lutheran Church Washburn, Iowa Earth has its boundaries, but human stupidity is limitless. -- Gustave Flaubert To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Correctness of UIO_MAXIOV definition?
Hi,
A few days ago I posted a short message to hackers asking
for input concerning the definition of UIO_MAXIOV.
The definition of UIO_MAXIOV is hidden behind _KERNEL. I
have a small patch I'd like to apply to simply move the
#define outside of _KERNEL. The patch is below.
The second question I have is more standards based.
Should we consider changing UIO_MAXIOV to IOV_MAX or
_XOPEN_IOV_MAX and deprecating the 1st? I am unclear
on what the standard is for this.
Draft 4 of the Austin Group Common Specifications seems
to say:
9166 XSI {IOV_MAX}
9167 Maximum number of iovec structures that one process has
available for use with readv( ) or
9168 writev( ).
9169 Minimum Acceptable Value: {_XOPEN_IOV_MAX}
9524 XSI {_XOPEN_IOV_MAX}
9525 Maximum number of iovec structures that one process has
available for use with readv( ) or
9526 writev( ).
9694 * Under Runtime Invariant Values, {ATEXIT_MAX}, {IOV_MAX},
{PAGESIZE}, and
9695 {PAGE_SIZE} are added.
9696 * Under Minimum Values, {_XOPEN_IOV_MAX} is added.
13654 APPLICATION USAGE
13655The implementation can put a limit on the number of
scatter/gather elements which can be |
13656processed in one call. The symbol {IOV_MAX} defined in
should always be used to |
13657learn about the limits instead of assuming a fixed value.
|
13658 RATIONALE
13659Traditionally, the maximum number of scatter/gather elements
the system can process in one |
13660call were descibed by the symbolic value {UIO_MAXIOV}. In
IEEE Std. 1003.1-200x this value |
13661was replaced by the constant {IOV_MAX} which can be found in
. |
15151 The following symbolic constants shall be defined for
sysconf():
15198 XSI _SC_IOV_MAX
Comments welcome.
-john
Index: uio.h
===
RCS file: /home/ncvs/src/sys/sys/uio.h,v
retrieving revision 1.12
diff -u -r1.12 uio.h
--- uio.h 2001/02/16 14:31:49 1.12
+++ uio.h 2001/05/25 02:32:50
@@ -68,11 +68,6 @@
struct proc *uio_procp;
};
-/*
- * Limits
- */
-#define UIO_MAXIOV 1024/* max 1K of iov's */
-#define UIO_SMALLIOV 8 /* 8 on stack, else malloc */
struct vm_object;
@@ -91,6 +86,12 @@
ssize_treadv __P((int, const struct iovec *, int));
ssize_twritev __P((int, const struct iovec *, int));
__END_DECLS
+
+/*
+ * iovec array size limits
+ */
+#define UIO_MAXIOV 1024/* max 1K of iov's */
+#define UIO_SMALLIOV 8 /* 8 on stack, else malloc */
#endif /* _KERNEL */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: kbdcontrol the build-tool revisited (was: cvs commit: src/usr.sbin/kbdcontrol kbdcontrol.c)
Hi folks, As I'm sure most people here know, kbdcontrol is a build-tool because sysinstall requires it to generate keymap.h. This means that it has to compile with the headers already in /usr/include on the host system; the last time this came up with PASTE, we just defined the needed constant in kbdcontrol.c and forgot about the problem. This is rather silly, because it effectively means we can't add new features to kbdcontrol that depend on new header files. Furthermore, sysinstall only needs a small subset of its features, which can be easily factored out into a separate program. This has been proposed before; nobody really objected, but it was found that defining the constant was much quicker and easier. Since I think being unable to add new features to kbdcontrol is a rather silly limitation, I again propose to factor out `kbdcontrol -L` into a separate program, which can then be made a build-tool. I'll do all the work necessary if this is what we want to do. Regards, Dima Dorfman [EMAIL PROTECTED] Dima Dorfman <[EMAIL PROTECTED]> writes: > dd 2001/05/26 21:03:53 PDT > > Modified files: > usr.sbin/kbdcontrol kbdcontrol.c > Log: > A la rev. 1.36, define CONS_CLRHIST here if it isn't already since > this is a build tool, so it has to build on 4.x with the old headers. > > Revision ChangesPath > 1.38 +7 -3 src/usr.sbin/kbdcontrol/kbdcontrol.c > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recursed on non-recursive lock
After I'd been up a couple of hours I had a spontaneous reboot. No idea why. Still a lot better than I'd been doing ... -- Michael D. Harnois[EMAIL PROTECTED] Redeemer Lutheran Church Washburn, Iowa Earth has its boundaries, but human stupidity is limitless. -- Gustave Flaubert To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
next panic: blockable sleep lock
freeing uidinfo: uid = 0, sbsize = 3197224
freeing uidinfo: uid = 0, proccnt = 86
kernel trap 12 with interrupts disabled
panic: blockable sleep lock (sleep mutex) Giant @ ../../vm/vm_fault.c:213
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db> t
Debugger(c0350d9b) at Debugger+0x45
panic(c0353900, c034fd00,c0372434,c0368074,d5) at panic+0x70
witness_lock(co4230c0,8,c0368074,d5) at witness_lock+0x1b4
vm_fault(c040e2ec,deadc000,1,0,0) at vm_fault+0xb2
trap_pfault(c8d27e94,0,deadc2af,c8cbd200,c0b3351c) at trap_pfault+0x2d1
trap(c8d20018,c01d0010,c8cb0010,4,c0b3351c) at trap+0x5d0
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc01ba652, esp = 0xc8d27ed4, ebp = 0xc8d27ee0 ---
_mtx_lock_sleep(c0b3351c,0,c035076c,364) at mtx_lock_sleep+0x342
chgproccnt(c0b33500,,0,c1280900,c03b0d40,c8d26bbc,c1280900) at chgproccnt+0x67
wait1(c8cbd200,c8d27f80,0,c8d27fa0,c0323469) at wait1+0x765
wait4(c8cbd200,c8d27f80,8085c01,bfbfed04,c597) at wait4+0x12
syscall(2f,2f,2f,c597,bfbfed04) at syscall+0x695
syscall_with_err_pushed() at syscall_with_error_pushed+0x1b
db> show reg
cs 0x8
ds 0x8d20010
es 0x10
fs 0x18
ss 0x10
eax 0x12
edx 0xc0370e6f db_lengths+0x1d7
ebx 0x202
esp 0xc8d27da4
ebp 0xc8d27db0
esi 0x100
edi 0xc8cbd200
eip 0xc0313d09
efl 0x46
Debugger+0x45: pushl %ebx
db> show locks
exclusive (sleep mutex) Giant (0xc04230c0) locked @ ../../i386/i386/trap.c:1153
exclusive (spin mutex) sched lock (0xc0422f20) locked @ ../../kern/kern_mutex.c: 312
--
Michael D. Harnois[EMAIL PROTECTED]
Redeemer Lutheran Church Washburn, Iowa
Earth has its boundaries, but human stupidity is limitless.
-- Gustave Flaubert
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: worklist_remove panic
Peter Wemm <[EMAIL PROTECTED]> wrote: > For some reason, sysinstall or the kernel decided to += 64k on the > start address of the swap partition (to avoid swap clobbering the > fdisk, bootblocks, etc at the start of the disk), but neglected to > remove 64k from the size. This could be undone. Swapping has been fixed long ago to not clobber disklabels (i. e. it doesn't start at the beginning of the swap partition). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
