From owner-freebsd-current@FreeBSD.ORG Sun Nov 23 15:12:41 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80E5716A4CE; Sun, 23 Nov 2003 15:12:41 -0800 (PST) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B140C43FE9; Sun, 23 Nov 2003 15:12:38 -0800 (PST) (envelope-from netch@iv.nn.kiev.ua) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id hBNNCbbC001553; Mon, 24 Nov 2003 01:12:37 +0200 (EET) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.12.9p2/8.12.9) id hANNAeK2000521; Mon, 24 Nov 2003 01:10:40 +0200 (EET) (envelope-from netch) Date: Mon, 24 Nov 2003 01:10:40 +0200 From: Valentin Nechayev To: current@freebsd.org Message-ID: <20031123231040.GA375@iv.nn.kiev.ua> References: <20031122110810.GA22130@iv.nn.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031122110810.GA22130@iv.nn.kiev.ua> X-42: On Organization: Dark side of coredump Subject: ATAng lockups (Re: geom<->ata forever cycle) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2003 23:12:41 -0000 Sat, Nov 22, 2003 at 13:08:10, netch (Valentin Nechayev) wrote about "geom<->ata forever cycle": VN> 5.1-current of 2003-11-20 hangs during kernel initialization with forever VN> cycle around geom partitioning detection and ATA read failure. VN> Message rate is too fast to record, no stopping is available, no serial VN> console. VN> Previous 5-current on this machine was of 2003-05-23. VN> How to diagnose? Well, I restricted time interval to between 2003-08-18 and 2003-08-25, so it is ATAng. Also tested 2003-11-20 and 2003-10-06 with the same result. Different poses were seen: - forever cycle around GEOM detecting - simple lockup - panic("initiate_write_inodeblock_ufs1: already started") - another kinds of panic and all have common sign - impossibility of driver to dig itself out of lockup (switch to PIO, reset bus, etc.) Dirty fix works to set hw.ata.ata_dma=0 in loader; moreover, `atacontrol mode 1 udma100 -' doesn't cause problems, but `atacontrol mode 0 udma33 -' drops system to broken state in a few minutes. Please say how to dig this problem. Full verbose dmesg.boot (from 2003-08-18 kernel) and config (unchanged) was put in previous letters and can be resent personally. Entries, bound with ATA, in first problematic (2003-08-25) dmesg.boot: pcib0: at pcibus 0 on motherboard atapci0: port 0xf000-0xf00f at device 31.1 on pci0 ata0: pre reset mask=03 ostat0=50 ostat2=00 ata0-master: ATAPI 00 00 ata0-slave: ATAPI 14 eb ata0: after reset mask=03 stat0=50 stat1=00 ata0-master: ATA 01 a5 ata0: devices=09 ata0: at 0x1f0 irq 14 on atapci0 ata0-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ata0-master: pio=0x0c wdma=0x22 udma=0x44 cable=40pin ad0: setting PIO4 on Intel ICH2 chip ad0: ATA-4 disk at ata0-master ad0: 14664MB (30033360 sectors), 29795 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, PIO4 acd0: setting PIO4 on Intel ICH2 chip acd0: CDROM drive at ata0 as slave acd0: read 6890KB/s (6890KB/s), 128KB buffer, PIO4 (remind that it is with hw.ata.ata_dma=0) -netch-