openSUSE AMD64 May 2007

amd64@lists.opensuse.org

4 participants
5 discussions

[opensuse-amd64] After recompiling util-linux, "which" segfaults

by Frank Steiner

Hi, we are running SuSE 10.1/x86_64 and SLES 10/x86_64 (same issue). We need a patched version of util-linux so I first tried to recompile the util-linux.src.rpm by simply rpm -ihv .../suse/src/util-linux-2.12r-35.src.rpm rpmbuild -ba SPECS/util-linux.spec This runs through and creates a new RPM. After installing it, /usr/bin/which segfaults when called with a parameter: backus /root/rpm# /usr/bin/which Usage: /usr/bin/which [options] [--] programname [...] Options: --version, -[vV] Print version and exit successfully. --help, Print this help and exit successfully. ... backus /root/rpm# /usr/bin/which nxloadconfig Segmentation fault strace shows this: backus /root/rpm# strace -f /usr/bin/which nxloadconfig execve("/usr/bin/which", ["/usr/bin/which", "nxloadconfig"], [/* 85 vars */]) = 0 brk(0) = 0x505000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2af979b07000 uname({sys="Linux", node="backus", ...}) = 0 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=306211, ...}) = 0 mmap(NULL, 306211, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2af979b08000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\322\1\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1475924, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2af979b53000 mmap(NULL, 2289896, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2af979c09000 madvise(0x2af979c09000, 2289896, MADV_SEQUENTIAL|0x1) = 0 mprotect(0x2af979d2f000, 1048576, PROT_NONE) = 0 mmap(0x2af979e2f000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x126000) = 0x2af979e2f000 mmap(0x2af979e34000, 16616, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2af979e34000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2af979e39000 arch_prctl(ARCH_SET_FS, 0x2af979e396d0) = 0 mprotect(0x2af979e2f000, 12288, PROT_READ) = 0 munmap(0x2af979b08000, 306211) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Process 7351 detached What's wrong here? I didn't change the spec file, so how can the recompiled package behave differently? cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-amd64+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-amd64+help(a)opensuse.org

14 years, 3 months

Re: [opensuse-amd64] SATA boot order: solved

by einar_linux

It is really root=LABEL=root The syntax looks funny but it worked for me. regards, einar Constantine 'Gus' Fantanas wrote: > einar_linux wrote: >> ... >> Grub then looks: >> kernel /boot/vmlinuz root=LABEL=root bla bla bla >> > Are you sure it is not > kernel /boot/vmlinuz root=LABEL/root... (instead of > root=LABEL=root... --two equal signs around 'LABEL')? > > Thanks for the very informative posting! > > cf > --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-amd64+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-amd64+help(a)opensuse.org

14 years, 3 months

IOMMU...PCI memory hole...MTRR...I give up.

by David W. Hankins

I have an MSI K8D-Master-F motherboard with two Opteron 244's. It recently got retasked as a desktop machine due to another system's failure...I thought the little ATI Rage built into the motherboard would make more than a sufficient 2d desktop type framebuffer, and as far as other stuff inside this box... this should be a pretty kick ass, high performance workstation. But I can literally watch the screen redraw if I switch virtual desktops. Painfully slow. Thinking this was just some crippled built-in video bug, I threw in an old nVidia card we had lying around in one of the regular PCI slots. Slightly slower, if you can believe it. I think this: mtrr: type mismatch for e5000000,1000000 old: uncachable new: write-combining And of course this: $ cat /proc/mtrr reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 Has something to do with it (and may also explain why I'm getting less than stellar performance out of other PCI devices, such as the RAID array that has a 128MB memory region the driver directly reads and writes on). The above is with the nVidia PCI card inserted, the built-in ATI card would also emit a similar mtrr rejection message, just the address is different, and the system would only list 512MB uncachable without the nVidia. Also notice that there's 4GB installed in this machine, in 2 2GB DIMMs installed in one bank together. And yet the BIOS map: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000bfff0000 (usable) BIOS-e820: 00000000bfff0000 - 00000000bffff000 (ACPI data) BIOS-e820: 00000000bffff000 - 00000000c0000000 (ACPI NVS) BIOS-e820: 00000000ff7c0000 - 0000000100000000 (reserved) Lists nothing beyond the 4GB mark where that memory might reasonably have been moved to. Assuming this is just a neglectful BIOS, I tried setting 'mem=4G' and 'memmap=1G@4G' kernel options, to define the 1GB 'hole' I presume is being placed here, and which got me this added line to dmesg: user: 0000000100000000 - 0000000140000000 (usable) But still only 3GB available. To add even more insult to rising injury, I noticed while looking through dmesg that the IOMMU is being disabled. It appears the value being advertised by the CPU's: CPU 0: aperture @ 1b80000000 size 128 MB Is being rejected because it lies (WELL) above the 4GB mark. I've been going through archives and I'm not finding anything that looks like actionable advice. The latest BIOS MSI's webpage lists for this motherboard is 1.1: already installed. It has no option for 'pci hole: software'. The only options I'm finding are memory bank interleaving (which I tried disabling), and 'Disabled/Best-Fit/Absolute' settings for the IOMMU, as well as its aperture size (128M, which I might increase if it would be used rather than ignored...). One post in the archive that matched on motherboard make and model looks confused to me, because he refers to his BIOS as AWARD 2.0, but the only BIOS MSI puts out for this board is AMI (versioned 1.1). In summary what I'd like to know is: 1) Where is the 'go fast' button? re: pci video that's slower than even isa video should be (and presumably similar performance problems on other PCI devices). 2) How do I get the last 25% of my memory back? 3) How do I get the system to put the IOMMU somewhere in the range it stole under 4G (so Linux can use it)? Can Linux move this on its own accord? Thanks in advance for any and all help. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins

14 years, 3 months

[opensuse-amd64] Sound recording issue

by Majdi Jaqaman

Hello, I've had a problem that drove me nuts for a couple of weeks. The microphone works fine but recording sound had an issue. The problem I faced was that when I recorded (using KRecord) the sound will be too low and far and unclear. For a couple of weeks, I could not get my hand on the "move" that would fix it. However, every now and then I got it working. But when I reboot, or start a new session it goes back to old unclear and low sound. What drove me nuts was the fact that every time I get it working, it's after a different series of steps than the last time I did it. So for a while I was just in trial and error period. Last week I finally figured out the specific "move" or "step", which fixes the problem. What I needed to do, is open Kmix, and go to the "Switches" tab and then just shuffle the the three "Input Source" fields that I have. After I shuffle them, I bring them back to the same setup of "Mic", "Front Mic", "Line". Then it works. Note that before I did the shuffling, the three fields were in that same exact order! That's as far as I got trying to debug this issue. Has anybody faced this? I would like to know, if anybody has had this, before I dig deeper into the problem to find out what actually changes when I start a new session (and what happens when I do this shuffling). My sound card is: Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) I'm using alsa driver: Advanced Linux Sound Architecture Driver Version 1.0.12rc1. OS: openSUSE 10.2. CPU: Intel core 2 duo. 64-bit. Regards, Majdi Jaqaman ____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-amd64+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-amd64+help(a)opensuse.org

14 years, 4 months

[opensuse-amd64] this is a shell issue?

by eshsf

Hello list, I find a strange problem now. The system is openSuSE 10.2 x86-64 (2.6.18.8-0.1-default). When I was used gdb, this was generated. the following are the procedures. [foo] > ps PID TTY TIME CMD 29508 pts/5 00:00:00 bash 29545 pts/5 00:00:00 ps And switches to another terminal "bar" here. [bar] > gdb -q -p 29508 Attaching to process 29508 [...] 0x00002b9129d41200 in __read_nocancel () from /lib64/libc.so.6 (gdb) p write(1, "Hallo, SuSE\n", 12) $1 = 12 Then check the "foo" terminal. [foo] > Hallo, SuSE Ok, let's advance processing on the "bar" terminal. (gdb) c Continuing. Program exited normally. (gdb) Suddenly, the bash as "foo" exited here. I was expecting to stop at the "Continuing.". but I don't know what the cause. Does anyone know this cause? Thanks, eshsf --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-amd64+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-amd64+help(a)opensuse.org

14 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

openSUSE AMD64 May 2007