From owner-freebsd-current@FreeBSD.ORG Tue Dec 23 17:38:39 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 D5ACF16A4CE for ; Tue, 23 Dec 2003 17:38:39 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 5CBEE43D49 for ; Tue, 23 Dec 2003 17:38:37 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 93305 invoked by uid 1000); 24 Dec 2003 01:38:39 -0000 Date: Tue, 23 Dec 2003 17:38:39 -0800 (PST) From: Nate Lawson To: current@freebsd.org Message-ID: <20031223172258.B93254@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 24 Dec 2003 05:12:55 -0800 Subject: More info: ATA hang on resume 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: Wed, 24 Dec 2003 01:38:39 -0000 I did some more tracing on this and found that the reset of ata0 is indeed hanging. My machine does not have an APIC, just a simple PIC laptop (IBM T23). I've disabled most devices and am not using atapi-cam. atapci0@pci0:31:1: class=0x01018a card=0x02201014 chip=0x248a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CAM (ICH3-M) UltraATA/100 EIDE Controller' atapci0: port 0x1860-0x186f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] ad0: 19077MB [41344/15/63] at ata0-master UDMA100 acd0: CDRW at ata1-master PIO4 After putting in some debugging prints, I found that the hang is happening in this call stack: ata_controlcmd(ATA_SF_SETXFER) ata-chipset.c:874 ata_intel_new_setmode() ata-chipset.c:851 ch->device[MASTER].setmode(..., ATA_PIO_MAX) ata-all.c:681 ata_identify_devices() ata-all.c:276 ata_reinit() ata-all.c:231 I don't know what in ata_controlcmd() is hanging. If I remove the call to setting ATA_PIO_MAX so I just do the call to set ATA_DMA_MAX, it still hangs in that call in the same place. Are you sure it's legal to call ATA_SF_SETXFER with a mode of ATA_PIO_MAX (0x0f) or ATA_DMA_MAX (0x4f)? I tried changing these calls to set PIO4 and UDMA5 just in case, but no luck. What information can I find to help you track down this regression? You fixed suspend/resume early October (I think) although it broke again sometime in November. Thanks, -Nate