Re: panic: bremfree: removing a buffer not on a queue
> My bitty box just crashed out while doing some light desktop work and > a small amount of NFS server stuff. FWIW, this problem is repeatable - a few minutes after as I start doing any NFS service, the box crashes out and dies. Any clues on where to start looking? Nick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: bremfree: removing a buffer not on a queue
My bitty box just crashed out while doing some light desktop work and a small amount of NFS server stuff. The source was cvsup'd a few minutes before the kernel was compiled last Sunday. The contents of dmesg.boot are include below. If it's of any use, the machine crashed badly the day before yesterday during the middle of a background fsck, and a whole pile of unexpected soft update errors popped up. Most of the files reappeared in lost+found, but a few went to swim with the fishes. Nick pancake# uname -a FreeBSD pancake.netability.ie 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Mar 23 11:50:37 GMT 2003 [EMAIL PROTECTED]:/opt/usr.obj.pancake/usr/src/sys/PANCAKE i386 pancake# gdb -k kernel.debug.0 vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"... panic: bremfree: removing a buffer not on a queue panic messages: --- panic: softdep_disk_io_initiation: read cpuid = 1; lapic.id = 0100 boot() called on cpu#1 syncing disks, buffers remaining... panic: bremfree: removing a buffer not on a queue cpuid = 1; lapic.id = 0100 boot() called on cpu#1 Uptime: 1d22h51m8s Dumping 255 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- Reading symbols from /boot/kernel/snd_pcm.ko...done. Loaded symbols for /boot/kernel/snd_pcm.ko Reading symbols from /boot/kernel/snd_ich.ko...done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/nvidia.ko...done. Loaded symbols for /boot/kernel/nvidia.ko Reading symbols from /boot/kernel/linux.ko...done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/acpi.ko...done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/usb.ko...done. Loaded symbols for /boot/kernel/usb.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 239 dumping++; (kgdb) bt full #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 No locals. #1 0xc01d0c22 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371 No locals. #2 0xc01d0f70 in poweroff_wait (junk=0xc035da3f, howto=1) at /usr/src/sys/kern/kern_shutdown.c:542 td = (struct thread *) 0xc0eca1e0 bootopt = 260 buf = "bremfree: removing a buffer not on a queue", '\0' #3 0xc0215800 in bremfreel (bp=0xc035da3f) at /usr/src/sys/kern/vfs_bio.c:636 old_qindex = 260 #4 0xc0215713 in bremfree (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:618 No locals. #5 0xc02177cd in vfs_bio_awrite (bp=0x104) at /usr/src/sys/kern/vfs_bio.c:1687 i = 1 j = 0 lblkno = 11 vp = (struct vnode *) 0xc0eca1e0 ncl = -1070212545 nwritten = -1070212545 size = 8192 maxcl = 16 #6 0xc02c6ef2 in ffs_fsync (ap=0xcd2079cc) at /usr/src/sys/ufs/ffs/ffs_vnops.c:255 ---Type to continue, or q to quit--- vp = (struct vnode *) 0xc3458490 ip = (struct inode *) 0xc7729440 bp = (struct buf *) 0xc7729440 nbp = (struct buf *) 0xc7749470 error = 0 wait = 0 passes = 4 skipmeta = 0 lbn = 14 #7 0xc02c5ff9 in ffs_sync (mp=0xc2657c00, waitfor=2, cred=0xc0eb5e80, td=0xc037e5c0) at vnode_if.h:612 nvp = (struct vnode *) 0xc31fea44 vp = (struct vnode *) 0xc3458490 devvp = (struct vnode *) 0xc3458490 ip = (struct inode *) 0x0 ump = (struct ufsmount *) 0xc2752a00 fs = (struct fs *) 0xc25e6800 error = 0 count = -853509684 wait = 0 lockreq = 18 allerror = 0 #8 0xc022c83b in sync (td=0xc037e5c0, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:138 ---Type to continue, or q to quit--- mp = (struct mount *) 0xc2657c00 nmp = (struct mount *) 0x0 asyncflag = 0 #9 0xc01d0747 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280 bp = (struct buf *) 0xc0ec7080 iter = 4 nbusy = 0 pbusy = 1 subiter = 0 #10 0xc01d0f70 in poweroff_wait (junk=0xc0366096, howto=-1071556845) at /usr/src/sys/kern/kern_shutdown.c:542 td = (struct thread *) 0xc0eca1e0 bootopt = 256 buf = "bremfree: removing a buffer not on a queue", '\0' #11 0xc02bf38c in softdep_disk_io_initiation (bp=0xc0eca1e0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3465 wk = (struct worklist *) 0xc0366096 nextwk = (struct worklist *) 0xc775fba8 indirdep = (struct indirdep *) 0x100 inodedep = (struct inodedep *) 0x0 #12 0xc021e43d in cluster_wbuild (vp=0xc3458490, size=8192, start_lbn=11, len=2) at buf.h:422 bp = (struct buf *) 0xc76b2fe8 ---Type to continue, or q to quit---
Re: Who broke sort(1) ?
> >It's not like people didn't have nine years' advance warning to fix
> >their scripts.
>
> When's the first time the FreeBSD sort(1) man page mentioned that this
> syntax was deprecated? Can we at least start from there?
The man page in 4.x notes that "-k" is an alternative rather than the
recommended syntax. Moving something from being officially recommended
syntax in 4.x to dropping the syntax completely in 5.x is verging on
gratuitous breakage, and is going to confuse and piss off a lot of
users. In fact, why does somebody not modify the man page for -stable
to note that it is now deprecated usage, and please use "-k" instead?
Should this change even make it into 4.7? After all, the sooner the
better, and if 5.0 is going to be released in 6 weeks, that's not much
warning.
I'm all for the making the change in a controlled manner, but let's not
lose sight of the fact that FreeBSD is supposedly a functional operating
system, not a dysfunctional one. Tim Kientzle's suggestion is a good
compromise, and although it may cause some peculiar behaviour in
edge-case situations, it would be a lot better than the dropping the
syntax without warning from one major version to the next.
Nick
(off to fix some _POSIXLY_VERBOTEN scripts, grumble)
--- sort.1.orig Mon Sep 10 12:10:30 2001
+++ sort.1 Thu Sep 26 10:32:04 2002
@@ -5,7 +5,7 @@
.SH SYNOPSIS
.B sort
[\-cmus] [\-t separator] [\-o output-file] [\-T tempdir] [\-bdfiMnr]
-[+POS1 [\-POS2]] [\-k POS1[,POS2]] [file...]
+[\-k POS1[,POS2]] [file...]
.br
.B sort
{\-\-help,\-\-version}
@@ -150,15 +150,19 @@
.I \-c
option, check that no pair of consecutive lines compares equal.
.TP
-.I "+POS1 [\-POS2]"
+.I "\-k POS1[,POS2]"
+An alternate syntax for specifying sorting keys.
Specify a field within each line to use as a sorting key. The field
consists of the portion of the line starting at POS1 and up to (but
not including) POS2 (or to the end of the line if POS2 is not given).
-The fields and character positions are numbered starting with 0.
+The fields and character positions are numbered starting with 1.
.TP
-.I "\-k POS1[,POS2]"
+.I "+POS1 [\-POS2]"
An alternate syntax for specifying sorting keys.
-The fields and character positions are numbered starting with 1.
+The fields and character positions are numbered starting with 0.
+This syntax is now officially deprecated because it conflicts with
+the POSIX 1003.2 standard. The syntax will be dropped in a future
+release of FreeBSD.
.PP
A position has the form \fIf\fP.\fIc\fP, where \fIf\fP is the number
of the field to use and \fIc\fP is the number of the first character
typo in /usr/src/sys/sys/sx.h
There's a small typo in /usr/src/sys/sys/sx.h which causes kernel builds to break unless INVARIANTS is defined. Patch below against version 1.2 of the file. Nick --- /usr/src/sys/sys/sx.h.orig Tue Mar 6 10:57:31 2001 +++ /usr/src/sys/sys/sx.h Tue Mar 6 10:57:38 2001 @@ -78,7 +78,7 @@ #else /* INVARIANTS */ #defineSX_ASSERT_SLOCKED(sx) -#defineSX_ASSERT_XLOCKER(sx) +#defineSX_ASSERT_XLOCKED(sx) #endif /* INVARIANTS */ #endif /* _KERNEL */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
phk wrote: > This is *CURRENT* remember ? We want this transistion done and > tested before current becomes 4.0-RELEASE. The time is NOW! Not quite: this is -current, 4 days before a functionality freeze and potentially less than one month before 4.0-RELEASE. Replacing critical parts of the system at this stage is a bad idea because it's simply not going to leave enough time for the ata drivers to mature and stabilise to the same level as the wd drivers. By all means, make the transition, but if you're going to do it, please don't release 4.0 in early Jan. As an end user, I have no problem with the removal of the wd drivers (or with releasing 4.0 a little later than planned), but if making this transition is something which is going to potentially compromise either stability or hardware support due to the time-scales involved, then it is ill-advised. This isn't Linux, you know. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Threads and my new job.
> Why do we need to smite the Linux database servers? With threads in their > current state they already outperform Linux's native threads by ~50x for > things like sending mail. I would assume that the differences in database > performance is similar. The threads (& the old nfs issues which have now thankfully been fixed) in their current state led bCandid to write about the Cyclone news router: : Issues the w/FreeBSD kernel and buggy threads have required our development : team to wait until improvements to the OS can be made. We did have a beta : posted on our website for a while but have since removed it. disclaimer: I am not a thread hacker. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C597 fast ethernet support
> I've got a 100Mbit 3COM EISA ethernet interface. Here are the particulars: > > vx0: <3Com 3C597-TX Network Adapter> at 0x5000-0x501f, 0x5c80-0x5c89 > vx0: irq 12 (edge) on eisa0 slot 5 > > I've been running it for a while now at 10Mbit. From what I can gather, the > vx driver doesn't support fast ethernet. I'd be happy to lend the card to > anyone interested The vx driver supports FE speeds, just not very well. The problem is caused by the fact that the vx driver uses the 3com programmed I/O mechanism for talking to the nic, and this protocol is just not up to dealing with 100mbit speeds because its 4-byte buffer is far too small to handle large amounts of data very quickly. Its been some while since I've used the vx driver myself, but I remember being pretty disappointed by the speed of it. There's more about this in http://www.freebsd.org/~wpaul/3Com/. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
