http://blog.gmane.org/gmane.linux.ports.sparc hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.ports.sparc/16441 <pre>Took a closer look at the remaining references in arch/kernel/sparc to CONFIG_SPARC_LEON. It turned out to be easier than anticipated to allow multi platfrom support in the remaining bits. This is on top of the previous batch sent earlier today. With this patch I can build a kernel with LEON selected and it boots on my ss5 :-) Sam Sam Ravnborg (4): sparc32: refactor cpu_idle() sparc32,leon: always include leon_pmc in build sparc32,leon: always support leon in ioport sparc32: support leon + sun in dma_make_coherent() arch/sparc/include/asm/dma-mapping.h | 9 +++++++-- arch/sparc/kernel/Makefile | 2 +- arch/sparc/kernel/ioport.c | 23 ++++++----------------- arch/sparc/kernel/leon_pmc.c | 15 +++++++++------ arch/sparc/kernel/process_32.c | 28 ++-------------------------- 5 files changed, 25 insertions(+), 52 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo&lt; at &gt;</pre> Sam Ravnborg 2012-05-26T14:40:47 http://comments.gmane.org/gmane.linux.ports.sparc/16423 <pre>With this patch-set applied most of the low-level code in the kernel supports both LEON and SUN. The only references left are in: arch/sparc/Kconfig arch/sparc/kernel/Makefile arch/sparc/kernel/ioport.c arch/sparc/kernel/process_32.c drivers/pci/Makefile drivers/usb/Kconfig drivers/usb/host/Kconfig drivers/usb/host/ehci-hcd.c drivers/usb/host/uhci-hcd.c I need to analyse things a bit before attacking the last users, and wanted to get this batch out for review (and eventually applied). I expect some variant (like SPARC_LEON_PCI) to continue to be present - but lets see. Changes since the [RFC] version: - used more optimal assembler as suggested by davem - fix up error message as pointed out by davem - fix up error message as pointed out by Julian Calaby - use LEON as default and patch for SUN (which uncovered a bug - good!) - added several patches... This version boots on my ss5. If I build a LEON variant the build fails when it starts to probe my SCSI drive (I think it was here). This was expected since </pre> Sam Ravnborg 2012-05-26T07:17:49 http://comments.gmane.org/gmane.linux.ports.sparc/16422 <pre>Hi, I've pulled todays git from git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git master I'v build an smp kernel with some spin-lock and driver-dma debugging stuff enabled. I've booted the kernel on my sparcstation-10 with dual supersparc-II (sm71) cpu The kernel boots and I can ssh into the system and it seems to run fine with "normal" use. I do see frequent debug messages about "BUG: scheduling while atomic: swapper/2/0/0x00000000". Under more heavy load, like building a kernel with "make -j4" the system will lock up after about 10 minutes, no error messages. root:~# uname -a Linux ss10 3.4.0-07645-g456d3d4-dirty #5 SMP Fri May 25 18:51:24 CEST 2012 sparc sun4m Texas Instruments, Inc. - SuperSparc-(II) GNU/Linux regards Magnus Lindholm -- To unsubscribe from this list: send the line "unsubscribe sparclinux" 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> Magnus Lindholm 2012-05-25T17:35:05 http://comments.gmane.org/gmane.linux.ports.sparc/16421 <pre> UltraSPARC-T2 and later do not use the fp_exception_other trap and do not set the floating point trap type field in the %fsr at all when you try to execute an unimplemented FPU operation. Instead, it uses the illegal_instruction trap and it leaves the floating point trap type field clear. So we should not validate the %fsr trap type field when do_mathemu() is invoked from the illegal instruction handler. Also, the floating point trap type field is 3 bits, not 4 bits. Signed-off-by: David S. Miller &lt;davem&lt; at &gt;davemloft.net&gt; --- arch/sparc/kernel/traps_64.c | 12 +++++++----- arch/sparc/math-emu/math_64.c | 20 ++++++++++++++------ 2 files changed, 21 insertions(+), 11 deletions(-) diff --git a/arch/sparc/kernel/traps_64.c b/arch/sparc/kernel/traps_64.c index c72fdf5..3b05e66 100644 --- a/arch/sparc/kernel/traps_64.c +++ b/arch/sparc/kernel/traps_64.c &lt; at &gt;&lt; at &gt; -2054,7 +2054,7 &lt; at &gt;&lt; at &gt; void do_fpieee(struct pt_regs *regs) do_fpe_common(regs); } -extern int do_mathemu(struct pt_regs *, struct fpustate *); +exte</pre> David Miller 2012-05-25T07:37:14 http://comments.gmane.org/gmane.linux.ports.sparc/16420 <pre> This has the generic strncpy_from_user() implementation architectures can now use, which we've been developing on linux-arch over the past few days. For good measure I ran both a 32-bit and a 64-bit glibc testsuite run, and the latter of which pointed out an adjustment I needed to make to sparc's user_addr_max() definition. Linus, you were right, STACK_TOP was not the right thing to use, even on sparc itself :-) From Sam Ravnborg, we have a conversion of sparc32 over to the common alloc_thread_info_node(), since the aspect which originally blocked our doing so (sun4c) has been removed. Please pull, thanks a lot. The following changes since commit 72c04af9a2d57b7945cf3de8e71461bd80695d50: fbdev: sh_mobile_lcdc: Don't confuse line size with pitch (2012-05-21 20:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git master for you to fetch changes up to c5389831cda3b38a56606a348a537a1332f2d729: sparc: Fix user_addr_max() definition. (2</pre> David Miller 2012-05-24T21:32:39 http://comments.gmane.org/gmane.linux.ports.sparc/16418 <pre>Dear friend 24/05/2012. I am Dr Raymond Chien Independent Non-executive Director of Hang Seng Bank Hong Kong I have a business transaction of $44.5 million USD to share with you,If interested contact me for more details via my personal email: draymndch8&lt; at &gt;yahoo.co.jp Full names:Address:Age:Occupation:Phone/Fax Regards: Date: 24/05/2012. Dr Raymond Chien Kuo Fung -- To unsubscribe from this list: send the line "unsubscribe sparclinux" 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> From Hang Seng Bank 2012-05-24T20:47:24 http://comments.gmane.org/gmane.linux.ports.sparc/16417 <pre> We need to use TASK_SIZE because for 64-bit tasks the value of STACK_TOP actually sits in the middle of the address space so we'll get false-negatives. Adjust the TASK_SIZE definition on sparc64 to accomodate this, in the context in which user_addr_max() is used we have the test_thread_flag() definition available but not the one for test_tsk_thread_flag(). Signed-off-by: David S. Miller &lt;davem&lt; at &gt;davemloft.net&gt; --- Some glibc testsuite failures for 64-bit showed me that STACK_TOP isn't the right thing to use here because of how we place the 64-bit process stack in the middle of the address space. Committed to master. arch/sparc/include/asm/processor_64.h | 4 +++- arch/sparc/include/asm/uaccess.h | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/sparc/include/asm/processor_64.h b/arch/sparc/include/asm/processor_64.h index e713db2..6ca7709 100644 --- a/arch/sparc/include/asm/processor_64.h +++ b/arch/sparc/include/asm/processor_64.h &lt; at &gt;&lt; at &gt; -42,7 +42,9 &lt; at &gt;&lt; at &gt; #define TASK_SIZ</pre> David Miller 2012-05-24T20:57:28 http://comments.gmane.org/gmane.linux.ports.sparc/16416 <pre> To use this, an architecture simply needs to: 1) Provide a user_addr_max() implementation via asm/uaccess.h 2) Add "select GENERIC_STRNCPY_FROM_USER" to their arch Kcnfig 3) Remove the existing strncpy_from_user() implementation and symbol exports their architecture had. Signed-off-by: David S. Miller &lt;davem&lt; at &gt;davemloft.net&gt; Acked-by: David Howells &lt;dhowells&lt; at &gt;redhat.com&gt; --- arch/sparc/Kconfig | 1 + arch/sparc/lib/usercopy.c | 144 -------------------------------------------- lib/Kconfig | 3 + lib/Makefile | 2 + lib/strncpy_from_user.c | 146 +++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 152 insertions(+), 144 deletions(-) create mode 100644 lib/strncpy_from_user.c diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index 051af37..2247423 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig &lt; at &gt;&lt; at &gt; -32,6 +32,7 &lt; at &gt;&lt; at &gt; config SPARC select HAVE_NMI_WATCHDOG if SPARC64 select HAVE_BPF_JIT select GENERIC_SMP_IDLE_THREAD +select GENERIC_</pre> David Miller 2012-05-24T20:26:31 http://comments.gmane.org/gmane.linux.ports.sparc/16414 <pre> Hide details of maximum user address calculation in a new asm/uaccess.h interface named user_addr_max(). Provide little-endian implementation in find_zero(), which should work but can probably be improved. Abstrace alignment check behind IS_UNALIGNED() macro. Kill double-semicolon, noticed by David Howells. Signed-off-by: David S. Miller &lt;davem&lt; at &gt;davemloft.net&gt; --- arch/sparc/include/asm/uaccess.h | 3 +++ arch/sparc/lib/usercopy.c | 32 +++++++++++++++++++++++++++----- 2 files changed, 30 insertions(+), 5 deletions(-) diff --git a/arch/sparc/include/asm/uaccess.h b/arch/sparc/include/asm/uaccess.h index 42a28cf..20c2acb 100644 --- a/arch/sparc/include/asm/uaccess.h +++ b/arch/sparc/include/asm/uaccess.h &lt; at &gt;&lt; at &gt; -6,6 +6,9 &lt; at &gt;&lt; at &gt; #include &lt;asm/uaccess_32.h&gt; #endif +#define user_addr_max() \ +(segment_eq(get_fs(), USER_DS) ? STACK_TOP : ~0UL) + extern long strncpy_from_user(char *dest, const char __user *src, long count); #endif diff --git a/arch/sparc/lib/usercopy.c b/arch/sparc/lib/usercopy.</pre> David Miller 2012-05-24T20:26:13 http://comments.gmane.org/gmane.linux.ports.sparc/16413 <pre> Ok, this integrates all the feedback I received and I pushed it out to my Sparc GIT tree. I'll ask Linus to pull this stuff in shortly. Thanks everyone. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" 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-24T20:26:04 http://comments.gmane.org/gmane.linux.ports.sparc/16412 <pre>Hi, I gave today's sparc.git a try on a SS20 with SuperSparc-II and another one with HyperSparc CPUs. Starting with an UP kernel, I got some bugs on the SuperSparc and a segfault on the HyperSparc, see below for bootlogs. I can test patches etc. If more info is required, please let me know. Thanks, M === HyperSparc === SPARCstation 20 MP (4 X RT625), No Keyboard ROM Rev. 2.25R hyperSPARC, 448 MB memory installed, Serial #8491359. Ethernet address 8:0:20:81:91:5f, Host ID: 7281915f. Timeout waiting for ARP/RARP packet 349c00 PROMLIB: obio_ranges 5 PROMLIB: Sun Boot Prom Version 3 Revision 2 Linux version 3.4.0-02583-g4efcac3 (builder&lt; at &gt;jalapeno) (gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) #2 Thu May 24 18:44:32 CEST 2012 bootconsole [earlyprom0] enabled ARCH: SUN4M TYPE: Sun4m SparcStation10/20 Ethernet address: 08:00:20:81:91:5f SRMMU: Using VAC size of 262144 bytes, line size 64 bytes. 255MB HIGHMEM available. OF stdout device is: /obio/zs&lt; at &gt;0,100000:a PROM: Built device tree with 30178 bytes of</pre> Marcel van Nies 2012-05-24T19:27:31 http://comments.gmane.org/gmane.linux.ports.sparc/16411 <pre> Compute a mask that will only have 0x80 in the bytes which had a zero in them. The formula is: ~(((x &amp; 0x7f7f7f7f) + 0x7f7f7f7f) | x | 0x7f7f7f7f) In the inner word iteration, we have to compute the "x | 0x7f7f7f7f" part, so we can reuse that in the above calculation. Once we have this mask, we perform divide and conquer to find the highest 0x80 location. Signed-off-by: David S. Miller &lt;davem&lt; at &gt;davemloft.net&gt; --- On linux-arch we're talking about making this code I wrote for sparc suitable for other platforms to use since it's reasonably portable already. As part of that Linus wanted me to make an effort to improve the code GCC generates for the final zero byte discovery code and this is what I came up with. arch/sparc/lib/usercopy.c | 50 +++++++++++++++++++-------------------------- 1 file changed, 21 insertions(+), 29 deletions(-) diff --git a/arch/sparc/lib/usercopy.c b/arch/sparc/lib/usercopy.c index 851cb75..87f9645 100644 --- a/arch/sparc/lib/usercopy.c +++ b/arch/sparc/lib/usercopy.c &lt; at &gt;&lt; at &gt; -</pre> David Miller 2012-05-24T02:29:31 http://comments.gmane.org/gmane.linux.ports.sparc/16406 <pre> Linus removed the end-of-address-space hackery from fs/namei.c:do_getname() so we really have to validate these edge conditions and cannot cheat any more (as x86 used to as well). Move to a common C implementation like x86 did. And if both src and dst are sufficiently aligned we'll do word at a time copies and checks as well. Signed-off-by: David S. Miller &lt;davem&lt; at &gt;davemloft.net&gt; --- This addresses: http://marc.info/?l=linux-arch&amp;m=133761921425977&amp;w=2 arch/sparc/include/asm/uaccess.h | 3 + arch/sparc/include/asm/uaccess_32.h | 10 --- arch/sparc/include/asm/uaccess_64.h | 4 - arch/sparc/lib/Makefile | 2 +- arch/sparc/lib/ksyms.c | 3 - arch/sparc/lib/strncpy_from_user_32.S | 47 ------------ arch/sparc/lib/strncpy_from_user_64.S | 133 --------------------------------- arch/sparc/lib/usercopy.c | 132 ++++++++++++++++++++++++++++++++ 8 files changed, 136 insertions(+), 198 deletions(-) delete mode 100644 arch/sparc/lib/strncpy_from</pre> David Miller 2012-05-23T07:35:50 http://comments.gmane.org/gmane.linux.ports.sparc/16394 <pre>I wanted feedback on the changes in head_32.S and decided to send out what I considered ready for now. This set does not yet include the run-time patching as discussed the other day. I decided to postpone this until next batch as I have not prepared any users of it yet. But again - main point here is feedback on the head_32.S changes as I do not feel too familiar with SPARC assembler just yet. At least it boots on my ss5 box :-) I am btw. utterly confused by the handling of secondary cpus for leon. For some reason there is a direct call to leon_smp_cpu_startup: in trampoline_32.S. But sun4m does not need such a trick. Sam Sam Ravnborg (5): sparc32: whitespace cleanup in head_32.S sparc32: implement proper LEON support in head_32 (before highmem) sparc32: implement proper LEON support in head_32 (after highmem) sparc32: handle leon in cpu.c sparc32: handle leon in irq_32.c arch/sparc/include/asm/psr.h | 6 +++ arch/sparc/kernel/cpu.c | 18 ++++---- arch/sparc/</pre> Sam Ravnborg 2012-05-22T20:06:37 http://comments.gmane.org/gmane.linux.ports.sparc/16389 <pre>From 52d8a6d1b81a19e693a09df90275600f44293f43 Mon Sep 17 00:00:00 2001 From: Sam Ravnborg &lt;sam&lt; at &gt;ravnborg.org&gt; Date: Tue, 22 May 2012 16:39:00 +0200 Subject: [PATCH] sparc32: use the common implementation of alloc_thread_info_node() With sun4c removed we can fall-back to the common implementation. Signed-off-by: Sam Ravnborg &lt;sam&lt; at &gt;ravnborg.org&gt; Cc: Thomas Gleixner &lt;tglx&lt; at &gt;linutronix.de&gt; --- This is not a "real" bug but I would like it applied anyway. Thomas Gleixner &lt;tglx&lt; at &gt;linutronix.de&gt; consolidated all alloc_thread_info_node() implmentations but sparc32 was left out due to sun4c weirdness. With sun4c gone we can align with the rest of the world. (and I promised Thomas to follow-up on this when his patch-set was merged). This patch is on top of: bf67f3a5c456a18f2e8d062f7e88506ef2cd9837 ("Merge branch 'smp-hotplug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip") Sam arch/sparc/Kconfig | 1 - arch/sparc/include/asm/thread_info_32.h | 11 ++--------- arch/sparc</pre> Sam Ravnborg 2012-05-22T15:11:23 http://comments.gmane.org/gmane.linux.ports.sparc/16383 <pre> Linus has pulled in all of the sparc-next changes into his tree. I have therefore fast-forwarded both 'sparc' and 'sparc-next' to the head of his tree. 'sparc-next' is now frozen and no developer should occur against it until it is reopenned some time after the merge window is over. All changes should be bug fixes and made against the 'sparc' tree. I am going to allow Sam to finish his de-LEON'ization work and will merge it in via the 'sparc' tree, because these changes will significantly increase the maintainability of the tree. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" 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-21T21:15:20 http://comments.gmane.org/gmane.linux.ports.sparc/16373 <pre>Who is the relevant Gaisler contact person these days for Linux stuff? I sometimes uses Daniel, sometimes Konrad. I can just add both of you - this is no problem. As I plan to update the LEON integration it would be good to have in place. Anyway - the real question.. In head_32.S I need very early on to determine the CPU type, so I can distingush between LEON and SUN. This is due to LEON using a different ASI for mmuregs as discussed in another mail. I assume this can be determinded from PSR. If this is correct - then what values shall I use to determine if the relevant cpu is LEON or SUN? Sam -- To unsubscribe from this list: send the line "unsubscribe sparclinux" 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> Sam Ravnborg 2012-05-21T16:22:53 http://comments.gmane.org/gmane.linux.ports.sparc/16371 <pre>Hello Dave, I am trying to catch up on what has been happening lately with the sparc port. Have the latest patches removed support for SPARC V7 CPUs? The LEON VHDL model supports both V7 and V8 CPUs, FPU and non-FPU in any combination. Daniel -- To unsubscribe from this list: send the line "unsubscribe sparclinux" 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> Daniel Hellstrom 2012-05-21T14:14:20 http://comments.gmane.org/gmane.linux.ports.sparc/16370 <pre> 1) Kill off support for sun4c and Cypress sun4m chips. And as a result we were able to also kill off that ugly btfixup thing that required multi-stage links of the final vmlinux image in the Kbuild system. This should make the kbuild maintainers really happy. Thanks a lot to Sam Ravnborg for his tireless efforts to get this going. 2) Convert sparc64 to nobootmem. I suspect now with sparc32 being a lot cleaner, it should be able to fall in line and modernize in this area too. 3) Make sparc32 use generic clockevents, from Tkhai Kirill. There is going to be a merge conflict between the commit in the net-next tree that adds the Sparc BPF JIT, and the one in here which adds arch/sparc/Kbuild. It should be quite easy to resolve. Please pull, thanks a lot! The following changes since commit 82b769063598d01a8b24abf250a53f8b437e09f1: Merge branch 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile (2012-04-26 15:36:27 -0700) are available in the git rep</pre> David Miller 2012-05-21T09:03:00 http://comments.gmane.org/gmane.linux.ports.sparc/16357 <pre> Hello Sales I went over your contact online and found some items which we have interest in purchasing to our store in Spain for urgent supply. I will like to know the prices per each items plus the shipping cost. I also want to know if Letter of Credit or T/T is acceptable for payment. I await your quick response asap so i can proceed with my needed items and quantity. Thank you mcckoy robertson N.B.M Global Supply Inc Address: Autovía A-5, salidas 22 y 26. Arroyomolinos, 28939 Madrid Spain Tel: +34 902 26 77 26 Email: nbmglobalsupply&lt; at &gt;gmail.com Website : http://www.brplastics.com -- To unsubscribe from this list: send the line "unsubscribe sparclinux" 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> Mcckoy Robertson 2012-05-20T16:04:04 http://comments.gmane.org/gmane.linux.ports.sparc/16356 <pre>I have not tested any sparc32 configs since Debian dropped sparc32. However, I do have some hardware that I'd like to put to good use for testing the sparc32 changes (SS10 SP, SS10 MP, SS10 4x100 Ross, SS20 (maybe SMP too), SS5 70 MHz stock CPU, SS5 with 170 MHz Fujitsu(?) CPU), SS4, probably some lunchboxes too if I find some big enough working HDD-s (LX, CLassic), ADEE S10Station (SS10 clone). That leads to the question, what is the best userland to compile and run sparc32 kernels? This probably means recent gcc &amp; binutils, and that they are routinely updated. I can ocassionally compile a binutils or a gcc if it has been automated by someone else (like in gentoo), or better use binary packages and update these. And I want to compile the kernels on these machines themselves (as all my tect machines do), to have better testing. So, what distros do people suggest? </pre> Meelis Roos 2012-05-20T16:07:03 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.ports.sparc