linux-parisc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
@ 2012-05-08 21:59 Vincent
  2012-05-09  6:53 ` Rolf Eike Beer
  0 siblings, 1 reply; 56+ messages in thread
From: Vincent @ 2012-05-08 21:59 UTC (permalink / raw)
  To: linux-parisc

Hi parisc folks,

I have noticed that the mainline kernel won't boot any more on my
hp712/100, starting with v2.6.39. It panics in
flush_instruction_cache_local.

After bisection, it appeared the culprit was commit
f311847c2fcebd81912e2f0caf8a461dec28db41 "parisc: flush pages through
tmpalias space". Reverting it made v2.6.39 boot again.

=46or v3.0, I needed to revert a few more patches simply to allow
reverting the original bad commit. And starting with v3.2, I needed to
add the patch from John David Anglin to adjust section arrangement, too
(see http://www.spinics.net/lists/linux-parisc/msg04091.html).

Here is the final patch "pile" I need on v3.4-rc6 to make it boot prope=
rly:

 <patch from John David Anglin>
 Revert f311847c "parisc: flush pages through tmpalias space"
 Revert 8b4ae334 "eliminate special FLUSH flag from page table"
 Revert b54cd0d5 "[PARISC] fix pacache .size with new binutils"
 Revert b7d45818 "[PARISC] prevent speculative re-read on cache flush"

If someone manages to repair the cache routines, I would be glad to tes=
t
the patches :)

Best regards,

--=20
Vincent Stehl=E9


Kernel panic when booting v3.4-rc6 with only the patch from John David
Anglin:

=2E..
[   16.032000] Freeing unused kernel memory: 252k freed
[   16.096000]       _______________________________
[   16.096000]      < Your System ate a SPARC! Gah! >
[   16.096000]       -------------------------------
[   16.096000]              \   ^__^
[   16.096000]                  (__)\       )\/\
[   16.096000]                   U  ||----w |
[   16.096000]                      ||     ||
[   16.456000] swapper (pid 1): Illegal instruction (code 8)
[   16.520000]
[   16.536000]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[   16.592000] PSW: 00000000000000000000000000000000 Not tainted
[   16.660000] r00-03  00000000 00000003 101122b4 105e7b40
[   16.724000] r04-07  105da000 0000000f ffeffff6 00000001
[   16.784000] r08-11  0f2ff000 0f000000 00000001 00000001
[   16.848000] r12-15  ffeffff6 00000017 16633000 16646ffc
[   16.912000] r16-19  00000000 00000023 16633000 17430000
[   16.972000] r20-23  00000000 105e7b60 00000001 00000020
[   17.036000] r24-27  00000000 00000000 0000bb40 104ee000
[   17.096000] r28-31  0f2ff000 00000001 17430740 10268e50
[   17.160000] sr00-03  00000000 00000000 00000000 00000000
[   17.224000] sr04-07  00000000 00000000 00000000 00000000
[   17.288000]
[   17.304000] IASQ: 00000000 00000000 IAOQ: 101009ec 101009f0
[   17.372000]  IIR: 0f801280    ISR: 00000000  IOR: 0f2ff000
[   17.436000]  CPU:        0   CR30: 17430000 CR31: 00000002
[   17.500000]  ORIG_R28: 00000012
[   17.540000]  IAOQ[0]: __clear_user_page_asm+0x20/0x70
[   17.600000]  IAOQ[1]: __clear_user_page_asm+0x24/0x70
[   17.660000]  RP(r2): clear_user_page+0x38/0x50
[   17.712000] Backtrace:
[   17.740000]  [<101122b4>] clear_user_page+0x38/0x50
[   17.800000]  [<1019c37c>] handle_pte_fault+0x1e0/0x7a8
[   17.860000]  [<1019ca08>] handle_mm_fault+0xc4/0xf4
[   17.916000]  [<1019d208>] __get_user_pages+0x18c/0x370
[   17.980000]  [<101bcc08>] get_arg_page+0x5c/0x108
[   18.036000]  [<101bcecc>] copy_strings+0x114/0x25c
[   18.092000]  [<101bd030>] copy_strings_kernel+0x1c/0x30
[   18.156000]  [<101be408>] do_execve+0x1f4/0x370
[   18.208000]  [<10117f0c>] sys_execve+0x44/0x70
[   18.260000]  [<10103084>] __execve+0x20/0x34
[   18.312000]  [<1012a098>] vprintk+0x39c/0x3f0
[   18.364000]  [<1010e074>] printk+0x24/0x30
[   18.412000]  [<101110cc>] init_post+0x6c/0x148
[   18.468000]  [<1059d624>] kernel_init+0x218/0x250
[   18.524000]
[   18.540000] Backtrace:
[   18.568000]  [<10113124>] die_if_kernel+0x138/0x1b0
[   18.628000]  [<10113374>] handle_interruption+0x1d8/0x6d8
[   18.692000]  [<10104078>] intr_check_sig+0x0/0x34
[   18.748000]  [<10174e28>] rcu_irq_exit+0x50/0x60
[   18.804000]  [<101009f0>] __clear_user_page_asm+0x24/0x70
[   18.868000]
[   18.884000] ---[ end trace 1a0bf3a13bdb1148 ]---
[   18.940000] note: swapper[1] exited with preempt_count 1
[   19.004000] Kernel panic - not syncing: Attempted to kill init!
exitcode=3D0x0000000b
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-08 21:59 Issue booting v2.6.39 .. v3.4-rc6 on hp712/100 Vincent
@ 2012-05-09  6:53 ` Rolf Eike Beer
  2012-05-09 15:55   ` John David Anglin
  2012-05-09 21:00   ` Vincent
  0 siblings, 2 replies; 56+ messages in thread
From: Rolf Eike Beer @ 2012-05-09  6:53 UTC (permalink / raw)
  To: Vincent; +Cc: linux-parisc

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

Vincent wrote:
> Hi parisc folks,
> 
> I have noticed that the mainline kernel won't boot any more on my
> hp712/100, starting with v2.6.39. It panics in
> flush_instruction_cache_local.

See the mail thread "Boot error using 3.2.1: swapper (pid 1): Illegal 
instruction (code 8)" I started when I first hit this on my 705. But James 
doesn't care.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-09  6:53 ` Rolf Eike Beer
@ 2012-05-09 15:55   ` John David Anglin
  2012-05-09 21:14     ` Vincent
  2012-05-09 21:00   ` Vincent
  1 sibling, 1 reply; 56+ messages in thread
From: John David Anglin @ 2012-05-09 15:55 UTC (permalink / raw)
  To: Rolf Eike Beer; +Cc: Vincent, linux-parisc

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

On 5/9/2012 2:53 AM, Rolf Eike Beer wrote:
> Vincent wrote:
>> Hi parisc folks,
>>
>> I have noticed that the mainline kernel won't boot any more on my
>> hp712/100, starting with v2.6.39. It panics in
>> flush_instruction_cache_local.
> See the mail thread "Boot error using 3.2.1: swapper (pid 1): Illegal
> instruction (code 8)" I started when I first hit this on my 705. But James
> doesn't care.
There is a fair chance that the patch posted here 
<http://www.spinics.net/lists/linux-parisc/msg04068.html>
would fix the boot issue.   However, I recently discovered a build issue 
on non SMP configurations.  Attached
is an updated version.   It applies against 3.3.4.

It has been tested extensively on rp3440.

clear_user_page does not use the tmpalias region.  I believe the problem 
with the current implementation
is that the TLB setup can be clobbered if __clear_user_page_asm is 
reentered.

Signed-off-by: John David Anglin <dave.anglin@bell.net>

Dave

-- 
John David Anglin    dave.anglin@bell.net


[-- Attachment #2: cache-2.d.txt --]
[-- Type: text/plain, Size: 27669 bytes --]

diff --git a/arch/parisc/include/asm/cacheflush.h b/arch/parisc/include/asm/cacheflush.h
index da601dd..08f85dc 100644
--- a/arch/parisc/include/asm/cacheflush.h
+++ b/arch/parisc/include/asm/cacheflush.h
@@ -115,7 +115,9 @@ flush_anon_page(struct vm_area_struct *vma, struct page *page, unsigned long vma
 {
 	if (PageAnon(page)) {
 		flush_tlb_page(vma, vmaddr);
+		preempt_disable();
 		flush_dcache_page_asm(page_to_phys(page), vmaddr);
+		preempt_enable();
 	}
 }
 
diff --git a/arch/parisc/include/asm/page.h b/arch/parisc/include/asm/page.h
index a84cc1f..9400a62 100644
--- a/arch/parisc/include/asm/page.h
+++ b/arch/parisc/include/asm/page.h
@@ -21,15 +21,27 @@
 #include <asm/types.h>
 #include <asm/cache.h>
 
-#define clear_page(page)	memset((void *)(page), 0, PAGE_SIZE)
-#define copy_page(to,from)      copy_user_page_asm((void *)(to), (void *)(from))
+#define clear_page(page)	clear_page_asm((void *)(page))
+#define copy_page(to,from)	copy_page_asm((void *)(to), (void *)(from))
 
 struct page;
 
-void copy_user_page_asm(void *to, void *from);
+void clear_page_asm(void *page);
+void copy_page_asm(void *to, void *from);
+void clear_user_page(void *vto, unsigned long vaddr, struct page *pg);
 void copy_user_page(void *vto, void *vfrom, unsigned long vaddr,
 			   struct page *pg);
-void clear_user_page(void *page, unsigned long vaddr, struct page *pg);
+
+// #define CONFIG_PARISC_TMPALIAS
+
+#ifdef CONFIG_PARISC_TMPALIAS
+void clear_user_highpage(struct page *page, unsigned long vaddr);
+#define clear_user_highpage clear_user_highpage
+struct vm_area_struct;
+void copy_user_highpage(struct page *to, struct page *from,
+	unsigned long vaddr, struct vm_area_struct *vma);
+#define __HAVE_ARCH_COPY_USER_HIGHPAGE
+#endif
 
 /*
  * These are used to make use of C type-checking..
diff --git a/arch/parisc/include/asm/pgtable.h b/arch/parisc/include/asm/pgtable.h
index 22dadeb..100f409 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -12,11 +12,10 @@
 
 #include <linux/bitops.h>
 #include <linux/spinlock.h>
+#include <linux/mm_types.h>
 #include <asm/processor.h>
 #include <asm/cache.h>
 
-struct vm_area_struct;
-
 /*
  * kern_addr_valid(ADDR) tests if ADDR is pointing to valid kernel
  * memory.  For the return value to be meaningful, ADDR must be >=
@@ -40,7 +39,14 @@ struct vm_area_struct;
         do{                                                     \
                 *(pteptr) = (pteval);                           \
         } while(0)
-#define set_pte_at(mm,addr,ptep,pteval) set_pte(ptep,pteval)
+
+extern void purge_tlb_entries(struct mm_struct *, unsigned long);
+
+#define set_pte_at(mm,addr,ptep, pteval)                        \
+        do{                                                     \
+                set_pte(ptep,pteval);                           \
+                purge_tlb_entries(mm,addr);                     \
+        } while(0)
 
 #endif /* !__ASSEMBLY__ */
 
@@ -460,10 +466,13 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr,
 #ifdef CONFIG_SMP
 	unsigned long new, old;
 
+	/* ??? This might be racy because the page table updates in
+	   entry.S don't use the same lock.  */
 	do {
 		old = pte_val(*ptep);
 		new = pte_val(pte_wrprotect(__pte (old)));
 	} while (cmpxchg((unsigned long *) ptep, old, new) != old);
+	purge_tlb_entries(mm, addr);
 #else
 	pte_t old_pte = *ptep;
 	set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index 83335f3..f31edc2 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -268,9 +268,11 @@ static inline void
 __flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr,
 		   unsigned long physaddr)
 {
+	preempt_disable();
 	flush_dcache_page_asm(physaddr, vmaddr);
 	if (vma->vm_flags & VM_EXEC)
 		flush_icache_page_asm(physaddr, vmaddr);
+	preempt_enable();
 }
 
 void flush_dcache_page(struct page *page)
@@ -316,7 +318,7 @@ void flush_dcache_page(struct page *page)
 		flush_tlb_page(mpnt, addr);
 		if (old_addr == 0 || (old_addr & (SHMLBA - 1)) != (addr & (SHMLBA - 1))) {
 			__flush_cache_page(mpnt, addr, page_to_phys(page));
-			if (old_addr)
+			if (old_addr && parisc_requires_coherency())
 				printk(KERN_ERR "INEQUIVALENT ALIASES 0x%lx and 0x%lx in file %s\n", old_addr, addr, mpnt->vm_file ? (char *)mpnt->vm_file->f_path.dentry->d_name.name : "(null)");
 			old_addr = addr;
 		}
@@ -331,17 +333,6 @@ EXPORT_SYMBOL(flush_kernel_dcache_page_asm);
 EXPORT_SYMBOL(flush_data_cache_local);
 EXPORT_SYMBOL(flush_kernel_icache_range_asm);
 
-void clear_user_page_asm(void *page, unsigned long vaddr)
-{
-	unsigned long flags;
-	/* This function is implemented in assembly in pacache.S */
-	extern void __clear_user_page_asm(void *page, unsigned long vaddr);
-
-	purge_tlb_start(flags);
-	__clear_user_page_asm(page, vaddr);
-	purge_tlb_end(flags);
-}
-
 #define FLUSH_THRESHOLD 0x80000 /* 0.5MB */
 int parisc_cache_flush_threshold __read_mostly = FLUSH_THRESHOLD;
 
@@ -375,20 +366,9 @@ void __init parisc_setup_cache_timing(void)
 	printk(KERN_INFO "Setting cache flush threshold to %x (%d CPUs online)\n", parisc_cache_flush_threshold, num_online_cpus());
 }
 
-extern void purge_kernel_dcache_page(unsigned long);
-extern void clear_user_page_asm(void *page, unsigned long vaddr);
-
-void clear_user_page(void *page, unsigned long vaddr, struct page *pg)
-{
-	unsigned long flags;
-
-	purge_kernel_dcache_page((unsigned long)page);
-	purge_tlb_start(flags);
-	pdtlb_kernel(page);
-	purge_tlb_end(flags);
-	clear_user_page_asm(page, vaddr);
-}
-EXPORT_SYMBOL(clear_user_page);
+extern void purge_kernel_dcache_page_asm(unsigned long);
+extern void clear_user_page_asm(void *, unsigned long);
+extern void copy_user_page_asm(void *, void *, unsigned long);
 
 void flush_kernel_dcache_page_addr(void *addr)
 {
@@ -401,11 +381,26 @@ void flush_kernel_dcache_page_addr(void *addr)
 }
 EXPORT_SYMBOL(flush_kernel_dcache_page_addr);
 
+void clear_user_page(void *vto, unsigned long vaddr, struct page *page)
+{
+	clear_page_asm(vto);
+	if (!parisc_requires_coherency())
+		flush_kernel_dcache_page_asm(vto);
+}
+EXPORT_SYMBOL(clear_user_page);
+
 void copy_user_page(void *vto, void *vfrom, unsigned long vaddr,
-		    struct page *pg)
+	struct page *pg)
 {
-	/* no coherency needed (all in kmap/kunmap) */
-	copy_user_page_asm(vto, vfrom);
+	/* Copy using kernel mapping.  No coherency is needed
+	   (all in kmap/kunmap) on machines that don't support
+	   non-equivalent aliasing.  However, the `from' page
+	   needs to be flushed before it can be accessed through
+	   the kernel mapping. */
+	preempt_disable();
+	flush_dcache_page_asm(__pa(vfrom), vaddr);
+	preempt_enable();
+	copy_page_asm(vto, vfrom);
 	if (!parisc_requires_coherency())
 		flush_kernel_dcache_page_asm(vto);
 }
@@ -460,8 +455,65 @@ void flush_cache_all(void)
 	on_each_cpu(cacheflush_h_tmp_function, NULL, 1);
 }
 
+static inline unsigned long mm_total_size(struct mm_struct *mm)
+{
+	struct vm_area_struct *vma;
+	unsigned long usize = 0;
+
+	for (vma = mm->mmap; vma; vma = vma->vm_next)
+		usize += vma->vm_end - vma->vm_start;
+	return usize;
+}
+
+static inline pte_t *get_ptep(pgd_t *pgd, unsigned long addr)
+{
+	pte_t *ptep = NULL;
+
+        if (!pgd_none(*pgd)) {
+                pud_t *pud = pud_offset(pgd, addr);
+                if (!pud_none(*pud)) {
+                        pmd_t *pmd = pmd_offset(pud, addr);
+                        if (!pmd_none(*pmd)) {
+                                ptep = pte_offset_map(pmd, addr);
+                        }
+                }
+        }
+	return ptep;
+}
+
 void flush_cache_mm(struct mm_struct *mm)
 {
+	/* Flushing the whole cache on each cpu takes forever on
+	   rp3440, etc.  So, avoid it if the mm isn't too big.
+	   Note: This approach is faster than a range flush when the
+	   context is current, and it works even when non current.  */
+	if (mm_total_size(mm) < parisc_cache_flush_threshold) {
+		struct vm_area_struct *vma;
+
+		if (mm->context == mfsp(3)) {
+			for (vma = mm->mmap; vma; vma = vma->vm_next) {
+				flush_user_dcache_range_asm(vma->vm_start, vma->vm_end);
+				if(vma->vm_flags & VM_EXEC)
+					flush_user_icache_range_asm(vma->vm_start, vma->vm_end);
+			}
+		} else {
+			pgd_t *pgd = mm->pgd;
+
+			for (vma = mm->mmap; vma; vma = vma->vm_next) {
+				unsigned long addr;
+
+				for (addr = vma->vm_start; addr < vma->vm_end; addr += PAGE_SIZE) {
+					pte_t *ptep = get_ptep(pgd, addr);
+					if (ptep != NULL) {
+						pte_t pte = *ptep;
+						__flush_cache_page(vma, addr, page_to_phys(pte_page(pte)));
+					}
+				}
+			}
+		}
+		return;
+	}
+
 #ifdef CONFIG_SMP
 	flush_cache_all();
 #else
@@ -487,20 +539,34 @@ flush_user_icache_range(unsigned long start, unsigned long end)
 		flush_instruction_cache();
 }
 
-
 void flush_cache_range(struct vm_area_struct *vma,
 		unsigned long start, unsigned long end)
 {
-	int sr3;
-
 	BUG_ON(!vma->vm_mm->context);
 
-	sr3 = mfsp(3);
-	if (vma->vm_mm->context == sr3) {
-		flush_user_dcache_range(start,end);
-		flush_user_icache_range(start,end);
+	if ((end - start) < parisc_cache_flush_threshold) {
+		if (vma->vm_mm->context == mfsp(3)) {
+			flush_user_dcache_range_asm(start,end);
+			if(vma->vm_flags & VM_EXEC)
+				flush_user_icache_range_asm(start,end);
+		} else {
+			unsigned long addr;
+			pgd_t *pgd = vma->vm_mm->pgd;
+
+			for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
+				pte_t *ptep = get_ptep(pgd, addr);
+				if (ptep != NULL) {
+					pte_t pte = *ptep;
+					flush_cache_page(vma, addr, pte_pfn(pte));
+				}
+			}
+		}
 	} else {
+#ifdef CONFIG_SMP
 		flush_cache_all();
+#else
+		flush_cache_all_local();
+#endif
 	}
 }
 
@@ -513,3 +579,81 @@ flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr, unsigned long
 	__flush_cache_page(vma, vmaddr, page_to_phys(pfn_to_page(pfn)));
 
 }
+
+void purge_tlb_entries(struct mm_struct *mm, unsigned long addr)
+{
+	unsigned long flags;
+
+	/* Note: purge_tlb_entries can be called at startup with
+	   no context.  */
+
+	mtsp(mm->context,1);
+	purge_tlb_start(flags);
+	pdtlb(addr);
+	pitlb(addr);
+	purge_tlb_end(flags);
+}
+
+#ifdef CONFIG_PARISC_TMPALIAS
+
+void clear_user_highpage(struct page *page, unsigned long vaddr)
+{
+	void *vto;
+	unsigned long flags;
+
+	/* Clear using TMPALIAS region.  The page doesn't need to
+	   be flushed but the kernel mapping needs to be purged.  */
+
+	vto = kmap_atomic(page, KM_USER0);
+
+	/* The PA-RISC 2.0 Architecture book states on page F-6:
+	   "Before a write-capable translation is enabled, *all*
+	   non-equivalently-aliased translations must be removed
+	   from the page table and purged from the TLB.  (Note
+	   that the caches are not required to be flushed at this
+	   time.)  Before any non-equivalent aliased translation
+	   is re-enabled, the virtual address range for the writeable
+	   page (the entire page) must be flushed from the cache,
+	   and the write-capable translation removed from the page
+	   table and purged from the TLB."  */
+
+	purge_kernel_dcache_page_asm((unsigned long)vto);
+	purge_tlb_start(flags);
+	pdtlb_kernel(vto);
+	purge_tlb_end(flags);
+	preempt_disable();
+	clear_user_page_asm(vto, vaddr);
+	preempt_enable();
+
+	pagefault_enable();		/* kunmap_atomic(addr, KM_USER0); */
+}
+
+void copy_user_highpage(struct page *to, struct page *from,
+	unsigned long vaddr, struct vm_area_struct *vma)
+{
+	void *vfrom, *vto;
+	unsigned long flags;
+
+	/* Copy using TMPALIAS region.  This has the advantage
+	   that the `from' page doesn't need to be flushed.  However,
+	   the `to' page must be flushed in copy_user_page_asm since
+	   it can be used to bring in executable code.  */
+
+	vfrom = kmap_atomic(from, KM_USER0);
+	vto = kmap_atomic(to, KM_USER1);
+
+	purge_kernel_dcache_page_asm((unsigned long)vto);
+	purge_tlb_start(flags);
+	pdtlb_kernel(vto);
+	pdtlb_kernel(vfrom);
+	purge_tlb_end(flags);
+	preempt_disable();
+	copy_user_page_asm(vto, vfrom, vaddr);
+	flush_dcache_page_asm(__pa(vto), vaddr);
+	preempt_enable();
+
+	pagefault_enable();		/* kunmap_atomic(addr, KM_USER1); */
+	pagefault_enable();		/* kunmap_atomic(addr, KM_USER0); */
+}
+
+#endif /* CONFIG_PARISC_TMPALIAS */
diff --git a/arch/parisc/kernel/pacache.S b/arch/parisc/kernel/pacache.S
index 93ff3d9..9a29e34 100644
--- a/arch/parisc/kernel/pacache.S
+++ b/arch/parisc/kernel/pacache.S
@@ -199,7 +199,6 @@ ENTRY(flush_instruction_cache_local)
 	.callinfo NO_CALLS
 	.entry
 
-	mtsp		%r0, %sr1
 	load32		cache_info, %r1
 
 	/* Flush Instruction Cache */
@@ -208,20 +207,46 @@ ENTRY(flush_instruction_cache_local)
 	LDREG		ICACHE_STRIDE(%r1), %arg1
 	LDREG		ICACHE_COUNT(%r1), %arg2
 	LDREG		ICACHE_LOOP(%r1), %arg3
-	rsm             PSW_SM_I, %r22		/* No mmgt ops during loop*/
+	rsm		PSW_SM_I, %r22		/* No mmgt ops during loop*/
 	addib,COND(=)		-1, %arg3, fioneloop	/* Preadjust and test */
 	movb,<,n	%arg3, %r31, fisync	/* If loop < 0, do sync */
 
 fimanyloop:					/* Loop if LOOP >= 2 */
 	addib,COND(>)		-1, %r31, fimanyloop	/* Adjusted inner loop decr */
-	fice            %r0(%sr1, %arg0)
-	fice,m		%arg1(%sr1, %arg0)	/* Last fice and addr adjust */
+	fice            %r0(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)	/* Last fice and addr adjust */
 	movb,tr		%arg3, %r31, fimanyloop	/* Re-init inner loop count */
 	addib,COND(<=),n	-1, %arg2, fisync	/* Outer loop decr */
 
 fioneloop:					/* Loop if LOOP = 1 */
-	addib,COND(>)		-1, %arg2, fioneloop	/* Outer loop count decr */
-	fice,m		%arg1(%sr1, %arg0)	/* Fice for one loop */
+	/* Some implementations may flush with a single fice instruction */
+	cmpib,COND(>>=),n	15, %arg2, fioneloop2
+
+fioneloop1:
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	addib,COND(>)	-16, %arg2, fioneloop1
+	fice,m		%arg1(%sr2, %arg0)
+
+	/* Check if done */
+	cmpb,COND(=),n	%arg2, %r0, fisync	/* Predict branch taken */
+
+fioneloop2:
+	addib,COND(>)	-1, %arg2, fioneloop2	/* Outer loop count decr */
+	fice,m		%arg1(%sr2, %arg0)	/* Fice for one loop */
 
 fisync:
 	sync
@@ -240,8 +265,7 @@ ENTRY(flush_data_cache_local)
 	.callinfo NO_CALLS
 	.entry
 
-	mtsp		%r0, %sr1
-	load32 		cache_info, %r1
+	load32		cache_info, %r1
 
 	/* Flush Data Cache */
 
@@ -249,20 +273,46 @@ ENTRY(flush_data_cache_local)
 	LDREG		DCACHE_STRIDE(%r1), %arg1
 	LDREG		DCACHE_COUNT(%r1), %arg2
 	LDREG		DCACHE_LOOP(%r1), %arg3
-	rsm		PSW_SM_I, %r22
+	rsm		PSW_SM_I, %r22		/* No mmgt ops during loop*/
 	addib,COND(=)		-1, %arg3, fdoneloop	/* Preadjust and test */
 	movb,<,n	%arg3, %r31, fdsync	/* If loop < 0, do sync */
 
 fdmanyloop:					/* Loop if LOOP >= 2 */
 	addib,COND(>)		-1, %r31, fdmanyloop	/* Adjusted inner loop decr */
-	fdce		%r0(%sr1, %arg0)
-	fdce,m		%arg1(%sr1, %arg0)	/* Last fdce and addr adjust */
+	fdce		%r0(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)	/* Last fdce and addr adjust */
 	movb,tr		%arg3, %r31, fdmanyloop	/* Re-init inner loop count */
 	addib,COND(<=),n	-1, %arg2, fdsync	/* Outer loop decr */
 
 fdoneloop:					/* Loop if LOOP = 1 */
-	addib,COND(>)		-1, %arg2, fdoneloop	/* Outer loop count decr */
-	fdce,m		%arg1(%sr1, %arg0)	/* Fdce for one loop */
+	/* Some implementations may flush with a single fdce instruction */
+	cmpib,COND(>>=),n	15, %arg2, fdoneloop2
+
+fdoneloop1:
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	addib,COND(>)	-16, %arg2, fdoneloop1
+	fdce,m		%arg1(%sr2, %arg0)
+
+	/* Check if done */
+	cmpb,COND(=),n	%arg2, %r0, fdsync	/* Predict branch taken */
+
+fdoneloop2:
+	addib,COND(>)	-1, %arg2, fdoneloop2	/* Outer loop count decr */
+	fdce,m		%arg1(%sr2, %arg0)	/* Fdce for one loop */
 
 fdsync:
 	syncdma
@@ -277,7 +327,104 @@ ENDPROC(flush_data_cache_local)
 
 	.align	16
 
-ENTRY(copy_user_page_asm)
+/* Macros to serialize TLB purge operations on SMP.  */
+
+	.macro	tlb_lock	la,flags,tmp
+#ifdef CONFIG_SMP
+	ldil		L%pa_tlb_lock,%r1
+	ldo		R%pa_tlb_lock(%r1),\la
+	rsm		PSW_SM_I,\flags
+1:	LDCW		0(\la),\tmp
+	cmpib,<>,n	0,\tmp,3f
+2:	ldw		0(\la),\tmp
+	cmpb,<>		%r0,\tmp,1b
+	nop
+	b,n		2b
+3:
+#endif
+	.endm
+
+	.macro	tlb_unlock	la,flags,tmp
+#ifdef CONFIG_SMP
+	ldi		1,\tmp
+	stw		\tmp,0(\la)
+	mtsm		\flags
+#endif
+	.endm
+
+/* Clear page using kernel mapping.  */
+
+ENTRY(clear_page_asm)
+	.proc
+	.callinfo NO_CALLS
+	.entry
+
+#ifdef CONFIG_64BIT
+
+	/* Unroll the loop.  */
+	ldi		(PAGE_SIZE / 128), %r1
+
+1:
+	std		%r0, 0(%r26)
+	std		%r0, 8(%r26)
+	std		%r0, 16(%r26)
+	std		%r0, 24(%r26)
+	std		%r0, 32(%r26)
+	std		%r0, 40(%r26)
+	std		%r0, 48(%r26)
+	std		%r0, 56(%r26)
+	std		%r0, 64(%r26)
+	std		%r0, 72(%r26)
+	std		%r0, 80(%r26)
+	std		%r0, 88(%r26)
+	std		%r0, 96(%r26)
+	std		%r0, 104(%r26)
+	std		%r0, 112(%r26)
+	std		%r0, 120(%r26)
+
+	/* Note reverse branch hint for addib is taken.  */
+	addib,COND(>),n	-1, %r1, 1b
+	ldo		128(%r26), %r26
+
+#else
+
+	/*
+	 * Note that until (if) we start saving the full 64-bit register
+	 * values on interrupt, we can't use std on a 32 bit kernel.
+	 */
+	ldi		(PAGE_SIZE / 64), %r1
+
+1:
+	stw		%r0, 0(%r26)
+	stw		%r0, 4(%r26)
+	stw		%r0, 8(%r26)
+	stw		%r0, 12(%r26)
+	stw		%r0, 16(%r26)
+	stw		%r0, 20(%r26)
+	stw		%r0, 24(%r26)
+	stw		%r0, 28(%r26)
+	stw		%r0, 32(%r26)
+	stw		%r0, 36(%r26)
+	stw		%r0, 40(%r26)
+	stw		%r0, 44(%r26)
+	stw		%r0, 48(%r26)
+	stw		%r0, 52(%r26)
+	stw		%r0, 56(%r26)
+	stw		%r0, 60(%r26)
+
+	addib,COND(>),n	-1, %r1, 1b
+	ldo		64(%r26), %r26
+#endif
+	bv		%r0(%r2)
+	nop
+	.exit
+
+	.procend
+ENDPROC(clear_page_asm)
+
+/* Copy page using kernel mapping.  */
+
+ENTRY(copy_page_asm)
 	.proc
 	.callinfo NO_CALLS
 	.entry
@@ -285,18 +432,14 @@ ENTRY(copy_user_page_asm)
 #ifdef CONFIG_64BIT
 	/* PA8x00 CPUs can consume 2 loads or 1 store per cycle.
 	 * Unroll the loop by hand and arrange insn appropriately.
-	 * GCC probably can do this just as well.
+	 * Prefetch doesn't improve performance on rp3440.
+	 * GCC probably can do this just as well...
 	 */
 
-	ldd		0(%r25), %r19
 	ldi		(PAGE_SIZE / 128), %r1
 
-	ldw		64(%r25), %r0		/* prefetch 1 cacheline ahead */
-	ldw		128(%r25), %r0		/* prefetch 2 */
-
-1:	ldd		8(%r25), %r20
-	ldw		192(%r25), %r0		/* prefetch 3 */
-	ldw		256(%r25), %r0		/* prefetch 4 */
+1:	ldd		0(%r25), %r19
+	ldd		8(%r25), %r20
 
 	ldd		16(%r25), %r21
 	ldd		24(%r25), %r22
@@ -330,20 +473,16 @@ ENTRY(copy_user_page_asm)
 
 	ldd		112(%r25), %r21
 	ldd		120(%r25), %r22
+	ldo		128(%r25), %r25
 	std		%r19, 96(%r26)
 	std		%r20, 104(%r26)
 
-	ldo		128(%r25), %r25
 	std		%r21, 112(%r26)
 	std		%r22, 120(%r26)
-	ldo		128(%r26), %r26
 
-	/* conditional branches nullify on forward taken branch, and on
-	 * non-taken backward branch. Note that .+4 is a backwards branch.
-	 * The ldd should only get executed if the branch is taken.
-	 */
-	addib,COND(>),n	-1, %r1, 1b		/* bundle 10 */
-	ldd		0(%r25), %r19		/* start next loads */
+	/* Note reverse branch hint for addib is taken.  */
+	addib,COND(>),n	-1, %r1, 1b
+	ldo		128(%r26), %r26
 
 #else
 
@@ -399,7 +538,7 @@ ENTRY(copy_user_page_asm)
 	.exit
 
 	.procend
-ENDPROC(copy_user_page_asm)
+ENDPROC(copy_page_asm)
 
 /*
  * NOTE: Code in clear_user_page has a hard coded dependency on the
@@ -422,8 +561,6 @@ ENDPROC(copy_user_page_asm)
  *          %r23 physical page (shifted for tlb insert) of "from" translation
  */
 
-#if 0
-
 	/*
 	 * We can't do this since copy_user_page is used to bring in
 	 * file data that might have instructions. Since the data would
@@ -435,6 +572,7 @@ ENDPROC(copy_user_page_asm)
 	 * use it if more information is passed into copy_user_page().
 	 * Have to do some measurements to see if it is worthwhile to
 	 * lobby for such a change.
+	 *
 	 */
 
 ENTRY(copy_user_page_asm)
@@ -442,16 +580,21 @@ ENTRY(copy_user_page_asm)
 	.callinfo NO_CALLS
 	.entry
 
+	/* Convert virtual `to' and `from' addresses to physical addresses.
+	   Move `from' physical address to non shadowed register.  */
 	ldil		L%(__PAGE_OFFSET), %r1
 	sub		%r26, %r1, %r26
-	sub		%r25, %r1, %r23		/* move physical addr into non shadowed reg */
+	sub		%r25, %r1, %r23
 
 	ldil		L%(TMPALIAS_MAP_START), %r28
 	/* FIXME for different page sizes != 4k */
 #ifdef CONFIG_64BIT
-	extrd,u		%r26,56,32, %r26		/* convert phys addr to tlb insert format */
-	extrd,u		%r23,56,32, %r23		/* convert phys addr to tlb insert format */
-	depd		%r24,63,22, %r28		/* Form aliased virtual address 'to' */
+#if (TMPALIAS_MAP_START >= 0x80000000)
+	depdi		0, 31,32, %r28		/* clear any sign extension */
+#endif
+	extrd,u		%r26,56,32, %r26	/* convert phys addr to tlb insert format */
+	extrd,u		%r23,56,32, %r23	/* convert phys addr to tlb insert format */
+	depd		%r24,63,22, %r28	/* Form aliased virtual address 'to' */
 	depdi		0, 63,12, %r28		/* Clear any offset bits */
 	copy		%r28, %r29
 	depdi		1, 41,1, %r29		/* Form aliased virtual address 'from' */
@@ -466,10 +609,76 @@ ENTRY(copy_user_page_asm)
 
 	/* Purge any old translations */
 
+#ifdef CONFIG_PA20
+	pdtlb,l		0(%r28)
+	pdtlb,l		0(%r29)
+#else
+	tlb_lock	%r20,%r21,%r22
 	pdtlb		0(%r28)
 	pdtlb		0(%r29)
+	tlb_unlock	%r20,%r21,%r22
+#endif
 
-	ldi		64, %r1
+#ifdef CONFIG_64BIT
+	/* PA8x00 CPUs can consume 2 loads or 1 store per cycle.
+	 * Unroll the loop by hand and arrange insn appropriately.
+	 * GCC probably can do this just as well.
+	 */
+
+	ldd		0(%r29), %r19
+	ldi		(PAGE_SIZE / 128), %r1
+
+1:	ldd		8(%r29), %r20
+
+	ldd		16(%r29), %r21
+	ldd		24(%r29), %r22
+	std		%r19, 0(%r28)
+	std		%r20, 8(%r28)
+
+	ldd		32(%r29), %r19
+	ldd		40(%r29), %r20
+	std		%r21, 16(%r28)
+	std		%r22, 24(%r28)
+
+	ldd		48(%r29), %r21
+	ldd		56(%r29), %r22
+	std		%r19, 32(%r28)
+	std		%r20, 40(%r28)
+
+	ldd		64(%r29), %r19
+	ldd		72(%r29), %r20
+	std		%r21, 48(%r28)
+	std		%r22, 56(%r28)
+
+	ldd		80(%r29), %r21
+	ldd		88(%r29), %r22
+	std		%r19, 64(%r28)
+	std		%r20, 72(%r28)
+
+	ldd		 96(%r29), %r19
+	ldd		104(%r29), %r20
+	std		%r21, 80(%r28)
+	std		%r22, 88(%r28)
+
+	ldd		112(%r29), %r21
+	ldd		120(%r29), %r22
+	std		%r19, 96(%r28)
+	std		%r20, 104(%r28)
+
+	ldo		128(%r29), %r29
+	std		%r21, 112(%r28)
+	std		%r22, 120(%r28)
+	ldo		128(%r28), %r28
+
+	/* conditional branches nullify on forward taken branch, and on
+	 * non-taken backward branch. Note that .+4 is a backwards branch.
+	 * The ldd should only get executed if the branch is taken.
+	 */
+	addib,COND(>),n	-1, %r1, 1b		/* bundle 10 */
+	ldd		0(%r29), %r19		/* start next loads */
+
+#else
+	ldi		(PAGE_SIZE / 64), %r1
 
 	/*
 	 * This loop is optimized for PCXL/PCXL2 ldw/ldw and stw/stw
@@ -480,9 +689,7 @@ ENTRY(copy_user_page_asm)
 	 * use ldd/std on a 32 bit kernel.
 	 */
 
-
-1:
-	ldw		0(%r29), %r19
+1:	ldw		0(%r29), %r19
 	ldw		4(%r29), %r20
 	ldw		8(%r29), %r21
 	ldw		12(%r29), %r22
@@ -515,8 +722,10 @@ ENTRY(copy_user_page_asm)
 	stw		%r21, 56(%r28)
 	stw		%r22, 60(%r28)
 	ldo		64(%r28), %r28
+
 	addib,COND(>)		-1, %r1,1b
 	ldo		64(%r29), %r29
+#endif
 
 	bv		%r0(%r2)
 	nop
@@ -524,9 +733,8 @@ ENTRY(copy_user_page_asm)
 
 	.procend
 ENDPROC(copy_user_page_asm)
-#endif
 
-ENTRY(__clear_user_page_asm)
+ENTRY(clear_user_page_asm)
 	.proc
 	.callinfo NO_CALLS
 	.entry
@@ -550,7 +758,13 @@ ENTRY(__clear_user_page_asm)
 
 	/* Purge any old translation */
 
+#ifdef CONFIG_PA20
+	pdtlb,l		0(%r28)
+#else
+	tlb_lock	%r20,%r21,%r22
 	pdtlb		0(%r28)
+	tlb_unlock	%r20,%r21,%r22
+#endif
 
 #ifdef CONFIG_64BIT
 	ldi		(PAGE_SIZE / 128), %r1
@@ -580,8 +794,7 @@ ENTRY(__clear_user_page_asm)
 #else	/* ! CONFIG_64BIT */
 	ldi		(PAGE_SIZE / 64), %r1
 
-1:
-	stw		%r0, 0(%r28)
+1:	stw		%r0, 0(%r28)
 	stw		%r0, 4(%r28)
 	stw		%r0, 8(%r28)
 	stw		%r0, 12(%r28)
@@ -606,7 +819,7 @@ ENTRY(__clear_user_page_asm)
 	.exit
 
 	.procend
-ENDPROC(__clear_user_page_asm)
+ENDPROC(clear_user_page_asm)
 
 ENTRY(flush_dcache_page_asm)
 	.proc
@@ -630,7 +843,13 @@ ENTRY(flush_dcache_page_asm)
 
 	/* Purge any old translation */
 
+#ifdef CONFIG_PA20
+	pdtlb,l		0(%r28)
+#else
+	tlb_lock	%r20,%r21,%r22
 	pdtlb		0(%r28)
+	tlb_unlock	%r20,%r21,%r22
+#endif
 
 	ldil		L%dcache_stride, %r1
 	ldw		R%dcache_stride(%r1), %r1
@@ -663,8 +882,17 @@ ENTRY(flush_dcache_page_asm)
 	fdc,m		%r1(%r28)
 
 	sync
+
+#ifdef CONFIG_PA20
+	pdtlb,l		0(%r25)
+#else
+	tlb_lock	%r20,%r21,%r22
+	pdtlb		0(%r25)
+	tlb_unlock	%r20,%r21,%r22
+#endif
+
 	bv		%r0(%r2)
-	pdtlb		(%r25)
+	nop
 	.exit
 
 	.procend
@@ -692,7 +920,13 @@ ENTRY(flush_icache_page_asm)
 
 	/* Purge any old translation */
 
+#ifdef CONFIG_PA20
+	pitlb,l		%r0(%sr0,%r28)
+#else
+	tlb_lock	%r20,%r21,%r22
 	pitlb		(%sr0,%r28)
+	tlb_unlock	%r20,%r21,%r22
+#endif
 
 	ldil		L%icache_stride, %r1
 	ldw		R%icache_stride(%r1), %r1
@@ -725,8 +959,17 @@ ENTRY(flush_icache_page_asm)
 	fic,m		%r1(%r28)
 
 	sync
-	bv		%r0(%r2)
+
+#ifdef CONFIG_PA20
+	pitlb,l		%r0(%sr0,%r25)
+#else
+	tlb_lock	%r20,%r21,%r22
 	pitlb		(%sr0,%r25)
+	tlb_unlock	%r20,%r21,%r22
+#endif
+
+	bv		%r0(%r2)
+	nop
 	.exit
 
 	.procend
@@ -775,7 +1018,7 @@ ENTRY(flush_kernel_dcache_page_asm)
 	.procend
 ENDPROC(flush_kernel_dcache_page_asm)
 
-ENTRY(purge_kernel_dcache_page)
+ENTRY(purge_kernel_dcache_page_asm)
 	.proc
 	.callinfo NO_CALLS
 	.entry
@@ -815,7 +1058,7 @@ ENTRY(purge_kernel_dcache_page)
 	.exit
 
 	.procend
-ENDPROC(purge_kernel_dcache_page)
+ENDPROC(purge_kernel_dcache_page_asm)
 
 ENTRY(flush_user_dcache_range_asm)
 	.proc
diff --git a/arch/parisc/kernel/parisc_ksyms.c b/arch/parisc/kernel/parisc_ksyms.c
index a7bb757..25835d8 100644
--- a/arch/parisc/kernel/parisc_ksyms.c
+++ b/arch/parisc/kernel/parisc_ksyms.c
@@ -158,5 +158,6 @@ extern void _mcount(void);
 EXPORT_SYMBOL(_mcount);
 #endif
 
-/* from pacache.S -- needed for copy_page */
-EXPORT_SYMBOL(copy_user_page_asm);
+/* from pacache.S -- needed for clear/copy_page */
+EXPORT_SYMBOL(clear_page_asm);
+EXPORT_SYMBOL(copy_page_asm);
diff --git a/arch/parisc/kernel/signal.c b/arch/parisc/kernel/signal.c
index 12c1ed3..5dd1059 100644
--- a/arch/parisc/kernel/signal.c
+++ b/arch/parisc/kernel/signal.c
@@ -314,7 +314,7 @@ setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 #if DEBUG_SIG
 	/* Assert that we're flushing in the correct space... */
 	{
-		int sid;
+		unsigned long sid;
 		asm ("mfsp %%sr3,%0" : "=r" (sid));
 		DBG(1,"setup_rt_frame: Flushing 64 bytes at space %#x offset %p\n",
 		       sid, frame->tramp);
diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
index c9b9322..f0cb56e 100644
--- a/arch/parisc/kernel/sys_parisc.c
+++ b/arch/parisc/kernel/sys_parisc.c
@@ -92,11 +92,12 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
 {
 	if (len > TASK_SIZE)
 		return -ENOMEM;
-	/* Might want to check for cache aliasing issues for MAP_FIXED case
-	 * like ARM or MIPS ??? --BenH.
-	 */
-	if (flags & MAP_FIXED)
+	if (flags & MAP_FIXED) {
+		if ((flags & MAP_SHARED) &&
+		    (addr - (pgoff << PAGE_SHIFT)) & (SHMLBA - 1))
+			return -EINVAL;
 		return addr;
+	}
 	if (!addr)
 		addr = TASK_UNMAPPED_BASE;
 

^ permalink raw reply related	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-09  6:53 ` Rolf Eike Beer
  2012-05-09 15:55   ` John David Anglin
@ 2012-05-09 21:00   ` Vincent
  1 sibling, 0 replies; 56+ messages in thread
From: Vincent @ 2012-05-09 21:00 UTC (permalink / raw)
  To: Rolf Eike Beer; +Cc: linux-parisc

On 05/09/2012 08:53 AM, Rolf Eike Beer wrote:
> See the mail thread "Boot error using 3.2.1: swapper (pid 1): Illegal 
> instruction (code 8)" I started when I first hit this on my 705.

I agree; this is the same issue, and you pointed at the same "culprit"
commit already. Too bad I did not search the ML archive enough.

V.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-09 15:55   ` John David Anglin
@ 2012-05-09 21:14     ` Vincent
  2012-05-09 21:33       ` John David Anglin
  2012-05-10  2:03       ` John David Anglin
  0 siblings, 2 replies; 56+ messages in thread
From: Vincent @ 2012-05-09 21:14 UTC (permalink / raw)
  To: John David Anglin; +Cc: Rolf Eike Beer, linux-parisc

On 05/09/2012 05:55 PM, John David Anglin wrote:
> Attached is an updated version.   It applies against 3.3.4.

Thanks. It applies on v3.4-rc6 with no issue. However, it crashes at
boot in flush_dcache_page_asm.

Best regards,

V.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-09 21:14     ` Vincent
@ 2012-05-09 21:33       ` John David Anglin
  2012-05-10  2:03       ` John David Anglin
  1 sibling, 0 replies; 56+ messages in thread
From: John David Anglin @ 2012-05-09 21:33 UTC (permalink / raw)
  To: Vincent; +Cc: Rolf Eike Beer, linux-parisc

On 5/9/2012 5:14 PM, Vincent wrote:
> On 05/09/2012 05:55 PM, John David Anglin wrote:
>> Attached is an updated version.   It applies against 3.3.4.
> Thanks. It applies on v3.4-rc6 with no issue. However, it crashes at
> boot in flush_dcache_page_asm.
>
Do you have a specific instruction where it crashes?

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-09 21:14     ` Vincent
  2012-05-09 21:33       ` John David Anglin
@ 2012-05-10  2:03       ` John David Anglin
  2012-05-10  6:41         ` Rolf Eike Beer
  2012-05-12 22:50         ` Helge Deller
  1 sibling, 2 replies; 56+ messages in thread
From: John David Anglin @ 2012-05-10  2:03 UTC (permalink / raw)
  To: Vincent; +Cc: Rolf Eike Beer, linux-parisc

On 9-May-12, at 5:14 PM, Vincent wrote:

> On 05/09/2012 05:55 PM, John David Anglin wrote:
>> Attached is an updated version.   It applies against 3.3.4.
>
> Thanks. It applies on v3.4-rc6 with no issue. However, it crashes at
> boot in flush_dcache_page_asm.


I want to make a general comment.

The hp712/100 is an old machine.  There is no longer ANY support for
parisc open source by HP.  If the parisc user community wants to  
continue
to run current open source software, then it will have to work  
together to
achieve this goal.

In this case, we need to figure out what is wrong with the tmpalias code
on the hp712/100.

Debian dropping hppa after the lenny release was a wake up call.  There
is pressure on other fronts.  See for example the following thread,
http://gcc.gnu.org/ml/gcc/2012-05/msg00093.html

If accepted, it would mean the end of 32-bit GCC development for parisc,
and therefore the end of parisc linux and netbsd systems.  More  
specifically,
it may be reasonable to drop support for PA 1.1 systems.  So, we need
to hear why it is important to continue to try to maintain PA 1.1  
systems.

In general, I have found Debian package maintainers to be supportive
of bug fixes for parisc.  Most packages still support parisc and build  
without
problems but there is some porting work that needs doing.  For example,
mono has seriously rotted.  Without a viable userspace, there's not much
point to maintaining the kernel.

I applaud Mikulas for reviewing Rolf Eike's fixes for 3.4 and posting  
them to the
linux-kernel list.  Maintainers have personal time issues and can't  
always be
available.

I have spent hundreds of hours building packages, working on GCC,
binutils, glibc and kernel bugs over the past year.  I have pushed fixes
upstream and back ported them as quickly as possible because it takes
considerable time before the fixes start to percolate downstream.

I have a project to restart a Debian buildd for parisc and help would be
appreciated.  The key issue is help in reporting and analyzing package
bugs. and informing the appropriate maintainers when there are problems.

I posted a number of kernel work in progress patches to the linux-parisc
list but nobody bothered to test them except for Vincent today.  All I  
know
at this point is my rp3440 is much more stable and runs twice as fast as
it used to with my cache patch.  As such, it can keep up with unstable.
This took hundreds of kernel builds and considerable long term testing.

The problem with cache bugs is they are difficult.  The parisc  
architecture
and the linux requirements for cache routines are inadequately  
documented.
So, it has become a trial and error exercise.  This has always been the
critical problem for parisc-linux and the code in cache.c reflects this.

It is impossible for volunteers to run and maintain a broad range of
hardware.  So, we need to focus on the hardware that is used and will
continue to used over the next few years.  If users want support, then
they need to be willing to help as well.

Regards,
Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-10  2:03       ` John David Anglin
@ 2012-05-10  6:41         ` Rolf Eike Beer
  2012-05-10 16:32           ` John David Anglin
  2012-05-13 14:32           ` Jeroen Roovers
  2012-05-12 22:50         ` Helge Deller
  1 sibling, 2 replies; 56+ messages in thread
From: Rolf Eike Beer @ 2012-05-10  6:41 UTC (permalink / raw)
  To: John David Anglin; +Cc: Vincent, linux-parisc

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

John David Anglin wrote:

> I posted a number of kernel work in progress patches to the linux-parisc
> list but nobody bothered to test them except for Vincent today.  All I
> know
> at this point is my rp3440 is much more stable and runs twice as fast as
> it used to with my cache patch.  As such, it can keep up with unstable.
> This took hundreds of kernel builds and considerable long term testing.

I have your patch from a while back applied to my C8000 and I have not seen 
any crashes or other issues yet (since beginning of April). Your futex patches 
are on this machine for even longer. This of course means only that there is 
no obvious breakage, I did not run any special testcase for any of those stuff, 
but at least it doesn't randomly eats my machine.

I think Guy Martin has the cache patch running on at least one of his 
machines.

Related note: The #Gentoo-HPPA channel on Freenode has at least some activity 
every other day, often even daily. The last 3 critical breakages I had (the 
gcc bug breaking swap, the gcc bug breaking ext4 and the 3.4-rc compile 
breakage) were first discussed there before posting anywhere. Because of that 
the initial report e.g. to linux-parisc already had rather good data on what 
is happening.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-10  6:41         ` Rolf Eike Beer
@ 2012-05-10 16:32           ` John David Anglin
  2012-05-10 19:32             ` Rolf Eike Beer
  2012-05-11 21:17             ` Vincent
  2012-05-13 14:32           ` Jeroen Roovers
  1 sibling, 2 replies; 56+ messages in thread
From: John David Anglin @ 2012-05-10 16:32 UTC (permalink / raw)
  To: Rolf Eike Beer; +Cc: Vincent, linux-parisc

On 5/10/2012 2:41 AM, Rolf Eike Beer wrote:
> John David Anglin wrote:
>
>> I posted a number of kernel work in progress patches to the linux-parisc
>> list but nobody bothered to test them except for Vincent today.  All I
>> know
>> at this point is my rp3440 is much more stable and runs twice as fast as
>> it used to with my cache patch.  As such, it can keep up with unstable.
>> This took hundreds of kernel builds and considerable long term testing.
> I have your patch from a while back applied to my C8000 and I have not seen
> any crashes or other issues yet (since beginning of April). Your futex patches
> are on this machine for even longer. This of course means only that there is
> no obvious breakage, I did not run any special testcase for any of those stuff,
> but at least it doesn't randomly eats my machine.
>
> I think Guy Martin has the cache patch running on at least one of his
> machines.
>
> Related note: The #Gentoo-HPPA channel on Freenode has at least some activity
> every other day, often even daily. The last 3 critical breakages I had (the
> gcc bug breaking swap, the gcc bug breaking ext4 and the 3.4-rc compile
> breakage) were first discussed there before posting anywhere. Because of that
> the initial report e.g. to linux-parisc already had rather good data on what
> is happening.
>
Thanks, it's good to know that there has been some other testing.

Does anyone have a working 32-bit kernel using the tmpalias support?  It 
would be nice
to know if the problem is a 32-bit or PA 1.1 issue.

I asked where the crash occurred because PA 2.0 mnemonics are used in 
the tmpalias
code.  On the other hand, if the failure occurs on the first flush 
instruction, the issue is likely
in the TLB insert code in entry.S.

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-10 16:32           ` John David Anglin
@ 2012-05-10 19:32             ` Rolf Eike Beer
  2012-05-11 21:17             ` Vincent
  1 sibling, 0 replies; 56+ messages in thread
From: Rolf Eike Beer @ 2012-05-10 19:32 UTC (permalink / raw)
  To: John David Anglin; +Cc: Vincent, linux-parisc

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

John David Anglin wrote:
> On 5/10/2012 2:41 AM, Rolf Eike Beer wrote:
> > John David Anglin wrote:
> >> I posted a number of kernel work in progress patches to the linux-parisc
> >> list but nobody bothered to test them except for Vincent today.  All I
> >> know at this point is my rp3440 is much more stable and runs twice as
> >> fast as it used to with my cache patch.  As such, it can keep up with
> >> unstable. This took hundreds of kernel builds and considerable long term
> >> testing.
> > 
> > I have your patch from a while back applied to my C8000 and I have not
> > seen any crashes or other issues yet (since beginning of April).

> > I think Guy Martin has the cache patch running on at least one of his
> > machines.

> Thanks, it's good to know that there has been some other testing.
> 
> Does anyone have a working 32-bit kernel using the tmpalias support?  It
> would be nice to know if the problem is a 32-bit or PA 1.1 issue.
> 
> I asked where the crash occurred because PA 2.0 mnemonics are used in
> the tmpalias code.  On the other hand, if the failure occurs on the first
> flush instruction, the issue is likely in the TLB insert code in entry.S.

I have a C3600 running a 32 bit kernel and it is rock solid. It is currently 
running 3.3.5 and has before been running 3.2.4 without any problems (but both 
without your cache patch).

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-10 16:32           ` John David Anglin
  2012-05-10 19:32             ` Rolf Eike Beer
@ 2012-05-11 21:17             ` Vincent
  1 sibling, 0 replies; 56+ messages in thread
From: Vincent @ 2012-05-11 21:17 UTC (permalink / raw)
  To: John David Anglin; +Cc: Rolf Eike Beer, linux-parisc

On 05/10/2012 06:32 PM, John David Anglin wrote:
(..)
> I asked where the crash occurred because PA 2.0 mnemonics are used in
> the tmpalias
> code.  On the other hand, if the failure occurs on the first flush
> instruction, the issue is likely
> in the TLB insert code in entry.S.

Hi John,

I think the crash occurs at the first 'fdc,m r1(ret0)', but I don't read
PA assembly that much, so you might want to cross-check by yourself :)
Here is the crash dump:

---
      _______________________________
     < Your System ate a SPARC! Gah! >
      -------------------------------
             \   ^__^
                 (__)\       )\/\
                  U  ||----w |
                     ||     ||
swapper (pid 1): Illegal instruction (code 8)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000000000000000000000000 Not tainted
r00-03  00000000 00000001 1019d550 105ebbc0
r04-07  00000000 00000017 16640000 ffeffff6
r08-11  0f2ff000 0f000000 00000001 fff00ff6
r12-15  1742c000 00000017 00000000 00000020
r16-19  00000000 00000043 1662f000 fffff000
r20-23  000005de 00118277 00000001 00000020
r24-27  00000000 00000000 0000bbc0 104f2000
r28-31  0f2ff000 00000001 17430600 102691d8
sr00-03  00000000 00000001 00000000 00000000
sr04-07  00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 10100c10 10100c14
 IIR: 078112a0    ISR: 00000000  IOR: 0f2ff000
 CPU:        0   CR30: 17430000 CR31: 00000002
 ORIG_R28: 1662f000
 IAOQ[0]: flush_dcache_page_asm+0x28/0x7c
 IAOQ[1]: flush_dcache_page_asm+0x2c/0x7c
 RP(r2): __get_user_pages+0x2c8/0x370
Backtrace:
 [<1019d550>] __get_user_pages+0x2c8/0x370
 [<101bcf8c>] get_arg_page+0x5c/0x108
 [<101bd250>] copy_strings+0x114/0x25c
 [<101bd3b4>] copy_strings_kernel+0x1c/0x30
 [<101be78c>] do_execve+0x1f4/0x370
 [<101180a0>] sys_execve+0x44/0x70
 [<10103084>] __execve+0x20/0x34
 [<1012a224>] vprintk+0x39c/0x3f0
 [<1010e074>] printk+0x24/0x30
 [<101110cc>] init_post+0x6c/0x148
 [<105a1624>] kernel_init+0x218/0x250

Backtrace:
 [<1011329c>] die_if_kernel+0x138/0x1b0
 [<101134ec>] handle_interruption+0x1d8/0x6d8
 [<10104078>] intr_check_sig+0x0/0x34
 [<1018975c>] __alloc_pages_nodemask+0x1a4/0x688
---

And here is the disassembly of function flush_dcache_page_asm:

---
10100be8 <flush_dcache_page_asm>:
10100be8:       23 80 01 e0     ldil L%f000000,ret0
10100bec:       d3 5a 1b 07     extrw,u r26,24,25,r26
10100bf0:       d7 99 0c 0a     depw r25,31,22,ret0
10100bf4:       d7 80 1c 14     depwi 0,31,12,ret0
10100bf8:       07 80 12 00     pdtlb r0(ret0)
10100bfc:       20 39 c2 08     ldil L%104f2000,r1
10100c00:       48 21 00 b8     ldw 5c(r1),r1
10100c04:       d7 22 19 9f     depwi,z 1,19,1,r25
10100c08:       0b 3c 06 39     add ret0,r25,r25
10100c0c:       08 39 04 39     sub r25,r1,r25
10100c10:       07 81 12 a0     fdc,m r1(ret0)
10100c14:       07 81 12 a0     fdc,m r1(ret0)
10100c18:       07 81 12 a0     fdc,m r1(ret0)
10100c1c:       07 81 12 a0     fdc,m r1(ret0)
10100c20:       07 81 12 a0     fdc,m r1(ret0)
10100c24:       07 81 12 a0     fdc,m r1(ret0)
10100c28:       07 81 12 a0     fdc,m r1(ret0)
10100c2c:       07 81 12 a0     fdc,m r1(ret0)
10100c30:       07 81 12 a0     fdc,m r1(ret0)
10100c34:       07 81 12 a0     fdc,m r1(ret0)
10100c38:       07 81 12 a0     fdc,m r1(ret0)
10100c3c:       07 81 12 a0     fdc,m r1(ret0)
10100c40:       07 81 12 a0     fdc,m r1(ret0)
10100c44:       07 81 12 a0     fdc,m r1(ret0)
10100c48:       07 81 12 a0     fdc,m r1(ret0)
10100c4c:       83 3c 9f 7d     cmpb,<< ret0,r25,10100c10
<flush_dcache_page_asm+0x28>
10100c50:       07 81 12 a0     fdc,m r1(ret0)
10100c54:       00 00 04 00     sync
10100c58:       07 20 12 00     pdtlb r0(r25)
10100c5c:       e8 40 c0 00     bv r0(rp)
10100c60:       08 00 02 40     nop
---

Best regards,

V.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-10  2:03       ` John David Anglin
  2012-05-10  6:41         ` Rolf Eike Beer
@ 2012-05-12 22:50         ` Helge Deller
  2012-05-13 14:11           ` John David Anglin
  2012-05-14  1:10           ` John David Anglin
  1 sibling, 2 replies; 56+ messages in thread
From: Helge Deller @ 2012-05-12 22:50 UTC (permalink / raw)
  To: John David Anglin; +Cc: Vincent, Rolf Eike Beer, linux-parisc

[-- Attachment #1: Type: text/plain, Size: 4424 bytes --]

On 05/10/2012 04:03 AM, John David Anglin wrote:
> On 9-May-12, at 5:14 PM, Vincent wrote:
>
>> On 05/09/2012 05:55 PM, John David Anglin wrote:
>>> Attached is an updated version.   It applies against 3.3.4.
>>
>> Thanks. It applies on v3.4-rc6 with no issue. However, it crashes at
>> boot in flush_dcache_page_asm.
>
>
> I want to make a general comment.
>
> The hp712/100 is an old machine.  There is no longer ANY support for
> parisc open source by HP.  If the parisc user community wants to continue
> to run current open source software, then it will have to work 
> together to
> achieve this goal.
>
> In this case, we need to figure out what is wrong with the tmpalias code
> on the hp712/100.
>
> Debian dropping hppa after the lenny release was a wake up call.  There
> is pressure on other fronts.  See for example the following thread,
> http://gcc.gnu.org/ml/gcc/2012-05/msg00093.html
>
> If accepted, it would mean the end of 32-bit GCC development for parisc,
> and therefore the end of parisc linux and netbsd systems.  More 
> specifically,
> it may be reasonable to drop support for PA 1.1 systems.  So, we need
> to hear why it is important to continue to try to maintain PA 1.1 
> systems.
>
> In general, I have found Debian package maintainers to be supportive
> of bug fixes for parisc.  Most packages still support parisc and build 
> without
> problems but there is some porting work that needs doing.  For example,
> mono has seriously rotted.  Without a viable userspace, there's not much
> point to maintaining the kernel.
>
> I applaud Mikulas for reviewing Rolf Eike's fixes for 3.4 and posting 
> them to the
> linux-kernel list.  Maintainers have personal time issues and can't 
> always be
> available.
>
> I have spent hundreds of hours building packages, working on GCC,
> binutils, glibc and kernel bugs over the past year.  I have pushed fixes
> upstream and back ported them as quickly as possible because it takes
> considerable time before the fixes start to percolate downstream.
>
> I have a project to restart a Debian buildd for parisc and help would be
> appreciated.  The key issue is help in reporting and analyzing package
> bugs. and informing the appropriate maintainers when there are problems.
>
> I posted a number of kernel work in progress patches to the linux-parisc
> list but nobody bothered to test them except for Vincent today.  All I 
> know
> at this point is my rp3440 is much more stable and runs twice as fast as
> it used to with my cache patch.  As such, it can keep up with unstable.
> This took hundreds of kernel builds and considerable long term testing.
>
> The problem with cache bugs is they are difficult.  The parisc 
> architecture
> and the linux requirements for cache routines are inadequately 
> documented.
> So, it has become a trial and error exercise.  This has always been the
> critical problem for parisc-linux and the code in cache.c reflects this.
>
> It is impossible for volunteers to run and maintain a broad range of
> hardware.  So, we need to focus on the hardware that is used and will
> continue to used over the next few years.  If users want support, then
> they need to be willing to help as well.

Hi Dave,

I have my machines now up and running again.

I tested upstream version (bcc62fb) and got on all my machines the same 
bug (same Kernel binary started on all):

Backtrace:
  [<1021dc3c>] mpage_readpages+0xf0/0x16c
  [<10257e88>] ext3_readpages+0x28/0x38
  [<101acb90>] __do_page_cache_readahead+0x1e0/0x27c
  [<101acc5c>] ra_submit+0x30/0x40
  [<101acee0>] ondemand_readahead+0xd0/0x26c

or

Backtrace:
  [<1021dc3c>] mpage_readpages+0xf0/0x16c
  [<10257e88>] ext3_readpages+0x28/0x38
  [<101acb90>] __do_page_cache_readahead+0x1e0/0x27c
  [<101acc5c>] ra_submit+0x30/0x40
  [<101acee0>] ondemand_readahead+0xd0/0x26c
  [<101ad1a8>] page_cache_sync_readahead+0x44/0x74
  [<101a38e4>] generic_file_aio_read+0x400/0x764
  [<101e243c>] do_sync_read+0xd4/0x130
  [<101e32f4>] vfs_read+0xac/0x158
  [<101ea47c>] kernel_read+0x40/0x5c
  [<101ea58c>] prepare_binprm+0xf4/0x130
  [<101eae3c>] do_execve+0x2b8/0x3a4
  [<1012199c>] sys_execve+0x64/0x94
  [<10104084>] __execve+0x20/0x34
  [<10136374>] vprintk+0x1e8/0x488
  [<101a83e8>] __free_pages+0x54/0x64


all logs attached for the 715/64, B160L and C3000 machines.

I'll test tomorrow your patch (but will try to update my binutils/gcc 
prior to that).

Helge




[-- Attachment #2: b160L.log --]
[-- Type: text/plain, Size: 14392 bytes --]

Information: No console specified on kernel command line. This is normal.
PALO will choose the console currently used by firmware (serial).
Command line for kernel: 'HOME=/ root=/dev/sda3 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux'
Selected kernel: /vmlinux from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing 32-bit kernelELF32 executable
Entry 00100000 first 00100000 n 3
Segment 0 load 00100000 size 6647808 mediaptr 0x1000
Segment 1 load 007a0000 size 185472 mediaptr 0x658000
Segment 2 load 007ce000 size 145080 mediaptr 0x686000
Branching to kernel entry point 0x00100000.  If this is the last
message you see, you may need to switch your console.  This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.4.0-rc6-32bit+ (deller@p100) (gcc version 4.3.3 (GCC) ) #7 Sat May 12 22:55:41 CEST 2012
unwind_init: start = 0x106a8000, end = 0x106ebdc0, entries = 17372
WARNING: Out of order unwind entry! 106a95c0 and 106a95d0
WARNING: Out of order unwind entry! 106a95d0 and 106a95e0
WARNING: Out of order unwind entry! 106aa090 and 106aa0a0
WARNING: Out of order unwind entry! 106aa0a0 and 106aa0b0
WARNING: Out of order unwind entry! 106aa110 and 106aa120
WARNING: Out of order unwind entry! 106aa120 and 106aa130
WARNING: Out of order unwind entry! 106aa140 and 106aa150
WARNING: Out of order unwind entry! 106aa150 and 106aa160
WARNING: Out of order unwind entry! 106aa160 and 106aa170
WARNING: Out of order unwind entry! 106aa170 and 106aa180
WARNING: Out of order unwind entry! 106aa180 and 106aa190
WARNING: Out of order unwind entry! 106aa190 and 106aa1a0
WARNING: Out of order unwind entry! 106aa1a0 and 106aa1b0
WARNING: Out of order unwind entry! 106aa1b0 and 106aa1c0
WARNING: Out of order unwind entry! 106aa1c0 and 106aa1d0
WARNING: Out of order unwind entry! 106aa1d0 and 106aa1e0
WARNING: Out of order unwind entry! 106aa1e0 and 106aa1f0
WARNING: Out of order unwind entry! 106aa1f0 and 106aa200
WARNING: Out of order unwind entry! 106aa210 and 106aa220
WARNING: Out of order unwind entry! 106aa220 and 106aa230
FP[0] enabled: Rev 1 Model 15
The 32-bit Kernel has started...
bootconsole [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: System Map.
model 00005020 00000481 00000000 02020202 7794d7fe 100000f0 00000004 000000ba 000000ba
vers  00000008
CPUID vers 15 rev 8 (0x000001e8)
capabilities 0x2
model 9000/778/B160L
Total Memory: 128 MB
LED display at f0190001 registered
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: HOME=/ root=/dev/sda3 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
allocated 262144 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Memory: 122356k/131072k available (4505k kernel code, 8716k reserved, 1964k data, 328k init)
virtual kernel memory layout:
    vmalloc : 0x00810000 - 0x0f000000   ( 231 MB)
    memory  : 0x10000000 - 0x18000000   ( 128 MB)
      .init : 0x107a0000 - 0x107f2000   ( 328 kB)
      .data : 0x10566690 - 0x107517b0   (1964 kB)
      .text : 0x10100000 - 0x10566690   (4505 kB)
NR_IRQS:96
Console: colour dummy device 128x48
Calibrating delay loop... 106.39 BogoMIPS (lpj=531968)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys blkio
xor: measuring software checksum speed
   8regs     :   131.200 MB/sec
   8regs_prefetch:   130.800 MB/sec
   32regs    :   206.400 MB/sec
   32regs_prefetch:   206.000 MB/sec
xor: using function: 32regs (206.400 MB/sec)
atomic64 test passed
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Found devices:
1. Phantom PseudoBC GSC+ Port at 0xffc00000 [8] { 7, 0x0, 0x504, 0x00000 }
2. Dino PCI Bridge at 0xfff80000 [8/0] { 13, 0x3, 0x680, 0x0000a }
3. Merlin+ 132 Dino RS-232 at 0xfff83000 [8/0/63] { 10, 0x0, 0x022, 0x0008c }
4. Merlin 160 Core FW-SCSI at 0xfff8c000 [8/12] { 4, 0x0, 0x03d, 0x00089 }
5. Merlin 160 Core BA at 0xffd00000 [8/16] { 11, 0x0, 0x03d, 0x00081 }, additional addresses: 0xffd0c000 0xffc00000 
6. Merlin 160 Core RS-232 at 0xffd05000 [8/16/4] { 10, 0x0, 0x03d, 0x0008c }
7. Merlin 160 Core SCSI at 0xffd06000 [8/16/5] { 10, 0x0, 0x03d, 0x00082 }
8. Merlin 160 Core LAN (802.3) at 0xffd07000 [8/16/6] { 10, 0x0, 0x03d, 0x0008a }
9. Merlin 160 Core Centronics at 0xffd02000 [8/16/0] { 10, 0x0, 0x03d, 0x00074 }, additional addresses: 0xffd01000 0xffd03000 
10. Merlin 160 Core Audio at 0xffd04000 [8/16/1] { 10, 0x4, 0x03d, 0x0007b }
11. Merlin 160 Core PS/2 Port at 0xffd08000 [8/16/7] { 10, 0x0, 0x03d, 0x00084 }
12. Merlin 160 Core PS/2 Port at 0xffd08100 [8/16/8] { 10, 0x0, 0x03d, 0x00084 }
13. Coral SGC Graphics at 0xfa000000 [8/4] { 10, 0x0, 0x004, 0x00077 }
14. Coral SGC Graphics at 0xf4000000 [8/8] { 10, 0x0, 0x004, 0x00077 }
15. Gecko GSC Core Graphics at 0xf8000000 [8/24] { 10, 0x0, 0x016, 0x00085 }, additional addresses: 0xf0011000 
16. Merlin L2 160 (9000/778/B160L) at 0xfffbe000 [62] { 0, 0x0, 0x502, 0x00004 }
17. Memory at 0xfffbf000 [63] { 1, 0x0, 0x067, 0x00009 }
18. Merlin+ 132 Dino PS/2 Port at 0xfff81000 [1] { 10, 0x0, 0x022, 0x00096 }
CPU(s): 1 x PA7300LC (PCX-L2) at 160.000000 MHz
Setting cache flush threshold to 920 (1 CPUs online)
Lasi version 0 at 0xffd00000 found.
Dino version 3.1 found at 0xfff80000
Dino: No PCI devices enabled.
dino 8:0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
powersw: Soft power switch at 0xf0140000 enabled.
bio: create slab <bio-0> at 0
raid6: int32x1     59 MB/s
raid6: int32x2     72 MB/s
raid6: int32x4     89 MB/s
raid6: int32x8     49 MB/s
raid6: using algorithm int32x4 (89 MB/s)
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource cr16
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 4, 81920 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP: reno registered
UDP hash table entries: 128 (order: 0, 6144 bytes)
UDP-Lite hash table entries: 128 (order: 0, 6144 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Enabling PDC chassis warnings support v0.05
Initializing RT-Tester: OK
====[ backtrace testing ]===========
Testing a backtrace from process context.
The following trace is a kernel self test and not a bug!
Backtrace:
 [<1011b070>] show_stack+0x18/0x28
 [<101148f8>] dump_stack+0x1c/0x2c
 [<10181098>] backtrace_regression_test+0x50/0x130
 [<10118eac>] do_one_initcall+0x54/0x284
 [<107a1abc>] kernel_init+0x1a8/0x270
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a backtrace from irq context.
The following trace is a kernel self test and not a bug!
Backtrace:
 [<1011b070>] show_stack+0x18/0x28
 [<101148f8>] dump_stack+0x1c/0x2c
 [<10181028>] backtrace_test_irq_callback+0x18/0x38
 [<1013b96c>] tasklet_action+0x80/0xe4
 [<1018ffc0>] rcu_process_callbacks+0x30/0x40
 [<1013c2e0>] __do_softirq+0x148/0x198
 [<1013c39c>] run_ksoftirqd+0x6c/0x120
 [<101174bc>] schedule+0x30/0x74
 [<101546f4>] kthread+0xac/0xb4
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a saved backtrace.
The following trace is a kernel self test and not a bug!
 [<10124bd4>] save_stack_trace+0x28/0x60
 [<10181140>] backtrace_regression_test+0xf8/0x130
 [<10118eac>] do_one_initcall+0x54/0x284
 [<107a1abc>] kernel_init+0x1a8/0x270
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24
 [<ffffffff>] 0xffffffff
====[ end of backtrace testing ]====
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
msgmni has been set to 238
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
PDC Stable Storage facility v0.30
STI GSC/PCI core graphics driver Version 0.9a
    id 2bcb015a-9a02587, conforms to spec rev. 8.04
    graphics card name: HPA4071B
    id 2d08c0a7-9a02587, conforms to spec rev. 8.07
    graphics card name: HPA4450AX1024
    id 2d08c0a7-9a02587, conforms to spec rev. 8.07
    graphics card name: INTERNAL_EG_X1024
sticon: Initializing STI text console.
Console: switching to colour STI console 160x64
Console: switching to colour frame buffer device 160x64
fb0: stifb 1280x1024-32 frame buffer device, HPA4071B, id: 2bcb015a, mmio: 0xfa100000
fb1: stifb 1024x768-8 frame buffer device, HPA4450AX1024, id: 2d08c0a7, mmio: 0xf4100000
fb2: stifb 1024x768-8 frame buffer device, INTERNAL_EG_X1024, id: 2d08c0a7, mmio: 0xf8100000
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
8:16:4: ttyS0 at MMIO 0xffd05800 (irq = 16) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
8:0:63: ttyS1 at MMIO 0xfff83800 (irq = 22) is a 16550A
Linux agpgart interface v0.103
parport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xffd02800, irq 19 [PCSPP,TRISTATE]
parport0: fix this legacy no-device port driver!
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
ide-cd driver 5.00
zalon_probe: Zalon version 1, IRQ 67
ncr53c720-0: rev 0xf irq 67
ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential
scsi0 : ncr53c8xx-3.4.3g
scsi 0:0:6:0: Direct-Access     SEAGATE  ST32171W         HP03 PQ: 0 ANSI: 2
scsi target0:0:6: Beginning Domain Validation
scsi target0:0:6: asynchronous
scsi target0:0:6: wide asynchronous
scsi target0:0:6: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8)
scsi target0:0:6: Domain Validation skipping write tests
scsi target0:0:6: Ending Domain Validation
53c700: Version 2.8 By James.Bottomley@HansenPartnership.com
scsi1: 53c710 rev 2 
scsi1 : LASI SCSI 53c700
scsi 1:0:1:0: CD-ROM            PHILIPS  PCA80SC          V3-0 PQ: 0 ANSI: 2
scsi target1:0:1: Beginning Domain Validation
scsi target1:0:1: asynchronous
scsi target1:0:1: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 8)
scsi target1:0:1: Domain Validation skipping write tests
scsi target1:0:1: Ending Domain Validation
st: Version 20101219, fixed bufsize 32768, s/g segs 256
sd 0:0:6:0: [sda] 4194685 512-byte logical blocks: (2.14 GB/2.00 GiB)
sd 0:0:6:0: [sda] Write Protect is off
sr0: scsi-1 drive
cdrom: Uniform CD-ROM driver Revision: 3.20
sd 0:0:6:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 0:0:6:0: Attached scsi generic sg0 type 0
sr 1:0:1:0: Attached scsi generic sg1 type 5
LASI 82596 driver - Revision: 1.30
Found i82596 at 0xffd07000, IRQ 18
eth0: 82596 at 0xffd07000, 08:00:09:ef:34:f5 IRQ 18.
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
serio: gsc-ps2-keyboard port at 0x0081a000 irq 21 @ 8:16:7
serio: gsc-ps2-mouse port at 0x0081c100 irq 21 @ 8:16:8
 sda: sda1 sda2 sda3 < sda5 sda6 >
mousedev: PS/2 mouse device common for all mice
rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid10 personality registered for level 10
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
device-mapper: uevent: version 1.0.3
sd 0:0:6:0: [sda] Attached SCSI disk
device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using timer interrupt.
TCP: cubic registered
NET: Registered protocol family 17
rtc-generic rtc-generic: setting system clock to 1987-04-12 22:08:53 UTC (545263733)
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 192.168.178.50, my address is 192.168.178.65
IP-Config: Complete:
     device=eth0, addr=192.168.178.65, mask=255.255.255.0, gw=192.168.178.1
     host=b160, domain=box, nis-domain=(none)
     bootserver=192.168.178.50, rootserver=192.168.178.50, rootpath=
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
attempt to access beyond end of device
sda3: rw=0, want=4, limit=2
EXT3-fs (sda3): error: unable to read superblock
attempt to access beyond end of device
sda3: rw=0, want=4, limit=2
EXT2-fs (sda3): error: unable to read superblock
swapper: sending ioctl 5310 to a partition!
swapper: sending ioctl 5310 to a partition!
attempt to access beyond end of device
sda3: rw=0, want=66, limit=2
isofs_fill_super: bread failed, dev=sda3, iso_blknum=16, block=32
List of all partitions:
0b00         1048575 sr0  driver: sr
0800         2097342 sda  driver: sd
  0801           32098 sda1 00000000-0000-0000-0000-000000000000
  0802          128520 sda2 00000000-0000-0000-0000-000000000000
  0803               1 sda3 00000000-0000-0000-0000-000000000000
  0805         1791216 sda5 00000000-0000-0000-0000-000000000000
  0806          144553 sda6 00000000-0000-0000-0000-000000000000
No filesystem could mount root, tried:  ext3 ext2 vfat iso9660
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,3)
Backtrace:
 [<1011b070>] show_stack+0x18/0x28
 [<101148f8>] dump_stack+0x1c/0x2c
 [<101149dc>] panic+0xd4/0x28c
 [<107a292c>] mount_block_root+0x254/0x28c
 [<107a2a10>] mount_root+0xac/0x138
 [<107a2b38>] prepare_namespace+0x9c/0x1f4
 [<107a1b28>] kernel_init+0x214/0x270
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24


[-- Attachment #3: c3000.log --]
[-- Type: text/plain, Size: 33446 bytes --]

Information: No console specified on kernel command line. This is normal.
PALO will choose the console currently used by firmware (serial).
Command line for kernel: 'HOME=/ root=/dev/sda3 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux'
Selected kernel: /vmlinux from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... 
This box can boot either 32 or 64-bit kernels...Only see a 32-bit kernel, using thatELF32 executable
Entry 00100000 first 00100000 n 3
Segment 0 load 00100000 size 6647808 mediaptr 0x1000
Segment 1 load 007a0000 size 185472 mediaptr 0x658000
Segment 2 load 007ce000 size 145080 mediaptr 0x686000
Branching to kernel entry point 0x00100000.  If this is the last
message you see, you may need to switch your console.  This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.4.0-rc6-32bit+ (deller@p100) (gcc version 4.3.3 (GCC) ) #7 Sat May 12 22:55:41 CEST 2012
unwind_init: start = 0x106a8000, end = 0x106ebdc0, entries = 17372
WARNING: Out of order unwind entry! 106a95c0 and 106a95d0
WARNING: Out of order unwind entry! 106a95d0 and 106a95e0
WARNING: Out of order unwind entry! 106aa090 and 106aa0a0
WARNING: Out of order unwind entry! 106aa0a0 and 106aa0b0
WARNING: Out of order unwind entry! 106aa110 and 106aa120
WARNING: Out of order unwind entry! 106aa120 and 106aa130
WARNING: Out of order unwind entry! 106aa140 and 106aa150
WARNING: Out of order unwind entry! 106aa150 and 106aa160
WARNING: Out of order unwind entry! 106aa160 and 106aa170
WARNING: Out of order unwind entry! 106aa170 and 106aa180
WARNING: Out of order unwind entry! 106aa180 and 106aa190
WARNING: Out of order unwind entry! 106aa190 and 106aa1a0
WARNING: Out of order unwind entry! 106aa1a0 and 106aa1b0
WARNING: Out of order unwind entry! 106aa1b0 and 106aa1c0
WARNING: Out of order unwind entry! 106aa1c0 and 106aa1d0
WARNING: Out of order unwind entry! 106aa1d0 and 106aa1e0
WARNING: Out of order unwind entry! 106aa1e0 and 106aa1f0
WARNING: Out of order unwind entry! 106aa1f0 and 106aa200
WARNING: Out of order unwind entry! 106aa210 and 106aa220
WARNING: Out of order unwind entry! 106aa220 and 106aa230
FP[0] enabled: Rev 1 Model 19
The 32-bit Kernel has started...
bootconsole [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: System Map.
model 00005dc0 00000481 00000000 00000002 777c3e84 100000f0 00000008 000000b2 000000b2
vers  00000301
CPUID vers 19 rev 11 (0x0000026b)
capabilities 0x7
model 9000/785/C3700
Total Memory: 2048 MB
LCD display at f05d0008,f05d0000 registered
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 520192
Kernel command line: HOME=/ root=/dev/sda3 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
allocated 4194304 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Memory: 2065788k/2097152k available (4505k kernel code, 31364k reserved, 1964k data, 328k init)
virtual kernel memory layout:
    vmalloc : 0x00008000 - 0x0f000000   ( 239 MB)
    memory  : 0x10000000 - 0x90000000   (2048 MB)
      .init : 0x107a0000 - 0x107f2000   ( 328 kB)
      .data : 0x10566690 - 0x107517b0   (1964 kB)
      .text : 0x10100000 - 0x10566690   (4505 kB)
NR_IRQS:96
Console: colour dummy device 128x48
Calibrating delay loop... 1495.85 BogoMIPS (lpj=7479296)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys blkio
xor: measuring software checksum speed
   8regs     :  1808.800 MB/sec
   8regs_prefetch:  1727.600 MB/sec
   32regs    :  1444.800 MB/sec
   32regs_prefetch:  1431.200 MB/sec
xor: using function: 8regs (1808.800 MB/sec)
atomic64 test passed
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Found devices:
1. Astro BC Runway Port at 0xfed00000 [10] { 12, 0x0, 0x582, 0x0000b }
2. Elroy PCI Bridge at 0xfed30000 [10/0] { 13, 0x0, 0x782, 0x0000a }
3. Elroy PCI Bridge at 0xfed32000 [10/1] { 13, 0x0, 0x782, 0x0000a }
4. Elroy PCI Bridge at 0xfed38000 [10/4] { 13, 0x0, 0x782, 0x0000a }
5. Elroy PCI Bridge at 0xfed3c000 [10/6] { 13, 0x0, 0x782, 0x0000a }
6. Allegro W2 at 0xfffa0000 [32] { 0, 0x0, 0x5dc, 0x00004 }
7. Memory at 0xfed10200 [49] { 1, 0x0, 0x09c, 0x00009 }
CPU(s): 1 x PA8700 (PCX-W2) at 750.000000 MHz
Setting cache flush threshold to a20 (1 CPUs online)
SBA found Astro 2.1 at 0xfed00000
Elroy version TR4.0 (0x5) found at 0xfed30000
LBA 10:0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0x1fff]
pci_bus 0000:00: root bus resource [mem 0xf2000000-0xf23fffff]
PCI: Enabled native mode for NS87415 (pif=0x8f)
Elroy version TR4.0 (0x5) found at 0xfed32000
LBA 10:1: PCI host bridge to bus 0000:01
pci_bus 0000:01: root bus resource [io  0x12000-0x13fff] (bus address [0x2000-0x3fff])
pci_bus 0000:01: root bus resource [mem 0xf6000000-0xf6ffffff]
pci_bus 0000:01: root bus resource [mem 0xf2400000-0xf27fffff]
pci 0000:01:04.0: no compatible bridge window for [mem 0xf6000000-0xf7ffffff]
iosapic: no IRTE for 0000:01:04.0 (IRQ not connected?)
pci 0000:01:05.0: no compatible bridge window for [mem 0xf8000000-0xf8ffffff pref]
iosapic: no IRTE for 0000:01:05.0 (IRQ not connected?)
pci 0000:01:06.0: PCI bridge to [bus 02-ff]
pci 0000:01:06.0: can't handle 64-bit address space for bridge
pci 0000:01:06.0: no compatible bridge window for [??? 0x00000000 flags 0x0]
pci 0000:01:06.0: no compatible bridge window for [mem 0xf9000000-0xfbffffff]
pci 0000:01:06.0: no compatible bridge window for [??? 0x00000000 flags 0x0]
pci 0000:01:06.0: no compatible bridge window for [??? 0x00000000 flags 0x0]
pci 0000:01:06.0: device not available (can't reserve [mem 0xf9000000-0xfbffffff])
pci 0000:01:06.0: Error enabling bridge (-22), continuing
Elroy version TR4.0 (0x5) found at 0xfed38000
LBA 10:4: PCI host bridge to bus 0000:03
pci_bus 0000:03: root bus resource [io  0x28000-0x29fff] (bus address [0x8000-0x9fff])
pci_bus 0000:03: root bus resource [mem 0xf3000000-0xf33fffff]
Elroy version TR4.0 (0x5) found at 0xfed3c000
LBA 10:6: PCI host bridge to bus 0000:04
pci_bus 0000:04: root bus resource [io  0x3c000-0x3dfff] (bus address [0xc000-0xdfff])
pci_bus 0000:04: root bus resource [mem 0xf4000000-0xf5ffffff]
pci_bus 0000:04: root bus resource [mem 0xf3800000-0xf3bfffff]
iosapic: hpa not registered for 0000:04:02.0
powersw: Soft power switch at 0xf0400804 enabled.
bio: create slab <bio-0> at 0
raid6: int32x1    434 MB/s
raid6: int32x2    499 MB/s
raid6: int32x4    530 MB/s
raid6: int32x8    404 MB/s
raid6: using algorithm int32x4 (530 MB/s)
vgaarb: device added: PCI:0000:02:00.0,decodes=io+mem,owns=none,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:02:00.0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource cr16
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 8, 1310720 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP: reno registered
UDP hash table entries: 1024 (order: 3, 49152 bytes)
UDP-Lite hash table entries: 1024 (order: 3, 49152 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
SuperIO: Found NS87560 Legacy I/O device at 0000:00:0e.1 (IRQ 67)
SuperIO: Serial port 1 at 0x3f8
SuperIO: Serial port 2 at 0x2f8
SuperIO: Parallel port at 0x378
SuperIO: Floppy controller at 0x3f0
SuperIO: ACPI at 0x7e0
SuperIO: USB regulator enabled
Enabling PDC chassis warnings support v0.05
Initializing RT-Tester: OK
====[ backtrace testing ]===========
Testing a backtrace from process context.
The following trace is a kernel self test and not a bug!
Backtrace:
 [<1011b070>] show_stack+0x18/0x28
 [<101148f8>] dump_stack+0x1c/0x2c
 [<10181098>] backtrace_regression_test+0x50/0x130
 [<10118eac>] do_one_initcall+0x54/0x284
 [<107a1abc>] kernel_init+0x1a8/0x270
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a backtrace from irq context.
The following trace is a kernel self test and not a bug!
Backtrace:
 [<1011b070>] show_stack+0x18/0x28
 [<101148f8>] dump_stack+0x1c/0x2c
 [<10181028>] backtrace_test_irq_callback+0x18/0x38
 [<1013b96c>] tasklet_action+0x80/0xe4
 [<1018ffc0>] rcu_process_callbacks+0x30/0x40
 [<1013c2e0>] __do_softirq+0x148/0x198
 [<1013c39c>] run_ksoftirqd+0x6c/0x120
 [<101174bc>] schedule+0x30/0x74
 [<101546f4>] kthread+0xac/0xb4
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a saved backtrace.
The following trace is a kernel self test and not a bug!
 [<10124bd4>] save_stack_trace+0x28/0x60
 [<10181140>] backtrace_regression_test+0xf8/0x130
 [<10118eac>] do_one_initcall+0x54/0x284
 [<107a1abc>] kernel_init+0x1a8/0x270
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24
 [<ffffffff>] 0xffffffff
====[ end of backtrace testing ]====
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
msgmni has been set to 4034
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
PDC Stable Storage facility v0.30
STI GSC/PCI core graphics driver Version 0.9a
sti 0000:01:04.0: device not available (can't reserve [mem 0xf6000000-0xf7ffffff])
sti 0000:01:04.0: Cannot enable PCI device
sti: probe of 0000:01:04.0 failed with error -22
STI PCI graphic ROM found at f3800000 (2048 kB), fb at f4000000 (32 MB)
    id 35acda30-9a02587, conforms to spec rev. 8.0d
    graphics card name: A1262A
sticon: Initializing STI text console.
Console: switching to colour STI console 128x48
matroxfb 0000:02:00.0: enabling SERR and PARITY (0007 -> 0147)
matroxfb: Matrox G450 detected
PInS memtype = 4
matroxfb: cannot determine memory size
matroxfb: probe of 0000:02:00.0 failed with error -1
stifb: 'A1262A' (id: 0x35acda30) not supported.
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 3) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
serial8250: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
Linux agpgart interface v0.103
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
ns87415 0000:00:0e.0: IDE controller (0x100b:0x0002 rev 0x03)
ns87415 0000:00:0e.0: 100% native mode on irq 7
    ide0: BM-DMA at 0x0a00-0x0a07
    ide1: BM-DMA at 0x0a08-0x0a0f
hda: CD-532E-B, ATAPI CD/DVD-ROM drive
ide0 at 0xf00-0xf07,0xe02 on irq 7
ide1 at 0xd00-0xd07,0xb02 on irq 7
ide-gd driver 1.18
ide-cd driver 5.00
ide-cd: hda: ATAPI 32X CD-ROM drive, 128kB Cache
cdrom: Uniform CD-ROM driver Revision: 3.20
sym0: <896> rev 0x7 at pci 0000:00:0f.0 irq 68
sym0: PA-RISC Firmware, ID 7, Fast-40, SE, parity checking
sym0: SCSI BUS has been reset.
sym0: SCSI BUS mode change from SE to SE.
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.3
sym1: <896> rev 0x7 at pci 0000:00:0f.1 irq 68
sym1: PA-RISC Firmware, ID 7, Fast-40, LVD, parity checking
sym1: SCSI BUS has been reset.
scsi1 : sym-2.2.3
scsi 1:0:5:0: Direct-Access     SEAGATE  ST39102LC        HP01 PQ: 0 ANSI: 2
scsi target1:0:5: tagged command queuing enabled, command queue depth 16.
scsi target1:0:5: Beginning Domain Validation
scsi target1:0:5: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 15)
scsi target1:0:5: Domain Validation skipping write tests
scsi target1:0:5: Ending Domain Validation
scsi 1:0:6:0: Direct-Access     HP 36.4G ST336607LC       HPC3 PQ: 0 ANSI: 3
scsi target1:0:6: tagged command queuing enabled, command queue depth 16.
scsi target1:0:6: Beginning Domain Validation
scsi target1:0:6: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
scsi target1:0:6: Domain Validation skipping write tests
scsi target1:0:6: Ending Domain Validation
st: Version 20101219, fixed bufsize 32768, s/g segs 256
sd 1:0:5:0: Attached scsi generic sg0 type 0
sd 1:0:6:0: Attached scsi generic sg1 type 0
Linux Tulip driver version 1.1.15 (Feb 27, 2007)
tulip0: no phy info, aborting mtable build
tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1
net eth0: Digital DS21142/43 Tulip rev 65 at Port 0x1000, 00:30:6e:48:aa:64, IRQ 65
tulip1: EEPROM default media type Autosense
tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block
tulip1: Index #1 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block
tulip1: Index #2 - Media AUI (#2) described by a 21142 Serial PHY (2) block
tulip1:  MII transceiver #1 config 3100 status 7849 advertising 0101
sd 1:0:5:0: [sda] 17773524 512-byte logical blocks: (9.10 GB/8.47 GiB)
sd 1:0:6:0: [sdb] 71132960 512-byte logical blocks: (36.4 GB/33.9 GiB)
net eth1: Digital DS21142/43 Tulip rev 33 at Port 0x28000, 00:60:b0:7a:12:89, IRQ 71
sd 1:0:6:0: [sdb] Write Protect is off
LASI 82596 driver - Revision: 1.30
sd 1:0:6:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:0e.2: OHCI Host Controller
ohci_hcd 0000:00:0e.2: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:0e.2: irq 1, io mem 0xf2007000
sd 1:0:5:0: [sda] Write Protect is off
sd 1:0:5:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: OHCI Host Controller
usb usb1: Manufacturer: Linux 3.4.0-rc6-32bit+ ohci_hcd
usb usb1: SerialNumber: 0000:00:0e.2
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
uhci_hcd: USB Universal Host Controller Interface driver
mousedev: PS/2 mouse device common for all mice
 sdb: sdb1 sdb2 sdb3 sdb4
rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
 sda: sda1 sda2 sda3 sda4
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid10 personality registered for level 10
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
sd 1:0:6:0: [sdb] Attached SCSI disk
sd 1:0:5:0: [sda] Attached SCSI disk
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using timer interrupt.
TCP: cubic registered
NET: Registered protocol family 17
rtc-generic rtc-generic: setting system clock to 2012-05-12 20:57:11 UTC (1336856231)
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 192.168.178.50, my address is 192.168.178.66
IP-Config: Complete:
     device=eth0, addr=192.168.178.66, mask=255.255.255.0, gw=192.168.178.1
     host=c3000, domain=box, nis-domain=(none)
     bootserver=192.168.178.50, rootserver=192.168.178.50, rootpath=
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sda3): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) readonly on device 8:3.
Freeing unused kernel memory: 328k freed
Backtrace:
 [<1021dc3c>] mpage_readpages+0xf0/0x16c
 [<10257e88>] ext3_readpages+0x28/0x38
 [<101acb90>] __do_page_cache_readahead+0x1e0/0x27c
 [<101acc5c>] ra_submit+0x30/0x40
 [<101acee0>] ondemand_readahead+0xd0/0x26c
ohci_hcd 0000:00:0e.2: new USB bus registered, assigned bus number 1                                                                                                                                                                         
ohci_hcd 0000:00:0e.2: irq 1, io mem 0xf2007000                                                                                                                                                                                              
sd 1:0:5:0: [sda] Write Protect is off                                                                                                                                                                                                       
sd 1:0:5:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA                                                                                                                                                           
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001                                                                                                                                                                                
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1                                                                                                                                                                           
usb usb1: Product: OHCI Host Controller                                                                                                                                                                                                      
usb usb1: Manufacturer: Linux 3.4.0-rc6-32bit+ ohci_hcd                                                                                                                                                                                      
usb usb1: SerialNumber: 0000:00:0e.2                                                                                                                                                                                                         
hub 1-0:1.0: USB hub found                                                                                                                                                                                                                   
hub 1-0:1.0: 3 ports detected                                                                                                                                                                                                                
uhci_hcd: USB Universal Host Controller Interface driver                                                                                                                                                                                     
mousedev: PS/2 mouse device common for all mice                                                                                                                                                                                              
 sdb: sdb1 sdb2 sdb3 sdb4                                                                                                                                                                                                                    
rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0                                                                                                                                                                            
 sda: sda1 sda2 sda3 sda4                                                                                                                                                                                                                    
 [<101acee0>] ondemand_readahead+0xd0/0x26c                                                                                                                                                                                                  
 [<101acee0>] ondemand_readahead+0xd0/0x26c                                                                                                                                                                                                  
 [<101acee0>] ondemand_readahead+0xd0/0x26c                                                                                                                                                                                                  
 [<101ad1a8>] page_cache_sync_readahead+0x44/0x74                                                                                                                                                                                            
 [<101a38e4>] generic_file_aio_read+0x400/0x764                                                                                                                                                                                              
 [<101e243c>] do_sync_read+0xd4/0x130                                                                                                                                                                                                        
 [<101e32f4>] vfs_read+0xac/0x158                                                                                                                                                                                                            
 [<101ea47c>] kernel_read+0x40/0x5c                                                                                                                                                                                                          
 [<101ea58c>] prepare_binprm+0xf4/0x130                                                                                                                                                                                                      
 [<101eae3c>] do_execve+0x2b8/0x3a4                                                                                                                                                                                                          
 [<1012199c>] sys_execve+0x64/0x94                                                                                                                                                                                                           
 [<10104084>] __execve+0x20/0x34                                                                                                                                                                                                             
 [<1019faf8>] perf_output_begin+0x150/0x240                                                                                                                                                                                                  
 [<101a83e8>] __free_pages+0x54/0x64                                                                                                                                                                                                         
                                                                                                                                                                                                                                             
                                                                                                                                                                                                                                             
Kernel Fault: Code=26 regs=8fc30bc0 (Addr=00000034)                                                                                                                                                                                          
                                                                                                                                                                                                                                             
     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI                                                                                                                                                                                                        
PSW: 00000000000001101111111100001111 Not tainted                                                                                                                                                                                            
r00-03  0006ff0f 8fc30c40 1021d928 8fc30b00                                                                                                                                                                                                  
r04-07  00000001 00000001 00000001 8fc30a50                                                                                                                                                                                                  
r08-11  00000001 00000000 00000004 00000001                                                                                                                                                                                                  
r12-15  8f8024c0 0000000c 10925fa0 8f812598                                                                                                                                                                                                  
r16-19  00000013 8fc30b08 00000004 1021d324                                                                                                                                                                                                  
r20-23  8fc30a48 00060370 00000002 8f8124d8                                                                                                                                                                                                  
r24-27  70030600 00000000 00000000 106fa020                                                                                                                                                                                                  
r28-31  10645000 00000000 8fc30bc0 00000002                                                                                                                                                                                                  
sr00-03  00000000 00000000 00000000 00000000                                                                                                                                                                                                 
sr04-07  00000000 00000000 00000000 00000000                                                                                                                                                                                                 
                                                                                                                                                                                                                                             
IASQ: 00000000 00000000 IAOQ: 1021d784 1021d788                                                                                                                                                                                              
 IIR: 69330068    ISR: 00000000  IOR: 00000034                                                                                                                                                                                               
 CPU:        0   CR30: 8fc30000 CR31: d23345e2                                                                                                                                                                                               
 ORIG_R28: 8fdf2000                                                                                                                                                                                                                          
 IAOQ[0]: do_mpage_readpage+0x284/0x5d4                                                                                                                                                                                                      
 IAOQ[1]: do_mpage_readpage+0x288/0x5d4                                                                                                                                                                                                      
 RP(r2): do_mpage_readpage+0x428/0x5d4                                                                                                                                                                                                       
Backtrace:                                                                                                                                                                                                                                   
 [<1021dc3c>] mpage_readpages+0xf0/0x16c                                                                                                                                                                                                     
 [<10257e88>] ext3_readpages+0x28/0x38                                                                                                                                                                                                       
 [<101acb90>] __do_page_cache_readahead+0x1e0/0x27c                                                                                                                                                                                          
 [<101acc5c>] ra_submit+0x30/0x40                                                                                                                                                                                                            
 [<101acee0>] ondemand_readahead+0xd0/0x26c                                                                                                                                                                                                  
 [<101ad1a8>] page_cache_sync_readahead+0x44/0x74                                                                                                                                                                                            
 [<101a38e4>] generic_file_aio_read+0x400/0x764                                                                                                                                                                                              
 [<101e243c>] do_sync_read+0xd4/0x130                                                                                                                                                                                                        
 [<101e32f4>] vfs_read+0xac/0x158                                                                                                                                                                                                            
 [<101ea47c>] kernel_read+0x40/0x5c                                                                                                                                                                                                          
 [<101ea58c>] prepare_binprm+0xf4/0x130                                                                                                                                                                                                      
 [<101eae3c>] do_execve+0x2b8/0x3a4                                                                                                                                                                                                          
 [<1012199c>] sys_execve+0x64/0x94                                                                                                                                                                                                           
 [<10104084>] __execve+0x20/0x34                                                                                                                                                                                                             
 [<1019faf8>] perf_output_begin+0x150/0x240                                                                                                                                                                                                  
 [<101a83e8>] __free_pages+0x54/0x64                                                                                                                                                                                                         
                                                                                                                                                                                                                                             
Kernel panic - not syncing: Kernel Fault   

[-- Attachment #4: pa64.log --]
[-- Type: text/plain, Size: 13811 bytes --]

Command line for kernel: 'HOME=/ root=/dev/sda5 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux'
Selected kernel: /vmlinux from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing 32-bit kernelELF32 executable
Entry 00100000 first 00100000 n 3
Segment 0 load 00100000 size 6647808 mediaptr 0x1000
Segment 1 load 007a0000 size 185472 mediaptr 0x658000
Segment 2 load 007ce000 size 145080 mediaptr 0x686000
Branching to kernel entry point 0x00100000.  If this is the last
message you see, you may need to switch your console.  This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.4.0-rc6-32bit+ (deller@p100) (gcc version 4.3.3 (GCC) ) #7 Sat May 12 22:55:41 CEST 2012
unwind_init: start = 0x106a8000, end = 0x106ebdc0, entries = 17372
WARNING: Out of order unwind entry! 106a95c0 and 106a95d0
WARNING: Out of order unwind entry! 106a95d0 and 106a95e0
WARNING: Out of order unwind entry! 106aa090 and 106aa0a0
WARNING: Out of order unwind entry! 106aa0a0 and 106aa0b0
WARNING: Out of order unwind entry! 106aa110 and 106aa120
WARNING: Out of order unwind entry! 106aa120 and 106aa130
WARNING: Out of order unwind entry! 106aa140 and 106aa150
WARNING: Out of order unwind entry! 106aa150 and 106aa160
WARNING: Out of order unwind entry! 106aa160 and 106aa170
WARNING: Out of order unwind entry! 106aa170 and 106aa180
WARNING: Out of order unwind entry! 106aa180 and 106aa190
WARNING: Out of order unwind entry! 106aa190 and 106aa1a0
WARNING: Out of order unwind entry! 106aa1a0 and 106aa1b0
WARNING: Out of order unwind entry! 106aa1b0 and 106aa1c0
WARNING: Out of order unwind entry! 106aa1c0 and 106aa1d0
WARNING: Out of order unwind entry! 106aa1d0 and 106aa1e0
WARNING: Out of order unwind entry! 106aa1e0 and 106aa1f0
WARNING: Out of order unwind entry! 106aa1f0 and 106aa200
WARNING: Out of order unwind entry! 106aa210 and 106aa220
WARNING: Out of order unwind entry! 106aa220 and 106aa230
FP[0] enabled: Rev 1 Model 13
The 32-bit Kernel has started...
bootconsole [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: Snake.
model 000060a0 00000481 00000000 00000000 773c7d2c 00000000 00000004 00000072 00000072
vers  0000000c
model 9000/715
Total Memory: 160 MB
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 40640
Kernel command line: HOME=/ root=/dev/sda5 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
allocated 327680 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Memory: 154668k/163840k available (4505k kernel code, 9172k reserved, 1964k data, 328k init)
virtual kernel memory layout:
    vmalloc : 0x00810000 - 0x0f000000   ( 231 MB)
    memory  : 0x10000000 - 0x1a000000   ( 160 MB)
      .init : 0x107a0000 - 0x107f2000   ( 328 kB)
      .data : 0x10566690 - 0x107517b0   (1964 kB)
      .text : 0x10100000 - 0x10566690   (4505 kB)
NR_IRQS:96
Console: colour dummy device 128x48
Calibrating delay loop... 63.07 BogoMIPS (lpj=315392)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys blkio
xor: measuring software checksum speed
   8regs     :    44.800 MB/sec
   8regs_prefetch:    44.400 MB/sec
   32regs    :    72.000 MB/sec
   32regs_prefetch:    71.600 MB/sec
xor: using function: 32regs (72.000 MB/sec)
atomic64 test passed
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Found devices:
1. Mirage Jr GSC Builtin Graphics at 0xf8000000 [1] { 10, 0x0, 0x012, 0x00085 }
2. Mirage Jr Core BA at 0xf0100000 [2] { 11, 0x0, 0x028, 0x00081 }
3. Mirage Jr Core SCSI at 0xf0106000 [2/0/1] { 10, 0x0, 0x028, 0x00082 }
4. Mirage Jr Core LAN (802.3) at 0xf0107000 [2/0/2] { 10, 0x0, 0x028, 0x0008a }
5. Mirage Jr Core RS-232 at 0xf0105000 [2/0/4] { 10, 0x0, 0x028, 0x0008c }
6. Mirage Jr Core Centronics at 0xf0102000 [2/0/6] { 10, 0x0, 0x028, 0x00074 }
7. Mirage Jr Audio at 0xf0104000 [2/0/8] { 10, 0x0, 0x028, 0x0007b }
8. Mirage Jr Core PC Floppy at 0xf010a000 [2/0/10] { 10, 0x0, 0x028, 0x00083 }
9. Mirage Jr Core PS/2 Port at 0xf0108000 [2/0/11] { 10, 0x0, 0x028, 0x00084 }
10. Mirage Jr Core PS/2 Port at 0xf0108100 [2/0/12] { 10, 0x0, 0x028, 0x00084 }
11. Mirage Jr Wax EISA BA at 0xfc000000 [4] { 11, 0x0, 0x028, 0x00090 }
12. Mirage Jr Wax BA at 0xf0200000 [5] { 11, 0x0, 0x012, 0x0008e }
13. Mirage Jr Wax HIL at 0xf0201000 [5/0/1] { 10, 0x0, 0x012, 0x00073 }
14. Mirage Jr Wax RS-232 at 0xf0202000 [5/0/2] { 10, 0x0, 0x012, 0x0008c }
15. Mirage Jr (715/64) at 0xfffbe000 [8] { 0, 0x0, 0x60a, 0x00004 }
16. Memory at 0xfffbf000 [9] { 1, 0x0, 0x04a, 0x00009 }
CPU(s): 1 x PA7100LC (PCX-L) at 64.000000 MHz
Setting cache flush threshold to 3e0 (1 CPUs online)
Lasi version 0 at 0xf0100000 found.
LED display at f00e0000 registered
wax at 0xf0200000 found.
Wax EISA Adapter found at 0xfc000000
Enumerating EISA bus
EISA: Probing bus 0 at 4
EISA: Mainboard HWPC000 detected.
EISA: Detected 0 cards.
powersw: Gecko-style soft power switch enabled.
bio: create slab <bio-0> at 0
raid6: int32x1     28 MB/s
raid6: int32x2     31 MB/s
raid6: int32x4     37 MB/s
raid6: int32x8     17 MB/s
raid6: using algorithm int32x4 (37 MB/s)
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource cr16
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 128 (order: 0, 6144 bytes)
UDP-Lite hash table entries: 128 (order: 0, 6144 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Chassis warnings not supported.
Initializing RT-Tester: OK
====[ backtrace testing ]===========
Testing a backtrace from process context.
The following trace is a kernel self test and not a bug!
Backtrace:
 [<1011b070>] show_stack+0x18/0x28
 [<101148f8>] dump_stack+0x1c/0x2c
 [<10181098>] backtrace_regression_test+0x50/0x130
 [<10118eac>] do_one_initcall+0x54/0x284
 [<107a1abc>] kernel_init+0x1a8/0x270
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a backtrace from irq context.
The following trace is a kernel self test and not a bug!
Backtrace:
 [<1011b070>] show_stack+0x18/0x28
 [<101148f8>] dump_stack+0x1c/0x2c
 [<10181028>] backtrace_test_irq_callback+0x18/0x38
 [<1013b96c>] tasklet_action+0x80/0xe4
 [<1018ffc0>] rcu_process_callbacks+0x30/0x40
 [<1013c2e0>] __do_softirq+0x148/0x198
 [<1013c39c>] run_ksoftirqd+0x6c/0x120
 [<101174bc>] schedule+0x30/0x74
 [<101546f4>] kthread+0xac/0xb4
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a saved backtrace.
The following trace is a kernel self test and not a bug!
 [<ffffffff>] 0xffffffff
====[ end of backtrace testing ]====
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
msgmni has been set to 302
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
EISA EEPROM at 0x00810400
PDC Stable Storage facility v0.30
STI GSC/PCI core graphics driver Version 0.9a
    id 2b4ded6d-40a00499, conforms to spec rev. 8.04
    graphics card name: HPA208LC1024
sticon: Initializing STI text console.
Console: switching to colour STI console 128x48
Console: switching to colour frame buffer device 128x48
fb0: stifb 1024x768-8 frame buffer device, HPA208LC1024, id: 2b4ded6d, mmio: 0xf8100000
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
2:0:4: ttyS0 at MMIO 0xf0105800 (irq = 18) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
5:0:2: ttyS1 at MMIO 0xf0202800 (irq = 25) is a 16550A
Linux agpgart interface v0.103
parport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xf0102800, irq 19 [PCSPP,TRISTATE]
parport0: fix this legacy no-device port driver!
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
ide-cd driver 5.00
53c700: Version 2.8 By James.Bottomley@HansenPartnership.com
scsi0: 53c710 rev 2 
scsi0 : LASI SCSI 53c700
scsi 0:0:6:0: Direct-Access     QUANTUM  FIREBALL_TM3200S 300X PQ: 0 ANSI: 2
scsi target0:0:6: Beginning Domain Validation
scsi 0:0:6:0: Enabling Tag Command Queuing
scsi target0:0:6: asynchronous
scsi target0:0:6: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 8)
scsi target0:0:6: Domain Validation skipping write tests
scsi target0:0:6: Ending Domain Validation
st: Version 20101219, fixed bufsize 32768, s/g segs 256
sd 0:0:6:0: Attached scsi generic sg0 type 0
sd 0:0:6:0: [sda] 6281856 512-byte logical blocks: (3.21 GB/2.99 GiB)
LASI 82596 driver - Revision: 1.30
Found i82596 at 0xf0107000, IRQ 17
eth0: 82596 at 0xf0107000, 08:00:09:c2:9e:60 IRQ 17.
sd 0:0:6:0: [sda] Write Protect is off
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
sd 0:0:6:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
serio: gsc-ps2-keyboard port at 0x0081a000 irq 22 @ 2:0:11
serio: gsc-ps2-mouse port at 0x0081c100 irq 22 @ 2:0:12
mousedev: PS/2 mouse device common for all mice
rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid10 personality registered for level 10
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using timer interrupt.
TCP: cubic registered
NET: Registered protocol family 17
rtc-generic rtc-generic: setting system clock to 1970-01-04 11:04:35 UTC (299075)
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 192.168.178.50, my address is 192.168.178.64
IP-Config: Complete:
     device=eth0, addr=192.168.178.64, mask=255.255.255.0, gw=192.168.178.1
     host=pa64, domain=box, nis-domain=(none)
     bootserver=192.168.178.50, rootserver=192.168.178.50, rootpath=
 sda: sda1 sda2 sda3 < sda5 sda6 >
sd 0:0:6:0: [sda] Attached SCSI disk
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sda5): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) readonly on device 8:5.
Freeing unused kernel memory: 328k freed
Backtrace:
 [<1021dc3c>] mpage_readpages+0xf0/0x16c
 [<10257e88>] ext3_readpages+0x28/0x38
 [<101acb90>] __do_page_cache_readahead+0x1e0/0x27c
 [<101acc5c>] ra_submit+0x30/0x40
 [<101acee0>] ondemand_readahead+0xd0/0x26c
 [<101ad1a8>] page_cache_sync_readahead+0x44/0x74
 [<101a38e4>] generic_file_aio_read+0x400/0x764
 [<101e243c>] do_sync_read+0xd4/0x130
 [<101e32f4>] vfs_read+0xac/0x158
 [<101ea47c>] kernel_read+0x40/0x5c
 [<101ea58c>] prepare_binprm+0xf4/0x130
 [<101eae3c>] do_execve+0x2b8/0x3a4
 [<1012199c>] sys_execve+0x64/0x94
 [<10104084>] __execve+0x20/0x34
 [<10136374>] vprintk+0x1e8/0x488
 [<101a83e8>] __free_pages+0x54/0x64


Kernel Fault: Code=26 regs=19c24bc0 (Addr=00000034)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001101111111100001111 Not tainted
r00-03  0006ff0f 19c24c40 1021d928 19c24b00
r04-07  00000001 00000001 00000001 19c24a50
r08-11  00000001 00000000 00000004 00000001
r12-15  19802280 0000000c 10803980 19811598
r16-19  00000013 19c24b08 00000004 1021d324
r20-23  19c24a48 00068345 00000004 198114d8
r24-27  45830600 00000000 00000000 106fa020
r28-31  10645000 00000000 19c24bc0 00000004
sr00-03  00000000 00000000 00000000 00000000
sr04-07  00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 1021d784 1021d788
 IIR: 69330068    ISR: 00000000  IOR: 00000034
 CPU:        0   CR30: 19c24000 CR31: f00effff
 ORIG_R28: 19e71c00
 IAOQ[0]: do_mpage_readpage+0x284/0x5d4
 IAOQ[1]: do_mpage_readpage+0x288/0x5d4
 RP(r2): do_mpage_readpage+0x428/0x5d4
Backtrace:
 [<1021dc3c>] mpage_readpages+0xf0/0x16c
 [<10257e88>] ext3_readpages+0x28/0x38
 [<101acb90>] __do_page_cache_readahead+0x1e0/0x27c
 [<101acc5c>] ra_submit+0x30/0x40
 [<101acee0>] ondemand_readahead+0xd0/0x26c
 [<101ad1a8>] page_cache_sync_readahead+0x44/0x74
 [<101a38e4>] generic_file_aio_read+0x400/0x764
 [<101e243c>] do_sync_read+0xd4/0x130
 [<101e32f4>] vfs_read+0xac/0x158
 [<101ea47c>] kernel_read+0x40/0x5c
 [<101ea58c>] prepare_binprm+0xf4/0x130
 [<101eae3c>] do_execve+0x2b8/0x3a4
 [<1012199c>] sys_execve+0x64/0x94
 [<10104084>] __execve+0x20/0x34
 [<10136374>] vprintk+0x1e8/0x488
 [<101a83e8>] __free_pages+0x54/0x64

Kernel panic - not syncing: Kernel Fault


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-12 22:50         ` Helge Deller
@ 2012-05-13 14:11           ` John David Anglin
  2012-05-14  1:10           ` John David Anglin
  1 sibling, 0 replies; 56+ messages in thread
From: John David Anglin @ 2012-05-13 14:11 UTC (permalink / raw)
  To: Helge Deller; +Cc: Vincent, Rolf Eike Beer, linux-parisc

On 12-May-12, at 6:50 PM, Helge Deller wrote:

> I have my machines now up and running again.

Good.

>
> I tested upstream version (bcc62fb) and got on all my machines the  
> same bug (same Kernel binary started on all):
>
> Backtrace:
> [<1021dc3c>] mpage_readpages+0xf0/0x16c
> [<10257e88>] ext3_readpages+0x28/0x38
> [<101acb90>] __do_page_cache_readahead+0x1e0/0x27c
> [<101acc5c>] ra_submit+0x30/0x40
> [<101acee0>] ondemand_readahead+0xd0/0x26c
>
> or
>
> Backtrace:
> [<1021dc3c>] mpage_readpages+0xf0/0x16c
> [<10257e88>] ext3_readpages+0x28/0x38
> [<101acb90>] __do_page_cache_readahead+0x1e0/0x27c
> [<101acc5c>] ra_submit+0x30/0x40
> [<101acee0>] ondemand_readahead+0xd0/0x26c
> [<101ad1a8>] page_cache_sync_readahead+0x44/0x74
> [<101a38e4>] generic_file_aio_read+0x400/0x764
> [<101e243c>] do_sync_read+0xd4/0x130
> [<101e32f4>] vfs_read+0xac/0x158
> [<101ea47c>] kernel_read+0x40/0x5c
> [<101ea58c>] prepare_binprm+0xf4/0x130
> [<101eae3c>] do_execve+0x2b8/0x3a4
> [<1012199c>] sys_execve+0x64/0x94
> [<10104084>] __execve+0x20/0x34
> [<10136374>] vprintk+0x1e8/0x488
> [<101a83e8>] __free_pages+0x54/0x64

I haven't tried 3.4.  These seem to be new issues.  I will try 3.4  
soon, but
could you try stable 3.3.6?  Stable 3.3 up to 3.3.4 is known to work on
various machines.

>
>
> all logs attached for the 715/64, B160L and C3000 machines.
>
> I'll test tomorrow your patch (but will try to update my binutils/ 
> gcc prior to that).


There are known issues with GCC 4.3 branch.  In particular, the  
delayed branch support
is broken (at least three different bugs).  I would suggest you  
install 4.6.3 from shirka
or magnum.

Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-10  6:41         ` Rolf Eike Beer
  2012-05-10 16:32           ` John David Anglin
@ 2012-05-13 14:32           ` Jeroen Roovers
  2012-05-14  0:52             ` John David Anglin
  1 sibling, 1 reply; 56+ messages in thread
From: Jeroen Roovers @ 2012-05-13 14:32 UTC (permalink / raw)
  To: linux-parisc; +Cc: Rolf Eike Beer, John David Anglin, Vincent

On Thu, 10 May 2012 08:41:50 +0200
Rolf Eike Beer <eike-kernel@sf-tec.de> wrote:

> I think Guy Martin has the cache patch running on at least one of his 
> machines.

I have the patched code running on a C3650 (kernel 3.2.12) and a C8000
(kernel 3.3.5). Looks stable so far, after a few days of heavy use. I
can't say it's actually running faster on either system because I
simply didn't test for that change.


     jer

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-13 14:32           ` Jeroen Roovers
@ 2012-05-14  0:52             ` John David Anglin
  0 siblings, 0 replies; 56+ messages in thread
From: John David Anglin @ 2012-05-14  0:52 UTC (permalink / raw)
  To: Jeroen Roovers; +Cc: linux-parisc, Rolf Eike Beer, Vincent

On 13-May-12, at 10:32 AM, Jeroen Roovers wrote:

> I
> can't say it's actually running faster on either system because I
> simply didn't test for that change.

You will only see a significant performance improvement on PA8800/PA8900
machines with the 32 MB cache.

I believe other machines will see an improvement in thread support.   
However,
there is still more to fix in this area.

Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-12 22:50         ` Helge Deller
  2012-05-13 14:11           ` John David Anglin
@ 2012-05-14  1:10           ` John David Anglin
  2012-05-14 22:11             ` Helge Deller
  1 sibling, 1 reply; 56+ messages in thread
From: John David Anglin @ 2012-05-14  1:10 UTC (permalink / raw)
  To: Helge Deller; +Cc: Vincent, Rolf Eike Beer, linux-parisc

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

Hi Helge,

I had a successful bot of 3.4.0-rc7+ this evening.

I updated my running kernel patch to 3.4.  The futex patch is removed  
and Srivatsa S. Bhat's
patch added.

Attached are patch and dmesg log.

Regards,
Dave

On 12-May-12, at 6:50 PM, Helge Deller wrote:

> I have my machines now up and running again.
>
> I tested upstream version (bcc62fb) and got on all my machines the  
> same bug (same Kernel binary started on all):
>
> Backtrace:
> [<1021dc3c>] mpage_readpages+0xf0/0x16c
> [<10257e88>] ext3_readpages+0x28/0x38
> [<101acb90>] __do_page_cache_readahead+0x1e0/0x27c
> [<101acc5c>] ra_submit+0x30/0x40
> [<101acee0>] ondemand_readahead+0xd0/0x26c
>
> or
>
> Backtrace:
> [<1021dc3c>] mpage_readpages+0xf0/0x16c
> [<10257e88>] ext3_readpages+0x28/0x38
> [<101acb90>] __do_page_cache_readahead+0x1e0/0x27c
> [<101acc5c>] ra_submit+0x30/0x40
> [<101acee0>] ondemand_readahead+0xd0/0x26c
> [<101ad1a8>] page_cache_sync_readahead+0x44/0x74
> [<101a38e4>] generic_file_aio_read+0x400/0x764
> [<101e243c>] do_sync_read+0xd4/0x130
> [<101e32f4>] vfs_read+0xac/0x158
> [<101ea47c>] kernel_read+0x40/0x5c
> [<101ea58c>] prepare_binprm+0xf4/0x130
> [<101eae3c>] do_execve+0x2b8/0x3a4
> [<1012199c>] sys_execve+0x64/0x94
> [<10104084>] __execve+0x20/0x34
> [<10136374>] vprintk+0x1e8/0x488
> [<101a83e8>] __free_pages+0x54/0x64
>
>
> all logs attached for the 715/64, B160L and C3000 machines.
>
> I'll test tomorrow your patch (but will try to update my binutils/ 
> gcc prior to that).



--
John David Anglin	dave.anglin@bell.net



[-- Attachment #2: linux-3.4-rc7-20120513.d.4 --]
[-- Type: application/octet-stream, Size: 37081 bytes --]

diff --git a/arch/parisc/hpux/wrappers.S b/arch/parisc/hpux/wrappers.S
index 58c53c8..bdcea33 100644
--- a/arch/parisc/hpux/wrappers.S
+++ b/arch/parisc/hpux/wrappers.S
@@ -88,7 +88,7 @@ ENTRY(hpux_fork_wrapper)
 
 	STREG	%r2,-20(%r30)
 	ldo	64(%r30),%r30
-	STREG	%r2,PT_GR19(%r1)	;! save for child
+	STREG	%r2,PT_SYSCALL_RP(%r1)	;! save for child
 	STREG	%r30,PT_GR21(%r1)	;! save for child
 
 	LDREG	PT_GR30(%r1),%r25
@@ -132,7 +132,7 @@ ENTRY(hpux_child_return)
 	bl,n	schedule_tail, %r2
 #endif
 
-	LDREG	TASK_PT_GR19-TASK_SZ_ALGN-128(%r30),%r2
+	LDREG	TASK_PT_SYSCALL_RP-TASK_SZ_ALGN-128(%r30),%r2
 	b fork_return
 	copy %r0,%r28
 ENDPROC(hpux_child_return)
diff --git a/arch/parisc/include/asm/cacheflush.h b/arch/parisc/include/asm/cacheflush.h
index 9f21ab0..79f694f 100644
--- a/arch/parisc/include/asm/cacheflush.h
+++ b/arch/parisc/include/asm/cacheflush.h
@@ -115,7 +115,9 @@ flush_anon_page(struct vm_area_struct *vma, struct page *page, unsigned long vma
 {
 	if (PageAnon(page)) {
 		flush_tlb_page(vma, vmaddr);
+		preempt_disable();
 		flush_dcache_page_asm(page_to_phys(page), vmaddr);
+		preempt_enable();
 	}
 }
 
diff --git a/arch/parisc/include/asm/mmzone.h b/arch/parisc/include/asm/mmzone.h
index e67eb9c..31835b9 100644
--- a/arch/parisc/include/asm/mmzone.h
+++ b/arch/parisc/include/asm/mmzone.h
@@ -1,9 +1,10 @@
 #ifndef _PARISC_MMZONE_H
 #define _PARISC_MMZONE_H
 
+#define MAX_PHYSMEM_RANGES 8 /* Fix the size for now (current known max is 3) */
+
 #ifdef CONFIG_DISCONTIGMEM
 
-#define MAX_PHYSMEM_RANGES 8 /* Fix the size for now (current known max is 3) */
 extern int npmem_ranges;
 
 struct node_map_data {
@@ -60,7 +61,5 @@ static inline int pfn_valid(int pfn)
 	return 0;
 }
 
-#else /* !CONFIG_DISCONTIGMEM */
-#define MAX_PHYSMEM_RANGES 	1 
 #endif
 #endif /* _PARISC_MMZONE_H */
diff --git a/arch/parisc/include/asm/page.h b/arch/parisc/include/asm/page.h
index 4e0e7db..d9812d8 100644
--- a/arch/parisc/include/asm/page.h
+++ b/arch/parisc/include/asm/page.h
@@ -21,15 +21,27 @@
 #include <asm/types.h>
 #include <asm/cache.h>
 
-#define clear_page(page)	memset((void *)(page), 0, PAGE_SIZE)
-#define copy_page(to,from)      copy_user_page_asm((void *)(to), (void *)(from))
+#define clear_page(page)	clear_page_asm((void *)(page))
+#define copy_page(to,from)	copy_page_asm((void *)(to), (void *)(from))
 
 struct page;
 
-void copy_user_page_asm(void *to, void *from);
+void clear_page_asm(void *page);
+void copy_page_asm(void *to, void *from);
+void clear_user_page(void *vto, unsigned long vaddr, struct page *pg);
 void copy_user_page(void *vto, void *vfrom, unsigned long vaddr,
 			   struct page *pg);
-void clear_user_page(void *page, unsigned long vaddr, struct page *pg);
+
+// #define CONFIG_PARISC_TMPALIAS
+
+#ifdef CONFIG_PARISC_TMPALIAS
+void clear_user_highpage(struct page *page, unsigned long vaddr);
+#define clear_user_highpage clear_user_highpage
+struct vm_area_struct;
+void copy_user_highpage(struct page *to, struct page *from,
+	unsigned long vaddr, struct vm_area_struct *vma);
+#define __HAVE_ARCH_COPY_USER_HIGHPAGE
+#endif
 
 /*
  * These are used to make use of C type-checking..
diff --git a/arch/parisc/include/asm/pgtable.h b/arch/parisc/include/asm/pgtable.h
index ee99f23..563724d 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -12,11 +12,10 @@
 
 #include <linux/bitops.h>
 #include <linux/spinlock.h>
+#include <linux/mm_types.h>
 #include <asm/processor.h>
 #include <asm/cache.h>
 
-struct vm_area_struct;
-
 /*
  * kern_addr_valid(ADDR) tests if ADDR is pointing to valid kernel
  * memory.  For the return value to be meaningful, ADDR must be >=
@@ -40,7 +39,14 @@ struct vm_area_struct;
         do{                                                     \
                 *(pteptr) = (pteval);                           \
         } while(0)
-#define set_pte_at(mm,addr,ptep,pteval) set_pte(ptep,pteval)
+
+extern void purge_tlb_entries(struct mm_struct *, unsigned long);
+
+#define set_pte_at(mm,addr,ptep, pteval)                        \
+        do{                                                     \
+                set_pte(ptep,pteval);                           \
+                purge_tlb_entries(mm,addr);                     \
+        } while(0)
 
 #endif /* !__ASSEMBLY__ */
 
@@ -462,10 +468,13 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr,
 #ifdef CONFIG_SMP
 	unsigned long new, old;
 
+	/* ??? This might be racy because the page table updates in
+	   entry.S don't use the same lock.  */
 	do {
 		old = pte_val(*ptep);
 		new = pte_val(pte_wrprotect(__pte (old)));
 	} while (cmpxchg((unsigned long *) ptep, old, new) != old);
+	purge_tlb_entries(mm, addr);
 #else
 	pte_t old_pte = *ptep;
 	set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
diff --git a/arch/parisc/kernel/asm-offsets.c b/arch/parisc/kernel/asm-offsets.c
index dcd5510..5df1597 100644
--- a/arch/parisc/kernel/asm-offsets.c
+++ b/arch/parisc/kernel/asm-offsets.c
@@ -141,6 +141,7 @@ int main(void)
 	DEFINE(TASK_PT_IAOQ0, offsetof(struct task_struct, thread.regs.iaoq[0]));
 	DEFINE(TASK_PT_IAOQ1, offsetof(struct task_struct, thread.regs.iaoq[1]));
 	DEFINE(TASK_PT_CR27, offsetof(struct task_struct, thread.regs.cr27));
+	DEFINE(TASK_PT_SYSCALL_RP, offsetof(struct task_struct, thread.regs.pad0));
 	DEFINE(TASK_PT_ORIG_R28, offsetof(struct task_struct, thread.regs.orig_r28));
 	DEFINE(TASK_PT_KSP, offsetof(struct task_struct, thread.regs.ksp));
 	DEFINE(TASK_PT_KPC, offsetof(struct task_struct, thread.regs.kpc));
@@ -230,6 +231,7 @@ int main(void)
 	DEFINE(PT_IAOQ0, offsetof(struct pt_regs, iaoq[0]));
 	DEFINE(PT_IAOQ1, offsetof(struct pt_regs, iaoq[1]));
 	DEFINE(PT_CR27, offsetof(struct pt_regs, cr27));
+	DEFINE(PT_SYSCALL_RP, offsetof(struct pt_regs, pad0));
 	DEFINE(PT_ORIG_R28, offsetof(struct pt_regs, orig_r28));
 	DEFINE(PT_KSP, offsetof(struct pt_regs, ksp));
 	DEFINE(PT_KPC, offsetof(struct pt_regs, kpc));
diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index 9d18189..695f790 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -133,7 +133,7 @@ parisc_cache_init(void)
 	if (pdc_cache_info(&cache_info) < 0)
 		panic("parisc_cache_init: pdc_cache_info failed");
 
-#if 0
+#if 1
 	printk("ic_size %lx dc_size %lx it_size %lx\n",
 		cache_info.ic_size,
 		cache_info.dc_size,
@@ -267,9 +267,11 @@ static inline void
 __flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr,
 		   unsigned long physaddr)
 {
+	preempt_disable();
 	flush_dcache_page_asm(physaddr, vmaddr);
 	if (vma->vm_flags & VM_EXEC)
 		flush_icache_page_asm(physaddr, vmaddr);
+	preempt_enable();
 }
 
 void flush_dcache_page(struct page *page)
@@ -315,7 +317,7 @@ void flush_dcache_page(struct page *page)
 		flush_tlb_page(mpnt, addr);
 		if (old_addr == 0 || (old_addr & (SHMLBA - 1)) != (addr & (SHMLBA - 1))) {
 			__flush_cache_page(mpnt, addr, page_to_phys(page));
-			if (old_addr)
+			if (old_addr && parisc_requires_coherency())
 				printk(KERN_ERR "INEQUIVALENT ALIASES 0x%lx and 0x%lx in file %s\n", old_addr, addr, mpnt->vm_file ? (char *)mpnt->vm_file->f_path.dentry->d_name.name : "(null)");
 			old_addr = addr;
 		}
@@ -330,17 +332,6 @@ EXPORT_SYMBOL(flush_kernel_dcache_page_asm);
 EXPORT_SYMBOL(flush_data_cache_local);
 EXPORT_SYMBOL(flush_kernel_icache_range_asm);
 
-void clear_user_page_asm(void *page, unsigned long vaddr)
-{
-	unsigned long flags;
-	/* This function is implemented in assembly in pacache.S */
-	extern void __clear_user_page_asm(void *page, unsigned long vaddr);
-
-	purge_tlb_start(flags);
-	__clear_user_page_asm(page, vaddr);
-	purge_tlb_end(flags);
-}
-
 #define FLUSH_THRESHOLD 0x80000 /* 0.5MB */
 int parisc_cache_flush_threshold __read_mostly = FLUSH_THRESHOLD;
 
@@ -374,20 +365,9 @@ void __init parisc_setup_cache_timing(void)
 	printk(KERN_INFO "Setting cache flush threshold to %x (%d CPUs online)\n", parisc_cache_flush_threshold, num_online_cpus());
 }
 
-extern void purge_kernel_dcache_page(unsigned long);
-extern void clear_user_page_asm(void *page, unsigned long vaddr);
-
-void clear_user_page(void *page, unsigned long vaddr, struct page *pg)
-{
-	unsigned long flags;
-
-	purge_kernel_dcache_page((unsigned long)page);
-	purge_tlb_start(flags);
-	pdtlb_kernel(page);
-	purge_tlb_end(flags);
-	clear_user_page_asm(page, vaddr);
-}
-EXPORT_SYMBOL(clear_user_page);
+extern void purge_kernel_dcache_page_asm(unsigned long);
+extern void clear_user_page_asm(void *, unsigned long);
+extern void copy_user_page_asm(void *, void *, unsigned long);
 
 void flush_kernel_dcache_page_addr(void *addr)
 {
@@ -400,11 +380,26 @@ void flush_kernel_dcache_page_addr(void *addr)
 }
 EXPORT_SYMBOL(flush_kernel_dcache_page_addr);
 
+void clear_user_page(void *vto, unsigned long vaddr, struct page *page)
+{
+	clear_page_asm(vto);
+	if (!parisc_requires_coherency())
+		flush_kernel_dcache_page_asm(vto);
+}
+EXPORT_SYMBOL(clear_user_page);
+
 void copy_user_page(void *vto, void *vfrom, unsigned long vaddr,
-		    struct page *pg)
+	struct page *pg)
 {
-	/* no coherency needed (all in kmap/kunmap) */
-	copy_user_page_asm(vto, vfrom);
+	/* Copy using kernel mapping.  No coherency is needed
+	   (all in kmap/kunmap) on machines that don't support
+	   non-equivalent aliasing.  However, the `from' page
+	   needs to be flushed before it can be accessed through
+	   the kernel mapping. */
+	preempt_disable();
+	flush_dcache_page_asm(__pa(vfrom), vaddr);
+	preempt_enable();
+	copy_page_asm(vto, vfrom);
 	if (!parisc_requires_coherency())
 		flush_kernel_dcache_page_asm(vto);
 }
@@ -459,8 +454,65 @@ void flush_cache_all(void)
 	on_each_cpu(cacheflush_h_tmp_function, NULL, 1);
 }
 
+static inline unsigned long mm_total_size(struct mm_struct *mm)
+{
+	struct vm_area_struct *vma;
+	unsigned long usize = 0;
+
+	for (vma = mm->mmap; vma; vma = vma->vm_next)
+		usize += vma->vm_end - vma->vm_start;
+	return usize;
+}
+
+static inline pte_t *get_ptep(pgd_t *pgd, unsigned long addr)
+{
+	pte_t *ptep = NULL;
+
+        if (!pgd_none(*pgd)) {
+                pud_t *pud = pud_offset(pgd, addr);
+                if (!pud_none(*pud)) {
+                        pmd_t *pmd = pmd_offset(pud, addr);
+                        if (!pmd_none(*pmd)) {
+                                ptep = pte_offset_map(pmd, addr);
+                        }
+                }
+        }
+	return ptep;
+}
+
 void flush_cache_mm(struct mm_struct *mm)
 {
+	/* Flushing the whole cache on each cpu takes forever on
+	   rp3440, etc.  So, avoid it if the mm isn't too big.
+	   Note: This approach is faster than a range flush when the
+	   context is current, and it works even when non current.  */
+	if (mm_total_size(mm) < parisc_cache_flush_threshold) {
+		struct vm_area_struct *vma;
+
+		if (mm->context == mfsp(3)) {
+			for (vma = mm->mmap; vma; vma = vma->vm_next) {
+				flush_user_dcache_range_asm(vma->vm_start, vma->vm_end);
+				if(vma->vm_flags & VM_EXEC)
+					flush_user_icache_range_asm(vma->vm_start, vma->vm_end);
+			}
+		} else {
+			pgd_t *pgd = mm->pgd;
+
+			for (vma = mm->mmap; vma; vma = vma->vm_next) {
+				unsigned long addr;
+
+				for (addr = vma->vm_start; addr < vma->vm_end; addr += PAGE_SIZE) {
+					pte_t *ptep = get_ptep(pgd, addr);
+					if (ptep != NULL) {
+						pte_t pte = *ptep;
+						__flush_cache_page(vma, addr, page_to_phys(pte_page(pte)));
+					}
+				}
+			}
+		}
+		return;
+	}
+
 #ifdef CONFIG_SMP
 	flush_cache_all();
 #else
@@ -486,20 +538,34 @@ flush_user_icache_range(unsigned long start, unsigned long end)
 		flush_instruction_cache();
 }
 
-
 void flush_cache_range(struct vm_area_struct *vma,
 		unsigned long start, unsigned long end)
 {
-	int sr3;
-
 	BUG_ON(!vma->vm_mm->context);
 
-	sr3 = mfsp(3);
-	if (vma->vm_mm->context == sr3) {
-		flush_user_dcache_range(start,end);
-		flush_user_icache_range(start,end);
+	if ((end - start) < parisc_cache_flush_threshold) {
+		if (vma->vm_mm->context == mfsp(3)) {
+			flush_user_dcache_range_asm(start,end);
+			if(vma->vm_flags & VM_EXEC)
+				flush_user_icache_range_asm(start,end);
+		} else {
+			unsigned long addr;
+			pgd_t *pgd = vma->vm_mm->pgd;
+
+			for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
+				pte_t *ptep = get_ptep(pgd, addr);
+				if (ptep != NULL) {
+					pte_t pte = *ptep;
+					flush_cache_page(vma, addr, pte_pfn(pte));
+				}
+			}
+		}
 	} else {
+#ifdef CONFIG_SMP
 		flush_cache_all();
+#else
+		flush_cache_all_local();
+#endif
 	}
 }
 
@@ -512,3 +578,81 @@ flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr, unsigned long
 	__flush_cache_page(vma, vmaddr, page_to_phys(pfn_to_page(pfn)));
 
 }
+
+void purge_tlb_entries(struct mm_struct *mm, unsigned long addr)
+{
+	unsigned long flags;
+
+	/* Note: purge_tlb_entries can be called at startup with
+	   no context.  */
+
+	mtsp(mm->context,1);
+	purge_tlb_start(flags);
+	pdtlb(addr);
+	pitlb(addr);
+	purge_tlb_end(flags);
+}
+
+#ifdef CONFIG_PARISC_TMPALIAS
+
+void clear_user_highpage(struct page *page, unsigned long vaddr)
+{
+	void *vto;
+	unsigned long flags;
+
+	/* Clear using TMPALIAS region.  The page doesn't need to
+	   be flushed but the kernel mapping needs to be purged.  */
+
+	vto = kmap_atomic(page, KM_USER0);
+
+	/* The PA-RISC 2.0 Architecture book states on page F-6:
+	   "Before a write-capable translation is enabled, *all*
+	   non-equivalently-aliased translations must be removed
+	   from the page table and purged from the TLB.  (Note
+	   that the caches are not required to be flushed at this
+	   time.)  Before any non-equivalent aliased translation
+	   is re-enabled, the virtual address range for the writeable
+	   page (the entire page) must be flushed from the cache,
+	   and the write-capable translation removed from the page
+	   table and purged from the TLB."  */
+
+	purge_kernel_dcache_page_asm((unsigned long)vto);
+	purge_tlb_start(flags);
+	pdtlb_kernel(vto);
+	purge_tlb_end(flags);
+	preempt_disable();
+	clear_user_page_asm(vto, vaddr);
+	preempt_enable();
+
+	pagefault_enable();		/* kunmap_atomic(addr, KM_USER0); */
+}
+
+void copy_user_highpage(struct page *to, struct page *from,
+	unsigned long vaddr, struct vm_area_struct *vma)
+{
+	void *vfrom, *vto;
+	unsigned long flags;
+
+	/* Copy using TMPALIAS region.  This has the advantage
+	   that the `from' page doesn't need to be flushed.  However,
+	   the `to' page must be flushed in copy_user_page_asm since
+	   it can be used to bring in executable code.  */
+
+	vfrom = kmap_atomic(from, KM_USER0);
+	vto = kmap_atomic(to, KM_USER1);
+
+	purge_kernel_dcache_page_asm((unsigned long)vto);
+	purge_tlb_start(flags);
+	pdtlb_kernel(vto);
+	pdtlb_kernel(vfrom);
+	purge_tlb_end(flags);
+	preempt_disable();
+	copy_user_page_asm(vto, vfrom, vaddr);
+	flush_dcache_page_asm(__pa(vto), vaddr);
+	preempt_enable();
+
+	pagefault_enable();		/* kunmap_atomic(addr, KM_USER1); */
+	pagefault_enable();		/* kunmap_atomic(addr, KM_USER0); */
+}
+
+#endif /* CONFIG_PARISC_TMPALIAS */
diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
index 6f05944..3caa199 100644
--- a/arch/parisc/kernel/entry.S
+++ b/arch/parisc/kernel/entry.S
@@ -483,7 +483,7 @@
 	 * B <-> _PAGE_DMB (memory break)
 	 *
 	 * Then incredible subtlety: The access rights are
-	 * _PAGE_GATEWAY _PAGE_EXEC _PAGE_READ
+	 * _PAGE_GATEWAY, _PAGE_EXEC and _PAGE_WRITE
 	 * See 3-14 of the parisc 2.0 manual
 	 *
 	 * Finally, _PAGE_READ goes in the top bit of PL1 (so we
@@ -493,7 +493,7 @@
 
 	/* PAGE_USER indicates the page can be read with user privileges,
 	 * so deposit X1|11 to PL1|PL2 (remember the upper bit of PL1
-	 * contains _PAGE_READ */
+	 * contains _PAGE_READ) */
 	extrd,u,*=      \pte,_PAGE_USER_BIT+32,1,%r0
 	depdi		7,11,3,\prot
 	/* If we're a gateway page, drop PL2 back to zero for promotion
@@ -1777,9 +1777,9 @@ ENTRY(sys_fork_wrapper)
 	ldo	-16(%r30),%r29		/* Reference param save area */
 #endif
 
-	/* These are call-clobbered registers and therefore
-	   also syscall-clobbered (we hope). */
-	STREG	%r2,PT_GR19(%r1)	/* save for child */
+	STREG	%r2,PT_SYSCALL_RP(%r1)	/* save for child */
+
+	/* WARNING - Clobbers r21, userspace must save! */
 	STREG	%r30,PT_GR21(%r1)
 
 	LDREG	PT_GR30(%r1),%r25
@@ -1809,7 +1809,7 @@ ENTRY(child_return)
 	nop
 
 	LDREG	TI_TASK-THREAD_SZ_ALGN-FRAME_SIZE-FRAME_SIZE(%r30), %r1
-	LDREG	TASK_PT_GR19(%r1),%r2
+	LDREG	TASK_PT_SYSCALL_RP(%r1),%r2
 	b	wrapper_exit
 	copy	%r0,%r28
 ENDPROC(child_return)
@@ -1828,8 +1828,9 @@ ENTRY(sys_clone_wrapper)
 	ldo	-16(%r30),%r29		/* Reference param save area */
 #endif
 
-	/* WARNING - Clobbers r19 and r21, userspace must save these! */
-	STREG	%r2,PT_GR19(%r1)	/* save for child */
+	STREG	%r2,PT_SYSCALL_RP(%r1)	/* save for child */
+
+	/* WARNING - Clobbers r21, userspace must save! */
 	STREG	%r30,PT_GR21(%r1)
 	BL	sys_clone,%r2
 	copy	%r1,%r24
@@ -1852,7 +1853,7 @@ ENTRY(sys_vfork_wrapper)
 	ldo	-16(%r30),%r29		/* Reference param save area */
 #endif
 
-	STREG	%r2,PT_GR19(%r1)	/* save for child */
+	STREG	%r2,PT_SYSCALL_RP(%r1)	/* save for child */
 	STREG	%r30,PT_GR21(%r1)
 
 	BL	sys_vfork,%r2
diff --git a/arch/parisc/kernel/irq.c b/arch/parisc/kernel/irq.c
index c0b1aff..8094d3e 100644
--- a/arch/parisc/kernel/irq.c
+++ b/arch/parisc/kernel/irq.c
@@ -379,14 +379,14 @@ void do_cpu_irq_mask(struct pt_regs *regs)
 static struct irqaction timer_action = {
 	.handler = timer_interrupt,
 	.name = "timer",
-	.flags = IRQF_DISABLED | IRQF_TIMER | IRQF_PERCPU | IRQF_IRQPOLL,
+	.flags = IRQF_TIMER | IRQF_PERCPU | IRQF_IRQPOLL,
 };
 
 #ifdef CONFIG_SMP
 static struct irqaction ipi_action = {
 	.handler = ipi_interrupt,
 	.name = "IPI",
-	.flags = IRQF_DISABLED | IRQF_PERCPU,
+	.flags = IRQF_PERCPU,
 };
 #endif
 
@@ -410,11 +410,13 @@ void __init init_IRQ(void)
 {
 	local_irq_disable();	/* PARANOID - should already be disabled */
 	mtctl(~0UL, 23);	/* EIRR : clear all pending external intr */
-	claim_cpu_irqs();
 #ifdef CONFIG_SMP
-	if (!cpu_eiem)
+	if (!cpu_eiem) {
+		claim_cpu_irqs();
 		cpu_eiem = EIEM_MASK(IPI_IRQ) | EIEM_MASK(TIMER_IRQ);
+	}
 #else
+	claim_cpu_irqs();
 	cpu_eiem = EIEM_MASK(TIMER_IRQ);
 #endif
         set_eiem(cpu_eiem);	/* EIEM : enable all external intr */
diff --git a/arch/parisc/kernel/pacache.S b/arch/parisc/kernel/pacache.S
index 93ff3d9..9a29e34 100644
--- a/arch/parisc/kernel/pacache.S
+++ b/arch/parisc/kernel/pacache.S
@@ -199,7 +199,6 @@ ENTRY(flush_instruction_cache_local)
 	.callinfo NO_CALLS
 	.entry
 
-	mtsp		%r0, %sr1
 	load32		cache_info, %r1
 
 	/* Flush Instruction Cache */
@@ -208,20 +207,46 @@ ENTRY(flush_instruction_cache_local)
 	LDREG		ICACHE_STRIDE(%r1), %arg1
 	LDREG		ICACHE_COUNT(%r1), %arg2
 	LDREG		ICACHE_LOOP(%r1), %arg3
-	rsm             PSW_SM_I, %r22		/* No mmgt ops during loop*/
+	rsm		PSW_SM_I, %r22		/* No mmgt ops during loop*/
 	addib,COND(=)		-1, %arg3, fioneloop	/* Preadjust and test */
 	movb,<,n	%arg3, %r31, fisync	/* If loop < 0, do sync */
 
 fimanyloop:					/* Loop if LOOP >= 2 */
 	addib,COND(>)		-1, %r31, fimanyloop	/* Adjusted inner loop decr */
-	fice            %r0(%sr1, %arg0)
-	fice,m		%arg1(%sr1, %arg0)	/* Last fice and addr adjust */
+	fice            %r0(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)	/* Last fice and addr adjust */
 	movb,tr		%arg3, %r31, fimanyloop	/* Re-init inner loop count */
 	addib,COND(<=),n	-1, %arg2, fisync	/* Outer loop decr */
 
 fioneloop:					/* Loop if LOOP = 1 */
-	addib,COND(>)		-1, %arg2, fioneloop	/* Outer loop count decr */
-	fice,m		%arg1(%sr1, %arg0)	/* Fice for one loop */
+	/* Some implementations may flush with a single fice instruction */
+	cmpib,COND(>>=),n	15, %arg2, fioneloop2
+
+fioneloop1:
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	fice,m		%arg1(%sr2, %arg0)
+	addib,COND(>)	-16, %arg2, fioneloop1
+	fice,m		%arg1(%sr2, %arg0)
+
+	/* Check if done */
+	cmpb,COND(=),n	%arg2, %r0, fisync	/* Predict branch taken */
+
+fioneloop2:
+	addib,COND(>)	-1, %arg2, fioneloop2	/* Outer loop count decr */
+	fice,m		%arg1(%sr2, %arg0)	/* Fice for one loop */
 
 fisync:
 	sync
@@ -240,8 +265,7 @@ ENTRY(flush_data_cache_local)
 	.callinfo NO_CALLS
 	.entry
 
-	mtsp		%r0, %sr1
-	load32 		cache_info, %r1
+	load32		cache_info, %r1
 
 	/* Flush Data Cache */
 
@@ -249,20 +273,46 @@ ENTRY(flush_data_cache_local)
 	LDREG		DCACHE_STRIDE(%r1), %arg1
 	LDREG		DCACHE_COUNT(%r1), %arg2
 	LDREG		DCACHE_LOOP(%r1), %arg3
-	rsm		PSW_SM_I, %r22
+	rsm		PSW_SM_I, %r22		/* No mmgt ops during loop*/
 	addib,COND(=)		-1, %arg3, fdoneloop	/* Preadjust and test */
 	movb,<,n	%arg3, %r31, fdsync	/* If loop < 0, do sync */
 
 fdmanyloop:					/* Loop if LOOP >= 2 */
 	addib,COND(>)		-1, %r31, fdmanyloop	/* Adjusted inner loop decr */
-	fdce		%r0(%sr1, %arg0)
-	fdce,m		%arg1(%sr1, %arg0)	/* Last fdce and addr adjust */
+	fdce		%r0(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)	/* Last fdce and addr adjust */
 	movb,tr		%arg3, %r31, fdmanyloop	/* Re-init inner loop count */
 	addib,COND(<=),n	-1, %arg2, fdsync	/* Outer loop decr */
 
 fdoneloop:					/* Loop if LOOP = 1 */
-	addib,COND(>)		-1, %arg2, fdoneloop	/* Outer loop count decr */
-	fdce,m		%arg1(%sr1, %arg0)	/* Fdce for one loop */
+	/* Some implementations may flush with a single fdce instruction */
+	cmpib,COND(>>=),n	15, %arg2, fdoneloop2
+
+fdoneloop1:
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	fdce,m		%arg1(%sr2, %arg0)
+	addib,COND(>)	-16, %arg2, fdoneloop1
+	fdce,m		%arg1(%sr2, %arg0)
+
+	/* Check if done */
+	cmpb,COND(=),n	%arg2, %r0, fdsync	/* Predict branch taken */
+
+fdoneloop2:
+	addib,COND(>)	-1, %arg2, fdoneloop2	/* Outer loop count decr */
+	fdce,m		%arg1(%sr2, %arg0)	/* Fdce for one loop */
 
 fdsync:
 	syncdma
@@ -277,7 +327,104 @@ ENDPROC(flush_data_cache_local)
 
 	.align	16
 
-ENTRY(copy_user_page_asm)
+/* Macros to serialize TLB purge operations on SMP.  */
+
+	.macro	tlb_lock	la,flags,tmp
+#ifdef CONFIG_SMP
+	ldil		L%pa_tlb_lock,%r1
+	ldo		R%pa_tlb_lock(%r1),\la
+	rsm		PSW_SM_I,\flags
+1:	LDCW		0(\la),\tmp
+	cmpib,<>,n	0,\tmp,3f
+2:	ldw		0(\la),\tmp
+	cmpb,<>		%r0,\tmp,1b
+	nop
+	b,n		2b
+3:
+#endif
+	.endm
+
+	.macro	tlb_unlock	la,flags,tmp
+#ifdef CONFIG_SMP
+	ldi		1,\tmp
+	stw		\tmp,0(\la)
+	mtsm		\flags
+#endif
+	.endm
+
+/* Clear page using kernel mapping.  */
+
+ENTRY(clear_page_asm)
+	.proc
+	.callinfo NO_CALLS
+	.entry
+
+#ifdef CONFIG_64BIT
+
+	/* Unroll the loop.  */
+	ldi		(PAGE_SIZE / 128), %r1
+
+1:
+	std		%r0, 0(%r26)
+	std		%r0, 8(%r26)
+	std		%r0, 16(%r26)
+	std		%r0, 24(%r26)
+	std		%r0, 32(%r26)
+	std		%r0, 40(%r26)
+	std		%r0, 48(%r26)
+	std		%r0, 56(%r26)
+	std		%r0, 64(%r26)
+	std		%r0, 72(%r26)
+	std		%r0, 80(%r26)
+	std		%r0, 88(%r26)
+	std		%r0, 96(%r26)
+	std		%r0, 104(%r26)
+	std		%r0, 112(%r26)
+	std		%r0, 120(%r26)
+
+	/* Note reverse branch hint for addib is taken.  */
+	addib,COND(>),n	-1, %r1, 1b
+	ldo		128(%r26), %r26
+
+#else
+
+	/*
+	 * Note that until (if) we start saving the full 64-bit register
+	 * values on interrupt, we can't use std on a 32 bit kernel.
+	 */
+	ldi		(PAGE_SIZE / 64), %r1
+
+1:
+	stw		%r0, 0(%r26)
+	stw		%r0, 4(%r26)
+	stw		%r0, 8(%r26)
+	stw		%r0, 12(%r26)
+	stw		%r0, 16(%r26)
+	stw		%r0, 20(%r26)
+	stw		%r0, 24(%r26)
+	stw		%r0, 28(%r26)
+	stw		%r0, 32(%r26)
+	stw		%r0, 36(%r26)
+	stw		%r0, 40(%r26)
+	stw		%r0, 44(%r26)
+	stw		%r0, 48(%r26)
+	stw		%r0, 52(%r26)
+	stw		%r0, 56(%r26)
+	stw		%r0, 60(%r26)
+
+	addib,COND(>),n	-1, %r1, 1b
+	ldo		64(%r26), %r26
+#endif
+	bv		%r0(%r2)
+	nop
+	.exit
+
+	.procend
+ENDPROC(clear_page_asm)
+
+/* Copy page using kernel mapping.  */
+
+ENTRY(copy_page_asm)
 	.proc
 	.callinfo NO_CALLS
 	.entry
@@ -285,18 +432,14 @@ ENTRY(copy_user_page_asm)
 #ifdef CONFIG_64BIT
 	/* PA8x00 CPUs can consume 2 loads or 1 store per cycle.
 	 * Unroll the loop by hand and arrange insn appropriately.
-	 * GCC probably can do this just as well.
+	 * Prefetch doesn't improve performance on rp3440.
+	 * GCC probably can do this just as well...
 	 */
 
-	ldd		0(%r25), %r19
 	ldi		(PAGE_SIZE / 128), %r1
 
-	ldw		64(%r25), %r0		/* prefetch 1 cacheline ahead */
-	ldw		128(%r25), %r0		/* prefetch 2 */
-
-1:	ldd		8(%r25), %r20
-	ldw		192(%r25), %r0		/* prefetch 3 */
-	ldw		256(%r25), %r0		/* prefetch 4 */
+1:	ldd		0(%r25), %r19
+	ldd		8(%r25), %r20
 
 	ldd		16(%r25), %r21
 	ldd		24(%r25), %r22
@@ -330,20 +473,16 @@ ENTRY(copy_user_page_asm)
 
 	ldd		112(%r25), %r21
 	ldd		120(%r25), %r22
+	ldo		128(%r25), %r25
 	std		%r19, 96(%r26)
 	std		%r20, 104(%r26)
 
-	ldo		128(%r25), %r25
 	std		%r21, 112(%r26)
 	std		%r22, 120(%r26)
-	ldo		128(%r26), %r26
 
-	/* conditional branches nullify on forward taken branch, and on
-	 * non-taken backward branch. Note that .+4 is a backwards branch.
-	 * The ldd should only get executed if the branch is taken.
-	 */
-	addib,COND(>),n	-1, %r1, 1b		/* bundle 10 */
-	ldd		0(%r25), %r19		/* start next loads */
+	/* Note reverse branch hint for addib is taken.  */
+	addib,COND(>),n	-1, %r1, 1b
+	ldo		128(%r26), %r26
 
 #else
 
@@ -399,7 +538,7 @@ ENTRY(copy_user_page_asm)
 	.exit
 
 	.procend
-ENDPROC(copy_user_page_asm)
+ENDPROC(copy_page_asm)
 
 /*
  * NOTE: Code in clear_user_page has a hard coded dependency on the
@@ -422,8 +561,6 @@ ENDPROC(copy_user_page_asm)
  *          %r23 physical page (shifted for tlb insert) of "from" translation
  */
 
-#if 0
-
 	/*
 	 * We can't do this since copy_user_page is used to bring in
 	 * file data that might have instructions. Since the data would
@@ -435,6 +572,7 @@ ENDPROC(copy_user_page_asm)
 	 * use it if more information is passed into copy_user_page().
 	 * Have to do some measurements to see if it is worthwhile to
 	 * lobby for such a change.
+	 *
 	 */
 
 ENTRY(copy_user_page_asm)
@@ -442,16 +580,21 @@ ENTRY(copy_user_page_asm)
 	.callinfo NO_CALLS
 	.entry
 
+	/* Convert virtual `to' and `from' addresses to physical addresses.
+	   Move `from' physical address to non shadowed register.  */
 	ldil		L%(__PAGE_OFFSET), %r1
 	sub		%r26, %r1, %r26
-	sub		%r25, %r1, %r23		/* move physical addr into non shadowed reg */
+	sub		%r25, %r1, %r23
 
 	ldil		L%(TMPALIAS_MAP_START), %r28
 	/* FIXME for different page sizes != 4k */
 #ifdef CONFIG_64BIT
-	extrd,u		%r26,56,32, %r26		/* convert phys addr to tlb insert format */
-	extrd,u		%r23,56,32, %r23		/* convert phys addr to tlb insert format */
-	depd		%r24,63,22, %r28		/* Form aliased virtual address 'to' */
+#if (TMPALIAS_MAP_START >= 0x80000000)
+	depdi		0, 31,32, %r28		/* clear any sign extension */
+#endif
+	extrd,u		%r26,56,32, %r26	/* convert phys addr to tlb insert format */
+	extrd,u		%r23,56,32, %r23	/* convert phys addr to tlb insert format */
+	depd		%r24,63,22, %r28	/* Form aliased virtual address 'to' */
 	depdi		0, 63,12, %r28		/* Clear any offset bits */
 	copy		%r28, %r29
 	depdi		1, 41,1, %r29		/* Form aliased virtual address 'from' */
@@ -466,10 +609,76 @@ ENTRY(copy_user_page_asm)
 
 	/* Purge any old translations */
 
+#ifdef CONFIG_PA20
+	pdtlb,l		0(%r28)
+	pdtlb,l		0(%r29)
+#else
+	tlb_lock	%r20,%r21,%r22
 	pdtlb		0(%r28)
 	pdtlb		0(%r29)
+	tlb_unlock	%r20,%r21,%r22
+#endif
 
-	ldi		64, %r1
+#ifdef CONFIG_64BIT
+	/* PA8x00 CPUs can consume 2 loads or 1 store per cycle.
+	 * Unroll the loop by hand and arrange insn appropriately.
+	 * GCC probably can do this just as well.
+	 */
+
+	ldd		0(%r29), %r19
+	ldi		(PAGE_SIZE / 128), %r1
+
+1:	ldd		8(%r29), %r20
+
+	ldd		16(%r29), %r21
+	ldd		24(%r29), %r22
+	std		%r19, 0(%r28)
+	std		%r20, 8(%r28)
+
+	ldd		32(%r29), %r19
+	ldd		40(%r29), %r20
+	std		%r21, 16(%r28)
+	std		%r22, 24(%r28)
+
+	ldd		48(%r29), %r21
+	ldd		56(%r29), %r22
+	std		%r19, 32(%r28)
+	std		%r20, 40(%r28)
+
+	ldd		64(%r29), %r19
+	ldd		72(%r29), %r20
+	std		%r21, 48(%r28)
+	std		%r22, 56(%r28)
+
+	ldd		80(%r29), %r21
+	ldd		88(%r29), %r22
+	std		%r19, 64(%r28)
+	std		%r20, 72(%r28)
+
+	ldd		 96(%r29), %r19
+	ldd		104(%r29), %r20
+	std		%r21, 80(%r28)
+	std		%r22, 88(%r28)
+
+	ldd		112(%r29), %r21
+	ldd		120(%r29), %r22
+	std		%r19, 96(%r28)
+	std		%r20, 104(%r28)
+
+	ldo		128(%r29), %r29
+	std		%r21, 112(%r28)
+	std		%r22, 120(%r28)
+	ldo		128(%r28), %r28
+
+	/* conditional branches nullify on forward taken branch, and on
+	 * non-taken backward branch. Note that .+4 is a backwards branch.
+	 * The ldd should only get executed if the branch is taken.
+	 */
+	addib,COND(>),n	-1, %r1, 1b		/* bundle 10 */
+	ldd		0(%r29), %r19		/* start next loads */
+
+#else
+	ldi		(PAGE_SIZE / 64), %r1
 
 	/*
 	 * This loop is optimized for PCXL/PCXL2 ldw/ldw and stw/stw
@@ -480,9 +689,7 @@ ENTRY(copy_user_page_asm)
 	 * use ldd/std on a 32 bit kernel.
 	 */
 
-
-1:
-	ldw		0(%r29), %r19
+1:	ldw		0(%r29), %r19
 	ldw		4(%r29), %r20
 	ldw		8(%r29), %r21
 	ldw		12(%r29), %r22
@@ -515,8 +722,10 @@ ENTRY(copy_user_page_asm)
 	stw		%r21, 56(%r28)
 	stw		%r22, 60(%r28)
 	ldo		64(%r28), %r28
+
 	addib,COND(>)		-1, %r1,1b
 	ldo		64(%r29), %r29
+#endif
 
 	bv		%r0(%r2)
 	nop
@@ -524,9 +733,8 @@ ENTRY(copy_user_page_asm)
 
 	.procend
 ENDPROC(copy_user_page_asm)
-#endif
 
-ENTRY(__clear_user_page_asm)
+ENTRY(clear_user_page_asm)
 	.proc
 	.callinfo NO_CALLS
 	.entry
@@ -550,7 +758,13 @@ ENTRY(__clear_user_page_asm)
 
 	/* Purge any old translation */
 
+#ifdef CONFIG_PA20
+	pdtlb,l		0(%r28)
+#else
+	tlb_lock	%r20,%r21,%r22
 	pdtlb		0(%r28)
+	tlb_unlock	%r20,%r21,%r22
+#endif
 
 #ifdef CONFIG_64BIT
 	ldi		(PAGE_SIZE / 128), %r1
@@ -580,8 +794,7 @@ ENTRY(__clear_user_page_asm)
 #else	/* ! CONFIG_64BIT */
 	ldi		(PAGE_SIZE / 64), %r1
 
-1:
-	stw		%r0, 0(%r28)
+1:	stw		%r0, 0(%r28)
 	stw		%r0, 4(%r28)
 	stw		%r0, 8(%r28)
 	stw		%r0, 12(%r28)
@@ -606,7 +819,7 @@ ENTRY(__clear_user_page_asm)
 	.exit
 
 	.procend
-ENDPROC(__clear_user_page_asm)
+ENDPROC(clear_user_page_asm)
 
 ENTRY(flush_dcache_page_asm)
 	.proc
@@ -630,7 +843,13 @@ ENTRY(flush_dcache_page_asm)
 
 	/* Purge any old translation */
 
+#ifdef CONFIG_PA20
+	pdtlb,l		0(%r28)
+#else
+	tlb_lock	%r20,%r21,%r22
 	pdtlb		0(%r28)
+	tlb_unlock	%r20,%r21,%r22
+#endif
 
 	ldil		L%dcache_stride, %r1
 	ldw		R%dcache_stride(%r1), %r1
@@ -663,8 +882,17 @@ ENTRY(flush_dcache_page_asm)
 	fdc,m		%r1(%r28)
 
 	sync
+
+#ifdef CONFIG_PA20
+	pdtlb,l		0(%r25)
+#else
+	tlb_lock	%r20,%r21,%r22
+	pdtlb		0(%r25)
+	tlb_unlock	%r20,%r21,%r22
+#endif
+
 	bv		%r0(%r2)
-	pdtlb		(%r25)
+	nop
 	.exit
 
 	.procend
@@ -692,7 +920,13 @@ ENTRY(flush_icache_page_asm)
 
 	/* Purge any old translation */
 
+#ifdef CONFIG_PA20
+	pitlb,l		%r0(%sr0,%r28)
+#else
+	tlb_lock	%r20,%r21,%r22
 	pitlb		(%sr0,%r28)
+	tlb_unlock	%r20,%r21,%r22
+#endif
 
 	ldil		L%icache_stride, %r1
 	ldw		R%icache_stride(%r1), %r1
@@ -725,8 +959,17 @@ ENTRY(flush_icache_page_asm)
 	fic,m		%r1(%r28)
 
 	sync
-	bv		%r0(%r2)
+
+#ifdef CONFIG_PA20
+	pitlb,l		%r0(%sr0,%r25)
+#else
+	tlb_lock	%r20,%r21,%r22
 	pitlb		(%sr0,%r25)
+	tlb_unlock	%r20,%r21,%r22
+#endif
+
+	bv		%r0(%r2)
+	nop
 	.exit
 
 	.procend
@@ -775,7 +1018,7 @@ ENTRY(flush_kernel_dcache_page_asm)
 	.procend
 ENDPROC(flush_kernel_dcache_page_asm)
 
-ENTRY(purge_kernel_dcache_page)
+ENTRY(purge_kernel_dcache_page_asm)
 	.proc
 	.callinfo NO_CALLS
 	.entry
@@ -815,7 +1058,7 @@ ENTRY(purge_kernel_dcache_page)
 	.exit
 
 	.procend
-ENDPROC(purge_kernel_dcache_page)
+ENDPROC(purge_kernel_dcache_page_asm)
 
 ENTRY(flush_user_dcache_range_asm)
 	.proc
diff --git a/arch/parisc/kernel/parisc_ksyms.c b/arch/parisc/kernel/parisc_ksyms.c
index a7bb757..25835d8 100644
--- a/arch/parisc/kernel/parisc_ksyms.c
+++ b/arch/parisc/kernel/parisc_ksyms.c
@@ -158,5 +158,6 @@ extern void _mcount(void);
 EXPORT_SYMBOL(_mcount);
 #endif
 
-/* from pacache.S -- needed for copy_page */
-EXPORT_SYMBOL(copy_user_page_asm);
+/* from pacache.S -- needed for clear/copy_page */
+EXPORT_SYMBOL(clear_page_asm);
+EXPORT_SYMBOL(copy_page_asm);
diff --git a/arch/parisc/kernel/signal.c b/arch/parisc/kernel/signal.c
index 12c1ed3..5dd1059 100644
--- a/arch/parisc/kernel/signal.c
+++ b/arch/parisc/kernel/signal.c
@@ -314,7 +314,7 @@ setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
 #if DEBUG_SIG
 	/* Assert that we're flushing in the correct space... */
 	{
-		int sid;
+		unsigned long sid;
 		asm ("mfsp %%sr3,%0" : "=r" (sid));
 		DBG(1,"setup_rt_frame: Flushing 64 bytes at space %#x offset %p\n",
 		       sid, frame->tramp);
diff --git a/arch/parisc/kernel/smp.c b/arch/parisc/kernel/smp.c
index 0bb1d63..4dc7b79 100644
--- a/arch/parisc/kernel/smp.c
+++ b/arch/parisc/kernel/smp.c
@@ -31,6 +31,7 @@
 #include <linux/delay.h>
 #include <linux/bitops.h>
 #include <linux/ftrace.h>
+#include <linux/cpu.h>
 
 #include <linux/atomic.h>
 #include <asm/current.h>
@@ -295,8 +296,13 @@ smp_cpu_init(int cpunum)
 
 		printk(KERN_CRIT "CPU#%d already initialized!\n", cpunum);
 		machine_halt();
-	}  
+	}
+
+	notify_cpu_starting(cpunum);
+
+	ipi_call_lock();
 	set_cpu_online(cpunum, true);
+	ipi_call_unlock();
 
 	/* Initialise the idle task for this CPU */
 	atomic_inc(&init_mm.mm_count);
diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
index c9b9322..f0cb56e 100644
--- a/arch/parisc/kernel/sys_parisc.c
+++ b/arch/parisc/kernel/sys_parisc.c
@@ -92,11 +92,12 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
 {
 	if (len > TASK_SIZE)
 		return -ENOMEM;
-	/* Might want to check for cache aliasing issues for MAP_FIXED case
-	 * like ARM or MIPS ??? --BenH.
-	 */
-	if (flags & MAP_FIXED)
+	if (flags & MAP_FIXED) {
+		if ((flags & MAP_SHARED) &&
+		    (addr - (pgoff << PAGE_SHIFT)) & (SHMLBA - 1))
+			return -EINVAL;
 		return addr;
+	}
 	if (!addr)
 		addr = TASK_UNMAPPED_BASE;
 
diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c
index 70e105d..4a24ba7 100644
--- a/arch/parisc/kernel/time.c
+++ b/arch/parisc/kernel/time.c
@@ -77,7 +77,7 @@ irqreturn_t __irq_entry timer_interrupt(int irq, void *dev_id)
 
 	cycles_elapsed = now - next_tick;
 
-	if ((cycles_elapsed >> 6) < cpt) {
+	if ((cycles_elapsed >> 7) < cpt) {
 		/* use "cheap" math (add/subtract) instead
 		 * of the more expensive div/mul method
 		 */
diff --git a/arch/parisc/kernel/vmlinux.lds.S b/arch/parisc/kernel/vmlinux.lds.S
index fa6f2b8..64a9998 100644
--- a/arch/parisc/kernel/vmlinux.lds.S
+++ b/arch/parisc/kernel/vmlinux.lds.S
@@ -50,8 +50,10 @@ SECTIONS
 	. = KERNEL_BINARY_TEXT_START;
 
 	_text = .;		/* Text and read-only data */
-	.text ALIGN(16) : {
+	.head ALIGN(16) : {
 		HEAD_TEXT
+	} = 0
+	.text ALIGN(16) : {
 		TEXT_TEXT
 		SCHED_TEXT
 		LOCK_TEXT
@@ -65,7 +67,7 @@ SECTIONS
 		*(.fixup)
 		*(.lock.text)		/* out-of-line lock text */
 		*(.gnu.warning)
-	} = 0
+	}
 	/* End of text section */
 	_etext = .;
 
diff --git a/arch/parisc/math-emu/cnv_float.h b/arch/parisc/math-emu/cnv_float.h
index 9071e09..37299c7 100644
--- a/arch/parisc/math-emu/cnv_float.h
+++ b/arch/parisc/math-emu/cnv_float.h
@@ -347,16 +347,15 @@
     Sgl_isinexact_to_fix(sgl_value,exponent)
 
 #define Duint_from_sgl_mantissa(sgl_value,exponent,dresultA,dresultB)	\
-  {Sall(sgl_value) <<= SGL_EXP_LENGTH;  /*  left-justify  */		\
+  {unsigned int val = Sall(sgl_value) << SGL_EXP_LENGTH;		\
     if (exponent <= 31) {						\
     	Dintp1(dresultA) = 0;						\
-    	Dintp2(dresultB) = (unsigned)Sall(sgl_value) >> (31 - exponent); \
+    	Dintp2(dresultB) = val >> (31 - exponent);			\
     }									\
     else {								\
-    	Dintp1(dresultA) = Sall(sgl_value) >> (63 - exponent);		\
-    	Dintp2(dresultB) = Sall(sgl_value) << (exponent - 31);		\
+    	Dintp1(dresultA) = val >> (63 - exponent);			\
+    	Dintp2(dresultB) = exponent <= 62 ? val << (exponent - 31) : 0;	\
     }									\
-    Sall(sgl_value) >>= SGL_EXP_LENGTH;  /* return to original */	\
   }
 
 #define Duint_setzero(dresultA,dresultB) 	\
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6080f6b..231996a 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -574,6 +574,7 @@ out_eoi:
 void
 handle_percpu_irq(unsigned int irq, struct irq_desc *desc)
 {
+	struct irqaction *action;
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 
 	kstat_incr_irqs_this_cpu(irq, desc);
@@ -581,7 +582,9 @@ handle_percpu_irq(unsigned int irq, struct irq_desc *desc)
 	if (chip->irq_ack)
 		chip->irq_ack(&desc->irq_data);
 
-	handle_irq_event_percpu(desc, desc->action);
+	action = desc->action;
+	if (action)
+		handle_irq_event_percpu(desc, action);
 
 	if (chip->irq_eoi)
 		chip->irq_eoi(&desc->irq_data);

[-- Attachment #3: dmesg.0 --]
[-- Type: application/octet-stream, Size: 21516 bytes --]

Linux version 3.4.0-rc7+ (dave@mx3210) (gcc version 4.7.0 (GCC) ) #2 SMP Sun May 13 17:23:28 EDT 2012
unwind_init: start = 0x404c9000, end = 0x404f6f30, entries = 11763
FP[0] enabled: Rev 1 Model 20
The 64-bit Kernel has started...
bootconsole [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: 64 bit PAT.
model 00008870 00000491 00000000 00000002 3e0505e7352af711 100000f0 00000008 000000b2 000000b2
vers  00000301
CPUID vers 20 rev 4 (0x00000284)
capabilities 0x35
model 9000/800/rp3440  
ic_size 2000000 dc_size 2000000 it_size f0
DC  base 0x0 stride 0x80 count 0x40000 loop 0x1
dc_conf = 0x1882000  alias 0 blk 1 line 4 shift 1
	wt 0 sh 0 cst 1 hv 0
IC  base 0x0 stride 0x80 count 0x40000 loop 0x1
ic_conf = 0x1882000  alias 0 blk 1 line 4 shift 1
	wt 0 sh 0 cst 1 hv 0
D-TLB conf: sh 3 page 1 cst 1 aid 0 pad1 0
I-TLB conf: sh 3 page 1 cst 1 aid 3 pad1 0
parisc_cache_init: Only equivalent aliasing supported!
Memory Ranges:
 0) Start 0x0000000000000000 End 0x000000003fffffff Size   1024 MB
 1) Start 0x0000000100000000 End 0x000000027fdfffff Size   6142 MB
 2) Start 0x0000004040000000 End 0x00000040ffffffff Size   3072 MB
Total Memory: 10238 MB
initrd: 7f87c000-7ffee61e
initrd: reserving 3f87c000-3ffee61e (mem_max 27fe00000)
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat 405127c0, node_mem_map 419f7000
  Normal zone: 3584 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 258560 pages, LIFO batch:31
On node 1 totalpages: 1572352
free_area_init_node: node 1, pgdat 40513540, node_mem_map 140000000
  Normal zone: 21497 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 1550855 pages, LIFO batch:31
On node 2 totalpages: 786432
free_area_init_node: node 2, pgdat 405142c0, node_mem_map 4080000000
  Normal zone: 10752 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 775680 pages, LIFO batch:31
PERCPU: Embedded 10 pages/cpu @0000000042800000 s8448 r8192 d24320 u40960
pcpu-alloc: s8448 r8192 d24320 u40960 alloc=10*4096
pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] 06 [0] 07 
pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11 [0] 12 [0] 13 [0] 14 [0] 15 
pcpu-alloc: [0] 16 [0] 17 [0] 18 [0] 19 [0] 20 [0] 21 [0] 22 [0] 23 
pcpu-alloc: [0] 24 [0] 25 [0] 26 [0] 27 [0] 28 [0] 29 [0] 30 [0] 31 
SMP: bootstrap CPU ID is 0
Built 3 zonelists in Zone order, mobility grouping on.  Total pages: 2585095
Kernel command line: root=/dev/sda5 console=ttyS1 HOME=/ rootfstype=ext3 palo_kernel=2/vmlinux
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes)
Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Memory: 10280328k/10483712k available (3250k kernel code, 203384k reserved, 1429k data, 216k init)
virtual kernel memory layout:
    vmalloc : 0x0000000000008000 - 0x000000003f000000   (1007 MB)
    memory  : 0x0000000040000000 - 0x0000004140000000   (266240 MB)
      .init : 0x000000004065c000 - 0x0000000040692000   ( 216 kB)
      .data : 0x000000004042c8e8 - 0x0000000040591e10   (1429 kB)
      .text : 0x0000000040100000 - 0x000000004042c8e8   (3250 kB)
Hierarchical RCU implementation.
NR_IRQS:128
Console: colour dummy device 160x64
------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
                                 | spin |wlock |rlock |mutex | wsem | rsem |
  --------------------------------------------------------------------------
                     A-A deadlock:failed|failed|  ok  |failed|failed|failed|
                 A-B-B-A deadlock:failed|failed|  ok  |failed|failed|failed|
             A-B-B-C-C-A deadlock:failed|failed|  ok  |failed|failed|failed|
             A-B-C-A-B-C deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-B-C-C-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-C-D-B-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-C-D-B-C-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
                    double unlock:failed|failed|failed|  ok  |failed|failed|
                  initialize held:failed|failed|failed|failed|failed|failed|
                 bad unlock order:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
  --------------------------------------------------------------------------
              recursive read-lock:             |  ok  |             |failed|
           recursive read-lock #2:             |  ok  |             |failed|
            mixed read-write-lock:             |failed|             |failed|
            mixed write-read-lock:             |failed|             |failed|
  --------------------------------------------------------------------------
     hard-irqs-on + irq-safe-A/12:failed|failed|  ok  |
     soft-irqs-on + irq-safe-A/12:failed|failed|  ok  |
     hard-irqs-on + irq-safe-A/21:failed|failed|  ok  |
     soft-irqs-on + irq-safe-A/21:failed|failed|  ok  |
       sirq-safe-A => hirqs-on/12:failed|failed|  ok  |
       sirq-safe-A => hirqs-on/21:failed|failed|  ok  |
         hard-safe-A + irqs-on/12:failed|failed|  ok  |
         soft-safe-A + irqs-on/12:failed|failed|  ok  |
         hard-safe-A + irqs-on/21:failed|failed|  ok  |
         soft-safe-A + irqs-on/21:failed|failed|  ok  |
    hard-safe-A + unsafe-B #1/123:failed|failed|  ok  |
    soft-safe-A + unsafe-B #1/123:failed|failed|  ok  |
    hard-safe-A + unsafe-B #1/132:failed|failed|  ok  |
    soft-safe-A + unsafe-B #1/132:failed|failed|  ok  |
    hard-safe-A + unsafe-B #1/213:failed|failed|  ok  |
    soft-safe-A + unsafe-B #1/213:failed|failed|  ok  |
    hard-safe-A + unsafe-B #1/231:failed|failed|  ok  |
    soft-safe-A + unsafe-B #1/231:failed|failed|  ok  |
    hard-safe-A + unsafe-B #1/312:failed|failed|  ok  |
    soft-safe-A + unsafe-B #1/312:failed|failed|  ok  |
    hard-safe-A + unsafe-B #1/321:failed|failed|  ok  |
    soft-safe-A + unsafe-B #1/321:failed|failed|  ok  |
    hard-safe-A + unsafe-B #2/123:failed|failed|  ok  |
    soft-safe-A + unsafe-B #2/123:failed|failed|  ok  |
    hard-safe-A + unsafe-B #2/132:failed|failed|  ok  |
    soft-safe-A + unsafe-B #2/132:failed|failed|  ok  |
    hard-safe-A + unsafe-B #2/213:failed|failed|  ok  |
    soft-safe-A + unsafe-B #2/213:failed|failed|  ok  |
    hard-safe-A + unsafe-B #2/231:failed|failed|  ok  |
    soft-safe-A + unsafe-B #2/231:failed|failed|  ok  |
    hard-safe-A + unsafe-B #2/312:failed|failed|  ok  |
    soft-safe-A + unsafe-B #2/312:failed|failed|  ok  |
    hard-safe-A + unsafe-B #2/321:failed|failed|  ok  |
    soft-safe-A + unsafe-B #2/321:failed|failed|  ok  |
      hard-irq lock-inversion/123:failed|failed|  ok  |
      soft-irq lock-inversion/123:failed|failed|  ok  |
      hard-irq lock-inversion/132:failed|failed|  ok  |
      soft-irq lock-inversion/132:failed|failed|  ok  |
      hard-irq lock-inversion/213:failed|failed|  ok  |
      soft-irq lock-inversion/213:failed|failed|  ok  |
      hard-irq lock-inversion/231:failed|failed|  ok  |
      soft-irq lock-inversion/231:failed|failed|  ok  |
      hard-irq lock-inversion/312:failed|failed|  ok  |
      soft-irq lock-inversion/312:failed|failed|  ok  |
      hard-irq lock-inversion/321:failed|failed|  ok  |
      soft-irq lock-inversion/321:failed|failed|  ok  |
      hard-irq read-recursion/123:  ok  |
      soft-irq read-recursion/123:  ok  |
      hard-irq read-recursion/132:  ok  |
      soft-irq read-recursion/132:  ok  |
      hard-irq read-recursion/213:  ok  |
      soft-irq read-recursion/213:  ok  |
      hard-irq read-recursion/231:  ok  |
      soft-irq read-recursion/231:  ok  |
      hard-irq read-recursion/312:  ok  |
      soft-irq read-recursion/312:  ok  |
      hard-irq read-recursion/321:  ok  |
      soft-irq read-recursion/321:  ok  |
--------------------------------------------------------
144 out of 218 testcases failed, as expected. |
----------------------------------------------------
Calibrating delay loop... 1594.36 BogoMIPS (lpj=3188736)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 256
Brought up 1 CPUs
devtmpfs: initialized
atomic64 test passed
NET: Registered protocol family 16
Searching for devices...
Found devices:
1. Storm Peak Slow at 0xfffffffffe780000 [128] { 0, 0x0, 0x887, 0x00004 }
2. Storm Peak Slow at 0xfffffffffe781000 [129] { 0, 0x0, 0x887, 0x00004 }
3. Storm Peak Slow at 0xfffffffffe798000 [152] { 0, 0x0, 0x887, 0x00004 }
4. Storm Peak Slow at 0xfffffffffe799000 [153] { 0, 0x0, 0x887, 0x00004 }
5. Everest Mako Memory at 0xfffffffffed08000 [8] { 1, 0x0, 0x0af, 0x00009 }
6. Pluto BC McKinley Port at 0xfffffffffed00000 [0] { 12, 0x0, 0x880, 0x0000c }
7. Mercury PCI Bridge at 0xfffffffffed20000 [0/0] { 13, 0x0, 0x783, 0x0000a }
8. Mercury PCI Bridge at 0xfffffffffed22000 [0/1] { 13, 0x0, 0x783, 0x0000a }
9. Mercury PCI Bridge at 0xfffffffffed24000 [0/2] { 13, 0x0, 0x783, 0x0000a }
10. Mercury PCI Bridge at 0xfffffffffed26000 [0/3] { 13, 0x0, 0x783, 0x0000a }
11. Mercury PCI Bridge at 0xfffffffffed28000 [0/4] { 13, 0x0, 0x783, 0x0000a }
12. Mercury PCI Bridge at 0xfffffffffed2c000 [0/6] { 13, 0x0, 0x783, 0x0000a }
13. Mercury PCI Bridge at 0xfffffffffed2e000 [0/7] { 13, 0x0, 0x783, 0x0000a }
14. BMC IPMI Mgmt Ctlr at 0xfffffff0f05b0000 [16] { 15, 0x0, 0x004, 0x000c0 }
Releasing cpu 1 now, hpa=fffffffffe781000
FP[1] enabled: Rev 1 Model 20
Releasing cpu 2 now, hpa=fffffffffe798000
FP[2] enabled: Rev 1 Model 20
Releasing cpu 3 now, hpa=fffffffffe799000
FP[3] enabled: Rev 1 Model 20
CPU(s): 4 x PA8800 (Mako) at 800.007300 MHz
Whole cache flush 9074766 cycles, flushing 5840896 bytes 584238 cycles
Setting cache flush threshold to 2000000 (4 CPUs online)
SBA found Pluto 2.3 at 0xfffffffffed00000
Mercury version TR3.2 (0x32) found at 0xfffffffffed20000
LBA 0:0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0xffffffff80000000-0xffffffff8fffffff] (bus address [0x80000000-0x8fffffff])
pci_bus 0000:00: root bus resource [mem 0xffffff0004000000-0xffffff0fffffffff]
pci 0000:00:01.0: [1033:0035] type 00 class 0x0c0310
pci 0000:00:01.0: reg 10: [mem 0xffffffff80002000-0xffffffff80002fff]
pci 0000:00:01.0: supports D1 D2
pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:01.1: [1033:0035] type 00 class 0x0c0310
pci 0000:00:01.1: reg 10: [mem 0xffffffff80001000-0xffffffff80001fff]
pci 0000:00:01.1: supports D1 D2
pci 0000:00:01.1: PME# supported from D0 D1 D2 D3hot
pci 0000:00:01.2: [1033:00e0] type 00 class 0x0c0320
pci 0000:00:01.2: reg 10: [mem 0xffffffff80000000-0xffffffff800000ff]
pci 0000:00:01.2: supports D1 D2
pci 0000:00:01.2: PME# supported from D0 D1 D2 D3hot
pci 0000:00:02.0: [1095:0649] type 00 class 0x01018f
pci 0000:00:02.0: reg 10: [io  0x0d18-0x0d1f]
pci 0000:00:02.0: reg 14: [io  0x0d24-0x0d27]
pci 0000:00:02.0: reg 18: [io  0x0d10-0x0d17]
pci 0000:00:02.0: reg 1c: [io  0x0d20-0x0d23]
pci 0000:00:02.0: reg 20: [io  0x0d00-0x0d0f]
pci 0000:00:02.0: supports D1 D2
Mercury version TR3.2 (0x32) found at 0xfffffffffed22000
LBA 0:1: PCI host bridge to bus 0000:20
pci_bus 0000:20: root bus resource [io  0x10000-0x1ffff] (bus address [0x0000-0xffff])
pci_bus 0000:20: root bus resource [mem 0xffffffff90000000-0xffffffff9fffffff] (bus address [0x90000000-0x9fffffff])
pci_bus 0000:20: root bus resource [mem 0xffffff1004000000-0xffffff1fffffffff]
pci 0000:20:01.0: [1000:0021] type 00 class 0x010000
pci 0000:20:01.0: reg 10: [io  0x12100-0x121ff]
pci 0000:20:01.0: reg 14: [mem 0xffffffff90015000-0xffffffff900153ff 64bit]
pci 0000:20:01.0: reg 1c: [mem 0xffffffff90012000-0xffffffff90013fff 64bit]
pci 0000:20:01.0: supports D1 D2
pci 0000:20:01.1: [1000:0021] type 00 class 0x010000
pci 0000:20:01.1: reg 10: [io  0x12000-0x120ff]
pci 0000:20:01.1: reg 14: [mem 0xffffffff90014000-0xffffffff900143ff 64bit]
pci 0000:20:01.1: reg 1c: [mem 0xffffffff90010000-0xffffffff90011fff 64bit]
pci 0000:20:01.1: supports D1 D2
pci 0000:20:02.0: [14e4:1645] type 00 class 0x020000
pci 0000:20:02.0: reg 10: [mem 0xffffffff90000000-0xffffffff9000ffff 64bit]
pci 0000:20:02.0: PME# supported from D3hot D3cold
Mercury version TR3.2 (0x32) found at 0xfffffffffed24000
LBA 0:2: PCI host bridge to bus 0000:40
pci_bus 0000:40: root bus resource [io  0x20000-0x2ffff] (bus address [0x0000-0xffff])
pci_bus 0000:40: root bus resource [mem 0xffffffffa0000000-0xffffffffafffffff] (bus address [0xa0000000-0xafffffff])
pci_bus 0000:40: root bus resource [mem 0xffffff2004000000-0xffffff2fffffffff]
Mercury version TR3.2 (0x32) found at 0xfffffffffed26000
LBA 0:3: PCI host bridge to bus 0000:60
pci_bus 0000:60: root bus resource [io  0x30000-0x3ffff] (bus address [0x0000-0xffff])
pci_bus 0000:60: root bus resource [mem 0xffffffffb0000000-0xffffffffbfffffff] (bus address [0xb0000000-0xbfffffff])
pci_bus 0000:60: root bus resource [mem 0xffffff3004000000-0xffffff3fffffffff]
Mercury version TR3.2 (0x32) found at 0xfffffffffed28000
LBA 0:4: PCI host bridge to bus 0000:80
pci_bus 0000:80: root bus resource [io  0x40000-0x4ffff] (bus address [0x0000-0xffff])
pci_bus 0000:80: root bus resource [mem 0xffffffffc0000000-0xffffffffcfffffff] (bus address [0xc0000000-0xcfffffff])
pci_bus 0000:80: root bus resource [mem 0xffffff4004000000-0xffffff4fffffffff]
Mercury version TR3.2 (0x32) found at 0xfffffffffed2c000
LBA 0:6: PCI host bridge to bus 0000:c0
pci_bus 0000:c0: root bus resource [io  0x50000-0x5ffff] (bus address [0x0000-0xffff])
pci_bus 0000:c0: root bus resource [mem 0xffffffffe0000000-0xffffffffefffffff] (bus address [0xe0000000-0xefffffff])
pci_bus 0000:c0: root bus resource [mem 0xffffff6004000000-0xffffff6fffffffff]
Mercury version TR3.2 (0x32) found at 0xfffffffffed2e000
LBA: Truncating lmmio_space [fffffffff0000000/fffffffffecffffe] to [fffffffff0000000,fffffffffe77ffff]
LBA 0:7: PCI host bridge to bus 0000:e0
pci_bus 0000:e0: root bus resource [io  0x60000-0x6ffff] (bus address [0x0000-0xffff])
pci_bus 0000:e0: root bus resource [mem 0xfffffffff0000000-0xfffffffffe77ffff] (bus address [0xf0000000-0xfe77ffff])
pci_bus 0000:e0: root bus resource [mem 0xffffff7004000000-0xffffff7fffffffff]
pci 0000:e0:01.0: [103c:1290] type 00 class 0x078000
pci 0000:e0:01.0: reg 18: [mem 0xfffffffff4051000-0xfffffffff405100f]
pci 0000:e0:01.1: [103c:1048] type 00 class 0x070002
pci 0000:e0:01.1: reg 10: [mem 0xfffffffff4050000-0xfffffffff4050fff]
pci 0000:e0:01.1: reg 18: [mem 0xfffffffff4020000-0xfffffffff403ffff pref]
pci 0000:e0:02.0: [1002:5159] type 00 class 0x030000
pci 0000:e0:02.0: reg 10: [mem 0xfffffffff0000000-0xfffffffff3ffffff pref]
pci 0000:e0:02.0: reg 14: [io  0x6e000-0x6e0ff]
pci 0000:e0:02.0: reg 18: [mem 0xfffffffff4040000-0xfffffffff404ffff]
pci 0000:e0:02.0: reg 30: [mem 0xfffffffff4000000-0xfffffffff401ffff pref]
pci 0000:e0:02.0: supports D1 D2
powersw: Soft power switch support not available.
bio: create slab <bio-0> at 0
vgaarb: device added: PCI:0000:e0:02.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:e0:02.0
NET: Registered protocol family 2
IP route cache hash table entries: 524288 (order: 10, 4194304 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP: reno registered
UDP hash table entries: 8192 (order: 6, 262144 bytes)
UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)
NET: Registered protocol family 1
PCI: CLS 64 bytes
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 7625k freed
Performance monitoring counters enabled for Storm Peak Slow
msgmni has been set to 20093
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
0000:e0:01.0: ttyS0 at MMIO 0xfffffffff4051000 (irq = 73) is a 16550A
0000:e0:01.1: ttyS1 at MMIO 0xfffffffff4050000 (irq = 73) is a 16550A
console [ttyS1] enabled, bootconsole disabled
0000:e0:01.1: ttyS2 at MMIO 0xfffffffff4050010 (irq = 73) is a 16550A
0000:e0:01.1: ttyS3 at MMIO 0xfffffffff4050038 (irq = 73) is a 16550A
Linux agpgart interface v0.103
brd: module loaded
HP SDC: No SDC found.
HP SDC MLC: Registering the System Domain Controller's HIL MLC.
HP SDC MLC: Request for raw HIL ISR hook denied
mousedev: PS/2 mouse device common for all mice
rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
TCP: cubic registered
rtc-generic rtc-generic: setting system clock to 2012-05-14 00:36:09 UTC (1336955769)
Freeing unused kernel memory: 216k freed
udevd[836]: starting version 175
SCSI subsystem initialized
tg3.c:v3.123 (March 21, 2012)
libata version 3.00 loaded.
pata_cmd64x 0000:00:02.0: Secondary port is disabled
scsi0 : pata_cmd64x
scsi1 : pata_cmd64x
ata1: PATA max UDMA/100 cmd 0xd18 ctl 0xd24 bmdma 0xd00 irq 69
ata2: DUMMY
pata_cmd64x: active 10 recovery 10 setup 3.
pata_cmd64x: active 10 recovery 10 setup 3.
ata1.00: ATAPI: DW-224E, C.0B, max UDMA/33
pata_cmd64x: active 3 recovery 1 setup 1.
ata1.00: configured for UDMA/33
scsi 0:0:0:0: CD-ROM            TEAC     DW-224E          C.0B PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
cdrom: Uniform CD-ROM driver Revision: 3.20
sr 0:0:0:0: Attached scsi CD-ROM sr0
tg3 0000:20:02.0: eth0: Tigon3 [partno(BCM95700A6) rev 0105] (PCI:66MHz:64-bit) MAC address 00:30:6e:4b:16:4d
tg3 0000:20:02.0: eth0: attached PHY is 5701 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
tg3 0000:20:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[0]
tg3 0000:20:02.0: eth0: dma_rwctrl[76ff2d0f] dma_mask[32-bit]
sym0: <1010-66> rev 0x1 at pci 0000:20:01.0 irq 70
sym0: PA-RISC Firmware, ID 7, Fast-80, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi2 : sym-2.2.3
scsi 2:0:0:0: Direct-Access     FUJITSU  MAJ3364MC        HP12 PQ: 0 ANSI: 2
scsi target2:0:0: tagged command queuing enabled, command queue depth 16.
scsi target2:0:0: Beginning Domain Validation
scsi target2:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
scsi target2:0:0: Ending Domain Validation
sym1: <1010-66> rev 0x1 at pci 0000:20:01.1 irq 71
sym1: PA-RISC Firmware, ID 7, Fast-80, LVD, parity checking
sym1: SCSI BUS has been reset.
scsi3 : sym-2.2.3
scsi 3:0:2:0: Direct-Access     SEAGATE  ST318203LC       HP04 PQ: 0 ANSI: 2
scsi target3:0:2: tagged command queuing enabled, command queue depth 16.
scsi target3:0:2: Beginning Domain Validation
scsi target3:0:2: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 15)
scsi target3:0:2: Domain Validation skipping write tests
scsi target3:0:2: Ending Domain Validation
sd 2:0:0:0: [sda] 71132960 512-byte logical blocks: (36.4 GB/33.9 GiB)
sd 3:0:2:0: [sdb] 35566480 512-byte logical blocks: (18.2 GB/16.9 GiB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: ab 00 10 08
sd 3:0:2:0: [sdb] Write Protect is off
sd 3:0:2:0: [sdb] Mode Sense: 9f 00 10 08
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
sd 3:0:2:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
 sdb: sdb1 sdb2
 sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
sd 3:0:2:0: [sdb] Attached SCSI disk
sd 2:0:0:0: [sda] Attached SCSI disk
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sda5): mounted filesystem with writeback data mode
udevd[1019]: starting version 175
udisks-part-id(1135): unaligned access to 0x00000000fafdc98e at ip=0x0000000000012b53
udisks-part-id(1135): unaligned access to 0x00000000fafdc992 at ip=0x0000000000012bc7
udisks-part-id(1135): unaligned access to 0x00000000fafdc99e at ip=0x0000000000012b53
udisks-part-id(1135): unaligned access to 0x00000000fafdc9a2 at ip=0x0000000000012bc7
udisks-part-id(1134): unaligned access to 0x00000000fb3db98e at ip=0x0000000000012b53
Adding 979928k swap on /dev/sda6.  Priority:-1 extents:1 across:979928k 
EXT3-fs (sda5): using internal journal
handle_unaligned: 179 callbacks suppressed
udisks-part-id(1617): unaligned access to 0x00000000fb6239ce at ip=0x0000000000012b53
udisks-part-id(1617): unaligned access to 0x00000000fb6239d2 at ip=0x0000000000012bc7
udisks-part-id(1617): unaligned access to 0x00000000fb6239de at ip=0x0000000000012b53
udisks-part-id(1617): unaligned access to 0x00000000fb6239e2 at ip=0x0000000000012bc7
udisks-part-id(1617): unaligned access to 0x00000000fb6239ee at ip=0x0000000000012b53
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sda7): using internal journal
EXT3-fs (sda7): mounted filesystem with writeback data mode
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sdb1): using internal journal
EXT3-fs (sdb1): mounted filesystem with writeback data mode
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sdb2): using internal journal
EXT3-fs (sdb2): mounted filesystem with writeback data mode
NET: Registered protocol family 10
ADDRCONF(NETDEV_UP): eth0: link is not ready
tg3 0000:20:02.0: eth0: Link is up at 100 Mbps, full duplex
tg3 0000:20:02.0: eth0: Flow control is on for TX and on for RX
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).

^ permalink raw reply related	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-14  1:10           ` John David Anglin
@ 2012-05-14 22:11             ` Helge Deller
  2012-05-14 22:38               ` John David Anglin
  2012-05-15  8:06               ` James Bottomley
  0 siblings, 2 replies; 56+ messages in thread
From: Helge Deller @ 2012-05-14 22:11 UTC (permalink / raw)
  To: John David Anglin; +Cc: Vincent, Rolf Eike Beer, linux-parisc

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

On 05/14/2012 03:10 AM, John David Anglin wrote:
> I had a successful bot of 3.4.0-rc7+ this evening.
>
> I updated my running kernel patch to 3.4.  The futex patch is removed 
> and Srivatsa S. Bhat's
> patch added.

Ok, I applied your patch now.
I used latest binutils and (as suggested by Dave) gcc-4.6 branch.
I built Kernel 3.4.0-rc7 as 32bit-binary for my c3000, b160L and 715/64.

The c3000 booted nicely into userspace.

The B160L and the 715/64 (both 32bit-only PA1.X machines) crashed with 
the following trace.
All logs attached.

Any ideas?

Helge



swapper (pid 1): Illegal instruction (code 8)

      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000000000000000000000000 Not tainted
r00-03  00000000 00000001 101bc460 19c246c0
r04-07  00000017 19e6a5f8 19c22db8 ffeffff1
r08-11  0f2ff000 0f000000 00000033 fff00ff1
r12-15  00000000 00000017 00000001 00000000
r16-19  00000000 00000043 00000000 107e9a80
r20-23  19c245c8 10957000 00000001 00000001
r24-27  00000000 00000000 0000fa80 106e2020
r28-31  0f2ff000 000094b9 19c24740 00009271
sr00-03  00000000 00000001 00000000 00000000
sr04-07  00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 10101110 10101114
  IIR: 078112a0    ISR: 00000000  IOR: 0f2ff000
  CPU:        0   CR30: 19c24000 CR31: f00effff
  ORIG_R28: 19e84ffc
  IAOQ[0]: flush_dcache_page_asm+0x28/0x7c
  IAOQ[1]: flush_dcache_page_asm+0x2c/0x7c
  RP(r2): __get_user_pages+0x38c/0x3c4
Backtrace:
  [<101bc460>] __get_user_pages+0x38c/0x3c4
  [<101bc580>] get_user_pages+0x50/0x60
  [<101e1a1c>] get_arg_page+0x64/0xe8
  [<101e1bac>] copy_strings+0x10c/0x248
  [<101e1d10>] copy_strings_kernel+0x28/0x44
  [<101e360c>] do_execve+0x2a0/0x36c
  [<10120598>] sys_execve+0x44/0x7c
  [<10104084>] __execve+0x20/0x34
  [<10133d2c>] vprintk+0x1d8/0x4f4
  [<10134078>] printk+0x30/0x40
  [<10118550>] free_initmem+0x154/0x184
  [<10117cbc>] init_post+0xa0/0xd4
  [<1078a294>] kernel_init+0x210/0x214


[-- Attachment #2: 715_64.log --]
[-- Type: text/plain, Size: 23520 bytes --]

Command line for kernel: 'HOME=/ root=/dev/sda5 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux'
Selected kernel: /vmlinux from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing 32-bit kernelELF32 executable
Entry 00100000 first 00100000 n 3
Segment 0 load 00100000 size 6549504 mediaptr 0x1000
Segment 1 load 00788000 size 176308 mediaptr 0x640000
Segment 2 load 007b4000 size 144916 mediaptr 0x66c000
Branching to kernel entry point 0x00100000.  If this is the last
message you see, you may need to switch your console.  This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.4.0-rc7-32bit+ (deller@p100) (gcc version 4.6.4 20120514 (prerelease) (GCC) ) #1 Mon May 14 23:10:09 CEST 2012
unwind_init: start = 0x10690000, end = 0x106d5190, entries = 17689
FP[0] enabled: Rev 1 Model 13
The 32-bit Kernel has started...
bootconsole [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: Snake.
model 000060a0 00000481 00000000 00000000 773c7d2c 00000000 00000004 00000072 00000072
vers  0000000c
model 9000/715
ic_size 20000 dc_size 20000 it_size 40
DC  base 0x0 stride 0x20 count 0x1000 loop 0x1
dc_conf = 0x61402000  alias 6 blk 1 line 2 shift 0
        wt 0 sh 0 cst 1 hv 0
IC  base 0x0 stride 0x20 count 0x1000 loop 0x1
ic_conf = 0x61402000  alias 6 blk 1 line 2 shift 0
        wt 0 sh 0 cst 1 hv 0
D-TLB conf: sh 3 page 1 cst 1 aid 0 pad1 0
I-TLB conf: sh 3 page 1 cst 1 aid 0 pad1 0
Total Memory: 160 MB
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 40640
Kernel command line: HOME=/ root=/dev/sda5 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
allocated 327680 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Memory: 154772k/163840k available (4405k kernel code, 9068k reserved, 1968k data, 320k init)
virtual kernel memory layout:
    vmalloc : 0x00810000 - 0x0f000000   ( 231 MB)
    memory  : 0x10000000 - 0x1a000000   ( 160 MB)
      .init : 0x10788000 - 0x107d8000   ( 320 kB)
      .data : 0x1054d6c4 - 0x10739770   (1968 kB)
      .text : 0x10100000 - 0x1054d6c4   (4405 kB)
NR_IRQS:96
Console: colour dummy device 128x48
Calibrating delay loop... 63.48 BogoMIPS (lpj=317440)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys blkio
xor: measuring software checksum speed
   8regs     :    44.800 MB/sec
   8regs_prefetch:    44.800 MB/sec
   32regs    :    72.800 MB/sec
   32regs_prefetch:    72.800 MB/sec
xor: using function: 32regs_prefetch (72.800 MB/sec)
atomic64 test passed
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Found devices:
1. Mirage Jr GSC Builtin Graphics at 0xf8000000 [1] { 10, 0x0, 0x012, 0x00085 }
2. Mirage Jr Core BA at 0xf0100000 [2] { 11, 0x0, 0x028, 0x00081 }
3. Mirage Jr Core SCSI at 0xf0106000 [2/0/1] { 10, 0x0, 0x028, 0x00082 }
4. Mirage Jr Core LAN (802.3) at 0xf0107000 [2/0/2] { 10, 0x0, 0x028, 0x0008a }
5. Mirage Jr Core RS-232 at 0xf0105000 [2/0/4] { 10, 0x0, 0x028, 0x0008c }
6. Mirage Jr Core Centronics at 0xf0102000 [2/0/6] { 10, 0x0, 0x028, 0x00074 }
7. Mirage Jr Audio at 0xf0104000 [2/0/8] { 10, 0x0, 0x028, 0x0007b }
8. Mirage Jr Core PC Floppy at 0xf010a000 [2/0/10] { 10, 0x0, 0x028, 0x00083 }
9. Mirage Jr Core PS/2 Port at 0xf0108000 [2/0/11] { 10, 0x0, 0x028, 0x00084 }
10. Mirage Jr Core PS/2 Port at 0xf0108100 [2/0/12] { 10, 0x0, 0x028, 0x00084 }
11. Mirage Jr Wax EISA BA at 0xfc000000 [4] { 11, 0x0, 0x028, 0x00090 }
12. Mirage Jr Wax BA at 0xf0200000 [5] { 11, 0x0, 0x012, 0x0008e }
13. Mirage Jr Wax HIL at 0xf0201000 [5/0/1] { 10, 0x0, 0x012, 0x00073 }
14. Mirage Jr Wax RS-232 at 0xf0202000 [5/0/2] { 10, 0x0, 0x012, 0x0008c }
15. Mirage Jr (715/64) at 0xfffbe000 [8] { 0, 0x0, 0x60a, 0x00004 }
16. Memory at 0xfffbf000 [9] { 1, 0x0, 0x04a, 0x00009 }
CPU(s): 1 x PA7100LC (PCX-L) at 64.000000 MHz
Setting cache flush threshold to e0 (1 CPUs online)
Lasi version 0 at 0xf0100000 found.
LED display at f00e0000 registered
wax at 0xf0200000 found.
Wax EISA Adapter found at 0xfc000000
Enumerating EISA bus
EISA: Probing bus 0 at 4
EISA: Mainboard HWPC000 detected.
EISA: Detected 0 cards.
powersw: Gecko-style soft power switch enabled.
bio: create slab <bio-0> at 0
raid6: int32x1     26 MB/s
raid6: int32x2     29 MB/s
raid6: int32x4     33 MB/s
raid6: int32x8     21 MB/s
raid6: using algorithm int32x4 (33 MB/s)
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource cr16
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 128 (order: 0, 6144 bytes)
UDP-Lite hash table entries: 128 (order: 0, 6144 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Chassis warnings not supported.
Initializing RT-Tester: OK
====[ backtrace testing ]===========
Testing a backtrace from process context.
The following trace is a kernel self test and not a bug!
Backtrace:
 [<10119d14>] dump_stack+0x1c/0x2c
 [<1017d4ec>] backtrace_regression_test+0x44/0x124
 [<10117f48>] do_one_initcall+0x258/0x2b8
 [<1078a208>] kernel_init+0x184/0x214
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a backtrace from irq context.
The following trace is a kernel self test and not a bug!
Backtrace:
 [<10119d14>] dump_stack+0x1c/0x2c
 [<1017d488>] backtrace_test_irq_callback+0x18/0x38
 [<101399d0>] tasklet_action+0x78/0xdc
 [<10139f64>] __do_softirq+0x130/0x17c
 [<1013a020>] run_ksoftirqd+0x70/0x124
 [<10151484>] kthread+0xac/0xb4
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a saved backtrace.
The following trace is a kernel self test and not a bug!
 [<10123624>] save_stack_trace+0x28/0x60
 [<1017d598>] backtrace_regression_test+0xf0/0x124
 [<10117f48>] do_one_initcall+0x258/0x2b8
 [<1078a208>] kernel_init+0x184/0x214
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24
 [<ffffffff>] 0xffffffff
====[ end of backtrace testing ]====
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
msgmni has been set to 302
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
EISA EEPROM at 0x00810400
PDC Stable Storage facility v0.30
STI GSC/PCI core graphics driver Version 0.9a
    id 2b4ded6d-40a00499, conforms to spec rev. 8.04
    graphics card name: HPA208LC1024
sticon: Initializing STI text console.
Console: switching to colour STI console 128x48
Console: switching to colour frame buffer device 128x48
fb0: stifb 1024x768-8 frame buffer device, HPA208LC1024, id: 2b4ded6d, mmio: 0xf8100000
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
2:0:4: ttyS0 at MMIO 0xf0105800 (irq = 18) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
5:0:2: ttyS1 at MMIO 0xf0202800 (irq = 25) is a 16550A
Linux agpgart interface v0.103
parport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xf0102800, irq 19 [PCSPP,TRISTATE]
parport0: fix this legacy no-device port driver!
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
ide-cd driver 5.00
53c700: Version 2.8 By James.Bottomley@HansenPartnership.com
scsi0: 53c710 rev 2 
scsi0 : LASI SCSI 53c700
scsi 0:0:6:0: Direct-Access     QUANTUM  FIREBALL_TM3200S 300X PQ: 0 ANSI: 2
scsi target0:0:6: Beginning Domain Validation
scsi 0:0:6:0: Enabling Tag Command Queuing
scsi target0:0:6: asynchronous
scsi target0:0:6: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 8)
scsi target0:0:6: Domain Validation skipping write tests
scsi target0:0:6: Ending Domain Validation
st: Version 20101219, fixed bufsize 32768, s/g segs 256
sd 0:0:6:0: Attached scsi generic sg0 type 0
sd 0:0:6:0: [sda] 6281856 512-byte logical blocks: (3.21 GB/2.99 GiB)
LASI 82596 driver - Revision: 1.30
Found i82596 at 0xf0107000, IRQ 17
eth0: 82596 at 0xf0107000, 08:00:09:c2:9e:60 IRQ 17.
sd 0:0:6:0: [sda] Write Protect is off
sd 0:0:6:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
serio: gsc-ps2-keyboard port at 0x0081a000 irq 22 @ 2:0:11
serio: gsc-ps2-mouse port at 0x0081c100 irq 22 @ 2:0:12
mousedev: PS/2 mouse device common for all mice
rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid10 personality registered for level 10
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
device-mapper: uevent: version 1.0.3
 sda: sda1 sda2 sda3 < sda5 sda6 >
device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
sd 0:0:6:0: [sda] Attached SCSI disk
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using timer interrupt.
TCP: cubic registered
NET: Registered protocol family 17
rtc-generic rtc-generic: setting system clock to 1970-01-04 01:59:05 UTC (266345)
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 192.168.178.50, my address is 192.168.178.64
IP-Config: Complete:
     device=eth0, addr=192.168.178.64, mask=255.255.255.0, gw=192.168.178.1
     host=pa64, domain=box, nis-domain=(none)
     bootserver=192.168.178.50, rootserver=192.168.178.50, rootpath=
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sda5): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) readonly on device 8:5.
Freeing unused kernel memory: 320k freed
      _______________________________                                                                                                                                                                                                        
     < Your System ate a SPARC! Gah! >                                                                                                                                                                                                       
      -------------------------------                                                                                                                                                                                                        
             \   ^__^                                                                                                                                                                                                                        
                 (__)\       )\/\                                                                                                                                                                                                            
                  U  ||----w |                                                                                                                                                                                                               
                     ||     ||                                                                                                                                                                                                               
swapper (pid 1): Illegal instruction (code 8)                                                                                                                                                                                                
                                                                                                                                                                                                                                             
     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI                                                                                                                                                                                                        
PSW: 00000000000000000000000000000000 Not tainted                                                                                                                                                                                            
r00-03  00000000 00000001 101bc460 19c246c0                                                                                                                                                                                                  
r04-07  00000017 19e6a5f8 19c22db8 ffeffff1                                                                                                                                                                                                  
r08-11  0f2ff000 0f000000 00000033 fff00ff1                                                                                                                                                                                                  
r12-15  00000000 00000017 00000001 00000000                                                                                                                                                                                                  
r16-19  00000000 00000043 00000000 107e9a80                                                                                                                                                                                                  
r20-23  19c245c8 10957000 00000001 00000001                                                                                                                                                                                                  
r24-27  00000000 00000000 0000fa80 106e2020                                                                                                                                                                                                  
r28-31  0f2ff000 000094b9 19c24740 00009271                                                                                                                                                                                                  
sr00-03  00000000 00000001 00000000 00000000                                                                                                                                                                                                 
sr04-07  00000000 00000000 00000000 00000000                                                                                                                                                                                                 
                                                                                                                                                                                                                                             
IASQ: 00000000 00000000 IAOQ: 10101110 10101114                                                                                                                                                                                              
 IIR: 078112a0    ISR: 00000000  IOR: 0f2ff000                                                                                                                                                                                               
 CPU:        0   CR30: 19c24000 CR31: f00effff                                                                                                                                                                                               
 ORIG_R28: 19e84ffc                                                                                                                                                                                                                          
 IAOQ[0]: flush_dcache_page_asm+0x28/0x7c                                                                                                                                                                                                    
 IAOQ[1]: flush_dcache_page_asm+0x2c/0x7c                                                                                                                                                                                                    
 RP(r2): __get_user_pages+0x38c/0x3c4                                                                                                                                                                                                        
Backtrace:                                                                                                                                                                                                                                   
 [<101bc460>] __get_user_pages+0x38c/0x3c4                                                                                                                                                                                                   
 [<101bc580>] get_user_pages+0x50/0x60                                                                                                                                                                                                       
 [<101e1a1c>] get_arg_page+0x64/0xe8                                                                                                                                                                                                         
 [<101e1bac>] copy_strings+0x10c/0x248                                                                                                                                                                                                       
 [<101e1d10>] copy_strings_kernel+0x28/0x44                                                                                                                                                                                                  
 [<101e360c>] do_execve+0x2a0/0x36c                                                                                                                                                                                                          
 [<10120598>] sys_execve+0x44/0x7c                                                                                                                                                                                                           
 [<10104084>] __execve+0x20/0x34                                                                                                                                                                                                             
 [<10133d2c>] vprintk+0x1d8/0x4f4                                                                                                                                                                                                            
 [<10134078>] printk+0x30/0x40                                                                                                                                                                                                               
 [<10118550>] free_initmem+0x154/0x184                                                                                                                                                                                                       
 [<10117cbc>] init_post+0xa0/0xd4                                                                                                                                                                                                            
 [<1078a294>] kernel_init+0x210/0x214                                                                                                                                                                                                        
                                                                                                                                                                                                                                             
Backtrace:                                                                                                                                                                                                                                   
 [<10119d14>] dump_stack+0x1c/0x2c                                                                                                                                                                                                           
 [<1011a290>] die_if_kernel+0xc0/0x1c0                                                                                                                                                                                                       
 [<1011a988>] handle_interruption+0x324/0x6c4                                                                                                                                                                                                
 [<10105078>] intr_check_sig+0x0/0x34                                                                                                                                                                                                        
 [<101d78e0>] mem_cgroup_charge_common+0x50/0x6c                                                                                                                                                                                             
                                                                                                                                                                                                                                             
---[ end trace 47c58df5faf7bacb ]---                                                                                                                                                                                                         
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000bCommand line for kernel: 'HOME=/ root=/dev/sda5 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux'

[-- Attachment #3: b160L.log --]
[-- Type: text/plain, Size: 14552 bytes --]

Command line for kernel: 'HOME=/ root=/dev/sda5 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux'
Selected kernel: /vmlinux from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing 32-bit kernelELF32 executable
Entry 00100000 first 00100000 n 3
Segment 0 load 00100000 size 6549504 mediaptr 0x1000
Segment 1 load 00788000 size 176308 mediaptr 0x640000
Segment 2 load 007b4000 size 144916 mediaptr 0x66c000
Branching to kernel entry point 0x00100000.  If this is the last
message you see, you may need to switch your console.  This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.4.0-rc7-32bit+ (deller@p100) (gcc version 4.6.4 20120514 (prerelease) (GCC) ) #1 Mon May 14 23:10:09 CEST 2012
unwind_init: start = 0x10690000, end = 0x106d5190, entries = 17689
FP[0] enabled: Rev 1 Model 15
The 32-bit Kernel has started...
bootconsole [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: System Map.
model 00005020 00000481 00000000 02020202 7794d7fe 100000f0 00000004 000000ba 000000ba
vers  00000008
CPUID vers 15 rev 8 (0x000001e8)
capabilities 0x2
model 9000/778/B160L
ic_size 10000 dc_size 10000 it_size 60
DC  base 0x0 stride 0x20 count 0x400 loop 0x2
dc_conf = 0x41402000  alias 4 blk 1 line 2 shift 0
        wt 0 sh 0 cst 1 hv 0
IC  base 0x0 stride 0x20 count 0x400 loop 0x2
ic_conf = 0x41402000  alias 4 blk 1 line 2 shift 0
        wt 0 sh 0 cst 1 hv 0
D-TLB conf: sh 3 page 1 cst 1 aid 0 pad1 0
I-TLB conf: sh 3 page 1 cst 1 aid 0 pad1 0
Total Memory: 128 MB
LED display at f0190001 registered
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: HOME=/ root=/dev/sda5 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
allocated 262144 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Memory: 122460k/131072k available (4405k kernel code, 8612k reserved, 1968k data, 320k init)
virtual kernel memory layout:
    vmalloc : 0x00810000 - 0x0f000000   ( 231 MB)
    memory  : 0x10000000 - 0x18000000   ( 128 MB)
      .init : 0x10788000 - 0x107d8000   ( 320 kB)
      .data : 0x1054d6c4 - 0x10739770   (1968 kB)
      .text : 0x10100000 - 0x1054d6c4   (4405 kB)
NR_IRQS:96
Console: colour dummy device 128x48
Calibrating delay loop... 106.39 BogoMIPS (lpj=531968)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys blkio
xor: measuring software checksum speed
   8regs     :   130.800 MB/sec
   8regs_prefetch:   130.800 MB/sec
   32regs    :   198.400 MB/sec
   32regs_prefetch:   198.400 MB/sec
xor: using function: 32regs_prefetch (198.400 MB/sec)
atomic64 test passed
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Found devices:
1. Phantom PseudoBC GSC+ Port at 0xffc00000 [8] { 7, 0x0, 0x504, 0x00000 }
2. Dino PCI Bridge at 0xfff80000 [8/0] { 13, 0x3, 0x680, 0x0000a }
3. Merlin+ 132 Dino RS-232 at 0xfff83000 [8/0/63] { 10, 0x0, 0x022, 0x0008c }
4. Merlin 160 Core FW-SCSI at 0xfff8c000 [8/12] { 4, 0x0, 0x03d, 0x00089 }
5. Merlin 160 Core BA at 0xffd00000 [8/16] { 11, 0x0, 0x03d, 0x00081 }, additional addresses: 0xffd0c000 0xffc00000 
6. Merlin 160 Core RS-232 at 0xffd05000 [8/16/4] { 10, 0x0, 0x03d, 0x0008c }
7. Merlin 160 Core SCSI at 0xffd06000 [8/16/5] { 10, 0x0, 0x03d, 0x00082 }
8. Merlin 160 Core LAN (802.3) at 0xffd07000 [8/16/6] { 10, 0x0, 0x03d, 0x0008a }
9. Merlin 160 Core Centronics at 0xffd02000 [8/16/0] { 10, 0x0, 0x03d, 0x00074 }, additional addresses: 0xffd01000 0xffd03000 
10. Merlin 160 Core Audio at 0xffd04000 [8/16/1] { 10, 0x4, 0x03d, 0x0007b }
11. Merlin 160 Core PS/2 Port at 0xffd08000 [8/16/7] { 10, 0x0, 0x03d, 0x00084 }
12. Merlin 160 Core PS/2 Port at 0xffd08100 [8/16/8] { 10, 0x0, 0x03d, 0x00084 }
13. Coral SGC Graphics at 0xfa000000 [8/4] { 10, 0x0, 0x004, 0x00077 }
14. Coral SGC Graphics at 0xf4000000 [8/8] { 10, 0x0, 0x004, 0x00077 }
15. Gecko GSC Core Graphics at 0xf8000000 [8/24] { 10, 0x0, 0x016, 0x00085 }, additional addresses: 0xf0011000 
16. Merlin L2 160 (9000/778/B160L) at 0xfffbe000 [62] { 0, 0x0, 0x502, 0x00004 }
17. Memory at 0xfffbf000 [63] { 1, 0x0, 0x067, 0x00009 }
18. Merlin+ 132 Dino PS/2 Port at 0xfff81000 [1] { 10, 0x0, 0x022, 0x00096 }
CPU(s): 1 x PA7300LC (PCX-L2) at 160.000000 MHz
Setting cache flush threshold to 8a0 (1 CPUs online)
Lasi version 0 at 0xffd00000 found.
Dino version 3.1 found at 0xfff80000
Dino: No PCI devices enabled.
dino 8:0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
powersw: Soft power switch at 0xf0140000 enabled.
bio: create slab <bio-0> at 0
raid6: int32x1     60 MB/s
raid6: int32x2     71 MB/s
raid6: int32x4     85 MB/s
raid6: int32x8     61 MB/s
raid6: using algorithm int32x4 (85 MB/s)
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource cr16
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 4, 81920 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP: reno registered
UDP hash table entries: 128 (order: 0, 6144 bytes)
UDP-Lite hash table entries: 128 (order: 0, 6144 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Enabling PDC chassis warnings support v0.05
Initializing RT-Tester: OK
====[ backtrace testing ]===========
Testing a backtrace from process context.
The following trace is a kernel self test and not a bug!
Backtrace:
 [<10119d14>] dump_stack+0x1c/0x2c
 [<1017d4ec>] backtrace_regression_test+0x44/0x124
 [<10117f48>] do_one_initcall+0x258/0x2b8
 [<1078a208>] kernel_init+0x184/0x214
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a backtrace from irq context.
The following trace is a kernel self test and not a bug!
Backtrace:
 [<10119d14>] dump_stack+0x1c/0x2c
 [<1017d488>] backtrace_test_irq_callback+0x18/0x38
 [<101399d0>] tasklet_action+0x78/0xdc
 [<10139f64>] __do_softirq+0x130/0x17c
 [<1013a020>] run_ksoftirqd+0x70/0x124
 [<10151484>] kthread+0xac/0xb4
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a saved backtrace.
The following trace is a kernel self test and not a bug!
 [<10123624>] save_stack_trace+0x28/0x60
 [<1017d598>] backtrace_regression_test+0xf0/0x124
 [<10117f48>] do_one_initcall+0x258/0x2b8
 [<1078a208>] kernel_init+0x184/0x214
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24
 [<ffffffff>] 0xffffffff
====[ end of backtrace testing ]====
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
msgmni has been set to 239
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
PDC Stable Storage facility v0.30
STI GSC/PCI core graphics driver Version 0.9a
    id 2bcb015a-9a02587, conforms to spec rev. 8.04
    graphics card name: HPA4071B
    id 2d08c0a7-9a02587, conforms to spec rev. 8.07
    graphics card name: HPA4450AX1024
    id 2d08c0a7-9a02587, conforms to spec rev. 8.07
    graphics card name: INTERNAL_EG_X1024
sticon: Initializing STI text console.
Console: switching to colour STI console 160x64
Console: switching to colour frame buffer device 160x64
fb0: stifb 1280x1024-32 frame buffer device, HPA4071B, id: 2bcb015a, mmio: 0xfa100000
fb1: stifb 1024x768-8 frame buffer device, HPA4450AX1024, id: 2d08c0a7, mmio: 0xf4100000
fb2: stifb 1024x768-8 frame buffer device, INTERNAL_EG_X1024, id: 2d08c0a7, mmio: 0xf8100000
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
8:16:4: ttyS0 at MMIO 0xffd05800 (irq = 16) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
8:0:63: ttyS1 at MMIO 0xfff83800 (irq = 22) is a 16550A
Linux agpgart interface v0.103
parport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xffd02800, irq 19 [PCSPP,TRISTATE]
parport0: fix this legacy no-device port driver!
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
ide-cd driver 5.00
zalon_probe: Zalon version 1, IRQ 67
ncr53c720-0: rev 0xf irq 67
ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential
scsi0 : ncr53c8xx-3.4.3g
scsi 0:0:6:0: Direct-Access     SEAGATE  ST32171W         HP03 PQ: 0 ANSI: 2
scsi target0:0:6: Beginning Domain Validation
scsi target0:0:6: asynchronous
scsi target0:0:6: wide asynchronous
scsi target0:0:6: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8)
scsi target0:0:6: Domain Validation skipping write tests
scsi target0:0:6: Ending Domain Validation
53c700: Version 2.8 By James.Bottomley@HansenPartnership.com
scsi1: 53c710 rev 2 
scsi1 : LASI SCSI 53c700
scsi 1:0:1:0: CD-ROM            PHILIPS  PCA80SC          V3-0 PQ: 0 ANSI: 2
scsi target1:0:1: Beginning Domain Validation
scsi target1:0:1: asynchronous
scsi target1:0:1: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 8)
scsi target1:0:1: Domain Validation skipping write tests
scsi target1:0:1: Ending Domain Validation
st: Version 20101219, fixed bufsize 32768, s/g segs 256
sd 0:0:6:0: [sda] 4194685 512-byte logical blocks: (2.14 GB/2.00 GiB)
sd 0:0:6:0: [sda] Write Protect is off
sr0: scsi-1 drive
cdrom: Uniform CD-ROM driver Revision: 3.20
sd 0:0:6:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 0:0:6:0: Attached scsi generic sg0 type 0
sr 1:0:1:0: Attached scsi generic sg1 type 5
LASI 82596 driver - Revision: 1.30
Found i82596 at 0xffd07000, IRQ 18
eth0: 82596 at 0xffd07000, 08:00:09:ef:34:f5 IRQ 18.
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
serio: gsc-ps2-keyboard port at 0x0081a000 irq 21 @ 8:16:7
serio: gsc-ps2-mouse port at 0x0081c100 irq 21 @ 8:16:8
 sda: sda1 sda2 sda3 < sda5 sda6 >
mousedev: PS/2 mouse device common for all mice
rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid10 personality registered for level 10
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
device-mapper: uevent: version 1.0.3
sd 0:0:6:0: [sda] Attached SCSI disk
device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using timer interrupt.
TCP: cubic registered
NET: Registered protocol family 17
rtc-generic rtc-generic: setting system clock to 1987-04-14 10:58:29 UTC (545396309)
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 192.168.178.50, my address is 192.168.178.65
IP-Config: Complete:
     device=eth0, addr=192.168.178.65, mask=255.255.255.0, gw=192.168.178.1
     host=b160, domain=box, nis-domain=(none)
     bootserver=192.168.178.50, rootserver=192.168.178.50, rootpath=
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sda5): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) readonly on device 8:5.
Freeing unused kernel memory: 320k freed
      _______________________________ 
     < Your System ate a SPARC! Gah! >
      ------------------------------- 
             \   ^__^
                 (__)\       )\/\
                  U  ||----w |
                     ||     ||
swapper (pid 1): Illegal instruction (code 8)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000000000000000000000000 Not tainted
r00-03  00000000 00000001 101bc460 17c246c0
r04-07  00000017 17eaa5f8 17c22db8 ffeffff1
r08-11  0f2ff000 0f000000 00000033 fff00ff1
r12-15  00000000 00000017 00000001 00000000
r16-19  00000000 00000043 00000000 107e8a80
r20-23  17c245c8 108fc000 00000001 00000001
r24-27  00000000 00000000 0000fa80 106e2020
r28-31  0f2ff000 000074ee 17c24740 000072e6
sr00-03  00000000 00000001 00000000 00000000
sr04-07  00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 10101110 10101114
 IIR: 078112a0    ISR: 00000000  IOR: 0f2ff000
 CPU:        0   CR30: 17c24000 CR31: f0102978
 ORIG_R28: 17ec4ffc
 IAOQ[0]: flush_dcache_page_asm+0x28/0x7c
 IAOQ[1]: flush_dcache_page_asm+0x2c/0x7c
 RP(r2): __get_user_pages+0x38c/0x3c4
Backtrace:
 [<101bc460>] __get_user_pages+0x38c/0x3c4
 [<101bc580>] get_user_pages+0x50/0x60
 [<101e1a1c>] get_arg_page+0x64/0xe8
 [<101e1bac>] copy_strings+0x10c/0x248
 [<101e1d10>] copy_strings_kernel+0x28/0x44
 [<101e360c>] do_execve+0x2a0/0x36c
 [<10120598>] sys_execve+0x44/0x7c
 [<10104084>] __execve+0x20/0x34
 [<10133d2c>] vprintk+0x1d8/0x4f4
 [<10134078>] printk+0x30/0x40
 [<10118550>] free_initmem+0x154/0x184
 [<10117cbc>] init_post+0xa0/0xd4
 [<1078a294>] kernel_init+0x210/0x214

Backtrace:
 [<10119d14>] dump_stack+0x1c/0x2c
 [<1011a290>] die_if_kernel+0xc0/0x1c0
 [<1011a988>] handle_interruption+0x324/0x6c4
 [<10105078>] intr_check_sig+0x0/0x34
 [<101d78e0>] mem_cgroup_charge_common+0x50/0x6c
 [<101bc440>] __get_user_pages+0x36c/0x3c4
 [<101bc580>] get_user_pages+0x50/0x60
 [<101e1a1c>] get_arg_page+0x64/0xe8
 [<101e1bac>] copy_strings+0x10c/0x248
 [<101e1d10>] copy_strings_kernel+0x28/0x44
 [<101e360c>] do_execve+0x2a0/0x36c
 [<10120598>] sys_execve+0x44/0x7c
 [<10104084>] __execve+0x20/0x34
 [<10133d2c>] vprintk+0x1d8/0x4f4
 [<10134078>] printk+0x30/0x40
 [<10118550>] free_initmem+0x154/0x184

---[ end trace 3da5cee95bb8512d ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b


[-- Attachment #4: c3000.log --]
[-- Type: text/plain, Size: 15133 bytes --]

Command line for kernel: 'HOME=/ root=/dev/sda3 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux'
Selected kernel: /vmlinux from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... 
This box can boot either 32 or 64-bit kernels...Only see a 32-bit kernel, using thatELF32 executable
Entry 00100000 first 00100000 n 3
Segment 0 load 00100000 size 6549504 mediaptr 0x1000
Segment 1 load 00788000 size 176308 mediaptr 0x640000
Segment 2 load 007b4000 size 144916 mediaptr 0x66c000
Branching to kernel entry point 0x00100000.  If this is the last
message you see, you may need to switch your console.  This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.4.0-rc7-32bit+ (deller@p100) (gcc version 4.6.4 20120514 (prerelease) (GCC) ) #1 Mon May 14 23:10:09 CEST 2012
unwind_init: start = 0x10690000, end = 0x106d5190, entries = 17689
FP[0] enabled: Rev 1 Model 19
The 32-bit Kernel has started...
bootconsole [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: System Map.
model 00005dc0 00000481 00000000 00000002 777c3e84 100000f0 00000008 000000b2 000000b2
vers  00000301
CPUID vers 19 rev 11 (0x0000026b)
capabilities 0x7
model 9000/785/C3700
ic_size c0000 dc_size 180000 it_size f0
DC  base 0x0 stride 0x40 count 0x6000 loop 0x1
dc_conf = 0xb1802000  alias 11 blk 1 line 4 shift 0
        wt 0 sh 0 cst 1 hv 0
IC  base 0x20000 stride 0x40 count 0xc00 loop 0x1
ic_conf = 0x91802000  alias 9 blk 1 line 4 shift 0
        wt 0 sh 0 cst 1 hv 0
D-TLB conf: sh 3 page 1 cst 1 aid 0 pad1 0
I-TLB conf: sh 3 page 1 cst 1 aid 3 pad1 0
Total Memory: 2048 MB
LCD display at f05d0008,f05d0000 registered
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 520192
Kernel command line: HOME=/ root=/dev/sda3 pa64root=sda5 ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
allocated 4194304 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Memory: 2065892k/2097152k available (4405k kernel code, 31260k reserved, 1968k data, 320k init)
virtual kernel memory layout:
    vmalloc : 0x00008000 - 0x0f000000   ( 239 MB)
    memory  : 0x10000000 - 0x90000000   (2048 MB)
      .init : 0x10788000 - 0x107d8000   ( 320 kB)
      .data : 0x1054d6c4 - 0x10739770   (1968 kB)
      .text : 0x10100000 - 0x1054d6c4   (4405 kB)
NR_IRQS:96
Console: colour dummy device 128x48
Calibrating delay loop... 1495.85 BogoMIPS (lpj=7479296)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys blkio
xor: measuring software checksum speed
   8regs     :  1749.200 MB/sec
   8regs_prefetch:  1727.600 MB/sec
   32regs    :  1446.400 MB/sec
   32regs_prefetch:  1436.800 MB/sec
xor: using function: 8regs (1749.200 MB/sec)
atomic64 test passed
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Found devices:
1. Astro BC Runway Port at 0xfed00000 [10] { 12, 0x0, 0x582, 0x0000b }
2. Elroy PCI Bridge at 0xfed30000 [10/0] { 13, 0x0, 0x782, 0x0000a }
3. Elroy PCI Bridge at 0xfed32000 [10/1] { 13, 0x0, 0x782, 0x0000a }
4. Elroy PCI Bridge at 0xfed38000 [10/4] { 13, 0x0, 0x782, 0x0000a }
5. Elroy PCI Bridge at 0xfed3c000 [10/6] { 13, 0x0, 0x782, 0x0000a }
6. Allegro W2 at 0xfffa0000 [32] { 0, 0x0, 0x5dc, 0x00004 }
7. Memory at 0xfed10200 [49] { 1, 0x0, 0x09c, 0x00009 }
CPU(s): 1 x PA8700 (PCX-W2) at 750.000000 MHz
Setting cache flush threshold to 8a0 (1 CPUs online)
SBA found Astro 2.1 at 0xfed00000
Elroy version TR4.0 (0x5) found at 0xfed30000
LBA 10:0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0x1fff]
pci_bus 0000:00: root bus resource [mem 0xf2000000-0xf23fffff]
PCI: Enabled native mode for NS87415 (pif=0x8f)
Elroy version TR4.0 (0x5) found at 0xfed32000
LBA 10:1: PCI host bridge to bus 0000:01
pci_bus 0000:01: root bus resource [io  0x12000-0x13fff] (bus address [0x2000-0x3fff])
pci_bus 0000:01: root bus resource [mem 0xf6000000-0xf6ffffff]
pci_bus 0000:01: root bus resource [mem 0xf2400000-0xf27fffff]
pci 0000:01:04.0: no compatible bridge window for [mem 0xf6000000-0xf7ffffff]
iosapic: no IRTE for 0000:01:04.0 (IRQ not connected?)
pci 0000:01:05.0: no compatible bridge window for [mem 0xf8000000-0xf8ffffff pref]
iosapic: no IRTE for 0000:01:05.0 (IRQ not connected?)
pci 0000:01:06.0: PCI bridge to [bus 02-ff]
pci 0000:01:06.0: can't handle 64-bit address space for bridge
pci 0000:01:06.0: no compatible bridge window for [??? 0x00000000 flags 0x0]
pci 0000:01:06.0: no compatible bridge window for [mem 0xf9000000-0xfbffffff]
pci 0000:01:06.0: no compatible bridge window for [??? 0x00000000 flags 0x0]
pci 0000:01:06.0: no compatible bridge window for [??? 0x00000000 flags 0x0]
pci 0000:01:06.0: device not available (can't reserve [mem 0xf9000000-0xfbffffff])
pci 0000:01:06.0: Error enabling bridge (-22), continuing
Elroy version TR4.0 (0x5) found at 0xfed38000
LBA 10:4: PCI host bridge to bus 0000:03
pci_bus 0000:03: root bus resource [io  0x28000-0x29fff] (bus address [0x8000-0x9fff])
pci_bus 0000:03: root bus resource [mem 0xf3000000-0xf33fffff]
Elroy version TR4.0 (0x5) found at 0xfed3c000
LBA 10:6: PCI host bridge to bus 0000:04
pci_bus 0000:04: root bus resource [io  0x3c000-0x3dfff] (bus address [0xc000-0xdfff])
pci_bus 0000:04: root bus resource [mem 0xf4000000-0xf5ffffff]
pci_bus 0000:04: root bus resource [mem 0xf3800000-0xf3bfffff]
iosapic: hpa not registered for 0000:04:02.0
powersw: Soft power switch at 0xf0400804 enabled.
bio: create slab <bio-0> at 0
raid6: int32x1    393 MB/s
raid6: int32x2    481 MB/s
raid6: int32x4    524 MB/s
raid6: int32x8    477 MB/s
raid6: using algorithm int32x4 (524 MB/s)
vgaarb: device added: PCI:0000:02:00.0,decodes=io+mem,owns=none,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:02:00.0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource cr16
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 8, 1310720 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP: reno registered
UDP hash table entries: 1024 (order: 3, 49152 bytes)
UDP-Lite hash table entries: 1024 (order: 3, 49152 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
SuperIO: Found NS87560 Legacy I/O device at 0000:00:0e.1 (IRQ 67)
SuperIO: Serial port 1 at 0x3f8
SuperIO: Serial port 2 at 0x2f8
SuperIO: Parallel port at 0x378
SuperIO: Floppy controller at 0x3f0
SuperIO: ACPI at 0x7e0
SuperIO: USB regulator enabled
Enabling PDC chassis warnings support v0.05
Initializing RT-Tester: OK
====[ backtrace testing ]===========
Testing a backtrace from process context.
The following trace is a kernel self test and not a bug!
Backtrace:
 [<10119d14>] dump_stack+0x1c/0x2c
 [<1017d4ec>] backtrace_regression_test+0x44/0x124
 [<10117f48>] do_one_initcall+0x258/0x2b8
 [<1078a208>] kernel_init+0x184/0x214
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a backtrace from irq context.
The following trace is a kernel self test and not a bug!
Backtrace:
 [<10119d14>] dump_stack+0x1c/0x2c
 [<1017d488>] backtrace_test_irq_callback+0x18/0x38
 [<101399d0>] tasklet_action+0x78/0xdc
 [<10139f64>] __do_softirq+0x130/0x17c
 [<1013a020>] run_ksoftirqd+0x70/0x124
 [<10151484>] kthread+0xac/0xb4
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a saved backtrace.
The following trace is a kernel self test and not a bug!
 [<10123624>] save_stack_trace+0x28/0x60
 [<1017d598>] backtrace_regression_test+0xf0/0x124
 [<10117f48>] do_one_initcall+0x258/0x2b8
 [<1078a208>] kernel_init+0x184/0x214
 [<1010405c>] ret_from_kernel_thread+0x1c/0x24
 [<ffffffff>] 0xffffffff
====[ end of backtrace testing ]====
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
msgmni has been set to 4034
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
PDC Stable Storage facility v0.30
STI GSC/PCI core graphics driver Version 0.9a
sti 0000:01:04.0: device not available (can't reserve [mem 0xf6000000-0xf7ffffff])
sti 0000:01:04.0: Cannot enable PCI device
sti: probe of 0000:01:04.0 failed with error -22
STI PCI graphic ROM found at f3800000 (2048 kB), fb at f4000000 (32 MB)
    id 35acda30-9a02587, conforms to spec rev. 8.0d
    graphics card name: A1262A
sticon: Initializing STI text console.
Console: switching to colour STI console 128x48
matroxfb 0000:02:00.0: enabling SERR and PARITY (0007 -> 0147)
matroxfb: Matrox G450 detected
PInS memtype = 4
matroxfb: cannot determine memory size
matroxfb: probe of 0000:02:00.0 failed with error -1
stifb: 'A1262A' (id: 0x35acda30) not supported.
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 3) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
serial8250: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
Linux agpgart interface v0.103
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
ns87415 0000:00:0e.0: IDE controller (0x100b:0x0002 rev 0x03)
ns87415 0000:00:0e.0: 100% native mode on irq 7
    ide0: BM-DMA at 0x0a00-0x0a07
    ide1: BM-DMA at 0x0a08-0x0a0f
hda: CD-532E-B, ATAPI CD/DVD-ROM drive
ide0 at 0xf00-0xf07,0xe02 on irq 7
ide1 at 0xd00-0xd07,0xb02 on irq 7
ide-gd driver 1.18
ide-cd driver 5.00
ide-cd: hda: ATAPI 32X CD-ROM drive, 128kB Cache
cdrom: Uniform CD-ROM driver Revision: 3.20
sym0: <896> rev 0x7 at pci 0000:00:0f.0 irq 68
sym0: PA-RISC Firmware, ID 7, Fast-40, SE, parity checking
sym0: SCSI BUS has been reset.
sym0: SCSI BUS mode change from SE to SE.
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.3
sym1: <896> rev 0x7 at pci 0000:00:0f.1 irq 68
sym1: PA-RISC Firmware, ID 7, Fast-40, LVD, parity checking
sym1: SCSI BUS has been reset.
scsi1 : sym-2.2.3
scsi 1:0:5:0: Direct-Access     SEAGATE  ST39102LC        HP01 PQ: 0 ANSI: 2
scsi target1:0:5: tagged command queuing enabled, command queue depth 16.
scsi target1:0:5: Beginning Domain Validation
scsi target1:0:5: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 15)
scsi target1:0:5: Domain Validation skipping write tests
scsi target1:0:5: Ending Domain Validation
scsi 1:0:6:0: Direct-Access     HP 36.4G ST336607LC       HPC3 PQ: 0 ANSI: 3
scsi target1:0:6: tagged command queuing enabled, command queue depth 16.
scsi target1:0:6: Beginning Domain Validation
scsi target1:0:6: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
scsi target1:0:6: Domain Validation skipping write tests
scsi target1:0:6: Ending Domain Validation
st: Version 20101219, fixed bufsize 32768, s/g segs 256
sd 1:0:5:0: Attached scsi generic sg0 type 0
sd 1:0:6:0: Attached scsi generic sg1 type 0
Linux Tulip driver version 1.1.15 (Feb 27, 2007)
tulip0: no phy info, aborting mtable build
tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1
net eth0: Digital DS21142/43 Tulip rev 65 at Port 0x1000, 00:30:6e:48:aa:64, IRQ 65
tulip1: EEPROM default media type Autosense
tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block
tulip1: Index #1 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block
tulip1: Index #2 - Media AUI (#2) described by a 21142 Serial PHY (2) block
tulip1:  MII transceiver #1 config 3100 status 7849 advertising 0101
sd 1:0:5:0: [sda] 17773524 512-byte logical blocks: (9.10 GB/8.47 GiB)
sd 1:0:6:0: [sdb] 71132960 512-byte logical blocks: (36.4 GB/33.9 GiB)
sd 1:0:5:0: [sda] Write Protect is off
sd 1:0:6:0: [sdb] Write Protect is off
net eth1: Digital DS21142/43 Tulip rev 33 at Port 0x28000, 00:60:b0:7a:12:89, IRQ 71
LASI 82596 driver - Revision: 1.30
sd 1:0:5:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 1:0:6:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:0e.2: OHCI Host Controller
ohci_hcd 0000:00:0e.2: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:0e.2: irq 1, io mem 0xf2007000
 sda: sda1 sda2 sda3 sda4
 sdb: sdb1 sdb2 sdb3 sdb4
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: OHCI Host Controller
usb usb1: Manufacturer: Linux 3.4.0-rc7-32bit+ ohci_hcd
usb usb1: SerialNumber: 0000:00:0e.2
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
uhci_hcd: USB Universal Host Controller Interface driver
mousedev: PS/2 mouse device common for all mice
sd 1:0:6:0: [sdb] Attached SCSI disk
sd 1:0:5:0: [sda] Attached SCSI disk
rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid10 personality registered for level 10
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using timer interrupt.
TCP: cubic registered
NET: Registered protocol family 17
rtc-generic rtc-generic: setting system clock to 2012-05-14 21:31:39 UTC (1337031099)
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 192.168.178.50, my address is 192.168.178.66
IP-Config: Complete:
     device=eth0, addr=192.168.178.66, mask=255.255.255.0, gw=192.168.178.1
     host=c3000, domain=box, nis-domain=(none)
     bootserver=192.168.178.50, rootserver=192.168.178.50, rootpath=
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sda3): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) readonly on device 8:3.
Freeing unused kernel memory: 320k freed
modprobe: FATAL: Could not load /lib/modules/3.4.0-rc7-32bit+/modules.dep: No such file or directory

INIT: version 2.88 booting

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-14 22:11             ` Helge Deller
@ 2012-05-14 22:38               ` John David Anglin
  2012-05-14 22:55                 ` John David Anglin
  2012-05-15  8:09                 ` James Bottomley
  2012-05-15  8:06               ` James Bottomley
  1 sibling, 2 replies; 56+ messages in thread
From: John David Anglin @ 2012-05-14 22:38 UTC (permalink / raw)
  To: Helge Deller; +Cc: Vincent, Rolf Eike Beer, linux-parisc

On 14-May-12, at 6:11 PM, Helge Deller wrote:

> The B160L and the 715/64 (both 32bit-only PA1.X machines) crashed  
> with the following trace.
> All logs attached.
>
> Any ideas?

This is exactly the same failure as reported by Vincent.

The most likely problem is the PA 1.1 tmpalias support in entry.S is  
broken.  For example,
the cache stride that is loaded in flush_dcache_page_asm to register  
r1 is wrong.  Probably,
the do_alias macro is wrong for PA 1.1.  This is hunk of code that  
should be executed
when a fdc non access fault occurs.

nadtlb_check_alias_11:
         do_alias        spc,t0,t1,va,pte,prot,nadtlb_emulate

         idtlba          pte,(va)
         idtlbp          prot,(va)

         rfir
         nop

The TLB insert instructions on PA 1.1 have a different format than on  
PA 2.0.  I'm not sure
how this would corrupt r1.

On the other hand, I had asked Vincent to put a "b,n ." instruction  
just before the fdc loop,
boot, hit the TOC button, and capture the setup registers for the  
flush operation.  It's possible
the stride variable has been clobbered.

Dave

--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-14 22:38               ` John David Anglin
@ 2012-05-14 22:55                 ` John David Anglin
  2012-05-15  8:09                 ` James Bottomley
  1 sibling, 0 replies; 56+ messages in thread
From: John David Anglin @ 2012-05-14 22:55 UTC (permalink / raw)
  To: John David Anglin; +Cc: Helge Deller, Vincent, Rolf Eike Beer, linux-parisc

In particular, compare below to what happens in a normal non access  
fault:

nadtlb_miss_11:
        get_pgd         spc,ptp

        space_check     spc,t0,nadtlb_fault

        L2_ptep         ptp,pte,t0,va,nadtlb_check_alias_11

        update_ptep     ptp,pte,t0,t1

        make_insert_tlb_11      spc,pte,prot


        mfsp            %sr1,t0  /* Save sr1 so we can use it in tlb  
inserts */
        mtsp            spc,%sr1

        idtlba          pte,(%sr1,va)
        idtlbp          prot,(%sr1,va)

        mtsp            t0, %sr1        /* Restore sr1 */

        rfir
        nop

On 14-May-12, at 6:38 PM, John David Anglin wrote:

> On 14-May-12, at 6:11 PM, Helge Deller wrote:
>
>> The B160L and the 715/64 (both 32bit-only PA1.X machines) crashed  
>> with the following trace.
>> All logs attached.
>>
>> Any ideas?
>
> This is exactly the same failure as reported by Vincent.
>
> The most likely problem is the PA 1.1 tmpalias support in entry.S is  
> broken.  For example,
> the cache stride that is loaded in flush_dcache_page_asm to register  
> r1 is wrong.  Probably,
> the do_alias macro is wrong for PA 1.1.  This is hunk of code that  
> should be executed
> when a fdc non access fault occurs.
>
> nadtlb_check_alias_11:
>        do_alias        spc,t0,t1,va,pte,prot,nadtlb_emulate
>
>        idtlba          pte,(va)
>        idtlbp          prot,(va)
>
>        rfir
>        nop
>
> The TLB insert instructions on PA 1.1 have a different format than  
> on PA 2.0.  I'm not sure
> how this would corrupt r1.
>
> On the other hand, I had asked Vincent to put a "b,n ." instruction  
> just before the fdc loop,
> boot, hit the TOC button, and capture the setup registers for the  
> flush operation.  It's possible
> the stride variable has been clobbered.
>
> Dave
>
> --
> John David Anglin	dave.anglin@bell.net
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> parisc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-14 22:11             ` Helge Deller
  2012-05-14 22:38               ` John David Anglin
@ 2012-05-15  8:06               ` James Bottomley
  1 sibling, 0 replies; 56+ messages in thread
From: James Bottomley @ 2012-05-15  8:06 UTC (permalink / raw)
  To: Helge Deller; +Cc: John David Anglin, Vincent, Rolf Eike Beer, linux-parisc

On Tue, 2012-05-15 at 00:11 +0200, Helge Deller wrote:
> On 05/14/2012 03:10 AM, John David Anglin wrote:
> > I had a successful bot of 3.4.0-rc7+ this evening.
> >
> > I updated my running kernel patch to 3.4.  The futex patch is removed 
> > and Srivatsa S. Bhat's
> > patch added.
> 
> Ok, I applied your patch now.
> I used latest binutils and (as suggested by Dave) gcc-4.6 branch.
> I built Kernel 3.4.0-rc7 as 32bit-binary for my c3000, b160L and 715/64.
> 
> The c3000 booted nicely into userspace.
> 
> The B160L and the 715/64 (both 32bit-only PA1.X machines) crashed with 
> the following trace.
> All logs attached.
> 
> Any ideas?

Yes, I'm fairly certain there's a non-PA 1.0 instruction in the TLB
insertion code path.  The reason I didn't see it is that all the systems
I boot 32 bit kernels on have PA2.0 processors, so even in 32 bit mode,
they won't trip over an illegal 1.0 instruction.  The backtrace is bogus
because the actual problem is in the interruption after all of the trace
information is saved.  I'll see if I can get the system to trigger a
HPMC or TOC to get the actual location of the problem in the
interruption path.

I've finally got my systems, so just unpacking and setting them up now.

James



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-14 22:38               ` John David Anglin
  2012-05-14 22:55                 ` John David Anglin
@ 2012-05-15  8:09                 ` James Bottomley
  2012-05-15  9:13                   ` James Bottomley
  1 sibling, 1 reply; 56+ messages in thread
From: James Bottomley @ 2012-05-15  8:09 UTC (permalink / raw)
  To: John David Anglin; +Cc: Helge Deller, Vincent, Rolf Eike Beer, linux-parisc

On Mon, 2012-05-14 at 18:38 -0400, John David Anglin wrote:
> On 14-May-12, at 6:11 PM, Helge Deller wrote:
> 
> > The B160L and the 715/64 (both 32bit-only PA1.X machines) crashed  
> > with the following trace.
> > All logs attached.
> >
> > Any ideas?
> 
> This is exactly the same failure as reported by Vincent.
> 
> The most likely problem is the PA 1.1 tmpalias support in entry.S is  
> broken.  For example,
> the cache stride that is loaded in flush_dcache_page_asm to register  
> r1 is wrong.  Probably,
> the do_alias macro is wrong for PA 1.1.  This is hunk of code that  
> should be executed
> when a fdc non access fault occurs.
> 
> nadtlb_check_alias_11:
>          do_alias        spc,t0,t1,va,pte,prot,nadtlb_emulate
> 
>          idtlba          pte,(va)
>          idtlbp          prot,(va)
> 
>          rfir
>          nop
> 
> The TLB insert instructions on PA 1.1 have a different format than on  
> PA 2.0.  I'm not sure
> how this would corrupt r1.
> 
> On the other hand, I had asked Vincent to put a "b,n ." instruction  
> just before the fdc loop,
> boot, hit the TOC button, and capture the setup registers for the  
> flush operation.  It's possible
> the stride variable has been clobbered.

Actually, I don't think it's that.  I built a PA 1.1 only kernel and
booted it successfully on the C360.  That exercises all the _11 paths,
so I don't think there's a code fault.  I do think there's a non PA1.1
instruction in there somewhere that the C360 wouldn't notice.

James



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15  8:09                 ` James Bottomley
@ 2012-05-15  9:13                   ` James Bottomley
  2012-05-15 18:23                     ` John David Anglin
  2012-05-15 21:01                     ` Vincent
  0 siblings, 2 replies; 56+ messages in thread
From: James Bottomley @ 2012-05-15  9:13 UTC (permalink / raw)
  To: John David Anglin; +Cc: Helge Deller, Vincent, Rolf Eike Beer, linux-parisc

On Tue, 2012-05-15 at 09:09 +0100, James Bottomley wrote:
> On Mon, 2012-05-14 at 18:38 -0400, John David Anglin wrote:
> > On 14-May-12, at 6:11 PM, Helge Deller wrote:
> > 
> > > The B160L and the 715/64 (both 32bit-only PA1.X machines) crashed  
> > > with the following trace.
> > > All logs attached.
> > >
> > > Any ideas?
> > 
> > This is exactly the same failure as reported by Vincent.
> > 
> > The most likely problem is the PA 1.1 tmpalias support in entry.S is  
> > broken.  For example,
> > the cache stride that is loaded in flush_dcache_page_asm to register  
> > r1 is wrong.  Probably,
> > the do_alias macro is wrong for PA 1.1.  This is hunk of code that  
> > should be executed
> > when a fdc non access fault occurs.
> > 
> > nadtlb_check_alias_11:
> >          do_alias        spc,t0,t1,va,pte,prot,nadtlb_emulate
> > 
> >          idtlba          pte,(va)
> >          idtlbp          prot,(va)
> > 
> >          rfir
> >          nop
> > 
> > The TLB insert instructions on PA 1.1 have a different format than on  
> > PA 2.0.  I'm not sure
> > how this would corrupt r1.
> > 
> > On the other hand, I had asked Vincent to put a "b,n ." instruction  
> > just before the fdc loop,
> > boot, hit the TOC button, and capture the setup registers for the  
> > flush operation.  It's possible
> > the stride variable has been clobbered.
> 
> Actually, I don't think it's that.  I built a PA 1.1 only kernel and
> booted it successfully on the C360.  That exercises all the _11 paths,
> so I don't think there's a code fault.  I do think there's a non PA1.1
> instruction in there somewhere that the C360 wouldn't notice.

OK, I think this is the problem.  We have a depd instruction in do_alias
which is now in the _11 fault paths.

This should be the fix, if someone wants to test it before I can get
around to building it.

James

---

diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
index 6f05944..5350342 100644
--- a/arch/parisc/kernel/entry.S
+++ b/arch/parisc/kernel/entry.S
@@ -581,7 +581,11 @@
 	 */
 	cmpiclr,=	0x01,\tmp,%r0
 	ldi		(_PAGE_DIRTY|_PAGE_READ|_PAGE_WRITE),\prot
+#ifdef CONFIG_64BIT
 	depd,z		\prot,8,7,\prot
+#else
+	depw,z		\prot,8,7,\prot
+#endif
 	/*
 	 * OK, it is in the temp alias region, check whether "from" or "to".
 	 * Check "subtle" note in pacache.S re: r23/r26.



^ permalink raw reply related	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15  9:13                   ` James Bottomley
@ 2012-05-15 18:23                     ` John David Anglin
  2012-05-15 18:50                       ` Helge Deller
  2012-05-15 19:09                       ` James Bottomley
  2012-05-15 21:01                     ` Vincent
  1 sibling, 2 replies; 56+ messages in thread
From: John David Anglin @ 2012-05-15 18:23 UTC (permalink / raw)
  To: James Bottomley; +Cc: Helge Deller, Vincent, Rolf Eike Beer, linux-parisc

On 5/15/2012 5:13 AM, James Bottomley wrote:
> On Tue, 2012-05-15 at 09:09 +0100, James Bottomley wrote:
>> On Mon, 2012-05-14 at 18:38 -0400, John David Anglin wrote:
>>> On 14-May-12, at 6:11 PM, Helge Deller wrote:
>>>
>>>> The B160L and the 715/64 (both 32bit-only PA1.X machines) crashed
>>>> with the following trace.
>>>> All logs attached.
>>>>
>>>> Any ideas?
>>> This is exactly the same failure as reported by Vincent.
>>>
>>> The most likely problem is the PA 1.1 tmpalias support in entry.S is
>>> broken.  For example,
>>> the cache stride that is loaded in flush_dcache_page_asm to register
>>> r1 is wrong.  Probably,
>>> the do_alias macro is wrong for PA 1.1.  This is hunk of code that
>>> should be executed
>>> when a fdc non access fault occurs.
>>>
>>> nadtlb_check_alias_11:
>>>           do_alias        spc,t0,t1,va,pte,prot,nadtlb_emulate
>>>
>>>           idtlba          pte,(va)
>>>           idtlbp          prot,(va)
>>>
>>>           rfir
>>>           nop
>>>
>>> The TLB insert instructions on PA 1.1 have a different format than on
>>> PA 2.0.  I'm not sure
>>> how this would corrupt r1.
>>>
>>> On the other hand, I had asked Vincent to put a "b,n ." instruction
>>> just before the fdc loop,
>>> boot, hit the TOC button, and capture the setup registers for the
>>> flush operation.  It's possible
>>> the stride variable has been clobbered.
>> Actually, I don't think it's that.  I built a PA 1.1 only kernel and
>> booted it successfully on the C360.  That exercises all the _11 paths,
>> so I don't think there's a code fault.  I do think there's a non PA1.1
>> instruction in there somewhere that the C360 wouldn't notice.
> OK, I think this is the problem.  We have a depd instruction in do_alias
> which is now in the _11 fault paths.
>
> This should be the fix, if someone wants to test it before I can get
> around to building it.
>
> James
>
> ---
>
> diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
> index 6f05944..5350342 100644
> --- a/arch/parisc/kernel/entry.S
> +++ b/arch/parisc/kernel/entry.S
> @@ -581,7 +581,11 @@
>   	 */
>   	cmpiclr,=	0x01,\tmp,%r0
>   	ldi		(_PAGE_DIRTY|_PAGE_READ|_PAGE_WRITE),\prot
> +#ifdef CONFIG_64BIT
>   	depd,z		\prot,8,7,\prot
> +#else
> +	depw,z		\prot,8,7,\prot
> +#endif
>   	/*
>   	 * OK, it is in the temp alias region, check whether "from" or "to".
>   	 * Check "subtle" note in pacache.S re: r23/r26.
Better check that this fix doesn't break 32-bit PA 2.0 as the seven bit 
are now being deposited
in a different place.

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 18:23                     ` John David Anglin
@ 2012-05-15 18:50                       ` Helge Deller
  2012-05-15 19:24                         ` John David Anglin
  2012-05-15 19:52                         ` James Bottomley
  2012-05-15 19:09                       ` James Bottomley
  1 sibling, 2 replies; 56+ messages in thread
From: Helge Deller @ 2012-05-15 18:50 UTC (permalink / raw)
  To: John David Anglin; +Cc: James Bottomley, Vincent, Rolf Eike Beer, linux-parisc

On 05/15/2012 08:23 PM, John David Anglin wrote:
> On 5/15/2012 5:13 AM, James Bottomley wrote:
>> On Tue, 2012-05-15 at 09:09 +0100, James Bottomley wrote:
>>> On Mon, 2012-05-14 at 18:38 -0400, John David Anglin wrote:
>>>> On 14-May-12, at 6:11 PM, Helge Deller wrote:
>>>>
>>>>> The B160L and the 715/64 (both 32bit-only PA1.X machines) crashed
>>>>> with the following trace.
>>>>> All logs attached.
>>>>>
>>>>> Any ideas?
>>>> This is exactly the same failure as reported by Vincent.
>>>>
>>>> The most likely problem is the PA 1.1 tmpalias support in entry.S is
>>>> broken.  For example,
>>>> the cache stride that is loaded in flush_dcache_page_asm to register
>>>> r1 is wrong.  Probably,
>>>> the do_alias macro is wrong for PA 1.1.  This is hunk of code that
>>>> should be executed
>>>> when a fdc non access fault occurs.
>>>>
>>>> nadtlb_check_alias_11:
>>>>           do_alias        spc,t0,t1,va,pte,prot,nadtlb_emulate
>>>>
>>>>           idtlba          pte,(va)
>>>>           idtlbp          prot,(va)
>>>>
>>>>           rfir
>>>>           nop
>>>>
>>>> The TLB insert instructions on PA 1.1 have a different format than on
>>>> PA 2.0.  I'm not sure
>>>> how this would corrupt r1.
>>>>
>>>> On the other hand, I had asked Vincent to put a "b,n ." instruction
>>>> just before the fdc loop,
>>>> boot, hit the TOC button, and capture the setup registers for the
>>>> flush operation.  It's possible
>>>> the stride variable has been clobbered.
>>> Actually, I don't think it's that.  I built a PA 1.1 only kernel and
>>> booted it successfully on the C360.  That exercises all the _11 paths,
>>> so I don't think there's a code fault.  I do think there's a non PA1.1
>>> instruction in there somewhere that the C360 wouldn't notice.
>> OK, I think this is the problem.  We have a depd instruction in do_alias
>> which is now in the _11 fault paths.
>>
>> This should be the fix, if someone wants to test it before I can get
>> around to building it.
>>
>> James
>>
>> ---
>>
>> diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
>> index 6f05944..5350342 100644
>> --- a/arch/parisc/kernel/entry.S
>> +++ b/arch/parisc/kernel/entry.S
>> @@ -581,7 +581,11 @@
>>        */
>>       cmpiclr,=    0x01,\tmp,%r0
>>       ldi        (_PAGE_DIRTY|_PAGE_READ|_PAGE_WRITE),\prot
>> +#ifdef CONFIG_64BIT
>>       depd,z        \prot,8,7,\prot
>> +#else
>> +    depw,z        \prot,8,7,\prot
>> +#endif
>>       /*
>>        * OK, it is in the temp alias region, check whether "from" or 
>> "to".
>>        * Check "subtle" note in pacache.S re: r23/r26.
> Better check that this fix doesn't break 32-bit PA 2.0 as the seven 
> bit are now being deposited
> in a different place.


James & Dave - good catches!

James patch now let my 715/64 boot, but still crashes on my B160L:

swapper (pid 1): Illegal instruction (code 8)

      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001110000100001111 Not tainted
r00-03  0004e10f 00000020 101198cc 17c245c0
r04-07  ffeff000 17ec05f8 007d4000 17e60260
r08-11  17c5100b fffff000 17e60310 00020000
r12-15  00000ffc 0000000b 00000000 ffeff000
r16-19  007d4000 10768020 10000000 17c22db8
r20-23  17c245c8 108fc000 00000001 00000020
r24-27  000007d4 0f2fffe0 0000fa80 106e2020
r28-31  0f2ff000 000074ee 17c24640 000072e6
sr00-03  00000000 00000001 00000000 00000000
sr04-07  00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
  IIR: 078113e0    ISR: 00000000  IOR: 0f2ff000
  CPU:        0   CR30: 17c24000 CR31: f0102978
  ORIG_R28: 17ebbe40
  IAOQ[0]: flush_icache_page_asm+0x28/0x7c
  IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
  RP(r2): flush_cache_page+0x90/0xb0
Backtrace:



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 18:23                     ` John David Anglin
  2012-05-15 18:50                       ` Helge Deller
@ 2012-05-15 19:09                       ` James Bottomley
  1 sibling, 0 replies; 56+ messages in thread
From: James Bottomley @ 2012-05-15 19:09 UTC (permalink / raw)
  To: John David Anglin; +Cc: Helge Deller, Vincent, Rolf Eike Beer, linux-parisc

On Tue, 2012-05-15 at 14:23 -0400, John David Anglin wrote:
> On 5/15/2012 5:13 AM, James Bottomley wrote:
> > On Tue, 2012-05-15 at 09:09 +0100, James Bottomley wrote:
> >> On Mon, 2012-05-14 at 18:38 -0400, John David Anglin wrote:
> >>> On 14-May-12, at 6:11 PM, Helge Deller wrote:
> >>>
> >>>> The B160L and the 715/64 (both 32bit-only PA1.X machines) crashed
> >>>> with the following trace.
> >>>> All logs attached.
> >>>>
> >>>> Any ideas?
> >>> This is exactly the same failure as reported by Vincent.
> >>>
> >>> The most likely problem is the PA 1.1 tmpalias support in entry.S is
> >>> broken.  For example,
> >>> the cache stride that is loaded in flush_dcache_page_asm to register
> >>> r1 is wrong.  Probably,
> >>> the do_alias macro is wrong for PA 1.1.  This is hunk of code that
> >>> should be executed
> >>> when a fdc non access fault occurs.
> >>>
> >>> nadtlb_check_alias_11:
> >>>           do_alias        spc,t0,t1,va,pte,prot,nadtlb_emulate
> >>>
> >>>           idtlba          pte,(va)
> >>>           idtlbp          prot,(va)
> >>>
> >>>           rfir
> >>>           nop
> >>>
> >>> The TLB insert instructions on PA 1.1 have a different format than on
> >>> PA 2.0.  I'm not sure
> >>> how this would corrupt r1.
> >>>
> >>> On the other hand, I had asked Vincent to put a "b,n ." instruction
> >>> just before the fdc loop,
> >>> boot, hit the TOC button, and capture the setup registers for the
> >>> flush operation.  It's possible
> >>> the stride variable has been clobbered.
> >> Actually, I don't think it's that.  I built a PA 1.1 only kernel and
> >> booted it successfully on the C360.  That exercises all the _11 paths,
> >> so I don't think there's a code fault.  I do think there's a non PA1.1
> >> instruction in there somewhere that the C360 wouldn't notice.
> > OK, I think this is the problem.  We have a depd instruction in do_alias
> > which is now in the _11 fault paths.
> >
> > This should be the fix, if someone wants to test it before I can get
> > around to building it.
> >
> > James
> >
> > ---
> >
> > diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
> > index 6f05944..5350342 100644
> > --- a/arch/parisc/kernel/entry.S
> > +++ b/arch/parisc/kernel/entry.S
> > @@ -581,7 +581,11 @@
> >   	 */
> >   	cmpiclr,=	0x01,\tmp,%r0
> >   	ldi		(_PAGE_DIRTY|_PAGE_READ|_PAGE_WRITE),\prot
> > +#ifdef CONFIG_64BIT
> >   	depd,z		\prot,8,7,\prot
> > +#else
> > +	depw,z		\prot,8,7,\prot
> > +#endif
> >   	/*
> >   	 * OK, it is in the temp alias region, check whether "from" or "to".
> >   	 * Check "subtle" note in pacache.S re: r23/r26.
> Better check that this fix doesn't break 32-bit PA 2.0 as the seven bit 
> are now being deposited
> in a different place.

It doesn't.  It's the same on both 32 and 64 bit: I compared with the
original code.

James



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 18:50                       ` Helge Deller
@ 2012-05-15 19:24                         ` John David Anglin
  2012-05-15 19:46                           ` John David Anglin
  2012-05-15 19:52                         ` James Bottomley
  1 sibling, 1 reply; 56+ messages in thread
From: John David Anglin @ 2012-05-15 19:24 UTC (permalink / raw)
  To: Helge Deller; +Cc: James Bottomley, Vincent, Rolf Eike Beer, linux-parisc

James patch now let my 715/64 boot, but still crashes on my B160L:
>
> swapper (pid 1): Illegal instruction (code 8)
>
>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001001110000100001111 Not tainted
> r00-03  0004e10f 00000020 101198cc 17c245c0
> r04-07  ffeff000 17ec05f8 007d4000 17e60260
> r08-11  17c5100b fffff000 17e60310 00020000
> r12-15  00000ffc 0000000b 00000000 ffeff000
> r16-19  007d4000 10768020 10000000 17c22db8
> r20-23  17c245c8 108fc000 00000001 00000020
> r24-27  000007d4 0f2fffe0 0000fa80 106e2020
> r28-31  0f2ff000 000074ee 17c24640 000072e6
> sr00-03  00000000 00000001 00000000 00000000
> sr04-07  00000000 00000000 00000000 00000000
>
> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
>  IIR: 078113e0    ISR: 00000000  IOR: 0f2ff000
>  CPU:        0   CR30: 17c24000 CR31: f0102978
>  ORIG_R28: 17ebbe40
>  IAOQ[0]: flush_icache_page_asm+0x28/0x7c
>  IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
>  RP(r2): flush_cache_page+0x90/0xb0
> Backtrace:
This one is in a different place: flush_icache_page_asm.  It has
crashed on the first fic,m instruction.  Again it is an illegal instruction.

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 19:24                         ` John David Anglin
@ 2012-05-15 19:46                           ` John David Anglin
  2012-05-15 19:59                             ` Helge Deller
  0 siblings, 1 reply; 56+ messages in thread
From: John David Anglin @ 2012-05-15 19:46 UTC (permalink / raw)
  To: Helge Deller; +Cc: James Bottomley, Vincent, Rolf Eike Beer, linux-parisc

On 5/15/2012 3:24 PM, John David Anglin wrote:
> James patch now let my 715/64 boot, but still crashes on my B160L:
>>
>> swapper (pid 1): Illegal instruction (code 8)
>>
>>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>> PSW: 00000000000001001110000100001111 Not tainted
>> r00-03  0004e10f 00000020 101198cc 17c245c0
>> r04-07  ffeff000 17ec05f8 007d4000 17e60260
>> r08-11  17c5100b fffff000 17e60310 00020000
>> r12-15  00000ffc 0000000b 00000000 ffeff000
>> r16-19  007d4000 10768020 10000000 17c22db8
>> r20-23  17c245c8 108fc000 00000001 00000020
>> r24-27  000007d4 0f2fffe0 0000fa80 106e2020
>> r28-31  0f2ff000 000074ee 17c24640 000072e6
>> sr00-03  00000000 00000001 00000000 00000000
>> sr04-07  00000000 00000000 00000000 00000000
>>
>> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
>>  IIR: 078113e0    ISR: 00000000  IOR: 0f2ff000
>>  CPU:        0   CR30: 17c24000 CR31: f0102978
>>  ORIG_R28: 17ebbe40
>>  IAOQ[0]: flush_icache_page_asm+0x28/0x7c
>>  IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
>>  RP(r2): flush_cache_page+0x90/0xb0
>> Backtrace:
> This one is in a different place: flush_icache_page_asm.  It has
> crashed on the first fic,m instruction.  Again it is an illegal 
> instruction.
>
Looking at the PA 1.1 arch, I see that the space register needs to be
explicitly specified on PA 1.1 (format 26).  The implicit (format 24)
instruction was added in PA 2.0.

Could you try adding %sr0 to the fic instructions?

Thanks,
Dave



-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 18:50                       ` Helge Deller
  2012-05-15 19:24                         ` John David Anglin
@ 2012-05-15 19:52                         ` James Bottomley
  1 sibling, 0 replies; 56+ messages in thread
From: James Bottomley @ 2012-05-15 19:52 UTC (permalink / raw)
  To: Helge Deller; +Cc: John David Anglin, Vincent, Rolf Eike Beer, linux-parisc

On Tue, 2012-05-15 at 20:50 +0200, Helge Deller wrote:
> On 05/15/2012 08:23 PM, John David Anglin wrote:
> > On 5/15/2012 5:13 AM, James Bottomley wrote:
> >> On Tue, 2012-05-15 at 09:09 +0100, James Bottomley wrote:
> >>> On Mon, 2012-05-14 at 18:38 -0400, John David Anglin wrote:
> >>>> On 14-May-12, at 6:11 PM, Helge Deller wrote:
> >>>>
> >>>>> The B160L and the 715/64 (both 32bit-only PA1.X machines) crashed
> >>>>> with the following trace.
> >>>>> All logs attached.
> >>>>>
> >>>>> Any ideas?
> >>>> This is exactly the same failure as reported by Vincent.
> >>>>
> >>>> The most likely problem is the PA 1.1 tmpalias support in entry.S is
> >>>> broken.  For example,
> >>>> the cache stride that is loaded in flush_dcache_page_asm to register
> >>>> r1 is wrong.  Probably,
> >>>> the do_alias macro is wrong for PA 1.1.  This is hunk of code that
> >>>> should be executed
> >>>> when a fdc non access fault occurs.
> >>>>
> >>>> nadtlb_check_alias_11:
> >>>>           do_alias        spc,t0,t1,va,pte,prot,nadtlb_emulate
> >>>>
> >>>>           idtlba          pte,(va)
> >>>>           idtlbp          prot,(va)
> >>>>
> >>>>           rfir
> >>>>           nop
> >>>>
> >>>> The TLB insert instructions on PA 1.1 have a different format than on
> >>>> PA 2.0.  I'm not sure
> >>>> how this would corrupt r1.
> >>>>
> >>>> On the other hand, I had asked Vincent to put a "b,n ." instruction
> >>>> just before the fdc loop,
> >>>> boot, hit the TOC button, and capture the setup registers for the
> >>>> flush operation.  It's possible
> >>>> the stride variable has been clobbered.
> >>> Actually, I don't think it's that.  I built a PA 1.1 only kernel and
> >>> booted it successfully on the C360.  That exercises all the _11 paths,
> >>> so I don't think there's a code fault.  I do think there's a non PA1.1
> >>> instruction in there somewhere that the C360 wouldn't notice.
> >> OK, I think this is the problem.  We have a depd instruction in do_alias
> >> which is now in the _11 fault paths.
> >>
> >> This should be the fix, if someone wants to test it before I can get
> >> around to building it.
> >>
> >> James
> >>
> >> ---
> >>
> >> diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
> >> index 6f05944..5350342 100644
> >> --- a/arch/parisc/kernel/entry.S
> >> +++ b/arch/parisc/kernel/entry.S
> >> @@ -581,7 +581,11 @@
> >>        */
> >>       cmpiclr,=    0x01,\tmp,%r0
> >>       ldi        (_PAGE_DIRTY|_PAGE_READ|_PAGE_WRITE),\prot
> >> +#ifdef CONFIG_64BIT
> >>       depd,z        \prot,8,7,\prot
> >> +#else
> >> +    depw,z        \prot,8,7,\prot
> >> +#endif
> >>       /*
> >>        * OK, it is in the temp alias region, check whether "from" or 
> >> "to".
> >>        * Check "subtle" note in pacache.S re: r23/r26.
> > Better check that this fix doesn't break 32-bit PA 2.0 as the seven 
> > bit are now being deposited
> > in a different place.
> 
> 
> James & Dave - good catches!
> 
> James patch now let my 715/64 boot, but still crashes on my B160L:
> 
> swapper (pid 1): Illegal instruction (code 8)
> 
>       YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001001110000100001111 Not tainted
> r00-03  0004e10f 00000020 101198cc 17c245c0
> r04-07  ffeff000 17ec05f8 007d4000 17e60260
> r08-11  17c5100b fffff000 17e60310 00020000
> r12-15  00000ffc 0000000b 00000000 ffeff000
> r16-19  007d4000 10768020 10000000 17c22db8
> r20-23  17c245c8 108fc000 00000001 00000020
> r24-27  000007d4 0f2fffe0 0000fa80 106e2020
> r28-31  0f2ff000 000074ee 17c24640 000072e6
> sr00-03  00000000 00000001 00000000 00000000
> sr04-07  00000000 00000000 00000000 00000000
> 
> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
>   IIR: 078113e0    ISR: 00000000  IOR: 0f2ff000
>   CPU:        0   CR30: 17c24000 CR31: f0102978
>   ORIG_R28: 17ebbe40
>   IAOQ[0]: flush_icache_page_asm+0x28/0x7c
>   IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
>   RP(r2): flush_cache_page+0x90/0xb0
> Backtrace:

OK, so I assume one (the 715) has a shared D and I TLB and the b160
doesn't?

James



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 19:46                           ` John David Anglin
@ 2012-05-15 19:59                             ` Helge Deller
  2012-05-15 20:05                               ` John David Anglin
  0 siblings, 1 reply; 56+ messages in thread
From: Helge Deller @ 2012-05-15 19:59 UTC (permalink / raw)
  To: John David Anglin; +Cc: James Bottomley, Vincent, Rolf Eike Beer, linux-parisc

On 05/15/2012 09:46 PM, John David Anglin wrote:
> On 5/15/2012 3:24 PM, John David Anglin wrote:
>> James patch now let my 715/64 boot, but still crashes on my B160L:
>>>
>>> swapper (pid 1): Illegal instruction (code 8)
>>>
>>>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>>> PSW: 00000000000001001110000100001111 Not tainted
>>> r00-03  0004e10f 00000020 101198cc 17c245c0
>>> r04-07  ffeff000 17ec05f8 007d4000 17e60260
>>> r08-11  17c5100b fffff000 17e60310 00020000
>>> r12-15  00000ffc 0000000b 00000000 ffeff000
>>> r16-19  007d4000 10768020 10000000 17c22db8
>>> r20-23  17c245c8 108fc000 00000001 00000020
>>> r24-27  000007d4 0f2fffe0 0000fa80 106e2020
>>> r28-31  0f2ff000 000074ee 17c24640 000072e6
>>> sr00-03  00000000 00000001 00000000 00000000
>>> sr04-07  00000000 00000000 00000000 00000000
>>>
>>> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
>>>  IIR: 078113e0    ISR: 00000000  IOR: 0f2ff000
>>>  CPU:        0   CR30: 17c24000 CR31: f0102978
>>>  ORIG_R28: 17ebbe40
>>>  IAOQ[0]: flush_icache_page_asm+0x28/0x7c
>>>  IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
>>>  RP(r2): flush_cache_page+0x90/0xb0
>>> Backtrace:
>> This one is in a different place: flush_icache_page_asm.  It has
>> crashed on the first fic,m instruction.  Again it is an illegal 
>> instruction.
>>
> Looking at the PA 1.1 arch, I see that the space register needs to be
> explicitly specified on PA 1.1 (format 26).  The implicit (format 24)
> instruction was added in PA 2.0.
>
> Could you try adding %sr0 to the fic instructions?
no illegal instruction any longer, but "bad address"....
I changed all to " fic,m           %r1(%sr0,%r28)"



Freeing unused kernel memory: 320k freed
Backtrace:
  [<101198cc>] flush_cache_page+0x90/0xb0
  [<101b9b84>] do_wp_page+0x1e0/0x7b4
  [<101bb970>] handle_pte_fault+0x284/0x7c0
  [<101bbf74>] handle_mm_fault+0xc8/0x120
  [<10118cc8>] do_page_fault+0x228/0x2d0
  [<1011a838>] handle_interruption+0x1d4/0x6c4
  [<10105078>] intr_check_sig+0x0/0x34


Bad Address (null pointer deref?): Code=17 regs=17c244c0 (Addr=0f17d000)

      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111100100001111 Not tainted
r00-03  0004f90f 00000020 101198cc 17c24440
r04-07  4017d4c4 17ebf498 007cd000 007cdb05
r08-11  17ebee40 17ec55f4 107eb7c0 10768020
r12-15  000007cd 17ebee74 000005f4 00050000
r16-19  17c23098 17c24140 0011849c 17c22db8
r20-23  0000004b 108fc000 00000000 00000000
r24-27  000007cd 0f17dfe0 0000f9a0 106e2020
r28-31  0f17d000 17c23098 17c244c0 6fffffff
sr00-03  00000800 00000001 00000000 00000001
sr04-07  00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
  IIR: 078102a0    ISR: 00000800  IOR: 0f17d000
  CPU:        0   CR30: 17c24000 CR31: f0102978
  ORIG_R28: 17c51000
  IAOQ[0]: flush_icache_page_asm+0x28/0x7c
  IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
  RP(r2): flush_cache_page+0x90/0xb0
Backtrace:
  [<101198cc>] flush_cache_page+0x90/0xb0
  [<101b9b84>] do_wp_page+0x1e0/0x7b4
  [<101bb970>] handle_pte_fault+0x284/0x7c0
  [<101bbf74>] handle_mm_fault+0xc8/0x120
  [<10118cc8>] do_page_fault+0x228/0x2d0
  [<1011a838>] handle_interruption+0x1d4/0x6c4
  [<10105078>] intr_check_sig+0x0/0x34



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 19:59                             ` Helge Deller
@ 2012-05-15 20:05                               ` John David Anglin
  2012-05-15 20:28                                 ` Helge Deller
  0 siblings, 1 reply; 56+ messages in thread
From: John David Anglin @ 2012-05-15 20:05 UTC (permalink / raw)
  To: Helge Deller; +Cc: James Bottomley, Vincent, Rolf Eike Beer, linux-parisc

On 5/15/2012 3:59 PM, Helge Deller wrote:
> On 05/15/2012 09:46 PM, John David Anglin wrote:
>> On 5/15/2012 3:24 PM, John David Anglin wrote:
>>> James patch now let my 715/64 boot, but still crashes on my B160L:
>>>>
>>>> swapper (pid 1): Illegal instruction (code 8)
>>>>
>>>>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>>>> PSW: 00000000000001001110000100001111 Not tainted
>>>> r00-03  0004e10f 00000020 101198cc 17c245c0
>>>> r04-07  ffeff000 17ec05f8 007d4000 17e60260
>>>> r08-11  17c5100b fffff000 17e60310 00020000
>>>> r12-15  00000ffc 0000000b 00000000 ffeff000
>>>> r16-19  007d4000 10768020 10000000 17c22db8
>>>> r20-23  17c245c8 108fc000 00000001 00000020
>>>> r24-27  000007d4 0f2fffe0 0000fa80 106e2020
>>>> r28-31  0f2ff000 000074ee 17c24640 000072e6
>>>> sr00-03  00000000 00000001 00000000 00000000
>>>> sr04-07  00000000 00000000 00000000 00000000
>>>>
>>>> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
>>>>  IIR: 078113e0    ISR: 00000000  IOR: 0f2ff000
>>>>  CPU:        0   CR30: 17c24000 CR31: f0102978
>>>>  ORIG_R28: 17ebbe40
>>>>  IAOQ[0]: flush_icache_page_asm+0x28/0x7c
>>>>  IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
>>>>  RP(r2): flush_cache_page+0x90/0xb0
>>>> Backtrace:
>>> This one is in a different place: flush_icache_page_asm.  It has
>>> crashed on the first fic,m instruction.  Again it is an illegal 
>>> instruction.
>>>
>> Looking at the PA 1.1 arch, I see that the space register needs to be
>> explicitly specified on PA 1.1 (format 26).  The implicit (format 24)
>> instruction was added in PA 2.0.
>>
>> Could you try adding %sr0 to the fic instructions?
> no illegal instruction any longer, but "bad address"....
> I changed all to " fic,m           %r1(%sr0,%r28)"
>
>
>
> Freeing unused kernel memory: 320k freed
> Backtrace:
>  [<101198cc>] flush_cache_page+0x90/0xb0
>  [<101b9b84>] do_wp_page+0x1e0/0x7b4
>  [<101bb970>] handle_pte_fault+0x284/0x7c0
>  [<101bbf74>] handle_mm_fault+0xc8/0x120
>  [<10118cc8>] do_page_fault+0x228/0x2d0
>  [<1011a838>] handle_interruption+0x1d4/0x6c4
>  [<10105078>] intr_check_sig+0x0/0x34
>
>
> Bad Address (null pointer deref?): Code=17 regs=17c244c0 (Addr=0f17d000)
>
>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001001111100100001111 Not tainted
> r00-03  0004f90f 00000020 101198cc 17c24440
> r04-07  4017d4c4 17ebf498 007cd000 007cdb05
> r08-11  17ebee40 17ec55f4 107eb7c0 10768020
> r12-15  000007cd 17ebee74 000005f4 00050000
> r16-19  17c23098 17c24140 0011849c 17c22db8
> r20-23  0000004b 108fc000 00000000 00000000
> r24-27  000007cd 0f17dfe0 0000f9a0 106e2020
> r28-31  0f17d000 17c23098 17c244c0 6fffffff
> sr00-03  00000800 00000001 00000000 00000001
> sr04-07  00000000 00000000 00000000 00000000
>
> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
>  IIR: 078102a0    ISR: 00000800  IOR: 0f17d000
>  CPU:        0   CR30: 17c24000 CR31: f0102978
>  ORIG_R28: 17c51000
>  IAOQ[0]: flush_icache_page_asm+0x28/0x7c
>  IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
>  RP(r2): flush_cache_page+0x90/0xb0
> Backtrace:
>  [<101198cc>] flush_cache_page+0x90/0xb0
>  [<101b9b84>] do_wp_page+0x1e0/0x7b4
>  [<101bb970>] handle_pte_fault+0x284/0x7c0
>  [<101bbf74>] handle_mm_fault+0xc8/0x120
>  [<10118cc8>] do_page_fault+0x228/0x2d0
>  [<1011a838>] handle_interruption+0x1d4/0x6c4
>  [<10105078>] intr_check_sig+0x0/0x34
>
>
>
>
Try %sr2 or %sr4.  %sr0 isn't zero.

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 20:05                               ` John David Anglin
@ 2012-05-15 20:28                                 ` Helge Deller
  2012-05-15 20:48                                   ` John David Anglin
                                                     ` (2 more replies)
  0 siblings, 3 replies; 56+ messages in thread
From: Helge Deller @ 2012-05-15 20:28 UTC (permalink / raw)
  To: John David Anglin; +Cc: James Bottomley, Vincent, Rolf Eike Beer, linux-parisc

On 05/15/2012 10:05 PM, John David Anglin wrote:
> On 5/15/2012 3:59 PM, Helge Deller wrote:
>> On 05/15/2012 09:46 PM, John David Anglin wrote:
>>> On 5/15/2012 3:24 PM, John David Anglin wrote:
>>>> James patch now let my 715/64 boot, but still crashes on my B160L:
>>>>>
>>>>> swapper (pid 1): Illegal instruction (code 8)
>>>>>
>>>>>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>>>>> PSW: 00000000000001001110000100001111 Not tainted
>>>>> r00-03  0004e10f 00000020 101198cc 17c245c0
>>>>> r04-07  ffeff000 17ec05f8 007d4000 17e60260
>>>>> r08-11  17c5100b fffff000 17e60310 00020000
>>>>> r12-15  00000ffc 0000000b 00000000 ffeff000
>>>>> r16-19  007d4000 10768020 10000000 17c22db8
>>>>> r20-23  17c245c8 108fc000 00000001 00000020
>>>>> r24-27  000007d4 0f2fffe0 0000fa80 106e2020
>>>>> r28-31  0f2ff000 000074ee 17c24640 000072e6
>>>>> sr00-03  00000000 00000001 00000000 00000000
>>>>> sr04-07  00000000 00000000 00000000 00000000
>>>>>
>>>>> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
>>>>>  IIR: 078113e0    ISR: 00000000  IOR: 0f2ff000
>>>>>  CPU:        0   CR30: 17c24000 CR31: f0102978
>>>>>  ORIG_R28: 17ebbe40
>>>>>  IAOQ[0]: flush_icache_page_asm+0x28/0x7c
>>>>>  IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
>>>>>  RP(r2): flush_cache_page+0x90/0xb0
>>>>> Backtrace:
>>>> This one is in a different place: flush_icache_page_asm.  It has
>>>> crashed on the first fic,m instruction.  Again it is an illegal 
>>>> instruction.
>>>>
>>> Looking at the PA 1.1 arch, I see that the space register needs to be
>>> explicitly specified on PA 1.1 (format 26).  The implicit (format 24)
>>> instruction was added in PA 2.0.
>>>
>>> Could you try adding %sr0 to the fic instructions?
>> no illegal instruction any longer, but "bad address"....
>> I changed all to " fic,m           %r1(%sr0,%r28)"
>>
>>
>>
>> Freeing unused kernel memory: 320k freed
>> Backtrace:
>>  [<101198cc>] flush_cache_page+0x90/0xb0
>>  [<101b9b84>] do_wp_page+0x1e0/0x7b4
>>  [<101bb970>] handle_pte_fault+0x284/0x7c0
>>  [<101bbf74>] handle_mm_fault+0xc8/0x120
>>  [<10118cc8>] do_page_fault+0x228/0x2d0
>>  [<1011a838>] handle_interruption+0x1d4/0x6c4
>>  [<10105078>] intr_check_sig+0x0/0x34
>>
>>
>> Bad Address (null pointer deref?): Code=17 regs=17c244c0 (Addr=0f17d000)
>>
>>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>> PSW: 00000000000001001111100100001111 Not tainted
>> r00-03  0004f90f 00000020 101198cc 17c24440
>> r04-07  4017d4c4 17ebf498 007cd000 007cdb05
>> r08-11  17ebee40 17ec55f4 107eb7c0 10768020
>> r12-15  000007cd 17ebee74 000005f4 00050000
>> r16-19  17c23098 17c24140 0011849c 17c22db8
>> r20-23  0000004b 108fc000 00000000 00000000
>> r24-27  000007cd 0f17dfe0 0000f9a0 106e2020
>> r28-31  0f17d000 17c23098 17c244c0 6fffffff
>> sr00-03  00000800 00000001 00000000 00000001
>> sr04-07  00000000 00000000 00000000 00000000
>>
>> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
>>  IIR: 078102a0    ISR: 00000800  IOR: 0f17d000
>>  CPU:        0   CR30: 17c24000 CR31: f0102978
>>  ORIG_R28: 17c51000
>>  IAOQ[0]: flush_icache_page_asm+0x28/0x7c
>>  IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
>>  RP(r2): flush_cache_page+0x90/0xb0
>> Backtrace:
>>  [<101198cc>] flush_cache_page+0x90/0xb0
>>  [<101b9b84>] do_wp_page+0x1e0/0x7b4
>>  [<101bb970>] handle_pte_fault+0x284/0x7c0
>>  [<101bbf74>] handle_mm_fault+0xc8/0x120
>>  [<10118cc8>] do_page_fault+0x228/0x2d0
>>  [<1011a838>] handle_interruption+0x1d4/0x6c4
>>  [<10105078>] intr_check_sig+0x0/0x34
>>
>>
>>
>>
> Try %sr2 or %sr4.  %sr0 isn't zero.

Dave, great, you fixed it !
All my machines now boot the 32bit kernel.
%sr2 does not work since it becomes a value unequal to zero later in the 
boot process.
%sr4 did worked - it's actually used further down in pacache.S in 
flush_kernel_icache_page() as well...

I still have the problem that my B160L "hangs" during boot after 
starting crond - but I'm not sure if this is related to your patches 
since the other machines do work.
Maybe it's just some userspace trouble....

Will you send your patches to Linus as he requested in the other mail?

Helge

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 20:28                                 ` Helge Deller
@ 2012-05-15 20:48                                   ` John David Anglin
  2012-05-16 14:59                                     ` James Bottomley
  2012-05-17 19:26                                     ` Helge Deller
  2012-05-15 21:08                                   ` John David Anglin
  2012-05-16  7:27                                   ` James Bottomley
  2 siblings, 2 replies; 56+ messages in thread
From: John David Anglin @ 2012-05-15 20:48 UTC (permalink / raw)
  To: Helge Deller; +Cc: James Bottomley, Vincent, Rolf Eike Beer, linux-parisc

On 5/15/2012 4:28 PM, Helge Deller wrote:
> Will you send your patches to Linus as he requested in the other mail?
You have the diff for the two PA 1.1 changes.  Suggest you send them.
I think these should go to stable as well as soon as it is verified that all
targets boot.

I think my cache-2 is more appropriate for linux-next.  There are a number
of subtle issues with it.  I am pleased that the users that have tried 
it have
been generally happy with it.

We need to debug why your B160L hangs.  Can you kill whatever hangs
from the console?  Sometimes the application is still in the foreground.

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15  9:13                   ` James Bottomley
  2012-05-15 18:23                     ` John David Anglin
@ 2012-05-15 21:01                     ` Vincent
  2012-05-16 19:07                       ` Helge Deller
  1 sibling, 1 reply; 56+ messages in thread
From: Vincent @ 2012-05-15 21:01 UTC (permalink / raw)
  To: James Bottomley
  Cc: John David Anglin, Helge Deller, Rolf Eike Beer, linux-parisc

On 05/15/2012 11:13 AM, James Bottomley wrote:
(..)
> OK, I think this is the problem.  We have a depd instruction in do_alias
> which is now in the _11 fault paths.
> 
> This should be the fix, if someone wants to test it before I can get
> around to building it.

Hi James,

This makes my hp712 boot now; congrats!

Works for me with v3.4-rc6 and v3.4-rc7, with the following "patches pile":

depd patch     (http://www.spinics.net/lists/linux-parisc/msg04169.html)
sections patch (http://www.spinics.net/lists/linux-parisc/msg04091.html)
cache patch    (http://www.spinics.net/lists/linux-parisc/msg04120.html)
v3.4-rc7

Thanks!

...I think I'll upload a git, somewhere, for convenience.

Best regards,

V.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 20:28                                 ` Helge Deller
  2012-05-15 20:48                                   ` John David Anglin
@ 2012-05-15 21:08                                   ` John David Anglin
  2012-05-16  7:27                                   ` James Bottomley
  2 siblings, 0 replies; 56+ messages in thread
From: John David Anglin @ 2012-05-15 21:08 UTC (permalink / raw)
  To: Helge Deller; +Cc: James Bottomley, Vincent, Rolf Eike Beer, linux-parisc

On 5/15/2012 4:28 PM, Helge Deller wrote:
> %sr2 does not work since it becomes a value unequal to zero later in 
> the boot process.

I think my cache patch is broken sr2 isn't always 0.  The only code that 
plays with sr2
seems to be in lib/memcpy.c.

Dave

-- 
John David Anglin    dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 20:28                                 ` Helge Deller
  2012-05-15 20:48                                   ` John David Anglin
  2012-05-15 21:08                                   ` John David Anglin
@ 2012-05-16  7:27                                   ` James Bottomley
  2012-05-16  9:27                                     ` James Bottomley
  2012-05-16 10:49                                     ` John David Anglin
  2 siblings, 2 replies; 56+ messages in thread
From: James Bottomley @ 2012-05-16  7:27 UTC (permalink / raw)
  To: Helge Deller; +Cc: John David Anglin, Vincent, Rolf Eike Beer, linux-parisc

On Tue, 2012-05-15 at 22:28 +0200, Helge Deller wrote:
> On 05/15/2012 10:05 PM, John David Anglin wrote:
> > On 5/15/2012 3:59 PM, Helge Deller wrote:
> >> On 05/15/2012 09:46 PM, John David Anglin wrote:
> >>> On 5/15/2012 3:24 PM, John David Anglin wrote:
> >>>> James patch now let my 715/64 boot, but still crashes on my B160L:
> >>>>>
> >>>>> swapper (pid 1): Illegal instruction (code 8)
> >>>>>
> >>>>>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> >>>>> PSW: 00000000000001001110000100001111 Not tainted
> >>>>> r00-03  0004e10f 00000020 101198cc 17c245c0
> >>>>> r04-07  ffeff000 17ec05f8 007d4000 17e60260
> >>>>> r08-11  17c5100b fffff000 17e60310 00020000
> >>>>> r12-15  00000ffc 0000000b 00000000 ffeff000
> >>>>> r16-19  007d4000 10768020 10000000 17c22db8
> >>>>> r20-23  17c245c8 108fc000 00000001 00000020
> >>>>> r24-27  000007d4 0f2fffe0 0000fa80 106e2020
> >>>>> r28-31  0f2ff000 000074ee 17c24640 000072e6
> >>>>> sr00-03  00000000 00000001 00000000 00000000
> >>>>> sr04-07  00000000 00000000 00000000 00000000
> >>>>>
> >>>>> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
> >>>>>  IIR: 078113e0    ISR: 00000000  IOR: 0f2ff000
> >>>>>  CPU:        0   CR30: 17c24000 CR31: f0102978
> >>>>>  ORIG_R28: 17ebbe40
> >>>>>  IAOQ[0]: flush_icache_page_asm+0x28/0x7c
> >>>>>  IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
> >>>>>  RP(r2): flush_cache_page+0x90/0xb0
> >>>>> Backtrace:
> >>>> This one is in a different place: flush_icache_page_asm.  It has
> >>>> crashed on the first fic,m instruction.  Again it is an illegal 
> >>>> instruction.
> >>>>
> >>> Looking at the PA 1.1 arch, I see that the space register needs to be
> >>> explicitly specified on PA 1.1 (format 26).  The implicit (format 24)
> >>> instruction was added in PA 2.0.
> >>>
> >>> Could you try adding %sr0 to the fic instructions?
> >> no illegal instruction any longer, but "bad address"....
> >> I changed all to " fic,m           %r1(%sr0,%r28)"
> >>
> >>
> >>
> >> Freeing unused kernel memory: 320k freed
> >> Backtrace:
> >>  [<101198cc>] flush_cache_page+0x90/0xb0
> >>  [<101b9b84>] do_wp_page+0x1e0/0x7b4
> >>  [<101bb970>] handle_pte_fault+0x284/0x7c0
> >>  [<101bbf74>] handle_mm_fault+0xc8/0x120
> >>  [<10118cc8>] do_page_fault+0x228/0x2d0
> >>  [<1011a838>] handle_interruption+0x1d4/0x6c4
> >>  [<10105078>] intr_check_sig+0x0/0x34
> >>
> >>
> >> Bad Address (null pointer deref?): Code=17 regs=17c244c0 (Addr=0f17d000)
> >>
> >>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> >> PSW: 00000000000001001111100100001111 Not tainted
> >> r00-03  0004f90f 00000020 101198cc 17c24440
> >> r04-07  4017d4c4 17ebf498 007cd000 007cdb05
> >> r08-11  17ebee40 17ec55f4 107eb7c0 10768020
> >> r12-15  000007cd 17ebee74 000005f4 00050000
> >> r16-19  17c23098 17c24140 0011849c 17c22db8
> >> r20-23  0000004b 108fc000 00000000 00000000
> >> r24-27  000007cd 0f17dfe0 0000f9a0 106e2020
> >> r28-31  0f17d000 17c23098 17c244c0 6fffffff
> >> sr00-03  00000800 00000001 00000000 00000001
> >> sr04-07  00000000 00000000 00000000 00000000
> >>
> >> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
> >>  IIR: 078102a0    ISR: 00000800  IOR: 0f17d000
> >>  CPU:        0   CR30: 17c24000 CR31: f0102978
> >>  ORIG_R28: 17c51000
> >>  IAOQ[0]: flush_icache_page_asm+0x28/0x7c
> >>  IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
> >>  RP(r2): flush_cache_page+0x90/0xb0
> >> Backtrace:
> >>  [<101198cc>] flush_cache_page+0x90/0xb0
> >>  [<101b9b84>] do_wp_page+0x1e0/0x7b4
> >>  [<101bb970>] handle_pte_fault+0x284/0x7c0
> >>  [<101bbf74>] handle_mm_fault+0xc8/0x120
> >>  [<10118cc8>] do_page_fault+0x228/0x2d0
> >>  [<1011a838>] handle_interruption+0x1d4/0x6c4
> >>  [<10105078>] intr_check_sig+0x0/0x34
> >>
> >>
> >>
> >>
> > Try %sr2 or %sr4.  %sr0 isn't zero.
> 
> Dave, great, you fixed it !
> All my machines now boot the 32bit kernel.
> %sr2 does not work since it becomes a value unequal to zero later in the 
> boot process.
> %sr4 did worked - it's actually used further down in pacache.S in 
> flush_kernel_icache_page() as well...

Right, in the two byte space encoding, which is what we usually do, a
zero means use the correct quadrant space register (i.e. %sr4 through %
sr7 depending on which quadrant we're in.  Since PA doesn't use
quadrants, we keep them all at the space of the context - i.e. zero for
kernel).  The 24 bit form of the instruction has an explicit space
requirement, so you have to specify manually, which means just pick any
of %sr4-%sr7 since they're always the same.

> I still have the problem that my B160L "hangs" during boot after 
> starting crond - but I'm not sure if this is related to your patches 
> since the other machines do work.
> Maybe it's just some userspace trouble....
> 
> Will you send your patches to Linus as he requested in the other mail?

I'll take care of the urgent ones once we have a set of booting kernels.
My current attempts to boot a B180 are failing on RCU:

Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
devtmpfs: initialized
NET: Registered protocol family 16
Backtrace:
 [<10180fc4>] rcu_process_callbacks+0x20/0x40
 [<101330b0>] __do_softirq+0xd8/0x190
 [<101331d0>] run_ksoftirqd+0x68/0x118
 [<1014a144>] kthread+0xac/0xb4
 [<1010305c>] ret_from_kernel_thread+0x1c/0x24


Kernel Fault: Code=26 regs=2ec3c2c0 (Addr=00000000)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000000000001111 Not tainted
r00-03  0004000f 104d9820 10180fc4 2ec3c240
r04-07  2ec76630 00000000 00000fff 10480910
r08-11  00000100 0000000a 104d9c60 104d9c80
r12-15  1047e884 103f16a8 00000009 f0100000
r16-19  f0000c70 f0000194 1fffffe0 00000100
r20-23  00000007 2ec222d8 2ec222d8 00000000
r24-27  00000000 0000006b 2ec222a8 1046a020
r28-31  2ec3c000 2ec222a0 2ec3c2c0 00000004
sr00-03  00000000 00000000 00000000 00000000
sr04-07  00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 10180f58 10180f5c
 IIR: 0ca01080    ISR: 00000000  IOR: 00000000
 CPU:        0   CR30: 2ec3c000 CR31: f0102978
 ORIG_R28: 00000000
 IAOQ[0]: __rcu_process_callbacks+0x7c/0xc8
 IAOQ[1]: __rcu_process_callbacks+0x80/0xc8
 RP(r2): rcu_process_callbacks+0x20/0x40
Backtrace:
 [<10180fc4>] rcu_process_callbacks+0x20/0x40
 [<101330b0>] __do_softirq+0xd8/0x190
 [<101331d0>] run_ksoftirqd+0x68/0x118
 [<1014a144>] kthread+0xac/0xb4
 [<1010305c>] ret_from_kernel_thread+0x1c/0x24

Kernel panic - not syncing: Kernel Fault

James



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-16  7:27                                   ` James Bottomley
@ 2012-05-16  9:27                                     ` James Bottomley
  2012-05-16 10:09                                       ` James Bottomley
  2012-05-16 10:49                                     ` John David Anglin
  1 sibling, 1 reply; 56+ messages in thread
From: James Bottomley @ 2012-05-16  9:27 UTC (permalink / raw)
  To: Helge Deller; +Cc: John David Anglin, Vincent, Rolf Eike Beer, linux-parisc

On Wed, 2012-05-16 at 08:27 +0100, James Bottomley wrote:
> My current attempts to boot a B180 are failing on RCU:
> 
> Initializing cgroup subsys cpuacct
> Initializing cgroup subsys memory
> Initializing cgroup subsys devices
> Initializing cgroup subsys freezer
> devtmpfs: initialized
> NET: Registered protocol family 16
> Backtrace:
>  [<10180fc4>] rcu_process_callbacks+0x20/0x40
>  [<101330b0>] __do_softirq+0xd8/0x190
>  [<101331d0>] run_ksoftirqd+0x68/0x118
>  [<1014a144>] kthread+0xac/0xb4
>  [<1010305c>] ret_from_kernel_thread+0x1c/0x24
> 
> 
> Kernel Fault: Code=26 regs=2ec3c2c0 (Addr=00000000)

OK, debugged this: it's a prefetch(NULL) in the RCU code.  Apparently on
the PA7300LC processor, which is what my B180 has, this is actually
generating a dtlb insertion interruption.  The fix is to nullify the
prefetch if the address is zero, which I'm testing out now.

James



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-16  9:27                                     ` James Bottomley
@ 2012-05-16 10:09                                       ` James Bottomley
  0 siblings, 0 replies; 56+ messages in thread
From: James Bottomley @ 2012-05-16 10:09 UTC (permalink / raw)
  To: Helge Deller; +Cc: John David Anglin, Vincent, Rolf Eike Beer, linux-parisc

On Wed, 2012-05-16 at 10:27 +0100, James Bottomley wrote:
> On Wed, 2012-05-16 at 08:27 +0100, James Bottomley wrote:
> > My current attempts to boot a B180 are failing on RCU:
> > 
> > Initializing cgroup subsys cpuacct
> > Initializing cgroup subsys memory
> > Initializing cgroup subsys devices
> > Initializing cgroup subsys freezer
> > devtmpfs: initialized
> > NET: Registered protocol family 16
> > Backtrace:
> >  [<10180fc4>] rcu_process_callbacks+0x20/0x40
> >  [<101330b0>] __do_softirq+0xd8/0x190
> >  [<101331d0>] run_ksoftirqd+0x68/0x118
> >  [<1014a144>] kthread+0xac/0xb4
> >  [<1010305c>] ret_from_kernel_thread+0x1c/0x24
> > 
> > 
> > Kernel Fault: Code=26 regs=2ec3c2c0 (Addr=00000000)
> 
> OK, debugged this: it's a prefetch(NULL) in the RCU code.  Apparently on
> the PA7300LC processor, which is what my B180 has, this is actually
> generating a dtlb insertion interruption.  The fix is to nullify the
> prefetch if the address is zero, which I'm testing out now.

OK, confirmed, my B180 finally boot.  This is the final patch it needed.

James

---

diff --git a/arch/parisc/include/asm/prefetch.h b/arch/parisc/include/asm/prefetch.h
index c5edc60..1ee7c82 100644
--- a/arch/parisc/include/asm/prefetch.h
+++ b/arch/parisc/include/asm/prefetch.h
@@ -21,7 +21,12 @@
 #define ARCH_HAS_PREFETCH
 static inline void prefetch(const void *addr)
 {
-	__asm__("ldw 0(%0), %%r0" : : "r" (addr));
+	__asm__(
+#ifndef CONFIG_PA20
+		/* Need to avoid prefetch of NULL on PA7300LC */
+		"	extrw,u,= %0,31,32,%%r0\n"
+#endif
+		"	ldw 0(%0), %%r0" : : "r" (addr));
 }
 
 /* LDD is a PA2.0 addition. */



^ permalink raw reply related	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-16  7:27                                   ` James Bottomley
  2012-05-16  9:27                                     ` James Bottomley
@ 2012-05-16 10:49                                     ` John David Anglin
  2012-05-16 10:57                                       ` James Bottomley
  1 sibling, 1 reply; 56+ messages in thread
From: John David Anglin @ 2012-05-16 10:49 UTC (permalink / raw)
  To: James Bottomley; +Cc: Helge Deller, Vincent, Rolf Eike Beer, linux-parisc

On 16-May-12, at 3:27 AM, James Bottomley wrote:

> On Tue, 2012-05-15 at 22:28 +0200, Helge Deller wrote:
>> On 05/15/2012 10:05 PM, John David Anglin wrote:
>>> On 5/15/2012 3:59 PM, Helge Deller wrote:
>>>> On 05/15/2012 09:46 PM, John David Anglin wrote:
>>>>> On 5/15/2012 3:24 PM, John David Anglin wrote:
>>>>>> James patch now let my 715/64 boot, but still crashes on my  
>>>>>> B160L:
>>>>>>>
>>>>>>> swapper (pid 1): Illegal instruction (code 8)
>>>>>>>
>>>>>>>     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>>>>>>> PSW: 00000000000001001110000100001111 Not tainted
>>>>>>> r00-03  0004e10f 00000020 101198cc 17c245c0
>>>>>>> r04-07  ffeff000 17ec05f8 007d4000 17e60260
>>>>>>> r08-11  17c5100b fffff000 17e60310 00020000
>>>>>>> r12-15  00000ffc 0000000b 00000000 ffeff000
>>>>>>> r16-19  007d4000 10768020 10000000 17c22db8
>>>>>>> r20-23  17c245c8 108fc000 00000001 00000020
>>>>>>> r24-27  000007d4 0f2fffe0 0000fa80 106e2020
>>>>>>> r28-31  0f2ff000 000074ee 17c24640 000072e6
>>>>>>> sr00-03  00000000 00000001 00000000 00000000
>>>>>>> sr04-07  00000000 00000000 00000000 00000000
>>>>>>>
>>>>>>> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
>>>>>>> IIR: 078113e0    ISR: 00000000  IOR: 0f2ff000
>>>>>>> CPU:        0   CR30: 17c24000 CR31: f0102978
>>>>>>> ORIG_R28: 17ebbe40
>>>>>>> IAOQ[0]: flush_icache_page_asm+0x28/0x7c
>>>>>>> IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
>>>>>>> RP(r2): flush_cache_page+0x90/0xb0
>>>>>>> Backtrace:
>>>>>> This one is in a different place: flush_icache_page_asm.  It has
>>>>>> crashed on the first fic,m instruction.  Again it is an illegal
>>>>>> instruction.
>>>>>>
>>>>> Looking at the PA 1.1 arch, I see that the space register needs  
>>>>> to be
>>>>> explicitly specified on PA 1.1 (format 26).  The implicit  
>>>>> (format 24)
>>>>> instruction was added in PA 2.0.
>>>>>
>>>>> Could you try adding %sr0 to the fic instructions?
>>>> no illegal instruction any longer, but "bad address"....
>>>> I changed all to " fic,m           %r1(%sr0,%r28)"
>>>>
>>>>
>>>>
>>>> Freeing unused kernel memory: 320k freed
>>>> Backtrace:
>>>> [<101198cc>] flush_cache_page+0x90/0xb0
>>>> [<101b9b84>] do_wp_page+0x1e0/0x7b4
>>>> [<101bb970>] handle_pte_fault+0x284/0x7c0
>>>> [<101bbf74>] handle_mm_fault+0xc8/0x120
>>>> [<10118cc8>] do_page_fault+0x228/0x2d0
>>>> [<1011a838>] handle_interruption+0x1d4/0x6c4
>>>> [<10105078>] intr_check_sig+0x0/0x34
>>>>
>>>>
>>>> Bad Address (null pointer deref?): Code=17 regs=17c244c0  
>>>> (Addr=0f17d000)
>>>>
>>>>     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>>>> PSW: 00000000000001001111100100001111 Not tainted
>>>> r00-03  0004f90f 00000020 101198cc 17c24440
>>>> r04-07  4017d4c4 17ebf498 007cd000 007cdb05
>>>> r08-11  17ebee40 17ec55f4 107eb7c0 10768020
>>>> r12-15  000007cd 17ebee74 000005f4 00050000
>>>> r16-19  17c23098 17c24140 0011849c 17c22db8
>>>> r20-23  0000004b 108fc000 00000000 00000000
>>>> r24-27  000007cd 0f17dfe0 0000f9a0 106e2020
>>>> r28-31  0f17d000 17c23098 17c244c0 6fffffff
>>>> sr00-03  00000800 00000001 00000000 00000001
>>>> sr04-07  00000000 00000000 00000000 00000000
>>>>
>>>> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
>>>> IIR: 078102a0    ISR: 00000800  IOR: 0f17d000
>>>> CPU:        0   CR30: 17c24000 CR31: f0102978
>>>> ORIG_R28: 17c51000
>>>> IAOQ[0]: flush_icache_page_asm+0x28/0x7c
>>>> IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
>>>> RP(r2): flush_cache_page+0x90/0xb0
>>>> Backtrace:
>>>> [<101198cc>] flush_cache_page+0x90/0xb0
>>>> [<101b9b84>] do_wp_page+0x1e0/0x7b4
>>>> [<101bb970>] handle_pte_fault+0x284/0x7c0
>>>> [<101bbf74>] handle_mm_fault+0xc8/0x120
>>>> [<10118cc8>] do_page_fault+0x228/0x2d0
>>>> [<1011a838>] handle_interruption+0x1d4/0x6c4
>>>> [<10105078>] intr_check_sig+0x0/0x34
>>>>
>>>>
>>>>
>>>>
>>> Try %sr2 or %sr4.  %sr0 isn't zero.
>>
>> Dave, great, you fixed it !
>> All my machines now boot the 32bit kernel.
>> %sr2 does not work since it becomes a value unequal to zero later  
>> in the
>> boot process.
>> %sr4 did worked - it's actually used further down in pacache.S in
>> flush_kernel_icache_page() as well...
>
> Right, in the two byte space encoding, which is what we usually do, a
> zero means use the correct quadrant space register (i.e. %sr4  
> through %
> sr7 depending on which quadrant we're in.  Since PA doesn't use
> quadrants, we keep them all at the space of the context - i.e. zero  
> for
> kernel).  The 24 bit form of the instruction has an explicit space
> requirement, so you have to specify manually, which means just pick  
> any
> of %sr4-%sr7 since they're always the same.

Don't forget to update the purge TLB instructions before and after the  
loop.

>> I still have the problem that my B160L "hangs" during boot after
>> starting crond - but I'm not sure if this is related to your patches
>> since the other machines do work.
>> Maybe it's just some userspace trouble....
>>
>> Will you send your patches to Linus as he requested in the other  
>> mail?
>
> I'll take care of the urgent ones once we have a set of booting  
> kernels.


Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-16 10:49                                     ` John David Anglin
@ 2012-05-16 10:57                                       ` James Bottomley
  2012-05-16 11:17                                         ` John David Anglin
  2012-05-16 11:57                                         ` Rolf Eike Beer
  0 siblings, 2 replies; 56+ messages in thread
From: James Bottomley @ 2012-05-16 10:57 UTC (permalink / raw)
  To: John David Anglin; +Cc: Helge Deller, Vincent, Rolf Eike Beer, linux-parisc

On Wed, 2012-05-16 at 06:49 -0400, John David Anglin wrote:
> On 16-May-12, at 3:27 AM, James Bottomley wrote:
> 
> > On Tue, 2012-05-15 at 22:28 +0200, Helge Deller wrote:
> >> On 05/15/2012 10:05 PM, John David Anglin wrote:
> >>> On 5/15/2012 3:59 PM, Helge Deller wrote:
> >>>> On 05/15/2012 09:46 PM, John David Anglin wrote:
> >>>>> On 5/15/2012 3:24 PM, John David Anglin wrote:
> >>>>>> James patch now let my 715/64 boot, but still crashes on my  
> >>>>>> B160L:
> >>>>>>>
> >>>>>>> swapper (pid 1): Illegal instruction (code 8)
> >>>>>>>
> >>>>>>>     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> >>>>>>> PSW: 00000000000001001110000100001111 Not tainted
> >>>>>>> r00-03  0004e10f 00000020 101198cc 17c245c0
> >>>>>>> r04-07  ffeff000 17ec05f8 007d4000 17e60260
> >>>>>>> r08-11  17c5100b fffff000 17e60310 00020000
> >>>>>>> r12-15  00000ffc 0000000b 00000000 ffeff000
> >>>>>>> r16-19  007d4000 10768020 10000000 17c22db8
> >>>>>>> r20-23  17c245c8 108fc000 00000001 00000020
> >>>>>>> r24-27  000007d4 0f2fffe0 0000fa80 106e2020
> >>>>>>> r28-31  0f2ff000 000074ee 17c24640 000072e6
> >>>>>>> sr00-03  00000000 00000001 00000000 00000000
> >>>>>>> sr04-07  00000000 00000000 00000000 00000000
> >>>>>>>
> >>>>>>> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
> >>>>>>> IIR: 078113e0    ISR: 00000000  IOR: 0f2ff000
> >>>>>>> CPU:        0   CR30: 17c24000 CR31: f0102978
> >>>>>>> ORIG_R28: 17ebbe40
> >>>>>>> IAOQ[0]: flush_icache_page_asm+0x28/0x7c
> >>>>>>> IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
> >>>>>>> RP(r2): flush_cache_page+0x90/0xb0
> >>>>>>> Backtrace:
> >>>>>> This one is in a different place: flush_icache_page_asm.  It has
> >>>>>> crashed on the first fic,m instruction.  Again it is an illegal
> >>>>>> instruction.
> >>>>>>
> >>>>> Looking at the PA 1.1 arch, I see that the space register needs  
> >>>>> to be
> >>>>> explicitly specified on PA 1.1 (format 26).  The implicit  
> >>>>> (format 24)
> >>>>> instruction was added in PA 2.0.
> >>>>>
> >>>>> Could you try adding %sr0 to the fic instructions?
> >>>> no illegal instruction any longer, but "bad address"....
> >>>> I changed all to " fic,m           %r1(%sr0,%r28)"
> >>>>
> >>>>
> >>>>
> >>>> Freeing unused kernel memory: 320k freed
> >>>> Backtrace:
> >>>> [<101198cc>] flush_cache_page+0x90/0xb0
> >>>> [<101b9b84>] do_wp_page+0x1e0/0x7b4
> >>>> [<101bb970>] handle_pte_fault+0x284/0x7c0
> >>>> [<101bbf74>] handle_mm_fault+0xc8/0x120
> >>>> [<10118cc8>] do_page_fault+0x228/0x2d0
> >>>> [<1011a838>] handle_interruption+0x1d4/0x6c4
> >>>> [<10105078>] intr_check_sig+0x0/0x34
> >>>>
> >>>>
> >>>> Bad Address (null pointer deref?): Code=17 regs=17c244c0  
> >>>> (Addr=0f17d000)
> >>>>
> >>>>     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> >>>> PSW: 00000000000001001111100100001111 Not tainted
> >>>> r00-03  0004f90f 00000020 101198cc 17c24440
> >>>> r04-07  4017d4c4 17ebf498 007cd000 007cdb05
> >>>> r08-11  17ebee40 17ec55f4 107eb7c0 10768020
> >>>> r12-15  000007cd 17ebee74 000005f4 00050000
> >>>> r16-19  17c23098 17c24140 0011849c 17c22db8
> >>>> r20-23  0000004b 108fc000 00000000 00000000
> >>>> r24-27  000007cd 0f17dfe0 0000f9a0 106e2020
> >>>> r28-31  0f17d000 17c23098 17c244c0 6fffffff
> >>>> sr00-03  00000800 00000001 00000000 00000001
> >>>> sr04-07  00000000 00000000 00000000 00000000
> >>>>
> >>>> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
> >>>> IIR: 078102a0    ISR: 00000800  IOR: 0f17d000
> >>>> CPU:        0   CR30: 17c24000 CR31: f0102978
> >>>> ORIG_R28: 17c51000
> >>>> IAOQ[0]: flush_icache_page_asm+0x28/0x7c
> >>>> IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
> >>>> RP(r2): flush_cache_page+0x90/0xb0
> >>>> Backtrace:
> >>>> [<101198cc>] flush_cache_page+0x90/0xb0
> >>>> [<101b9b84>] do_wp_page+0x1e0/0x7b4
> >>>> [<101bb970>] handle_pte_fault+0x284/0x7c0
> >>>> [<101bbf74>] handle_mm_fault+0xc8/0x120
> >>>> [<10118cc8>] do_page_fault+0x228/0x2d0
> >>>> [<1011a838>] handle_interruption+0x1d4/0x6c4
> >>>> [<10105078>] intr_check_sig+0x0/0x34
> >>>>
> >>>>
> >>>>
> >>>>
> >>> Try %sr2 or %sr4.  %sr0 isn't zero.
> >>
> >> Dave, great, you fixed it !
> >> All my machines now boot the 32bit kernel.
> >> %sr2 does not work since it becomes a value unequal to zero later  
> >> in the
> >> boot process.
> >> %sr4 did worked - it's actually used further down in pacache.S in
> >> flush_kernel_icache_page() as well...
> >
> > Right, in the two byte space encoding, which is what we usually do, a
> > zero means use the correct quadrant space register (i.e. %sr4  
> > through %
> > sr7 depending on which quadrant we're in.  Since PA doesn't use
> > quadrants, we keep them all at the space of the context - i.e. zero  
> > for
> > kernel).  The 24 bit form of the instruction has an explicit space
> > requirement, so you have to specify manually, which means just pick  
> > any
> > of %sr4-%sr7 since they're always the same.
> 
> Don't forget to update the purge TLB instructions before and after the  
> loop.

Right, this is what I have currently.

On a related note, do you want me to put you down as author of this,
since you identified the problem?

James

---

As pointed out by serveral people, PA1.1 only has a type 26 instruction
meaning that the space register must be explicitly encoded.  Not giving an
explicit space means that the compiler uses the type 24 version which is PA2.0
only resulting in an illegal instruction crash.

This regression was caused by

    commit f311847c2fcebd81912e2f0caf8a461dec28db41
    Author: James Bottomley <James.Bottomley@HansenPartnership.com>
    Date:   Wed Dec 22 10:22:11 2010 -0600

        parisc: flush pages through tmpalias space

Reported-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org	#2.6.39+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

diff --git a/arch/parisc/kernel/pacache.S b/arch/parisc/kernel/pacache.S
index 93ff3d9..f1b4c1c 100644
--- a/arch/parisc/kernel/pacache.S
+++ b/arch/parisc/kernel/pacache.S
@@ -692,7 +692,7 @@ ENTRY(flush_icache_page_asm)
 
 	/* Purge any old translation */
 
-	pitlb		(%sr0,%r28)
+	pitlb		(%sr4,%r28)
 
 	ldil		L%icache_stride, %r1
 	ldw		R%icache_stride(%r1), %r1
@@ -706,27 +706,29 @@ ENTRY(flush_icache_page_asm)
 	sub		%r25, %r1, %r25
 
 
-1:      fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
-	fic,m		%r1(%r28)
+	/* fic only has the type 24 form on PA1.1, requiring an
+	 * explicit space specification, so use %sr4 */
+1:      fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
+	fic,m		%r1(%sr4,%r28)
 	cmpb,COND(<<)		%r28, %r25,1b
-	fic,m		%r1(%r28)
+	fic,m		%r1(%sr4,%r28)
 
 	sync
 	bv		%r0(%r2)
-	pitlb		(%sr0,%r25)
+	pitlb		(%sr4,%r25)
 	.exit
 
 	.procend



^ permalink raw reply related	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-16 10:57                                       ` James Bottomley
@ 2012-05-16 11:17                                         ` John David Anglin
  2012-05-16 11:57                                         ` Rolf Eike Beer
  1 sibling, 0 replies; 56+ messages in thread
From: John David Anglin @ 2012-05-16 11:17 UTC (permalink / raw)
  To: James Bottomley; +Cc: Helge Deller, Vincent, Rolf Eike Beer, linux-parisc

Please add:

Signed-off by:  John David Anglin  <dave.anglin@bell.net>

On 16-May-12, at 6:57 AM, James Bottomley wrote:

> On Wed, 2012-05-16 at 06:49 -0400, John David Anglin wrote:
>> On 16-May-12, at 3:27 AM, James Bottomley wrote:
>>
>>> On Tue, 2012-05-15 at 22:28 +0200, Helge Deller wrote:
>>>> On 05/15/2012 10:05 PM, John David Anglin wrote:
>>>>> On 5/15/2012 3:59 PM, Helge Deller wrote:
>>>>>> On 05/15/2012 09:46 PM, John David Anglin wrote:
>>>>>>> On 5/15/2012 3:24 PM, John David Anglin wrote:
>>>>>>>> James patch now let my 715/64 boot, but still crashes on my
>>>>>>>> B160L:
>>>>>>>>>
>>>>>>>>> swapper (pid 1): Illegal instruction (code 8)
>>>>>>>>>
>>>>>>>>>    YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>>>>>>>>> PSW: 00000000000001001110000100001111 Not tainted
>>>>>>>>> r00-03  0004e10f 00000020 101198cc 17c245c0
>>>>>>>>> r04-07  ffeff000 17ec05f8 007d4000 17e60260
>>>>>>>>> r08-11  17c5100b fffff000 17e60310 00020000
>>>>>>>>> r12-15  00000ffc 0000000b 00000000 ffeff000
>>>>>>>>> r16-19  007d4000 10768020 10000000 17c22db8
>>>>>>>>> r20-23  17c245c8 108fc000 00000001 00000020
>>>>>>>>> r24-27  000007d4 0f2fffe0 0000fa80 106e2020
>>>>>>>>> r28-31  0f2ff000 000074ee 17c24640 000072e6
>>>>>>>>> sr00-03  00000000 00000001 00000000 00000000
>>>>>>>>> sr04-07  00000000 00000000 00000000 00000000
>>>>>>>>>
>>>>>>>>> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
>>>>>>>>> IIR: 078113e0    ISR: 00000000  IOR: 0f2ff000
>>>>>>>>> CPU:        0   CR30: 17c24000 CR31: f0102978
>>>>>>>>> ORIG_R28: 17ebbe40
>>>>>>>>> IAOQ[0]: flush_icache_page_asm+0x28/0x7c
>>>>>>>>> IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
>>>>>>>>> RP(r2): flush_cache_page+0x90/0xb0
>>>>>>>>> Backtrace:
>>>>>>>> This one is in a different place: flush_icache_page_asm.  It  
>>>>>>>> has
>>>>>>>> crashed on the first fic,m instruction.  Again it is an illegal
>>>>>>>> instruction.
>>>>>>>>
>>>>>>> Looking at the PA 1.1 arch, I see that the space register needs
>>>>>>> to be
>>>>>>> explicitly specified on PA 1.1 (format 26).  The implicit
>>>>>>> (format 24)
>>>>>>> instruction was added in PA 2.0.
>>>>>>>
>>>>>>> Could you try adding %sr0 to the fic instructions?
>>>>>> no illegal instruction any longer, but "bad address"....
>>>>>> I changed all to " fic,m           %r1(%sr0,%r28)"
>>>>>>
>>>>>>
>>>>>>
>>>>>> Freeing unused kernel memory: 320k freed
>>>>>> Backtrace:
>>>>>> [<101198cc>] flush_cache_page+0x90/0xb0
>>>>>> [<101b9b84>] do_wp_page+0x1e0/0x7b4
>>>>>> [<101bb970>] handle_pte_fault+0x284/0x7c0
>>>>>> [<101bbf74>] handle_mm_fault+0xc8/0x120
>>>>>> [<10118cc8>] do_page_fault+0x228/0x2d0
>>>>>> [<1011a838>] handle_interruption+0x1d4/0x6c4
>>>>>> [<10105078>] intr_check_sig+0x0/0x34
>>>>>>
>>>>>>
>>>>>> Bad Address (null pointer deref?): Code=17 regs=17c244c0
>>>>>> (Addr=0f17d000)
>>>>>>
>>>>>>    YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>>>>>> PSW: 00000000000001001111100100001111 Not tainted
>>>>>> r00-03  0004f90f 00000020 101198cc 17c24440
>>>>>> r04-07  4017d4c4 17ebf498 007cd000 007cdb05
>>>>>> r08-11  17ebee40 17ec55f4 107eb7c0 10768020
>>>>>> r12-15  000007cd 17ebee74 000005f4 00050000
>>>>>> r16-19  17c23098 17c24140 0011849c 17c22db8
>>>>>> r20-23  0000004b 108fc000 00000000 00000000
>>>>>> r24-27  000007cd 0f17dfe0 0000f9a0 106e2020
>>>>>> r28-31  0f17d000 17c23098 17c244c0 6fffffff
>>>>>> sr00-03  00000800 00000001 00000000 00000001
>>>>>> sr04-07  00000000 00000000 00000000 00000000
>>>>>>
>>>>>> IASQ: 00000000 00000000 IAOQ: 1010118c 10101190
>>>>>> IIR: 078102a0    ISR: 00000800  IOR: 0f17d000
>>>>>> CPU:        0   CR30: 17c24000 CR31: f0102978
>>>>>> ORIG_R28: 17c51000
>>>>>> IAOQ[0]: flush_icache_page_asm+0x28/0x7c
>>>>>> IAOQ[1]: flush_icache_page_asm+0x2c/0x7c
>>>>>> RP(r2): flush_cache_page+0x90/0xb0
>>>>>> Backtrace:
>>>>>> [<101198cc>] flush_cache_page+0x90/0xb0
>>>>>> [<101b9b84>] do_wp_page+0x1e0/0x7b4
>>>>>> [<101bb970>] handle_pte_fault+0x284/0x7c0
>>>>>> [<101bbf74>] handle_mm_fault+0xc8/0x120
>>>>>> [<10118cc8>] do_page_fault+0x228/0x2d0
>>>>>> [<1011a838>] handle_interruption+0x1d4/0x6c4
>>>>>> [<10105078>] intr_check_sig+0x0/0x34
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Try %sr2 or %sr4.  %sr0 isn't zero.
>>>>
>>>> Dave, great, you fixed it !
>>>> All my machines now boot the 32bit kernel.
>>>> %sr2 does not work since it becomes a value unequal to zero later
>>>> in the
>>>> boot process.
>>>> %sr4 did worked - it's actually used further down in pacache.S in
>>>> flush_kernel_icache_page() as well...
>>>
>>> Right, in the two byte space encoding, which is what we usually  
>>> do, a
>>> zero means use the correct quadrant space register (i.e. %sr4
>>> through %
>>> sr7 depending on which quadrant we're in.  Since PA doesn't use
>>> quadrants, we keep them all at the space of the context - i.e. zero
>>> for
>>> kernel).  The 24 bit form of the instruction has an explicit space
>>> requirement, so you have to specify manually, which means just pick
>>> any
>>> of %sr4-%sr7 since they're always the same.
>>
>> Don't forget to update the purge TLB instructions before and after  
>> the
>> loop.
>
> Right, this is what I have currently.
>
> On a related note, do you want me to put you down as author of this,
> since you identified the problem?
>
> James
>
> ---
>
> As pointed out by serveral people, PA1.1 only has a type 26  
> instruction
> meaning that the space register must be explicitly encoded.  Not  
> giving an
> explicit space means that the compiler uses the type 24 version  
> which is PA2.0
> only resulting in an illegal instruction crash.
>
> This regression was caused by
>
>    commit f311847c2fcebd81912e2f0caf8a461dec28db41
>    Author: James Bottomley <James.Bottomley@HansenPartnership.com>
>    Date:   Wed Dec 22 10:22:11 2010 -0600
>
>        parisc: flush pages through tmpalias space
>
> Reported-by: Helge Deller <deller@gmx.de>
> Cc: stable@vger.kernel.org	#2.6.39+
> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
>
> diff --git a/arch/parisc/kernel/pacache.S b/arch/parisc/kernel/ 
> pacache.S
> index 93ff3d9..f1b4c1c 100644
> --- a/arch/parisc/kernel/pacache.S
> +++ b/arch/parisc/kernel/pacache.S
> @@ -692,7 +692,7 @@ ENTRY(flush_icache_page_asm)
>
> 	/* Purge any old translation */
>
> -	pitlb		(%sr0,%r28)
> +	pitlb		(%sr4,%r28)
>
> 	ldil		L%icache_stride, %r1
> 	ldw		R%icache_stride(%r1), %r1
> @@ -706,27 +706,29 @@ ENTRY(flush_icache_page_asm)
> 	sub		%r25, %r1, %r25
>
>
> -1:      fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> -	fic,m		%r1(%r28)
> +	/* fic only has the type 24 form on PA1.1, requiring an
> +	 * explicit space specification, so use %sr4 */
> +1:      fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> +	fic,m		%r1(%sr4,%r28)
> 	cmpb,COND(<<)		%r28, %r25,1b
> -	fic,m		%r1(%r28)
> +	fic,m		%r1(%sr4,%r28)
>
> 	sync
> 	bv		%r0(%r2)
> -	pitlb		(%sr0,%r25)
> +	pitlb		(%sr4,%r25)
> 	.exit
>
> 	.procend
>
>
>


Thanks,
Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-16 10:57                                       ` James Bottomley
  2012-05-16 11:17                                         ` John David Anglin
@ 2012-05-16 11:57                                         ` Rolf Eike Beer
  2012-05-16 12:24                                           ` James Bottomley
  1 sibling, 1 reply; 56+ messages in thread
From: Rolf Eike Beer @ 2012-05-16 11:57 UTC (permalink / raw)
  To: James Bottomley; +Cc: John David Anglin, Helge Deller, Vincent, linux-parisc

> As pointed out by serveral people, PA1.1 only has a type 26 instruction
> meaning that the space register must be explicitly encoded.  Not giving an
> explicit space means that the compiler uses the type 24 version which is
> PA2.0
> only resulting in an illegal instruction crash.

> +	/* fic only has the type 24 form on PA1.1, requiring an
> +	 * explicit space specification, so use %sr4 */

Once you say 2.0 and once 1.1, I assume the latter is a typo?

Eike

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-16 11:57                                         ` Rolf Eike Beer
@ 2012-05-16 12:24                                           ` James Bottomley
  0 siblings, 0 replies; 56+ messages in thread
From: James Bottomley @ 2012-05-16 12:24 UTC (permalink / raw)
  To: Rolf Eike Beer; +Cc: John David Anglin, Helge Deller, Vincent, linux-parisc

On Wed, 2012-05-16 at 13:57 +0200, Rolf Eike Beer wrote:
> > As pointed out by serveral people, PA1.1 only has a type 26 instruction
> > meaning that the space register must be explicitly encoded.  Not giving an
> > explicit space means that the compiler uses the type 24 version which is
> > PA2.0
> > only resulting in an illegal instruction crash.
> 
> > +	/* fic only has the type 24 form on PA1.1, requiring an
> > +	 * explicit space specification, so use %sr4 */
> 
> Once you say 2.0 and once 1.1, I assume the latter is a typo?

Yes, it should be 26 ... I already fixed this up before pushing it out.

James



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 20:48                                   ` John David Anglin
@ 2012-05-16 14:59                                     ` James Bottomley
  2012-05-17 19:26                                     ` Helge Deller
  1 sibling, 0 replies; 56+ messages in thread
From: James Bottomley @ 2012-05-16 14:59 UTC (permalink / raw)
  To: John David Anglin; +Cc: Helge Deller, Vincent, Rolf Eike Beer, linux-parisc

On Tue, 2012-05-15 at 16:48 -0400, John David Anglin wrote:
> On 5/15/2012 4:28 PM, Helge Deller wrote:
> > Will you send your patches to Linus as he requested in the other mail?
> You have the diff for the two PA 1.1 changes.  Suggest you send them.
> I think these should go to stable as well as soon as it is verified that all
> targets boot.
> 
> I think my cache-2 is more appropriate for linux-next.  There are a number
> of subtle issues with it.  I am pleased that the users that have tried 
> it have
> been generally happy with it.

So to be a patch for the linux kernel, it really needs to be divided up
into its components.  It looks like cache-2 is a combination of five or
six separate things, and each one needs a change long.

James



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 21:01                     ` Vincent
@ 2012-05-16 19:07                       ` Helge Deller
  0 siblings, 0 replies; 56+ messages in thread
From: Helge Deller @ 2012-05-16 19:07 UTC (permalink / raw)
  To: Vincent; +Cc: James Bottomley, John David Anglin, Rolf Eike Beer, linux-parisc

On 05/15/2012 11:01 PM, Vincent wrote:
> On 05/15/2012 11:13 AM, James Bottomley wrote:
> (..)
>> OK, I think this is the problem.  We have a depd instruction in do_alias
>> which is now in the _11 fault paths.
>>
>> This should be the fix, if someone wants to test it before I can get
>> around to building it.
> Hi James,
>
> This makes my hp712 boot now; congrats!
>
> Works for me with v3.4-rc6 and v3.4-rc7, with the following "patches pile":
>
> depd patch     (http://www.spinics.net/lists/linux-parisc/msg04169.html)
> sections patch (http://www.spinics.net/lists/linux-parisc/msg04091.html)
> cache patch    (http://www.spinics.net/lists/linux-parisc/msg04120.html)
> v3.4-rc7
I can confirm that the "sections patch" mentioned above is needed for my 
B160L as well.
It probably happens since I build a monolithic kernel with all needed 
modules built-in.

@James: Any chance to include this patch (or a similar one) into your 
fixes branch?

BTW, I still have issues with the B160L hanging after starting crond.... 
looking into it now...

Helge



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-15 20:48                                   ` John David Anglin
  2012-05-16 14:59                                     ` James Bottomley
@ 2012-05-17 19:26                                     ` Helge Deller
  2012-05-17 19:57                                       ` Rolf Eike Beer
  2012-05-18  8:12                                       ` James Bottomley
  1 sibling, 2 replies; 56+ messages in thread
From: Helge Deller @ 2012-05-17 19:26 UTC (permalink / raw)
  To: John David Anglin; +Cc: James Bottomley, Vincent, Rolf Eike Beer, linux-parisc

On 05/15/2012 10:48 PM, John David Anglin wrote:
> We need to debug why your B160L hangs.  Can you kill whatever hangs
> from the console?  Sometimes the application is still in the foreground.

Ok, the B160L problem is gone now.
I found the reason for this bug between the chair and the monitor :-)   
(it was my fault - sorry .... )

But I think we still have a problem.
I'm using 3.4.0-rc7, have pulled all fixes from James "fixes" branch, 
and Dave's "vmlinux.lds" patch.

The 32bit machines (715/64 and B160L) boot nicely into userspace.
The 64bit machine (C3000) crashes directly when switching to userspace.

Do we still have another problem somewhere?
Or is it introduced because of the vmlinux.lds patch?
(Reminder: without the vmlinux.lds patch the C3000 hangs directly at 
bootup after printing memory information...)

Helge

VFS: Mounted root (ext3 filesystem) readonly on device 8:3.
Freeing unused kernel memory: 316k freed
Backtrace:
  [<10119560>] clear_user_page_asm+0x44/0x6c
  [<101195dc>] clear_user_page+0x54/0x6c
  [<101bbaa8>] handle_pte_fault+0x5dc/0x7a8
  [<101bbd3c>] handle_mm_fault+0xc8/0x120
  [<101bbffc>] __get_user_pages+0x160/0x3c4
  [<101bc348>] get_user_pages+0x50/0x60
  [<101e169c>] get_arg_page+0x64/0xe8
  [<101e182c>] copy_strings+0x10c/0x248
  [<101e1990>] copy_strings_kernel+0x28/0x44
  [<101e328c>] do_execve+0x2a0/0x36c
  [<10120424>] sys_execve+0x44/0x7c
  [<10104084>] __execve+0x20/0x34
  [<10133b9c>] vprintk+0x1d8/0x4f4
  [<10133ee8>] printk+0x30/0x40
  [<10118550>] free_initmem+0x154/0x184
  [<10117cbc>] init_post+0xa0/0xd4


Kernel Fault: Code=26 regs=8fc30940 (Addr=0f2ff000)

      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001101111111100001110 Not tainted
r00-03  0006ff0e 00000040 10119560 8fc308c0
r04-07  106e5820 107d2000 0000000f 10768020
r08-11  ffeffff1 8fd00ffc 8f49ce40 00000001
r12-15  00000000 00000017 00000001 00000000
r16-19  00004400 00000020 00000000 ffffffff
r20-23  00000000 00000000 00000001 00000040
r24-27  1090aa40 ffeffff1 0000fa40 106e2020
r28-31  0f2ff000 0007d882 8fc30940 0007d024
sr00-03  00000000 00000000 00000000 00000000
sr04-07  00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 10100eec 10100ef0
  IIR: 0f801280    ISR: 00000000  IOR: 0f2ff000
  CPU:        0   CR30: 8fc30000 CR31: de9345e0
  ORIG_R28: 8f812728
  IAOQ[0]: __clear_user_page_asm+0x20/0x70
  IAOQ[1]: __clear_user_page_asm+0x24/0x70
  RP(r2): clear_user_page_asm+0x44/0x6c
Backtrace:
  [<10119560>] clear_user_page_asm+0x44/0x6c
  [<101195dc>] clear_user_page+0x54/0x6c
  [<101bbaa8>] handle_pte_fault+0x5dc/0x7a8
  [<101bbd3c>] handle_mm_fault+0xc8/0x120
  [<101bbffc>] __get_user_pages+0x160/0x3c4
  [<101bc348>] get_user_pages+0x50/0x60
  [<101e169c>] get_arg_page+0x64/0xe8
  [<101e182c>] copy_strings+0x10c/0x248
  [<101e1990>] copy_strings_kernel+0x28/0x44
  [<101e328c>] do_execve+0x2a0/0x36c
  [<10120424>] sys_execve+0x44/0x7c
  [<10104084>] __execve+0x20/0x34
  [<10133b9c>] vprintk+0x1d8/0x4f4
  [<10133ee8>] printk+0x30/0x40
  [<10118550>] free_initmem+0x154/0x184
  [<10117cbc>] init_post+0xa0/0xd4

Kernel panic - not syncing: Kernel Fault


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-17 19:26                                     ` Helge Deller
@ 2012-05-17 19:57                                       ` Rolf Eike Beer
  2012-05-18  8:12                                       ` James Bottomley
  1 sibling, 0 replies; 56+ messages in thread
From: Rolf Eike Beer @ 2012-05-17 19:57 UTC (permalink / raw)
  To: Helge Deller; +Cc: John David Anglin, James Bottomley, Vincent, linux-parisc

> On 05/15/2012 10:48 PM, John David Anglin wrote:
>> We need to debug why your B160L hangs.  Can you kill whatever hangs
>> from the console?  Sometimes the application is still in the foreground.
>
> Ok, the B160L problem is gone now.
> I found the reason for this bug between the chair and the monitor :-)
> (it was my fault - sorry .... )
>
> But I think we still have a problem.
> I'm using 3.4.0-rc7, have pulled all fixes from James "fixes" branch,
> and Dave's "vmlinux.lds" patch.
>
> The 32bit machines (715/64 and B160L) boot nicely into userspace.
> The 64bit machine (C3000) crashes directly when switching to userspace.
>
> Do we still have another problem somewhere?
> Or is it introduced because of the vmlinux.lds patch?
> (Reminder: without the vmlinux.lds patch the C3000 hangs directly at
> bootup after printing memory information...)
>
> Helge
>
> VFS: Mounted root (ext3 filesystem) readonly on device 8:3.
> Freeing unused kernel memory: 316k freed
> Backtrace:
>   [<10119560>] clear_user_page_asm+0x44/0x6c
>   [<101195dc>] clear_user_page+0x54/0x6c
>   [<101bbaa8>] handle_pte_fault+0x5dc/0x7a8
>   [<101bbd3c>] handle_mm_fault+0xc8/0x120
>   [<101bbffc>] __get_user_pages+0x160/0x3c4
>   [<101bc348>] get_user_pages+0x50/0x60
>   [<101e169c>] get_arg_page+0x64/0xe8
>   [<101e182c>] copy_strings+0x10c/0x248
>   [<101e1990>] copy_strings_kernel+0x28/0x44
>   [<101e328c>] do_execve+0x2a0/0x36c
>   [<10120424>] sys_execve+0x44/0x7c
>   [<10104084>] __execve+0x20/0x34
>   [<10133b9c>] vprintk+0x1d8/0x4f4
>   [<10133ee8>] printk+0x30/0x40
>   [<10118550>] free_initmem+0x154/0x184
>   [<10117cbc>] init_post+0xa0/0xd4
>
>
> Kernel Fault: Code=26 regs=8fc30940 (Addr=0f2ff000)
>
>       YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001101111111100001110 Not tainted
> r00-03  0006ff0e 00000040 10119560 8fc308c0
> r04-07  106e5820 107d2000 0000000f 10768020
> r08-11  ffeffff1 8fd00ffc 8f49ce40 00000001
> r12-15  00000000 00000017 00000001 00000000
> r16-19  00004400 00000020 00000000 ffffffff
> r20-23  00000000 00000000 00000001 00000040
> r24-27  1090aa40 ffeffff1 0000fa40 106e2020
> r28-31  0f2ff000 0007d882 8fc30940 0007d024
> sr00-03  00000000 00000000 00000000 00000000
> sr04-07  00000000 00000000 00000000 00000000
>
> IASQ: 00000000 00000000 IAOQ: 10100eec 10100ef0
>   IIR: 0f801280    ISR: 00000000  IOR: 0f2ff000
>   CPU:        0   CR30: 8fc30000 CR31: de9345e0
>   ORIG_R28: 8f812728
>   IAOQ[0]: __clear_user_page_asm+0x20/0x70
>   IAOQ[1]: __clear_user_page_asm+0x24/0x70
>   RP(r2): clear_user_page_asm+0x44/0x6c
> Backtrace:
>   [<10119560>] clear_user_page_asm+0x44/0x6c
>   [<101195dc>] clear_user_page+0x54/0x6c
>   [<101bbaa8>] handle_pte_fault+0x5dc/0x7a8

Looks basically as if we are back at the start, no? Because the initial
problem was only a few instructions away. So, did we change the 64 bit
assembly in any way?

Eike

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-17 19:26                                     ` Helge Deller
  2012-05-17 19:57                                       ` Rolf Eike Beer
@ 2012-05-18  8:12                                       ` James Bottomley
  2012-05-18 21:09                                         ` Helge Deller
  1 sibling, 1 reply; 56+ messages in thread
From: James Bottomley @ 2012-05-18  8:12 UTC (permalink / raw)
  To: Helge Deller; +Cc: John David Anglin, Vincent, Rolf Eike Beer, linux-parisc

On Thu, 2012-05-17 at 21:26 +0200, Helge Deller wrote:
> On 05/15/2012 10:48 PM, John David Anglin wrote:
> > We need to debug why your B160L hangs.  Can you kill whatever hangs
> > from the console?  Sometimes the application is still in the foreground.
> 
> Ok, the B160L problem is gone now.
> I found the reason for this bug between the chair and the monitor :-)   
> (it was my fault - sorry .... )
> 
> But I think we still have a problem.
> I'm using 3.4.0-rc7, have pulled all fixes from James "fixes" branch, 
> and Dave's "vmlinux.lds" patch.
> 
> The 32bit machines (715/64 and B160L) boot nicely into userspace.
> The 64bit machine (C3000) crashes directly when switching to userspace.
> 
> Do we still have another problem somewhere?
> Or is it introduced because of the vmlinux.lds patch?
> (Reminder: without the vmlinux.lds patch the C3000 hangs directly at 
> bootup after printing memory information...)

I'm not seeing it on my rp3410 ... I'm going to have to find the J box
(which I think is closest to your C3000 ... that's an astro system) and
boot it.

> Helge
> 
> VFS: Mounted root (ext3 filesystem) readonly on device 8:3.
> Freeing unused kernel memory: 316k freed
> Backtrace:
>   [<10119560>] clear_user_page_asm+0x44/0x6c
>   [<101195dc>] clear_user_page+0x54/0x6c
>   [<101bbaa8>] handle_pte_fault+0x5dc/0x7a8
>   [<101bbd3c>] handle_mm_fault+0xc8/0x120
>   [<101bbffc>] __get_user_pages+0x160/0x3c4
>   [<101bc348>] get_user_pages+0x50/0x60
>   [<101e169c>] get_arg_page+0x64/0xe8
>   [<101e182c>] copy_strings+0x10c/0x248
>   [<101e1990>] copy_strings_kernel+0x28/0x44
>   [<101e328c>] do_execve+0x2a0/0x36c
>   [<10120424>] sys_execve+0x44/0x7c
>   [<10104084>] __execve+0x20/0x34
>   [<10133b9c>] vprintk+0x1d8/0x4f4
>   [<10133ee8>] printk+0x30/0x40
>   [<10118550>] free_initmem+0x154/0x184
>   [<10117cbc>] init_post+0xa0/0xd4
> 
> 
> Kernel Fault: Code=26 regs=8fc30940 (Addr=0f2ff000)
> 
>       YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001101111111100001110 Not tainted
> r00-03  0006ff0e 00000040 10119560 8fc308c0
> r04-07  106e5820 107d2000 0000000f 10768020
> r08-11  ffeffff1 8fd00ffc 8f49ce40 00000001
> r12-15  00000000 00000017 00000001 00000000
> r16-19  00004400 00000020 00000000 ffffffff
> r20-23  00000000 00000000 00000001 00000040
> r24-27  1090aa40 ffeffff1 0000fa40 106e2020
> r28-31  0f2ff000 0007d882 8fc30940 0007d024
> sr00-03  00000000 00000000 00000000 00000000
> sr04-07  00000000 00000000 00000000 00000000
> 
> IASQ: 00000000 00000000 IAOQ: 10100eec 10100ef0
>   IIR: 0f801280    ISR: 00000000  IOR: 0f2ff000
>   CPU:        0   CR30: 8fc30000 CR31: de9345e0
>   ORIG_R28: 8f812728
>   IAOQ[0]: __clear_user_page_asm+0x20/0x70
>   IAOQ[1]: __clear_user_page_asm+0x24/0x70
>   RP(r2): clear_user_page_asm+0x44/0x6c
> Backtrace:
>   [<10119560>] clear_user_page_asm+0x44/0x6c
>   [<101195dc>] clear_user_page+0x54/0x6c
>   [<101bbaa8>] handle_pte_fault+0x5dc/0x7a8
>   [<101bbd3c>] handle_mm_fault+0xc8/0x120
>   [<101bbffc>] __get_user_pages+0x160/0x3c4
>   [<101bc348>] get_user_pages+0x50/0x60
>   [<101e169c>] get_arg_page+0x64/0xe8
>   [<101e182c>] copy_strings+0x10c/0x248
>   [<101e1990>] copy_strings_kernel+0x28/0x44
>   [<101e328c>] do_execve+0x2a0/0x36c
>   [<10120424>] sys_execve+0x44/0x7c
>   [<10104084>] __execve+0x20/0x34
>   [<10133b9c>] vprintk+0x1d8/0x4f4
>   [<10133ee8>] printk+0x30/0x40
>   [<10118550>] free_initmem+0x154/0x184
>   [<10117cbc>] init_post+0xa0/0xd4
> 
> Kernel panic - not syncing: Kernel Fault

What this says is something went wrong in the tmpalias space because it
fell through to the fault path.  How much memory does this system have
(and what's the layout map)?  It's 64 bit but you're booting it with a
32 bit kernel ... I'm wondering if there's no space for tmpalias.

James



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-18  8:12                                       ` James Bottomley
@ 2012-05-18 21:09                                         ` Helge Deller
  2012-05-20 10:01                                           ` James Bottomley
  0 siblings, 1 reply; 56+ messages in thread
From: Helge Deller @ 2012-05-18 21:09 UTC (permalink / raw)
  To: James Bottomley; +Cc: John David Anglin, Vincent, Rolf Eike Beer, linux-parisc

On 05/18/2012 10:12 AM, James Bottomley wrote:
> On Thu, 2012-05-17 at 21:26 +0200, Helge Deller wrote:
>> But I think we still have a problem.
>> I'm using 3.4.0-rc7, have pulled all fixes from James "fixes" branch,
>> and Dave's "vmlinux.lds" patch.
>>
>> The 32bit machines (715/64 and B160L) boot nicely into userspace.
>> The 64bit machine (C3000) crashes directly when switching to userspace.
>>
>> Do we still have another problem somewhere?
>> Or is it introduced because of the vmlinux.lds patch?
>> (Reminder: without the vmlinux.lds patch the C3000 hangs directly at
>> bootup after printing memory information...)
> I'm not seeing it on my rp3410 ... I'm going to have to find the J box
> (which I think is closest to your C3000 ... that's an astro system) and
> boot it.
[crash log removed - new one see below]
> What this says is something went wrong in the tmpalias space because 
> it fell through to the fault path. How much memory does this system 
> have (and what's the layout map)? It's 64 bit but you're booting it 
> with a 32 bit kernel ... I'm wondering if there's no space for 
> tmpalias. James 

James, here is the full kernel log. Does this help?

---
Selected kernel: /vmlinux from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing...
This box can boot either 32 or 64-bit kernels...Only see a 32-bit 
kernel, using thatELF32 executable
Entry 00100000 first 00100000 n 3
Segment 0 load 00100000 size 6549504 mediaptr 0x1000
Segment 1 load 00788000 size 175988 mediaptr 0x640000
Segment 2 load 007b3000 size 144916 mediaptr 0x66b000
Branching to kernel entry point 0x00100000.  If this is the last
message you see, you may need to switch your console.  This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.4.0-rc7-32bit+ (deller@p100) (gcc version 4.6.4 20120514 
(prerelease) (GCC) ) #10 Thu May 17 21:12:16 CEST 2012
unwind_init: start = 0x10690000, end = 0x106d5170, entries = 17687
FP[0] enabled: Rev 1 Model 19
The 32-bit Kernel has started...
bootconsole [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: System Map.
model 00005dc0 00000481 00000000 00000002 777c3e84 100000f0 00000008 
000000b2 000000b2
vers  00000301
CPUID vers 19 rev 11 (0x0000026b)
capabilities 0x7
model 9000/785/C3700
Total Memory: 2048 MB
LCD display at f05d0008,f05d0000 registered
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 520192
Kernel command line: HOME=/ root=/dev/sda3 pa64root=sda5 b160Lroot=sda5 
ip=bootp panic_timeout=60 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
allocated 4194304 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Memory: 2065896k/2097152k available (4404k kernel code, 31256k reserved, 
1969k data, 316k init)
virtual kernel memory layout:
     vmalloc : 0x00008000 - 0x0f000000   ( 239 MB)
     memory  : 0x10000000 - 0x90000000   (2048 MB)
       .init : 0x10788000 - 0x107d7000   ( 316 kB)
       .data : 0x1054d304 - 0x10739770   (1969 kB)
       .text : 0x10100000 - 0x1054d304   (4404 kB)
NR_IRQS:96
Console: colour dummy device 128x48
Calibrating delay loop... 1495.85 BogoMIPS (lpj=7479296)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys blkio
xor: measuring software checksum speed
    8regs     :  1822.000 MB/sec
    8regs_prefetch:  1798.400 MB/sec
    32regs    :  1443.600 MB/sec
    32regs_prefetch:  1442.800 MB/sec
xor: using function: 8regs (1822.000 MB/sec)
atomic64 test passed
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Found devices:
1. Astro BC Runway Port at 0xfed00000 [10] { 12, 0x0, 0x582, 0x0000b }
2. Elroy PCI Bridge at 0xfed30000 [10/0] { 13, 0x0, 0x782, 0x0000a }
3. Elroy PCI Bridge at 0xfed32000 [10/1] { 13, 0x0, 0x782, 0x0000a }
4. Elroy PCI Bridge at 0xfed38000 [10/4] { 13, 0x0, 0x782, 0x0000a }
5. Elroy PCI Bridge at 0xfed3c000 [10/6] { 13, 0x0, 0x782, 0x0000a }
6. Allegro W2 at 0xfffa0000 [32] { 0, 0x0, 0x5dc, 0x00004 }
7. Memory at 0xfed10200 [49] { 1, 0x0, 0x09c, 0x00009 }
CPU(s): 1 x PA8700 (PCX-W2) at 750.000000 MHz
Setting cache flush threshold to 1a0 (1 CPUs online)
SBA found Astro 2.1 at 0xfed00000
Elroy version TR4.0 (0x5) found at 0xfed30000
LBA 10:0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0x1fff]
pci_bus 0000:00: root bus resource [mem 0xf2000000-0xf23fffff]
PCI: Enabled native mode for NS87415 (pif=0x8f)
Elroy version TR4.0 (0x5) found at 0xfed32000
LBA 10:1: PCI host bridge to bus 0000:01
pci_bus 0000:01: root bus resource [io  0x12000-0x13fff] (bus address 
[0x2000-0x3fff])
pci_bus 0000:01: root bus resource [mem 0xf6000000-0xf6ffffff]
pci_bus 0000:01: root bus resource [mem 0xf2400000-0xf27fffff]
pci 0000:01:04.0: no compatible bridge window for [mem 
0xf6000000-0xf7ffffff]
iosapic: no IRTE for 0000:01:04.0 (IRQ not connected?)
pci 0000:01:05.0: no compatible bridge window for [mem 
0xf8000000-0xf8ffffff pref]
iosapic: no IRTE for 0000:01:05.0 (IRQ not connected?)
pci 0000:01:06.0: PCI bridge to [bus 02-ff]
pci 0000:01:06.0: can't handle 64-bit address space for bridge
pci 0000:01:06.0: no compatible bridge window for [??? 0x00000000 flags 0x0]
pci 0000:01:06.0: no compatible bridge window for [mem 
0xf9000000-0xfbffffff]
pci 0000:01:06.0: no compatible bridge window for [??? 0x00000000 flags 0x0]
pci 0000:01:06.0: no compatible bridge window for [??? 0x00000000 flags 0x0]
pci 0000:01:06.0: device not available (can't reserve [mem 
0xf9000000-0xfbffffff])
pci 0000:01:06.0: Error enabling bridge (-22), continuing
Elroy version TR4.0 (0x5) found at 0xfed38000
LBA 10:4: PCI host bridge to bus 0000:03
pci_bus 0000:03: root bus resource [io  0x28000-0x29fff] (bus address 
[0x8000-0x9fff])
pci_bus 0000:03: root bus resource [mem 0xf3000000-0xf33fffff]
Elroy version TR4.0 (0x5) found at 0xfed3c000
LBA 10:6: PCI host bridge to bus 0000:04
pci_bus 0000:04: root bus resource [io  0x3c000-0x3dfff] (bus address 
[0xc000-0xdfff])
pci_bus 0000:04: root bus resource [mem 0xf4000000-0xf5ffffff]
pci_bus 0000:04: root bus resource [mem 0xf3800000-0xf3bfffff]
iosapic: hpa not registered for 0000:04:02.0
powersw: Soft power switch at 0xf0400804 enabled.
bio: create slab <bio-0> at 0
raid6: int32x1    393 MB/s
raid6: int32x2    481 MB/s
raid6: int32x4    524 MB/s
raid6: int32x8    478 MB/s
raid6: using algorithm int32x4 (524 MB/s)
vgaarb: device added: PCI:0000:02:00.0,decodes=io+mem,owns=none,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:02:00.0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource cr16
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 8, 1310720 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP: reno registered
UDP hash table entries: 1024 (order: 3, 49152 bytes)
UDP-Lite hash table entries: 1024 (order: 3, 49152 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
SuperIO: Found NS87560 Legacy I/O device at 0000:00:0e.1 (IRQ 67)
SuperIO: Serial port 1 at 0x3f8
SuperIO: Serial port 2 at 0x2f8
SuperIO: Parallel port at 0x378
SuperIO: Floppy controller at 0x3f0
SuperIO: ACPI at 0x7e0
SuperIO: USB regulator enabled
Enabling PDC chassis warnings support v0.05
Initializing RT-Tester: OK
====[ backtrace testing ]===========
Testing a backtrace from process context.
The following trace is a kernel self test and not a bug!
Backtrace:
  [<10119bc8>] dump_stack+0x1c/0x2c
  [<1017d35c>] backtrace_regression_test+0x44/0x124
  [<10117f48>] do_one_initcall+0x258/0x2b8
  [<1078a208>] kernel_init+0x184/0x214
  [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a backtrace from irq context.
The following trace is a kernel self test and not a bug!
Backtrace:
  [<10119bc8>] dump_stack+0x1c/0x2c
  [<1017d2f8>] backtrace_test_irq_callback+0x18/0x38
  [<10139840>] tasklet_action+0x78/0xdc
  [<10139dd4>] __do_softirq+0x130/0x17c
  [<10139e90>] run_ksoftirqd+0x70/0x124
  [<101512f4>] kthread+0xac/0xb4
  [<1010405c>] ret_from_kernel_thread+0x1c/0x24

Testing a saved backtrace.
The following trace is a kernel self test and not a bug!
  [<101234b0>] save_stack_trace+0x28/0x60
  [<1017d408>] backtrace_regression_test+0xf0/0x124
  [<10117f48>] do_one_initcall+0x258/0x2b8
  [<1078a208>] kernel_init+0x184/0x214
  [<1010405c>] ret_from_kernel_thread+0x1c/0x24
  [<ffffffff>] 0xffffffff
====[ end of backtrace testing ]====
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
msgmni has been set to 4034
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
start plist test
end plist test
PDC Stable Storage facility v0.30
STI GSC/PCI core graphics driver Version 0.9a
sti 0000:01:04.0: device not available (can't reserve [mem 
0xf6000000-0xf7ffffff])
sti 0000:01:04.0: Cannot enable PCI device
sti: probe of 0000:01:04.0 failed with error -22
STI PCI graphic ROM found at f3800000 (2048 kB), fb at f4000000 (32 MB)
     id 35acda30-9a02587, conforms to spec rev. 8.0d
     graphics card name: A1262A
sticon: Initializing STI text console.
Console: switching to colour STI console 128x48
matroxfb 0000:02:00.0: enabling SERR and PARITY (0007 -> 0147)
matroxfb: Matrox G450 detected
PInS memtype = 4
matroxfb: cannot determine memory size
matroxfb: probe of 0000:02:00.0 failed with error -1
stifb: 'A1262A' (id: 0x35acda30) not supported.
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 3) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
serial8250: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
Linux agpgart interface v0.103
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
ns87415 0000:00:0e.0: IDE controller (0x100b:0x0002 rev 0x03)
ns87415 0000:00:0e.0: 100% native mode on irq 7
     ide0: BM-DMA at 0x0a00-0x0a07
     ide1: BM-DMA at 0x0a08-0x0a0f
hda: CD-532E-B, ATAPI CD/DVD-ROM drive
ide0 at 0xf00-0xf07,0xe02 on irq 7
ide1 at 0xd00-0xd07,0xb02 on irq 7
ide-gd driver 1.18
ide-cd driver 5.00
ide-cd: hda: ATAPI 32X CD-ROM drive, 128kB Cache
cdrom: Uniform CD-ROM driver Revision: 3.20
sym0: <896> rev 0x7 at pci 0000:00:0f.0 irq 68
sym0: PA-RISC Firmware, ID 7, Fast-40, SE, parity checking
sym0: SCSI BUS has been reset.
sym0: SCSI BUS mode change from SE to SE.
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.3
sym1: <896> rev 0x7 at pci 0000:00:0f.1 irq 68
sym1: PA-RISC Firmware, ID 7, Fast-40, LVD, parity checking
sym1: SCSI BUS has been reset.
scsi1 : sym-2.2.3
scsi 1:0:5:0: Direct-Access     SEAGATE  ST39102LC        HP01 PQ: 0 ANSI: 2
scsi target1:0:5: tagged command queuing enabled, command queue depth 16.
scsi target1:0:5: Beginning Domain Validation
scsi target1:0:5: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 15)
scsi target1:0:5: Domain Validation skipping write tests
scsi target1:0:5: Ending Domain Validation
scsi 1:0:6:0: Direct-Access     HP 36.4G ST336607LC       HPC3 PQ: 0 ANSI: 3
scsi target1:0:6: tagged command queuing enabled, command queue depth 16.
scsi target1:0:6: Beginning Domain Validation
scsi target1:0:6: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
scsi target1:0:6: Domain Validation skipping write tests
scsi target1:0:6: Ending Domain Validation
st: Version 20101219, fixed bufsize 32768, s/g segs 256
sd 1:0:5:0: Attached scsi generic sg0 type 0
sd 1:0:6:0: Attached scsi generic sg1 type 0
Linux Tulip driver version 1.1.15 (Feb 27, 2007)
tulip0: no phy info, aborting mtable build
tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1
net eth0: Digital DS21142/43 Tulip rev 65 at Port 0x1000, 
00:30:6e:48:aa:64, IRQ 65
tulip1: EEPROM default media type Autosense
tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block
tulip1: Index #1 - Media 10base2 (#1) described by a 21142 Serial PHY 
(2) block
tulip1: Index #2 - Media AUI (#2) described by a 21142 Serial PHY (2) block
tulip1:  MII transceiver #1 config 3100 status 7849 advertising 0101
sd 1:0:5:0: [sda] 17773524 512-byte logical blocks: (9.10 GB/8.47 GiB)
sd 1:0:6:0: [sdb] 71132960 512-byte logical blocks: (36.4 GB/33.9 GiB)
sd 1:0:5:0: [sda] Write Protect is off
sd 1:0:6:0: [sdb] Write Protect is off
net eth1: Digital DS21142/43 Tulip rev 33 at Port 0x28000, 
00:60:b0:7a:12:89, IRQ 71
LASI 82596 driver - Revision: 1.30
sd 1:0:5:0: [sda] Write cache: disabled, read cache: enabled, supports 
DPO and FUA
sd 1:0:6:0: [sdb] Write cache: disabled, read cache: enabled, supports 
DPO and FUA
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:0e.2: OHCI Host Controller
ohci_hcd 0000:00:0e.2: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:0e.2: irq 1, io mem 0xf2007000
  sda: sda1 sda2 sda3 sda4
  sdb: sdb1 sdb2 sdb3 sdb4
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: OHCI Host Controller
usb usb1: Manufacturer: Linux 3.4.0-rc7-32bit+ ohci_hcd
usb usb1: SerialNumber: 0000:00:0e.2
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
uhci_hcd: USB Universal Host Controller Interface driver
mousedev: PS/2 mouse device common for all mice
sd 1:0:6:0: [sdb] Attached SCSI disk
sd 1:0:5:0: [sda] Attached SCSI disk
rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid10 personality registered for level 10
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: 
dm-devel@redhat.com
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using timer interrupt.
TCP: cubic registered
NET: Registered protocol family 17
rtc-generic rtc-generic: setting system clock to 2012-05-18 21:06:15 UTC 
(1337375175)
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 192.168.178.50, my address is 
192.168.178.66
IP-Config: Complete:
      device=eth0, addr=192.168.178.66, mask=255.255.255.0, gw=192.168.178.1
      host=c3000, domain=box, nis-domain=(none)
      bootserver=192.168.178.50, rootserver=192.168.178.50, rootpath=
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sda3): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) readonly on device 8:3.
Freeing unused kernel memory: 316k freed
Backtrace:
  [<10119560>] clear_user_page_asm+0x44/0x6c
  [<101195dc>] clear_user_page+0x54/0x6c
  [<101bbaa8>] handle_pte_fault+0x5dc/0x7a8
  [<101bbd3c>] handle_mm_fault+0xc8/0x120
  [<101bbffc>] __get_user_pages+0x160/0x3c4
  [<101bc348>] get_user_pages+0x50/0x60
  [<101e169c>] get_arg_page+0x64/0xe8
  [<101e182c>] copy_strings+0x10c/0x248
  [<101e1990>] copy_strings_kernel+0x28/0x44
  [<101e328c>] do_execve+0x2a0/0x36c
  [<10120424>] sys_execve+0x44/0x7c
  [<10104084>] __execve+0x20/0x34
  [<10133b9c>] vprintk+0x1d8/0x4f4
  [<10133ee8>] printk+0x30/0x40
  [<10118550>] free_initmem+0x154/0x184
  [<10117cbc>] init_post+0xa0/0xd4


Kernel Fault: Code=26 regs=8fc30940 (Addr=0f2ff000)

      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001101111111100001110 Not tainted
r00-03  0006ff0e 00000040 10119560 8fc308c0
r04-07  106e5820 107d2000 0000000f 10768020
r08-11  ffeffff1 8f0aeffc 8f08ce40 00000001
r12-15  00000000 00000017 00000001 00000000
r16-19  00004400 00000020 00000000 ffffffff
r20-23  00000000 00000000 00000001 00000040
r24-27  1090aa40 ffeffff1 0000fa40 106e2020
r28-31  0f2ff000 0007d8a3 8fc30940 0007d045
sr00-03  00000000 00000000 00000000 00000000
sr04-07  00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 10100eec 10100ef0
  IIR: 0f801280    ISR: 00000000  IOR: 0f2ff000
  CPU:        0   CR30: 8fc30000 CR31: ffffffff
  ORIG_R28: 8f812728
  IAOQ[0]: __clear_user_page_asm+0x20/0x70
  IAOQ[1]: __clear_user_page_asm+0x24/0x70
  RP(r2): clear_user_page_asm+0x44/0x6c
Backtrace:
  [<10119560>] clear_user_page_asm+0x44/0x6c
  [<101195dc>] clear_user_page+0x54/0x6c
  [<101bbaa8>] handle_pte_fault+0x5dc/0x7a8
  [<101bbd3c>] handle_mm_fault+0xc8/0x120
  [<101bbffc>] __get_user_pages+0x160/0x3c4
  [<101bc348>] get_user_pages+0x50/0x60
  [<101e169c>] get_arg_page+0x64/0xe8
  [<101e182c>] copy_strings+0x10c/0x248
  [<101e1990>] copy_strings_kernel+0x28/0x44
  [<101e328c>] do_execve+0x2a0/0x36c
  [<10120424>] sys_execve+0x44/0x7c
  [<10104084>] __execve+0x20/0x34
  [<10133b9c>] vprintk+0x1d8/0x4f4
  [<10133ee8>] printk+0x30/0x40
  [<10118550>] free_initmem+0x154/0x184
  [<10117cbc>] init_post+0xa0/0xd4

Kernel panic - not syncing: Kernel Fault


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-18 21:09                                         ` Helge Deller
@ 2012-05-20 10:01                                           ` James Bottomley
  2012-05-20 19:11                                             ` Helge Deller
  0 siblings, 1 reply; 56+ messages in thread
From: James Bottomley @ 2012-05-20 10:01 UTC (permalink / raw)
  To: Helge Deller; +Cc: John David Anglin, Vincent, Rolf Eike Beer, linux-parisc

On Fri, 2012-05-18 at 23:09 +0200, Helge Deller wrote:
> James, here is the full kernel log. Does this help?

Yes and no: it shows clearly we got all the way through the initrd, so
we've gone through the alias region thousands of times doing flushes.

> Kernel Fault: Code=26 regs=8fc30940 (Addr=0f2ff000)
> 
It's an access rights trap, presumably on the alias tlb, since the
address is definitely in the alias region.  The obvious candidate is the
protection id deposit in do_alias

	depw,z		\prot,8,7,\prot

but that all checks out fine (you can compare it with
make_insert_tlb_11). So the page should have read, write and dirty set.

The interesting thing is that the only way to get an access rights trap
in the kernel is if the protection type is zero and I just can't see how
do_alias would zero out \prot in a way that functions on your C3000
(PA2.0) but not on the PA1.1 systems.

Are you sure this is booting the same kernel?

James



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-20 10:01                                           ` James Bottomley
@ 2012-05-20 19:11                                             ` Helge Deller
  2012-05-20 20:15                                               ` James Bottomley
  0 siblings, 1 reply; 56+ messages in thread
From: Helge Deller @ 2012-05-20 19:11 UTC (permalink / raw)
  To: James Bottomley; +Cc: John David Anglin, Vincent, Rolf Eike Beer, linux-parisc

On 05/20/2012 12:01 PM, James Bottomley wrote:
> On Fri, 2012-05-18 at 23:09 +0200, Helge Deller wrote:
>> James, here is the full kernel log. Does this help?
>
> Yes and no: it shows clearly we got all the way through the initrd, so
> we've gone through the alias region thousands of times doing flushes.
>
>> Kernel Fault: Code=26 regs=8fc30940 (Addr=0f2ff000)
>>
> It's an access rights trap, presumably on the alias tlb, since the
> address is definitely in the alias region.  The obvious candidate is the
> protection id deposit in do_alias
>
> 	depw,z		\prot,8,7,\prot
>
> but that all checks out fine (you can compare it with
> make_insert_tlb_11). So the page should have read, write and dirty set.
>
> The interesting thing is that the only way to get an access rights trap
> in the kernel is if the protection type is zero and I just can't see how
> do_alias would zero out \prot in a way that functions on your C3000
> (PA2.0) but not on the PA1.1 systems.
>
> Are you sure this is booting the same kernel?

Yes, since I use tftboot to deliver same vmlinux kernel to all my machines
for bootup.

Helge

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-20 19:11                                             ` Helge Deller
@ 2012-05-20 20:15                                               ` James Bottomley
  2012-05-20 21:09                                                 ` Helge Deller
  0 siblings, 1 reply; 56+ messages in thread
From: James Bottomley @ 2012-05-20 20:15 UTC (permalink / raw)
  To: Helge Deller; +Cc: John David Anglin, Vincent, Rolf Eike Beer, linux-parisc

On Sun, 2012-05-20 at 21:11 +0200, Helge Deller wrote:
> On 05/20/2012 12:01 PM, James Bottomley wrote:
> > On Fri, 2012-05-18 at 23:09 +0200, Helge Deller wrote:
> >> James, here is the full kernel log. Does this help?
> >
> > Yes and no: it shows clearly we got all the way through the initrd, so
> > we've gone through the alias region thousands of times doing flushes.
> >
> >> Kernel Fault: Code=26 regs=8fc30940 (Addr=0f2ff000)
> >>
> > It's an access rights trap, presumably on the alias tlb, since the
> > address is definitely in the alias region.  The obvious candidate is the
> > protection id deposit in do_alias
> >
> > 	depw,z		\prot,8,7,\prot
> >
> > but that all checks out fine (you can compare it with
> > make_insert_tlb_11). So the page should have read, write and dirty set.
> >
> > The interesting thing is that the only way to get an access rights trap
> > in the kernel is if the protection type is zero and I just can't see how
> > do_alias would zero out \prot in a way that functions on your C3000
> > (PA2.0) but not on the PA1.1 systems.
> >
> > Are you sure this is booting the same kernel?
> 
> Yes, since I use tftboot to deliver same vmlinux kernel to all my machines
> for bootup.

The penny finally dropped on Dave's last comment.  The _20 path needs to
use wide instructions even though it's executing narrow code because we
have to use the PA2.0 tlb insertion instruction, so it's not
CONFIG_64BIT that's the differentiator, but which interruption path
we're on.

Does this fix it?

James

---

diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
index 5350342..07ef351 100644
--- a/arch/parisc/kernel/entry.S
+++ b/arch/parisc/kernel/entry.S
@@ -552,7 +552,7 @@
 	 * entry (identifying the physical page) and %r23 up with
 	 * the from tlb entry (or nothing if only a to entry---for
 	 * clear_user_page_asm) */
-	.macro		do_alias	spc,tmp,tmp1,va,pte,prot,fault
+	.macro		do_alias	spc,tmp,tmp1,va,pte,prot,fault,patype
 	cmpib,COND(<>),n 0,\spc,\fault
 	ldil		L%(TMPALIAS_MAP_START),\tmp
 #if defined(CONFIG_64BIT) && (TMPALIAS_MAP_START >= 0x80000000)
@@ -581,11 +581,15 @@
 	 */
 	cmpiclr,=	0x01,\tmp,%r0
 	ldi		(_PAGE_DIRTY|_PAGE_READ|_PAGE_WRITE),\prot
-#ifdef CONFIG_64BIT
+.ifc \patype,20
 	depd,z		\prot,8,7,\prot
-#else
+.else
+.ifc \patype,11
 	depw,z		\prot,8,7,\prot
-#endif
+.else
+	.error "undefined PA type to do_alias"
+.endif
+.endif
 	/*
 	 * OK, it is in the temp alias region, check whether "from" or "to".
 	 * Check "subtle" note in pacache.S re: r23/r26.
@@ -1189,7 +1193,7 @@ dtlb_miss_20w:
 	nop
 
 dtlb_check_alias_20w:
-	do_alias	spc,t0,t1,va,pte,prot,dtlb_fault
+	do_alias	spc,t0,t1,va,pte,prot,dtlb_fault,20
 
 	idtlbt          pte,prot
 
@@ -1213,7 +1217,7 @@ nadtlb_miss_20w:
 	nop
 
 nadtlb_check_alias_20w:
-	do_alias	spc,t0,t1,va,pte,prot,nadtlb_emulate
+	do_alias	spc,t0,t1,va,pte,prot,nadtlb_emulate,20
 
 	idtlbt          pte,prot
 
@@ -1245,7 +1249,7 @@ dtlb_miss_11:
 	nop
 
 dtlb_check_alias_11:
-	do_alias	spc,t0,t1,va,pte,prot,dtlb_fault
+	do_alias	spc,t0,t1,va,pte,prot,dtlb_fault,11
 
 	idtlba          pte,(va)
 	idtlbp          prot,(va)
@@ -1277,7 +1281,7 @@ nadtlb_miss_11:
 	nop
 
 nadtlb_check_alias_11:
-	do_alias	spc,t0,t1,va,pte,prot,nadtlb_emulate
+	do_alias	spc,t0,t1,va,pte,prot,nadtlb_emulate,11
 
 	idtlba          pte,(va)
 	idtlbp          prot,(va)
@@ -1304,7 +1308,7 @@ dtlb_miss_20:
 	nop
 
 dtlb_check_alias_20:
-	do_alias	spc,t0,t1,va,pte,prot,dtlb_fault
+	do_alias	spc,t0,t1,va,pte,prot,dtlb_fault,20
 	
 	idtlbt          pte,prot
 
@@ -1330,7 +1334,7 @@ nadtlb_miss_20:
 	nop
 
 nadtlb_check_alias_20:
-	do_alias	spc,t0,t1,va,pte,prot,nadtlb_emulate
+	do_alias	spc,t0,t1,va,pte,prot,nadtlb_emulate,20
 
 	idtlbt          pte,prot
 
@@ -1457,7 +1461,7 @@ naitlb_miss_20w:
 	nop
 
 naitlb_check_alias_20w:
-	do_alias	spc,t0,t1,va,pte,prot,naitlb_fault
+	do_alias	spc,t0,t1,va,pte,prot,naitlb_fault,20
 
 	iitlbt		pte,prot
 
@@ -1511,7 +1515,7 @@ naitlb_miss_11:
 	nop
 
 naitlb_check_alias_11:
-	do_alias	spc,t0,t1,va,pte,prot,itlb_fault
+	do_alias	spc,t0,t1,va,pte,prot,itlb_fault,11
 
 	iitlba          pte,(%sr0, va)
 	iitlbp          prot,(%sr0, va)
@@ -1557,7 +1561,7 @@ naitlb_miss_20:
 	nop
 
 naitlb_check_alias_20:
-	do_alias	spc,t0,t1,va,pte,prot,naitlb_fault
+	do_alias	spc,t0,t1,va,pte,prot,naitlb_fault,20
 
 	iitlbt          pte,prot
 



^ permalink raw reply related	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-20 20:15                                               ` James Bottomley
@ 2012-05-20 21:09                                                 ` Helge Deller
  2012-05-20 21:25                                                   ` John David Anglin
  2012-05-23  8:47                                                   ` Peter Gantner (nephros)
  0 siblings, 2 replies; 56+ messages in thread
From: Helge Deller @ 2012-05-20 21:09 UTC (permalink / raw)
  To: James Bottomley; +Cc: John David Anglin, Vincent, Rolf Eike Beer, linux-parisc

On 05/20/2012 10:15 PM, James Bottomley wrote:
> On Sun, 2012-05-20 at 21:11 +0200, Helge Deller wrote:
>> On 05/20/2012 12:01 PM, James Bottomley wrote:
>>> On Fri, 2012-05-18 at 23:09 +0200, Helge Deller wrote:
>>>> James, here is the full kernel log. Does this help?
>>> Yes and no: it shows clearly we got all the way through the initrd, so
>>> we've gone through the alias region thousands of times doing flushes.
>>>
>>>> Kernel Fault: Code=26 regs=8fc30940 (Addr=0f2ff000)
>>>>
>>> It's an access rights trap, presumably on the alias tlb, since the
>>> address is definitely in the alias region.  The obvious candidate is the
>>> protection id deposit in do_alias
>>>
>>> 	depw,z		\prot,8,7,\prot
>>>
>>> but that all checks out fine (you can compare it with
>>> make_insert_tlb_11). So the page should have read, write and dirty set.
>>>
>>> The interesting thing is that the only way to get an access rights trap
>>> in the kernel is if the protection type is zero and I just can't see how
>>> do_alias would zero out \prot in a way that functions on your C3000
>>> (PA2.0) but not on the PA1.1 systems.
>>>
>>> Are you sure this is booting the same kernel?
>> Yes, since I use tftboot to deliver same vmlinux kernel to all my machines
>> for bootup.
> The penny finally dropped on Dave's last comment.  The _20 path needs to
> use wide instructions even though it's executing narrow code because we
> have to use the PA2.0 tlb insertion instruction, so it's not
> CONFIG_64BIT that's the differentiator, but which interruption path
> we're on.
>
> Does this fix it?
Yes, this fixed the crash. No segfaults at all on all my machines  :-)

C3000:~# uname -a
Linux c3000 3.4.0-rc7-32bit+ #11 Sun May 20 22:30:48 CEST 2012 parisc 
GNU/Linux

715/64:~# uname -a
Linux pa64 3.4.0-rc7-32bit+ #11 Sun May 20 22:30:48 CEST 2012 parisc 
GNU/Linux

B160L:~# uname -a
Linux b160 3.4.0-rc7-32bit+ #11 Sun May 20 22:30:48 CEST 2012 parisc 
GNU/Linux

REALLY COOL!

This is with
- Linus git head (which includes James "parisc-fixes" branch)
- with Daves vmlinux.lds.S patch
- and James PA 20 TLB-fix patch above.



Just to make sure, I just wanted to build the same kernel now for 64bit...
Sadly hppa64-ld crashes for me...

[deller@p100 linus-linux-2.6-64bit]$ gdb 
/opt/cross-hppa-4.6/bin/hppa64-linux-ld
GNU gdb (GDB) Fedora (7.3.1-48.fc15)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/cross-hppa-4.6/bin/hppa64-linux-ld...done.
(gdb) run --build-id -o .tmp_vmlinux2 -T arch/parisc/kernel/vmlinux.lds 
arch/parisc/kernel/head.o init/built-in.o --start-group usr/built-in.o 
arch/parisc/mm/built-in.o arch/parisc/kernel/built-in.o 
arch/parisc/math-emu/built-in.o arch/parisc/kernel/init_task.o 
kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o 
security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a 
arch/parisc/lib/lib.a `hppa64-linux-gcc -print-libgcc-file-name` 
lib/built-in.o arch/parisc/lib/built-in.o `hppa64-linux-gcc 
-print-libgcc-file-name` drivers/built-in.o sound/built-in.o 
firmware/built-in.o net/built-in.o --end-group .tmp_kallsyms1.o
Starting program: /opt/cross-hppa-4.6/bin/hppa64-linux-ld --build-id -o 
.tmp_vmlinux2 -T arch/parisc/kernel/vmlinux.lds 
arch/parisc/kernel/head.o init/built-in.o --start-group usr/built-in.o 
arch/parisc/mm/built-in.o arch/parisc/kernel/built-in.o 
arch/parisc/math-emu/built-in.o arch/parisc/kernel/init_task.o 
kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o 
security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a 
arch/parisc/lib/lib.a `hppa64-linux-gcc -print-libgcc-file-name` 
lib/built-in.o arch/parisc/lib/built-in.o `hppa64-linux-gcc 
-print-libgcc-file-name` drivers/built-in.o sound/built-in.o 
firmware/built-in.o net/built-in.o --end-group .tmp_kallsyms1.o
/opt/cross-hppa-4.6/bin/hppa64-linux-ld:
Program received signal SIGSEGV, Segmentation fault.
0x00000034d7a4a26e in vfprintf () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install 
glibc-2.14.1-6.x86_64 zlib-1.2.5-6.fc15.x86_64
(gdb) bt
#0  0x00000034d7a4a26e in vfprintf () from /lib64/libc.so.6
#1  0x00000034d7a4b4f4 in buffered_vfprintf () from /lib64/libc.so.6
#2  0x00000034d7a4691e in vfprintf () from /lib64/libc.so.6
#3  0x0000000000425a2d in _bfd_default_error_handler (fmt=0x4c6ff3 
"+0xlx): cannot reach %s") at /mnt/sda4/home/cvs/binutils/bfd/bfd.c:727
#4  0x0000000000441de0 in elf_hppa_final_link_relocate (eh=0x773890, 
sym_sec=<optimized out>, info=0x6e8d00, value=<optimized out>, 
contents=0x2a624e0 "\b\003\002A\017\302\022\301\b\036\002Cs\301\002(+v 
", input_section=0x7627c8,
     output_bfd=0x705900, input_bfd=0x73e270, rel=0x7779e0) at 
/mnt/sda4/home/cvs/binutils/bfd/elf64-hppa.c:3276
#5  elf64_hppa_relocate_section (output_bfd=0x705900, info=0x6e8d00, 
input_bfd=0x73e270, input_section=0x7627c8, contents=0x2a624e0 
"\b\003\002A\017\302\022\301\b\036\002Cs\301\002(+v ", relocs=<optimized 
out>, local_syms=0x2d1b230,
     local_sections=0x2dec550) at 
/mnt/sda4/home/cvs/binutils/bfd/elf64-hppa.c:3930
#6  0x000000000046250f in elf_link_input_bfd (flinfo=0x7fffffffd910, 
input_bfd=0x73e270) at /mnt/sda4/home/cvs/binutils/bfd/elflink.c:9582
#7  0x0000000000463ff7 in bfd_elf_final_link (abfd=0x705900, 
info=0x6e8d00) at /mnt/sda4/home/cvs/binutils/bfd/elflink.c:10734
#8  0x000000000043f032 in elf64_hppa_final_link (abfd=0x705900, 
info=0x6e8d00) at /mnt/sda4/home/cvs/binutils/bfd/elf64-hppa.c:3028
#9  0x0000000000417e26 in ldwrite () at 
/mnt/sda4/home/cvs/binutils/ld/ldwrite.c:582
#10 0x0000000000402f9c in main (argc=33, argv=0x7fffffffdce8) at 
/mnt/sda4/home/cvs/binutils/ld/ldmain.c:420

this is with binutils CVS head (just pulled and compiled again), gcc 
from gcc-4.6 branch

Helge

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-20 21:09                                                 ` Helge Deller
@ 2012-05-20 21:25                                                   ` John David Anglin
  2012-05-21 20:59                                                     ` Helge Deller
  2012-05-23  8:47                                                   ` Peter Gantner (nephros)
  1 sibling, 1 reply; 56+ messages in thread
From: John David Anglin @ 2012-05-20 21:25 UTC (permalink / raw)
  To: Helge Deller; +Cc: James Bottomley, Vincent, Rolf Eike Beer, linux-parisc

On 20-May-12, at 5:09 PM, Helge Deller wrote:

> Just to make sure, I just wanted to build the same kernel now for  
> 64bit...
> Sadly hppa64-ld crashes for me...

Please file a bug report ;(

I haven't tested binutils for some time...

Suggest using 2.22 branch for now.

Dave
--
John David Anglin	dave.anglin@bell.net




^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-20 21:25                                                   ` John David Anglin
@ 2012-05-21 20:59                                                     ` Helge Deller
  0 siblings, 0 replies; 56+ messages in thread
From: Helge Deller @ 2012-05-21 20:59 UTC (permalink / raw)
  To: John David Anglin; +Cc: James Bottomley, Vincent, Rolf Eike Beer, linux-parisc

On 05/20/2012 11:25 PM, John David Anglin wrote:
> On 20-May-12, at 5:09 PM, Helge Deller wrote:
>
>> Just to make sure, I just wanted to build the same kernel now for 
>> 64bit...
>> Sadly hppa64-ld crashes for me...
>
> Please file a bug report ;(

Ok, will do.

>
> I haven't tested binutils for some time...
>
> Suggest using 2.22 branch for now.

hppa64-linux-ld from 2.22 segfaults the same way.

Helge

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-20 21:09                                                 ` Helge Deller
  2012-05-20 21:25                                                   ` John David Anglin
@ 2012-05-23  8:47                                                   ` Peter Gantner (nephros)
  2012-05-23 23:09                                                     ` John David Anglin
  1 sibling, 1 reply; 56+ messages in thread
From: Peter Gantner (nephros) @ 2012-05-23  8:47 UTC (permalink / raw)
  To: Helge Deller
  Cc: James Bottomley, John David Anglin, Vincent, Rolf Eike Beer,
	linux-parisc

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4567 bytes --]

Hodie XIII Kal. Iun. MMXII AUC quidam/quædam/quoddam 'Helge Deller' inquit:

> On 05/20/2012 10:15 PM, James Bottomley wrote:
>> On Sun, 2012-05-20 at 21:11 +0200, Helge Deller wrote:
>>> On 05/20/2012 12:01 PM, James Bottomley wrote:
>>>> On Fri, 2012-05-18 at 23:09 +0200, Helge Deller wrote:
>>>>> James, here is the full kernel log. Does this help?
>>>> Yes and no: it shows clearly we got all the way through the initrd, so
>>>> we've gone through the alias region thousands of times doing flushes.
>>>> 
>>>>> Kernel Fault: Code=26 regs=8fc30940 (Addr=0f2ff000)
>>>>> 
>>>> It's an access rights trap, presumably on the alias tlb, since the
>>>> address is definitely in the alias region.  The obvious candidate is the
>>>> protection id deposit in do_alias
>>>>
>>>> 	depw,z		\prot,8,7,\prot
>>>> 
>>>> but that all checks out fine (you can compare it with
>>>> make_insert_tlb_11). So the page should have read, write and dirty set.
>>>> 
>>>> The interesting thing is that the only way to get an access rights trap
>>>> in the kernel is if the protection type is zero and I just can't see how
>>>> do_alias would zero out \prot in a way that functions on your C3000
>>>> (PA2.0) but not on the PA1.1 systems.
>>>> 
>>>> Are you sure this is booting the same kernel?
>>> Yes, since I use tftboot to deliver same vmlinux kernel to all my machines
>>> for bootup.
>> The penny finally dropped on Dave's last comment.  The _20 path needs to
>> use wide instructions even though it's executing narrow code because we
>> have to use the PA2.0 tlb insertion instruction, so it's not
>> CONFIG_64BIT that's the differentiator, but which interruption path
>> we're on.
>> 
>> Does this fix it?
> Yes, this fixed the crash. No segfaults at all on all my machines  :-)

Just checking in to report that I did the same patch dance on my C180 (after
spending about a week on getting its ancient Gentoo installation up to date.
Many many thanks to whoever provides the binaries on tinderbox.dev.gentoo.org):

# uname -a
Linux hydralisk 3.4.0-rc7-hyT #11 Wed May 23 10:00:17 CEST 2012 parisc 
PA8000 (PCX-U) 9000/780/C180 GNU/Linux

and these patches work here as well (also I get the same oopses without 
them).

You can see all relevant files here:
https://public.nephros.org/~nephros/stuff/hppa/linux-2.6-d6c77973/

In addition after a suggestion by Mikulas I applied the NO_IRQ patch from here:
http://www.spinics.net/lists/linux-parisc/msg03894.html
and it did not seem to have adverse effect.

Let me know if I can test anything else.

On a side note, I get a warning while booting about RTC being registered, in the dmesg here:
https://public.nephros.org/~nephros/stuff/hppa/linux-2.6-d6c77973/try4/
as well as some warnings during compile (don't have a log of them right now, sorry)

Is that something peculiar to my config, or is there something amiss in the current source?

------------[ cut here ]------------
WARNING: at fs/proc/generic.c:586
Modules linked in:

      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000000000001111 Not tainted
r00-03  0004000f 104c4800 101e100c 6ecc6940
r04-07  6fc05240 6ecc6b40 6ecc698d 6ecb52b8
r08-11  00000000 104fe000 104fe000 00000048
r12-15  10578b18 1055c45c 000000fd f0100000
r16-19  f000168c f000020c f0000204 104c4d38
r20-23  00000000 0000000a 102b6efc 102b7ab0
r24-27  ffffffff 00002358 104c4f88 104aa000
r28-31  00000035 000000b4 6fc2c5c0 102b8d28
sr00-03  00000000 00000000 00000000 00000000
sr04-07  00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 101e100c 101e1010
  IIR: 03ffe01f    ISR: 00000000  IOR: 00000000
  CPU:        0   CR30: 6fc2c000 CR31: ffffffff
  ORIG_R28: 10418800
  IAOQ[0]: proc_register+0x13c/0x190
  IAOQ[1]: proc_register+0x140/0x190
  RP(r2): proc_register+0x13c/0x190
Backtrace:
  [<101e10ec>] proc_create_data+0x8c/0xb4
  [<102ff488>] rtc_proc_add_device+0x30/0x3c
  [<102fd0d8>] rtc_device_register+0x1d8/0x264
  [<10555b78>] generic_rtc_probe+0x28/0x4c
  [<102c4adc>] platform_drv_probe+0x1c/0x28
  [<102c392c>] driver_probe_device+0xac/0x1c0
  [<102c3aa8>] __driver_attach+0x68/0x9c
  [<102c20f8>] bus_for_each_dev+0x60/0xa0
  [<102c2fac>] bus_add_driver+0xac/0x230
  [<102c3e80>] driver_register+0xa4/0x13c
  [<102c4e40>] platform_driver_probe+0x20/0x6c
  [<10112850>] do_one_initcall+0x180/0x24c
  [<10540ae4>] kernel_init+0x134/0x1fc
  [<1010305c>] ret_from_kernel_thread+0x1c/0x24

---[ end trace a48b844e905b2419 ]---

Best Wishes,
   Peter G.

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
  2012-05-23  8:47                                                   ` Peter Gantner (nephros)
@ 2012-05-23 23:09                                                     ` John David Anglin
  0 siblings, 0 replies; 56+ messages in thread
From: John David Anglin @ 2012-05-23 23:09 UTC (permalink / raw)
  To: Peter Gantner
  Cc: Helge Deller, James Bottomley, Vincent, Rolf Eike Beer,
	linux-parisc

I haven't seen the RTC problem.  I have the following RTC options in =20
my rp3440 config:

CONFIG_HP_SDC_RTC=3Dm

CONFIG_RTC_LIB=3Dy
CONFIG_RTC_CLASS=3Dy
CONFIG_RTC_HCTOSYS=3Dy
CONFIG_RTC_HCTOSYS_DEVICE=3D"rtc0"

CONFIG_RTC_INTF_SYSFS=3Dy
CONFIG_RTC_INTF_PROC=3Dy
CONFIG_RTC_INTF_DEV=3Dy

CONFIG_RTC_DRV_GENERIC=3Dy

Dave

On 23-May-12, at 4:47 AM, Peter Gantner (nephros) wrote:

> Hodie XIII Kal. Iun. MMXII AUC quidam/qu=E6dam/quoddam 'Helge Deller'=
 =20
> inquit:
>
>> On 05/20/2012 10:15 PM, James Bottomley wrote:
>>> On Sun, 2012-05-20 at 21:11 +0200, Helge Deller wrote:
>>>> On 05/20/2012 12:01 PM, James Bottomley wrote:
>>>>> On Fri, 2012-05-18 at 23:09 +0200, Helge Deller wrote:
>>>>>> James, here is the full kernel log. Does this help?
>>>>> Yes and no: it shows clearly we got all the way through the =20
>>>>> initrd, so
>>>>> we've gone through the alias region thousands of times doing =20
>>>>> flushes.
>>>>>> Kernel Fault: Code=3D26 regs=3D8fc30940 (Addr=3D0f2ff000)
>>>>> It's an access rights trap, presumably on the alias tlb, since th=
e
>>>>> address is definitely in the alias region.  The obvious =20
>>>>> candidate is the
>>>>> protection id deposit in do_alias
>>>>>
>>>>> 	depw,z		\prot,8,7,\prot
>>>>> but that all checks out fine (you can compare it with
>>>>> make_insert_tlb_11). So the page should have read, write and =20
>>>>> dirty set.
>>>>> The interesting thing is that the only way to get an access =20
>>>>> rights trap
>>>>> in the kernel is if the protection type is zero and I just can't =
=20
>>>>> see how
>>>>> do_alias would zero out \prot in a way that functions on your =20
>>>>> C3000
>>>>> (PA2.0) but not on the PA1.1 systems.
>>>>> Are you sure this is booting the same kernel?
>>>> Yes, since I use tftboot to deliver same vmlinux kernel to all my =
=20
>>>> machines
>>>> for bootup.
>>> The penny finally dropped on Dave's last comment.  The _20 path =20
>>> needs to
>>> use wide instructions even though it's executing narrow code =20
>>> because we
>>> have to use the PA2.0 tlb insertion instruction, so it's not
>>> CONFIG_64BIT that's the differentiator, but which interruption path
>>> we're on.
>>> Does this fix it?
>> Yes, this fixed the crash. No segfaults at all on all my =20
>> machines  :-)
>
> Just checking in to report that I did the same patch dance on my =20
> C180 (after
> spending about a week on getting its ancient Gentoo installation up =20
> to date.
> Many many thanks to whoever provides the binaries on =20
> tinderbox.dev.gentoo.org):
>
> # uname -a
> Linux hydralisk 3.4.0-rc7-hyT #11 Wed May 23 10:00:17 CEST 2012 =20
> parisc PA8000 (PCX-U) 9000/780/C180 GNU/Linux
>
> and these patches work here as well (also I get the same oopses =20
> without them).
>
> You can see all relevant files here:
> https://public.nephros.org/~nephros/stuff/hppa/linux-2.6-d6c77973/
>
> In addition after a suggestion by Mikulas I applied the NO_IRQ patch =
=20
> from here:
> http://www.spinics.net/lists/linux-parisc/msg03894.html
> and it did not seem to have adverse effect.
>
> Let me know if I can test anything else.
>
> On a side note, I get a warning while booting about RTC being =20
> registered, in the dmesg here:
> https://public.nephros.org/~nephros/stuff/hppa/linux-2.6-d6c77973/=20
> try4/
> as well as some warnings during compile (don't have a log of them =20
> right now, sorry)
>
> Is that something peculiar to my config, or is there something amiss =
=20
> in the current source?
>
> ------------[ cut here ]------------
> WARNING: at fs/proc/generic.c:586
> Modules linked in:
>
>     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001000000000000001111 Not tainted
> r00-03  0004000f 104c4800 101e100c 6ecc6940
> r04-07  6fc05240 6ecc6b40 6ecc698d 6ecb52b8
> r08-11  00000000 104fe000 104fe000 00000048
> r12-15  10578b18 1055c45c 000000fd f0100000
> r16-19  f000168c f000020c f0000204 104c4d38
> r20-23  00000000 0000000a 102b6efc 102b7ab0
> r24-27  ffffffff 00002358 104c4f88 104aa000
> r28-31  00000035 000000b4 6fc2c5c0 102b8d28
> sr00-03  00000000 00000000 00000000 00000000
> sr04-07  00000000 00000000 00000000 00000000
>
> IASQ: 00000000 00000000 IAOQ: 101e100c 101e1010
> IIR: 03ffe01f    ISR: 00000000  IOR: 00000000
> CPU:        0   CR30: 6fc2c000 CR31: ffffffff
> ORIG_R28: 10418800
> IAOQ[0]: proc_register+0x13c/0x190
> IAOQ[1]: proc_register+0x140/0x190
> RP(r2): proc_register+0x13c/0x190
> Backtrace:
> [<101e10ec>] proc_create_data+0x8c/0xb4
> [<102ff488>] rtc_proc_add_device+0x30/0x3c
> [<102fd0d8>] rtc_device_register+0x1d8/0x264
> [<10555b78>] generic_rtc_probe+0x28/0x4c
> [<102c4adc>] platform_drv_probe+0x1c/0x28
> [<102c392c>] driver_probe_device+0xac/0x1c0
> [<102c3aa8>] __driver_attach+0x68/0x9c
> [<102c20f8>] bus_for_each_dev+0x60/0xa0
> [<102c2fac>] bus_add_driver+0xac/0x230
> [<102c3e80>] driver_register+0xa4/0x13c
> [<102c4e40>] platform_driver_probe+0x20/0x6c
> [<10112850>] do_one_initcall+0x180/0x24c
> [<10540ae4>] kernel_init+0x134/0x1fc
> [<1010305c>] ret_from_kernel_thread+0x1c/0x24
>
> ---[ end trace a48b844e905b2419 ]---
>
> Best Wishes,
>  Peter G.

--
John David Anglin	dave.anglin@bell.net



--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 56+ messages in thread

end of thread, other threads:[~2012-05-23 23:09 UTC | newest]

Thread overview: 56+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-05-08 21:59 Issue booting v2.6.39 .. v3.4-rc6 on hp712/100 Vincent
2012-05-09  6:53 ` Rolf Eike Beer
2012-05-09 15:55   ` John David Anglin
2012-05-09 21:14     ` Vincent
2012-05-09 21:33       ` John David Anglin
2012-05-10  2:03       ` John David Anglin
2012-05-10  6:41         ` Rolf Eike Beer
2012-05-10 16:32           ` John David Anglin
2012-05-10 19:32             ` Rolf Eike Beer
2012-05-11 21:17             ` Vincent
2012-05-13 14:32           ` Jeroen Roovers
2012-05-14  0:52             ` John David Anglin
2012-05-12 22:50         ` Helge Deller
2012-05-13 14:11           ` John David Anglin
2012-05-14  1:10           ` John David Anglin
2012-05-14 22:11             ` Helge Deller
2012-05-14 22:38               ` John David Anglin
2012-05-14 22:55                 ` John David Anglin
2012-05-15  8:09                 ` James Bottomley
2012-05-15  9:13                   ` James Bottomley
2012-05-15 18:23                     ` John David Anglin
2012-05-15 18:50                       ` Helge Deller
2012-05-15 19:24                         ` John David Anglin
2012-05-15 19:46                           ` John David Anglin
2012-05-15 19:59                             ` Helge Deller
2012-05-15 20:05                               ` John David Anglin
2012-05-15 20:28                                 ` Helge Deller
2012-05-15 20:48                                   ` John David Anglin
2012-05-16 14:59                                     ` James Bottomley
2012-05-17 19:26                                     ` Helge Deller
2012-05-17 19:57                                       ` Rolf Eike Beer
2012-05-18  8:12                                       ` James Bottomley
2012-05-18 21:09                                         ` Helge Deller
2012-05-20 10:01                                           ` James Bottomley
2012-05-20 19:11                                             ` Helge Deller
2012-05-20 20:15                                               ` James Bottomley
2012-05-20 21:09                                                 ` Helge Deller
2012-05-20 21:25                                                   ` John David Anglin
2012-05-21 20:59                                                     ` Helge Deller
2012-05-23  8:47                                                   ` Peter Gantner (nephros)
2012-05-23 23:09                                                     ` John David Anglin
2012-05-15 21:08                                   ` John David Anglin
2012-05-16  7:27                                   ` James Bottomley
2012-05-16  9:27                                     ` James Bottomley
2012-05-16 10:09                                       ` James Bottomley
2012-05-16 10:49                                     ` John David Anglin
2012-05-16 10:57                                       ` James Bottomley
2012-05-16 11:17                                         ` John David Anglin
2012-05-16 11:57                                         ` Rolf Eike Beer
2012-05-16 12:24                                           ` James Bottomley
2012-05-15 19:52                         ` James Bottomley
2012-05-15 19:09                       ` James Bottomley
2012-05-15 21:01                     ` Vincent
2012-05-16 19:07                       ` Helge Deller
2012-05-15  8:06               ` James Bottomley
2012-05-09 21:00   ` Vincent

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).