i have just recently installed suse 9.1 on my new amd64 machine, and
eventually found out that i would need the latest orinoco drivers (>=
0.15rc1) in order to use my card on this machine which currently after
the YasT updates is only running 0.13. I am having problems compiling
the modules for reasons i think are specific to suse, here is a
rundown of the errors produced:
Makefile:56: *** PCMCIA_CS must be defined to overwrite old drivers. Stop.
## after this i installed the source for the pcmcia package, and
directed the Makefile to the directory and ran make again.
Makefile:51: *** Can't cope with 2.6 and pcmcia-cs together. Stop.
I know this is somewhat out of the scope of this list but i thought i
might try seeing as how these newer drivers fix bugs with 64bit OS.
Any help is very very much appreciated. thanks!
thank you to all of you for your answers.
Actually, I tried Carl's approach, but it didn't work for me :(
I am still not able to enter X, because the X-Server tells me
it doesn't find the device. That's pretty weird since it's the
latest drivers and yast/sax2 is able to find the PCIe-device. Probably,
it's a problem with this special graphics chipset, because it's
not the high end one, but the low end version Geforce 6200.
The Patch CD_RC3 does something weird, it installs pretty fine
through yast and through it's bootup installer, but it destroys
the kernel. When I reboot my pc, the reiserfs.ko isn't found anymore
and the system stopps booting.
So, I'll going to try the approch with recompiling the xorg.
I don't need any 3D-enhancement, but I need just 1024x768 ;)
Hopefully, that works.
From: Carl Zeilon [mailto:email@example.com]
Sent: Wednesday, March 02, 2005 3:27 PM
To: Hänel Matthias; 'suse-amd64(a)suse.com'
Subject: Re: [suse-amd64] SuSE 9.2 AMD64 installation
At 03:26 AM 3/2/2005, you wrote:
>we bought a brand new AMD64-PC with a AMD64 3200, ASUS A8V-E Deluxe and a
>Geforce 6200 (MSI NX 6200)
>with 1 GBytes of RAM a Seagate SATA 160 GB harddrive. Actually, we ran into
>problems while installation.
>First we were trying with the DVD-Installation (Manual, Install, Install
>without ACPI, Install safe) the results are
>always the same. The systems locks up with a beep directly after yast is
>initialized but not started. Therefore
>we were trying a real old PCI graphics controller with S3 chipset and we
>the same lockup.
>Then I read here on the list there is a patch CD that solves these SATA
>problems. Today we tried this new installation
>CD (Patch_CD_RC3). Actually we got no new results, always this lockup right
>before yast is starting. So,we tried to
>disable USB, Firewire, ACPI in the BIOS with no significant result. No ACPI
>results in "normal installation" locks
>earlier but installation with "noacpi" still locks before yast. Actually,
>tried SUSE 9.1 (64) with the same result. The last
>test we did was an installation of a pretty old dist (SUSE 8.0 32-Bit) to
>prove the hardware. This test was successfully.
>That means the hardware works properly but not with newer distributions.
>Does anyone realized some problems like this? Is there a solution for this
>Thank you in advance.
>with best regards
I will relate some great advice I received from John Storrs on this list &
add some of my own comments:
"This is a known problem, due to a bug in XOrg PCI-Express code in the SuSE
distribution. I've just worked around it, with help from Andreas on this
(thread 9.2 AMD64 Install CD with New Kernel - see most recent postings) and
from postings to the Nvidia Linux Forum (thread Cursor missing and/or
icon, AMD64/PCIe/FC3/6629). See
https://bugs.freedesktop.org/show_bug.cgi?id=2322 for details of the bug.
The lockup occurs (I think) when YaST attempts to start the xorg vga driver,
which excites the bug. The workaround, as Andreas advised, is to do a text
mode install. When the linuxrc screen shows on bootup, press F2 and select
'Text Mode'. **Configure the default run level to 3** (no X) or you'll have
problems later. I installed from the SuSE 9.2 DVD (I didn't find that
Andreas' CD with New Kernel helped with this bug).
I got the latest NVidia graphics driver from www.nvidia.com (might be on
Andreas' CD too). I dealt with this install entirely off-line, so I had to
download the driver on another system and put it on a CD to transfer and
install it. Now the tricky bit. You need an /etc/X11/xorg.conf with the
default 'Device' entry using the new 'nvidia' driver, with the options:
Option "SWCursor" "on"
Option "NoRenderExtension" "on"
This is difficult to achieve because of the bug. **I did it by running
0=vga' (that's zero=vga) to get an initial xorg.conf (don't let the graphics
test run, or the system will lock up).** I edited /etc/X11/xorg.conf,
'vga' to 'nvidia', and adding the options shown above. I then daringly did
'init 5' to start X. That gave me a viable X display and KDE, and I could
YaST from the KDE menu to improve the graphics configuration. Finally
I dealt with the large bootup console font by editing /boot/grub/menu.lst:
replace "console=tty0" with "vga=0x31a". "
Press F2 & do a text install.
Set run level to 3 (you can also type "3" as a boot argument if you miss
Use YaST (text mode) to get "Kernel Sources" & "gcc" which are necessary
for the Nvidia driver.
I updated my system using YaST online update at this point.
Download the latest Nvidia driver on another machine & copy to a CD.
Copy the driver to your new box & install the Nvidia driver with sh command.
Run "sax2 -m 0=vga" (that's zero=vga) & finalize. Do Not Test!
Edit your etc/X11/xorg.conf file. Under "Device", change "vga" to "nvidia"
Option "SWCursor" "on"
Option "NoRenderExtension" "on"
Now you can switch to run level 5 & cross your fingers.
Using the "vesa, nv, or the YaST nvidia driver for graphics all resulted in
a locked machine.
Be sure to only start X when using "vga" or "nvidia".
It took me many, many tries to get this right - don't give up. email if
you get stuck.
Good luck, Carl
we bought a brand new AMD64-PC with a AMD64 3200, ASUS A8V-E Deluxe and a
Geforce 6200 (MSI NX 6200)
with 1 GBytes of RAM a Seagate SATA 160 GB harddrive. Actually, we ran into
problems while installation.
First we were trying with the DVD-Installation (Manual, Install, Install
without ACPI, Install safe) the results are
always the same. The systems locks up with a beep directly after yast is
initialized but not started. Therefore
we were trying a real old PCI graphics controller with S3 chipset and we got
the same lockup.
Then I read here on the list there is a patch CD that solves these SATA
problems. Today we tried this new installation
CD (Patch_CD_RC3). Actually we got no new results, always this lockup right
before yast is starting. So,we tried to
disable USB, Firewire, ACPI in the BIOS with no significant result. No ACPI
results in "normal installation" locks
earlier but installation with "noacpi" still locks before yast. Actually, we
tried SUSE 9.1 (64) with the same result. The last
test we did was an installation of a pretty old dist (SUSE 8.0 32-Bit) to
prove the hardware. This test was successfully.
That means the hardware works properly but not with newer distributions.
Does anyone realized some problems like this? Is there a solution for this
Thank you in advance.
with best regards
I have a HP PSC950 all-in-one device attached to my clean SuSe 9.2
installation. Setup of the printer part was easy, but the scanner is not
recognized. If I do a scanimage -L as root I get the following message:
No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).
If I look in /var/log/messages I find the follwing entries:
Mar 1 19:12:07 neo scanimage: resmgr: server response code 501
Mar 1 19:12:07 neo scanimage: resmgr: server response code 502
Mar 1 19:12:07 neo last message repeated 8 times
Mar 1 19:12:07 neo scanimage: resmgr: server response code 200
Does anyone know whats wrong?
I have installed the following packages:
I've been using the amd64 suse destro's since 9, and I have in that time
come across a number of issues with default configure/build scripts not
picking up the 64 suffix of various libraries scattered across the
system. If all configure/build scripts contained the enable libsuffix
option this wouldn't be a problem, but not all of them do...
One of the ugly hacks I use to get around this is to mv the lib dir of
whatever library is not being picked up to lib32 and then symlink lib to
lib64 for the duration of the build... this is ugly but the only way to
get around this issue.
My request is that libraries be layed out so that all 32bit libs contain
the suffix 32 so for instance qt3 resides in /usr/lib64/qt3/ (actually
it's a symlink but it doesn't matter) and contains a lib and a lib64 dir
within that directory (this is the same for a number of libraries), if
you are trying to compile an app which doesn't pick up the llib64 dir as
the correct one it will fail...
In this case what would happen is that /usr/lib64/qt3/lib would
become /usr/lib64/qt3/lib32 and a symlink to lib would exist to the
correct library set for the parent /usr/lib64 (i.e lib would point to
lib64 in this case).... This would resolve alot of issues...
It's not a trivial thing... but I think would greatly improve the
usability of suse as a build environment.
Implementation wise i'm open to suggestions.. but consider this a formal
request out of hours of fiddling with library parths to get joe random
thing to compile...
I compiled kmplayer 0.8.4a with "./configure --enable-libsuffix=64" and it worked.I get the same warning messages but not the error.
I can see nothing wrong with you output. (-I/usr/lib/qt3/include is correct since /usr/lib64/qt3 is linked against /usr/lib/qt3).
Try again with fresh source code but besides that I'm out of suggestions.
(My "mplayer -vo help" gives: xv, x11, xover, gl, gl2, dga, sdl, fbdev, fbdev2, aa, directfb, dfbmga, null, mpegpes, yuv4mpeg, png, jpeg, gif89a, tga, pnm, md5sum.
Maybe that could be of help)
On 25.2 2005 02:07, David wrote:
>Thanks for the input Arne. I used the
>--with-x11libdir=/usr/X11/lib64 switch and MPlayer compiled and worked just
>fine. I agree on KMplayer. I have tried a couple of time to compile it and have
>not gotten anywhere. Is this the way you are suggesting I try?
>I gave that a go and the configure worked fine. When I tried make I got
>/bin/sh ../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H
>-I. -I. -I.. -I/opt/kde3/include/kio -I/opt/kde3/include
>-I/usr/lib/qt3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT
>-D_REENTRANT -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi
>-D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align
>-Wconversion-Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings
>-O2 -Wformat-security -Wmissing-format-attribute -fno-exceptions
>-fno-check-new -fno-common -c -o kmplayerconfig.lo `test -f
>'kmplayerconfig.cpp' || echo './'`kmplayerconfig.cpp
>In file included from kmplayersource.h:28,
> from kmplayerconfig.cpp:45:
>kmplayerplaylist.h:143: warning: `inline' is not at beginning of declaration
>In file included from kmplayerpartbase.h:33,
> from kmplayerconfig.cpp:47:
>kmplayerprocess.h:158: warning: `visibility' attribute does not apply to
>kmplayerconfig.cpp:87: error: visibility arg must be one of "default",
> "hidden", "protected" or "internal"
>make: *** [kmplayerconfig.lo] Error 1
>make: Leaving directory `/home/david/program-files/kmplayer-0.8.4a/src'
>make: *** [all-recursive] Error 1
>make: Leaving directory `/home/david/program-files/kmplayer-0.8.4a'
>make: *** [all] Error 2
>I believe I have everything I need but nogo. Any tips? I won't be able
>to do much until the weekend so any advice will be appreciated.
>I am kind of new to SuSE only a few months experience. If I use this
>mv /usr/X11/lib /usr/X11/lib32
>ln -s /usr/X11/lib64 /usr/X11/lib
>configure and make.
>ln -s /usr/X11/lib32 /usr/X11/lib
>Will there be any future issues when I try to compile things?
Gratis svenskpråkig e-post och förmånliga textmeddelanden
I tried to configure it again but with a different monitor. This time
it worked on
a Samsung SyncMaster 712n. The first monitor that it failed on is a
Sony SDM-HX73. I still have no clue why it didn't work but it will try
again. I had to make it work though.
I also had to enter the Display size of 340mm x 270mm manually. I'll
post again when I try the Sony.
Jose Luis Ricardo Chavez wrote:
> David, look for the horizontal and vertical refresh rates in the
> monitor's manual and
> put them in the /etc/X11/xorg.conf file, entries HorizSync and
> VertRefresh. See what
> happens. If it does not work then look at the specifications of the
> graphics card, if it
> supports the 1280x1024 mode but if the required refresh rate is out of
> the monitor's
> range, it will not work. Hopefully the graphics card supports the
> 1280x1024 mode at
> several refresh rates. For instance, mine's support 1280x1024 at 85
> Hz, 75 Hz, 70 Hz
> and 60 Hz. On Windows I can use all these modes but on Linux only the
> 1280x1024@75Hz mode displays correctly.
> Hope this helps.
> - Jose Luis
> David Lazanja wrote:
>> I have an NVidia GeForceFX 5200 / 256MB AGP card.
>> It's identified as NVidia 0x0322 (nv) by Yast->Graphics Card and
>> Monitor (sax2).
>> I'm using SuSE 9.2.
>> The open source driver, nv, works great.
>> I downloaded and installed the nvidia driver with YOU. It works but
>> there is one problem. It will not use the 1280x1024 native
>> resolution of my 17" flat panel. When I tried to reconfigure the
>> card, it allowed me to select the 1280x1024 resolution (and all lower
>> resolutions were chosen as well). However, when I restart the X
>> server I can only get 1280x960. This of course doesn't look so hot
>> and a flat panel that natively does 1280x1024.
>> The nv driver correctly uses the 1280x1024 res. Instead of
>> configuring with sax2, I also tried to use the original xorg.conf
>> file for the nv driver and replace "nv" by "nvidia". That still
>> didn't correct the resolution problem.
>> I wanted to know if anybody else had a similar situation with nvidia
>> and if there's a simple quick fix.
# Department of Applied Physics and Applied Mathematics
# Columbia University