Issue booting v2.6.39 .. v3.4-rc6 on hp712/100
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Vincent
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
Quoted 9 lines · Rolf Eike Beer
Quoted 5 lines · Vincent
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.
Dave
Signature · 1 line
John David Anglin [email protected]
arch/parisc/include/asm/cacheflush.h +2 -0
@@ -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 (); } }
arch/parisc/include/asm/page.h +16 -4
@@ -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..
arch/parisc/include/asm/pgtable.h +12 -3
@@ -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));
arch/parisc/kernel/cache.c +180 -36
275 lines not on this page · raw message
arch/parisc/kernel/pacache.S +293 -50
532 lines not on this page · raw message
arch/parisc/kernel/parisc_ksyms.c +3 -2
@@ -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);
arch/parisc/kernel/signal.c +1 -1
@@ -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);
arch/parisc/kernel/sys_parisc.c +5 -4
@@ -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 ;
Quoted 1 line · John David Anglin
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.
Quoted 5 lines · Vincent
Quoted 1 line · John David Anglin
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
Signature · 1 line
John David Anglin [email protected]
Quoted 5 lines · Vincent
Quoted 1 line · John David Anglin
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 [email protected]
Quoted 6 lines · John David Anglin
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
Quoted 17 lines · Rolf Eike Beer
Quoted 6 lines · John David Anglin
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.
Quoted 7 lines
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
Signature · 1 line
John David Anglin [email protected]
Quoted 15 lines · John David Anglin
Quoted 8 lines · Rolf Eike Beer
Quoted 6 lines · John David Anglin
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.
Quoted 5 lines
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.
Quoted 8 lines
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
On 05/10/2012 06:32 PM, John David Anglin wrote:
(..)
Quoted 5 lines
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 inentry.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.
Quoted 2 lines · On Thu, 10 May 2012 08:41:50 +0200 Rolf Eike Beer <[email protected]> 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
Quoted 3 lines · Jeroen Roovers
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 [email protected]
Helge Deller
maintainerQuoted 58 lines · John David Anglin
Quoted 5 lines · Vincent
Quoted 1 line · John David Anglin
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.htmlIf 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.creflects this.
Quoted 4 lines
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
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 2012unwind_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:00pci_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 [email protected]). 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_X1024sticon: 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.103parport_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.00zalon_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 [email protected]
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) Driveruhci_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: [email protected]
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=2isofs_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
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 2012unwind_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:00pci_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:01pci_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:03pci_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:04pci_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 [email protected]).
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-0x0a0fhda: 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 FUAohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driverohci_hcd 0000:00:0e.2: OHCI Host Controllerohci_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 detecteduhci_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: [email protected] 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 detecteduhci_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 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 2012unwind_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 [email protected]).
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.103parport_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 [email protected]
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 offohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driveruhci_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: [email protected]
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
Quoted 1 line · Helge Deller
I have my machines now up and running again.
Good.
Quoted 21 lines
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/0x26cor
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
Quoted 8 lines
[<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.
Quoted 5 lines
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 [email protected]
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
Quoted 32 lines · Helge Deller
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/0x26cor
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
Quoted 3 lines
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 [email protected]
Helge Deller
maintainerQuoted 4 lines · John David Anglin
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
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 2012unwind_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/715ic_size 20000 dc_size 20000 it_size 40
DC base 0x0 stride 0x20 count 0x1000 loop 0x1dc_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 0x1ic_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 [email protected]).
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.103parport_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 [email protected]
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 FUAohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driveruhci_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: [email protected] 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'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 2012unwind_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/B160Lic_size 10000 dc_size 10000 it_size 60
DC base 0x0 stride 0x20 count 0x400 loop 0x2dc_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 0x2ic_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:00pci_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 [email protected]). 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_X1024sticon: 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.103parport_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.00zalon_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 [email protected]
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) Driveruhci_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: [email protected]
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
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 2012unwind_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/C3700ic_size c0000 dc_size 180000 it_size f0
DC base 0x0 stride 0x40 count 0x6000 loop 0x1dc_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 0x1ic_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:00pci_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:01pci_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:03pci_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:04pci_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 [email protected]).
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-0x0a0fhda: 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 FUAohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driverohci_hcd 0000:00:0e.2: OHCI Host Controllerohci_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 detecteduhci_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: [email protected]
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
Quoted 4 lines · Helge Deller
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 [email protected]
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
Quoted 37 lines · John David Anglin
Quoted 4 lines · Helge Deller
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.Sis broken. For example, the cache stride that is loaded inflush_dcache_page_asmto register r1 is wrong. Probably, thedo_aliasmacro 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_aliasspc,t0,t1,va,pte,prot,nadtlb_emulateidtlba pte,(va)
idtlbp prot,(va)rfir
nopThe 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 [email protected]
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
John David Anglin [email protected]
James Bottomley
maintainerQuoted 31 lines · John David Anglin
Quoted 5 lines · Helge Deller
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.Sis broken. For example,
the cache stride that is loaded inflush_dcache_page_asmto register r1 is wrong. Probably,
thedo_aliasmacro 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_aliasspc,t0,t1,va,pte,prot,nadtlb_emulateidtlba pte,(va)
idtlbp prot,(va)rfir
nopThe 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.
Quoted 5 lines
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
James Bottomley
maintainerQuoted 38 lines · James Bottomley
Quoted 31 lines · John David Anglin
Quoted 5 lines · Helge Deller
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.Sis broken. For example,
the cache stride that is loaded inflush_dcache_page_asmto register r1 is wrong. Probably,
thedo_aliasmacro 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_aliasspc,t0,t1,va,pte,prot,nadtlb_emulateidtlba pte,(va)
idtlbp prot,(va)rfir
nopThe 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.Quoted 5 lines
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.
Quoted 4 lines
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
---
arch/parisc/kernel/entry.S +4 -0
@@ -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.
Quoted 57 lines · James Bottomley
Quoted 36 lines · James Bottomley
Quoted 30 lines · John David Anglin
Quoted 5 lines · Helge Deller
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.Sis broken. For example,
the cache stride that is loaded inflush_dcache_page_asmto register r1 is wrong. Probably,
thedo_aliasmacro 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_aliasspc,t0,t1,va,pte,prot,nadtlb_emulateidtlba pte,(va)
idtlbp prot,(va)rfir
nopThe 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.Quoted 5 lines
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.Quoted 4 lines
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_aliaswhich 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
---
arch/parisc/kernel/entry.S +0
-0@@ -581,7 +581,11 @@ */
arch/parisc/kernel/entry.S line 591
Quoted 10 lines
arch/parisc/kernel/entry.S +4
-0cmpiclr,= 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
Signature · 1 line
John David Anglin [email protected]
Helge Deller
maintainerQuoted 63 lines · John David Anglin
Quoted 62 lines · James Bottomley
Quoted 36 lines · James Bottomley
Quoted 30 lines · John David Anglin
Quoted 5 lines · Helge Deller
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.Sis broken. For example,
the cache stride that is loaded inflush_dcache_page_asmto register r1 is wrong. Probably,
thedo_aliasmacro 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_aliasspc,t0,t1,va,pte,prot,nadtlb_emulateidtlba pte,(va)
idtlbp prot,(va)rfir
nopThe 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.Quoted 5 lines
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.Quoted 4 lines
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_aliaswhich 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
---
arch/parisc/kernel/entry.S +2
-0@@ -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
Quoted 8 lines
Quoted 6 lines
arch/parisc/kernel/entry.S +2
-0+ depw,z \prot,8,7,\prot +#endif /* * OK, it is in the temp alias region, check whether "from" or"to".
* Check "subtle" note inpacache.Sre: 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:
James patch now let my 715/64 boot, but still crashes on my B160L:
Quoted 16 lines
swapper (pid 1): Illegal instruction (code 8)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001110000100001111 Not taintedr00-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 000072e6sr00-03 00000000 00000001 00000000 00000000 sr04-07 00000000 00000000 00000000 00000000
Quoted 8 lines
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078113e0ISR: 00000000 IOR:0f2ff000
CPU: 0 CR30:17c24000CR31:f0102978
ORIG_R28:17ebbe40
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Backtrace:
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
Signature · 1 line
John David Anglin [email protected]
Quoted 25 lines · John David Anglin
James patch now let my 715/64 boot, but still crashes on my B160L:
Quoted 16 lines
swapper (pid 1): Illegal instruction (code 8)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001110000100001111 Not taintedr00-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 000072e6sr00-03 00000000 00000001 00000000 00000000 sr04-07 00000000 00000000 00000000 00000000
Quoted 8 lines
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078113e0ISR: 00000000 IOR:0f2ff000
CPU: 0 CR30:17c24000CR31:f0102978
ORIG_R28:17ebbe40
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Backtrace:
Quoted 3 lines
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
Signature · 1 line
John David Anglin [email protected]
Helge Deller
maintainerQuoted 26 lines · John David Anglin
Quoted 25 lines · John David Anglin
James patch now let my 715/64 boot, but still crashes on my B160L:
Quoted 24 lines
swapper (pid 1): Illegal instruction (code 8)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001110000100001111 Not taintedr00-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 000072e6sr00-03 00000000 00000001 00000000 00000000 sr04-07 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078113e0ISR: 00000000 IOR:0f2ff000
CPU: 0 CR30:17c24000CR31:f0102978
ORIG_R28:17ebbe40
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Backtrace:
Quoted 8 lines
Quoted 3 lines
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
Quoted 73 lines · Helge Deller
Quoted 26 lines · John David Anglin
Quoted 25 lines · John David Anglin
James patch now let my 715/64 boot, but still crashes on my B160L:
Quoted 24 lines
swapper (pid 1): Illegal instruction (code 8)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001110000100001111 Not taintedr00-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 000072e6sr00-03 00000000 00000001 00000000 00000000 sr04-07 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078113e0ISR: 00000000 IOR:0f2ff000
CPU: 0 CR30:17c24000CR31:f0102978
ORIG_R28:17ebbe40
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Backtrace:Quoted 8 lines
Quoted 3 lines
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/0x34Bad Address (null pointer deref?): Code=17 regs=17c244c0 (Addr=0f17d000)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111100100001111 Not taintedr00-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 6fffffffsr00-03 00000800 00000001 00000000 00000001 sr04-07 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078102a0ISR: 00000800 IOR:0f17d000
CPU: 0 CR30:17c24000CR31:f0102978
ORIG_R28:17c51000
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0
Quoted 12 lines
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
Signature · 1 line
John David Anglin [email protected]
Helge Deller
maintainerQuoted 86 lines · John David Anglin
Quoted 73 lines · Helge Deller
Quoted 26 lines · John David Anglin
Quoted 25 lines · John David Anglin
James patch now let my 715/64 boot, but still crashes on my B160L:
Quoted 24 lines
swapper (pid 1): Illegal instruction (code 8)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001110000100001111 Not taintedr00-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 000072e6sr00-03 00000000 00000001 00000000 00000000 sr04-07 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078113e0ISR: 00000000 IOR:0f2ff000
CPU: 0 CR30:17c24000CR31:f0102978
ORIG_R28:17ebbe40
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Backtrace:Quoted 8 lines
Quoted 3 lines
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/0x34Bad Address (null pointer deref?): Code=17 regs=17c244c0 (Addr=0f17d000)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111100100001111 Not taintedr00-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 6fffffffsr00-03 00000800 00000001 00000000 00000001 sr04-07 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078102a0ISR: 00000800 IOR:0f17d000
CPU: 0 CR30:17c24000CR31:f0102978
ORIG_R28:17c51000
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Quoted 12 lines
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
Quoted 1 line
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
Quoted 1 line · Helge Deller
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
Signature · 1 line
John David Anglin [email protected]
James Bottomley
maintainerQuoted 10 lines · John David Anglin
Quoted 1 line · Helge Deller
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
Helge Deller
maintainerQuoted 2 lines · John David Anglin
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
Quoted 65 lines · John David Anglin
Quoted 2 lines
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 thevmlinux.ldspatch? (Reminder: without thevmlinux.ldspatch 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/0xd4Kernel Fault: Code=26 regs=8fc30940 (Addr=0f2ff000)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001101111111100001110 Not taintedr00-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 0007d024sr00-03 00000000 00000000 00000000 00000000
sr04-07 00000000 00000000 00000000 00000000IASQ: 00000000 00000000 IAOQ:
10100eec10100ef0
IIR:0f801280ISR: 00000000 IOR:0f2ff000
CPU: 0 CR30:8fc30000CR31: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
Quoted 4 lines
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
James Bottomley
maintainerQuoted 12 lines · Helge Deller
Quoted 2 lines · John David Anglin
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.
Quoted 7 lines
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 thevmlinux.ldspatch? (Reminder: without thevmlinux.ldspatch 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.
Quoted 56 lines
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/0xd4Kernel Fault: Code=26 regs=8fc30940 (Addr=0f2ff000)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001101111111100001110 Not taintedr00-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 0007d024sr00-03 00000000 00000000 00000000 00000000
sr04-07 00000000 00000000 00000000 00000000IASQ: 00000000 00000000 IAOQ:
10100eec10100ef0
IIR:0f801280ISR: 00000000 IOR:0f2ff000
CPU: 0 CR30:8fc30000CR31: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/0x6cBacktrace: [<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
Quoted 8 lines
[<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
Helge Deller
maintainerQuoted 8 lines · James Bottomley
Quoted 7 lines · Helge Deller
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.
Quoted 7 lines
Quoted 4 lines
Do we still have another problem somewhere?
Or is it introduced because of thevmlinux.ldspatch? (Reminder: without thevmlinux.ldspatch 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]
Quoted 1 line
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 2012unwind_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:00pci_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:01pci_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:03pci_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:04pci_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 [email protected]).
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-0x0a0fhda: 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 FUAohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driverohci_hcd 0000:00:0e.2: OHCI Host Controllerohci_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 detecteduhci_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: [email protected]
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
James Bottomley
maintainerQuoted 1 line · Helge Deller
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.
Quoted 2 lines
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
Helge Deller
maintainerQuoted 17 lines · James Bottomley
Quoted 1 line · Helge Deller
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.
Quoted 2 lines
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_aliasdepw,z \prot,8,7,\protbut that all checks out fine (you can compare it with
make_insert_tlb_11). So the page should have read, write and dirty set.
Quoted 6 lines
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_aliaswould 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
James Bottomley
maintainerQuoted 23 lines · Helge Deller
Quoted 22 lines · James Bottomley
Quoted 1 line · Helge Deller
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.
Quoted 2 lines
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_aliasdepw,z \prot,8,7,\protbut 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_aliaswould zero out \prot in a way that functions on your C3000 (PA2.0) but not on the PA1.1 systems.
Quoted 4 lines
Quoted 1 line
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
---
arch/parisc/kernel/entry.S +17 -13
@@ -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
Helge Deller
maintainerQuoted 26 lines · James Bottomley
Quoted 17 lines · Helge Deller
Quoted 16 lines · James Bottomley
Quoted 1 line · Helge Deller
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.
Quoted 2 lines
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_aliasdepw,z \prot,8,7,\protbut that all checks out fine (you can compare it with
make_insert_tlb_11). So the page should have read, write and dirty set.Quoted 8 lines
Quoted 6 lines
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_aliaswould 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.
Quoted 7 lines
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_64BITthat'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
Quoted 2 lines · Helge Deller
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 [email protected]
Helge Deller
maintainerQuoted 6 lines · John David Anglin
Quoted 2 lines · Helge Deller
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.
Quoted 4 lines
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
Hodie XIII Kal. Iun. MMXII AUC quidam/quædam/quoddam 'Helge Deller' inquit:
Quoted 27 lines · James Bottomley
Quoted 26 lines · Helge Deller
Quoted 25 lines · James Bottomley
Quoted 16 lines · Helge Deller
Quoted 1 line
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.
Quoted 2 lines
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_aliasdepw,z \prot,8,7,\protbut that all checks out fine (you can compare it with
make_insert_tlb_11). So the page should have read, write and dirty set.Quoted 6 lines
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_aliaswould 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.
Quoted 8 lines
Quoted 7 lines
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_64BITthat'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.
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=3DyCONFIG_RTC_CLASS=3DyCONFIG_RTC_HCTOSYS=3DyCONFIG_RTC_HCTOSYS_DEVICE=3D"rtc0"
CONFIG_RTC_INTF_SYSFS=3DyCONFIG_RTC_INTF_PROC=3DyCONFIG_RTC_INTF_DEV=3Dy
CONFIG_RTC_DRV_GENERIC=3Dy
Dave
Quoted 1 line · Peter Gantner (nephros)
Hodie XIII Kal. Iun. MMXII AUC quidam/qu=E6dam/quoddam 'Helge Deller'=
=20
Quoted 13 lines
inquit:
Quoted 11 lines · James Bottomley
Quoted 10 lines · Helge Deller
Quoted 9 lines · James Bottomley
Quoted 8 lines · Helge Deller
Quoted 1 line
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.Quoted 1 line
Kernel Fault: Code=3D26 regs=3D8fc30940 (Addr=3D0f2ff000)
It's an access rights trap, presumably on the alias tlb, since th=
e
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
address is definitely in the alias region. The obvious =20 candidate is the
protection id deposit indo_aliasdepw,z \prot,8,7,\protbut 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
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
see how
do_aliaswould 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
Quoted 24 lines
Quoted 10 lines
Quoted 10 lines
Quoted 2 lines
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 notCONFIG_64BITthat's the differentiator, but which interruption path we're on.
Does this fix it?Quoted 2 lines
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
Quoted 7 lines
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_IRQpatch =
=20
Quoted 6 lines
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.
Quoted 8 lines
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
Quoted 44 lines
in the current source?
------------[ cut here ]------------ WARNING: at fs/proc/generic.c:586 Modules linked in:YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000000000001111 Not taintedr00-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 102b8d28sr00-03 00000000 00000000 00000000 00000000 sr04-07 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ:
101e100c101e1010
IIR:03ffe01fISR: 00000000 IOR: 00000000
CPU: 0 CR30:6fc2c000CR31: ffffffffORIG_R28: 10418800
IAOQ[0]:proc_register+0x13c/0x190IAOQ[1]:proc_register+0x140/0x190RP(r2):proc_register+0x13c/0x190Backtrace: [<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 ]---
Quoted 2 lines
Best Wishes,
Peter G.
--
John David Anglin [email protected]
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 1 line · Helge Deller
%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
Signature · 1 line
John David Anglin [email protected]
James Bottomley
maintainerQuoted 88 lines · Helge Deller
Quoted 87 lines · John David Anglin
Quoted 86 lines · Helge Deller
Quoted 30 lines · John David Anglin
Quoted 25 lines · John David Anglin
James patch now let my 715/64 boot, but still crashes on my B160L:
Quoted 16 lines
swapper (pid 1): Illegal instruction (code 8)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001110000100001111 Not taintedr00-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 000072e6sr00-03 00000000 00000001 00000000 00000000 sr04-07 00000000 00000000 00000000 00000000
Quoted 8 lines
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078113e0ISR: 00000000 IOR:0f2ff000
CPU: 0 CR30:17c24000CR31:f0102978
ORIG_R28:17ebbe40
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Backtrace:Quoted 4 lines
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.Quoted 5 lines
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/0x34Bad Address (null pointer deref?): Code=17 regs=17c244c0 (Addr=0f17d000)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111100100001111 Not taintedr00-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 6fffffffsr00-03 00000800 00000001 00000000 00000001 sr04-07 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078102a0ISR: 00000800 IOR:0f17d000
CPU: 0 CR30:17c24000CR31:f0102978
ORIG_R28:17c51000
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Backtrace: [<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
Quoted 8 lines
Quoted 1 line
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 inpacache.Sinflush_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.
Quoted 6 lines
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
James Bottomley
maintainerQuoted 16 lines · James Bottomley
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 16Backtrace: [<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
Quoted 1 line
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
James Bottomley
maintainerQuoted 17 lines · James Bottomley
Quoted 16 lines · James Bottomley
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 16Backtrace: [<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
Quoted 6 lines
Quoted 1 line
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
---
arch/parisc/include/asm/prefetch.h +6 -1
@@ -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. */
Quoted 98 lines · James Bottomley
Quoted 88 lines · Helge Deller
Quoted 87 lines · John David Anglin
Quoted 86 lines · Helge Deller
Quoted 30 lines · John David Anglin
Quoted 25 lines · John David Anglin
James patch now let my 715/64 boot, but still crashes on my B160L:
Quoted 16 lines
swapper (pid 1): Illegal instruction (code 8)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001110000100001111 Not taintedr00-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 000072e6sr00-03 00000000 00000001 00000000 00000000 sr04-07 00000000 00000000 00000000 00000000
Quoted 8 lines
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078113e0ISR: 00000000 IOR:0f2ff000
CPU: 0 CR30:17c24000CR31:f0102978ORIG_R28:17ebbe40
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Backtrace:Quoted 4 lines
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.Quoted 5 lines
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/0x34Bad Address (null pointer deref?): Code=17 regs=17c244c0 (Addr=0f17d000)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111100100001111 Not taintedr00-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 6fffffffsr00-03 00000800 00000001 00000000 00000001 sr04-07 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078102a0ISR: 00000800 IOR:0f17d000
CPU: 0 CR30:17c24000CR31:f0102978ORIG_R28:17c51000
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Backtrace: [<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/0x34Quoted 8 lines
Quoted 1 line
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 inpacache.Sinflush_kernel_icache_page()as well...
Quoted 7 lines
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.
Quoted 8 lines
Quoted 6 lines
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 [email protected]
James Bottomley
maintainerQuoted 116 lines · John David Anglin
Quoted 103 lines · James Bottomley
Quoted 94 lines · Helge Deller
Quoted 91 lines · John David Anglin
Quoted 78 lines · Helge Deller
Quoted 31 lines · John David Anglin
Quoted 26 lines · John David Anglin
James patch now let my 715/64 boot, but still crashes on my B160L:
Quoted 16 lines
swapper (pid 1): Illegal instruction (code 8)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001110000100001111 Not taintedr00-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 000072e6sr00-03 00000000 00000001 00000000 00000000 sr04-07 00000000 00000000 00000000 00000000
Quoted 8 lines
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078113e0ISR: 00000000 IOR:0f2ff000
CPU: 0 CR30:17c24000CR31:f0102978ORIG_R28:17ebbe40
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Backtrace:Quoted 4 lines
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.Quoted 7 lines
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/0x34Bad Address (null pointer deref?): Code=17 regs=17c244c0 (Addr=0f17d000)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111100100001111 Not taintedr00-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 6fffffffsr00-03 00000800 00000001 00000000 00000001 sr04-07 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078102a0ISR: 00000800 IOR:0f17d000
CPU: 0 CR30:17c24000CR31:f0102978ORIG_R28:17c51000
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Quoted 12 lines
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/0x34Quoted 1 line
Try %sr2 or %sr4. %sr0 isn't zero.
Quoted 7 lines
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 inpacache.Sinflush_kernel_icache_page()as well...Quoted 10 lines
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.
Quoted 2 lines
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 <[email protected]>
Date: Wed Dec 22 10:22:11 2010 -0600
parisc: flush pages through tmpalias space
arch/parisc/kernel/pacache.S +20 -18
@@ -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
Please add:
Signed-off by: John David Anglin <[email protected]>
Quoted 199 lines · James Bottomley
Quoted 116 lines · John David Anglin
Quoted 103 lines · James Bottomley
Quoted 94 lines · Helge Deller
Quoted 91 lines · John David Anglin
Quoted 78 lines · Helge Deller
Quoted 31 lines · John David Anglin
Quoted 26 lines · John David Anglin
James patch now let my 715/64 boot, but still crashes on my B160L:
Quoted 16 lines
swapper (pid 1): Illegal instruction (code 8)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001110000100001111 Not taintedr00-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 000072e6sr00-03 00000000 00000001 00000000 00000000 sr04-07 00000000 00000000 00000000 00000000
Quoted 8 lines
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078113e0ISR: 00000000 IOR:0f2ff000
CPU: 0 CR30:17c24000CR31:f0102978ORIG_R28:17ebbe40
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Backtrace:Quoted 4 lines
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.Quoted 7 lines
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/0x34Bad Address (null pointer deref?): Code=17 regs=17c244c0 (Addr=0f17d000)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111100100001111 Not taintedr00-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 6fffffffsr00-03 00000800 00000001 00000000 00000001 sr04-07 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078102a0ISR: 00000800 IOR:0f17d000
CPU: 0 CR30:17c24000CR31:f0102978ORIG_R28:17c51000
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Quoted 12 lines
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/0x34Quoted 1 line
Try %sr2 or %sr4. %sr0 isn't zero.
Quoted 7 lines
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 inpacache.Sinflush_kernel_icache_page()as well...Quoted 10 lines
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.Quoted 2 lines
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 <[email protected]>
Date: Wed Dec 22 10:22:11 2010 -0600parisc: flush pages through tmpalias space
Reported-by Helge Deller <[email protected]>Cc [email protected] #2.6.39+Signed-off-by James Bottomley <[email protected]>arch/parisc/kernel/pacache.S +18
-16@@ -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
arch/parisc/kernel/pacache.S ENTRY(flush_icache_page_asm) · line 734
Quoted 10 lines
arch/parisc/kernel/pacache.S +2
-2- 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 [email protected]
arch/parisc/kernel/pacache.S ENTRY(flush_icache_page_asm) · line 710
Quoted 8 lines
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.arch/parisc/kernel/pacache.S +2
-0+ /* 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
James Bottomley
maintainerQuoted 10 lines · Rolf Eike Beer
arch/parisc/kernel/pacache.S ENTRY(flush_icache_page_asm) · line 710
Quoted 8 lines
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.arch/parisc/kernel/pacache.S +2
-0+ /* 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
James Bottomley
maintainerQuoted 94 lines · Helge Deller
Quoted 64 lines · John David Anglin
Quoted 63 lines · James Bottomley
Quoted 36 lines · James Bottomley
Quoted 30 lines · John David Anglin
Quoted 5 lines · Helge Deller
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.Sis broken. For example,
the cache stride that is loaded inflush_dcache_page_asmto register r1 is wrong. Probably,
thedo_aliasmacro 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_aliasspc,t0,t1,va,pte,prot,nadtlb_emulateidtlba pte,(va)
idtlbp prot,(va)rfir
nopThe 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.Quoted 5 lines
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.Quoted 4 lines
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_aliaswhich 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
---
arch/parisc/kernel/entry.S +3
-0@@ -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,\protQuoted 8 lines
Quoted 5 lines
arch/parisc/kernel/entry.S +1
-0+#endif /* * OK, it is in the temp alias region, check whether "from" or"to".
* Check "subtle" note inpacache.Sre: 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 taintedr00-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 000072e6sr00-03 00000000 00000001 00000000 00000000 sr04-07 00000000 00000000 00000000 00000000
Quoted 8 lines
IASQ: 00000000 00000000 IAOQ:
1010118c10101190
IIR:078113e0ISR: 00000000 IOR:0f2ff000
CPU: 0 CR30:17c24000CR31:f0102978
ORIG_R28:17ebbe40
IAOQ[0]:flush_icache_page_asm+0x28/0x7cIAOQ[1]:flush_icache_page_asm+0x2c/0x7cRP(r2):flush_cache_page+0x90/0xb0Backtrace:
OK, so I assume one (the 715) has a shared D and I TLB and the b160 doesn't?
James
James Bottomley
maintainerQuoted 63 lines · John David Anglin
Quoted 62 lines · James Bottomley
Quoted 36 lines · James Bottomley
Quoted 30 lines · John David Anglin
Quoted 5 lines · Helge Deller
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.Sis broken. For example,
the cache stride that is loaded inflush_dcache_page_asmto register r1 is wrong. Probably,
thedo_aliasmacro 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_aliasspc,t0,t1,va,pte,prot,nadtlb_emulateidtlba pte,(va)
idtlbp prot,(va)rfir
nopThe 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.Quoted 5 lines
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.Quoted 4 lines
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_aliaswhich 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
---
arch/parisc/kernel/entry.S +2
-0@@ -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
Quoted 8 lines
arch/parisc/kernel/entry.S line 591
Quoted 5 lines
arch/parisc/kernel/entry.S +2
-0+ 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
On 05/15/2012 11:13 AM, James Bottomley wrote:
(..)
Quoted 5 lines
OK, I think this is the problem. We have a depd instruction in
do_aliaswhich 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.
Helge Deller
maintainerQuoted 9 lines · Vincent
On 05/15/2012 11:13 AM, James Bottomley wrote:
(..)Quoted 5 lines
OK, I think this is the problem. We have a depd instruction in
do_aliaswhich 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,
Quoted 8 lines
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
James Bottomley
maintainerQuoted 11 lines · Helge Deller
Quoted 5 lines · John David Anglin
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.
Quoted 7 lines
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
Quoted 2 lines · Rolf Eike Beer
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.