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.

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.

----- Forwarded message from mike ryan <[EMAIL PROTECTED]> -----

> From: mike ryan <[EMAIL PROTECTED]>
> Subject: ds1 pcm and fxp suspend/resume bugs (was Re: I'll be rolling a 4.1.1 
>release on September 25th)
> Date: Sat, 16 Sep 2000 22:53:53 -0400

[ background snipped: jkh announced 4.1.1, pir asked about some patches ] 

> the fxp fix (PR 18756), on the other hand, has gone nowhere.  david
> greenman expressed concern about one bit of the patch (see the PR
> for details), then disappeared.  i've sent him a couple messages (on
> may 22, also in the PR, and again august 26th in private mail)
> asking if he had any advice on how to fix the fix, but i've gotten
> no response.  i saw a message on cvs-all a few days ago suggesting
> that he had "resigned in a huff a few months ago", so perhaps this
> got orphaned then?
> more importantly, maybe somebody on this list can help?  briefly:
> after a suspend/resume on some sony laptops, the fxp device needs to
> have certain PCI registers reset, notably including the memory
> mapped base address registers.  in several places the fxp driver
> issues a command, then busy-waits on a DMA indicating completion.
> if such a command is issued before the base address registers have
> been reprogrammed, the kernel will wait forever for a DMA that'll
> never occur.  CSR_READs will hang the kernel similarly.
> the patch in PR 18756 does several things, mostly based on ideas
> from the netbsd and linux drivers: 
>     - saves and restores sufficient PCI registers across
>       suspend/resume.
>     - adds timeouts to DMA busy-waits.
>     - attempts to avoid handling interrupts before the device has
>       been resumed, to prevent hanging on the CSR_READ at the top of
>       fxp_intr().
> it's the latter that DG thought might be a problem.  the intent (and
> effect, at least on my sony z505hs) was to protect against shared
> interrupts delivered before the device is resumed.  on my machine,
> the fxp and uhci devices share irq 9.  if the uhci controller is
> resumed and generates an irq before the fxp device is resumed, the
> fxp_intr() routine is also called and the machine freezes.
> 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.

----- End forwarded message -----

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to