[lkml]   [2012]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: OF-related boot crash in 3.3.0-rc3-00188-g3ec1e88
    On 22/02/2012 00:36, Meelis Roos wrote:
    >> Meelis, can you please apply the following patch before& after the
    >> offending commit, boot with "memblock=debug" added as kernel param and
    >> post the boot log? The patch will generate some offset warnings after
    >> the commit but should work fine.
    > Before the commit (v3.2-rc3-75-g0ee332c): memblock1.gz (attached)
    > After the commit (v3.2-rc3-76-g7bd0b0f): memblock2.gz (attached)
    Its a long time since I regularly had to worry about SPARC boxes (not)
    booting so may be the difference between virtual & physical addresses
    but I notice that some of the addresses in the register dump have
    non-zero values in the upper 32 bits but the memblock values have zero
    in the upper half.

    memblock reserved: ADD [0x0000007fcc0a40-0x0000007fcc0a4e] node 1
    memblock reserved: add [0x0000007fcc0a40-000000007fcc0a4e] node 1 @767

    But a similar address in the registers has fffff800 in there.

    o4: fffff8007fcc0a4d

    I know that there are a number of explanations why things would be
    different (32 bit acesses etc) but it could explain things plus we would
    be talking 64 bit addresses in the kernel.

    Just a thought.


    > In addition, a third type of sparc machines breaks in a third way - V210
    > and V240 just hang after telling
    > console [tty0] enabled, bootconsole disabled
    > and before calibrating the delay loop. Bisect has led to the same commit.

     \ /
      Last update: 2012-02-22 19:33    [W:5.173 / U:0.216 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site