FreeBSD › freebsd-scsi

Kernel panic in FreeBSD-8.3 from UFS

Classic

List

Threaded

12 messages Options

kashyap

Kernel panic in FreeBSD-8.3 from UFS

Hi,

We have seen kernel panic while doing IO along with HBA reset. This looks to be very rare but not sure if someone can help me to understand what is a issue here. To me it does not look any issue with underline Device Driver <mps>

See below back trace.

#0 doadump (textdump=1) at pcpu.h:244
244 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0 doadump (textdump=1) at pcpu.h:244
#1 0xc0a1845a in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:442
#2 0xc0a186f1 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:607
#3 0xc0c7ceda in kmem_malloc (map=0xc15c808c, size=32768, flags=2)
at /usr/src/sys/vm/vm_kern.c:334
#4 0xc0c708e7 in page_alloc (zone=0x0, bytes=32768, pflag=0xf19839bf "\002",
wait=2) at /usr/src/sys/vm/uma_core.c:994
#5 0xc0c72fe0 in uma_large_malloc (size=32768, wait=2)
at /usr/src/sys/vm/uma_core.c:3067
#6 0xc0a04fac in malloc (size=32768, mtp=0xc102b808, flags=2)
at /usr/src/sys/kern/kern_malloc.c:492
#7 0xc0c42e89 in softdep_disk_io_initiation (bp=0xdef881fc)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:10126
#8 0xc0c5208f in ffs_geom_strategy (bo=0xc5fc30ac, bp=0xdef881fc)
at buf.h:411
#9 0xc0c65a43 in ufs_strategy (ap=0xf1983b00)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2317
#10 0xc0d6a6dd in VOP_STRATEGY_APV (vop=0xc102e4a0, a=0xf1983b00)
at vnode_if.c:2171
#11 0xc0a8d19e in bufstrategy (bo=0xc6b901bc, bp=0xdef881fc) at vnode_if.h:940
#12 0xc0a9352e in bufwrite (bp=0xdef881fc) at buf.h:404
#13 0xc0a8db5c in vfs_bio_awrite (bp=0xdef881fc) at buf.h:392
#14 0xc0c584c5 in ffs_syncvnode (vp=0xc6b90110, waitfor=1)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:288
#15 0xc0c58739 in ffs_fsync (ap=0xf1983c4c)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:187
#16 0xc0d69712 in VOP_FSYNC_APV (vop=0xc102dfc0, a=0xf1983c4c)
at vnode_if.c:1267
#17 0xc0ab5d49 in sys_fsync (td=0xc64ea8a0, uap=0xf1983cec) at vnode_if.h:549
#18 0xc0d49315 in syscall (frame=0xf1983d28) at subr_syscall.c:131
#19 0xc0d32af1 in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:266
#20 0x00000033 in ?? (

To me it looks like UFS is doing something to crash the kernel.

` Kashyap
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"

Konstantin Belousov

Re: Kernel panic in FreeBSD-8.3 from UFS

On Fri, Jun 01, 2012 at 05:30:39PM +0530, Desai, Kashyap wrote:
> Hi,
>
> We have seen kernel panic while doing IO along with HBA reset.
> This looks to be very rare but not sure if someone can help me to
> understand what is a issue here. To me it does not look any issue with
> underline Device Driver <mps>
>
> See below back trace.
You did not specified the panic message. Was it 'kmem_map too small' ?

Unless HBA driver causes memory leak, this is probably indeed unrelated.

>
>
> #0 doadump (textdump=1) at pcpu.h:244
> 244 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) #0 doadump (textdump=1) at pcpu.h:244
> #1 0xc0a1845a in kern_reboot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:442
> #2 0xc0a186f1 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:607
> #3 0xc0c7ceda in kmem_malloc (map=0xc15c808c, size=32768, flags=2)
> at /usr/src/sys/vm/vm_kern.c:334
> #4 0xc0c708e7 in page_alloc (zone=0x0, bytes=32768, pflag=0xf19839bf "\002",
> wait=2) at /usr/src/sys/vm/uma_core.c:994
> #5 0xc0c72fe0 in uma_large_malloc (size=32768, wait=2)
> at /usr/src/sys/vm/uma_core.c:3067
> #6 0xc0a04fac in malloc (size=32768, mtp=0xc102b808, flags=2)
> at /usr/src/sys/kern/kern_malloc.c:492
> #7 0xc0c42e89 in softdep_disk_io_initiation (bp=0xdef881fc)
> at /usr/src/sys/ufs/ffs/ffs_softdep.c:10126
> #8 0xc0c5208f in ffs_geom_strategy (bo=0xc5fc30ac, bp=0xdef881fc)
> at buf.h:411
> #9 0xc0c65a43 in ufs_strategy (ap=0xf1983b00)
> at /usr/src/sys/ufs/ufs/ufs_vnops.c:2317
> #10 0xc0d6a6dd in VOP_STRATEGY_APV (vop=0xc102e4a0, a=0xf1983b00)
> at vnode_if.c:2171
> #11 0xc0a8d19e in bufstrategy (bo=0xc6b901bc, bp=0xdef881fc) at vnode_if.h:940
> #12 0xc0a9352e in bufwrite (bp=0xdef881fc) at buf.h:404
> #13 0xc0a8db5c in vfs_bio_awrite (bp=0xdef881fc) at buf.h:392
> #14 0xc0c584c5 in ffs_syncvnode (vp=0xc6b90110, waitfor=1)
> at /usr/src/sys/ufs/ffs/ffs_vnops.c:288
> #15 0xc0c58739 in ffs_fsync (ap=0xf1983c4c)
> at /usr/src/sys/ufs/ffs/ffs_vnops.c:187
> #16 0xc0d69712 in VOP_FSYNC_APV (vop=0xc102dfc0, a=0xf1983c4c)
> at vnode_if.c:1267
> #17 0xc0ab5d49 in sys_fsync (td=0xc64ea8a0, uap=0xf1983cec) at vnode_if.h:549
> #18 0xc0d49315 in syscall (frame=0xf1983d28) at subr_syscall.c:131
> #19 0xc0d32af1 in Xint0x80_syscall ()
> at /usr/src/sys/i386/i386/exception.s:266
> #20 0x00000033 in ?? (
>
>
> To me it looks like UFS is doing something to crash the kernel.

You might try to use vmstat -z and vmstat -m on core to see what
has used KVA.

attachment0 (203 bytes) Download Attachment

kashyap

RE: Kernel panic in FreeBSD-8.3 from UFS

Thanks for the information. *YES* to me also looks like memory leaks only.. but it is CAM XPT who is using "366195K " memory..

See below output of "vmstat -m"

vmstat -m

Type InUse MemUse HighUse Requests Size(s)
feeder 7 1K - 7 16
acpiintr 1 1K - 1 32
isadev 9 1K - 9 64
acpica 3179 172K - 73127 16,32,64,128,256,512,1024,2048
cdev 7 1K - 7 128
acpitask 1 1K - 1 1024
sigio 1 1K - 1 32
filedesc 50 14K - 2926 16,256,512,1024
kenv 121 9K - 130 16,32,64,128,4096
kqueue 0 0K - 266 128,1024
CAM dev queue 8 1K - 8 128
proc-args 26 2K - 4746 16,32,64,128
hhook 2 1K - 2 128
ithread 128 11K - 128 16,64,128
CAM queue 43 9K - 595257 16,32,64,128,256,512,1024,2048,4096
KTRACE 100 13K - 100 128
acpisem 21 3K - 21 64,128
linker 157 6K - 166 16,32,256
lockf 1751 61K - 2311 32,64,128,256,512,1024
loginclass 2 1K - 96 64
ip6ndp 12 1K - 13 64,128
ip6opt 0 0K - 3 32
temp 56 233K - 11165 16,32,64,128,256,512,1024,2048,4096
devbuf 5248 4507K - 5360 16,32,64,128,256,512,1024,2048,4096
module 493 31K - 493 64,128
mtx_pool 2 8K - 2 4096
CAM SIM 8 1K - 8 128
subproc 216 219K - 3091 256,4096
proc 2 8K - 2 4096
session 18 2K - 109 64
pgrp 25 2K - 129 64
cred 62 6K - 13960 64,128
uidinfo 3 2K - 88 64,1024
plimit 18 5K - 1389 256
scsi_cd 0 0K - 4 16
CAM periph 22 3K - 84532 16,32,64,128
CAM XPT 183208 366195K - 722021 16,32,64,256,1024,2048
sysctltmp 0 0K - 453 16,32,64,128,4096
sysctloid 5010 158K - 5286 16,32,64,128
sysctl 0 0K - 763 16,32,64
tidhash 1 8K - 1
callout 7 1792K - 7
umtx 750 71K - 750 64,128
p1003.1b 1 1K - 1 16
SWAP 2 4373K - 2 64
bus-sc 97 417K - 6298 16,32,64,128,256,512,1024,2048,4096
bus 1382 64K - 9711 16,32,64,128,256,1024
devstat 16 33K - 16 16,4096
eventhandler 73 4K - 73 32,64,128
UART 6 3K - 6 16,256,1024
kobj 358 716K - 634 2048
Per-cpu 1 1K - 1 16
ata_pci 2 1K - 2 32
rman 226 13K - 424 16,32,64
sbuf 0 0K - 1636 16,32,64,128,256,512,1024,2048,4096
scsi_da 0 0K - 186 16
stack 0 0K - 2 128
taskqueue 15 1K - 15 16,64
Unitno 14 1K - 5912 16,64
iov 0 0K - 1847877 16,64,128,256
select 9 1K - 9 64
ioctlops 0 0K - 5848 16,32,64,128,256,512,1024,2048
msg 4 25K - 4 1024,4096
sem 4 101K - 4 1024,4096
shm 1 12K - 1
tty 21 11K - 23 512,2048
mbuf_tag 0 0K - 549 32,64
shmfd 1 4K - 1 4096
pcb 18 79K - 567 16,32,64,512,1024,2048,4096
soname 3 1K - 16885 16,32,128
vfscache 1 512K - 1
cl_savebuf 0 0K - 48 32
vfs_hash 1 256K - 1
acpidev 50 2K - 50 32
vnodes 2 1K - 2 128
vnodemarker 0 0K - 6497 512
mount 94 4K - 197 16,32,64,128,256
BPF 10 1K - 10 64
ether_multi 21 1K - 24 16,32,64
ifaddr 90 17K - 90 16,32,64,128,256,512,2048
ifnet 11 11K - 11 64,1024
USBdev 35 9K - 35 32,128,1024
clone 6 24K - 6 4096
arpcom 2 1K - 2 16
lltable 23 6K - 23 256
USB 66 40K - 69 16,32,64,128,256,1024,4096
routetbl 29 4K - 245 16,64,128,256
igmp 10 2K - 10 128
in_multi 1 1K - 1 128
sctp_iter 0 0K - 3 256
sctp_ifn 2 1K - 2 128
sctp_ifa 4 1K - 4 128
sctp_vrf 1 1K - 1 64
sctp_a_it 0 0K - 3 16
hostcache 1 16K - 1
syncache 1 72K - 1
entropy 1024 64K - 1024 64
in6_multi 15 2K - 15 16,256
pci_link 16 2K - 16 64,128
mld 10 2K - 10 128
rpc 2 1K - 2 128
audit_evclass 179 3K - 218 16
jblocks 2 1K - 2 128
savedino 0 0K - 121 256
sbdep 0 0K - 464 32
jsegdep 1 1K - 6778 32
jseg 1 1K - 4558 128
jfreefrag 0 0K - 179 64
jnewblk 0 0K - 5965 64
jremref 0 0K - 317 64
jaddref 0 0K - 317 64
freedep 0 0K - 9 32
freework 1 1K - 268 32,128
newdirblk 0 0K - 6 32
dirrem 0 0K - 305 64
mkdir 0 0K - 12 64
diradd 0 0K - 305 64
freefile 0 0K - 72 32
freeblks 0 0K - 157 128
freefrag 0 0K - 179 64
indirdep 1 1K - 4235 64
newblk 2 65K - 5966 128
bmsafemap 2 5K - 4389 128,4096
inodedep 2 257K - 4997 256
pagedep 1 64K - 51 128
ufs_dirhash 8 4K - 24 16,32,64,512
ufs_mount 21 390K - 21 256,4096
vm_pgdata 2 65K - 2 64
UMAHash 1 1K - 1 256
acpi_perf 2 1K - 2 256
DEVFS1 127 32K - 187 256
atkbddev 2 1K - 2 32
DEVFS3 141 18K - 223 128,256
DEVFS 24 1K - 25 16,64
memdesc 1 4K - 1 4096
apmdev 1 1K - 1 64
io_apic 2 2K - 2 1024
pfs_nodes 21 3K - 21 128
msi 3 1K - 3 64
nexusdev 5 1K - 5 16
GEOM 117 19K - 2291 16,32,64,128,256,512,1024,2048
SCSI SES 2 4K - 2 2048
kbdmux 7 18K - 7 16,256,1024,2048
mps 22 280K - 24141 16,32,64,128,256,512,2048,4096
mps_user 0 0K - 662 32,64

` Kashyap

> -----Original Message-----
> From: Konstantin Belousov [mailto:[hidden email]]
> Sent: Friday, June 01, 2012 6:14 PM
> To: Desai, Kashyap
> Cc: [hidden email]; [hidden email]; McConnell, Stephen
> Subject: Re: Kernel panic in FreeBSD-8.3 from UFS
>
> On Fri, Jun 01, 2012 at 05:30:39PM +0530, Desai, Kashyap wrote:
> > Hi,
> >
> > We have seen kernel panic while doing IO along with HBA reset.
> > This looks to be very rare but not sure if someone can help me to
> > understand what is a issue here. To me it does not look any issue with
> > underline Device Driver <mps>
> >
> > See below back trace.
> You did not specified the panic message. Was it 'kmem_map too small' ?
>
> Unless HBA driver causes memory leak, this is probably indeed unrelated.
> >
> >
> > #0 doadump (textdump=1) at pcpu.h:244
> > 244 pcpu.h: No such file or directory.
> > in pcpu.h
> > (kgdb) #0 doadump (textdump=1) at pcpu.h:244
> > #1 0xc0a1845a in kern_reboot (howto=260)
> > at /usr/src/sys/kern/kern_shutdown.c:442
> > #2 0xc0a186f1 in panic (fmt=Variable "fmt" is not available.
> > ) at /usr/src/sys/kern/kern_shutdown.c:607
> > #3 0xc0c7ceda in kmem_malloc (map=0xc15c808c, size=32768, flags=2)
> > at /usr/src/sys/vm/vm_kern.c:334
> > #4 0xc0c708e7 in page_alloc (zone=0x0, bytes=32768, pflag=0xf19839bf
> "\002",
> > wait=2) at /usr/src/sys/vm/uma_core.c:994
> > #5 0xc0c72fe0 in uma_large_malloc (size=32768, wait=2)
> > at /usr/src/sys/vm/uma_core.c:3067
> > #6 0xc0a04fac in malloc (size=32768, mtp=0xc102b808, flags=2)
> > at /usr/src/sys/kern/kern_malloc.c:492
> > #7 0xc0c42e89 in softdep_disk_io_initiation (bp=0xdef881fc)
> > at /usr/src/sys/ufs/ffs/ffs_softdep.c:10126
> > #8 0xc0c5208f in ffs_geom_strategy (bo=0xc5fc30ac, bp=0xdef881fc)
> > at buf.h:411
> > #9 0xc0c65a43 in ufs_strategy (ap=0xf1983b00)
> > at /usr/src/sys/ufs/ufs/ufs_vnops.c:2317
> > #10 0xc0d6a6dd in VOP_STRATEGY_APV (vop=0xc102e4a0, a=0xf1983b00)
> > at vnode_if.c:2171
> > #11 0xc0a8d19e in bufstrategy (bo=0xc6b901bc, bp=0xdef881fc) at
> > vnode_if.h:940
> > #12 0xc0a9352e in bufwrite (bp=0xdef881fc) at buf.h:404
> > #13 0xc0a8db5c in vfs_bio_awrite (bp=0xdef881fc) at buf.h:392
> > #14 0xc0c584c5 in ffs_syncvnode (vp=0xc6b90110, waitfor=1)
> > at /usr/src/sys/ufs/ffs/ffs_vnops.c:288
> > #15 0xc0c58739 in ffs_fsync (ap=0xf1983c4c)
> > at /usr/src/sys/ufs/ffs/ffs_vnops.c:187
> > #16 0xc0d69712 in VOP_FSYNC_APV (vop=0xc102dfc0, a=0xf1983c4c)
> > at vnode_if.c:1267
> > #17 0xc0ab5d49 in sys_fsync (td=0xc64ea8a0, uap=0xf1983cec) at
> > vnode_if.h:549
> > #18 0xc0d49315 in syscall (frame=0xf1983d28) at subr_syscall.c:131
> > #19 0xc0d32af1 in Xint0x80_syscall ()
> > at /usr/src/sys/i386/i386/exception.s:266
> > #20 0x00000033 in ?? (
> >
> >
> > To me it looks like UFS is doing something to crash the kernel.
>
> You might try to use vmstat -z and vmstat -m on core to see what has
> used KVA.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"

Konstantin Belousov

Re: Kernel panic in FreeBSD-8.3 from UFS

On Fri, Jun 01, 2012 at 06:19:56PM +0530, Desai, Kashyap wrote:
>
> Thanks for the information. *YES* to me also looks like memory leaks only.. but it is CAM XPT who is using "366195K " memory..
>
Yes, it seems that cam should be investigated next.

It is indeed most likely not related to UFS at all, and just happens to
trace through the UFS code since you might have run fs-intensive test and
filesystem just called allocator most often.

> See below output of "vmstat -m"
>
> vmstat -m
>
> Type InUse MemUse HighUse Requests Size(s)
> feeder 7 1K - 7 16
> acpiintr 1 1K - 1 32
> isadev 9 1K - 9 64
> acpica 3179 172K - 73127 16,32,64,128,256,512,1024,2048
> cdev 7 1K - 7 128
> acpitask 1 1K - 1 1024
> sigio 1 1K - 1 32
> filedesc 50 14K - 2926 16,256,512,1024
> kenv 121 9K - 130 16,32,64,128,4096
> kqueue 0 0K - 266 128,1024
> CAM dev queue 8 1K - 8 128
> proc-args 26 2K - 4746 16,32,64,128
> hhook 2 1K - 2 128
> ithread 128 11K - 128 16,64,128
> CAM queue 43 9K - 595257 16,32,64,128,256,512,1024,2048,4096
> KTRACE 100 13K - 100 128
> acpisem 21 3K - 21 64,128
> linker 157 6K - 166 16,32,256
> lockf 1751 61K - 2311 32,64,128,256,512,1024
> loginclass 2 1K - 96 64
> ip6ndp 12 1K - 13 64,128
> ip6opt 0 0K - 3 32
> temp 56 233K - 11165 16,32,64,128,256,512,1024,2048,4096
> devbuf 5248 4507K - 5360 16,32,64,128,256,512,1024,2048,4096
> module 493 31K - 493 64,128
> mtx_pool 2 8K - 2 4096
> CAM SIM 8 1K - 8 128
> subproc 216 219K - 3091 256,4096
> proc 2 8K - 2 4096
> session 18 2K - 109 64
> pgrp 25 2K - 129 64
> cred 62 6K - 13960 64,128
> uidinfo 3 2K - 88 64,1024
> plimit 18 5K - 1389 256
> scsi_cd 0 0K - 4 16
> CAM periph 22 3K - 84532 16,32,64,128
> CAM XPT 183208 366195K - 722021 16,32,64,256,1024,2048
> sysctltmp 0 0K - 453 16,32,64,128,4096
> sysctloid 5010 158K - 5286 16,32,64,128
> sysctl 0 0K - 763 16,32,64
> tidhash 1 8K - 1
> callout 7 1792K - 7
> umtx 750 71K - 750 64,128
> p1003.1b 1 1K - 1 16
> SWAP 2 4373K - 2 64
> bus-sc 97 417K - 6298 16,32,64,128,256,512,1024,2048,4096
> bus 1382 64K - 9711 16,32,64,128,256,1024
> devstat 16 33K - 16 16,4096
> eventhandler 73 4K - 73 32,64,128
> UART 6 3K - 6 16,256,1024
> kobj 358 716K - 634 2048
> Per-cpu 1 1K - 1 16
> ata_pci 2 1K - 2 32
> rman 226 13K - 424 16,32,64
> sbuf 0 0K - 1636 16,32,64,128,256,512,1024,2048,4096
> scsi_da 0 0K - 186 16
> stack 0 0K - 2 128
> taskqueue 15 1K - 15 16,64
> Unitno 14 1K - 5912 16,64
> iov 0 0K - 1847877 16,64,128,256
> select 9 1K - 9 64
> ioctlops 0 0K - 5848 16,32,64,128,256,512,1024,2048
> msg 4 25K - 4 1024,4096
> sem 4 101K - 4 1024,4096
> shm 1 12K - 1
> tty 21 11K - 23 512,2048
> mbuf_tag 0 0K - 549 32,64
> shmfd 1 4K - 1 4096
> pcb 18 79K - 567 16,32,64,512,1024,2048,4096
> soname 3 1K - 16885 16,32,128
> vfscache 1 512K - 1
> cl_savebuf 0 0K - 48 32
> vfs_hash 1 256K - 1
> acpidev 50 2K - 50 32
> vnodes 2 1K - 2 128
> vnodemarker 0 0K - 6497 512
> mount 94 4K - 197 16,32,64,128,256
> BPF 10 1K - 10 64
> ether_multi 21 1K - 24 16,32,64
> ifaddr 90 17K - 90 16,32,64,128,256,512,2048
> ifnet 11 11K - 11 64,1024
> USBdev 35 9K - 35 32,128,1024
> clone 6 24K - 6 4096
> arpcom 2 1K - 2 16
> lltable 23 6K - 23 256
> USB 66 40K - 69 16,32,64,128,256,1024,4096
> routetbl 29 4K - 245 16,64,128,256
> igmp 10 2K - 10 128
> in_multi 1 1K - 1 128
> sctp_iter 0 0K - 3 256
> sctp_ifn 2 1K - 2 128
> sctp_ifa 4 1K - 4 128
> sctp_vrf 1 1K - 1 64
> sctp_a_it 0 0K - 3 16
> hostcache 1 16K - 1
> syncache 1 72K - 1
> entropy 1024 64K - 1024 64
> in6_multi 15 2K - 15 16,256
> pci_link 16 2K - 16 64,128
> mld 10 2K - 10 128
> rpc 2 1K - 2 128
> audit_evclass 179 3K - 218 16
> jblocks 2 1K - 2 128
> savedino 0 0K - 121 256
> sbdep 0 0K - 464 32
> jsegdep 1 1K - 6778 32
> jseg 1 1K - 4558 128
> jfreefrag 0 0K - 179 64
> jnewblk 0 0K - 5965 64
> jremref 0 0K - 317 64
> jaddref 0 0K - 317 64
> freedep 0 0K - 9 32
> freework 1 1K - 268 32,128
> newdirblk 0 0K - 6 32
> dirrem 0 0K - 305 64
> mkdir 0 0K - 12 64
> diradd 0 0K - 305 64
> freefile 0 0K - 72 32
> freeblks 0 0K - 157 128
> freefrag 0 0K - 179 64
> indirdep 1 1K - 4235 64
> newblk 2 65K - 5966 128
> bmsafemap 2 5K - 4389 128,4096
> inodedep 2 257K - 4997 256
> pagedep 1 64K - 51 128
> ufs_dirhash 8 4K - 24 16,32,64,512
> ufs_mount 21 390K - 21 256,4096
> vm_pgdata 2 65K - 2 64
> UMAHash 1 1K - 1 256
> acpi_perf 2 1K - 2 256
> DEVFS1 127 32K - 187 256
> atkbddev 2 1K - 2 32
> DEVFS3 141 18K - 223 128,256
> DEVFS 24 1K - 25 16,64
> memdesc 1 4K - 1 4096
> apmdev 1 1K - 1 64
> io_apic 2 2K - 2 1024
> pfs_nodes 21 3K - 21 128
> msi 3 1K - 3 64
> nexusdev 5 1K - 5 16
> GEOM 117 19K - 2291 16,32,64,128,256,512,1024,2048
> SCSI SES 2 4K - 2 2048
> kbdmux 7 18K - 7 16,256,1024,2048
> mps 22 280K - 24141 16,32,64,128,256,512,2048,4096
> mps_user 0 0K - 662 32,64
>
>
> ` Kashyap
>
> > -----Original Message-----
> > From: Konstantin Belousov [mailto:[hidden email]]
> > Sent: Friday, June 01, 2012 6:14 PM
> > To: Desai, Kashyap
> > Cc: [hidden email]; [hidden email]; McConnell, Stephen
> > Subject: Re: Kernel panic in FreeBSD-8.3 from UFS
> >
> > On Fri, Jun 01, 2012 at 05:30:39PM +0530, Desai, Kashyap wrote:
> > > Hi,
> > >
> > > We have seen kernel panic while doing IO along with HBA reset.
> > > This looks to be very rare but not sure if someone can help me to
> > > understand what is a issue here. To me it does not look any issue with
> > > underline Device Driver <mps>
> > >
> > > See below back trace.
> > You did not specified the panic message. Was it 'kmem_map too small' ?
> >
> > Unless HBA driver causes memory leak, this is probably indeed unrelated.
> > >
> > >
> > > #0 doadump (textdump=1) at pcpu.h:244
> > > 244 pcpu.h: No such file or directory.
> > > in pcpu.h
> > > (kgdb) #0 doadump (textdump=1) at pcpu.h:244
> > > #1 0xc0a1845a in kern_reboot (howto=260)
> > > at /usr/src/sys/kern/kern_shutdown.c:442
> > > #2 0xc0a186f1 in panic (fmt=Variable "fmt" is not available.
> > > ) at /usr/src/sys/kern/kern_shutdown.c:607
> > > #3 0xc0c7ceda in kmem_malloc (map=0xc15c808c, size=32768, flags=2)
> > > at /usr/src/sys/vm/vm_kern.c:334
> > > #4 0xc0c708e7 in page_alloc (zone=0x0, bytes=32768, pflag=0xf19839bf
> > "\002",
> > > wait=2) at /usr/src/sys/vm/uma_core.c:994
> > > #5 0xc0c72fe0 in uma_large_malloc (size=32768, wait=2)
> > > at /usr/src/sys/vm/uma_core.c:3067
> > > #6 0xc0a04fac in malloc (size=32768, mtp=0xc102b808, flags=2)
> > > at /usr/src/sys/kern/kern_malloc.c:492
> > > #7 0xc0c42e89 in softdep_disk_io_initiation (bp=0xdef881fc)
> > > at /usr/src/sys/ufs/ffs/ffs_softdep.c:10126
> > > #8 0xc0c5208f in ffs_geom_strategy (bo=0xc5fc30ac, bp=0xdef881fc)
> > > at buf.h:411
> > > #9 0xc0c65a43 in ufs_strategy (ap=0xf1983b00)
> > > at /usr/src/sys/ufs/ufs/ufs_vnops.c:2317
> > > #10 0xc0d6a6dd in VOP_STRATEGY_APV (vop=0xc102e4a0, a=0xf1983b00)
> > > at vnode_if.c:2171
> > > #11 0xc0a8d19e in bufstrategy (bo=0xc6b901bc, bp=0xdef881fc) at
> > > vnode_if.h:940
> > > #12 0xc0a9352e in bufwrite (bp=0xdef881fc) at buf.h:404
> > > #13 0xc0a8db5c in vfs_bio_awrite (bp=0xdef881fc) at buf.h:392
> > > #14 0xc0c584c5 in ffs_syncvnode (vp=0xc6b90110, waitfor=1)
> > > at /usr/src/sys/ufs/ffs/ffs_vnops.c:288
> > > #15 0xc0c58739 in ffs_fsync (ap=0xf1983c4c)
> > > at /usr/src/sys/ufs/ffs/ffs_vnops.c:187
> > > #16 0xc0d69712 in VOP_FSYNC_APV (vop=0xc102dfc0, a=0xf1983c4c)
> > > at vnode_if.c:1267
> > > #17 0xc0ab5d49 in sys_fsync (td=0xc64ea8a0, uap=0xf1983cec) at
> > > vnode_if.h:549
> > > #18 0xc0d49315 in syscall (frame=0xf1983d28) at subr_syscall.c:131
> > > #19 0xc0d32af1 in Xint0x80_syscall ()
> > > at /usr/src/sys/i386/i386/exception.s:266
> > > #20 0x00000033 in ?? (
> > >
> > >
> > > To me it looks like UFS is doing something to crash the kernel.
> >
> > You might try to use vmstat -z and vmstat -m on core to see what has
> > used KVA.

attachment0 (203 bytes) Download Attachment

kashyap

RE: Kernel panic in FreeBSD-8.3 from UFS

Hi All,

We found some potential area of memory leak in CAM layer.
CAM XPT Memory leak is due to following function in scsi/scsi_all.c

int
scsi_command_string(struct ccb_scsiio *csio, struct sbuf *sb)

In above function, CAM layer allocate memory for ccb device as below
if ((cgd = (struct ccb_getdev*)xpt_alloc_ccb_nowait()) == NULL)

_But_, unfortunately we never free the allocated memory and we see memory leak of 2K every time when someone is calling
Scsi_command_string from kernel mode.

Attached is a proposed patch for this issue.

` Kashyap

> -----Original Message-----
> From: Konstantin Belousov [mailto:[hidden email]]
> Sent: Friday, June 01, 2012 6:28 PM
> To: Desai, Kashyap
> Cc: [hidden email]; [hidden email]; McConnell, Stephen
> Subject: Re: Kernel panic in FreeBSD-8.3 from UFS
>
> On Fri, Jun 01, 2012 at 06:19:56PM +0530, Desai, Kashyap wrote:
> >
> > Thanks for the information. *YES* to me also looks like memory leaks
> only.. but it is CAM XPT who is using "366195K " memory..
> >
> Yes, it seems that cam should be investigated next.
>
> It is indeed most likely not related to UFS at all, and just happens to
> trace through the UFS code since you might have run fs-intensive test
> and filesystem just called allocator most often.
>
> > See below output of "vmstat -m"
> >
> > vmstat -m
> >
> > Type InUse MemUse HighUse Requests Size(s)
> > feeder 7 1K - 7 16
> > acpiintr 1 1K - 1 32
> > isadev 9 1K - 9 64
> > acpica 3179 172K - 73127
> 16,32,64,128,256,512,1024,2048
> > cdev 7 1K - 7 128
> > acpitask 1 1K - 1 1024
> > sigio 1 1K - 1 32
> > filedesc 50 14K - 2926 16,256,512,1024
> > kenv 121 9K - 130 16,32,64,128,4096
> > kqueue 0 0K - 266 128,1024
> > CAM dev queue 8 1K - 8 128
> > proc-args 26 2K - 4746 16,32,64,128
> > hhook 2 1K - 2 128
> > ithread 128 11K - 128 16,64,128
> > CAM queue 43 9K - 595257
> 16,32,64,128,256,512,1024,2048,4096
> > KTRACE 100 13K - 100 128
> > acpisem 21 3K - 21 64,128
> > linker 157 6K - 166 16,32,256
> > lockf 1751 61K - 2311 32,64,128,256,512,1024
> > loginclass 2 1K - 96 64
> > ip6ndp 12 1K - 13 64,128
> > ip6opt 0 0K - 3 32
> > temp 56 233K - 11165
> 16,32,64,128,256,512,1024,2048,4096
> > devbuf 5248 4507K - 5360
> 16,32,64,128,256,512,1024,2048,4096
> > module 493 31K - 493 64,128
> > mtx_pool 2 8K - 2 4096
> > CAM SIM 8 1K - 8 128
> > subproc 216 219K - 3091 256,4096
> > proc 2 8K - 2 4096
> > session 18 2K - 109 64
> > pgrp 25 2K - 129 64
> > cred 62 6K - 13960 64,128
> > uidinfo 3 2K - 88 64,1024
> > plimit 18 5K - 1389 256
> > scsi_cd 0 0K - 4 16
> > CAM periph 22 3K - 84532 16,32,64,128
> > CAM XPT 183208 366195K - 722021 16,32,64,256,1024,2048
> > sysctltmp 0 0K - 453 16,32,64,128,4096
> > sysctloid 5010 158K - 5286 16,32,64,128
> > sysctl 0 0K - 763 16,32,64
> > tidhash 1 8K - 1
> > callout 7 1792K - 7
> > umtx 750 71K - 750 64,128
> > p1003.1b 1 1K - 1 16
> > SWAP 2 4373K - 2 64
> > bus-sc 97 417K - 6298
> 16,32,64,128,256,512,1024,2048,4096
> > bus 1382 64K - 9711 16,32,64,128,256,1024
> > devstat 16 33K - 16 16,4096
> > eventhandler 73 4K - 73 32,64,128
> > UART 6 3K - 6 16,256,1024
> > kobj 358 716K - 634 2048
> > Per-cpu 1 1K - 1 16
> > ata_pci 2 1K - 2 32
> > rman 226 13K - 424 16,32,64
> > sbuf 0 0K - 1636
> 16,32,64,128,256,512,1024,2048,4096
> > scsi_da 0 0K - 186 16
> > stack 0 0K - 2 128
> > taskqueue 15 1K - 15 16,64
> > Unitno 14 1K - 5912 16,64
> > iov 0 0K - 1847877 16,64,128,256
> > select 9 1K - 9 64
> > ioctlops 0 0K - 5848
> 16,32,64,128,256,512,1024,2048
> > msg 4 25K - 4 1024,4096
> > sem 4 101K - 4 1024,4096
> > shm 1 12K - 1
> > tty 21 11K - 23 512,2048
> > mbuf_tag 0 0K - 549 32,64
> > shmfd 1 4K - 1 4096
> > pcb 18 79K - 567
> 16,32,64,512,1024,2048,4096
> > soname 3 1K - 16885 16,32,128
> > vfscache 1 512K - 1
> > cl_savebuf 0 0K - 48 32
> > vfs_hash 1 256K - 1
> > acpidev 50 2K - 50 32
> > vnodes 2 1K - 2 128
> > vnodemarker 0 0K - 6497 512
> > mount 94 4K - 197 16,32,64,128,256
> > BPF 10 1K - 10 64
> > ether_multi 21 1K - 24 16,32,64
> > ifaddr 90 17K - 90 16,32,64,128,256,512,2048
> > ifnet 11 11K - 11 64,1024
> > USBdev 35 9K - 35 32,128,1024
> > clone 6 24K - 6 4096
> > arpcom 2 1K - 2 16
> > lltable 23 6K - 23 256
> > USB 66 40K - 69
> 16,32,64,128,256,1024,4096
> > routetbl 29 4K - 245 16,64,128,256
> > igmp 10 2K - 10 128
> > in_multi 1 1K - 1 128
> > sctp_iter 0 0K - 3 256
> > sctp_ifn 2 1K - 2 128
> > sctp_ifa 4 1K - 4 128
> > sctp_vrf 1 1K - 1 64
> > sctp_a_it 0 0K - 3 16
> > hostcache 1 16K - 1
> > syncache 1 72K - 1
> > entropy 1024 64K - 1024 64
> > in6_multi 15 2K - 15 16,256
> > pci_link 16 2K - 16 64,128
> > mld 10 2K - 10 128
> > rpc 2 1K - 2 128
> > audit_evclass 179 3K - 218 16
> > jblocks 2 1K - 2 128
> > savedino 0 0K - 121 256
> > sbdep 0 0K - 464 32
> > jsegdep 1 1K - 6778 32
> > jseg 1 1K - 4558 128
> > jfreefrag 0 0K - 179 64
> > jnewblk 0 0K - 5965 64
> > jremref 0 0K - 317 64
> > jaddref 0 0K - 317 64
> > freedep 0 0K - 9 32
> > freework 1 1K - 268 32,128
> > newdirblk 0 0K - 6 32
> > dirrem 0 0K - 305 64
> > mkdir 0 0K - 12 64
> > diradd 0 0K - 305 64
> > freefile 0 0K - 72 32
> > freeblks 0 0K - 157 128
> > freefrag 0 0K - 179 64
> > indirdep 1 1K - 4235 64
> > newblk 2 65K - 5966 128
> > bmsafemap 2 5K - 4389 128,4096
> > inodedep 2 257K - 4997 256
> > pagedep 1 64K - 51 128
> > ufs_dirhash 8 4K - 24 16,32,64,512
> > ufs_mount 21 390K - 21 256,4096
> > vm_pgdata 2 65K - 2 64
> > UMAHash 1 1K - 1 256
> > acpi_perf 2 1K - 2 256
> > DEVFS1 127 32K - 187 256
> > atkbddev 2 1K - 2 32
> > DEVFS3 141 18K - 223 128,256
> > DEVFS 24 1K - 25 16,64
> > memdesc 1 4K - 1 4096
> > apmdev 1 1K - 1 64
> > io_apic 2 2K - 2 1024
> > pfs_nodes 21 3K - 21 128
> > msi 3 1K - 3 64
> > nexusdev 5 1K - 5 16
> > GEOM 117 19K - 2291
> 16,32,64,128,256,512,1024,2048
> > SCSI SES 2 4K - 2 2048
> > kbdmux 7 18K - 7 16,256,1024,2048
> > mps 22 280K - 24141
> 16,32,64,128,256,512,2048,4096
> > mps_user 0 0K - 662 32,64
> >
> >
> > ` Kashyap
> >
> > > -----Original Message-----
> > > From: Konstantin Belousov [mailto:[hidden email]]
> > > Sent: Friday, June 01, 2012 6:14 PM
> > > To: Desai, Kashyap
> > > Cc: [hidden email]; [hidden email]; McConnell,
> > > Stephen
> > > Subject: Re: Kernel panic in FreeBSD-8.3 from UFS
> > >
> > > On Fri, Jun 01, 2012 at 05:30:39PM +0530, Desai, Kashyap wrote:
> > > > Hi,
> > > >
> > > > We have seen kernel panic while doing IO along with HBA reset.
> > > > This looks to be very rare but not sure if someone can help me to
> > > > understand what is a issue here. To me it does not look any issue
> > > > with underline Device Driver <mps>
> > > >
> > > > See below back trace.
> > > You did not specified the panic message. Was it 'kmem_map too small'
> ?
> > >
> > > Unless HBA driver causes memory leak, this is probably indeed
> unrelated.
> > > >
> > > >
> > > > #0 doadump (textdump=1) at pcpu.h:244
> > > > 244 pcpu.h: No such file or directory.
> > > > in pcpu.h
> > > > (kgdb) #0 doadump (textdump=1) at pcpu.h:244
> > > > #1 0xc0a1845a in kern_reboot (howto=260)
> > > > at /usr/src/sys/kern/kern_shutdown.c:442
> > > > #2 0xc0a186f1 in panic (fmt=Variable "fmt" is not available.
> > > > ) at /usr/src/sys/kern/kern_shutdown.c:607
> > > > #3 0xc0c7ceda in kmem_malloc (map=0xc15c808c, size=32768,
> flags=2)
> > > > at /usr/src/sys/vm/vm_kern.c:334
> > > > #4 0xc0c708e7 in page_alloc (zone=0x0, bytes=32768,
> > > > pflag=0xf19839bf
> > > "\002",
> > > > wait=2) at /usr/src/sys/vm/uma_core.c:994
> > > > #5 0xc0c72fe0 in uma_large_malloc (size=32768, wait=2)
> > > > at /usr/src/sys/vm/uma_core.c:3067
> > > > #6 0xc0a04fac in malloc (size=32768, mtp=0xc102b808, flags=2)
> > > > at /usr/src/sys/kern/kern_malloc.c:492
> > > > #7 0xc0c42e89 in softdep_disk_io_initiation (bp=0xdef881fc)
> > > > at /usr/src/sys/ufs/ffs/ffs_softdep.c:10126
> > > > #8 0xc0c5208f in ffs_geom_strategy (bo=0xc5fc30ac, bp=0xdef881fc)
> > > > at buf.h:411
> > > > #9 0xc0c65a43 in ufs_strategy (ap=0xf1983b00)
> > > > at /usr/src/sys/ufs/ufs/ufs_vnops.c:2317
> > > > #10 0xc0d6a6dd in VOP_STRATEGY_APV (vop=0xc102e4a0, a=0xf1983b00)
> > > > at vnode_if.c:2171
> > > > #11 0xc0a8d19e in bufstrategy (bo=0xc6b901bc, bp=0xdef881fc) at
> > > > vnode_if.h:940
> > > > #12 0xc0a9352e in bufwrite (bp=0xdef881fc) at buf.h:404
> > > > #13 0xc0a8db5c in vfs_bio_awrite (bp=0xdef881fc) at buf.h:392
> > > > #14 0xc0c584c5 in ffs_syncvnode (vp=0xc6b90110, waitfor=1)
> > > > at /usr/src/sys/ufs/ffs/ffs_vnops.c:288
> > > > #15 0xc0c58739 in ffs_fsync (ap=0xf1983c4c)
> > > > at /usr/src/sys/ufs/ffs/ffs_vnops.c:187
> > > > #16 0xc0d69712 in VOP_FSYNC_APV (vop=0xc102dfc0, a=0xf1983c4c)
> > > > at vnode_if.c:1267
> > > > #17 0xc0ab5d49 in sys_fsync (td=0xc64ea8a0, uap=0xf1983cec) at
> > > > vnode_if.h:549
> > > > #18 0xc0d49315 in syscall (frame=0xf1983d28) at subr_syscall.c:131
> > > > #19 0xc0d32af1 in Xint0x80_syscall ()
> > > > at /usr/src/sys/i386/i386/exception.s:266
> > > > #20 0x00000033 in ?? (
> > > >
> > > >
> > > > To me it looks like UFS is doing something to crash the kernel.
> > >
> > > You might try to use vmstat -z and vmstat -m on core to see what has
> > > used KVA.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"

xpt_free_ccb.patch (510 bytes) Download Attachment

John Baldwin

Re: Kernel panic in FreeBSD-8.3 from UFS

On Tuesday, June 05, 2012 8:19:05 am Desai, Kashyap wrote:

> Hi All,
>
> We found some potential area of memory leak in CAM layer.
> CAM XPT Memory leak is due to following function in scsi/scsi_all.c
>
> int
> scsi_command_string(struct ccb_scsiio *csio, struct sbuf *sb)
>
>
> In above function, CAM layer allocate memory for ccb device as below
> if ((cgd = (struct ccb_getdev*)xpt_alloc_ccb_nowait()) == NULL)
>
>
> _But_, unfortunately we never free the allocated memory and we see memory

leak of 2K every time when someone is calling
> Scsi_command_string from kernel mode.
>
>
> Attached is a proposed patch for this issue.

The patch looks correct to me. Can one of the CAM folks (Ken?) review it and
commit it?

--
John Baldwin
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"

Kenneth D. Merry

Re: Kernel panic in FreeBSD-8.3 from UFS

In reply to this post by kashyap

On Tue, Jun 05, 2012 at 17:49:05 +0530, Desai, Kashyap wrote:

The patch looks good, I just committed it.

Thanks!

Ken
--
Kenneth Merry
[hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"

Holm Tiffe

Re: Kernel panic in FreeBSD-8.3 from UFS

Kenneth D. Merry wrote:

> On Tue, Jun 05, 2012 at 17:49:05 +0530, Desai, Kashyap wrote:
> > Hi All,
> >
> > We found some potential area of memory leak in CAM layer.
> > CAM XPT Memory leak is due to following function in scsi/scsi_all.c
> >
> > int
> > scsi_command_string(struct ccb_scsiio *csio, struct sbuf *sb)
> >
> >
> > In above function, CAM layer allocate memory for ccb device as below
> > if ((cgd = (struct ccb_getdev*)xpt_alloc_ccb_nowait()) == NULL)
> >
> >
> > _But_, unfortunately we never free the allocated memory and we see memory leak of 2K every time when someone is calling
> > Scsi_command_string from kernel mode.
> >
> >
> > Attached is a proposed patch for this issue.
>
> The patch looks good, I just committed it.
>
> Thanks!
>
> Ken
> --
> Kenneth Merry
> [hidden email]
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "[hidden email]"

It looks that this patch or something related to it broke my tape backups.
I do have two SCSI Tapes connected to my system:

# camcontrol devlist
<IBM-SSG S53D073 C61E> at scbus0 target 0 lun 0 (pass0,da0)
<IBM-SSG S53D073 C61E> at scbus0 target 1 lun 0 (pass1,da1)
<IBM-SSG S53D073 C61A> at scbus0 target 2 lun 0 (pass2,da2)
<IBM-SSG S53D073 C61A> at scbus0 target 3 lun 0 (pass3,da3)
<TANDBERG SLR5 4/8GB =09:> at scbus1 target 5 lun 0 (pass4,sa0)
<COMPAQ DLT4000 D887> at scbus1 target 6 lun 0 (pass5,sa1)

an with an 8.3 stable from Jun 14 both of them arent able anymore to do
blocksizes over 8k and 8k are only working sometimes (huh?!).

# mt -f /dev/sa1 status
Mode Density Blocksize bpi Compression
Current: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
---------available modes---------
0: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
1: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
2: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
3: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
---------------------------------
Current Driver State: at rest.
---------------------------------
File Number: 0 Record Number: 0 Residual Count 0

# dd if=/dev/zero of=/dev/sa1 bs=1k count=1000
1000+0 records in
1000+0 records out
1024000 bytes transferred in 4.330778 secs (236447 bytes/sec)
# dd if=/dev/zero of=/dev/sa1 bs=2k count=1000
1000+0 records in
1000+0 records out
2048000 bytes transferred in 3.252421 secs (629685 bytes/sec)
# dd if=/dev/zero of=/dev/sa1 bs=4k count=1000
1000+0 records in
1000+0 records out
4096000 bytes transferred in 2.933208 secs (1396423 bytes/sec)
# dd if=/dev/zero of=/dev/sa1 bs=8k count=1000
1000+0 records in
1000+0 records out
8192000 bytes transferred in 3.567864 secs (2296052 bytes/sec)
# dd if=/dev/zero of=/dev/sa1 bs=16k count=1000
dd: /dev/sa1: Input/output error
1+0 records in
0+0 records out
0 bytes transferred in 0.000253 secs (0 bytes/sec)

There is no error message from the kernel related to that.

If I try to read an older backup tape (used 64k Tape Blocks for that):
# dd if=/dev/sa1 of=/dev/null bs=64k count=10
dd: /dev/sa1: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 0.000824 secs (0 bytes/sec)
#
... I get in /var/log/messages:

Jun 25 14:56:05 unicorn kernel: (sa1:sym0:0:6:0): 65536-byte tape record
bigger than supplied buffer

Nice ehy?

I've now booted kernel.old from Mar 15 and the problems are gone on both
drives.

Please check this.

Regards,

Holm

PS: Please Cc me, I'm not on that list anymore.
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
www.tsht.de, [hidden email], Fax +49 3731 74200, Mobil: 0172 8790 741

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"

Kenneth D. Merry

Re: Kernel panic in FreeBSD-8.3 from UFS

On Mon, Jun 25, 2012 at 15:55:43 +0200, Holm Tiffe wrote:

> Kenneth D. Merry wrote:
>
> > On Tue, Jun 05, 2012 at 17:49:05 +0530, Desai, Kashyap wrote:
> > > Hi All,
> > >
> > > We found some potential area of memory leak in CAM layer.
> > > CAM XPT Memory leak is due to following function in scsi/scsi_all.c
> > >
> > > int
> > > scsi_command_string(struct ccb_scsiio *csio, struct sbuf *sb)
> > >
> > >
> > > In above function, CAM layer allocate memory for ccb device as below
> > > if ((cgd = (struct ccb_getdev*)xpt_alloc_ccb_nowait()) == NULL)
> > >
> > >
> > > _But_, unfortunately we never free the allocated memory and we see memory leak of 2K every time when someone is calling
> > > Scsi_command_string from kernel mode.
> > >
> > >
> > > Attached is a proposed patch for this issue.
> >
> > The patch looks good, I just committed it.
> >
> > Thanks!
> >
> > Ken
> > --
> > Kenneth Merry
> > [hidden email]
> > _______________________________________________
> > [hidden email] mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> > To unsubscribe, send any mail to "[hidden email]"
>
>
> It looks that this patch or something related to it broke my tape backups.
> I do have two SCSI Tapes connected to my system:
>
> # camcontrol devlist
> <IBM-SSG S53D073 C61E> at scbus0 target 0 lun 0 (pass0,da0)
> <IBM-SSG S53D073 C61E> at scbus0 target 1 lun 0 (pass1,da1)
> <IBM-SSG S53D073 C61A> at scbus0 target 2 lun 0 (pass2,da2)
> <IBM-SSG S53D073 C61A> at scbus0 target 3 lun 0 (pass3,da3)
> <TANDBERG SLR5 4/8GB =09:> at scbus1 target 5 lun 0 (pass4,sa0)
> <COMPAQ DLT4000 D887> at scbus1 target 6 lun 0 (pass5,sa1)
>
> an with an 8.3 stable from Jun 14 both of them arent able anymore to do
> blocksizes over 8k and 8k are only working sometimes (huh?!).

The change in the above email didn't get merged back to stable/8 until June
20th. So it isn't that.

There were no changes to the sa(4) driver in stable/8 from March 15th to
June 14th, but there were lots of other CAM changes.

> # mt -f /dev/sa1 status
> Mode Density Blocksize bpi Compression
> Current: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> ---------available modes---------
> 0: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> 1: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> 2: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> 3: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> ---------------------------------
> Current Driver State: at rest.
> ---------------------------------
> File Number: 0 Record Number: 0 Residual Count 0
>
> # dd if=/dev/zero of=/dev/sa1 bs=1k count=1000
> 1000+0 records in
> 1000+0 records out
> 1024000 bytes transferred in 4.330778 secs (236447 bytes/sec)
> # dd if=/dev/zero of=/dev/sa1 bs=2k count=1000
> 1000+0 records in
> 1000+0 records out
> 2048000 bytes transferred in 3.252421 secs (629685 bytes/sec)
> # dd if=/dev/zero of=/dev/sa1 bs=4k count=1000
> 1000+0 records in
> 1000+0 records out
> 4096000 bytes transferred in 2.933208 secs (1396423 bytes/sec)
> # dd if=/dev/zero of=/dev/sa1 bs=8k count=1000
> 1000+0 records in
> 1000+0 records out
> 8192000 bytes transferred in 3.567864 secs (2296052 bytes/sec)
> # dd if=/dev/zero of=/dev/sa1 bs=16k count=1000
> dd: /dev/sa1: Input/output error
> 1+0 records in
> 0+0 records out
> 0 bytes transferred in 0.000253 secs (0 bytes/sec)
>
> There is no error message from the kernel related to that.
>
> If I try to read an older backup tape (used 64k Tape Blocks for that):
> # dd if=/dev/sa1 of=/dev/null bs=64k count=10
> dd: /dev/sa1: Input/output error
> 0+0 records in
> 0+0 records out
> 0 bytes transferred in 0.000824 secs (0 bytes/sec)
> #
> ... I get in /var/log/messages:
>
> Jun 25 14:56:05 unicorn kernel: (sa1:sym0:0:6:0): 65536-byte tape record
> bigger than supplied buffer
>
> Nice ehy?
>
> I've now booted kernel.old from Mar 15 and the problems are gone on both
> drives.

It isn't obvious where the problem was introduced, unfortunately.

Could you do a binary search to figure out which revision broke things for
you?

Ken
--
Kenneth Merry
[hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"

Alexander Motin-3

Re: Kernel panic in FreeBSD-8.3 from UFS

On 06/25/12 18:53, Kenneth D. Merry wrote:

> On Mon, Jun 25, 2012 at 15:55:43 +0200, Holm Tiffe wrote:
>> Kenneth D. Merry wrote:
>>
>>> On Tue, Jun 05, 2012 at 17:49:05 +0530, Desai, Kashyap wrote:
>>>> Hi All,
>>>>
>>>> We found some potential area of memory leak in CAM layer.
>>>> CAM XPT Memory leak is due to following function in scsi/scsi_all.c
>>>>
>>>> int
>>>> scsi_command_string(struct ccb_scsiio *csio, struct sbuf *sb)
>>>>
>>>>
>>>> In above function, CAM layer allocate memory for ccb device as below
>>>> if ((cgd = (struct ccb_getdev*)xpt_alloc_ccb_nowait()) == NULL)
>>>>
>>>>
>>>> _But_, unfortunately we never free the allocated memory and we see memory leak of 2K every time when someone is calling
>>>> Scsi_command_string from kernel mode.
>>>>
>>>>
>>>> Attached is a proposed patch for this issue.
>>>
>>> The patch looks good, I just committed it.
>>>
>>> Thanks!
>>>
>>> Ken
>>> --
>>> Kenneth Merry
>>> [hidden email]
>>> _______________________________________________
>>> [hidden email] mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
>>> To unsubscribe, send any mail to "[hidden email]"
>>
>>
>> It looks that this patch or something related to it broke my tape backups.
>> I do have two SCSI Tapes connected to my system:
>>
>> # camcontrol devlist
>> <IBM-SSG S53D073 C61E> at scbus0 target 0 lun 0 (pass0,da0)
>> <IBM-SSG S53D073 C61E> at scbus0 target 1 lun 0 (pass1,da1)
>> <IBM-SSG S53D073 C61A> at scbus0 target 2 lun 0 (pass2,da2)
>> <IBM-SSG S53D073 C61A> at scbus0 target 3 lun 0 (pass3,da3)
>> <TANDBERG SLR5 4/8GB =09:> at scbus1 target 5 lun 0 (pass4,sa0)
>> <COMPAQ DLT4000 D887> at scbus1 target 6 lun 0 (pass5,sa1)
>>
>> an with an 8.3 stable from Jun 14 both of them arent able anymore to do
>> blocksizes over 8k and 8k are only working sometimes (huh?!).
>
> The change in the above email didn't get merged back to stable/8 until June
> 20th. So it isn't that.
>
> There were no changes to the sa(4) driver in stable/8 from March 15th to
> June 14th, but there were lots of other CAM changes.
>
>> # mt -f /dev/sa1 status
>> Mode Density Blocksize bpi Compression
>> Current: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
>> ---------available modes---------
>> 0: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
>> 1: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
>> 2: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
>> 3: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
>> ---------------------------------
>> Current Driver State: at rest.
>> ---------------------------------
>> File Number: 0 Record Number: 0 Residual Count 0
>>
>> # dd if=/dev/zero of=/dev/sa1 bs=1k count=1000
>> 1000+0 records in
>> 1000+0 records out
>> 1024000 bytes transferred in 4.330778 secs (236447 bytes/sec)
>> # dd if=/dev/zero of=/dev/sa1 bs=2k count=1000
>> 1000+0 records in
>> 1000+0 records out
>> 2048000 bytes transferred in 3.252421 secs (629685 bytes/sec)
>> # dd if=/dev/zero of=/dev/sa1 bs=4k count=1000
>> 1000+0 records in
>> 1000+0 records out
>> 4096000 bytes transferred in 2.933208 secs (1396423 bytes/sec)
>> # dd if=/dev/zero of=/dev/sa1 bs=8k count=1000
>> 1000+0 records in
>> 1000+0 records out
>> 8192000 bytes transferred in 3.567864 secs (2296052 bytes/sec)
>> # dd if=/dev/zero of=/dev/sa1 bs=16k count=1000
>> dd: /dev/sa1: Input/output error
>> 1+0 records in
>> 0+0 records out
>> 0 bytes transferred in 0.000253 secs (0 bytes/sec)
>>
>> There is no error message from the kernel related to that.

You may try to boot with verbose kernel messages and enable some CAM
debug with `camcontrol debug -I all` and then repeat your tests. It
should probably make kernel to tell more about errors.

>> If I try to read an older backup tape (used 64k Tape Blocks for that):
>> # dd if=/dev/sa1 of=/dev/null bs=64k count=10
>> dd: /dev/sa1: Input/output error
>> 0+0 records in
>> 0+0 records out
>> 0 bytes transferred in 0.000824 secs (0 bytes/sec)
>> #
>> ... I get in /var/log/messages:
>>
>> Jun 25 14:56:05 unicorn kernel: (sa1:sym0:0:6:0): 65536-byte tape record
>> bigger than supplied buffer
>>
>> Nice ehy?
>>
>> I've now booted kernel.old from Mar 15 and the problems are gone on both
>> drives.
>
> It isn't obvious where the problem was introduced, unfortunately.
>
> Could you do a binary search to figure out which revision broke things for
> you?

--
Alexander Motin
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"

Holm Tiffe

Re: Kernel panic in FreeBSD-8.3 from UFS

In reply to this post by Kenneth D. Merry

Kenneth D. Merry wrote:

> On Mon, Jun 25, 2012 at 15:55:43 +0200, Holm Tiffe wrote:
> > Kenneth D. Merry wrote:
> >
> > > On Tue, Jun 05, 2012 at 17:49:05 +0530, Desai, Kashyap wrote:
> > > > Hi All,
> > > >
> > > > We found some potential area of memory leak in CAM layer.
> > > > CAM XPT Memory leak is due to following function in scsi/scsi_all.c
> > > >
> > > > int
> > > > scsi_command_string(struct ccb_scsiio *csio, struct sbuf *sb)
> > > >
> > > >
> > > > In above function, CAM layer allocate memory for ccb device as below
> > > > if ((cgd = (struct ccb_getdev*)xpt_alloc_ccb_nowait()) == NULL)
> > > >
> > > >
> > > > _But_, unfortunately we never free the allocated memory and we see memory leak of 2K every time when someone is calling
> > > > Scsi_command_string from kernel mode.
> > > >
> > > >
> > > > Attached is a proposed patch for this issue.
> > >
> > > The patch looks good, I just committed it.
> > >
> > > Thanks!
> > >
> > > Ken
> > > --
> > > Kenneth Merry
> > > [hidden email]
> > > _______________________________________________
> > > [hidden email] mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> > > To unsubscribe, send any mail to "[hidden email]"
> >
> >
> > It looks that this patch or something related to it broke my tape backups.
> > I do have two SCSI Tapes connected to my system:
> >
> > # camcontrol devlist
> > <IBM-SSG S53D073 C61E> at scbus0 target 0 lun 0 (pass0,da0)
> > <IBM-SSG S53D073 C61E> at scbus0 target 1 lun 0 (pass1,da1)
> > <IBM-SSG S53D073 C61A> at scbus0 target 2 lun 0 (pass2,da2)
> > <IBM-SSG S53D073 C61A> at scbus0 target 3 lun 0 (pass3,da3)
> > <TANDBERG SLR5 4/8GB =09:> at scbus1 target 5 lun 0 (pass4,sa0)
> > <COMPAQ DLT4000 D887> at scbus1 target 6 lun 0 (pass5,sa1)
> >
> > an with an 8.3 stable from Jun 14 both of them arent able anymore to do
> > blocksizes over 8k and 8k are only working sometimes (huh?!).
>
> The change in the above email didn't get merged back to stable/8 until June
> 20th. So it isn't that.
>
> There were no changes to the sa(4) driver in stable/8 from March 15th to
> June 14th, but there were lots of other CAM changes.
>
> > # mt -f /dev/sa1 status
> > Mode Density Blocksize bpi Compression
> > Current: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> > ---------available modes---------
> > 0: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> > 1: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> > 2: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> > 3: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> > ---------------------------------
> > Current Driver State: at rest.
> > ---------------------------------
> > File Number: 0 Record Number: 0 Residual Count 0
> >
> > # dd if=/dev/zero of=/dev/sa1 bs=1k count=1000
> > 1000+0 records in
> > 1000+0 records out
> > 1024000 bytes transferred in 4.330778 secs (236447 bytes/sec)
> > # dd if=/dev/zero of=/dev/sa1 bs=2k count=1000
> > 1000+0 records in
> > 1000+0 records out
> > 2048000 bytes transferred in 3.252421 secs (629685 bytes/sec)
> > # dd if=/dev/zero of=/dev/sa1 bs=4k count=1000
> > 1000+0 records in
> > 1000+0 records out
> > 4096000 bytes transferred in 2.933208 secs (1396423 bytes/sec)
> > # dd if=/dev/zero of=/dev/sa1 bs=8k count=1000
> > 1000+0 records in
> > 1000+0 records out
> > 8192000 bytes transferred in 3.567864 secs (2296052 bytes/sec)
> > # dd if=/dev/zero of=/dev/sa1 bs=16k count=1000
> > dd: /dev/sa1: Input/output error
> > 1+0 records in
> > 0+0 records out
> > 0 bytes transferred in 0.000253 secs (0 bytes/sec)
> >
> > There is no error message from the kernel related to that.
> >
> > If I try to read an older backup tape (used 64k Tape Blocks for that):
> > # dd if=/dev/sa1 of=/dev/null bs=64k count=10
> > dd: /dev/sa1: Input/output error
> > 0+0 records in
> > 0+0 records out
> > 0 bytes transferred in 0.000824 secs (0 bytes/sec)
> > #
> > ... I get in /var/log/messages:
> >
> > Jun 25 14:56:05 unicorn kernel: (sa1:sym0:0:6:0): 65536-byte tape record
> > bigger than supplied buffer
> >
> > Nice ehy?
> >
> > I've now booted kernel.old from Mar 15 and the problems are gone on both
> > drives.
>
> It isn't obvious where the problem was introduced, unfortunately.
>
> Could you do a binary search to figure out which revision broke things for
> you?
>
> Ken
> --
> Kenneth Merry
> [hidden email]

Sorry, I (really) don't have the time to do that.
But I've cvsupped and built a world and a kernel from today, the result
is, that the error is gone, but the performance is somewhere below
the basement:

0: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
1: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
2: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
3: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
---------------------------------
Current Driver State: at rest.
---------------------------------
File Number: 0 Record Number: 0 Residual Count 0
# dd if=/dev/zero of=/dev/sa1 bs=64k count=10000
10000+0 records in
10000+0 records out
655360000 bytes transferred in 125.909593 secs (5205005 bytes/sec)
#

It think the DLT drive should be streaming while writing 64K Blocks from
/dev/zero, shouldn't it? No, it moves back and forward all the time.

:-|

This is only the first half of the truth, here is the 2nd:

# dd of=/dev/null if=/dev/sa1 bs=64k

10000+0 records in
10000+0 records out
655360000 bytes transferred in 211.903853 secs (3092723 bytes/sec)
#
#
# dd of=/dev/null if=/dev/sa1 bs=64k
10000+0 records in
10000+0 records out
655360000 bytes transferred in 211.942410 secs (3092161 bytes/sec)
#

This thing is reading even slower than writing, the Drive makes pauses of
almost 10 seconds between the really short runs. The system is idle.

Please Guys, Im running -Stable and I'm doing this since I really don't
like such kind of features. Could I please get back a stable system with
the ability to backup my data?

Regards,

Holm

$ vmstat -i
interrupt total rate
irq0: clk 2768221 1000
irq1: atkbd0 13413 4
irq3: uart1 79 0
irq5: pcm0 rl0+ 977 0
irq6: fdc0 20 0
irq7: ppc0 1 0
irq8: rtc 2811413 1015
irq11: ahd0 ehci0 15654 5
irq12: psm0 27228 9
irq15: de0 sym0+++* 52176 18
Total 5689182 2055
$

# camcontrol devlist
<IBM-SSG S53D073 C61E> at scbus0 target 0 lun 0 (pass0,da0)
<IBM-SSG S53D073 C61E> at scbus0 target 1 lun 0 (pass1,da1)
<IBM-SSG S53D073 C61A> at scbus0 target 2 lun 0 (pass2,da2)
<IBM-SSG S53D073 C61A> at scbus0 target 3 lun 0 (pass3,da3)
<TANDBERG SLR5 4/8GB =09:> at scbus1 target 5 lun 0 (sa0,pass4)
<COMPAQ DLT4000 D887> at scbus1 target 6 lun 0 (sa1,pass5)

# uname -a
FreeBSD unicorn.tsht.lan 8.3-STABLE FreeBSD 8.3-STABLE #24: Mon Jun 25
20:00:51 CEST 2012
[hidden email]:/data/FreeBSD/obj/data/FreeBSD/src/sys/UNICORN i386
#

Copyright (c) 1992-2012 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.3-STABLE #24: Mon Jun 25 20:00:51 CEST 2012
[hidden email]:/data/FreeBSD/obj/data/FreeBSD/src/sys/UNICORN i386
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) XP 3000+ (2109.49-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x6a0 Family = 6 Model = a Stepping = 0
Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
AMD Features=0xc0400800<SYSCALL,MMX+,3DNow!+,3DNow!>
real memory = 2147483648 (2048 MB)
avail memory = 2092101632 (1995 MB)
kbd1 at kbdmux0
acpi0: <GBT AWRDACPI> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 7fef0000 (3) failed
cpu0: <ACPI CPU> on acpi0
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
agp0: <VIA 8377 (Apollo KT400/KT400A/KT600) host to PCI bridge> on hostb0
agp0: aperture size is 128M
pcib1: <PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xa000-0xa0ff mem 0xd8000000-0xdfffffff,0xe9000000-0xe900ffff irq 15 at device 0.0 on pci1
drm0: <ATI Radeon RV280 9200 SE> on vgapci0
info: [drm] AGP at 0xd0000000 128MB
info: [drm] Initialized radeon 1.31.0 20080613
vgapci1: <VGA-compatible display> mem 0xe0000000-0xe7ffffff,0xe9010000-0xe901ffff at device 0.1 on pci1
de0: <Digital 21040 Ethernet> port 0xb000-0xb07f mem 0xeb002000-0xeb00207f irq 15 at device 9.0 on pci0
de0: Cogent 21040 [10Mb/s] pass 2.3
de0: WARNING: using obsoleted if_watchdog interface
de0: Ethernet address: 00:00:92:90:09:8d
de0: [ITHREAD]
ahd0: <Adaptec 29320LP Ultra320 SCSI adapter> port 0xb400-0xb4ff,0xb800-0xb8ff mem 0xeb000000-0xeb001fff irq 11 at device 11.0 on pci0
ahd0: [ITHREAD]
aic7901A: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66MHz, 512 SCBs
puc0: <Oxford Semiconductor OX16PCI952 UARTs> port 0xbc00-0xbc07,0xc000-0xc007,0xc400-0xc41f mem 0xeb003000-0xeb003fff,0xeb004000-0xeb004fff irq 15 at device 12.0 on pci0
puc0: [FILTER]
uart2: <16550 or compatible> at port 1 on puc0
uart2: [FILTER]
uart3: <16550 or compatible> at port 2 on puc0
uart3: [FILTER]
sym0: <810a> port 0xc800-0xc8ff mem 0xeb005000-0xeb0050ff irq 15 at device 13.0 on pci0
sym0: No NVRAM, ID 7, Fast-10, SE, parity checking
sym0: [ITHREAD]
uhci0: <VIA 83C572 USB controller> port 0xcc00-0xcc1f irq 15 at device 16.0 on pci0
uhci0: [ITHREAD]
usbus0 on uhci0
uhci1: <VIA 83C572 USB controller> port 0xd000-0xd01f irq 15 at device 16.1 on pci0
uhci1: [ITHREAD]
usbus1 on uhci1
uhci2: <VIA 83C572 USB controller> port 0xd400-0xd41f irq 5 at device 16.2 on pci0
uhci2: [ITHREAD]
usbus2 on uhci2
ehci0: <VIA VT6202 USB 2.0 controller> mem 0xeb006000-0xeb0060ff irq 11 at device 16.3 on pci0
ehci0: [ITHREAD]
usbus3: EHCI version 1.0
usbus3 on ehci0
isab0: <PCI-ISA bridge> at device 17.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <VIA 8235 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 17.1 on pci0
ata0: <ATA channel> at channel 0 on atapci0
ata0: [ITHREAD]
ata1: <ATA channel> at channel 1 on atapci0
ata1: [ITHREAD]
pcm0: <VIA VT8235> port 0xdc00-0xdcff irq 5 at device 17.5 on pci0
pcm0: [ITHREAD]
pcm0: <Avance Logic ALC655 AC97 Codec>
pcm0: <VIA DXS Enabled: DXS 4 / SGD 1 / REC 1>
rl0: <RealTek 8139 10/100BaseTX> port 0xe000-0xe0ff mem 0xeb007000-0xeb0070ff irq 5 at device 19.0 on pci0
miibus0: <MII bus> on rl0
rlphy0: <RealTek internal media interface> PHY 0 on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl0: Ethernet address: 00:0d:61:c3:c4:5a
rl0: [ITHREAD]
atrtc0: <AT realtime clock> port 0x70-0x73 irq 8 on acpi0
fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
fd1: <1200-KB 5.25" drive> on fdc0 drive 1
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: [FILTER]
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
uart1: [FILTER]
ppc0: <Parallel port> port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
ppc0: [ITHREAD]
ppbus0: <Parallel port bus> on ppc0
plip0: <PLIP network interface> on ppbus0
plip0: [ITHREAD]
lpt0: <Printer> on ppbus0
lpt0: [ITHREAD]
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model MouseMan+, device ID 0
pmtimer0 on isa0
orm0: <ISA Option ROMs> at iomem 0xc0000-0xccfff,0xd0000-0xd97ff pnpid ORM0000 on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounter "TSC" frequency 2109485719 Hz quality 800
Timecounters tick every 1.000 msec
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 480Mbps High Speed USB v2.0
ugen0.1: <VIA> at usbus0
uhub0: <VIA UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <VIA> at usbus1
uhub1: <VIA UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
ugen2.1: <VIA> at usbus2
uhub2: <VIA UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2
ugen3.1: <VIA> at usbus3
uhub3: <VIA EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus3
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
uhub3: 6 ports with 6 removable, self powered
(probe20:sym0:0:5:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe20:sym0:0:5:0): CAM status: SCSI Status Error
(probe20:sym0:0:5:0): SCSI status: Check Condition
(probe20:sym0:0:5:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred)
(probe21:sym0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe21:sym0:0:6:0): CAM status: SCSI Status Error
(probe21:sym0:0:6:0): SCSI status: Check Condition
(probe21:sym0:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred)
da0 at ahd0 bus 0 scbus0 target 0 lun 0
da0: <IBM-SSG S53D073 C61E> Fixed Direct Access SCSI-3 device
da0: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
da0: Command Queueing enabled
da0: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C)
da1 at ahd0 bus 0 scbus0 target 1 lun 0
da1: <IBM-SSG S53D073 C61E> Fixed Direct Access SCSI-3 device
da1: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
da1: Command Queueing enabled
da1: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C)
da2 at ahd0 bus 0 scbus0 target 2 lun 0
da2: <IBM-SSG S53D073 C61A> Fixed Direct Access SCSI-3 device
da2: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
da2: Command Queueing enabled
da2: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C)
da3 at ahd0 bus 0 scbus0 target 3 lun 0
da3: <IBM-SSG S53D073 C61A> Fixed Direct Access SCSI-3 device
da3: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
da3: Command Queueing enabled
da3: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C)
sa0 at sym0 bus 0 scbus1 target 5 lun 0
sa0: <TANDBERG SLR5 4/8GB =09:> Removable Sequential Access SCSI-2 device
sa0: 4.166MB/s transfers (4.166MHz, offset 8)
sa1 at sym0 bus 0 scbus1 target 6 lun 0
sa1: <COMPAQ DLT4000 D887> Removable Sequential Access SCSI-2 device
sa1: 10.000MB/s transfers (10.000MHz, offset 8)
GEOM_CONCAT: Device gc0d created (id=2065581164).
GEOM_CONCAT: Disk da0d attached to gc0d.
GEOM_CONCAT: Device data created (id=2038144655).
GEOM_CONCAT: Disk da0g attached to data.
GEOM_MIRROR: Device mirror/gm0a launched (2/2).
GEOM_CONCAT: Disk da1d attached to gc0d.
GEOM_CONCAT: Device gc0d activated.
GEOM_MIRROR: Device mirror/gm0e launched (2/2).
GEOM_MIRROR: Device mirror/gm0f launched (2/2).
GEOM_CONCAT: Disk da1g attached to data.
GEOM_CONCAT: Disk da2a attached to data.
GEOM_CONCAT: Disk da2b attached to data.
GEOM_CONCAT: Device data activated.
Trying to mount root from ufs:/dev/mirror/gm0a
bridge0: Ethernet address: 02:82:44:4d:6c:00
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
www.tsht.de, [hidden email], Fax +49 3731 74200, Mobil: 0172 8790 741

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"

Joerg Wunsch

Re: Kernel panic in FreeBSD-8.3 from UFS

As Holm Tiffe wrote:

> ..., but the performance is somewhere below
> the basement:
>
> 0: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> 1: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> 2: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> 3: 0x1a:DLTapeIV(20GB) variable 81633 IDRC
> ---------------------------------
> Current Driver State: at rest.
> ---------------------------------
> File Number: 0 Record Number: 0 Residual Count 0
> # dd if=/dev/zero of=/dev/sa1 bs=64k count=10000
> 10000+0 records in
> 10000+0 records out
> 655360000 bytes transferred in 125.909593 secs (5205005 bytes/sec)

I don't think 5 MB/s is a poor value for a DLT-2000. On a
DLT-8000 (with wide SCSI), I get a little more than 10 MB/s
provided the data source is fast enough.

> It think the DLT drive should be streaming while writing 64K Blocks from
> /dev/zero, shouldn't it? No, it moves back and forward all the time.

Turn off hardware compression, the drive cannot compress your zeros as
fast as you want.

> This thing is reading even slower than writing, the Drive makes pauses of
> almost 10 seconds between the really short runs.

That's indeed poor.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"