Re: Asus K8N, Cool'n'Quiet, and sensors.conf
On Wed, Jan 26, 2005 at 10:07:35AM -0500, David Wood wrote: > Has anyone else noticed instability when using cpufreq modules? > > I have a pretty stable system, but I get OOPSes within a few hours or days > of using cpufreq_ondemand, and I've had a few crashes I was pretty sure > were related to cpufreq_userspace/powernowd. I'd been ignoring my Debian inbox for a long time until today... I have an Asus K8V (basic) with an Athlon64 3200+ (newcastle core) 1.5GB of RAM, two IDE disks, two SATA disks, and an ATI AIW Radeon 7200 (but I don't use the TV in/out features). I run x86 2.6.12.6. I'll eventually switch to AMD64 software when I know my hardware is stable with x86, so I can usefully make bug reports on crashing software... BTW, the K8V is a nice piece of hardware; the AD1980 sound hardware supports mixing PCM streams in hardware (or at least the driver does?), so I can have xmms, xine, and whatever other program all not interfering with each other. (except when something is doing 4 channel output). I couldn't decide between an Abit (I think) with a K8T800Pro chipset and my Asus with just K8T800, but I eventually chose the Asus because it had Analog Devices sound instead of Realtek. I was pleasantly surprised that the sound really was good on it, esp. with the multiple opens of the sound dev :) I've found that my machine is a lot less stable when running at lower than max speed. Not just stuff crashing, but memtest (from sysutils, or memtester; just mlock()s some memory to test, not like memtest86+). memtest finds errors when the CPU is slowed down. There might be other correlated factors, like disk access. To change speed, I've just used cpufreq-set -u 2000MHz (or 1800MHz, or 1000MHz). Max speed is 2200MHz. (Newcastle core: from dmidecode: ID: C0 0F 00 00 FF FB 8B 07 Signature: Extended Family 0, Model C, Stepping 0 ) Unfortunately, the machine isn't perfectly stable even at max speed. It never crashed before I upgraded the BIOS from 1.04 or something to 1.07, which was needed for cpufreq to work. Even when running at 2.2GHz (full speed) with only one stick of RAM (1024MB OCZ), it sometimes shows a cluster of memory errors in memtest. It doesn't seem significantly different from with both sticks of RAM, the other being a 512MB Infineon, IIRC. All DDR400. Run 129 completed in 357 seconds (0 tests showed errors). Run 130: Test 1: Stuck Address: Testing...Passed. Test 2: Random value: Setting...Testing... FAILURE: 0x7ffeebc8 != 0x7efeebc8 at offset 0x01ca67f0. Skipping to next test... Test 3:XOR comparison: Setting...Testing... FAILURE: 0x42ff4c7a != 0x43ff4c7a at offset 0x01ca67f0. Skipping to next test... Test 4:SUB comparison: Setting...Testing... FAILURE: 0x2707802e != 0x2807802e at offset 0x01ca67f0. Skipping to next test... Test 5:MUL comparison: Setting...Testing... FAILURE: 0x73c9b7ae != 0xb4c9b7ae at offset 0x01ca67f0. Skipping to next test... Test 6:DIV comparison: Setting...Testing... FAILURE: 0x != 0x0001 at offset 0x01ca67f0. Skipping to next test... Test 7: OR comparison: Setting...Testing... FAILURE: 0xb2dd75dc != 0xb2dd75dd at offset 0x01ca67f0. Skipping to next test... Test 8:AND comparison: Setting...Testing...Passed. Test 9: Sequential Increment: Setting...Testing...Passed. Test 10:Solid Bits: Testing...Passed. BIOS on all auto settings. no other runs showed errors (140 runs) (Running at lower CPU speeds, errors were much more frequent). Interesting that all the errors are clustered in time and space at one memory location... As I said, the software running is Debian i386 sid with Linux 2.6.12.6, compiled with gcc 4.0.2 20050816 (from sid). Does anyone have any ideas? I hate hardware I can't trust! What's the point of digital logic if it makes mistakes! So does anyone have any experience or advice? -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Asus K8V Cool'n'Quiet, problems solved
On Wed, Oct 12, 2005 at 08:54:49AM -0400, Lennart Sorensen wrote: I've once again been studiously ignoring my Debian mailbox for a long time... I thought I should reply to this for the benefit of the list archive, anyway. I eventually found a pdf on AMD's web site (the BIOS and Kernel guide, doc #26094) http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7203,00.html that suggested that the Athlon64 (Socket 754 version) memory controller can only run at DDR333 with two double-sided DIMMs, which is what I have. No wonder I was having problems! Setting DDR333 in the BIOS has made my machine rock-solid stable, even when running for months at 1000MHz at 1.1V. My theory on why I only had problems at lower CPU speeds is that the lower CPU voltage that comes with that either lowered the drive strength of the memory controller, or maybe lengthened the rise and fall times of the signals enough that it wasn't quite crisp enough for the RAM I have. With only one or the other DIMM, I could run at DDR400 at any CPU speed. So, problem solved. At DDR333, the memory timings are a little faster, so it's not too bad at all. I haven't really benchmarked, though. Thanks for all the suggestions. I read them at the time, and they were useful, but I didn't get around to replying until I had the system stable. BTW, I have an Enermax 465W power supply, so it's _solid_. > On Thu, Oct 06, 2005 at 06:06:39PM -0300, Peter Cordes wrote: > > I'd been ignoring my Debian inbox for a long time until today... > > > > I have an Asus K8V (basic) with an Athlon64 3200+ (newcastle core) 1.5GB of > > RAM, two IDE disks, two SATA disks, and an ATI AIW Radeon 7200 (but I don't > > use the TV in/out features). I run x86 2.6.12.6. I'll eventually switch to > > AMD64 software when I know my hardware is stable with x86, so I can usefully > > make bug reports on crashing software... > > > > BTW, the K8V is a nice piece of hardware; the AD1980 sound hardware > > supports mixing PCM streams in hardware (or at least the driver does?), so I > > can have xmms, xine, and whatever other program all not interfering with > > each other. (except when something is doing 4 channel output). I couldn't > > decide between an Abit (I think) with a K8T800Pro chipset and my Asus with > > just K8T800, but I eventually chose the Asus because it had Analog Devices > > sound instead of Realtek. I was pleasantly surprised that the sound really > > was good on it, esp. with the multiple opens of the sound dev :) > > > > I've found that my machine is a lot less stable when running at lower than > > max speed. Not just stuff crashing, but memtest (from sysutils, or > > memtester; just mlock()s some memory to test, not like memtest86+). memtest > > finds errors when the CPU is slowed down. There might be other correlated > > factors, like disk access. To change speed, I've just used cpufreq-set -u > > 2000MHz (or 1800MHz, or 1000MHz). Max speed is 2200MHz. (Newcastle core: > > from dmidecode: ID: C0 0F 00 00 FF FB 8B 07 > > Signature: Extended Family 0, Model C, Stepping 0 > > ) > > > > Unfortunately, the machine isn't perfectly stable even at max speed. It > > never crashed before I upgraded the BIOS from 1.04 or something to 1.07, > > which was needed for cpufreq to work. Even when running at 2.2GHz (full > > speed) with only one stick of RAM (1024MB OCZ), it sometimes shows a cluster > > of memory errors in memtest. It doesn't seem significantly different from > > with both sticks of RAM, the other being a 512MB Infineon, IIRC. All > > DDR400. > > > > Run 129 completed in 357 seconds (0 tests showed errors). > > Run 130: > > Test 1: Stuck Address: Testing...Passed. > > Test 2: Random value: Setting...Testing... > > FAILURE: 0x7ffeebc8 != 0x7efeebc8 at offset 0x01ca67f0. > > Skipping to next test... > > Test 3:XOR comparison: Setting...Testing... > > FAILURE: 0x42ff4c7a != 0x43ff4c7a at offset 0x01ca67f0. > > Skipping to next test... > > Test 4:SUB comparison: Setting...Testing... > > FAILURE: 0x2707802e != 0x2807802e at offset 0x01ca67f0. > > Skipping to next test... > > Test 5:MUL comparison: Setting...Testing... > > FAILURE: 0x73c9b7ae != 0xb4c9b7ae at offset 0x01ca67f0. > > Skipping to next test... > > Test 6:DIV comparison: Setting...Testing... > > FAILURE: 0x != 0x0001 at offset 0x01ca67f0. > > Skipping to next test... > > Test
Re: How do I know if...
On Sat, Jan 07, 2006 at 09:21:48PM +0100, Robert Cates wrote: > Hi, > > I have not yet successfully installed an AMD64 port (tried several > times, but keep getting a kernel panic for some reason), but when I do, > I'd like to know and be sure that I'm using 64-bit mode, and not 32-bit > mode. How can I check this to make sure I'm running the AMD64 port > installation in 64-bit mode? This might not help during the install, but file /bin/ls will tell you whether it's a 64bit or 32bit executable. ldd /bin/ls will print 64bit memory addresses. During the install, cat /proc/self/maps will show 32 or 64bit memory addresses, and that should depend on whether cat is 64 or 32bit, not just the kernel. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: is it em64t ?
On Sat, Jan 07, 2006 at 12:45:04PM +0100, Ernest jw ter Kuile wrote: > On Saturday 07 January 2006 11:46, Hamish Moffatt wrote: > > > > It does, but what if HyperThreading was present but disabled in the > > BIOS? I don't know how you would tell in that case. > > Most of these flags are not set simply because the kernel found a certain > type > of processor. They are the result of elaborate startup tests which detect > these capabilities. > > If a capability is disabled in the bios, two things can happen > > 1) the kernel does not detect it at all; in which case the relevant flag is > not set; > > 2) the kernel detects the capability but switched off; in which case the > kernel will attempt to switch it on (if it can of course). If this succeeds > the flag is set, if not you will often see an error and the flag is not > switched on. > > I have been told, however, that a few processor capabilities are so bound to > the a certain type of cpu that their flag is simply set if that cpu is found. > > I don't know under which category the hyperthreading flag falls, but knowing > that hyperthreading can be disabled in the bios, I would not expect the > kernel to simply set that flag blindly. I think that's all wrong. The flags are more or less a decoding of the CPUID result codes. As for HT, my dad's old laptop 1.7GHz P4-mobile (Northwood) has the ht flag, but it sure as hell doesn't have two logical CPUs. I looked at (but didn't really come close to understanding ;P) the relevant kernel code, and I think the ht flag indicates support for an API for asking how many logical CPUs there are, and so on, not that there actually are multiple logical CPUs on that physical CPU. The kernel log messages (look in /var/log/dmesg if other messages have bumped them from the ring buffer) are more useful than the ht flag. I don't remember if x86info is useful for this or not, but it's generally good at finding out about CPUs. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Asus K8V Cool'n'Quiet, problems solved
On Thu, Jan 12, 2006 at 04:38:50PM -0500, Homer Whittaker wrote: > I have searched thru the various tech notes and papers specified below > but am unable to find out HOWTO pick up the BIOS setting that are > referenced in your posts. > Can you be definitive in the exact settings (and where) for the AMD > Athlon 64 Socket 754 version? Are you asking how to set your BIOS to run at DDR400 (actually 200MHz, but with two data transfers per clock, so ddr400) or DDR333 (166MHz), or whatever? Some BIOSes have a setting for that directly, while in others you don't specify the absolute memory speed, but rather at a ratio of some other clock. e.g. in this old review of the K8V Deluxe http://www.lostcircuits.com/motherboard/asus_k8v/7.shtml, they say the BIOS had an Memclock to CPU Ratio setting. The BIOS will usually print out somewhere what speed your RAM is running at, either in MHz or DDRsomething. Probably more recent BIOS versions would present it as DDR something and hide the ratio stuff from the user. You can always boot memtest86+, and it will show you DDRsomething, and your memory timings (e.g. 3-4-4-7 = CAS latency: 3, etc. I don't remember which order they're in. see http://www.tomshardware.com/2006/01/04/bios_from_a_to_z/page11.html) Then you can poke at settings until you get something that makes memtest or the BIOS show you the speed you were aiming for. On my Asus K8V, the BIOS has a memory clock option, and if I take it off auto, I can set it to DDR333, which is what I do, because I have two double-sided DIMMs, in slots 1 and 3. At first I thought you were asking exactly where I found what speeds were ok, so I'll answer that, too: In AMD's doc http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF the table for socket 754 CPUs using unbuffered DIMMs is on pages 175-176. I guess x8 double rank = double sided, while x8 single rank or x16 means single sided memory modules. Earlier pages go into a lot of detail about timings (e.g. CAS latency), and tradeoffs vs. clock speed. e.g. the BIOS should go on memclock step slower if that lets it go one whole CAS latency faster. e.g. prefer DDR333 CAS 2 to DDR400 CAS 3, but not DDR333 CAS 2.5. (The docs says that tidbit of info was based on performance testing.) If none of that makes any sense, you should look on hardware review sites like tomshardware or anandtech for some bios settings guides. Or you should accept the fact that electronics are complicated, and just use AMD's table of settings as best you can without spending huge amounts of time learning electronics. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc bug?
On Wed, Dec 14, 2005 at 11:10:41AM +0300, Basil K wrote:
> Hi,
>
> I just to try compile example from OProfile docs with strfry(char *) function.
> Seg fault occured when I run result program.
>
> Is there error of my system (Acer aspire 1520), or Debian etch for
> AMD64 platform?
>
> This is listing of program:
>
> #include
>
> int main()
> {
> char string[ ] = "abcdefjh";
>
> strfry(string);
> return 0;
> }
Does compiling with -fwritable-strings make it work? I was going to point
out how string constants were stored, etc, but then I noticed that it's a
char [] not a char *. So maybe there's a gcc bug. BTW, compiles ok for me
on i386 sarge and on amd64 gcc-3.4 (on a workstation I installed for a
postdoc, which is now horribly out of date. That gcc-3.4 branch probably
isn't still being maintained, is it :(
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: blackdown Java, amd64 and java-package
On Fri, Nov 05, 2004 at 01:16:13PM +1100, Robert King wrote: > What am I doing wrong here? You're using make-jpkg with a reasonably up-to-date java release. That doesn't work, because java-package doesn't seem to be very actively maintained. You can probably hack the shell scripts to go ahead with the different version and file size, though. It would be really nice if someone who knows what they're doing with java would keep java-package up to date, so Java could be another one of those things that Just Works, at least after downloading Blackdown's release. > solzhenitsyn:/usr/local/package# make-jpkg j2re-1.4.2-rc1-linux-amd64.bin > Creating temporary directory: /tmp/make-jpkg.mFAQu4 > Loading plugins: blackdown-j2re.sh blackdown-j2sdk.sh common.sh j2re.sh > j2sdk.sh j2se.sh sun-j2re.sh sun-j2sdk.sh > > No matching plugin was found. > Removing temporary directory: done > -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: Xephyr on AMD64 Etch a.k.a multiseat
On Fri, Jun 08, 2007 at 10:14:38AM -0500, Igor TAmara wrote: > Hi, I'm following this howto[1] to make a multiseat system on AMD64, > I saw there were precompiled binaries for Xephyr, and I started to > create some packages with apt-get source applying the patches on > that page[1] > ... > Mi questions : > * Does anyone have experiences of multiseat with AMD64? > * If so, the Xephyr approach or something else? (documents?) > * If with Xephyr, do you have a recommendation for applying the > necessary patches? Maybe a pointing to a howto or a manual? I > suspect that I'm applying the patch incorrectly, how to do that in > a correct way? Sorry, this is an old email, but I'm digging through my Debian mailbox archives... xorg now supports sharing virtual terminals, so you can run multiple full X servers, with no need for xephyr anymore. They get device input from evdev, instead of from the console keyboard. I have a working g965 + PCI r128 multiseat system (two PS/2 keyboards and two USB mice plugged into an Intel DG965WH mobo). I have to get the PCI card initialized with int10, but if int10 is enabled when I start two X servers at once, they both get the g965 video BIOS or something, and it can't initialize. So my normal xorg.conf has i2c, ddc, int10, and vbe commented out. I was going to post some snippets of my xorg.conf, but it's going to be a lot more useful to actually post the whole thing. (and the number of snippets was climbing...) And the Device and Serverlayout sections have sprinklings of Option "NoInt10" "true" Option "NoDDC" "true" # somehow r128 sees the i810's VBE BIOS... Option "SingleCard" "true" # like IsolateDevice Option "InitPrimary" "true" I'm sure not all of these are necessary, but that's where I got to by trial and error. I have a normal (multihead single seat) xorg config that doesn't disable POSTing the video cards, which I use to get the video cards initialized. # sudo X -config xorg.conf.probe -probeonly # then # startx /usr/bin/fluxbox -- :1 -layout seat1 -sharevts vt8 & # startx /usr/bin/fluxbox -- :0 -layout seat0 -sharevts vt7 & The key of course is the -sharevts. If you google around, you can find how to configure gdm to start the X servers, and for more tutorials on this. http://blog.chris.tylers.info/index.php?/archives/14-Multiseat-X-Under-X11R6.97.0.html http://en.wikibooks.org/wiki/Multiterminal_with_evdev I had been hoping to give the PCI video card to a Xen hardware-virtualized domain, and give my dad a windows desktop. That doesn't work (yet?). I might do more with multihead when I get more RAM (2GB DIMMs are becoming available :), but I still need to reboot occasionally when the g965 driver crashes. (It doesn't lock the machine at all, but rebooting (or suspend-resume, when that works at all), is the only way I've found to get the g965 video hardware back to a useable state.) I have used multiseat while playing vegastrike on the g965 head, with out-of-game tools on the r128 head. Having a separate keyboard is a big win when using games that take over the X server and can't be switched away from easily. Well, CTRL+ALT+Fx to another X server might work. But anyway. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: Xephyr on AMD64 Etch a.k.a multiseat
On Wed, Aug 01, 2007 at 11:31:24PM -0300, peter wrote: > So my normal xorg.conf has i2c, ddc, int10, and vbe commented out. I was > going to post some snippets of my xorg.conf, but it's going to be a lot more > useful to actually post the whole thing. and as usual I forgot to. This time for sure... -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC # xorg.conf for multiseat operation, g965+r128. # can start i810 head without any probe: # startx /usr/bin/fluxbox -- -layout simple & # This X config omits the card init stuff, so to use the r128 it still needs # sudo X -config xorg.conf.probe -probeonly # then # startx /usr/bin/fluxbox -- :1 -layout seat1 -sharevts vt8 & # startx /usr/bin/fluxbox -- :0 -layout seat0 -sharevts vt7 & # occasional colour corruption on i810 head, but glxgears makes it go away #or # startx /usr/bin/fluxbox -- -layout alltogether & # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type "man /etc/X11/xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section "ServerFlags" Option "DefaultServerLayout" "simple" #Option "DefaultServerLayout" "alltogether" #Option "DefaultServerLayout" "seat0" Option "AllowMouseOpenFail" "true" Option "AIGLX" "false" EndSection Section "Files" FontPath"/usr/share/X11/fonts/misc" FontPath"/usr/share/X11/fonts/cyrillic" FontPath"/usr/share/X11/fonts/100dpi/:unscaled" FontPath"/usr/share/X11/fonts/75dpi/:unscaled" FontPath"/usr/share/X11/fonts/Type1" FontPath"/usr/share/X11/fonts/100dpi" FontPath"/usr/share/X11/fonts/75dpi" FontPath"/usr/share/fonts/X11/misc" # path to defoma fonts FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" EndSection #Section "Extensions" # Option "Composite" "disable" #EndSection Section "Module" # Load"i2c" Load"bitmap" # Load"ddc" Load"dri" SubSection "extmod" Option "omit xfree86-dga" EndSubSection # Load"extmod" # subsection does this Load"freetype" Load"glx" # Load"int10" Load"type1" # Load"vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" # Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "us" Option "XkbOptions""ctrl:nocaps" Option "Autorepeat""200 40" #Ubuntu default: lv3:ralt_switch ISO level 3 shift EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" # Option "CorePointer" Option "Device""/dev/input/mice" Option "Protocol" "ExplorerPS/2" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" Identifier "NoKeyboard" # Option "CoreKeyboard" Driver "void" EndSection Section "InputDevice" Identifier "NoMouse" # Option "CorePointer" Driver "void" EndSection Section "Device" Identifier "i810" Driver "intel" BusID "PCI:0:2:0" # VideoRam131072 #
Re: Do you know this mirror?
On Mon, Sep 27, 2004 at 12:25:15PM +0200, Andreas Jochens wrote: I missed your reply until now... oops. > On 04-Sep-24 17:00, Peter Cordes wrote: > > Speaking of which, the Packages.gz files for the gcc-3.4/testing repository > > on bach.hpc2n.umu.se are 20bytes (i.e. a gzip of an empty file). The > > uncompressed versions are right, but apt-get goes for the compressed. > > The amd64/gcc-3.4 repository currently has only packages from > sid/unstable and not from sarge/testing. This is the reason why the > Packages.gz file for testing is empty. It's not empty on Alioth. gcc-3.4/dists/testing/Release says it's unstable, not testing, though. A symlink, I guess. > However, I am preparing an amd64/gcc-3.4 sarge archive > for my own private use which has already the debs from > 7940 source packages from current 'testing' installed. > > If there is demand for an amd64/gcc-3.4 sarge/testing archive, > I could upload my packages to the gcc-3.4 archive on alioth. I guess the machine I thought was running sarge is actually running sid. I think I'll stick with sid, myself. Thanks for clearing up my confusion. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Promise or VIA?
On Mon, Sep 27, 2004 at 03:55:48PM +0200, Pep Turr? wrote: > Hi, > > (this is a bit off-topic) > > On Wed, 22 Sep 2004 17:55:50 -0500, Pete Harlan <[EMAIL PROTECTED]> wrote: > > The Asus A8V I bought has both a VIA and a Promise SATA controller, > > and both work fine with Linux. The Promise is better supported under > > Linux (or possibly just a better controller; it does TCQ under Linux, > > where the VIA doesn't (yet?)) as far as I could tell from the SATA > > compatibility page. > > I was wondering: having both a Promise and a VIA SATA controllers and > 2 hard drives: to implement software raid, which of these > configurations would give better performance?: > > 1. One HD attached to a different controller (one to VIA, one to Promise) > 2. Both HDs on the VIA controller > 3. Both HDs on the Promise controller > > I guess that using a single controller would put more load on it but > reduce the PCI bus load, and vice versa... am I right? Check your motherboard block diagram. If the disk controller is attached directly to the chipset, not through a 32bit/33MHz PCI bus, that's a Good Thing. If that's the case for only one of the controllers, you should obviously use that controller. (esp. don't use a controller that shares a slow bus with gigE if you're going to do any file/web-serving.) > >From the thread discussion, I would say that option 3 is better than 2 > (Promise being a better controller)... but is it better than option 1 > in overall performance on this scenario? what do you think? I agree. Hard drives these days don't saturate 150MB/s SATA, except on burst transfers to/from their cache. W/ 2 drives, you might come close to saturating 133MB/s 32bit 33MHz PCI. faster/wider PCI busses, hypertransport, or VIA's V-link (between north and southbridges) won't be a bottleneck unless you have more drives. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Promise or VIA?
On Wed, Sep 22, 2004 at 10:40:12AM -0500, Ron Johnson wrote: > On Wed, 2004-09-22 at 17:27 +0200, Leopold Palomo-Avellaneda wrote: > > A Dimecres 22 Setembre 2004 17:14, Paul Brook va escriure: > > > On Wednesday 22 September 2004 16:04, Leopold Palomo-Avellaneda wrote: > > > > A Dimecres 22 Setembre 2004 15:55, Ron Johnson va escriure: > > > > > On Wed, 2004-09-22 at 15:48 +0200, Leopold Palomo Avellaneda wrote: > > > > > > A Dimecres 22 Setembre 2004 15:38, Paul Brook va escriure: > > > > > > > On Wednesday 22 September 2004 14:11, Leopold Palomo-Avellaneda > > > > > > > wrote: > > > > > > > > > > [snip] > > > > > > [snip] > > So, it isn't worth it to have a SATA 150MB/s HD if you have the limitation > > of > > the 133 MB/s of the bus, no? > > From rom a pure speed point-of-view, you are correct. Not all boards have the SATA on a 32/33 PCI bus. e.g. NVidia's NForce3 250 chipset has SATA right in the chipset, where it's right on the hypertransport bus from the CPU. Unfortunately, the only drivers for the gigE NIC in that chipset are binary-only or reverse-engineered :( Same for the audio, AFAIK. Apparently the SATA driver is Free, though. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: SATA/usb mass storage conflict
On Tue, Sep 28, 2004 at 11:26:37AM +1000, Richard Salts wrote: > Is there a simple way to remove the drivers for usbms from the initrd > image while using the fc rescue disk? I've had to fight with Debian's initrds for 2.4 openMosix kernels (for the 3w-9xxx modules...) I wrote a shell script that mounts the cramfs image, makes an ext2 filesystem in an 8MB file, mounts it, cp -a, and fixes some things up. You might do the same thing (manually). > Has anyone had similar > experiences? I'm assuming the sata drives and the usb drives are > fighting over /dev/sda, if I were to create a kernel image with the sata > drivers compiled in statically and the usbms loaded as a module later > do people think it will still conflict? I think Linux knows not to load a module when it's already compiled in. (Probably just because of symbol errors.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Install Report: Tyan Thunder K8S Pro / dual Opteron 250 / 2GB / SATA root
On Thu, Sep 30, 2004 at 09:30:57PM +0200, Johan Groth wrote: > So I wonder which graphics card do you use? I have a Leadtek FX5200 > (AGPx8) which is the cheapest AGPx8 card I could find. Should I go for > something more expensive. I would prefer NVidia but can go for a ATI as > well. Just as long as it is compatible with a 2885 MB and is stable. I just put together an Athlon64 at home, with an Asus K8V mobo, and an Athlon64 3200+ (newcastle core :) CPU. I picked up a second-hand ATI Radeon All-in-Wonder AGP card, which supports AGP 4X (1.5V), so it works with 8x/4x-only mobos. It's the original Radeon 7000, w/32MB of RAM, so it's not fast at 3D, but it's ok. I haven't tried the TV in/out yet, but that should be an adventure w/AMD64 :) I'm still digesting all the recent emails about Promise PATA+SATA controllers... (I have 2 PATA drives with i386 Debian all nicely installed and set up with a combination of RAID1 and LVM... I was hoping to put one of them on the PATA port driven by the mobo's 20376 promise controller, but that may have to wait for driver advancements. The Promise BIOS seems unhappy that there is no RAID array defined for the drive... If I want to boot from it, I might have to set it up in the BIOS as a one-drive RAID0, which sounds ridiculous. The mobo manual says the promise controller won't work with optical drives, but if I can live without being able to boot from CDROM, that would be a good way to go if it works with Linux.) > > > From: David Dumas [mailto:[EMAIL PROTECTED] > Sent: Thu 30/09/2004 19:48 > To: debian-amd64@lists.debian.org > Subject: Install Report: Tyan Thunder K8S Pro / dual Opteron 250 / 2GB / SATA > root > ... > 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. Next time, try mount / -o remount,rw. Don't forget to mount / -o remount,ro when you're done, for a clean shutdown. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: newbie last try
On Thu, Oct 07, 2004 at 09:22:01AM +0200, Thomas J. Zeeman wrote: > > Hi, > > > 1. I am unable to have windows in option for boot-up in GRUB. During > [snip] > > This is an old bug I reported several months ago already. It is still not > fixed. > >From what I remember the installer for AMD64 does not have the necessary > scripts to recognize a Windows partition on NTFS. The fix someone > mentioned then was to use the same scripts for AMD64 as i386 already uses. > > You can alter the grub menu.lst file once you have the system installed. > There is an example in the comments at the start. > > > 2. When I finish installing the base system and bootloader and > > reboot, I constantly have the same code consistently repeating in the > > shell: > > > > nv_sata: primary device added > > nv_sata: primary device removed > > nv_sata: secondary device added > > nv_sata: secondary device removed > > > > Thsi keeps going on throughout the rest of the install, when trying to > > get apt-get working, to the point where I can't choose options or type > > since this is continually running and bringing the screen down. > > Horribly frustrating and irritating. No other distributions I tried > > had this problem, x86 or amd64. > > I remember seeing a post about this a few weeks ago. IIRC the poster > finished the installation blind and set a few configs afterwards that > fixed this. Check the archives from september for how and what he did. You should be able to change the console log level, so even if the kernel is generating the messages, they don't show up on the screen. ALT+SYSRQ+0 should set the log level so that you don't see anything. Depending on what priority those messages are logged at, ALT+SYSRQ+2 or 3 might be enough, and still let critical messages show on the console. See also setterm(1). If the installer kernel doesn't have sysrq support turned on, there's some /proc stuff, I think. Also echo 1 > /proc/sys/kernel/printk_ratelimit might help. echoing into /proc is doable without any special tools, so you can do it from tty2 in the installer even. (And it tab-completes filenames :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: No dma for via82cxxx
On Sun, Oct 10, 2004 at 06:22:30PM +0200, Michael Wagener wrote: > So probably you should check your cables. Those 80pin IDE cables seem > somewhat unreliable to me. Try changing the cable with a new/unused one. Also check /proc/ide/via. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: 64-bit kernel on sid / pure64?
On Tue, Oct 12, 2004 at 08:25:49PM -0500, Stephen Waters wrote: > Yay! Thanks to help from Peter Cordes, I was able to install the amd64 > k8 smp kernel from sid, amd64-libs, and iptables from pure64 -- and it > works! Great work, everyone! you're welcome :) Last time I tried the amd64 kernel from sid it oopsed during boot in kacpid (on my Tyan S2881). I haven't gotten around to reporting this yet. Should I, or does anyone who actually hacks on it have an S2881/2 mobo. > A few questions: > > 1) Is ALSA going to remain unusable until I upgrade alsa-base/alsa-utils > to 64-bit versions from pure64? If so, do I have to upgrade all of my > sound applications to ones from pure64? Someone mentioned a snd-ioctl32 module on this list recently... It's in the kernel in sound/core/ioctl32, but none of the docs in the kernel tree mention it. The comments in the code look promising, though. > I wish I had money to pay someone to make dist-upgrade magically work > for sid -> pure64/amd64 conversion! If you have the disk space, try debootstrap. Then maybe dpkg --get-selections | chroot something 'PATH=/sbin:/usr/sbin:$PATH; dpkg --set-selections' Then hack stuff around with /etc... Good luck hacking the symlinks and so on if you have /usr on a separate partition or something :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: Recommendations for cheap Linux-compatible Opteron mobo
On Wed, Oct 13, 2004 at 09:13:55AM +0800, Paolo Alexis Falcone wrote: > Any recommendations for a relatively cheap Linux-compatible opteron > motherboard? I'm looking forward for acquiring a couple of > single/dual-opteron boards for server stuff. Why not use a socket 754 Athlon64? Unless you need a ton of RAM, it should be fine. You can use registered ECC memory with them. The 32bit 33MHz PCI could be a bottleneck for you, though. If none of those are a concern, an Abit KV8Pro or an Asus K8V (or K8V-X if you don't need the extra Promise SATA) should do nicely. I eventually decided on the K8V over the KV8Pro, because I'm not into overclocking (the K8T800Pro chipset has an AGP/PCI clock lock), and 3 DIMM slots instead of 2 sounded good. I took a long time to decide, and eventually it came down to seeing an Analog Devices sound chip on the K8V, vs. Realtek on the KV8Pro :) I don't know if Realtek's sound hw is as cheap as their ethernet (rtl8139 has a crappy programming interface), but I just needed something to tip the scales one way or the other :) For dual opteron, Tyan boards (esp S2881 and 2) aren't cheap, but they're nice. (Tyan even _supports_ LinuxBios on them, and has an lm_sensors config you can download.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: Non-US packages
On Fri, Oct 08, 2004 at 11:50:24PM +0200, Koef wrote: > I need vtun package which normally is in the "non-US" repositories, but I > can't find non-US on the pure64 deb sites. What am I missing? You're missing that fact (or at least informed opinion) that vtun is not very secure: http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: 64-bit kernel on sid / pure64?
On Tue, Oct 12, 2004 at 11:58:05PM -0300, peter wrote: > Last time I tried the amd64 kernel from sid it oopsed during boot in kacpid > (on my Tyan S2881). I haven't gotten around to reporting this yet. Should > I, or does anyone who actually hacks on it have an S2881/2 mobo. Update: 2.6.8-4-amd64-k8-smp (version 2.6.8-4) booted ok. kacpid takes 100% cpu time (same as with 32bit kernels using 2.6.8-1-k7-smp (version 2.6.8-4)). I've re-niced it to +2 (instead of -10) so it doesn't cause too much trouble. With a 32bit kernel I sometimes saw kacpid take a few minutes before starting to eat CPU time, maybe depending on BIOS settings... (Tyan S2881 w/BIOS v2.04, Opteron 246HE CPUs, 6GB RAM, 3Ware 9500S-LP4.). The kernel complains about some ACPI method execution failures while booting. (at least it seems to respect nobiospnp, or at least doesn't do the same stuff as the 32bit kernel...). The kernel also doesn't like how Tyan's BIOS puts the IOMMU aperture above 4GB, so it says it can't use it. I've reported this to Tyan through my cluster vendor (HardData), so maybe someone will fix it... -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Recommendations for cheap Linux-compatible Opteron mobo
On Wed, Oct 13, 2004 at 08:47:09PM +0200, Roland Fehrenbacher wrote: > Ron> What's ASRock? > > Could you please keep this spam of the list??? In that spirit, I'll reply to another message from this thread here, instead of in a separate message: I said you could use ECC RAM with Athlon64, and someone said you have to use ECC RAM with Opteron. (Both of those things are true.) My point was that if you wanted a server with ECC RAM to prevent crashes due to cosmic rays, you don't need an Opteron, because Athlon64 (even the socket 754 version) can use ECC RAM. i.e. ECC RAM doesn't require Opteron. > Mind you, this is a Debian AMD64 list and not some hardware discussion > forum!!! I thought AMD64 was such a new architecture that a lot of people are just getting them, and so on. Maybe people should be reading linuxhardware.org or something, but I think it's better for people to post here and get steered towards good hardware (with Free drivers when possible) than for them to go out and buy bad stuff (esp. ATI Radeon > 9200) and then ask how to make it work with Debian :( I think it would be good if an official Debian person would weigh in with a comment on where to draw the line in terms of threads going off on tangents about hardware (or even being purely about hardware in the first place)... -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: Netboot- problem to find mirror
On Thu, Oct 14, 2004 at 07:15:25PM +0200, TAC-TAC computer wrote: > am using netboot installer (Sarge) > http://debian-amd64.alioth.debian.org/debian-installer/daily/netboot/ > > and I have problem to find a mirror with installer components. > > Err: Download installer components - Bad archive mirror The netboot installer loads some kernel modules (and installer components) from the mirror, so it has to match the installer. That means you have to tell it you're installing unstable. Use the "go back" option to get to the main menu... Once you've downloaded the installer components, you could go back and change to installing sarge again, except that there is no amd64 sarge archive. It's actually a symlink to sid, or something like that. Andreas (IIRC) said he had his own AMD64 Sarge archive, but I don't think he said he was going to put it on Alioth. > I tried to set it manually to debian-amd64.alioth.debian.org - but I am > not sure if there is the correct mirror located there, and I don't know the > right path to it. The path is /debian for the regular version, or /gcc-3.4 for the gcc 3.4 version. > Does exists a list of amd64 mirrors, and of mirrors with installer > componensts - I assume it is different. There's deb http://bach.hpc2n.umu.se/gcc-3.4 unstable main contrib non-free Get the installer components from the same mirror as the netboot image, since the kernel modules have to match the kernel. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: debian beginner is stuck....
On Mon, Oct 18, 2004 at 07:29:51PM +0100, Andreas Russ wrote: > Hi there, > I am just trying to run Debian on my Shuttle AMD64 box. I've worked with > most major distributions, but am new to Debian. A very positive > experience with the new installer on a 32-bit box now made me try the 64. > The base system installed perfectly via network (thanks to you all!), > within a couple of minutes I was up and running. But how do I go beyond > base to a graphical system? The 32-bit installer offered a choice, but > 64 just left me on my own. > I am using Alioth sid main and its mirrors, but I have the feeling I am > missing something here ;-) > Any help would be much appreciated, thanks a lot. 1. Log in as root 2. run apt-get install x-window-system-core gnome-desktop-environment 3. wait while a _ton_ of stuff installs :) (or 2. run apt-get install x-window-system-core xterm fluxbox, for a lighter weight desktop. There's also a "kde" package that depends on everything kde the same way gnome-desktop-environment does. If you have them both, use update-alternatives to set x-window-manager (or maybe x-session-manager) so you get the session you want.) Alternatively: 2. run apt-get install aptitude 3. run aptitude (There are other front-ends to apt, including graphical ones, but I like aptitude.) 4. hit / to search, and find x-window-system-core. hit + to select it. 5. find gnome-desktop-environment (or similar for kde), and pick the pieces you want. (you don't need every piece of gnome for a decent desktop, and it's easier on the mirrors if you're not continually updating stuff you're not using. You can aptitude install anything whenever you want.) 6. hit g to see what you're going to get. 7. hit g to do it. (8.) don't ^z and then fg the install process. Aptitude isn't smart enough to not mess up the terminal settings. :( If you don't want to log in on a text console and run startx every time you boot, you should install one of xdm, kdm, or gdm. (Note that the *dm don't source /etc/profile or ~/.bash_profile for your X session, unless you hack them. Thus $PATH, $LESSOPEN, and so on won't be set right. The ugly and lame solution to this is to put everything in ~/.bashrc and /etc/bash.bashrc... (even making your xterms all run login shells won't make PATH right for programs started from window manager menus. :( -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: 64-bit kernel on sid / pure64?
On Wed, Oct 13, 2004 at 08:38:32AM +0200, Frederik Schueler wrote: > Hi, > > On Tue, Oct 12, 2004 at 11:58:05PM -0300, Peter Cordes wrote: > > Last time I tried the amd64 kernel from sid it oopsed during boot in kacpid > > (on my Tyan S2881). I haven't gotten around to reporting this yet. Should > > I, or does anyone who actually hacks on it have an S2881/2 mobo. > > There where a few changes to acpi across the different versions of 2.6.8 > kernel-source debian packages, backports from 2.6.9-rc wich broke and fixed > again various issues. You might want to try > > deb http://users.idf.de/~fs/debian-kernel/i386/ ./ > > packages, wich actually are waiting in the NEW queue to be added to sid. Thanks. I didn't get around to trying them until they were in sid, on my university's local mirror, but anyway... They have the same problem as before. Sometimes they oops in kacpid, sometimes they boot but soon after become _very_ slow and lock up for minutes on end (with occasional periods of responsiveness) with kacpid taking all the CPU. It's not just the console that's messed up; I can ping but not ssh in. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Maybe a stupid question
On Mon, Oct 18, 2004 at 11:00:31PM +0200, Nicolas Sergent wrote: > Hello, > > I have a laptop (Acer Aspire 1511LMi) with a broadcom wlan card which > has no driver for linux, and ndiswrapper does not work in pure64 as > there is no 64 driver for MS Windows... I think many of us have the same > problem! > As far as I can understand it, the only way to get this card working > (until Broadcom release the specs) is to run a 32 bits kernel, but in > that case, what would be the point in having a AMD64? It's a fast CPU (significantly faster than Athlon), with SSE2, and with good power-saving when idle. (Down to 22W max at 1GHz, from 89W max at max speed.) It's not like it's crippled in 32bit mode. > Isn't it possible > to run a minimal 32 bits kernel in user-mode (in a kind of virtual > machine), just to run ndiswrapper on? Hmm, you mean route all your net traffic through vmware? That's so crazy it just might work. (I wrote the paragraph below about the kernel-userspace boundary before I read this carefully...) Maybe vmware even wouldn't be needed if UML can talk to hardware. Anyone care to comment on getting Linux under vmware to talk to hardware? > If this is totaly stupid I'd say having to use ndiswrapper is totally stupid, but I guess there's not much choice in AMD64 laptops at this point :( > and couldn't work, can please someone tell me > why (for my own culture)? Is this can be done, how can I help? the kernel-user boundary is well definined and has a limited number of system calls. The in-kernel stuff is constantly changing with new kernel releases, and probably would be harder to wrap in an emulation layer. (Besides, in-kernel function calls don't go through a context switch normally, and you'd have to introduce that, or put an x86 emulator like bochs in the kernel if you wanted to actually run 32bit code.) Perhaps pre-translating the ia32 code to amd64 code, like what gcj can do for java binaries -> machine code, would be better. It all boils down to open souce: good and flexible, closed source: bad and limiting. Depending on binary-only drivers from anyone puts you at their mercy. But you probably already knew that and didn't need me to lecture you... -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: amd64 sleeps too quickly
On Tue, Jul 20, 2004 at 01:20:03AM -0400, David Dumas wrote: > > 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... That's what I saw. As I mentioned somewhere in that thread Michael linked to, it's fixed in 2.4.27-pre3 and later. It turns out that soon after I initially reported the bug, Len Brown of Intel made some ACPI changes that happened to fix the double timer interrupts bug on AMD64. > I would think Ian would > notice this before testing out "sleep". That's what I noticed first! The fact that sleep is affected as well as just the system clock makes it more serious, though. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: Migration from unstable to testing.
On Fri, Jul 23, 2004 at 08:53:20PM +, Chris Wakefield wrote: > Ron Johnson wrote: > > >On Fri, 2004-07-23 at 18:17 +, Chris Wakefield wrote: > > > > > >>Greetings all: > >> > >>I would like to take this opportunity to thank all the developers and > >>people involved in porting Debian Linux to amd64. Debian is my favorite > >>Distribution and it's so great to finally be able to run in 64 bit mode! > >>I have been reading most of the posts, since the beginning of this year, > >>and I could see that it has been a lot of work and stress for you all. > >> > >>Thank You !!! > >> > >>My only concern at this point is: when Debian-amd64 finally makes it > >>into testing, how likely would a migration from unstable to testing > >>succeed? A while ago I downgraded a machine from unstable to woody (testing at the time, I think). I think apt took some convincing before it would do it, though. It is possible, but you should find a howto or something for some pointers on how to go about it. Unless you're happy to remove unstable repositories from your sources.list and wait for testing to catch up, which could take a long time for some packages, in which case it's easy. > >>... and would it be as simple as editing the sources.list and > >>_not_ involve pinning? (<-- not to be confused with my "pining" for > >>Debian-amd64!) or should I wait and do a reinstall to avoid the possible > >>difficulties? It's not too hard. I had a lot less experience with Debian than I do now when I did it. But apt doesn't automatically downgrade. > I have noticed that in the .config file of: vmlinuz-2.6.7-5-amd64-xeon If you're running an Opteron, you might want to run an Opteron kernel, instead of the Xeon flavour. I think someone said the Xeon doesn't have an IOMMU, and that kernel doesn't try to use it. You do have a 64bit system, though. > > has this: > > CONFIG_IA32_EMULATION=y That lets you run 32bit code too, e.g. statically linked or in a chroot. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: upgrade from testing i386 to amd64
On Sun, Jul 25, 2004 at 05:48:56PM +0200, Thomas J. Zeeman wrote: > > Are there any problems I may enounter? > > With i386 on an amd64 system any problem encountered is probably also a > problem on a real i386 system. > Do note that(AFAIK) you won't be able to use the extra registers, memory > address space and NX-bit in i386-mode. i386 Linux recently got support for the NX bit. (You've probably heard all the fuss about windoze getting super-virus-protection. The NX bit is what it uses to do that.) The extra registers are what makes AMD64 faster in 64bit mode, and you're right about them not being available in i386 mode. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: Installer problem
On Mon, Aug 02, 2004 at 06:55:30PM +0200, Miham KEREKES wrote: > Hi All, > > We're experiencing some problems regarding installing debian-amd64 on a > dual-Opteron 244 machine w/ 8G RAM. Disk subsystem is SATA w/ > 3ware Escalade 8506, the machine has 2TB HDD space. Is it on a PCI riser card in a PCI-X bus? That can cause problems with some Tyan mobos, according to some errata 3ware and Tyan mention. Other than that, maybe you're running into the 2TB block dev size limit? (I don't know exactly what it is, since the cluster we have coming in will have only 500GB of space, on a 3Ware 9xxx something card.) If have the time, you could compile your own kernel with kdb support, and boot the installer with it, so you can drop into the debugger by pressing a key. You could backtrace where the hang happens. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: testing buildd && gcc-3.4 transition
On Tue, Aug 03, 2004 at 02:14:59PM +0200, Goswin von Brederlow wrote: > deb http://debian-amd64.alioth.debian.org/gcc-3.4 sid main contrib non-free I have a pure64 chroot that I set up based on John's tarball a long time ago. I've apt-get dist-upgraded it a few times from alioth more recently, but it's been a month since I touched it now, I think. I don't plan to boot pure64 on these machines soon, just use it as a chroot, so does it make sense to just change my sources.list and apt-get dist-upgrade from the gcc-3.4 archive, or should I re-install from scratch? (Or should I apt-get install --reinstall everything from the new archive with a clever shell command?) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: [debian-amd64] Re: Installer problem
On Wed, Aug 04, 2004 at 10:57:36AM -0700, mike wrote: > I have a 3ware 9xxx card - you'll want to run kernel 2.6.8-rc1 or higher > to get fully supported in-kernel or module support. the source code from > their website is a pain to get working. i had them even examine my machine > personally. > > just so you know - it might save you some hassle later on. their low level > drivers are part of the linux kernel tree from 2.6.8-rc1 and later for the > 9xxx series. Hmm. I'd been planning to run openMosix on a 2.4 kernel until oM's 2.6 and AMD64 support stabilized. Maybe it's a good thing that the place building our cluster won't get it to us until mid-august... Thanks for the heads up. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: RFC: Adding minimal amd64/biarch support for sarge
On Wed, Aug 04, 2004 at 05:42:30PM -0400, Daniel Jacobowitz wrote: > First, what I'm suggesting: two new packages for sarge and one modified > package. They would allow 64-bit applications using a small set of standard > libraries to run on an otherwise i386 installation, and allow 64-bit > applications to be built. I would love that. I admin some bioinformatics clusters, and some phylogenetics (tree-of-life reconstruction) programs use tree data structures full of pointers that, with gcc-3.3, are faster in 32bit mode than 64bit mode. (It would really kick ass if AMD64 had a mode with the extra registers, but 32bit pointers. Then pointer-heavy data structures would be faster.) Anyway, being able to easily compile in 32 or 64bit and benchmark would be very useful. Also, I wouldn't have to statically link 64bit binaries that are faster in 64bit mode, and users wouldn't have to deal with the chroot. (not that it's much trouble with dchroot :) So, for me (and my ~dozen users) at least, this really would be useful. If you can't get it into sarge, I don't mind tracking unstable for some packages on the cluster (it's not quite what some would call a "production" system). It would rock to have it in sarge :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: RFC: Adding minimal amd64/biarch support for sarge
On Thu, Aug 05, 2004 at 02:29:12PM +0200, Goswin von Brederlow wrote: > It won't use the extra registers in 32bit mode. Yeah, I know there's no CPU mode that does that. I wish, though... > It would be > theoretically possible to build for 64bit (with extra registers) but > 32bit pointers [The Tru64 cc can do that on alpha] but it would > require extending the pointers to 64bit on every use and would > probably void all the speedup. Yeah. What if you mmap a memory pool below 2GB in virtual address space, so you only have to zero-extend? Isn't that what AMD64 does when you do a 32bit move from memory to register? gcc -mcmodel=small still uses 64bit pointers though, because it doesn't constrain data to be in the low 2GB. > One thing you could do with gcc to emulate this is to use an array > index instead of a pointer. That's a thought. There are lots of ways to store trees, and data structures with 64bit pointers could be avoided to cut down on cache traffic. > > So, for me (and my ~dozen users) at least, this really would be useful. If > > you can't get it into sarge, I don't mind tracking unstable for some > > packages on the cluster (it's not quite what some would call a "production" > > system). It would rock to have it in sarge :) > > The progress looks good. I have made an amd64-libs package with some > patches from Daniel Jacobowitz and he has made a gcc-3.4 package. Now > if I get thekernel-image-amd64 build and all of them through new in > time you have the 32/64 bit support. Your work (and all amd64 porters') is much appreciated. happy hacking :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: New kernel flavour names
On Wed, Aug 11, 2004 at 04:48:43PM +0200, Christoph Hellwig wrote: > > Now, if you have a better name for the "intel xeon e64mt nocona" kernel > > flavour (preferably something as short as k8 or k8-smp), feel free to > > propose it. > > Given that it's just a P4 core with 64bit extentions I'd call it -p4 and > -p4-smp Good idea. I think that makes a lot of sense. It doesn't say it's a 64bit kernel, but that's what arch fields in packages are for, so it doesn't have to, right? -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Problems etc. when installing pure64
On Wed, Aug 11, 2004 at 03:48:41PM +0200, Philipp Frauenfelder wrote: > - I have the following graphics card: > > :01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX > 5200] (rev a1) (prog-if 00 [VGA]) > Subsystem: LeadTek Research Inc.: Unknown device 53c3 > Flags: bus master, 66MHz, medium devsel, latency 248, IRQ 16 > Memory at fb00 (32-bit, non-prefetchable) [size=16M] > Memory at f000 (32-bit, prefetchable) [size=128M] > Expansion ROM at faf0 [disabled] [size=128K] > Capabilities: [60] Power Management version 2 > Capabilities: [44] AGP version 3.0 > > and a "Eizo FlexScan L767" with a DVI cable. The monitor only > showed green or purple or blue snow instead of a gdm login > screen after installing xserver-xfree86. I had to install the > binary driver from NVidia to get a usable picture under X. The > text console worked from the beginning. I recently helped someone at work set up a (P4 w/HT) laptop with the mobile version of that video hardware. Even on i386, I saw pretty much the same messed up graphics with the "nv" driver. The binary-only crap worked (and without as much hassle because it was i386). Other people have reported this with i386 laptops, too. It seems that the current state of the art in desktop vid hardware with Free drivers is the Radeon 9200 :/ Stupid ATI making closed HW now too :( -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: gcc-3.4 ready?
On Wed, Aug 11, 2004 at 12:08:38PM +0200, Harald Dunkel wrote: > > You should mention the sources.list for this. AFAIK its > > deb http://debian-amd64.alioth.debian.org/gcc-3.4/ unstable main non-free > contrib > deb-src http://debian-amd64.alioth.debian.org/gcc-3.4/ unstable main > non-free contrib > I just spent several hours installing pure64 gcc-3.4 onto a dual Opteron workstation (Tyan S2882, 6GB of RAM[1] :). This is for use by a not-very-hackerly user, but he'll be able to ask me for help if anything breaks. I left a partition for a sarge i386 dual boot, which I haven't set up yet. A few gcc-3.4 bumps along the way: I used the daily-built sid-amd64-monolithic.iso from Alioth. Besides not doing a very good job of letting me partition and set up RAID1 + LVM, it still doesn't tell debootstrap all the packages it needs. What finally worked was debootstrap --include=libstdc++6,gcc-3.4-base,libgnutls11 sarge /target http://debian-amd64.alioth.debian.org/gcc-3.4/ exim-daemon-light depends on libgnutls11 in the gcc-3.4 archive, but debootstrap is still pulling in libgnutls10. Fortunately, I didn't have any trouble with GRUB. Now it's installed, and I've come across some more interesting things: ia32-libs and libc6-i386 both contain /lib/ld-linux.so.2. What's the difference between ia32-libs-dev and libc6-i386-dev, and which one should I use? Hmm, libc6-i386 Replaces: ia32-libs, but it doesn't Conflicts:. Not good. [1]Anyone know what the BIOS setting IOMMU Absolute vs. Best Fit modes are? And which MTRR setting does Linux like better: Discrete or Continuous (continuous mean it has an uncachable region for the PCI hole, instead of just leaving it out of the MTRR altogether). -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Cinelerra compilation and linking
On Wed, Aug 25, 2004 at 10:25:12AM +0200, Piotr Kopszak wrote: > Good morning, > > Slightly off-topic, but I hope someone might be interested. I was > compiling yesterday the fresh new version of cinelerra 1.2.1 using > only the tools and libraries available with debian-amd64 port. It went > fine, so I guess all the object files are OK, but failed on > linking. Here is what I got: > > ../../freetype-2.1.4/x86_64/libfreetype.a: file not recognized: File > format not recognized > collect2: ld returned 1 exit status > make[3]: *** [../x86_64/titler.plugin] Bd 1 Well, what kind of file is it? Run file(1) on it. Other than that, I have no idea what the problem might be. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Compiler opt
On Sat, Aug 28, 2004 at 02:32:16PM -0700, Karl Hegbloom wrote: > [ I am subscribed to the list; there is no reason to Cc. ] > > On Sat, 2004-08-28 at 20:25 +0100, Paul Brook wrote: > > On Saturday 28 August 2004 19:55, Karl Hegbloom wrote: > > > On Sat, 2004-08-28 at 12:11 +0200, Sebastian Steinlechner wrote: > > > > On Sat, 2004-08-28 at 02:22, Karl Hegbloom wrote: > > > > > How do I determine the default compiler optimization settings? I'm > > > > > wonder if it will be worth while to try and recompile things like > > > > > python2.3 and python2.3-numeric with '-m64'? Or is '-m64' already the > > > > > default? > > > > > > > > If you're compiling on pure64, then you'll get 64-bit ELFs/libs (so -m64 > > > > is the default). > > > > > > Ok. So then -m64 implies -march=k8 ? > > > > No, but also we want binaries to work on Intel em64t cpus (right?). Using > > -march=k8 would prevent this (by potential use of 3dnow instructions). > > Ok, so, at least potentially, recompiling things like libc6, refblas3, > atlas3-base, and linpack3 with '-march=k8 -O3' could provide faster run > times for maths code? Yes. For some programs (as opposed to libraries) you could compile with -ffast-math. Not a good idea for libraries, because you don't want non-IEEE math in libraries that could be used by any program... For best results, compile once with -fprofile-generate, and then again with -fprofile-use. gcc will add code to keep track of which branches are usually taken, and which aren't, etc. Then you run the program with some representative input data. Then gcc will use the profile data to make better code when you compile again. To do this for compiling a Debian package, I found I had to remove stamp-configure and rebuild the whole package; It wasn't very convenient :( > Is it correct that both em64t and amd64 have sse2? Yes. Pentium4 has always had SSE2. Opteron and Athlon64 have always had SSE2 (unlike 32bit Athlon XP). SSE2 is vector/scalar double-precision floating point using the xmm registers. (as opposed to the x87 FP stack). SSE1 is single precision, and was introduced with the Pentium3. BTW, 3DNow was AMD's inferior (non-IEEE compliant) answer to SSE1. Short answer: SSE math is better. The FP stack sucks. > What exactly does -m64 buy me? > > Without -march=k8, does it only use the legacy i386 register set and > instructions, or does -m64 cause it to use them? -m64 makes it use them. -march=k8 can be used with -m32 or with the (default) -m64 to get gcc to tune the code for an Opteron/Athlon64, with its pipeline, rather than P4's longer pipeline. It also turns on support for all the instruction sets the CPU supports (i.e. everything P4 supports except sse3 (and I don't know what that is), plus 3dnow/extended 3dnow.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: newbie
On Tue, Aug 31, 2004 at 02:05:48PM +0200, Sythos wrote: > On Tue, Aug 31, 2004 at 01:26:07PM +0200, Thomas J. Zeeman wrote: > > > If I install amd64 port can I execute old i386 apps? > > Yes. See the AMD64 FAQ/HOWTO on the ports page for more info. > > The chroot is the only solution or in a little future there is a > pissibility to run i386 apps in general enviroment? You can run i386 stuff. E.g. readseq is broken on amd64 (pure64 gcc 3.4), so I copied /usr/bin/readseq from i386 Debian on another machine to /usr/local/bin. I had to put the libraries from libncbi6 in /usr/lib/i486-linux, since there doesn't seem to be a place in /usr/local for ia32 libs. :( Programs that only use libc and libm will work with libc6-i386 (you need that for /lib/ld-linux.so.2, too). Statically linked programs are of course fine. BTW, is there a way to use different ld.so.conf setups for ia32 and amd64? ldconfig has an option to use a different cache. I guess I'd have to binary edit or recompile ld.so to use the alternate cache. (or is there an env var?) (Too bad my new favourite hex editor hte isn't available on AMD64 :( -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: why "m32" in 'configuring kernel'?
On Sat, Sep 04, 2004 at 12:29:56AM +0200, Sythos wrote: > I'm reading amd64 howto and I don't understand why in end section about > kernel configuration the FAQ say: > > [cut] > Configuring the kernel > > make HOSTCC="gcc -m32" ARCH="x86_64" menuconfig > > Be sure to include IA32 emulation, otherwise you will not be able to run > multiarch or i386 binaries on your host system or in a chroot. And for > simplicity, build a monolithic kernel without any modules. > > make HOSTCC="gcc -m32" ARCH="x86_64" bzImage > [cut] > > why "m32" and not "m64"? because you're cross compiling. If you're doing this on a pure64 system, you don't need to specify ARCH or HOSTCC. If you're running a 32bit kernel, you can't run 64bit binaries. So programs that have to run during the build process (like programs that do the menuconfig dialogs) have to be 32bit. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: amd64 installation images
On Tue, Sep 07, 2004 at 04:38:00PM +0200, Goswin von Brederlow wrote: > > If I get the idea correctly, this is what happens basically: > > 1) kernel and initrd get loaded > > 2) modules from initrd are loaded as far as they are needed to get > > additional software (packages, modules) from the net. > > Additional software is called a "component" afaik. Those are the > udebs. Some components contain kernel modules like the disk drivers, > others the programs to partition the disk or install base. > > 3) the installer starts and loads any modules needed to do the > > install (SCSI/SATA/PATA/whatever drivers primarily) from the net > > Actualy it installs the extra components containing the kernel modules > and then a component with the full discover data file that then also > runs discover again with all modules present. Ok, so one of the components needs to contain 3ware 9xxx drivers, as well as 7/8xxx. The head node of my cluster, which should be arriving RSN, has all its disks connected to the 3ware card. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Do I need 64Bit if RAM is more than 4 GB?
On Tue, Sep 07, 2004 at 09:24:31PM +0200, Dirk H. Schulz wrote: > Hi folks, > > I hope this is the right place for this kind of question: > > I want to run a server with more than 4 GB of RAM. I do not need > applications/processes to address more than 4 GB each. Let's say I want to > have 2 instances of apache on the machine, and each instance should address > a max of 4 GB. > > Do I need a 64Bit Linux then? Or can I install a 32Bit Linux on a Server > with 8 GB RAM, set up my 2 instances of apache, and that`s it? > > Sorry for that kind of basic question but I did not find any docs on that > googling around. Ok, here are your options: 32bit kernel, 32bit user space: Each process gets 3GB of virtual address space. The kernel can divvy that up however it wants. You'll need to enable highmem support for that. If CPU performance isn't your bottleneck, it won't matter that you don't get to use the extra registers. You lose maybe 15% CPU performance, depending on what you're doing. (Compare SPEC scores breakdowns for AMD's submission, if you're curious.) This will be the most stable configuration, because you can just install i386 Sarge, and forget all about 64bit. (Yes, Opterons support PAE and all that's needed for a 32bit kernel to use lots of RAM.) The kernel has to use bounce buffers to move data around, because it can't map all the memory. The kernel uses the remaining 1GB of virtual address space for itself, and maps all the RAM it can. What's left is highmem. 64bit kernel, 32bit userspace: Each process gets 4GB of virtual address space. Disadvantage: you need a module-init-tools, iptables, and so on that can talk to the kernel. All the normal system calls by 32bit programs go through a translation layer (not much overhead, don't worry) so you can boot a 64bit kernel with root=/dev/path-to-i386-Sarge. You can install some 64bit libraries, or make some statically linked binaries, so you can run a few things 64bit. statically linked AMD64 iptables might be the best way to go. (you can debootstrap a 64bit chroot so you can apt-get install the stuff you need... Use dchroot to make your chroot convenient). The ia32->amd64 kernel translation layer works well, so while it might not be as stable as a fully i386 system, and you have to worry about special kernel interfaces that don't get 32bit translated, you don't have to worry about bugs in userspace programs like storing a pointer in an int variable. On an SMP system, the kernel will know about NUMA and be able to allocate memory that's attached to the CPU the requesting process is running on. 64bit kernel, 64bit userspace: Each process gets 64bit virtual address space. Same as above, but you have to worry about user-space too. Not all packages are available, and some of them have bugs because they truncate pointers to 32bits in some places. Just all around less stable still, not to mention that AMD64 Debian might not release with sarge, so security updates won't come from security.debian.org. You can install libraries so that you can run i386 binaries if you have any binary-only programs. (32bit code can't link to 64bit code at all, ever, on amd64. (not counting special translation layers like the kernel-userspace boundary).) 3D acceleration is only possible with 64/64 kernel/user, or 32/32, if that matters to you. 32bit kernel, 64bit userspace: not possible. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Success report: installing pure64 on a dell poweredge 1850
On Wed, Sep 08, 2004 at 02:32:43AM -0500, Ron Johnson wrote: > On Tue, 2004-09-07 at 23:16 -0700, Karl Hegbloom wrote: > > Apparently the 2.8GHz nocona is slower than the 1.8GHz Opteron. > > Intel got a lot of "DEC" engineers when it bought the Alpha from > Compaq. Maybe they couldn't stand the thought of working for The > Evil Empire, and joined the Rebellion? Does gcc support -m64 -march=pentium4? Maybe that would help. Code tuned for an Opteron might well be dog-slow on Nocona. I noticed that most of the benchmarks were faster on the nocona with -m32 instead of 64. The LU decomposition was almost a factor of 2, and that's not really a synthetic benchmark! -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: mplayer e w32codecs
On Wed, Sep 08, 2004 at 12:37:14PM +0200, Sythos wrote: > On Wed, Sep 08, 2004 at 12:09:06PM +0200, Zoltan Varga wrote: > >You can run mplayer inside an ia32 chroot. It works for me. > > Zoltan Is video scaling accelerated, or is it like 3D where the client has to match the server? Run 64 and 32bit xvinfo and compare the outputs... > too much simple in this way :) > > I want to view mplayer decode a DVD or Divx, write how can do this and > share info. Only 64bit is better than 32bit chroot You can watch a DVD on i386 Debian without any non-free software, right? (not with mplayer, but with ogle or xine). -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Don't see much difference between i386 vs amd64
On Wed, Sep 08, 2004 at 12:37:22PM -0400, Mario Bertrand wrote: > Hi, > > I have successfully install debian with sid-amd64-monolithic.iso on my > second ide (+kernel 2.6.8-3) and I don't see much difference in the > performance vs i386 sarge (+kernel 2.6.8-1) on my first ide. It is > normal? Should I expect more? Someone told me that I should buy a new > hard drive with more cache (8M) to take benefit of faster cpu. If you have plenty of RAM (1GB), the OS won't need to keep loading programs from disk all the time while they're running, because they won't get dropped from the cache. If whatever you're doing ends up waiting for the slow disk very often, getting a faster one will help you. > > hda - 2048k cache - 3923.96 BogoMIPS / i386 > hdb - 69k cache - 3932.16""/ amd64 Try a benchmark instead of an idle-loop calibrator: $ time bc -l ... scale=1000 4*a(1) quit look at user time, not real time, if you type in the commands by hand. IIRC, with some larger precision (scale=...), it's faster by 22s vs. 18s on an Opteron 240. (gcc-3.3 pure64 vs. i386 RedHat 9.) bonnie++ is a decent disk/filesystem benchmark -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: video card ?
On Mon, Sep 06, 2004 at 01:31:12PM +0200, Kaare Hviid wrote: > today even the lowly Matrox G550 requires a binary > IA32 HAL driver - and that at the price that DGA won't work. My G450 does 2D and 3D with Free software only. It's not fast 3D, but it's enough to play Armagettron on a PIII 500MHz :) A colleague at work has a workstation with a Tyan-S2882, and he's using just the on-board 8MB ATI Rage XL. It's pretty slow even on 2D, though. gnome-terminal scrolls noticeable slowly (especially scrolling backwards, like going back one line in less). xterm is super-fast, though. I don't know why, so I just un-installed gnome-terminal to make sure he wouldn't end up with a slow terminal. > Today, I'm using the Radeon 9800 that came with my Athlon 64 box. > No 3D, no TV-out, no TV-tuner support - but with one of those jet > engines. So, is there anything out there running smoothly on AMD64 > without power drain and without noise pollution? I would be surprised if an old Matrox or ATI AGP (or even PCI) card was not good enough. My Matrox G450 can keep up with gnome-terminal just fine on a PIII 500MHz :) Of course, you'll only get VGA, not DVI, outputs. The Matrox drivers won't do DRI 3D if there's not enough RAM left over after the framebuffer, though. An 8MB G200 can do 3D in 800x600x24, but not 1024x768x24. (My 16MB G450 can). The drivers for all these old cards are 100% Free, so even though I haven't used them in an AMD64, I wouldn't expect problems. I've never even tried to use the mga_hal proprietary stuff. Even without it, video colorspace conversion and scaling is accelerated enough watching movies on a PIII 500MHz. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Floppies for amd64 ?
On Tue, Sep 07, 2004 at 05:21:12PM -0400, Lennart Sorensen wrote: > On Tue, Sep 07, 2004 at 10:17:19PM +0200, Michelle Konzack wrote: > > The Switch make only GBit not 10/100 > > Hmm, OK, I thought they all did 10/100/1000. me too. Managed switches can have their port speed locked at Gb full duplex, though. > > I have installed lilo_22.5.9-3.0.0.1.amd64_and64.deb > > Well no idea about lilo. Yeah, I think a lot of people use GRUB. except for the big-RAM problem, (which is fixed now), grub has no trouble booting 64bit kernels. > > I have tried it with one memory Module (2 GByte) and it does not work. > > The Kernel does not find the second CPU > > I think the athlon 64 needs ram connected to every cpu. No. > It would > certainly work best that way. Yes. The bandwidth over the HT link is high enough, but you lose Opteron's latency advantage. Ram on the other CPU has similar latency to an Athlon going through a chipset. :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Installing on a dual Opteron with root on 3Ware 9500
On Tue, Sep 14, 2004 at 09:08:04PM +0200, Harald Dunkel wrote: > In The Night wrote: > >Hmmm > >I've tried that. > >I've tried mkinitrd -r /dev/sdb1 too... > > > >The problem seems to be me having root on a SATA-drive > > > > mkinitrd fails to find the sata driver necessary to mount > your root disk. See > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=263169 I just ran into that problem myself installing i386 Sarge on a dual Opteron (Tyan S2881) with a 3Ware 9500 SATA RAID controller. BTW, my 3Ware card is on a PCI riser with an EEPro 10/100. How can I tell if that's slowing down the PCI-X bus for the 3Ware card? It might be better to have one of those on the other PCI-X slot, but I don't want to slow down the PCI-X slot that the dual tg3 ethernet is on... Can anyone tell me anything useful? TIA. > Workaround is to add your sata driver to /etc/mkinitrd/modules > and rebuild the initrd. Yeah, from a shell on another console in debian-installer, I had to manually add 3w_9xxx to /etc/mkinitrd/modules and run mkinitrd -o /boot/initrd.img-2.6.8-1-k7-smp 2.6.8-1-k7-smp (It wasn't working at first; It was generating an empty output file. I think that was when I had 3w-9xxx, instead of 3w_9xxx in the modules file. It mkinitrd didn't give any error messages, it just made an empty initrd.) I'm glad you mentioned this, otherwise I don't know how long it would have taken me to figure out why the initrd wasn't doing its job, since I mounted it loopback and saw that it included 3w_9xxx.ko, IIRC. No wonder I always like to build my own kernel that includes critical drivers built-in... I'll have to do that anyway to get 3w_9xxx support in a 2.4 openMosix kernel. (It'll rock when they get oM ported to 2.6 and AMD64 :) > What I _really_ do not understand is why this is not seen > as a serious problem. Yeah, I think it's serious. It certainly took a lot longer to get this sorted out and finish installing i386 Sarge on a 3Ware 9xxx card than on IDE hardware I've done it on. Oh yeah, I said I was going to post info about installer support for 3Ware 9xxx cards: pure64 netboot 20040915: yes i386 netboot 20040916: yes[1] i386 pxeboot rc1: no presumably the CD versions would be the same. When PXE booting, debian-installer downloads some components from a Debian mirror, so you have to tell it you want to install unstable for it to find the kernel modules that match the kernel. You can go back and re-do the mirror selection question and select testing after it downloads the kernel modules and installer components. (And you don't need to be in "expert" mode. You just have to "Go Back" after downloading the modules fails, and it won't skip any questions this time.) [1] linux26 image only. Hangs when booting on Tyan boards unless you set the BIOS to ACPI 2.0: no, or Multimedia timer: no. Either of these makes Linux not find the HPET timer. When it does use the HPET, it hangs while "Calibrating delay loop..." (without printing bogomips, so I think it actually hangs while calibrating, not after.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: Do you know this mirror?
On Wed, Sep 22, 2004 at 05:43:51PM +0900, Kim Dong-ju wrote: > so we sync http://bach.hpc2n.umu.se/pure64 using rsync. Speaking of which, the Packages.gz files for the gcc-3.4/testing repository on bach.hpc2n.umu.se are 20bytes (i.e. a gzip of an empty file). The uncompressed versions are right, but apt-get goes for the compressed. debian-amd64.alioth.debian.org doesn't even resolve in DNS right now, from my home ISP or from dal.ca. Thanks, -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
