Date: Wed, 04 Dec 2013 13:59:52 +0100 From: Paolo Pinto <paolo.pinto@netasq.com> To: freebsd-geom@freebsd.org Cc: nicolas dumont <nicolas.dumont@netasq.com> Subject: geom_uzip, panic: bio_length in mdstart_vnode() Message-ID: <529F2748.2060900@netasq.com>
next in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format.
--------------ms050800030600090900040207
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi list!
My kernel is compiled with option INVARIANTS and I get a reproducible
kernel panic when trying to read data from a GEOM based compressed
memory disk:
Unread portion of the kernel message buffer:
panic: bio_length 140288
cpuid =3D 3
KDB: stack backtrace:
#0 0xffffffff80909726 at kdb_backtrace+0x66
#1 0xffffffff808d0fa8 at panic+0x1d8
#2 0xffffffff80595949 at mdstart_vnode+0x619
#3 0xffffffff80594053 at md_kthread+0x143
#4 0xffffffff808a3145 at fork_exit+0x135
#5 0xffffffff80c6fabe at fork_trampoline+0xe
Uptime: 16m21s
Dumping 367 out of 6113 MB:..5%..14%..22%..31%..44%..53%..61%..74%..83%..=
92%
Loaded symbols for /boot/kernel/geom_uzip.ko
#0 doadump (textdump=3D<value optimized out>) at pcpu.h:234
234 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0 doadump (textdump=3D<value optimized out>) at pcpu.h:234
#1 0xffffffff808d1552 in kern_reboot (howto=3D260)
at /data/usr/home/fabient/fabient-freebsd/sys/kern/kern_shutdown.c:44=
9
#2 0xffffffff808d0f79 in panic (fmt=3D0x1 <Address 0x1 out of bounds>)
at /data/usr/home/fabient/fabient-freebsd/sys/kern/kern_shutdown.c:63=
7
#3 0xffffffff80595949 in mdstart_vnode (sc=3D0xfffffe00070e5000,
bp=3D0xfffffe0059bf38b8)
at /data/usr/home/fabient/fabient-freebsd/sys/dev/md/md.c:742
#4 0xffffffff80594053 in md_kthread (arg=3D<value optimized out>)
at /data/usr/home/fabient/fabient-freebsd/sys/dev/md/md.c:945
#5 0xffffffff808a3145 in fork_exit (callout=3D0xffffffff80593f10
<md_kthread>,
arg=3D0xfffffe00070e5000, frame=3D0xffffff81bdc34c40)
at /data/usr/home/fabient/fabient-freebsd/sys/kern/kern_fork.c:992
#6 0xffffffff80c6fabe in fork_trampoline ()
at
/data/usr/home/fabient/fabient-freebsd/sys/amd64/amd64/exception.S:606
#7 0x0000000000000000 in ?? ()
(kgdb)
Panic is coming from a KASSERT :
KASSERT(bp->bio_length <=3D MAXPHYS, ("bio_length %jd",
(uintmax_t)bp->bio_length));
with MAXPHYS =3D 128*1024 =3D 131072
Environment :
$ uname -a
FreeBSD refbench 9.2-RELEASE-p1 FreeBSD 9.2-RELEASE-p1 #75
r229873+c58f3c3-dirty: Wed Dec 4 11:22:54 CET 2013
fabient@refbench:/usr/obj/data/usr/home/fabient/fabient-freebsd/sys/GENER=
IC
amd64
How-To-Repeat :
$ mkdir work && cd work
$ dd if=3D/dev/random of=3Ddata.img bs=3D256k count=3D1
1+0 records in
1+0 records out
262144 bytes transferred in 0.002899 secs (90427801 bytes/sec)
$ ls -lh
total 272
-rw-r--r-- 1 paolop devel 256k Dec 4 10:47:51 2013 data.img
$ cd -
$ makefs -t ffs -o optimization=3Dtime -o version=3D2 foo.img work/
Calculated size of `foo.img': 311296 bytes, 3 inodes
Extent size set to 8192
foo.img: 0.3MB (608 sectors) block size 8192, fragment size 1024
using 1 cylinder groups of 0.30MB, 38 blks, 32 inodes.
super-block backups (for fsck -b #) at:
32,
Populating `foo.img'
makefs: Writing inode 3 (work//./data.img), bytes 253952 + 8192: No
space left on device
First issue; why does this happen?
As workaround, I have to create another file/data :
$ python -c "print 'a'*300000" > work/bar.txt
$ ls -lh work/
total 592
-rw-r--r-- 1 paolop devel 293k Dec 4 10:49:22 2013 bar.txt
-rw-r--r-- 1 paolop devel 256k Dec 4 10:47:51 2013 data.img
$ makefs -t ffs -o optimization=3Dtime -o version=3D2 foo.img work/
Calculated size of `foo.img': 638976 bytes, 4 inodes
Extent size set to 8192
foo.img: 0.6MB (1248 sectors) block size 8192, fragment size 1024
using 1 cylinder groups of 0.61MB, 78 blks, 32 inodes.
super-block backups (for fsck -b #) at:
32,
Populating `foo.img'
Image `foo.img' complete
$ mkuzip foo.img; echo $?
0
$ ls -lh foo*
-rw-r--r-- 1 paolop devel 624k Dec 4 10:49:24 2013 foo.img
-rwxr-xr-x 1 paolop devel 259k Dec 4 10:49:36 2013 foo.img.uzip*
So, it's ok, I've my uzip file and I mount it :
$ sudo kldload geom_uzip
$ sudo mdconfig -a -t vnode -o readonly -f foo.img.uzip
md0
$ sudo mount -o ro,noatime /dev/md0.uzip /mnt
$ ls -al /mnt/
total 570
drwxr-xr-x 2 1023 1001 512 Dec 4 10:49 .
drwxr-xr-x 6 admin wheel 512 Dec 4 09:23 ..
-rw-r--r-- 1 1023 1001 300001 Dec 4 10:49 bar.txt
-rw-r--r-- 1 1023 1001 262144 Dec 4 10:47 data.img
$ cp /mnt/data.img /tmp/
And panic!
Is there anything I could do to help debugging this problem? I have the
core dump if that helps.
Thanks!
Regards,
--=20
Paolo Pinto
R&D System Engineer
NETASQ - We secure IT
--------------ms050800030600090900040207
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEnTCC
BJkwggOBoAMCAQICCnDGsUgWa/KQbFgwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkZS
MQ0wCwYDVQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEuMCwGA1UEChMl
TkVUQVNRIC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVUQVNR
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDgxMzE0NDUzM1oXDTE0MDgxMzE0NDUz
M1owgc4xCzAJBgNVBAYTAkZSMQ0wCwYDVQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5ldXZl
IGQnQXNjcTEuMCwGA1UEChMlTkVUQVNRIC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0
eTEnMCUGA1UECxMeTkVUQVNRIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MRQwEgYDVQQDEwtQ
YW9sbyBQSU5UTzElMCMGCSqGSIb3DQEJARYWcGFvbG8ucGludG9AbmV0YXNxLmNvbTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJfH5PlgbBG9sAsYW+VgBDysPWJOjsMJFaOq
iyCsBGgZUS6n0McSqWQMGaX+lGgiuVLkmxNxnLq8kZkARq4VbT25IaRdgbE0yPmFgYLd+9RK
RNUBfGD6S0++7pebb7CXDrplhofj8fL+oLjOU27MdG/ZkWqV6Y0kTH9XPPrMSdSNqUSAcy5O
iq7GwoTYwYlzhHILmXlVvjLZ1Ev9bJP053JomE1e7BuXjOETiPe1ymMvMNTCEjEXrmhpGmNV
GIpxOKbokkngGpECQpicXf+okbHFFyEiINaNFFYlpDGHl8XXADvcEyxC7SyrIxgwpSL95VXp
3WeBNzRB+XUlFXNLnSUCAwEAAaOBszCBsDAdBgNVHQ4EFgQUwDeJ4UTO9EshTMwEjMVUgs6Y
KcowHwYDVR0jBBgwFoAUJyrrHdlE2joXc2oJICDJJaj5f7IwCQYDVR0TBAIwADAOBgNVHQ8B
Af8EBAMCA+gwIQYDVR0RBBowGIEWcGFvbG8ucGludG9AbmV0YXNxLmNvbTARBglghkgBhvhC
AQEEBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUA
A4IBAQCEKfnRno7B0wOD+ZpUhK24j5uuvPTP4ObfFqbK/yRPJZOZpMr9OgJg9g+uhgL268EX
MqMmE5GbhDQq2uD70dS3f7irlssd9zjRQwdtH10c7J/NxTek3oMK+jDHFJMtaLwYyG/bfFPN
TV/z3LBh+XHIYzpgtE8LCz8q1LyPay6acw364LmQRlUNRjVy9VYPQ8aFTMIterRSuy5kUP3w
kga4WFan0uyLfGiTm5p21lyTExooMKFerEEdGdB/ctLfWbBcOaS8xTNzuhlwfINETBfqrhOQ
56ozRyAF6mElm0FFi4au/NPTX5sD/XrMITugeEub180NtKIP8ZeoQabp/j7ZMYIEATCCA/0C
AQEwgaAwgZExCzAJBgNVBAYTAkZSMQ0wCwYDVQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5l
dXZlIGQnQXNjcTEuMCwGA1UEChMlTkVUQVNRIC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rp
dml0eTEnMCUGA1UECxMeTkVUQVNRIENlcnRpZmljYXRpb24gQXV0aG9yaXR5AgpwxrFIFmvy
kGxYMAkGBSsOAwIaBQCgggI1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMTIwNDEyNTk1MlowIwYJKoZIhvcNAQkEMRYEFC/cAu7pvlRJ+q7H45Xr+f3D
wLh1MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgbEGCSsGAQQBgjcQBDGBozCBoDCBkTELMAkGA1UEBhMCRlIxDTALBgNVBAgTBE5v
cmQxGjAYBgNVBAcTEVZpbGxlbmV1dmUgZCdBc2NxMS4wLAYDVQQKEyVORVRBU1EgLSBTZWN1
cmUgSW50ZXJuZXQgQ29ubmVjdGl2aXR5MScwJQYDVQQLEx5ORVRBU1EgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkCCnDGsUgWa/KQbFgwgbMGCyqGSIb3DQEJEAILMYGjoIGgMIGRMQswCQYD
VQQGEwJGUjENMAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBkJ0FzY3ExLjAs
BgNVBAoTJU5FVEFTUSAtIFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAlBgNVBAsT
Hk5FVEFTUSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIKcMaxSBZr8pBsWDANBgkqhkiG9w0B
AQEFAASCAQBiUI91DKEx1ppfpTcJGQ/OCR/iL/MbD601nt+4W0SQk8uZEb4evgMsp8rr+dyh
P6/DkoTAWJ3arnSC951Pb2Nz/gMGe9xuUkAMqWSJ7aaHGc3sN46JrXlndhOiZvteqV54R8mz
UAfdodwQERwVrd/xYPHCXCRi20WGQcc/ZaDVYagxCnNXz6rXraOizT3VbIn+jCc783ti9ZSK
BNQL0OyDjj9ZrgB1hq0R6FOgge/Kwn6InENjFyeGC8zoSSAvsAQe0dkyWR+o//E9oWuOPu7/
stbJ3//pADLilb1NzemmjuG0aKQLmpFzAeY4UGfXetwDWyiZ1oUu7bBpRNaDZGZCAAAAAAAA
--------------ms050800030600090900040207--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?529F2748.2060900>