H. Peter Anvin wrote: > Andy Whitcroft wrote: >>> It definitely sounds like a memory clobber of some sort. >>> >>> Usual suspects, in addition to the input/output buffers you already >>> looked at, would be the heap and the stack. Finding where the stack >>> pointer lives would be my first, instinctive guess. >> The stack seems to be where it should be and seems to stay pretty much >> in the same place as it should. Adding checks for the heap also seem to >> stay within bounds. I've tried making the stack and the heap 64k to no >> effect. >> >> Moving the kernel to other places in memory seems to kill the decode >> completely during gunzip() which may be a hint I am not sure. >> >> This thing is trying to ruin my mind. >> > > Yours and mine both. Seems like *something* is clobbering memory, but > what and why is a mystery. The fact that putting the kernel in a higher > point in memory is a good indication that this clobber is at a > relatively high address. > > How much RAM does this machine have?
This is as 12GB machine. 3 numa nodes. I checked out the location of the IDT and GDT and both seem sane, in the 9xxxx range below the kernel destination. I also note that on another machine of this type, one Node only in that case some of the "did work" cases do not work. Also when I applied some of my patches on the top "working" cases stopped working. So whatever it is is definatly related to the shape of the kernel to be loaded. Very confusing. -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
