>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.


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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to