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
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: apt slink-potato using cds (long post)
On Thu, 9 Nov 2000, Brenda J. Butler wrote: Debian GNU/Linux 2.2 0a Potato - Official sparc Binary-2 (2818) while the apt-get program asks for Debian GNU/Linux 2.2 0a _Potato_ - Official sparc Binary-2 (2818) Err I fixed a bug with that at one point - I didn't think anyone mod disks like that :| The ,s should be underscores IIRC in cdroms.list Jason
Re: glibc 2.2 and gcc (Was Re: something completely different)
On 3 Aug 2000, Miquel van Smoorenburg wrote: Can't you simply add a dummy package called lib6.1 that Depends: or probably even Predepends: on libc6. It will take a few releases before you can get rid of it but it would get the Alpha back in line with the other archs. And there's not ever going to be a real libc6.1 anyway. Well, you can change the package name, but you must not change the soname or you are going to break binary comaptiblity with every other alpha dist out there. Our policy does say that the soname should be in the package name which means this scheme is somewhat against policy too.. Jason
RE: Swap space question
On Tue, 2 May 2000, Michael Anthon wrote: I am pretty sure that the original interpretation of this rule was more along the lines of determine how much memory you will need to run everything you need to run, then make sure that at least 1/3 of that is physical RAM. Actually, apparently, long ago, the amount of swap you had directly equaled the amount of VM you had. RAM was just a cache for your swap. So if you had alot of ram you needed at least that much swap behind it. From there it is pretty reasonable to go for double that, back in that era. Jason
auric..
Auric is properly up now, if any of you sparc users would care to run some compiles on it I'm sure it would enjoy having something to do : /scratch has space for such things. Thanks, Jason
Re: sparc binaries/disks missing?
On Mon, 24 Jan 2000, Glen S Mehn wrote: But no one can explain to me why the sparc distro seems to have dissappeared from ftp.us.debian.org. I imagine the ftp.us mirror has choosen to no longer mirror the whole distribution. Maybe we should re-shuffle the TLD assignments :| Jason
Re: problems with apt-get upgrading from slink to potato
On Fri, 21 Jan 2000, Ari Heitner wrote: $ ps aux USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND ... root 825 3.2 22.8 4856 3228 1 S18:30 0:57 apt-get dist-upgrade root 826 98.2 22.8 4856 3228 1 R18:32 27:41 apt-get dist-upgrade ... Uh, why do you have two of them running? APT is not multithreaded, it only forks when it is going to exec something. Strace it and see what is going wrong. Jason
Re: problems with apt-get upgrading from slink to potato
On Fri, 21 Jan 2000, Ari Heitner wrote: The strace crashed pretty quick, but apt seems to be using pthreads: Ah.. you have the old APT linked to pthreads. Upgrade these things: 1) Kernel 2) libc6 3) pthread 4) apt 5) strace Jason
GCC 2.95.2-1.2 busted?
Hi,
I just installed gcc 2.95.2-1.2 on kubrick.d.o and it seems *really*
busted:
kubrick{jgg}~/apt/apt-pkg#make
Compiling acquire-worker.cc to
../build-sparc/obj/apt-pkg/acquire-worker.opic
*Initialization*:1: warning: `__SIZE_TYPE__' redefined
*Initialization*:1: warning: `__PTRDIFF_TYPE__' redefined
In file included from acquire-worker.cc:18:
../build-sparc/include/apt-pkg/acquire-worker.h: In method `const struct
pkgAcquire::MethodConfig * pkgAcquire::Worker::GetConf() const':
../build-sparc/include/apt-pkg/acquire-worker.h:82: Internal compiler
error in `push_decl_scope', at dwarf2out.c:7719
Please submit a full bug report.
See URL:http://www.gnu.org/software/gcc/faq.html#bugreport for
instructions.
make: *** [../build-sparc/obj/apt-pkg/acquire-worker.opic] Error 1
The first two lines are printed for every compilation unit and the ICE is
unique that that module.
Whats up?
Jason
Re: GCC 2.95.2-1.2 busted?
On Mon, 15 Nov 1999, Jason Gunthorpe wrote:
kubrick{jgg}~/apt/apt-pkg#make
Compiling acquire-worker.cc to
../build-sparc/obj/apt-pkg/acquire-worker.opic
*Initialization*:1: warning: `__SIZE_TYPE__' redefined
*Initialization*:1: warning: `__PTRDIFF_TYPE__' redefined
This bit is due to cpp being out of date! gcc on sparc needs to depend on
cpp = 2.95.2-1.2
Jason
Re: Upgrading gcc in unstable
On Mon, 25 Oct 1999, James Moody wrote: For over a month now, the gcc package has appeared in my apt-get upgrade even though there is no new version available. This is quite strange. The gcc version is 2.95.2-0pre1. The only thing I can figure is that this is a bug in apt due to a colon in the filename, but that could be completely incorrect. All other packages behave correctly. It is a bug in APT and a bug in egcs, fix either : CVS apt has this corrected.. http://va.debian.org/~jgg/apt_0.3.13.1_sparc.deb Jason
Re: Pthread brokenness
On 5 Sep 1999, Mark W. Eichin wrote: hmm, I updated a months-old unstable sparc SS1+, and now sshd spins, apt-get spins sometimes (rolling back to slink apt-get helped some, but not enough; for now, I just run it under (limit cputime 2min) so it dies and I run it again :-) The latest sparc APT 0.3.12 should not use pthreads and advoid this little problem.. Nobody quite knows what it is, only happens on some kind of sparcs. Jason
Re: apt-cache hang! on IPX
On Mon, 30 Aug 1999, Chanop Silpa-Anan wrote: I'm running slink on IPX. I just upgrade apt to apt in slink-proposed-updates. After that apt acts weird. apt-cache will stay forever. I've read some discussion about apt on IPC weeks ago. But here apt-get ?? work fine except upgrade which I think it call apt-cache. Get APT 0.3.11.1 compiled for sparc at http://www.debian.org/~jgg - it should fix these problems. Jason
Re: apt-cache hang! on IPX
On Mon, 30 Aug 1999, Ben Collins wrote: This is a known issue with apt-cache on sun4c systems. The apt author has compiled a version without pthreads and it seems to have fixed the problem. I might just make an NMU for this so we can resolve this problem until a permanent fix is produced (which is a pthread problem). All future APT versions will be compiled without pthreads for the forseeable future. At least untill someone fixes this rather serious flaw. Jason
Re: size of Packages in main/binary-spac = 0
On Thu, 12 Aug 1999, Chanop Silpa-Anan wrote: Interestingly, the files Packages date is July 11. The duplicate files mechanism hardlinked the 0 length file to another zero length file, so the date is set randomly. Jason
Faure, Kubrick and Albert
VA has sent us a pair of 9G SCSI disks that they no longer needed and one has been installed into faure by Mark and Adam at Novare to replace the previously failed disk. The other is slated to go into Kubrick in a little while. All three machines are properly running again with another 6G more disk space! The content of the old home directory disk has however been lost. All the passwords are set to the passwords on master. Home dirs on the cluster are created automatically on login, but only faure does this right now. Jason Debian Admin
Pthread brokenness
Hi all, I have finally tracked the mysterious freezes in apt-get on certain non-intel platforms to some bizzar bug in libpthread. When APT is linked to the pthread library it will get stuck in pthread functions doing nice infinite loops on some specific hardware platforms. Several people have reported this on sparc IPCs and one has reported it on a Mac m68k. I don't have much details about the exact configurations of the machines. Removing pthreads immediately cures all problems and APT works as it should on these specific bits of hardware. This is odd because the apt-get program doesn't actually use pthreads - pthread capability is in libapt-pkg for use by one of the experimental GUIs. My initial guess is that something about the specific CPU type is confusing pthread. Pthread relies on a cpu atomic move and exchange or test and exchange opcode - if this opcode isn't found it falls back to something else. There is a good chance that this something else is buggy somehow. If anyone knows much about this then it would be great to get it fixed - maybe a simple program that excecises pthread functions would bring the real problem to light - APT seems to just be unlucky : Otherwise, let this be a warning that pthread in certain rare situations simply does not work and must not be linked to any programs. Future APT releases will not be linked to pthreads. A pre-release [not yet in CVS] is at http://faure.debian.org/~jgg/ please test if if you have had this problem. Jason
Faure, Kubrick and Albert down
These machines are down for now, it looks like the home disk has failed. Thanks, Jason Debian Admin
Sparc NFS?
Is something wrong with sparc nfs? The number of kernel messages that kubrick is spitting out is just crazy! __nfs_fhget: inode 556339224 still busy, i_count=2 __nfs_fhget: killing queue-1.20.1-pre4.orig.tmp-nest/queue-1.20.1-pre4.orig filehandle nsm_mon_unmon: rpc failed, status=-13 lockd: failed to monitor 209.41.108.194 __nfs_fhget: inode 556353730 still busy, i_count=2 __nfs_fhget: killing silo-0.8.6.tmp-nest/silo-0.8.6 filehandle __nfs_fhget: inode 555950101 still busy, i_count=2 __nfs_fhget: killing silo_0.8.6.orig.tar.gz.tmp-nest/silo-0.8.6.orig filehandle nsm_mon_unmon: rpc failed, status=-13 lockd: failed to monitor 209.41.108.194 __nfs_fhget: inode 556353731 still busy, i_count=2 __nfs_fhget: killing silo-0.8.6/boot.orig filehandle __nfs_fhget: inode 556280005 still busy, i_count=2 Server is using user-space nfsd.. Jason
Re: apt ftp method dying after upgrade
On Wed, 30 Jun 1999, Mike wrote: It was Working Okay Before(tm) and network connectivity is also fine. I can ftp to the target mirror okay from the command line and as ususal, everything else appears to be working fine. Try strace -o /tmp/jnk -ff apt-get fooo And see where the ftp method is blowing up (/tmp/jnk.?? will contain the trace) if it is a segv then gdb it please.. Jason
Re: apt ftp method dying after upgrade
On Wed, 30 Jun 1999, Mike wrote:
Bear with me here, I haven't done much C/Linux debugging before, but
this looks like the problem:
[snip]
ioctl(1, TCGETS, {B9600 opost isig icanon echo ...}) = 0
close(-1) = -1 EBADF (Bad file descriptor)
close(-1) = -1 EBADF (Bad file descriptor)
I don't have gdb handy, but I'll get it and have a futher look if you
think it would help.
Nope, that's harmless, look at the very end, the last couple lines of the
traces that contain exec(.../ftp) type lines
Jason
Re: apt ftp method dying after upgrade
On Wed, 30 Jun 1999, Mike wrote:
read(3, \0\0\0\0\0\0\0\1\0\0\0\25\0\0\0\1..., 32) = 32
readv(3, [{mirror.aarnet.edu.au\0, 21}, {\0\0\0\22, 4}, {\300o \2,
4}, {\
0\0\0\0\0\0\0\0\0\0\377\377\300..., 16}], 4) = 45
read(3, ftp.au.debian.org\0, 18) = 18
close(3)
--- SIGBUS (Bus error) ---
Do you want a copy of the trace?
Nope, that's just cool - can you get gdb hooked on that FTP process? That
might require some dark magic.. Bus Errors are bad news :
Jason
msync broken?
Hi, We just upgraded kubrick to 2.2.9 and glibc2.1 but unfortunately this has really hosed the msync syscall which apt relies on. Now every time I go to update the cache it writes something totally different to the disk! Removing the calls to msync hides the problem. This is using that latest 0.3.7 version of APT. This sounds like a nasty kernel bug, anyone have some idea how to fix it? [I've had APTs use of mmaps and msyncs kill kernels before, up till 2.2.6 everything would randomly lock up while running apt on intel :|] Thanks, Jason
