similar to: Fwd: rsync seem to be broken on sparc64

Displaying 20 results from an estimated 1400 matches similar to: "Fwd: rsync seem to be broken on sparc64"

2016 Jun 28
0
Fwd: rsync seem to be broken on sparc64
I know almost nothing about modern SPARC64 systems especially when they are running linux. But, can you try this command line and see if it gives more information before it blows up: rsync -vvai /export/test/ /export/test2/ On 06/28/2016 05:39 PM, alexmcwhirter at triadic.us wrote: > -------- Original Message -------- > Subject: rsync seem to be broken on sparc64 > Date: 2016-06-27
2007 Jun 21
3
[LLVMdev] Accounting for stack space
On Wed, 20 Jun 2007, Sandro Magi wrote: > To this end, are there any implicit allocations being done by > generated LLVM code, other than the system stack? heap allocations? Only malloc/free. Note that the compiler does generate calls to runtime libraries (e.g. libstdc++ and libgcc), we don't have control over when they do allocations. The libstdc++ calls show up in the .ll file,
2007 Jul 10
2
[LLVMdev] Accounting for stack space
On Sun, 8 Jul 2007, Sandro Magi wrote: > How about if I were to use LLVM's JIT? I suspect plenty of allocations > are performed in the JIT. The JIT does a ton of heap allocation. There is no way to approximate it from the code you give it. -Chris > Sandro > > On 6/20/07, Chris Lattner <sabre at nondot.org> wrote: >> On Wed, 20 Jun 2007, Sandro Magi wrote:
2008 Jul 29
1
[releng_7 tinderbox] failure on sparc64/sparc64
TB --- 2008-07-29 09:37:14 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-07-29 09:37:14 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2008-07-29 09:37:14 - cleaning the object tree TB --- 2008-07-29 09:37:32 - cvsupping the source tree TB --- 2008-07-29 09:37:32 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB ---
2013 Nov 20
1
[releng_10 tinderbox] failure on sparc64/sparc64
TB --- 2013-11-19 23:00:41 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-11-19 23:00:41 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-19 23:00:41 - starting RELENG_10 tinderbox run for sparc64/sparc64 TB --- 2013-11-19 23:00:41 - cleaning the
2009 Aug 20
5
help with regular expressions in R
I'm having trouble achieving the results I want using a regular expression. I want to eliminate all characters that fall within square brackets as well as the brackets themselves, returning an "". I'm not sure if it's R's use of double slash escapes or something else that is tripping me up. If I only use one slash I get 1: '\[' is an unrecognized escape in a
2008 Jun 03
0
[releng_6 tinderbox] failure on sparc64/sparc64
TB --- 2008-06-03 09:06:24 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-06-03 09:06:24 - starting RELENG_6 tinderbox run for sparc64/sparc64 TB --- 2008-06-03 09:06:24 - cleaning the object tree TB --- 2008-06-03 09:06:55 - cvsupping the source tree TB --- 2008-06-03 09:06:55 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/sparc64/sparc64/supfile TB ---
2010 Apr 26
2
[LLVMdev] llvm for freebsd on sparc64
I am trying to build llvm on freebsd-8.0 on sparc64 CPU. I patched sources because 'sparc' enum value in include/llvm/ADT/Triple.h conflicts with gcc typedef 'sparc'. This allowed llvm itself to build successfully. But there is an error during gcc frontend compile: Did not get a target machine! Triplet is sparc64-unknown-freebsd8.0 I think this is because in many places, like in
2012 Apr 08
0
[releng_9 tinderbox] failure on sparc64/sparc64
TB --- 2012-04-08 08:26:29 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-04-08 08:26:29 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-04-08 08:26:29 - starting RELENG_9 tinderbox run for sparc64/sparc64 TB --- 2012-04-08 08:26:29 - cleaning the
2007 Jun 18
2
[LLVMdev] Arbitrary bit width integers
Ok, so if I needed very precise control over the allocation of memory, then I should avoid using integers with bit widths larger than 64 bits (or perhaps 128)? Is there a hard rule for an integer being stack allocated, ie. one that doesn't depend on the current implementation details? Sandro On 6/18/07, Reid Spencer <rspencer at reidspencer.com> wrote: > Sandro Magi wrote: > >
2007 Jun 18
4
[LLVMdev] Arbitrary bit width integers
Where does the storage for large bit width integers come from? Are very large numbers heap allocated? Sandro
2018 Feb 22
0
Auth SEGV on sparc64, alignment problem?
On Tue, Feb 20, 2018 at 19:08:27 -0500, Chris Ross wrote: > > Apologies first for using two addresses, but I can?t currently read my email at distal.com. :-) > > I was previously running dovecot2-2.2.29.1_2 on FreeBSD 11 on sparc64. > Trying to debug a problem I was having with one of my clients, I > upgraded to dovecot-2.2.33.2_4 on that same server. However, I
2005 Dec 28
0
[patch] sparc64 fix stat()
From: Jurij Smakov <jurij@wooyd.org> I've investigated the sparc stat() klibc problem a bit and found that the definition of 'struct stat' in klibc's include/arch/sparc64/archstat.h is (most probably) incorrect. I've written a simple test case using stat() function and then looked at preprocessed source, which includes the 'struct stat' definition (from glibc
2010 Apr 26
0
[LLVMdev] llvm for freebsd on sparc64
We typically handle this by adding a "#undef sparc" in various places. For example see include/llvm/ADT/Triple.h which already has it. You'll probably need to add it to another header somewhere. -Chris On Apr 26, 2010, at 10:59 AM, Yuri wrote: > I am trying to build llvm on freebsd-8.0 on sparc64 CPU. > I patched sources because 'sparc' enum value in >
2018 Feb 21
0
Auth SEGV on sparc64, alignment problem?
Your core dump looks a bit broken. Since it seems to die instantly, can you try gdb /path/to/auth and just run it? Aki On 21.02.2018 02:08, Chris Ross wrote: > Apologies first for using two addresses, but I can?t currently read my email at distal.com. :-) > > I was previously running dovecot2-2.2.29.1_2 on FreeBSD 11 on sparc64. Trying to debug a problem I was having with one of
2003 Feb 03
0
[Bug 41] New: pptp-conntrack-nat and sparc64 structures/padding/maskcomp bug
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=41 Summary: pptp-conntrack-nat and sparc64 structures/padding/maskcomp bug Product: netfilter/iptables Version: patch-o-matic Platform: sparc64 OS/Version: All Status: NEW Severity: normal Priority: P2 Component: connection
2004 Jul 31
3
Asterisk on Sparc64
Ming-Wei Shih wrote (Re: [Asterisk-Users] Best Linux for Asterisk) > I am running * CVS head on Gentoo/i586 > and Gentoo/Sparc64 (US60 2x450/1GB RAM), > they are running great. > > On sparc64 * does not compile out-of-the-box, > some hackings in the Makefiles are needed. Great stuff. Please, can you share your adjustments to the Makefiles with the community?! If you don't
2007 Jun 18
2
[LLVMdev] Accounting for stack space
Given my recent posts, I think it's obvious that I'm trying to figure out how to build a resource-aware VM for a high-level language. I've figured out adequate solutions for most of the problems I've encountered, including separate heaps, quotas, etc. However, I'm not sure how I can account for a thread's stack space. Given a language process (LP) running in a heap with a
2007 Dec 02
3
ipp2p: Unaligned access in search_all_ed2k on sparc64
Hey guys, I''ve just built a sparc64 (Ultra/5) based firewall with ipp2p compiled as a module and I''m constantly getting the following message in my logs: Kernel unaligned access at TPC[100f8490] search_all_edk+0x20/0x4c [ipt_ipp2p] I''m running the following versions: - Kernel 2.6.22 - ipp2p 0.8.2-r4 - iptables 1.3.8-r1 Any thoughts?
2006 Jun 26
0
[klibc 16/43] sparc64: transmit arch-specific options to kinit via /arch.cmd
Sparc64 has support for a bunch of architecture-specific options taken from the PROM. Convert them to kernel command line form and write the file /arch.cmd in the rootfs, which can be recovered by kinit and processed. The kinit support has already been committed. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit c6e5c5a77681f5bf6f9fea55d031115e9f58ada6 tree