Date: Fri, 11 Oct 2002 10:58:27 -0400 From: "Moore, Eric Dean" <emoore@lsil.com> To: dillon@FreeBSD.ORG, bde@FreeBSD.ORG, alc@FreeBSD.ORG Cc: developers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: buf_daemon - system freeze pulling power - help Message-ID: <0E3FA95632D6D047BA649F95DAB60E5701529093@EXA-ATLANTA.se.lsil.com>
next in thread | raw e-mail | index | archive | help
I have installed freebsd 4.6 onto a IDE drive connected to motherboard ide
controller. A second hard drive is connected another controller and mounted
with UFS file system. On the 2nd drive I'm run heavy IO for several minutes,
then pull power to this drive to simulate hard error situation( a real test
case requested by our customer). Within 5 minutes the system freezes. When I
mean freeze, the system doesn't respond to any keyboard actions. The only
thing the keyboard recognizes is CNTR^ALT^ESC; e.g. ddb or gdb. I have
replicated this issue on several different platforms, so I don't think its
hardware dependent. As this doesn't freeze system for same hardware under
Linux, the customer would expect this to work as well under freebsd.
Please note, I have placed a 2nd drive(which power is pulled during heavy
IO) to different controllers, both
IDE drives and SCSI drives, and it freezes in all cases. I see it occur
with both CAM and Block device drivers under freebsd. The mide driver is a
driver I'm developing for our IDE controller.
(1) aic7899W ( loading the ahc driver - CAM driver )
(2) any AMI megaraid controller ( loading amr driver, compiled to expose
logical drives through CAM interface )
(3) any AMI megaraid controller ( loading amr driver, compiled to expose
logical drives using amrd block interface )
(3) ide controller CMD649 ( loading the atapi driver built into freebsd -
Block driver )
(4) ide controller CMD649 ( loading my mide soft raid driver - CAM driver )
I have been conversing with Justin Gibb's - he suggested that I return
CAM_SEL_TIMEOUT; when I do that I get the "Invalidate Pack" message in the
da driver, then the system hangs for any controller I use. I'm able to go
into gdb or ddb. The problem seems to be in the buf_daemon. See below are
three different stack traces ( occurred three diff times).
---------------------------------------------------------
Stack trace exhibit #1 ( using gdb )
#1 0xc0342da2 in scgetc (sc=0xc0450a20, flags=0x2) at
../../dev/syscons/syscons.c:3149
#2 0xc033f615 in sckbdevent (thiskbd=0xc04495e0, event=0x0, arg=0xc0450a20)
at ../../dev/syscons/syscons.c:616
#3 0xc0336fee in atkbd_intr (kbd=0xc04495e0, arg=0x0) at
../../dev/kbd/atkbd.c:462
#4 0xc0365078 in atkbd_isa_intr (arg=0xc04495e0) at
../../isa/atkbd_isa.c:140
#5 0xc03534a3 in pmap_qremove (va=0xcaa66000, count=0x10) at
machine/cpufunc.h:281
#6 0xc0213508 in cluster_callback (bp=0xc6842f94) at
../../kern/vfs_cluster.c:525
#7 0xc021133c in biodone (bp=0xc6842f94) at ../../kern/vfs_bio.c:2698
#8 0xc0133e73 in dastrategy (bp=0xc6842f94) at ../../cam/scsi/scsi_da.c:752
#9 0xc01f3675 in diskstrategy (bp=0xc6842f94) at ../../kern/subr_disk.c:251
#10 0xc02224a0 in spec_strategy (ap=0xcd39ee6c) at
../../miscfs/specfs/spec_vnops.c:479
#11 0xc0221ec9 in spec_vnoperate (ap=0xcd39ee6c) at
../../miscfs/specfs/spec_vnops.c:119
#12 0xc02f84d1 in ufs_vnoperatespec (ap=0xcd39ee6c) at
../../ufs/ufs/ufs_vnops.c:2440
#13 0xc02f7dd1 in ufs_strategy (ap=0xcd39eeb0) at vnode_if.h:944
#14 0xc02f84a1 in ufs_vnoperate (ap=0xcd39eeb0) at
../../ufs/ufs/ufs_vnops.c:2422
#15 0xc020ef9a in bwrite (bp=0xc6842f94) at vnode_if.h:944
#16 0xc02146c2 in vop_stdbwrite (ap=0xcd39eeec) at
../../kern/vfs_default.c:331
#17 0xc021451d in vop_defaultop (ap=0xcd39eeec) at
../../kern/vfs_default.c:150
#18 0xc02f84a1 in ufs_vnoperate (ap=0xcd39eeec) at
../../ufs/ufs/ufs_vnops.c:2422
#19 0xc020f2ea in bawrite (bp=0xc6842f94) at vnode_if.h:1193
#20 0xc0213d8b in cluster_wbuild (vp=0xcde6e0c0, size=0x2000,
start_lbn=0x1e2, len=0x10)
at ../../kern/vfs_cluster.c:945
#21 0xc020fe4c in vfs_bio_awrite (bp=0xc689622c) at
../../kern/vfs_bio.c:1453
#22 0xc0210596 in flushbufqueues () at ../../kern/vfs_bio.c:1889
#23 0xc021042d in buf_daemon () at ../../kern/vfs_bio.c:1814
---------------------------------------------------------
Stack trace exhibit #2 ( using gdb )
n lockmgr (lkp=0xc6843a1c, flags=0x10002, interlkp=0xc0450fe4, p=0xcc300920)
at ../../kern/kern_lock.c:355
#7 0xc0306769 in initpbuf (bp=0xc68439f4) at ../../sys/buf.h:286
#8 0xc030680e in getpbuf (pfreecnt=0xc040672c) at ../../vm/vm_pager.c:401
#9 0xc02139e8 in cluster_wbuild (vp=0xcde60700, size=0x4000,
start_lbn=0xd4, len=0x4)
at ../../kern/vfs_cluster.c:785
#10 0xc020fe4c in vfs_bio_awrite (bp=0xc685e5ec) at
../../kern/vfs_bio.c:1453
#11 0xc0210596 in flushbufqueues () at ../../kern/vfs_bio.c:1889
#12 0xc021042d in buf_daemon () at ../../kern/vfs_bio.c:1814
---------------------------------------------------------
Stack trace exhibit #3 ( using ddb )
vm_page_set_validclean
vm_page_set_valid
vfs_busy_pages
bwrite
vop_stdbwrite
vop_defaulttop
ufs_vnoperate
bawrite
cluster_wbuild
vfs_bio_awrite
flushbufqueues
buf_daemon
fork_trampoline
Eric Moore
> RAID Storage Adapters Division
> LSI Logic Corporation
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0E3FA95632D6D047BA649F95DAB60E5701529093>