Re: apt update issue
On Sun, 10 Aug 2003, Matt Herzog wrote: > Perhaps I should address this mail to the apt or dpkg mailing list > but I thought I'd try here forst in case it's a Sparc-specific issue. > I already and repeatedly tried the suggested solution to no avail. Long ago I observed that some of the older not-ultrasparc sparcs had a bug that caused writable mmap corruption that gave these symptoms. I've also seen similar problems on some BSD versions that botched msync. IIRC. 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: 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: 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: > 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
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: 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
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 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: 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, 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: 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: 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
Re: Pthread brokenness
On Wed, 4 Aug 1999, Andrew Howell wrote: > Yeah after getting apt working I tried install ssh and it seems to be looping > while > generating the host key. > > Anyone else had problems with ssh on IPCs? The current libgmp is broken. In my home dir on faure is a slightly older .deb that fixes that - someone should really fix it correctly. Jason
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
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
Re: apt not working with sparc ipc
On Fri, 30 Jul 1999, Andrew Howell wrote: > Attached is strace output of the http sub process. > > It just gets stuck in a loop of > > _newselect(0x1, 0xefffeb48, 0, 0, 0)= 1 > read(0, "", 4000) = 0 Ah, this is a different bug, the HTTP method was ignoring the signs of a close FD (woops) It's fixed in CVS now - it would be nice to see straces of the code leading up to the failure. Whatever is causing that FD to close is the real culprit here. Jason
Re: apt not working with sparc ipc
On Fri, 30 Jul 1999, Andrew Howell wrote: > > You are going to have to use PS to find out which process is spinning and > > strace that - I think you will find it is the 'http' or 'ftp' sub process. > > I usually use 'rm /tmp/apt*; strace -o /tmp/apt -ff apt-get' > > Attached is strace output of the http sub process. > > It just gets stuck in a loop of > > _newselect(0x1, 0xefffeb48, 0, 0, 0)= 1 > read(0, "", 4000) = 0 Can you try the 4.0 version of strace, you will have to compile from source. I need to see what the FD array in 0xefffeb48 looks like. That is one of them 'impossible' things - select cannot return that an fd is ready but then have read return 0. So the only possible explanation is that something is messed up either in strace or your kernel/libc. Anyone know what gives? Jason
Re: apt not working with sparc ipc
On Thu, 29 Jul 1999, Andrew Howell wrote: > Basically the potato version of apt-get just uses up 100% CPU and sits then > doing not much when you do a 'apt-get update' I left it there for a couple > of hours and when I came back it had fetched 99% of the main packages file. It's a bit early for me.. but get a non-defective strace (from potato) and strace the spinning process. Sparc seems to have lots of weird problems with APT that are just not explainable by anything other than a bad kernel/libc. I looked at something like the once ahh how did it go - apt calles timegm and it goes in libc and starts spinning on a mutex from pthreads and never returns. That was on some weird glibc, it wasn't 2.1. 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: > I'd need apt compiled w/ debugging symbols, right? Where could I get the > source from for 0.3.6? (I can only find 0.3.11 on the Debian ftp site). > Ta. Use 0.3.11, it is pretty much the same 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
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: > 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
Faure/kubrick
I've purgated the homedirs of people who have never used faure, they are tared up in ~sshdist/oldhomes.tar.gz. The machine now runs ssh-pam with my libpam-mkhomedir module. A home directory will be created automatically the first time someone logs in.. Right now only faure has the ssh-pam stuff setup, so if you want to use kubrick you might have to login to faure first (nfs mount) Kubrick, Faure and Albert are now participating in our experimental LDAP account replication, so let me know if there are any problems! Thanks, Jason Debian Admin
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