http://permalink.gmane.org/gmane.linux.ports.parisc hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.ports.parisc/4467 <pre>I'll queue this patch in our git repo. It seems to work fine for us, thanks, Dave! v2: use test_thread_flag() for max addr determination instead of tsk-&gt;thread.task_size James --- diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index ddb8b24..3ff21b5 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig &lt; at &gt;&lt; at &gt; -18,6 +18,7 &lt; at &gt;&lt; at &gt; 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/processor.h b/arch/parisc/include/asm/processor.h index 0e8b7b8..1419924 100644 --- a/arch/parisc/include/asm/processor.h +++ b/arch/parisc/include/asm/processor.h &lt; at &gt;&lt; at &gt; -40,12 +40,16 &lt; at &gt;&lt; at &gt; #define DEFAULT_TASK_SIZE32(0xFFF00000UL) #define DEFAULT_MAP_BASE32(0x40000000UL) +/* FIXME: remove task_size from current-&gt;thread and remove TMP_TASK_SIZE */ #ifdef CONFIG_64BIT #define DEFAULT_TASK_SIZE (MAX_ADDRESS-0xf000000)</pre> James Bottomley 2012-05-26T08:48:19 http://permalink.gmane.org/gmane.linux.ports.parisc/4466 <pre> Yes, we have all the machinery for a variable task_size, but we never use it. Right, so we have thread_info in %cr30, but we still seem to be using a vestigial struct thread_struct as well as a struct thread_info (so we don't have all the info at the right level). I'll code user_max_addr as (segment_eq(get_fs(), USER_DS) ? TMP_TASK_SIZE : ~0UL) And do TMP_TASK_SIZE as (test_tsk_thread_flag(tsk,TIF_32BIT) ? DEFAULT_TASK_SIZE_32 : DEFAULT_TASK_SIZE) until we can get this sorted out properly (i.e. by removing task_size from struct thread_struct) James -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> James Bottomley 2012-05-26T08:23:35 http://permalink.gmane.org/gmane.linux.ports.parisc/4465 <pre> i am robothroli, Purchase manager from roli Merchant Ltd. We are Import/export Company based in taiwan. We are interested in purchasing your product and I would like to make an inquiry. Please inform me on: Sample availability and price Minimum order quantity FOB Prices Sincerely Purchase Manager robothroli -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> robothroli company 2012-05-25T13:45:54 http://permalink.gmane.org/gmane.linux.ports.parisc/4464 <pre>From: James Bottomley &lt;James.Bottomley&lt; at &gt;HansenPartnership.com&gt; Date: Fri, 25 May 2012 14:59:52 +0100 Do what I did on Sparc wrt. TASK_SIZE, that way you won't need to include linux/sched.h The only reason you need linux/sched.h is to get test_tsk_thread_flag(), for your TASK_SIZE_OF(). But that's completely pointless for TASK_SIZE which only needs to look at the current thread's settings. Thus if you use test_thread_flag() for TASK_SIZE, instead of trying to borrow TASK_SIZE_OF()'s implementation, you'll no longer have this linux/sched.h dependency. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> David Miller 2012-05-25T20:16:51 http://permalink.gmane.org/gmane.linux.ports.parisc/4463 <pre>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 &lt;linux/sched.h&gt; 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 &lt; at &gt;&lt; at &gt; -18,6 +18,7 &lt; at &gt;&lt; at &gt; 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 9ac066</pre> James Bottomley 2012-05-25T13:59:52 http://permalink.gmane.org/gmane.linux.ports.parisc/4462 <pre> Ooops. Sorry. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Thomas Gleixner 2012-05-25T12:21:07 http://permalink.gmane.org/gmane.linux.ports.parisc/4460 <pre>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&lt; at &gt;bell.net -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> John David Anglin 2012-05-23T23:09:29 http://permalink.gmane.org/gmane.linux.ports.parisc/4459 <pre>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 s</pre> Peter Gantner (nephros 2012-05-23T08:47:18 http://permalink.gmane.org/gmane.linux.ports.parisc/4458 <pre> 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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Helge Deller 2012-05-21T20:59:46 http://permalink.gmane.org/gmane.linux.ports.parisc/4457 <pre>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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Bjorn Helgaas 2012-05-21T20:23:20 http://permalink.gmane.org/gmane.linux.ports.parisc/4456 <pre> 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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Grant Grundler 2012-05-21T16:19:57 http://permalink.gmane.org/gmane.linux.ports.parisc/4455 <pre>Hi, I just received this email as it seems that hwdb&lt; at &gt;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 &lt;karl.kolsto&lt; at &gt;uib.no&gt; Date: Mon, May 21, 2012 at 6:39 AM Subject: Washing of machine owner database To: hwdb&lt; at &gt;parisc-linux.org Cc: Karl Magnus Kolstoe &lt;karl.kolsto&lt; at &gt;uib.no&gt; 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&amp;name=K100 Just thought I should mention it. Thanks -- Karl Magnus Kolstø - Member of the first RFC 1149 implementation team. </pre> Thibaut VARENE 2012-05-21T15:37:15 http://permalink.gmane.org/gmane.linux.ports.parisc/4454 <pre> 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&lt; at &gt;bell.net -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> John David Anglin 2012-05-20T21:25:50 http://permalink.gmane.org/gmane.linux.ports.parisc/4453 <pre>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&lt; at &gt;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 &lt;http://gnu.org/licenses/gpl.html&gt; This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "sh</pre> Helge Deller 2012-05-20T21:09:09 http://permalink.gmane.org/gmane.linux.ports.parisc/4451 <pre> 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 &lt; at &gt;&lt; at &gt; -552,7 +552,7 &lt; at &gt;&lt; at &gt; * 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(&lt;&gt;),n 0,\spc,\fault ldilL%(TMPALIAS_MAP_START),\tmp #if defined(CONFIG_64BIT) &amp;&amp; (TMPALIAS_MAP_START &gt;= 0x80000000) &lt; at &gt;&lt; at &gt; -581,11 +581,15 &lt; at &gt;&lt; at &gt; */ cmpiclr,=0x01,\tmp,%r0 ldi(_PAGE_DIRTY|_PAGE_READ|_PAGE_WRITE),\prot -#ifdef CONFIG_64BIT +.ifc</pre> James Bottomley 2012-05-20T20:15:24 http://permalink.gmane.org/gmane.linux.ports.parisc/4450 <pre> 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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Helge Deller 2012-05-20T19:11:43 http://permalink.gmane.org/gmane.linux.ports.parisc/4449 <pre> 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&lt; at &gt;bell.net -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> John David Anglin 2012-05-20T18:46:21 http://permalink.gmane.org/gmane.linux.ports.parisc/4448 <pre> 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&lt; at &gt;9.cn PHONE:+447553197697 -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Anthony.Escalera< at >rcc.edu 2012-05-20T13:16:12 http://permalink.gmane.org/gmane.linux.ports.parisc/4447 <pre> 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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> James Bottomley 2012-05-20T10:01:00 http://permalink.gmane.org/gmane.linux.ports.parisc/4446 <pre> 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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Al Viro 2012-05-20T09:04:44 http://permalink.gmane.org/gmane.linux.ports.parisc/4445 <pre>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-&gt;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-&gt;ptrace &amp; 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 </pre> Al Viro 2012-05-20T08:40:42 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.ports.parisc