|
:: techAdmin wrote :: ... I've actually had no reports from 173, but I assume it will fail. ...I have the 173.14.36 driver (which I patched) working with some 3.7.x kernels and Xorg 1.13.0.902. :: Code :: $ inxi -GSxxx
System: Host: mepis1 Kernel: 3.7-1.towo-siduction-686-pae i686 (32 bit, gcc: 4.7.2) Desktop: KDE 4.8.4 (Qt 4.8.2) info: plasma-desktop dm: kdm Distro: MEPIS 12.0 wheezy Graphics: Card: NVIDIA NV34 [GeForce FX 5200] bus-ID: 02:00.0 X.Org: 1.13.0.902 driver: nvidia Resolution: 1024x768@50.0hz GLX Renderer: GeForce FX 5200/AGP/SSE/3DNOW! GLX Version: 2.1.2 NVIDIA 173.14.36 Direct Rendering: Yes I've been able to get it to work with the siduction 3.7 kernel shown above and also with a antix 3.7 kernel (3.7.1-antix.3-486-smp). With the antix kermel I did need to create a version.h symlink :: Code :: ln -s /lib/modules/3.7.1-antix.3-486-smp/build/include/generated/uapi/linux/version.h /lib/modules/3.7.1-antix.3-486-smp/build/include/linux/version.hI also tried the Debian experimental 3.7 kernel (3.7-trunk-486) a couple days ago but couldn't get it to work. It threw the same kind of error as the antix kernel did without the version.h symlink (I should probably try it again, my symlink might have been wrong). It's basically a fedora patch which I got from here: download1.rpmfusion.org/nonfree/fedora/development/rawhide/source/SRPMS/nvidia-173xx-kmod-173.14.36-1.fc19.src.rpm though I did need to alter it slightly (lines 1&2, 33&34) The patch I used is shown below and also here's a dropbox link to it: dl.dropbox.com/u/18456966/3.7_kernel_173.14.36.patch :: Code ::
--- usr/src/nv/conftest.sh.orig +++ usr/src/nv/conftest.sh @@ -127,6 +127,7 @@ build_cflags() { if [ "$ARCH" = "i386" -o "$ARCH" = "x86_64" ]; then MACH_CFLAGS="$MACH_CFLAGS -I$HEADERS/asm-x86/mach-default" MACH_CFLAGS="$MACH_CFLAGS -I$SOURCES/arch/x86/include/asm/mach-default" + MACH_CFLAGS="$MACH_CFLAGS -I$HEADERS/arch/x86/include/uapi" fi if [ "$XEN_PRESENT" != "0" ]; then MACH_CFLAGS="-I$HEADERS/asm-$ARCH/mach-xen $MACH_CFLAGS" @@ -136,6 +137,7 @@ build_cflags() { if [ "$ARCH" = "i386" -o "$ARCH" = "x86_64" ]; then MACH_CFLAGS="$MACH_CFLAGS -I$HEADERS/asm-x86/mach-default" MACH_CFLAGS="$MACH_CFLAGS -I$SOURCES/arch/x86/include/asm/mach-default" + MACH_CFLAGS="$MACH_CFLAGS -I$HEADERS/arch/x86/include/uapi" fi if [ "$XEN_PRESENT" != "0" ]; then MACH_CFLAGS="-I$HEADERS/asm/mach-xen $MACH_CFLAGS" @@ -143,9 +145,12 @@ build_cflags() { fi CFLAGS="$BASE_CFLAGS $MACH_CFLAGS $OUTPUT_CFLAGS -I$HEADERS $AUTOCONF_CFLAGS" + CFLAGS="$CFLAGS -I$HEADERS -I$HEADERS/uapi" if [ "$ARCH" = "i386" -o "$ARCH" = "x86_64" ]; then - CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include -I$OUTPUT/arch/x86/include/generated" + CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include" + CFLAGS="$CFLAGS -I$OUTPUT/arch/x86/include/generated" + CFLAGS="$CFLAGS -I$OUTPUT/arch/x86/include/generated/uapi" fi if [ -n "$BUILD_PARAMS" ]; then CFLAGS="$CFLAGS -D$BUILD_PARAMS" --- usr/src/nv/nv.c.orig +++ usr/src/nv/nv.c @@ -2609,7 +2609,11 @@ int nv_kern_mmap( /* prevent the swapper from swapping it out */ /* mark the memory i/o so the buffers aren't dumped on core dumps */ +#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,7,0) + vma->vm_flags |= (VM_IO | VM_LOCKED | (VM_DONTEXPAND | VM_DONTDUMP)); +#else vma->vm_flags |= (VM_IO | VM_LOCKED | VM_RESERVED); +#endif } NV_VMA_FILE(vma) = file; < Edited by kmathern :: Jan 5, 13, 18:51 > Back to top |
|
masmys thanks for reading the help closely enough to make me realize could happen to someone who read the stuff with no other information, there just wasn't enough there, as I realized above as I started explaining it, it finally hit me in the head like a brick, stupid, usability is about not requiring users to know all this, this is my failure, not yours, so sorry about the pebkac remark.
It was particularly in reading the -k and -W thatI realized this stuff just was't clear, the thing with W is that the backstory behind that option was clear to me, and to the mepis type users who it was made for, but not to many others. Try updating sgfxi,, sgfxi -U then starting it with: sgfxi -k -f no need to be root or out of x. then read the help menu again, as I noted, i still don't like thelanguage I'm using and i dont' think it's optimally clear, but as I started poking into the core script I realized that these were actually complicated options which had just sort of been merged in during testing and dev work, to the degree I didn;t' remember how the stuff worked at all myself. Back to top |
|
kmathern, that makes sense. The link path fix is also built in, it's called before the patch itself is run.
I will add your patch for 173 in that case as well,thanks for following up. I can add the path fix to sgfxi for 173 latest, that's easy, maybe i can add that patch too I guess. Back to top |
|
:: techAdmin wrote ::
Try updating sgfxi,, sgfxi -U Was working as root and did that. Hope that it is not a problem. Here is the output: :: Code ::
# sgfxi -U Updating sgfxi now using the default server - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - sgfxi :: version: 4.20.15 :: last updated: January 5 2013 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - graphics card information: series: NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) vendor: ASUSTeK Computer Inc. ram: 256M (note: not accurate for built in graphics) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - sgfxi was successfully updated. Please start the script again to access the latest features and drivers. Remember that sgfxi always updates itself automatically when it starts so usually -U is not required. To see the latest drivers or support features, use the -L option. You can run this option in X, and you don't need to be root to use it. Features: Show all currently supported drivers: sgfxi -L d Show current nVidia support status: sgfxi -L n Show current ATI/Fglrx support status: sgfxi -L f Show current local/remote sgfxi versions: sgfxi -L v - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please hit enter to continue - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Update completed. Exiting now. :: Quote ::
then starting it with: sgfxi -k -f Got this error message: :: Code ::
# sgfxi -k -f ERROR: (166) The options (-k and -f) you used are not compatible, and create internal sgfxi conflicts. Please correct this error and start again. Exiting script now Really appreciate your efforts to redo the things to make it as user friendly as possible. [Edit] Just running sgfxi (from the console after stopping X), installed the driver by retrieving the patch et al. This is for your information. Regards. Back to top |
|
kmathern, your patch runs smoothly and without error, which is refreshing, and is now included in sgfxi for the 173.14 driver and 3.7 kernel. I ran a test and the patch works, but I did not test an actual installation.
As with the other matter in this thread, if you use sgfxi to install the driver, then you have to use -f to force the patch to happen, otherwise the nvidia installer will exit with error when it fails to find its path. Also when a driver requires such patching, all other modules will the removed. Actually, as a trick, I realized you can do this: run sgfxi -f on the 3.7 kernel. Then, assuming you have no other 3.7 kernels installed, you should be able to run: sgfxi -! 40 to build back the modules for each other kernel in the system. Note that this only works with one and only one 3.7 kernel, or any number that required a patch. If you have two, or are testing new stuff all the time, then you have to do it each kernel install until nvidia releases an updated driver which includes that simple patch in their installer, which I am sure they will do fairly soon, in fact I'm surprised it's taken as long as it has. Back to top |
|
masmys, you don't have to show output for sgfxi -U, all it does is update sgfxi to current latest. That was just so you could see the error handling on -k -f and the new -h menu changes.
Back to top |
|
The nvidia driver install stopped working for me last week. I had previously use -f install to get the beta driver to install. From last week there is no current beta and the 313.18 driver fails to install with / without the -f option. I've had to go back to manually producing the symlink then it installs OK.
:: Code :: Host/Kernel/OS "hypnos32" running Linux 3.7-6.slh.2-aptosid-686 i686 [ sidux 2010-01 Ύπνος - kde-full - (201006131622) ]
CPU Info 2x AMD Athlon 64 X2 Dual Core 5600+ 1024 KB cache flags( sse3 ht nx lm svm ) clocked at [ 1000.000 MHz ] Videocard NVIDIA GT218 [GeForce 210] X.Org 1.12.4 [ 1680x1050@60.0hz ] Network cards NVIDIA MCP55 Processes 160 | Uptime 30min | Memory 760.1/3041.9MB | HDD WDC WD3200AAKS-0,WDC WD5000AAKS-0,WDC WD6400AAKS-0,WDC WD15EADS-00P Size 2960GB (34%used) | GLX Renderer GeForce 210/PCIe/SSE2/3DNOW! | GLX Version 3.3.0 NVIDIA 313.18 | Client Shell | Infobash v3.46 Back to top |
|
That's slh not updating his kernels for nvidia/fglrx, liquorix ones work fine, no need for path fix.
However, I added 303.* for the fix tests, and also will let the fixes / patches run on 3.8 kernels, if that fails for 3.8 kernel let me know. Back to top |
|
Hi h2,
It's 313.18 that's not installing . . . whereas the 313.10 used to install with the symlink update tlll last week but won't install with the -o option now Back to top |
|
I understood what you noted, and updated sgfxi to do the links for 313.18 as well, as I said.
If that is not working, let me know. Oh, wait, I see, you want 313.10? I can add that back in no problem. Check sgfxi -Ld to see if it's in again. I'll start keeping the older drivers in for a while for -o. But in terms of the links, there should be no difference between 310 and 313 drivers in general. I think you have mixed up the driver numbers however, I don't see any 313.10 released anywhere. There was I think a beta 313.09 Back to top |
|
All times are GMT - 8 Hours |