From owner-freebsd-bugs Fri Aug 11 3:52:13 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id BB21437B960; Fri, 11 Aug 2000 03:52:08 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id LAA68053; Fri, 11 Aug 2000 11:52:06 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id LAA00847; Fri, 11 Aug 2000 11:51:58 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200008111051.LAA00847@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Josef Karthauser Cc: Brian Somers , freebsd-bugs@FreeBSD.ORG, sheldonh@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: kern/20375: APM doesn't work properly! Suspend/resume/suspend/hang In-Reply-To: Message from Josef Karthauser of "Fri, 11 Aug 2000 01:21:35 BST." <20000811012135.A353@pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Aug 2000 11:51:58 +0100 From: Brian Somers Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What happens if you change the tsleep to DELAY() ? It should sort out the panic, but do you still die in the second suspend ? The bit I'm *really* interested in is why this hasn't happened for you 'till now ? It's been happening to me since FreeBSDCon (well, for the entire life of this laptop) !!! Index: ata-all.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v retrieving revision 1.62 diff -u -r1.62 ata-all.c --- ata-all.c 2000/08/08 14:57:36 1.62 +++ ata-all.c 2000/08/11 10:49:54 @@ -1281,10 +1281,7 @@ if (*mask == 0x03) /* wait for both master & slave */ if (!(status0 & ATA_S_BUSY) && !(status1 & ATA_S_BUSY)) break; - if (ata_delayed_attach) - DELAY(100); - else - tsleep(&ata_delayed_attach, PRIBIO, "atarst", 1); + DELAY(100); } DELAY(1); outb(scp->altioaddr, ATA_A_4BIT); > On Thu, Aug 10, 2000 at 12:22:15PM +0100, Josef Karthauser wrote: > > On Thu, Aug 10, 2000 at 12:12:17PM +0100, Brian Somers wrote: > > > > > > With the dodgy call to tsleep (passing a NULL as the first arg) I was > > > getting a panic in the KASSERT in tsleep(), but once that was fixed > > > I'm back where I can suspend, resume then lock up when I try to suspend > > > again. > > > > > > It'd be worth looking at a crash trace if you can get one. > > > > Mine was working once _until_ the tsleep fix! I'll recompile the > > kernel again afresh and check again. My guess is that this tsleep > > is independant to my original report. > > To repeat - even though it looks like the KASSERT in tsleep fixed the > ata code for you, it's still broken for me on the head branch. Upon > a resume the debugger kicks in at tsleep within atareset. > > > My original problem is the same as what you report above. I've > > tried with a cutdown kernel, to remove the possibility that it's > > pcm, etc, but it does appear to be more fundamental than that. I > > don't get a crash, just a hang, so no coredump or back trace is > > available. :( > > I've gone back to 1/Aug/2000 for the ata code to get around that local > problem which isn't necessarily the direct cause of the suspend/resume > hang that you mention, and which appears to be the same as the one that > I opened this PR under. > > My suspicion is that something isn't resuming properly and when asked > to suspend a second time it's hanging the system. I wish that I could > find our where the hang is occuring. > > Joe > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message