Date: Fri, 11 Aug 2000 11:51:58 +0100 From: Brian Somers <brian@Awfulhak.org> To: Josef Karthauser <joe@pavilion.net> Cc: Brian Somers <brian@Awfulhak.org>, freebsd-bugs@FreeBSD.ORG, sheldonh@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: kern/20375: APM doesn't work properly! Suspend/resume/suspend/hang Message-ID: <200008111051.LAA00847@hak.lan.Awfulhak.org> In-Reply-To: Message from Josef Karthauser <joe@pavilion.net> of "Fri, 11 Aug 2000 01:21:35 BST." <20000811012135.A353@pavilion.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008111051.LAA00847>