Re: Install Report: Tyan Thunder K8S Pro / dual Opteron 250 / 2GB / SATA root
> Next time, try mount / -o remount,rw. Don't forget to > mount / -o remount,ro when you're done, for a clean shutdown. In fact, I tried it this time. By "stuck" in readonly I meant that even in single user mode it refused to remount root read-write. I still don't know why this happened. -David
Re: firefox crach
I can confirm that I have had firefox crashes triggered by autocompletion of form data, and removal of the form history always solved the problem (if temporarily). Sadly these are only some of the crashes I have experienced; it seems that the blackdown mozilla flash plugin for amd64 also shows incompatibilities. I think these are separate problems. -David > Someone suggested this is due to autocompletion of form data. I > haven't verified this yet since I only learned about it today, but > it's probably worth trying to delete > ~/.mozilla/firefox/something/formhistory.dat. > > Cheers, > Kyle >
Install Report: Tyan Thunder K8S Pro / dual Opteron 250 / 2GB / SATA root
Executive Summary: I didn't use the installer, rather I debootstrapped on a HDD and then put it in the new machine. Unlike any of my previous debian-amd64 installs, everything "just worked". Thanks debian-amd64 developers for all of your hard work, as this port has come a long way! A Few Details: After rocky experiences installing debian-amd64 on Athlon64 boxen, I nevertheless decided to use it for my new computation server. This machine will be used for various long-running computationally-intensive mathematical tasks. The specs are: Tyan Thunder K8S Pro (s2882) with BIOS 2.03 Dual Opteron 250 2 GB Kingston ECC/Registered PC3200 DDR RAM Samsung SP1213C 120GB SATA HDD (By the way, the BIOS version may be important here. Tyan's web site says that Opteron 250 support was only recently added, but thankfully 2.03 has this feature.) I bootstrapped the installation rather than using a bootable CDROM; my procedure was: 1) Install HDD in working debian-amd64 box, partition and create filesystems. 2) cdebootstrap from alioth 3) chroot and apt-get miscellaneous utilities (scsi-tools, etc.) 4) compile kernel with hardware support as listed on debian-amd64 K8 mainboard compatibility list and "safe" options (e.g. no NUMA) 5) edit fstab and other config files to reflect predicted configuration of new machine 6) install GRUB 7) transplant HDD into dual Opteron machine and boot 8) apt-get more applications, recompile kernel with "optimal" settings (SMP, NUMA etc) The only hitch was that I left a "/dev/sdb" in fstab that needed to be "/dev/sda", and as a result fsck failed on boot. The root filesystem seemed stuck in readonly mode, so my solution was to add the kernel parameter "rw" and skip fsck on boot. I was then able to edit fstab. The K8 mainboard compatibility list was very helpful and all of the onboard hardware was supported immediately when I compiled a kernel with the drivers listed there. Maybe, though, it would be good to add a list of XFree86 drivers for the onboard video where appropriate? The K8S Pro has builting ATI Rage/XL which works fine with the "ati" driver. Hardware monitoring with lm_sensors works well but really requires the custom "sensors.conf" available from http://www.tyan.com. So far, I can definitely recommend this board/CPU combination for use with debian-amd64. I will post an update if anything changes significantly. -David
Re: Bug#260747: removing "--enable-final" allows successful compilation of arts-1.3.0
I was referring to the rules for arts-1.3.0-1, specifically, lines 73-76: # run configure with build tree $(objdir) cd $(objdir) && \ CC=gcc-3.3 CXX=g++-3.3 ../configure $(configkde) --enable-final \ --with-alsa However, as you point out, gcc/g++ 3.3 is used to build the package by default. I removed the CC and CXX settings and rebuilt with the default version on my system (3.4.1), and experienced the segfault in mcopidl. I then removed the suspicious "--enable-final" option and the package compiled successfully with 3.4.1. Thus in the end I replaced the rules quoted above with: # run configure with build tree $(objdir) cd $(objdir) && \ ../configure $(configkde) \ --with-alsa -David On Sun, 15 Aug 2004 21:56:08 +0200, Matthias Klose <[EMAIL PROTECTED]> wrote: > the version you cite is not made by the gcc-3.4 package in unstable > nor do I see that --enable-final is passed at configure time. > > Matthias > > David Dumas writes: > > I experienced the segfault in mcopidl when compiling arts-1.3.0 with > > gcc 3.4.1 under debian unstable (amd64). I looked at debian/rules and > > found that "--enable-final" is passed to configure; this option has > > the following description in the configure usage message: > > > > --enable-final build size optimized apps (experimental - needs > > lots > > of memory) > > > > Why would the debian package optimize for size? Anyway, removing this > > option allowed a successful build, i.e. no segfault in mcopidl. > > > > -David > > > > $ gcc -v > > Reading specs from /usr/lib/gcc/x86_64-linux/3.4.1/specs > > Configured with: ../src/configure -v > > --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang > > --prefix=/usr --libexecdir=/usr/lib > > --with-gxx-include-dir=/usr/include/c++/3.4 --enable-shared > > --with-system-zlib --enable-nls --without-included-gettext > > --program-suffix=-3.4 --enable-__cxa_atexit > > --enable-libstdcxx-allocator=mt --enable-clocale=gnu > > --enable-libstdcxx-debug --disable-werror x86_64-linux > > Thread model: posix > > gcc version 3.4.1 (Debian 3.4.1-5.0.0.2.amd64) > >
unison 2.9.1 segfault on amd64
When I try to synchronize my laptop (running debian i386 unstable) with my desktop (running debian amd64 unstable) the unison process on the desktop segfaults just before starting to update files. Is anyone else experiencing this problem? (BTW I mentioned before that there isn't a segfault in debian amd64 that recompiling with gcc 3.4 doesn't fix. I must now retract that statement, though 3.4 is still the right way to go.)
Re: amd64 sleeps too quickly
> Note the difference in command lines: Ian ran "time" on an outside > machine, so that the machine was not timing its own "sleep" command. I get the same (correct) result when using another host running i386 linux to time the sleep command: $ time ssh feynman "sleep 5; echo done" done real0m5.102s user0m0.011s sys 0m0.002s > This bug is probably one[1] that has been discussed at some length on > the linux-kernel list (after it showed up here). Looks like it, but as far as I can tell this also causes the time of day to advance twice as fast as it should... I would think Ian would notice this before testing out "sleep". -David
Re: amd64 sleeps too quickly
> $ time ssh pergolesi.debian.org "sleep 5; echo done" > done > > real0m2.957s The problem is not universal: $ uname -a Linux feynman 2.6.7.2004-07-11feynman-amd64 #3 Sun Jul 11 03:09:04 EDT 2004 x86_64 GNU/Linux $ time sleep 5 real0m5.001s user0m0.000s sys 0m0.002s $ dpkg -l coreutils Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii coreutils 5.0.91-2 The GNU core utilities
Re: gcc-defaults: Please make gcc-3.4 the default on amd64
On Mon, 19 Jul 2004 23:00:34 +0200, Andreas Jochens <[EMAIL PROTECTED]> wrote: > > Please make gcc-3.4 the default on amd64. It has much better support for > the amd64 architecture and also much better performance on amd64 > than gcc-3.3. > Yes, please do. I recently switched to the amd64 port full-time, and have not yet encountered a segfault that recompiling with gcc-3.4 didn't fix. Moreover, I think this relatively new port should standardize on a gcc with good K8 support while it is still young. -David
