Date: Wed, 13 Nov 2013 19:56:55 +0100 From: =?UTF-8?B?xYF1a2FzeiBKYWt1YiBTaWVtaXJhZHpraQ==?= <lukasz@siemiradzcy.pl> To: freebsd-fs@freebsd.org Subject: [ffs] ffs_valloc: dup alloc problem possible duplication of kern/133980 ? Message-ID: <5283CB77.2040202@siemiradzcy.pl>
next in thread | raw e-mail | index | archive | help
Hello!
I'm having a problem with ffs:
root@pathogen:~ # gpart delete -i 1 ada0
ada0s1 deleted
root@pathogen:~ # gpart destroy ada0
ada0 destroyed
root@pathogen:~ # gpart create -s GPT ada0
ada0 created
root@pathogen:~ # gpart add -s 32M -t freebsd ada0
ada0s1 added
root@pathogen:~ # newfs /dev/ada0s1
/dev/ada0s1: 32.0MB (65536 sectors) block size 32768, fragment size 4096
using 4 cylinder groups of 8.03MB, 257 blks, 1152 inodes.
super-block backups (for fsck -b #) at:
192, 16640, 33088, 49536
root@pathogen:~ # mount/dev/ada0s1 /media/
root@pathogen:~ # ls/media/
.snap
root@pathogen:~ # touch /media/a
mode = 040755, inum = 2, fs = /media
panic: ffs_valloc: dup alloc
KDB: enter: panic
[ thread pid 1089 tid 100062 ]
Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]!
db> bt
Tracing pid 1089 tid 100062 td 0xc4146640
db_trace_self() at db_trace_self
pc = 0xc0bfdf98 lr = 0xc0933044 (db_hex2dec+0x494)
sp = 0xde01c680 fp = 0xde01c698
r10 = 0xc0ce7ae0
db_hex2dec() at db_hex2dec+0x494
pc = 0xc0933044 lr = 0xc09329f8 (db_command_loop+0x2f4)
sp = 0xde01c6a0 fp = 0xde01c740
r4 = 0x00000000 r5 = 0x00000000
r6 = 0xc0c77132
db_command_loop() at db_command_loop+0x2f4
pc = 0xc09329f8 lr = 0xc0932754 (db_command_loop+0x50)
sp = 0xde01c748 fp = 0xde01c758
r4 = 0xc0c477d0 r5 = 0xc0c5e1d3
r6 = 0xc0d30d2c r7 = 0xde01c928
r8 = 0xc4146640 r9 = 0xc0d25ac4
r10 = 0xc0ce7d50
db_command_loop() at db_command_loop+0x50
pc = 0xc0932754 lr = 0xc09350a4 (X_db_symbol_values+0x254)
sp = 0xde01c760 fp = 0xde01c880
r4 = 0x00000000 r5 = 0xde01c768
r6 = 0xc0d25af0
X_db_symbol_values() at X_db_symbol_values+0x254
pc = 0xc09350a4 lr = 0xc0a774f0 (kdb_trap+0xd4)
sp = 0xde01c888 fp = 0xde01c8a8
r4 = 0x00000000 r5 = 0x00000001
r6 = 0xc0d25af0 r7 = 0xde01c928
kdb_trap() at kdb_trap+0xd4
pc = 0xc0a774f0 lr = 0xc0c0e918 (undefinedinstruction+0x20c)
sp = 0xde01c8b0 fp = 0xde01c920
r4 = 0x00000000 r5 = 0x00000000
r6 = 0xc0c0e65c r7 = 0xe7ffffff
r8 = 0xc4146640 r9 = 0xc0a76d98
r10 = 0xde01c928
undefinedinstruction() at undefinedinstruction+0x20c
pc = 0xc0c0e918 lr = 0xc0bff84c (exception_exit)
sp = 0xde01c928 fp = 0xde01c980
r4 = 0xffffffff r5 = 0xffff1004
r6 = 0xc0d33864 r7 = 0xc0d180b8
r8 = 0xc4146640 r9 = 0xc0d18040
r10 = 0xde01c9b4
exception_exit() at exception_exit
pc = 0xc0bff84c lr = 0xc0a76d8c (kdb_enter+0x40)
sp = 0xde01c97c fp = 0xde01c980
r0 = 0xc0d25ad4 r1 = 0x00000000
r2 = 0x00000000 r3 = 0x00000000
r4 = 0xc0c5e22d r5 = 0xc0c7274d
r6 = 0xc0d33864 r7 = 0xc0d180b8
r8 = 0xc4146640 r9 = 0xc0d18040
r10 = 0xde01c9b4 r12 = 0x00000000
kdb_enter() at kdb_enter+0x50
pc = 0xc0a76d9c lr = 0xc0a46c64 (panic+0xcc)
sp = 0xde01c988 fp = 0xde01c9a8
r4 = 0x00000100
panic() at panic+0xcc
pc = 0xc0a46c64 lr = 0xc0bb3b68 (ffs_valloc+0x8b4)
sp = 0xde01c9c0 fp = 0xde01ca40
r4 = 0x00000002 r5 = 0xc40e5780
r6 = 0xde01ca54 r7 = 0x00000000
r8 = 0x00000000 r9 = 0x000081a4
r10 = 0xde01cd48
ffs_valloc() at ffs_valloc+0x8b4
pc = 0xc0bb3b68 lr = 0xc0bd03f8 (ufs_vinit+0x31ec)
sp = 0xde01ca48 fp = 0xde01cb80
r4 = 0xde01cc60 r5 = 0x000081a4
r6 = 0xc0bb32b4 r7 = 0xc40e5780
r8 = 0xde01cd30 r9 = 0xc4196900
r10 = 0xde01cd48
ufs_vinit() at ufs_vinit+0x31ec
pc = 0xc0bd03f8 lr = 0xc0bcd280 (ufs_vinit+0x74)
sp = 0xde01cb88 fp = 0xde01cb88
r4 = 0xde01cc60 r5 = 0x00000000
r6 = 0xc0d0b1c0 r7 = 0xc4196900
r8 = 0x00000000 r9 = 0xde01cce0
r10 = 0x00000202
ufs_vinit() at ufs_vinit+0x74
pc = 0xc0bcd280 lr = 0xc0c26250 (VOP_CREATE_APV+0x9c)
sp = 0xde01cb90 fp = 0xde01cba0
VOP_CREATE_APV() at VOP_CREATE_APV+0x9c
pc = 0xc0c26250 lr = 0xc0add1a0 (vn_open_cred+0x2f8)
sp = 0xde01cba8 fp = 0xde01cc90
r4 = 0xde01cd30 r5 = 0xc4083820
r6 = 0xde01cce0
vn_open_cred() at vn_open_cred+0x2f8
pc = 0xc0add1a0 lr = 0xc0adcea0 (vn_open+0x24)
sp = 0xde01cc98 fp = 0xde01cca0
r4 = 0xc4146640 r5 = 0xc418b800
r6 = 0xde01cce0 r7 = 0x00000012
r8 = 0x00000000 r9 = 0x000500cf
r10 = 0xde01ccd0
vn_open() at vn_open+0x24
pc = 0xc0adcea0 lr = 0xc0ad6cc0 (kern_openat+0x24c)
sp = 0xde01cca8 fp = 0xde01cda8
kern_openat() at kern_openat+0x24c
pc = 0xc0ad6cc0 lr = 0xc0ad6a08 (sys_open+0x28)
sp = 0xde01cdb0 fp = 0xde01cdb8
r4 = 0xc4146640 r5 = 0xc405e640
r6 = 0x00000000 r7 = 0x00000000
r8 = 0xde01ce10 r9 = 0xbfffec10
r10 = 0xbfffebe8
sys_open() at sys_open+0x28
pc = 0xc0ad6a08 lr = 0xc0c0e010 (swi_handler+0x224)
sp = 0xde01cdc0 fp = 0xde01ce58
swi_handler() at swi_handler+0x224
pc = 0xc0c0e010 lr = 0xc0bff618 (swi_entry+0x40)
sp = 0xde01ce60 fp = 0xbfffed08
r4 = 0xbfffed44 r5 = 0x00000000
r6 = 0xbfffed44 r7 = 0x00000005
r8 = 0xbfffec20
swi_entry() at swi_entry+0x40
pc = 0xc0bff618 lr = 0xc0bff618 (swi_entry+0x40)
sp = 0xde01ce60 fp = 0xbfffed08
Unable to unwind further
db>
Some more details about system:
# uname -a
FreeBSD pathogen 10.0-BETA3 FreeBSD 10.0-BETA3 #9 r258097M: Wed Nov 13 19:06:32 CET 2013 root@fb:/usr/obj/arm.arm/usr/src/sys/SHEEVAPLUG
arm
# grep -Ei '(geom|FFS|MSDOS)' /usr/src/sys/arm/conf/SHEEVAPLUG
options FFS #Berkeley Fast Filesystem
options NO_FFS_SNAPSHOT
options MSDOSFS
options GEOM_PART_GPT
options GEOM_PART_MBR
options GEOM_ELI
# camcontrol identify 1:0:0
pass0: <WDC WD20EARX-00PASB0 51.0AB51> ATA-8 SATA 3.x device
pass0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes)
protocol ATA/ATAPI-8 SATA 3.x
device model WDC WD20EARX-00PASB0
firmware revision 51.0AB51
serial number WD-WCAZAJ212143
WWN 50014ee25ccb1ff4
cylinders 16383
heads 16
sectors/track 63
sector size logical 512, physical 4096, offset 0
LBA supported 268435455 sectors
LBA48 supported 3907029168 sectors
PIO supported PIO4
DMA supported WDMA2 UDMA6
Feature Support Enabled Value Vendor
read ahead yes yes
write cache yes yes
flush cache yes yes
overlap no
Tagged Command Queuing (TCQ) no no
Native Command Queuing (NCQ) yes 32 tags
SMART yes yes
microcode download yes yes
security yes no
power management yes yes
advanced power management no no
automatic acoustic management no no
media status notification no no
power-up in Standby yes no
write-read-verify no no
unload no no
free-fall no no
Data Set Management (DSM/TRIM) no
Host Protected Area (HPA) yes no 3907029168/3907029168
HPA - Security no
I see that similar problem was already reported back in 2009: kern/133980
Should I fill the PR?
Best regards / Pozdrawiam
Łukasz Siemiradzki
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5283CB77.2040202>