From mboxrd@z Thu Jan 1 00:00:00 1970 From: Randolph Chung Subject: Re: [parisc-linux] 64-bit kernel crashes on my c3600 Date: Sat, 30 Oct 2004 23:29:22 -0700 Message-ID: <20041031062922.GK4249@tausq.org> References: <20041019175440.GP16153@parcelfarce.linux.theplanet.co.uk> Reply-To: Randolph Chung Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: parisc-linux@parisc-linux.org To: Matthew Wilcox Return-Path: In-Reply-To: <20041019175440.GP16153@parcelfarce.linux.theplanet.co.uk> List-Id: parisc-linux developers list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: parisc-linux-bounces@lists.parisc-linux.org > One of the problems with this crash is that enabling EARLY_CONSOLE > doesn't help. The exact same configuration boots fine in 32-bit mode. > I'm building from the same tree (with O=) so there's no question of patch > skew. Turning on DISCONTIGMEM does not help. The HPMC points inside > the code generated by the save_general macro just past skip_save_ior > inside the intr_save function in entry.S i've found out some more info about this problem, but still no clue why it's happening.... at the end of head.S, when we branch to virtual space, the first virtual insn access (to start_kernel) causes a itlb miss fault (as expected). For some reason, the itlb handler is not able to find the page for start_kernel in the page table, so it attempts to call the fault handler (handle_interruption, via intr_save). However, in intr_save, as soon as we switch to virtual space (virt_map, right before the save_general macro call), we immediately cause another itlb miss fault, which fails, and calls intr_save again. Each time intr_save is called, we create a new stack frame. Eventually, the stack pointer points past valid phys addr space, and the machine HPMCs. The question is, why does the itlb miss handler fail to find the mapping for start_kernel? On my kernel, start_kernel is at 0x1056xxxx, which is well within the 16MB initially mapped in head.S. I went through the code in head.S several times and it seems to be correct. I also don't quite understand how this part of the code, which is all in assembly, can behave differently between gcc-3.3 and gcc-3.4. I tried to move the initial-VM initialization code in head.S much closer to the rfi (with the hypothesis that some intervening code had trashed the page table) but that doesn't seem to help. I also had a theory that perhaps the different gcc versions were expanding the #define's differently for offsets.h, but that doesn't seem to be the case either... so i'm out of ideas :( if it helps, what i see is that in L2_ptep, ldw,s \index(\pmd),\pmd is returning with \pmd == 0 weird.... randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux