November 2003 - openSUSE AMD64 - openSUSE Mailing Lists

Panic on Opteron with 2.6 kernel and 8GB
by Peter Rundberg 08 Nov '03

08 Nov '03

Hi, When using the 2.6.0-test kernel (up to and including test9-bk11) on Opteron systems with 8GB memory I get a kernel panic during boot. I have tried this on a dual machine (Tyan Thunder K8W) and on a quad machine (AMD mainboard??), both with 8GB memory. Is this a known issue with the 2.6 kernels or is there some config option that has to be set to make it work. /peter

2 1

Re: [suse-amd64] Installation of SUSE 9.0 AMD 64 Version on latest motherboards
by John McCorquodale 07 Nov '03

07 Nov '03

> > Yes, you need the -139 kernel from > > ftp.suse.com/pub/people/aj/Kernel-AMD64/ > > to support AGP, > > to be more precise to support AGP on that Tyan board that has both > PCI-X and AGP. Near all other boards work with AGP with the default 9.0 > kernel. Although you'll probably want to run the board with < 3GB of RAM if you want to use AGP, at least in 1.01 of the BIOS. I'm seeing mediocre (~270MB/s) fast-writes (on any card) with 2GB of system RAM, and when I install 8GB of system RAM, that drops to a pathetic 30MB/s. I _should_ be seeing 2GB/s on AGP 8x. This fast-write performance probably translates into similar AGP DMA performance, 'tho I have yet to verify this. I am in slow (on my part) conversation with Tyan about this. I'm trying now to read out the 8151's config registers to see what state BIOS is leaving things in and maybe figure out what's up. Whenever a clue begins to form in my mind, I'll forward it along to the list. :) On a related topic: has anybody got DGA to work on this Tyan board, on any kernel and any graphics card? It always hangs the system for me. I'm interested in knowing what write b/w (the "b" key) people see when running /usr/X11R6/bin/dga on this board, especially on nVidia boards with this mystical 64-bit driver somebody mentioned earlier. Cheerio, -mcq

3 2

Installation of SUSE 9.0 AMD 64 Version on latest motherboards
by Graeme Docherty 06 Nov '03

06 Nov '03

Hi Can anyone who has tried, please tell me if any of the latest motherboards provide an 'out of the box' install of SUSE 9.0 AMD-64 without the need for kernel patching. Particularly looking at the MSI, Gigabye and Asus boards, running nVidia and VIA chipsets. I'm tending to lean towards the VIA chipset boards (K8T800), so any guidance would be appreciated. Regards Graeme This e-mail transmission is intended for the named addressee only. Its contents are private and confidential and should not be read, copied, disclosed or distributed to or by any other person. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone (0141 585 6363), delete the contents of this transmission, destroy any copies made and no action should be taken which places reliance on its contents. Copyright Hanon Solutions Limited. All rights reserved. No part of this communication may be reproduced without the prior written permission of Hanon Solutions Limited.

5 6

packages needed for SLES 8 AMD64
by Jasjeet Sekhon 05 Nov '03

05 Nov '03

Hi, I'm running SLES 8 AMD64 and I would like to install some packages which are not available for SLES 8 AMD64 such as xemacs, latex and ispell. Would it be a bad idea to take such packages and their dependencies from SLES 8.2 beta or Professional 9 AMD64? I don't *need* these packages, certainly not at the price of making the system unstable. As an aside, am I the only one worried about the Novell purchase of SuSE? Cheers, Jas. ====================================== Jasjeet S. Sekhon Assistant Professor Harvard University Center for Basic Research in the Social Sciences jsekhon(a)fas.harvard.edu http://jsekhon.fas.harvard.edu/ Office: 617.496.2426 Fax: 617.496.5149 ======================================

3 2

known vncserver issues?
by Jasjeet Sekhon 05 Nov '03

05 Nov '03

Hi, Does anyone know of OS stability issues related to vncserver for SLES 8? My opteron server has crashes a couple of times. Each time I was using vncserver and connecting with vncviewer (from RH 9 systems using tight compression). I'm trying to figure out if this is a hardware or software problem. The OS is up-to-date and the hardware is: Polywell 2200A Dual Opteron ATX MB w/VGA,SATA,2LAN 2xAMD Opteron Processor Model 244 (64bit-1.8GHz) 8xDDR 333MHz 512M SDRAM PC2700 Memory ECC/Register 460W Power Supply for Dual CPU 2xWD 250GB Ultra-100 IDE 7200RPM 8MB HD 3Ware 7000-2 Port IDE RAID Controller In any case, a service person will check out the machine in 24 hours.... Cheers, Jas.

2 1

RE: [suse-amd64] IFC and SUSE 9.0
by Daniel Kidger 05 Nov '03

05 Nov '03

Martyn, > I have just insatlled intel fortran compiler on SUSE 9.0 > (with x86_64 opteron). When i try and link any fortran > program I get the error > > :/root/$ ifc test.f > program TEST > > 4 Lines Compiled > ld: skipping incompatible > /opt/intel/compiler70/ia32/lib/libintrins.a when searching > for -lintrins > ld: cannot find -lintrins This is a simple one - ifc will call upon the standard linker on the Opteron, which (naturally) defaults to making 64-bit binaries. Tell it to make 32bit binaries with "-Wl,-m elf_i386" and .. hey presto - it works. viz: --- cut here -- dan@quad0:~> cat hello.f print*,"Hello World" end dan@quad0:~> ifc hello.f -Wl,-m elf_i386 main program 3 Lines Compiled dan@quad0:~> file ./a.out ./a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped dan@quad0:~> ./a.out Hello World --- cut here -- Yours, Daniel. -------------------------------------------------------------- Dr. Dan Kidger, Quadrics Ltd. daniel.kidger(a)quadrics.com One Bridewell St., Bristol, BS1 2AA, UK 0117 915 5505 ----------------------- www.quadrics.com --------------------

1 0

IFC and SUSE 9.0
by Wheeler, Dr M.D. 05 Nov '03

05 Nov '03

I have just insatlled intel fortran compiler on SUSE 9.0 (with x86_64 opteron). When i try and link any fortran program I get the error :/root/$ ifc test.f program TEST 4 Lines Compiled ld: skipping incompatible /opt/intel/compiler70/ia32/lib/libintrins.a when searching for -lintrins ld: cannot find -lintrins Does anyone know what this means?? Thanks Martyn ---------------------------------------------- Dr. Martyn D. Wheeler Department of Chemistry University of Leicester University Road Leicester, LE1 7RH, UK. Tel (office): +44 (0)116 252 3985 Tel (lab): +44 (0)116 252 2115 Fax: +44 (0)116 252 3789 Email: martyn.wheeler(a)le.ac.uk http://www.le.ac.uk/chemistry/staff/mdw10.html

1 0

Re: [suse-amd64] Tyan S2885ANRF AGP framebuffer write slowness?
by Andi Kleen 05 Nov '03

05 Nov '03

On Wed, Nov 05, 2003 at 01:03:10AM -0800, John McCorquodale wrote: > > Most likely the aperture is there and you are messing with the IOMMU > > mappings. > > Yeah, I'm investigating that now. Figuring out how to read the aperture setup > out of the 8151. I've been talking to Tyan, they don't seem to have a solid > AGP configuration picture. Look in /var/log/boot.msg The kernel reads it and prints it early in boot. There are unfortunately multiple ways to store this (latest kernel should handle all this), it can be put into any northbridge and into the AGP bridge. Windows centric BIOS put it into the AGP bridge. > > > Does it go away when you boot with iommu=memaper=2 (this will make your > > system lose some memory) > > I will try this next time I'm in my office. It's worth noting that I've tried > most ATI video cards and the bad performance results are always the same, even > with AGP110 cards ('tho the 110 gets slightly faster due presumably to the > wider datapath; it's not a factor of two 'tho). > > I'll post a big writeup of this; I'm getting it together now but it'll spill > into tomorrow (getting sleepy). > > But while I've got you here, two questions: > > 1) It couldn't be that the AGP framebuffer is getting indirected through the > IOMMU when I map it through PCI-space or something like that could it? The frame buffer is normally not redirected through the AGP aperture. AGP aperture/IOMMU is to remap multiple mainboard ram areas to a single continuous bus area as seen from the AGP/PCI side. Frame buffer is a direct mmio area pointing to memory on the card. > > 2) Any clue why Tyan's BIOS would set the AGP aperture (and surrounding > address space to uncachable in the MTRR)? Setting the AGP aperture and the PCI hole (that is around it) to uncachable is standard and ok. Write combining MTRRs are set by the OS (the Xserver on Linux) > > It's also worth noting that changing video cards around changes the size of > the entry in the MTRR: sometimes it's 512MB, sometimes it's 1GB. The "missing > memory" varies with the size of this MTRR entry. That is because they have different sized PCI resources that are mapped there. > > > Overall it sounds more like hardware/BIOS issues than a Linux problem. I > > would recommend to contact Tyan. You could also try a different video card. > > I agree that the MTRR/missing memory is probably BIOS. But how is it possible Missing memory is a probably a minor BIOS problem or maybe unavoidable depending on your memory setup. The memory controller can map a single DIMM only in a single chunk and there has to be holeless memory < 4GB (Windows among others require this). The aperture and MMIO mappings also have to be <4GB. If the BIOS is unable to map the DIMMs completely around the hole containing aperture/MMIO you will lose memory. > to misconfigure hardware to the point that mere accesses to physical address > space get so much slower? It's a bus; it's just clocked. It seems to get Using cached access on a framebuffer/aperture is normally incredible slow. Frame buffer access is best using write combining. > Still in the dark really, but that's not reason not to send a verbose message > to the list! :) Just that you did not cc it to the list... Doing that now because the explanations may be useful to others. -Andi

1 0

Tyan S2885ANRF AGP framebuffer write slowness?
by John McCorquodale 05 Nov '03

05 Nov '03

Andreas and other interested folks, I just grabbed the 2.4.21-139 kernel, built it and installed it on my Tyan S2885ANRF. It now finds the 8151 AGP controller correctly, and seems to correctly identify both AGP110 (ATI X1) and older AGP v2 cards, go into 4x/8x modes fine and the like. However, if you take video-card-of-your-choice, map its framebuffer and set the AGP bridge for fast writes, the write bandwidth to the framebuffer is BAD. About a factor of 40 slower than it should be. A 1x card writes at about 18MB/s, a 4x card at 25 and an 8x card at 48MB/s. These numbers should be 256MB/s, 1GB/s and 2GB/s. Under no circumstances (1x, fast writes off) should the bandwidth be less than 256MB/s. I've tired this on lots of 760MPX machines and get the performance I expect, but I am at a loss as to what could possibly be causing this slowness. I notice that the Tyan board sets up the MTRR for the whole PCI physical address space to be uncachable: linux:~ # cat /proc/mtrr reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 reg01: base=0xbe000000 (3040MB), size= 32MB: uncachable, count=1 In previous framebuffer drivers, I have set the MTRR for the frame buffer to be write combining, which does have an effect on performance ('tho I've never known the effect to be a factor of 40!). I'd like to do the same thing on the Tyan board, but unsetting the c0000000-ffffffff uncacheable MTRR, or fragmenting it so that everything in that region EXCEPT the framebuffer is uncacheable both quickly lead to system crasshes (why? how could caching the framebuffer hang the system in text mode (corrupt screen contents, sure)? is this a race while the region is uncacheable?) It seems there's something strange going on. Could this be some kind of IOMMU interaction? The AGP aperture ends up at e0000000, which I cover with an uncacheable MTRR entry when I try the fragments, so I don't THINK I'm hurting anything. Any ideas why it could possibly be so slow or what I might do to get it back up to reasonable write speeds? Hard to do video when you can only get 2 frames/sec into the card's RAM. Thanks! -mcq

4 5