Date: Fri, 11 Aug 2000 04:00:03 -0700 (PDT) From: Brian Somers <brian@Awfulhak.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/20375: APM doesn't work properly! Suspend/resume/suspend/hang Message-ID: <200008111100.EAA52233@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/20375; it has been noted by GNATS.
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
Date: Fri, 11 Aug 2000 11:51:58 +0100
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?200008111100.EAA52233>