gmane.linux.ports.parisc

[PATCH] update parisc to use generic strncpy_from_user()

James Bottomley — 2012-05-25T13:59:52

I'll queue this patch in our git repo.  It seems to work fine for us,
thanks, Dave!

Parisc people, I'm a bit worried about the #include <linux/sched.h> in
asm/uaccess.h ... I'm sure that's going to lead to complications later.
It's needed to get the dynamic TASK_SIZE, which expands through the task
structure to fill in user_addr_max() ... I'm thinking though that the
top of address space doesn't provide much protection on pa (since our
stack grows up towards it anyway, so we could just replace that with
~0UL ... what do people think?

James

---

diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index ddb8b24..3ff21b5 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
< at >< at > -18,6 +18,7 < at >< at > config PARISC
 select IRQ_PER_CPU
 select ARCH_HAVE_NMI_SAFE_CMPXCHG
 select GENERIC_SMP_IDLE_THREAD
+select GENERIC_STRNCPY_FROM_USER
 
 help
   The PA-RISC microprocessor is designed by Hewlett-Packard and used
diff --git a/arch/parisc/include/asm/uaccess.h b/arch/parisc/include/asm/uaccess.h
index 9ac0660..d07eb50 100644
--- a/arch/parisc/include/asm/uaccess.h
+++ b/arch/parisc/include/asm/uaccess.h
< at >< at > -8,6 +8,7 < at >< at >
 #include <asm/cache.h>
 #include <asm/errno.h>
 #include <asm-generic/uaccess-unaligned.h>
+#include <linux/sched.h>
 
 #define VERIFY_READ 0
 #define VERIFY_WRITE 1
< at >< at > -218,15 +219,15 < at >< at > struct exception_data {
 extern unsigned long lcopy_to_user(void __user *, const void *, unsigned long);
 extern unsigned long lcopy_from_user(void *, const void __user *, unsigned long);
 extern unsigned long lcopy_in_user(void __user *, const void __user *, unsigned long);
-extern long lstrncpy_from_user(char *, const char __user *, long);
+extern long strncpy_from_user(char *, const char __user *, long);
 extern unsigned lclear_user(void __user *,unsigned long);
 extern long lstrnlen_user(const char __user *,long);
-
 /*
  * Complex access routines -- macros
  */
+#define user_addr_max() \
+(segment_eq(get_fs(), KERNEL_DS) ? ~0UL : TASK_SIZE)
 
-#define strncpy_from_user lstrncpy_from_user
 #define strnlen_user lstrnlen_user
 #define strlen_user(str) lstrnlen_user(str, 0x7fffffffL)
 #define clear_user lclear_user
diff --git a/arch/parisc/kernel/parisc_ksyms.c b/arch/parisc/kernel/parisc_ksyms.c
index a7bb757..ceec85d 100644
--- a/arch/parisc/kernel/parisc_ksyms.c
+++ b/arch/parisc/kernel/parisc_ksyms.c
< at >< at > -44,7 +44,6 < at >< at > EXPORT_SYMBOL(__cmpxchg_u64);
 #endif
 
 #include <asm/uaccess.h>
-EXPORT_SYMBOL(lstrncpy_from_user);
 EXPORT_SYMBOL(lclear_user);
 EXPORT_SYMBOL(lstrnlen_user);
 
diff --git a/arch/parisc/lib/lusercopy.S b/arch/parisc/lib/lusercopy.S
index 1bd23cc..6f2d935 100644
--- a/arch/parisc/lib/lusercopy.S
+++ b/arch/parisc/lib/lusercopy.S
< at >< at > -61,47 +61,6 < at >< at >
 .endm
 
 /*
- * long lstrncpy_from_user(char *dst, const char *src, long n)
- *
- * Returns -EFAULT if exception before terminator,
- *         N if the entire buffer filled,
- *         otherwise strlen (i.e. excludes zero byte)
- */
-
-ENTRY(lstrncpy_from_user)
-.proc
-.callinfo NO_CALLS
-.entry
-comib,=     0,%r24,$lsfu_done
-copy        %r24,%r23
-get_sr
-1:      ldbs,ma     1(%sr1,%r25),%r1
-$lsfu_loop:
-stbs,ma     %r1,1(%r26)
-comib,=,n   0,%r1,$lsfu_done
-addib,<>,n  -1,%r24,$lsfu_loop
-2:      ldbs,ma     1(%sr1,%r25),%r1
-$lsfu_done:
-sub         %r23,%r24,%r28
-$lsfu_exit:
-bv          %r0(%r2)
-nop
-.exit
-ENDPROC(lstrncpy_from_user)
-
-.section .fixup,"ax"
-3:      fixup_branch $lsfu_exit
-ldi         -EFAULT,%r28
-.previous
-
-.section __ex_table,"aw"
-ASM_ULONG_INSN 1b,3b
-ASM_ULONG_INSN 2b,3b
-.previous
-
-.procend

Re: Fix parisc compile failure after smp: Add task_struct argument to __cpu_up()

Thomas Gleixner — 2012-05-25T12:21:07


Ooops. Sorry.

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

Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100

John David Anglin — 2012-05-23T23:09:29

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

CONFIG_HP_SDC_RTC=m

CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y

CONFIG_RTC_DRV_GENERIC=y

Dave

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


--
John David Anglindave.anglin< at >bell.net



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

Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100

Peter Gantner (nephros — 2012-05-23T08:47:18

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


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.

Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100

Helge Deller — 2012-05-21T20:59:46

Ok, will do.


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

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

HP K360 available in Norway

Bjorn Helgaas — 2012-05-21T20:23:20

Someone with an HP K360 contacted me, looking for a way to give it to
somebody who could use it, preferably for Linux work.  It's a large
machine and expensive to ship, so ideally you'd be able to pick it up
in Bergen, Norway.

If you're interested, let me know and I can get you in touch with the owner.

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

Re: Washing of machine owner database

Grant Grundler — 2012-05-21T16:19:57

Thanks Thibaut!

Personally, I'd just delete anything related to "owners" from the
website. I'm willing to do that if there are no objections. Initially
it was useful to know who had particular HW. Now we can just post here
to ask if someone can please test on the necessary HW (e.g. pa8800 or
Astro chipset or 712).

cheers,
grant

ps. Kudos to Karl for pointing out the abuse.

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

Fwd: Washing of machine owner database

Thibaut VARENE — 2012-05-21T15:37:15

Hi,

I just received this email as it seems that hwdb< at >p-l.o is still an
alias for me, which prompts the following remarks: I haven't been
doing any work on the p-l hwdb in the past 5+ years I think so maybe
that alias could be better used otherwise, and I think that aside
pruning the stuff that spammers have put there, it might be useful to
make that website/database read-only... :-)

HTH,
T-Bone


---------- Forwarded message ----------
From: Karl Magnus Kolstoe <karl.kolsto< at >uib.no>
Date: Mon, May 21, 2012 at 6:39 AM
Subject: Washing of machine owner database
To: hwdb< at >parisc-linux.org
Cc: Karl Magnus Kolstoe <karl.kolsto< at >uib.no>


Hi,

I had a quick look at the machine database and concluded that you
might want to wash your database a bit.

Have e.g a look at "Owners of this machine" on this page;
http://hwdb.parisc-linux.org/view.php?type=machine&name=K100

Just thought I should mention it.

Thanks
--
Karl Magnus Kolstø - Member of the first RFC 1149 implementation team.

Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100

John David Anglin — 2012-05-20T21:25:50


Please file a bug report ;(

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

Suggest using 2.22 branch for now.

Dave
--
John David Anglindave.anglin< at >bell.net



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

Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100

Helge Deller — 2012-05-20T21:09:09

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< at >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
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100

James Bottomley — 2012-05-20T20:15:24

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

Does this fix it?

James

---

diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
index 5350342..07ef351 100644
--- a/arch/parisc/kernel/entry.S
+++ b/arch/parisc/kernel/entry.S
< at >< at > -552,7 +552,7 < at >< at >
  * 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) */
-.macrodo_aliasspc,tmp,tmp1,va,pte,prot,fault
+.macrodo_aliasspc,tmp,tmp1,va,pte,prot,fault,patype
 cmpib,COND(<>),n 0,\spc,\fault
 ldilL%(TMPALIAS_MAP_START),\tmp
 #if defined(CONFIG_64BIT) && (TMPALIAS_MAP_START >= 0x80000000)
< at >< at > -581,11 +581,15 < at >< at >
  */
 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.
< at >< at > -1189,7 +1193,7 < at >< at > dtlb_miss_20w:
 nop
 
 dtlb_check_alias_20w:
-do_aliasspc,t0,t1,va,pte,prot,dtlb_fault
+do_aliasspc,t0,t1,va,pte,prot,dtlb_fault,20
 
 idtlbt          pte,prot
 
< at >< at > -1213,7 +1217,7 < at >< at > nadtlb_miss_20w:
 nop
 
 nadtlb_check_alias_20w:
-do_aliasspc,t0,t1,va,pte,prot,nadtlb_emulate
+do_aliasspc,t0,t1,va,pte,prot,nadtlb_emulate,20
 
 idtlbt          pte,prot
 
< at >< at > -1245,7 +1249,7 < at >< at > dtlb_miss_11:
 nop
 
 dtlb_check_alias_11:
-do_aliasspc,t0,t1,va,pte,prot,dtlb_fault
+do_aliasspc,t0,t1,va,pte,prot,dtlb_fault,11
 
 idtlba          pte,(va)
 idtlbp          prot,(va)
< at >< at > -1277,7 +1281,7 < at >< at > nadtlb_miss_11:
 nop
 
 nadtlb_check_alias_11:
-do_aliasspc,t0,t1,va,pte,prot,nadtlb_emulate
+do_aliasspc,t0,t1,va,pte,prot,nadtlb_emulate,11
 
 idtlba          pte,(va)
 idtlbp          prot,(va)
< at >< at > -1304,7 +1308,7 < at >< at > dtlb_miss_20:
 nop
 
 dtlb_check_alias_20:
-do_aliasspc,t0,t1,va,pte,prot,dtlb_fault
+do_aliasspc,t0,t1,va,pte,prot,dtlb_fault,20
 
 idtlbt          pte,prot
 
< at >< at > -1330,7 +1334,7 < at >< at > nadtlb_miss_20:
 nop
 
 nadtlb_check_alias_20:
-do_aliasspc,t0,t1,va,pte,prot,nadtlb_emulate
+do_aliasspc,t0,t1,va,pte,prot,nadtlb_emulate,20
 
 idtlbt          pte,prot
 
< at >< at > -1457,7 +1461,7 < at >< at > naitlb_miss_20w:
 nop
 
 naitlb_check_alias_20w:
-do_aliasspc,t0,t1,va,pte,prot,naitlb_fault
+do_aliasspc,t0,t1,va,pte,prot,naitlb_fault,20
 
 iitlbtpte,prot
 
< at >< at > -1511,7 +1515,7 < at >< at > naitlb_miss_11:
 nop
 
 naitlb_check_alias_11:
-do_aliasspc,t0,t1,va,pte,prot,itlb_fault
+do_aliasspc,t0,t1,va,pte,prot,itlb_fault,11
 
 iitlba          pte,(%sr0, va)
 iitlbp          prot,(%sr0, va)
< at >< at > -1557,7 +1561,7 < at >< at > naitlb_miss_20:
 nop
 
 naitlb_check_alias_20:
-do_aliasspc,t0,t1,va,pte,prot,naitlb_fault
+do_aliasspc,t0,t1,va,pte,prot,naitlb_fault,20
 
 iitlbt          pte,prot
 


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

Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100

Helge Deller — 2012-05-20T19:11:43

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

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

Re: [parisc] double restarts on multiple signal arrivals

John David Anglin — 2012-05-20T18:46:21


This looks good to me.  There is similar code in entry.S.

I added the above change to my patch set for stable 3.3.6.  System still
boots.  I singled stepped /bin/ls through a directory listing and it  
seemed
to work.

Dave
--
John David Anglindave.anglin< at >bell.net



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

(unknown)

2012-05-20T13:16:12


Your e-mail won £1,000,000.00 in the BBC 2012 bonanza, For claims, Send your details to Mr.Roy Calton viaE-mail: mrcaltonclaimsunit1< at >9.cn PHONE:+447553197697
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100

James Bottomley — 2012-05-20T10:01:00

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.

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


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

Re: [parisc] double restarts on multiple signal arrivals

Al Viro — 2012-05-20T09:04:44

Actually, looks like I am missing something, but it's not particulary subtle.
SYSCALL_TRACE is needed for do_syscall_trace_enter() to do anything;
any of SYSCALL_TRACE/SINGLESTEP/BLOCKSTEP is makes do_syscall_trace_leave()
do things.  So checking one bit in flags is not enough - any of those 3 is
a reason for taking the slow path.  The point still stands, though -
mfctl   %cr30, %r1
LDREG   TI_FLAGS(%r1),%r1
ldi(_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP | _TIF_BLOCKSTEP), %r19
        and,COND(=) %r19, %r1, %r0
b,n.Ltracesys
would still be no worse on the fast path and would not hit the slow path in
a lot of cases when the current code does it for no apparent reason.

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

Re: [parisc] double restarts on multiple signal arrivals

Al Viro — 2012-05-20T08:40:42

BTW, after looking through the asm glue there, I've noticed something
rather odd.  *All* architectures other than parisc have the following thing
done on syscall entry:
* check if we have TIF_SYSCALL_TRACE in flags; bugger off to slow
path if we do.
* there check if we have PT_PTRACED in current->ptrace and if so
do the standard song and dance with raising SIGTRAP or SIGTRAP | 0x80,
etc.

parisc does that in the opposite order - it goes to slow path if
current->ptrace & PT_PTRACED is true.  The same actions with raising
SIGTRAP, etc. are done only if TIF_SYSCALL_TRACE is there as well,
but by that point we'd already plonked a bunch of registers on the
stack and we actually stay on the slow path even in absense of SYSCALL_TRACE.

The thing is, other architectures have a good reason for looking at
SYSCALL_TRACE first and not bothering with all that fun if it's not set.
PT_PTRACED is set when the task is being traced; it does *not* imply
stopping on every syscall entry.  E.g. a perfectly normal situation is
when in gdb you've said
break foo.c:69
cont
and let the process run until it hits that breakpoint.  It has PT_PTRACED
all along.  It will be stopped when it gets a signal, including SIGTRAP
we'll get when it steps on that breakpoint.  But by that time it's very
likely to have passed through tons of syscalls without stopping on any of
them.  SYSCALL_TRACE is set *only* when we want the process to stop on the
next syscall.  That's what strace(1) and friends are using.  So it doesn't
make sense to get overhead for all processes that have PT_PTRACED;
SYSCALL_TRACE is less likely, so checking it first is an obvious approach.

Moreover, checking PT_TRACED first is not even cheaper in the common case
(i.e. when branch to .Ltracesys is not taken at all).  As it is, parisc does
        mfctl   %cr30, %r1
        LDREG   TI_TASK(%r1),%r1
        ldw     TASK_PTRACE(%r1), %r1
        bb,<,n  %r1,31,.Ltracesys
and that's actually an extra dereference compared to
        mfctl   %cr30, %r1
        LDREG   TI_FLAGS(%r1),%r1
        bb,<,n  %r1,31 - TIF_SYSCALL_TRACE,.Ltracesys
Note that tracehook_report_syscall_entry/tracehook_report_syscall_exit
are checking PT_PTRACED, so it's not like we needed to change anything
other than that spot - resulting logics will be equivalent to what we
have right now.  Looks like a fairly straightforward optimisation...
Am I missing something subtle and parisc-specific here?
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] parisc fixes for 3.3-rc5

James Bottomley — 2012-05-19T18:51:05

This is a set of three bug fixes that gets parisc running again on
systems with PA1.1 processors.  Two fix regressions introduced in 2.6.39
and one fixes a prefetch bug that only affects PA7300LC processors.  We
also have another pending fix to do with the sectional arrangement of
vmlinux.lds, but there's a query on it during testing on one particular
system type, so I'll hold off sending it in for now.

The patches are here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6.git parisc-fixes

The short changelog is:


James Bottomley (2):
      [PARISC] fix panic on prefetch(NULL) on PA7300LC
      [PARISC] fix PA1.1 oops on boot

John David Anglin (1):
      [PARISC] fix crash in flush_icache_page_asm on PA1.1


And the diffstat:

 arch/parisc/include/asm/prefetch.h |    7 ++++++-
 arch/parisc/kernel/entry.S         |    4 ++++
 arch/parisc/kernel/pacache.S       |   38 +++++++++++++++++++-----------------
 3 files changed, 30 insertions(+), 19 deletions(-)

With the full diff below

James

---

diff --git a/arch/parisc/include/asm/prefetch.h b/arch/parisc/include/asm/prefetch.h
index c5edc60..1ee7c82 100644
--- a/arch/parisc/include/asm/prefetch.h
+++ b/arch/parisc/include/asm/prefetch.h
< at >< at > -21,7 +21,12 < at >< at >
 #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. */
diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
index 6f05944..5350342 100644
--- a/arch/parisc/kernel/entry.S
+++ b/arch/parisc/kernel/entry.S
< at >< at > -581,7 +581,11 < at >< at >
  */
 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.
diff --git a/arch/parisc/kernel/pacache.S b/arch/parisc/kernel/pacache.S
index 93ff3d9..5d7218a 100644
--- a/arch/parisc/kernel/pacache.S
+++ b/arch/parisc/kernel/pacache.S
< at >< at > -692,7 +692,7 < at >< at > ENTRY(flush_icache_page_asm)
 
 /* Purge any old translation */
 
-pitlb(%sr0,%r28)
+pitlb(%sr4,%r28)
 
 ldilL%icache_stride, %r1
 ldwR%icache_stride(%r1), %r1
< at >< at > -706,27 +706,29 < at >< at > 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 26 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


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

Re: [parisc] double restarts on multiple signal arrivals

Al Viro — 2012-05-19T13:37:12

... only that part should be done in sys_rt_sigreturn() instead, or we'll miss
it for 32bit-on-64bit case.

diff --git a/arch/parisc/hpux/gate.S b/arch/parisc/hpux/gate.S
index 38a1c1b..0114688 100644
--- a/arch/parisc/hpux/gate.S
+++ b/arch/parisc/hpux/gate.S
< at >< at > -71,7 +71,7 < at >< at > ENTRY(hpux_gateway_page)
 STREG%r26, TASK_PT_GR26(%r1) /* 1st argument */
 STREG%r27, TASK_PT_GR27(%r1)/* user dp */
 STREG   %r28, TASK_PT_GR28(%r1)         /* return value 0 */
-STREG   %r28, TASK_PT_ORIG_R28(%r1)     /* return value 0 (saved for signals) */
+STREG   %r0, TASK_PT_ORIG_R28(%r1)     /* don't prohibit restarts */
 STREG   %r29, TASK_PT_GR29(%r1)         /* 8th argument */
 STREG%r31, TASK_PT_GR31(%r1)/* preserve syscall return ptr */
 
diff --git a/arch/parisc/kernel/signal.c b/arch/parisc/kernel/signal.c
index 12c1ed3..369b1c4 100644
--- a/arch/parisc/kernel/signal.c
+++ b/arch/parisc/kernel/signal.c
< at >< at > -115,6 +115,8 < at >< at > sys_rt_sigreturn(struct pt_regs *regs, int in_syscall)
 (usp - sigframe_size);
 DBG(2,"sys_rt_sigreturn: frame is %p\n", frame);
 
+regs->orig_r28 = 1; /* no restarts for sigreturn */
+
 #ifdef CONFIG_64BIT
 compat_frame = (struct compat_rt_sigframe __user *)frame;
 
< at >< at > -471,6 +473,9 < at >< at > handle_signal(unsigned long sig, siginfo_t *info, struct k_sigaction *ka,
 static inline void
 syscall_restart(struct pt_regs *regs, struct k_sigaction *ka)
 {
+if (regs->orig_r28)
+return;
+regs->orig_r28 = 1; /* no more restarts */
 /* Check the return code */
 switch (regs->gr[28]) {
 case -ERESTART_RESTARTBLOCK:
< at >< at > -493,8 +498,6 < at >< at > syscall_restart(struct pt_regs *regs, struct k_sigaction *ka)
  * we have to do is fiddle the return pointer.
  */
 regs->gr[31] -= 8; /* delayed branching */
-/* Preserve original r28. */
-regs->gr[28] = regs->orig_r28;
 break;
 }
 }
< at >< at > -502,6 +505,9 < at >< at > syscall_restart(struct pt_regs *regs, struct k_sigaction *ka)
 static inline void
 insert_restart_trampoline(struct pt_regs *regs)
 {
+if (regs->orig_r28)
+return;
+regs->orig_r28 = 1; /* no more restarts */
 switch(regs->gr[28]) {
 case -ERESTART_RESTARTBLOCK: {
 /* Restart the system call - no handlers present */
< at >< at > -536,9 +542,6 < at >< at > insert_restart_trampoline(struct pt_regs *regs)
 flush_user_icache_range(regs->gr[30], regs->gr[30] + 4);
 
 regs->gr[31] = regs->gr[30] + 8;
-/* Preserve original r28. */
-regs->gr[28] = regs->orig_r28;
-
 return;
 }
 case -ERESTARTNOHAND:
< at >< at > -550,9 +553,6 < at >< at > insert_restart_trampoline(struct pt_regs *regs)
  * slot of the branch external instruction.
  */
 regs->gr[31] -= 8;
-/* Preserve original r28. */
-regs->gr[28] = regs->orig_r28;

Greeting from Kabul......

Capt James Hans — 2012-05-15T20:41:48


 Hello,I am Cpt. James Hans an officer of the U.S Army, serving with the 82nd Airborne Division Peace keeping force in Kabul,Afghanistan.We are currently in Afghanistan and I have some important items that i need to ship to you.I need you to reply only if you are interested.I will explain further when i get a response from you and here is my private email: jameshans22< at >gmail.comCpt. James Hans.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issue booting v2.6.39 .. v3.4-rc6 on hp712/100

Helge Deller — 2012-05-18T21:09:10

[crash log removed - new one see below]

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

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

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


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

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

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

Kernel panic - not syncing: Kernel Fault

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