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/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 http://permalink.gmane.org/gmane.linux.ports.parisc/4444 <pre>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 ---</pre> James Bottomley 2012-05-19T18:51:05 http://permalink.gmane.org/gmane.linux.ports.parisc/4443 <pre> ... 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 &lt; at &gt;&lt; at &gt; -71,7 +71,7 &lt; at &gt;&lt; at &gt; 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 &lt; at &gt;&lt; at &gt; -115,6 +115,8 &lt; at &gt;&lt; at &gt; sys_rt_sigreturn(struct pt_regs *regs, int in_syscall) (usp - sigframe_size); </pre> Al Viro 2012-05-19T13:37:12 http://permalink.gmane.org/gmane.linux.ports.parisc/4442 <pre>  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&lt; at &gt;gmail.comCpt. James Hans. -- 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> Capt James Hans 2012-05-15T20:41:48 http://permalink.gmane.org/gmane.linux.ports.parisc/4438 <pre>[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&lt; at &gt;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..</pre> Helge Deller 2012-05-18T21:09:10 http://permalink.gmane.org/gmane.linux.ports.parisc/4435 <pre> BTW, what should we put into the trampolines of subsequent sigframes when we are building more that one? I.e. suppose we are in a syscall and see two signals. We build a sigframe for the first one, with r25 = 1, call rt_sigreturn() in it. Return address of original syscall is stored into sigcontext of that frame, our return address set to the entry point of handler1. Now we see the second signal and build another sigframe. That one will have the entry point of the first handler stored in sigframe and we'll set the things up so that return to userland will land us in the entry of handler2. Fine, but... what should we have in r25 for rt_sigreturn() in the second trampoline? We return to userland and find ourselves in the beginning of handler2. It's executed and eventually we return from it. We are at the beginning of the second trampoline now. rt_sigreturn() is called, restores the registers from the second sigcontext and returns to userland. We are at the beginning of handler1. It is executed and </pre> Al Viro 2012-05-18T19:56:10 http://permalink.gmane.org/gmane.linux.ports.parisc/4434 <pre> In any case, it doesn't look like something that might be HPUX-related - there r28 is not used for arguments or syscall number either, as far as I can tell... That's a side story, in any case; whatever the reason for restoring r28, it only masks the bug with double restarts. If you enter syscall with r28 equal to e.g. -ERESTARTNOINTR, get the same value from sys_whatever() and have a couple of pending signals, you will have syscall_restart() called twice, each time seeing regs-&gt;gr[28] == -ERESTARTNOINTR and leaving it unchanged. regs-&gt;gr[31] will be decremented by 8 on each of those calls, first time back to your syscall (correctly), then to the entry point of the first handler minus 8. -- 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-18T18:57:12 http://permalink.gmane.org/gmane.linux.ports.parisc/4432 <pre>Since "[PATCH] PA-RISC assembler cleanups and fixes" back in 2005, (commit b6181a0a1999c7d4dd937d7f5234fb62eca68e89 in historical tree), we do loop until all pending signals are dealt with. Which is fine, except that now we need to deal with syscall restart logics in all of them. What happens if we have r28 containing e.g. -ERESTARTNOINTR when we do a syscall? Note that x86 analog of the code in parisc syscall_restart() differs in one respect - the same register is used for return value and syscall number. So once we'd copied -&gt;orig_ax to -&gt;ax, that's it - it *can't* be a restart-worthy value anymore, since then we would've been in a syscall with negative syscall number and -&gt;ax before the assignment would've been -ENOSYS. I.e. not a restart-worthy value, so we wouldn't have hit that regs-&gt;ax = regs-&gt;orig_ax in the first place. On parisc the counterpart of the above doesn't work; AFAICS, we might have whatever we bloody please in r28 when we make a syscall. Syscall number goes in r20, arguments are </pre> Al Viro 2012-05-18T17:58:33 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.ports.parisc