[lkml]   [2008]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)
    On Thursday, 4 of December 2008, Frans Pop wrote:
    > On Wednesday 03 December 2008, Linus Torvalds wrote:
    > > Well, I think that what _would_ be generally correct, and actually
    > > pretty simple, is a rather different approach: just not sizing things
    > > behind a transparent bridge AT ALL, since it really shouldn't matter.
    > I've given your patch a try and the few resumes from STR I've done were
    > all successful. That's not 100% conclusive yet, but a nice start.
    > Some info from logs etc. below.

    It doesn't help on my box, though. I've got a failure to resume from
    hibernation on the first attempt.

    However, this one appears to work reliably for me (on top of vanilla current

    --- linux-2.6.orig/drivers/pci/setup-bus.c
    +++ linux-2.6/drivers/pci/setup-bus.c
    @@ -350,6 +350,11 @@ static int pbus_size_mem(struct pci_bus

    if (r->parent || (r->flags & mask) != type)
    + if ((dev->class >> 8) == PCI_CLASS_BRIDGE_CARDBUS
    + && bus->self->transparent)
    + continue;
    r_size = resource_size(r);
    /* For bridges size != alignment */
    align = resource_alignment(r);
    > > > Also, I would be happy to actually understand _why_ this happens.
    > >
    > > 100% agreed. I do _not_ see why it should ever matter how we set up a
    > > PCI bridging window - whether prefetchable or not - on a bridge that
    > > should be transparent. It sounds really odd. I'm wondering if there is
    > > something we're missing here.
    > The theory that it is really a resume issue and not a device layout issue
    > sounds logical. Especially as everything always works correctly after a
    > normal boot.

    Well, in fact I'm pretty sure this is the case. By changing memory address
    space layout we effectively change conditions during suspend-resume and
    apparently we can choose one for which the failure condition doesn't trigger
    (or, IOW, the probability of it is _so_ small that we just can't see it).

    There seems to be a race of some kind or a missing delay or something similar.


     \ /
      Last update: 2008-12-04 23:13    [W:0.021 / U:41.552 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site