Re: OF-related boot crash in 3.3.0-rc3-00188-g3ec1e88
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On 22/02/2012 00:36, Meelis Roos wrote:
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.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)
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: fffff8007fcc0a4dI 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. Richard
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.
-- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux MIPS Home] [Kernel Development] [DCCP] [Linux ARM Development] [Linux] [Photo] [Yosemite News] [MIPS Architecture] [Linux ARM Kernel] [Linux SCSI] [Linux x86_64] [Linux Hams]