On Sun, Sep 17, 2000 at 05:31:45AM -0700, David Greenman wrote:
> >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.

While programming for cardbus under FreeBSD, I ran into similar issues that
when cards were powere down or removed where they would go into an infinite
loop reading status registers.  What actually happens is the register
returns 0xffffffff whenever it is read, and the resolution I used was to
check whether it is equal to 0xffff and do appropiate measures when it is
found to be true.  It looks from reading the PR that this might be a
similar issue here -- that the card is powered down during suspend and of
wakeup the reads to FXP_CSR_SCB_STATACK and cbp->cb_status returns 0xff.  I
believe this issue can be resolved by checking whether what was read equals
0xffffffff and abort the loop.  This should be fairly safe as interrups
shouldn't happen during powerdown (and can't be ack'ed anyway)...

    (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o)
 \\\_\            Jonathan Chen              [EMAIL PROTECTED]           /_///
 <____)  No electrons were harmed during production of this message (____>

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

Reply via email to