Memory alignment of pointers for sparc64
Hi, I was trying to build the C application swish-e on the Sourceforge Sun Ultra60 - Debian 3.0. Swish-e allocates memory from a memory pool. The application byte-aligns the allocated pointers based on the sizeof(void *). (Actually the original programmer used sizeof(long) ). So on 4 byte machines you would get pointers that end in 0, 4, 8, and C hex. On DEC alpha sizeof(void *) == 8 so the pointers low byte is 0 and 8. Now the problem is that on sparc64 sizeof(void *) == 4 but we need to align our pointers on 8-byte boundaries otherwise we get SIGBUS errors. So, can anyone suggest a way in C to test for this? Something like #if defined(__sparc64__) # define PointerAlign 8 #else # define PointerAlign sizeof( void * ) #endif My C skills are not great, and I know much less about porting. So it would be great to find a reasonably potable way to set the align size -- any suggestions are more than welcome. Thanks. -- Bill Moseley mailto:[EMAIL PROTECTED]
RE: Woody download using jigdo question
Thank you very much.. Rich -Original Message- From: Mike Renfro [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 04, 2002 7:03 PM To: Sharpe, Richard Cc: debian-sparc@lists.debian.org Subject: Re: Woody download using jigdo question On Wed, Sep 04, 2002 at 04:07:26PM -0400, Sharpe, Richard wrote: I have take all your advice and decided to try Debian for Sparc, I download the 6 sprc jigdo files and then I get stuck what do you enter in this prompt: Here's what I use to generate CDs nightly (with a local sparc mirror, you probably want to use apt-spy to find a nearby mirror if you don't have your own). The following snippets would generate woody-sparc-1: #!/bin/sh cd /some/local/directory/for/jigdo/files wget --mirror --no-parent -q --no-directories -Awoody*-1* \ http://us.cdimage.debian.org/jigdo-area/current/jigdo/sparc/ /usr/bin/jigdo-mirror and in ~/.jigdo-mirror: jigdoDir=/some/local/directory/for/jigdo/files imageDir=/some/local/directory/for/cd/images tmpDir=/some/local/directory/for/jigdo/tmp debianMirror=file:/home/ftp/debian nonusMirror=file:/home/ftp/debian/non-US exclude='_NONUS' jigdoFile=jigdo-file --cache=$tmpDir/jigdo-cache.db --cache-expiry=1w --report=noprogress --no-check-files maxMissing=100 filesPerFetch=10 wgetOpts=--passive-ftp --no-directories --non-verbose ...where all the directories mentioned are on the same partition. -- Mike Renfro / RD Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Memory alignment of pointers for sparc64
On Wed, Sep 04, 2002 at 11:06:04PM -0700, Bill Moseley wrote: Hi, I was trying to build the C application swish-e on the Sourceforge Sun Ultra60 - Debian 3.0. Swish-e allocates memory from a memory pool. The application byte-aligns the allocated pointers based on the sizeof(void *). (Actually the original programmer used sizeof(long) ). So on 4 byte machines you would get pointers that end in 0, 4, 8, and C hex. On DEC alpha sizeof(void *) == 8 so the pointers low byte is 0 and 8. Now the problem is that on sparc64 sizeof(void *) == 4 but we need to align our pointers on 8-byte boundaries otherwise we get SIGBUS errors. I'm pretty sure you mean sparc and not sparc64 (even if you are running an ultra, it is still 32bit userspace). On sparc64, sizeof(void *) does in fact equal 8bytes (64bit bins). Why not force minimum 8byte allocations? Will it really cause that much of a usage problem? Would probably cause less fragmentation, I bet. Guess you could do: #ifdef __sparc__ # define PointerAlign 8 #else # define PointerAlign sizeof(void *) #endif What was wrong with the original usage of sizeof(long)? -- Debian - http://www.debian.org/ Linux 1394 - http://linux1394.sourceforge.net/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: Memory alignment of pointers for sparc64
At 09:17 AM 09/05/02 -0400, Michael J. Saletnik wrote: On September 4, 2002 at 23:06, Bill Moseley wrote: the allocated pointers based on the sizeof(void *). On September 5, 2002 at 08:13, Ben Collins wrote: What was wrong with the original usage of sizeof(long)? Wouldn't it be most correct to use sizeof(caddr_t) ? I'm not familiar with caddr_t. (And I don't really have a grasp of what the underlying issue is regarding memory alignment.) Still, caddr_t == 4 on this machine (where I need 8), so it can't be used in all cases. Thanks, -- Bill Moseley mailto:[EMAIL PROTECTED]
Re: Memory alignment of pointers for sparc64
On Thu, 5 Sep 2002, Bill Moseley wrote: About all I understand of this problem is that our code allocates memory on 4-byte boundaries, and that cased SIGBUS on this one machine. I printed out the results of malloc() calls and noticed it was always on 8-byte boundaries. Hard-coding to 8-byte fixed our code. AFAIK on 32 bit SPARC, like you are using (and on other platforms, like MIPS, etc) you often need to align structures on 8 bytes for floating point members. doubles have to be aligned on their size generally. If your structures contains only things = 32 bits then you can get away with a 4 byte alignment in general, but if you add a double or a long long then some arches will demand 8 bytes. The basic rule is that the member of a structure has to be aligned on it's size - so a 2 byte short needs to have an addresss congruent to 2, a 4 byte long needs to be congruent to 4, a double to 8. Generally an allocator of this nature should align to the largest intrinsic type used in the structures it is allocating for. If that's a double or a uint64_t then it has to be 8 bytes. Jason
CDMA手机980元送1300元话费 市话通500元送400话费 详情请电26871524
CDMA手机980元送1300元话费 市话通500元送400话费 详情请电26871524
Re: Memory alignment of pointers for sparc64
On Thu, 5 Sep 2002, Bill Moseley wrote: Here's where it's blowing up: struct dev_ino *p; struct stat buf; ... // allocate a bit of memory from the pool. p = (struct dev_ino *) Mem_ZoneAlloc( sw-Index-entryZone,sizeof(struct dev_ino)); p-dev = buf.st_dev; // *poof!* SIGBUS SIGBUS when the address ends in 4 or C but OK when it ends in 0 or 8. Hum, that seems a bit surprising, what does your 'struct dev_ino' look like? Jason
Re: Memory alignment of pointers for sparc64
At 02:16 PM 09/05/02 -0600, Jason Gunthorpe wrote:
On Thu, 5 Sep 2002, Bill Moseley wrote:
Here's where it's blowing up:
struct dev_ino *p;
struct stat buf;
...
// allocate a bit of memory from the pool.
p = (struct dev_ino *) Mem_ZoneAlloc(
sw-Index-entryZone,sizeof(struct dev_ino));
p-dev = buf.st_dev; // *poof!* SIGBUS
SIGBUS when the address ends in 4 or C but OK when it ends in 0 or 8.
Hum, that seems a bit surprising, what does your 'struct dev_ino' look
like?
struct dev_ino
{
dev_t dev;
ino_t ino;
struct dev_ino *next;
};
And now I see another SIGBUS with this code:
Program received signal SIGBUS, Bus error.
0x0001ae60 in coalesce_word_locations (sw=0xdbdf0, indexf=0xf46e8,
e=0x7037dd50) at index.c:2691
2691*(unsigned int *)size_p = tmp;
And if I print out the address:
tmp is an unsigned int.
size_p at: 9BB5D
Bus error.
My guess is that's another alignment error.
That bit of code is used to compress our data in RAM.
Thanks,
--
Bill Moseley
mailto:[EMAIL PROTECTED]
NCPFS, anyone?
Has anyone gotten NCPFS mounts to work in Woody? Actually, I have but only on my old '386 box. However, on the Sparc, I get this: # ncpmount -S server -U rcb -A server /mnt Logging into SERVER as RCB Password: ncpmount: Invalid argument in mount(2) A 'dmesg' command shows the following: ncp_read_super: kernel requires mount version 3 I do have 'ncpfs' compiled into the kernel as a module. The really bizarre thing about this is that the 'mount' version appears to be the same (2.11) on both the old '386 box and the new Sparc. Ideas? Thanks, -- Roy Bixler [EMAIL PROTECTED]
xfree86: sunffb fails with signal 10
Greetings All, I'm a long time linux user, just beginning to use it on sparcs because it's so much easier to make a GNU system into a useable workstation than it is with Solaris... The machine I'm having trouble with is an Ultra 2 with a Creator card. I know the hardware works because I was running Solaris 8 on it last week and Sun's X server worked just fine. My config file and Xserver output are included below. As you can see, the server isn't reporting any useful errors, it just dies on signal 10. Unfortunately it doesn't even drop a core file. :-( TIA for any help --john Here's my config file: ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the ### BEGIN DEBCONF SECTION line above, and/or after the # ### END DEBCONF SECTION line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. Also see How do I add custom sections to a dexconf-generated # XF86Config or XF86Config-4 file? in /usr/share/doc/xfree86-common/FAQ.gz. Section Files FontPathunix/:7100# local font server # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi/:unscaled FontPath/usr/lib/X11/fonts/75dpi/:unscaled FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module LoadGLcore Loadbitmap Loaddbe Loadextmod Loadfreetype Loadglx Loadpex5 Loadrecord Loadspeedo Loadtype1 Loadxie EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules sun Option XkbModel type5 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/sunmouse Option Protocol BusMouse EndSection Section InputDevice Identifier Generic Mouse Driver mouse Option SendCoreEventstrue Option Device/dev/input/mice Option Protocol ImPS/2 EndSection Section Device Identifier Generic Video Card Driver sunffb Option UseFBDev true EndSection Section Monitor Identifier Generic Monitor HorizSync 70-90 VertRefresh 76-76 Option DPMS EndSection Section Screen Identifier Default Screen Device Generic Video Card Monitor Generic Monitor DefaultDepth24 SubSection Display Depth 1 Modes 1280x1024 EndSubSection SubSection Display Depth 4 Modes 1280x1024 EndSubSection SubSection Display Depth 8 Modes 1280x1024 EndSubSection SubSection Display Depth 15 Modes 1280x1024 EndSubSection SubSection Display Depth 16 Modes 1280x1024 EndSubSection SubSection Display Depth 24 Modes 1280x1024 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse InputDevice Generic Mouse EndSection Section DRI Mode0666 EndSection ### END DEBCONF SECTION And Here's the server output: This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to [EMAIL PROTECTED] Before reporting
Re: Memory alignment of pointers for sparc64
If I understand correctly, how about `__alignof__', utilizing GCC's
knowledge of the architecture?
$ cat a.c
#include stdio.h
#ifdef __GNUC__
size_t alignment = __alignof__ (double);
#else
size_t alignment = 8;
#endif
main () { printf (%d\n, alignment); exit (0); }
$ arch cc a.c ./a.out
i586
4
---
$ arch cc a.c ./a.out
sparc64
8
Re: NCPFS, anyone?
On Thu, Sep 05, 2002 at 05:53:26PM -0500, Roy Bixler wrote: Has anyone gotten NCPFS mounts to work in Woody? Actually, I have but only on my old '386 box. However, on the Sparc, I get this: # ncpmount -S server -U rcb -A server /mnt Logging into SERVER as RCB Password: ncpmount: Invalid argument in mount(2) A 'dmesg' command shows the following: ncp_read_super: kernel requires mount version 3 I do have 'ncpfs' compiled into the kernel as a module. The really bizarre thing about this is that the 'mount' version appears to be the same (2.11) on both the old '386 box and the new Sparc. Ideas? I should have also noted that I am using a stock 2.4.19 kernel. TIA, R.
Re: xfree86: sunffb fails with signal 10
On Thu, Sep 05, 2002 at 04:21:26PM -0700, John Riccardi wrote: Greetings All, I'm a long time linux user, just beginning to use it on sparcs because it's so much easier to make a GNU system into a useable workstation than it is with Solaris... The machine I'm having trouble with is an Ultra 2 with a Creator card. I know the hardware works because I was running Solaris 8 on it last week and Sun's X server worked just fine. My config file and Xserver output are included below. As you can see, the server isn't reporting any useful errors, it just dies on signal 10. Unfortunately it doesn't even drop a core file. :-( Can you send your /var/log/XFree86.log aswell? -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
