Date: Sun, 17 Sep 2000 05:31:45 -0700 From: David Greenman <dg@root.com> To: mike ryan <msr@elision.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: fxp suspend/resume hangs Message-ID: <200009171231.FAA26513@implode.root.com> In-Reply-To: Your message of "Sun, 17 Sep 2000 00:27:33 EDT." <20000917002733.A37043@medianstrip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>appended below is an excerpt from a message sent to -stable earlier
>tonight, containing content of a type which kris kenneway correctly
>suggested would find a more suitable audience on -current.
>
>in summary: PR kern/18756 contains a patch (against -stable, alas,
>sorry) which fixes kernel hangs in the fxp driver on some laptops
>after a resume from suspend. while quite a few people appear to be
>using this patch successfully, it hasn't been committed -- david
>greenman had an entirely reasonable objection to one aspect of the
>patch's behavior.
>
>unfortunately, my knowledge of the kernel isn't sufficient to
>adequately address david's concerns, and though i've mailed him to
>ask for guidance twice over the past 4 months, i haven't received a
>response. that's probably my fault, i probably should have been
>mailing -current to being with.
I can only find the 5/22 email regarding this, so I seem to have missed
your second message. With over a thousand emails a day coming into my inbox,
this shouldn't be too surprising. My response to the 5/22 message was this:
...
This could be a problem. If an interrupt occurs, it must be acknowledged
otherwise you'll be stuck in an infinit loop - PCI interrupts are level
sensitive and must be cleared in the ISR.
...
In short, while it may fix a hang in your laptop case, it opens the driver
up to a hang if an unexpected interrupt occurs while IFF_RUNNING is clear. I
think this is dangerous enough that I don't think the code should not be
compiled as part of the standard driver. One just cannot ignore level-
sensitive PCI interrupts.
>if anybody can offer any suggestions as to how to move forward with
>getting this patch to the point where it can be committed, i'd
>certainly appreciate it. alternately, any feedback on whether the
>patch is necessary and/or functional on your machine, laptop or no,
>would be interesting.
>> i wouldn't be at all surprised if there were a better approach than
>> simply ignoring interrupts when the device isn't running, but it's
>> not clear to me what that would be. if anybody has any suggestions
>> as to how to clean this up, i'm all ears. alternately, if any
>> committers want to take this on, that'd be swell too.
Someone needs to find out what the laptop is doing to the STATACK register
that causes a hang when it is accessed. Failing any better resolution, I guess
that the objected-to change could be committed with an ifdef.
-DG
David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
President, TeraSolutions, Inc. - http://www.terasolutions.com
Pave the road of life with opportunities.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009171231.FAA26513>