Re: panic: ffs_blkfree: freeing free block
On Wed, Dec 18, 2002 at 11:50:42AM -0800, Kirk McKusick wrote: > I have managed to panic my system on a hard reboot and now believe > that I have found the problem on which you are faulting. I have > checked in a fix to the head of the tree (sys/ufs/ffs/ffs_snapshot.c > version 1.57). Let me know if it fixes your problem. > > Kirk McKusick > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message Yep! It works now :) Thanks :) -- Aurelien msg49012/pgp0.pgp Description: PGP signature
Re: panic: ffs_blkfree: freeing free block
I have managed to panic my system on a hard reboot and now believe that I have found the problem on which you are faulting. I have checked in a fix to the head of the tree (sys/ufs/ffs/ffs_snapshot.c version 1.57). Let me know if it fixes your problem. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: ffs_blkfree: freeing free block
> > By hard shutdown I assume you mean hitting the reset button while > the machine is busily running along? If so, my test machine passes > that test. I'll keep plugging away at it though in the hopes of > getting it to fail. > > Kirk McKusick Yes, that's what I meant. My main box is a laptop so it only has a button to power it on or off but I think reset or shutdown leads to the same result. -- Aurelien msg49000/pgp0.pgp Description: PGP signature
Re: panic: ffs_blkfree: freeing free block
On Wed, Dec 18, 2002 at 08:00:19AM -0800, Kirk McKusick wrote: > I corrected a botched patch last night. Make sure that you are running > with version 1.56 2002/12/18 07:19:41 of ufs/ffs/ffs_snapshot.c. > > Kirk McKusick > > =-=-=-=-= > nebula# ident /usr/src/sys/ufs/ffs/ffs_snapshot.c /usr/src/sys/ufs/ffs/ffs_snapshot.c: $FreeBSD: src/sys/ufs/ffs/ffs_snapshot.c,v 1.56 2002/12/18 07:19:41 mckusic k Exp $ :/ -- Aurelien msg48996/pgp0.pgp Description: PGP signature
Re: panic: ffs_blkfree: freeing free block
I corrected a botched patch last night. Make sure that you are running
with version 1.56 2002/12/18 07:19:41 of ufs/ffs/ffs_snapshot.c.
Kirk McKusick
=-=-=-=-=
Date: Wed, 18 Dec 2002 11:43:25 +0100
From: Aurelien Nephtali <[EMAIL PROTECTED]>
To: Kirk McKusick <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: panic: ffs_blkfree: freeing free block
X-ASK-Info: Confirmed by User
> I introduced a bug to snapshots on 11/30/02 which did not get fixed=20
> until 12/15/02 which caused background fsck to (silently) fail to fix
> certain filesystem problems. If you ran background fsck on a system
> between 11/30 and 12/15 and then ran background fsck again on a system
> after that date, the earlier missed corruption causes the panic that
> you have seen. Once fixed on a post 12/15 system, it should not recur.
> You can avoid the panic by running `fsck -f -p' on all your system
> after upgrading to a post 12/15 system. If you find continued
> evidence of trouble after following the above procedures, please
> send me mail.
>
> Kirk McKusick
I rebuild a brand new system and the problem is still here :/.
uname -a:
FreeBSD nebula.wanadoo.fr 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Dec 18 10:45:30 CET
2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEBULA i386
I've also attached a new dump which matches to the new system.
-- Aurelien
--LQksG6bCIzRHxTLp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=dump
Content-Transfer-Encoding: quoted-printable
Script started on Wed Dec 18 11:36:02 2002
=0D=1B[m=1B[27m=1B[Jnebula# =1B[K=1B[61C/var/crash=1B[71Dg=08gdb -k=0D=0D
GNU gdb 5.2.1 (FreeBSD)=0D
Copyright 2002 Free Software Foundation, Inc.=0D
GDB is free software, covered by the GNU General Public License, and you ar=
e=0D
welcome to change it and/or distribute copies of it under certain condition=
s.=0D
Type "show copying" to see the conditions.=0D
There is absolutely no warranty for GDB. Type "show warranty" for details.=
=0D
This GDB was configured as "i386-undermydesk-freebsd".=0D
(kgdb) symbol-file kernel.debug.7 =0D
Reading symbols from kernel.debug.7...done.=0D
(kgdb) exec-file kernel.7=0D
(kgdb) core-file vmcore.7 =0D
panic: from debugger=0D
panic messages:=0D
---=0D
panic: ffs_blkfree: freeing free block=0D
panic: from debugger=0D
Uptime: 50s=0D
Dumping 123 MB=0D
ata0: resetting devices ..=0D
done=0D
16 32 48 64 80 96 112=0D
---=0D
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232=0D
232 dumping++;=0D
(kgdb) bt=0D
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232=0D
#1 0xc021c37e in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:3=
64=0D
#2 0xc021c5c3 in panic () at /usr/src/sys/kern/kern_shutdown.c:517=0D
#3 0xc013c212 in db_panic () at /usr/src/sys/ddb/db_command.c:450=0D
#4 0xc013c192 in db_command (last_cmdp=3D0xc03a0a00, cmd_table=3D0x0, =0D
aux_cmd_tablep=3D0xc039b53c, aux_cmd_tablep_end=3D0xc039b540)=0D
at /usr/src/sys/ddb/db_command.c:346=0D
#5 0xc013c2a6 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472=0D
#6 0xc013ef9a in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_trap.=
c:72=0D
#7 0xc0335d42 in kdb_trap (type=3D3, code=3D0, regs=3D0xc850da4c)=0D
at /usr/src/sys/i386/i386/db_interface.c:166=0D
#8 0xc0346b2f in trap (frame=3D=0D
{tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D -1061658176, tf=
_esi =3D 256, tf_ebp =3D -934225256, tf_isp =3D -934225288, tf_ebx =3D 0, t=
f_edx =3D 0, tf_ecx =3D -1069390144, tf_eax =3D 18, tf_trapno =3D 3, tf_err=
=3D 0, tf_eip =3D -1070374940, tf_cs =3D 8, tf_eflags =3D 646, tf_esp =3D =
-1069984152, tf_ss =3D -1070066283})=0D
at /usr/src/sys/i386/i386/trap.c:603=0D
#9 0xc0337558 in calltrap () at {standard input}:98=0D
#10 0xc021c5ab in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:50=
3=0D
#11 0xc02d8f0a in ffs_blkfree (fs=3D0xc18f3000, devvp=3D0xc191dce4, bno=3D1=
088, =0D
size=3D16384, inum=3D1088) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1771=0D
#12 0xc02e843f in indir_trunc (freeblks=3D0xc1b37500, dbn=3D4288, level=3D0=
, lbn=3D12, =0D
countp=3D0xc850dc10) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2600=0D
#13 0xc02e7ee5 in handle_workitem_freeblocks (freeblks=3D0xc1b37500, flags=
=3D0)=0D
---Type to continue, or q to quit---=0D
at /usr/src/sys/ufs/ffs/ffs_softdep.c:2466=0D
#14 0xc02e510a in process_worklist_item (matchmnt=3D0x0, flags=3D0)=0D
at /usr/src/sys/ufs/ffs/ffs_softdep.c:742=0D
#15 0xc02e4e50 in softdep_process_worklist (matchmnt=3D0x0)=0D
at /usr/src/sys/ufs/ffs/ffs_softdep.c:621=0D
#16 0xc026f89e in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1751=0D
#17 0xc0208c64 in fork_exit (callout=3D0xc026f5b0 , arg=3D0x0, =
=0D
frame=3D0x0) at /usr/src/sys/kern/kern_fork.c:872=0D
(kgdb) quit=0D
=0D=1B[m=1B[27m=1B[Jnebula# =1B[K=1B[61C/var/crash=1B[71De=08exit=0D=0D
Script done on Wed Dec 18 11:36:32 20
Re: panic: ffs_blkfree: freeing free block
> I introduced a bug to snapshots on 11/30/02 which did not get fixed
> until 12/15/02 which caused background fsck to (silently) fail to fix
> certain filesystem problems. If you ran background fsck on a system
> between 11/30 and 12/15 and then ran background fsck again on a system
> after that date, the earlier missed corruption causes the panic that
> you have seen. Once fixed on a post 12/15 system, it should not recur.
> You can avoid the panic by running `fsck -f -p' on all your system
> after upgrading to a post 12/15 system. If you find continued
> evidence of trouble after following the above procedures, please
> send me mail.
>
> Kirk McKusick
I rebuild a brand new system and the problem is still here :/.
uname -a:
FreeBSD nebula.wanadoo.fr 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Dec 18 10:45:3
0 CET 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEBULA i386
I've also attached a new dump which matches to the new system.
-- Aurelien
Script started on Wed Dec 18 11:36:02 2002
[m[27m[Jnebula# [K[61C/var/crash[71Dggdb -k
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".
(kgdb) symbol-file kernel.debug.7
Reading symbols from kernel.debug.7...done.
(kgdb) exec-file kernel.7
(kgdb) core-file vmcore.7
panic: from debugger
panic messages:
---
panic: ffs_blkfree: freeing free block
panic: from debugger
Uptime: 50s
Dumping 123 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc021c37e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc021c5c3 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc013c212 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc013c192 in db_command (last_cmdp=0xc03a0a00, cmd_table=0x0,
aux_cmd_tablep=0xc039b53c, aux_cmd_tablep_end=0xc039b540)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc013c2a6 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc013ef9a in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc0335d42 in kdb_trap (type=3, code=0, regs=0xc850da4c)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc0346b2f in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1061658176, tf_esi = 256, tf_ebp
= -934225256, tf_isp = -934225288, tf_ebx = 0, tf_edx = 0, tf_ecx = -1069390144,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070374940, tf_cs = 8, tf_eflags =
646, tf_esp = -1069984152, tf_ss = -1070066283})
at /usr/src/sys/i386/i386/trap.c:603
#9 0xc0337558 in calltrap () at {standard input}:98
#10 0xc021c5ab in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
#11 0xc02d8f0a in ffs_blkfree (fs=0xc18f3000, devvp=0xc191dce4, bno=1088,
size=16384, inum=1088) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1771
#12 0xc02e843f in indir_trunc (freeblks=0xc1b37500, dbn=4288, level=0, lbn=12,
countp=0xc850dc10) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2600
#13 0xc02e7ee5 in handle_workitem_freeblocks (freeblks=0xc1b37500, flags=0)
---Type to continue, or q to quit---
at /usr/src/sys/ufs/ffs/ffs_softdep.c:2466
#14 0xc02e510a in process_worklist_item (matchmnt=0x0, flags=0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:742
#15 0xc02e4e50 in softdep_process_worklist (matchmnt=0x0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:621
#16 0xc026f89e in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1751
#17 0xc0208c64 in fork_exit (callout=0xc026f5b0 , arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:872
(kgdb) quit
[m[27m[Jnebula# [K[61C/var/crash[71Deexit
Script done on Wed Dec 18 11:36:32 2002
msg48987/pgp0.pgp
Description: PGP signature
Re: panic: ffs_blkfree: freeing free block
> Date: Mon, 16 Dec 2002 22:42:07 -0600 > From: Dan Nelson <[EMAIL PROTECTED]> > To: Aurelien Nephtali <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: panic: ffs_blkfree: freeing free block > > In the last episode (Dec 16), Aurelien Nephtali said: > > Hi, > > > > I got a panic today which occured during a background fsck, after a > > hard-reboot of the system. The dump from gdb is attached and I can, > > of course, provide more infos if needed. > > "Me too". My info attached as well; almost identical stack trace. > Kernel was built from sources cvsupped just after 2002/12/15 17:41:07 > PST. (Why in the heck are all the timestamps in commitlogs in PST??) > > -- > Dan Nelson > [EMAIL PROTECTED] I introduced a bug to snapshots on 11/30/02 which did not get fixed until 12/15/02 which caused background fsck to (silently) fail to fix certain filesystem problems. If you ran background fsck on a system between 11/30 and 12/15 and then ran background fsck again on a system after that date, the earlier missed corruption causes the panic that you have seen. Once fixed on a post 12/15 system, it should not recur. You can avoid the panic by running `fsck -f -p' on all your system after upgrading to a post 12/15 system. If you find continued evidence of trouble after following the above procedures, please send me mail. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: ffs_blkfree: freeing free block
In the last episode (Dec 16), Aurelien Nephtali said: > Hi, > > I got a panic today which occured during a background fsck, after a > hard-reboot of the system. The dump from gdb is attached and I can, > of course, provide more infos if needed. "Me too". My info attached as well; almost identical stack trace. Kernel was built from sources cvsupped just after 2002/12/15 17:41:07 PST. (Why in the heck are all the timestamps in commitlogs in PST??) -- Dan Nelson [EMAIL PROTECTED] 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: page fault panic messages: --- panic: ffs_blkfree: freeing free block cpuid = 1; lapic.id = boot() called on cpu#1 Uptime: 1m24s pfs_vncache_unload(): 1 entries remaining Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = fault virtual address = 0x18 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02a70a4 stack pointer = 0x10:0xd4859ccc frame pointer = 0x10:0xd4859ce4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 26 (irq11: dc0) trap number = 12 panic: page fault cpuid = 1; lapic.id = boot() called on cpu#1 Uptime: 1m25s Dumping 512 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at ../../../kern/kern_shutdown.c:232 232 dumping++; #0 doadump () at ../../../kern/kern_shutdown.c:232 #1 0xc020c806 in boot (howto=260) at ../../../kern/kern_shutdown.c:364 #2 0xc020ca49 in panic () at ../../../kern/kern_shutdown.c:517 #3 0xc02b3048 in ffs_blkfree (fs=0xc2d2b000, devvp=0xc2d52a8c, bno=1896, size=8192, inum=1896) at ../../../ufs/ffs/ffs_alloc.c:1771 #4 0xc02c0395 in indir_trunc (freeblks=0xc3009d00, dbn=3696, level=0, lbn=12, countp=0xd483bc40) at ../../../ufs/ffs/ffs_softdep.c:2603 #5 0xc02bff14 in handle_workitem_freeblocks (freeblks=0xc3009d00, flags=0) at ../../../ufs/ffs/ffs_softdep.c:2469 #6 0xc02bd829 in process_worklist_item (matchmnt=0x0, flags=0) at ../../../ufs/ffs/ffs_softdep.c:745 #7 0xc02bd5dc in softdep_process_worklist (matchmnt=0x0) at ../../../ufs/ffs/ffs_softdep.c:624 #8 0xc0250b97 in sched_sync () at ../../../kern/vfs_subr.c:1751 #9 0xc01fd5ac in fork_exit (callout=0xc025094c , arg=0x0, frame=0xd483bd48) at ../../../kern/kern_fork.c:872
panic: ffs_blkfree: freeing free block
Hi,
I got a panic today which occured during a background fsck, after a hard-reboot
of the system. The dump from gdb is attached and I can, of course, provide more
infos if needed.
-- Aurelien
Script started on Mon Dec 16 22:08:36 2002
[m[27m[Jnebula# [K[39C/usr/src/sys/i386/compile/NEBULA[71Dggdb -k
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".
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /boot/kernel/kenre rnel
(kgdb) core-file /var/crash/vmcore.6
panic: from debugger
panic messages:
---
dev = ad0s1f, block = 1088, fs = /tmp
panic: ffs_blkfree: freeing free block
panic: from debugger
Uptime: 50s
Dumping 123 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc021c4de in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc021c723 in panic () at ../../../kern/kern_shutdown.c:517
#3 0xc013c232 in db_panic () at ../../../ddb/db_command.c:450
#4 0xc013c1b2 in db_command (last_cmdp=0xc03a0620, cmd_table=0x0,
aux_cmd_tablep=0xc039b14c, aux_cmd_tablep_end=0xc039b150)
at ../../../ddb/db_command.c:346
#5 0xc013c2c6 in db_command_loop () at ../../../ddb/db_command.c:472
#6 0xc013efba in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc0335c82 in kdb_trap (type=3, code=0, regs=0xc850da4c)
at ../../../i386/i386/db_interface.c:166
#8 0xc0346a3f in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1061658176, tf_esi = 256, tf_ebp
= -934225256, tf_isp = -934225288, tf_ebx = 0, tf_edx = 0, tf_ecx = -1069391136,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070375132, tf_cs = 8, tf_eflags =
646, tf_esp = -1069985075, tf_ss = -1070066800})
at ../../../i386/i386/trap.c:603
#9 0xc0337468 in calltrap () at {standard input}:98
#10 0xc021c70b in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:503
#11 0xc02d908a in ffs_blkfree (fs=0xc18f3000, devvp=0xc191dce4, bno=1088,
size=16384, inum=1088) at ../../../ufs/ffs/ffs_alloc.c:1771
#12 0xc02e85bf in indir_trunc (freeblks=0xc1b39100, dbn=4288, level=0, lbn=12,
countp=0xc850dc10) at ../../../ufs/ffs/ffs_softdep.c:2603
#13 0xc02e8065 in handle_workitem_freeblocks (freeblks=0xc1b39100, flags=0)
---Type to continue, or q to quit---
at ../../../ufs/ffs/ffs_softdep.c:2469
#14 0xc02e528a in process_worklist_item (matchmnt=0x0, flags=0)
at ../../../ufs/ffs/ffs_softdep.c:745
#15 0xc02e4fd0 in softdep_process_worklist (matchmnt=0x0)
at ../../../ufs/ffs/ffs_softdep.c:624
#16 0xc026fa0e in sched_sync () at ../../../kern/vfs_subr.c:1751
#17 0xc0208dc4 in fork_exit (callout=0xc026f720 , arg=0x0,
frame=0x0) at ../../../kern/kern_fork.c:872
(kgdb) quit
msg48859/pgp0.pgp
Description: PGP signature
Re: panic: ffs_blkfree: freeing free block / + UDMA ICRC error with ad0
On 19 Aug, Greg Lehey wrote:
>> -current as of Aug 16, ~2pm CEST:
>
> I don't see a "freeing free block" in the stack trace. What is
> missing from the trace below? Does the trace belong to the panic
> message?
The text you quotet is the backtrace of the coredump saved by savecore.
> The trace shows two panics: the first looks like a page fault kernel
To generate the backtrace I had to reboot twice, one of the reboots was
a little bit strange. I just got a black screen after issuing a shutdown
-r withhin X11... and then it rebootet. Perhaps there was another
coredump.
And here I have another one...:
---snip---
IdlePTD 4812800
initial pcb at 305f60
panicstr: bremfree: bp 0xc6a51d98 not locked
panic messages:
---
Fatal trap 12: page fault while in vm86 mode
fault virtual address = 0xc41c0
fault code = user read, page not present
instruction pointer = 0xc000:0x41c0
stack pointer = 0x0:0xfe0
frame pointer = 0x0:0x0
code segment= base 0x620016, limit 0x1, type 0x1
= DPL 3, pres 1, def32 0, gran 0
processor eflags= interrupt enabled, resume, vm86, IOPL = 0
current process = 544 (XF86_SVGA)
trap number = 12
panic: page fault
syncing disks... panic: bremfree: bp 0xc6a51d98 not locked
Uptime: 3h58m17s
dumping to dev ad0s2b, offset 20704
dump ata0: resetting devices .. done
[...]
#0 dumpsys () at ../../../kern/kern_shutdown.c:479
479 if (dumping++) {
(kgdb)
(kgdb) bt
#0 dumpsys () at ../../../kern/kern_shutdown.c:479
#1 0xc01baf11 in boot (howto=260) at ../../../kern/kern_shutdown.c:322
#2 0xc01bb32a in panic (fmt=0xc02ba51e "bremfree: bp %p not locked")
at ../../../kern/kern_shutdown.c:601
#3 0xc01ed20e in bremfree (bp=0xc6a51d98) at ../../../kern/vfs_bio.c:479
#4 0xc01ee948 in vfs_bio_awrite (bp=0xc6a51d98)
at ../../../kern/vfs_bio.c:1472
#5 0xc0235f72 in ffs_fsync (ap=0xc049ae8c) at ../../../ufs/ffs/ffs_vnops.c:239
#6 0xc0233f9f in ffs_sync (mp=0xc1870400, waitfor=2, cred=0xc0e61d00,
p=0xc0337000) at vnode_if.h:441
#7 0xc01fc2e1 in sync (p=0xc0337000, uap=0x0)
at ../../../kern/vfs_syscalls.c:620
#8 0xc01baa37 in boot (howto=256) at ../../../kern/kern_shutdown.c:231
#9 0xc01bb32a in panic (fmt=0xc02cfc5e "%s")
at ../../../kern/kern_shutdown.c:601
#10 0xc0276c90 in trap_fatal (frame=0xc049afa8, eva=803264)
at ../../../i386/i386/trap.c:935
#11 0xc02769c9 in trap_pfault (frame=0xc049afa8, usermode=0, eva=803264)
at ../../../i386/i386/trap.c:849
#12 0xc027615c in trap (frame={tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 0,
tf_esi = 12, tf_ebp = 0, tf_isp = -1068912684, tf_ebx = 31116,
tf_edx = 0, tf_ecx = 1056, tf_eax = 32868, tf_trapno = 12, tf_err = 4,
tf_eip = 16832, tf_cs = 49152, tf_eflags = 721431, tf_esp = 4064,
tf_ss = 0}) at ../../../i386/i386/trap.c:408
(kgdb)
---snip---
> mode, though the backtrace address looks user mode. The second panic
> is a "bremfree: bp not locked" in the subsequent sync. That one may
> be related to some SMP stuff that has been done recently. It would be
> interesting to look at the return address from the trap: the code
How (I didn't see "id" in the backtrace below, where do I have to
look?)?
> space ID is 0xc000, which I don't recognize. What process was
> running?
---snip---
(32) root@ttyp4 # ps -auxww -M /mnt/var/crash/vmcore.10 -N /mnt/var/crash/kernel.10
ps: Undefined error: 0
---snip---
Hmmm... \me is confused.
>> ---snip---
>> IdlePTD 4812800
>> initial pcb at 305f60
>> panicstr: bremfree: bp 0xc69e0748 not locked
>> panic messages:
>> ---
>> panic: ffs_blkfree: freeing free block
>> panic: from debugger
>> [...]
>> #0 dumpsys () at ../../../kern/kern_shutdown.c:479
>> #1 0xc01baf11 in boot (howto=260) at ../../../kern/kern_shutdown.c:322
>> #2 0xc01bb32a in panic (fmt=0xc02ba51e "bremfree: bp %p not locked")
>> at ../../../kern/kern_shutdown.c:601
>> #3 0xc01ed20e in bremfree (bp=0xc69e0748) at ../../../kern/vfs_bio.c:479
>> #4 0xc01eeb7a in getnewbuf (slpflag=0, slptimeo=0, size=8192, maxsize=8192)
>> at ../../../kern/vfs_bio.c:1632
>> #5 0xc01ef8d1 in getblk (vp=0xd063eec0, blkno=64, size=8192, slpflag=0,
>> slptimeo=0) at ../../../kern/vfs_bio.c:2244
>> #6 0xc01ed2ef in breadn (vp=0xd063eec0, blkno=64, size=8192, rablkno=0x0,
>> rabsize=0x0, cnt=0, cred=0x0, bpp=0xc049ae10)
>> at ../../../kern/vfs_bio.c:537
>> #7 0xc01ed2b4 in bread (vp=0xd063eec0, blkno=64, size=8192, cred=0x0,
>> bpp=0xc049ae10) at ../../../kern/vfs_bio.c:519
>> #8 0xc0228650 in ffs_update (vp=0xd063eda0, waitfor=0)
>> at ../../../ufs/ffs/ffs_inode.c:101
>> #9 0xc023601f in ffs_fsync (ap=0xc049ae8
Re: panic: ffs_blkfree: freeing free block / + UDMA ICRC error with ad0
On Saturday, 18 August 2001 at 14:56:10 +0200, Alexander Leidinger wrote:
> Hi,
>
> -current as of Aug 16, ~2pm CEST:
I don't see a "freeing free block" in the stack trace. What is
missing from the trace below? Does the trace belong to the panic
message?
The trace shows two panics: the first looks like a page fault kernel
mode, though the backtrace address looks user mode. The second panic
is a "bremfree: bp not locked" in the subsequent sync. That one may
be related to some SMP stuff that has been done recently. It would be
interesting to look at the return address from the trap: the code
space ID is 0xc000, which I don't recognize. What process was
running?
> ---snip---
> IdlePTD 4812800
> initial pcb at 305f60
> panicstr: bremfree: bp 0xc69e0748 not locked
> panic messages:
> ---
> panic: ffs_blkfree: freeing free block
> panic: from debugger
> [...]
> #0 dumpsys () at ../../../kern/kern_shutdown.c:479
> #1 0xc01baf11 in boot (howto=260) at ../../../kern/kern_shutdown.c:322
> #2 0xc01bb32a in panic (fmt=0xc02ba51e "bremfree: bp %p not locked")
> at ../../../kern/kern_shutdown.c:601
> #3 0xc01ed20e in bremfree (bp=0xc69e0748) at ../../../kern/vfs_bio.c:479
> #4 0xc01eeb7a in getnewbuf (slpflag=0, slptimeo=0, size=8192, maxsize=8192)
> at ../../../kern/vfs_bio.c:1632
> #5 0xc01ef8d1 in getblk (vp=0xd063eec0, blkno=64, size=8192, slpflag=0,
> slptimeo=0) at ../../../kern/vfs_bio.c:2244
> #6 0xc01ed2ef in breadn (vp=0xd063eec0, blkno=64, size=8192, rablkno=0x0,
> rabsize=0x0, cnt=0, cred=0x0, bpp=0xc049ae10)
> at ../../../kern/vfs_bio.c:537
> #7 0xc01ed2b4 in bread (vp=0xd063eec0, blkno=64, size=8192, cred=0x0,
> bpp=0xc049ae10) at ../../../kern/vfs_bio.c:519
> #8 0xc0228650 in ffs_update (vp=0xd063eda0, waitfor=0)
> at ../../../ufs/ffs/ffs_inode.c:101
> #9 0xc023601f in ffs_fsync (ap=0xc049ae8c) at ../../../ufs/ffs/ffs_vnops.c:292
> #10 0xc0233f9f in ffs_sync (mp=0xc1870400, waitfor=2, cred=0xc0e61d00,
> p=0xc0337000) at vnode_if.h:441
> #11 0xc01fc2e1 in sync (p=0xc0337000, uap=0x0)
> at ../../../kern/vfs_syscalls.c:620
> #12 0xc01baa37 in boot (howto=256) at ../../../kern/kern_shutdown.c:231
> #13 0xc01bb32a in panic (fmt=0xc02cfc5e "%s")
> at ../../../kern/kern_shutdown.c:601
> #14 0xc0276c90 in trap_fatal (frame=0xc049afa8, eva=794529)
> at ../../../i386/i386/trap.c:935
> #15 0xc02769c9 in trap_pfault (frame=0xc049afa8, usermode=0, eva=794529)
> at ../../../i386/i386/trap.c:849
> #16 0xc027615c in trap (frame={tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 3557,
> tf_esi = 20371, tf_ebp = 24, tf_isp = -1068912684, tf_ebx = 8,
> tf_edx = 145, tf_ecx = 3, tf_eax = 1544, tf_trapno = 12, tf_err = 4,
> tf_eip = 8097, tf_cs = 49152, tf_eflags = 721410, tf_esp = 4030,
> tf_ss = 0}) at ../../../i386/i386/trap.c:408
> #17 0x1fa1 in ?? ()
> Cannot access memory at address 0x18.
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
panic: ffs_blkfree: freeing free block / + UDMA ICRC error with ad0
Hi,
-current as of Aug 16, ~2pm CEST:
---snip---
IdlePTD 4812800
initial pcb at 305f60
panicstr: bremfree: bp 0xc69e0748 not locked
panic messages:
---
panic: ffs_blkfree: freeing free block
panic: from debugger
[...]
#0 dumpsys () at ../../../kern/kern_shutdown.c:479
#1 0xc01baf11 in boot (howto=260) at ../../../kern/kern_shutdown.c:322
#2 0xc01bb32a in panic (fmt=0xc02ba51e "bremfree: bp %p not locked")
at ../../../kern/kern_shutdown.c:601
#3 0xc01ed20e in bremfree (bp=0xc69e0748) at ../../../kern/vfs_bio.c:479
#4 0xc01eeb7a in getnewbuf (slpflag=0, slptimeo=0, size=8192, maxsize=8192)
at ../../../kern/vfs_bio.c:1632
#5 0xc01ef8d1 in getblk (vp=0xd063eec0, blkno=64, size=8192, slpflag=0,
slptimeo=0) at ../../../kern/vfs_bio.c:2244
#6 0xc01ed2ef in breadn (vp=0xd063eec0, blkno=64, size=8192, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0xc049ae10)
at ../../../kern/vfs_bio.c:537
#7 0xc01ed2b4 in bread (vp=0xd063eec0, blkno=64, size=8192, cred=0x0,
bpp=0xc049ae10) at ../../../kern/vfs_bio.c:519
#8 0xc0228650 in ffs_update (vp=0xd063eda0, waitfor=0)
at ../../../ufs/ffs/ffs_inode.c:101
#9 0xc023601f in ffs_fsync (ap=0xc049ae8c) at ../../../ufs/ffs/ffs_vnops.c:292
#10 0xc0233f9f in ffs_sync (mp=0xc1870400, waitfor=2, cred=0xc0e61d00,
p=0xc0337000) at vnode_if.h:441
#11 0xc01fc2e1 in sync (p=0xc0337000, uap=0x0)
at ../../../kern/vfs_syscalls.c:620
#12 0xc01baa37 in boot (howto=256) at ../../../kern/kern_shutdown.c:231
#13 0xc01bb32a in panic (fmt=0xc02cfc5e "%s")
at ../../../kern/kern_shutdown.c:601
#14 0xc0276c90 in trap_fatal (frame=0xc049afa8, eva=794529)
at ../../../i386/i386/trap.c:935
#15 0xc02769c9 in trap_pfault (frame=0xc049afa8, usermode=0, eva=794529)
at ../../../i386/i386/trap.c:849
#16 0xc027615c in trap (frame={tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 3557,
tf_esi = 20371, tf_ebp = 24, tf_isp = -1068912684, tf_ebx = 8,
tf_edx = 145, tf_ecx = 3, tf_eax = 1544, tf_trapno = 12, tf_err = 4,
tf_eip = 8097, tf_cs = 49152, tf_eflags = 721410, tf_esp = 4030,
tf_ss = 0}) at ../../../i386/i386/trap.c:408
#17 0x1fa1 in ?? ()
Cannot access memory at address 0x18.
---snip---
Transcript of the console message:
---snip---
ad0s2e: UDMA ICRC error: reading fsbn 61053200 of 27057504-27057535
(ad0s2e bn 61053200; cn 4037 tn 218 sn 26) retrying
dev = ad0s2e, block = 6885944, fs = /big
panic: ffs_blkfree: freeing free block
---snip---
This happened after issuing a "shutdown -h now", after the
"waiting 60 seconds" message, before the display of the uptime.
My sysctl.conf:
---snip---
vfs.vmiodirenable=1
net.inet.tcp.slowstart_flightsize=3
---snip---
My dmesg:
---snip---
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #21: Thu Aug 16 16:01:53 CEST 2001
[EMAIL PROTECTED]:/big/usr/src/sys/i386/compile/WORK
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 801838143 Hz
CPU: AMD Duron(tm) Processor (801.84-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x631 Stepping = 1
Features=0x183f9ff
AMD Features=0xc044<,AMIE,DSP,3DNow!>
real memory = 268369920 (262080K bytes)
avail memory = 256524288 (250512K bytes)
Preloaded elf kernel "kernel" at 0xc0478000.
Preloaded elf module "cd9660.ko" at 0xc04780a8.
Preloaded elf module "msdosfs.ko" at 0xc0478148.
Preloaded elf module "ntfs.ko" at 0xc04781e8.
Preloaded elf module "procfs.ko" at 0xc0478284.
Preloaded elf module "linux.ko" at 0xc0478324.
Preloaded elf module "miibus.ko" at 0xc04783c4.
Preloaded elf module "if_xl.ko" at 0xc0478464.
Preloaded elf module "snd_pcm.ko" at 0xc0478504.
Preloaded elf module "snd_es137x.ko" at 0xc04785a4.
Preloaded elf module "snd_via82c686.ko" at 0xc0478648.
Preloaded elf module "usb.ko" at 0xc04786f0.
Preloaded elf module "agp.ko" at 0xc047878c.
Preloaded elf module "accf_data.ko" at 0xc0478828.
Preloaded elf module "accf_http.ko" at 0xc04788cc.
Preloaded elf module "random.ko" at 0xc0478970.
Preloaded elf module "atspeaker.ko" at 0xc0478a10.
Preloaded elf module "joy.ko" at 0xc0478ab4.
Pentium Pro MTRR support enabled
VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc0319f17 (1000117)
VESA: 3dfx Interactive, Inc.
Using $PIR table, 9 entries at 0xc00fdd00
acpi0: on motherboard
acpi0: power button is handled as a fixed feature programming model.
Timecounter "ACPI" frequency 3579545 Hz
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
acpi_cpu0: on acpi0
acpi_button0: on acpi0
acpi_button1: on acpi0
acpi_pcib0: on acpi0
pci0: on acpi_pcib0
agp0: mem 0xd
panic: ffs_blkfree: freeing free block (Was: Re: More make world fun)
Doug wrote:
>
> Now that things are supposed to be fixed up in the world build I decided
> to finish what I started this morning. The build completed ok, but when it
> started the install phase it got part way through, then the machine
> spontaneously rebooted itself (first time ever on a make world for me,
> wh).
>
> When the system came back just about everything failed, including /bin/sh,
> which means the system is hose-ed.
Ok, I decided to try and find out what happened with this, and using csh
at the single user prompt I was able to get things to the point where I
could view logs, etc. There was nothing in /var/log/messages at all, and
the log of the build stopped at the point where it was installing libc_r.
However when I ran 'make installworld' this time it ran past the libc_r no
problem, but eventually I got a panic. Here is the info from the debugger:
dev=0x2fb0e, block = 9432, fs = /usr
panic: ffs_blkfree: freeing free block
Debugger("panic")
Stopped at Debugger+0x37: movl $0, in Debugger
trace:
Debugger()
panic()
ffs_blkfree()
ffs_truncate()
ufs_inactive()
ufs_vnoperate()
vput()
unlink()
syscall()
Xint0x80_syscall()
IIRC this system was last upgraded (world and kernel) on the first, maybe
june 30th. (I can get the exact date if needed.) It's all scsi, adaptec
2940UW adapter, IBM DCAS 4 gig disk, no softupdats. Let me know if there is
anything else to do here. I'll be out most of the day today, but I'll be
back tonight.
HTH,
Doug
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
