From owner-freebsd-fs Fri Oct 11 7:58:46 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB1AA37B404; Fri, 11 Oct 2002 07:58:35 -0700 (PDT) Received: from mail0.lsil.com (mail0.lsil.com [147.145.40.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4500043E9E; Fri, 11 Oct 2002 07:58:35 -0700 (PDT) (envelope-from emoore@lsil.com) Received: from mhbs.lsil.com (mhbs.lsil.com [147.145.31.100]) by mail0.lsil.com (8.12.4/8.12.4) with ESMTP id g9BEpbHv001486; Fri, 11 Oct 2002 07:58:33 -0700 (PDT) Received: from atl1.se.lsil.com by mhbs.lsil.com with ESMTP; Fri, 11 Oct 2002 07:58:30 -0700 Received: by EXA-ATLANTA.se.lsil.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Oct 2002 10:58:29 -0400 Message-Id: <0E3FA95632D6D047BA649F95DAB60E5701529093@EXA-ATLANTA.se.lsil.com> From: "Moore, Eric Dean" 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 Date: Fri, 11 Oct 2002 10:58:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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