Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 02-24-08, 10:47 AM   #49
towo|
Registered User
 
Join Date: Feb 2007
Posts: 113
Default Re: 169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

Quote:
Originally Posted by JackieBrown
If you look at the patch, you will see it is for the nvidia driver, not the kernel.
And if you look into the post, you will see, that the patch only is not enough.
Bacause the symbol init_mm must be exportet in kernel.
towo| is offline   Reply With Quote
Old 02-24-08, 09:46 PM   #50
saltydog
Registered User
 
Join Date: Feb 2008
Posts: 4
Default Re: 169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

Thank you Jama - works great for me. Because of problems with my hands which make it difficult to point the mouse precisely, the rotating cube provided by Compiz is a blessing - it is much easier for me to spin the mouse wheel than it is to point and click on the icon for a specific desktop.

Towol & Entrophy - after you lay out your kernel sources go to arch/x86/kernel/init_task.c and add the following line right after the line containing struct mm_struct init_mm = INIT_MM(init_mm);

EXPORT_SYMBOL(init_mm);

(I used the 2.6.25-rc3 sources tonight and the struct statement defining init_mm was on line 17, I added the EXPORT to line 18)

Then rebuild your kernel (make, make_modules, blah, blah)

Reboot in single user mode using the kernel you just built

Build the Nvidia driver

Don't forget to change your driver statement in your xorg.conf back from "nv" to "nvidia"

Have fun
saltydog is offline   Reply With Quote
Old 02-25-08, 04:56 AM   #51
towo|
Registered User
 
Join Date: Feb 2007
Posts: 113
Default Re: 169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

Have you take a look at /var/log/messages after startx?
I get a mass of warnings:
Code:
NVRM: loading NVIDIA UNIX x86 Kernel Module  169.09  Fri Jan 11 14:38:28 PST 2008
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap.c:137 __ioremap+0x195/0x1b0()
Modules linked in: nvidia(P) vboxdrv agpgart binfmt_misc af_packet speedstep_lib freq_table ipx p8022 psnap llc p8023 parport_pc ppdev parport video output container battery ac pktcdvd fuse psmouse isl6421 cx24123 cx88_dvb cx88_vp3054_i2c videobuf_dvb dvb_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss cx8802 cx88xx snd_pcm videodev v4l1_compat ir_common tveeprom btcx_risc snd_timer videobuf_dma_sg videobuf_core snd pcspkr i2c_i801 button soundcore snd_page_alloc shpchp pci_hotplug evdev dcdbas usbhid ff_memless e100 mii uhci_hcd ehci_hcd usbcore thermal processor fan [last unloaded: nvidia]
Pid: 13296, comm: Xorg Tainted: P         2.6.25-rc3-towo-1 #1
 [<c012736f>] warn_on_slowpath+0x5f/0x90
 [<c0157677>] __rmqueue_smallest+0xb7/0x130
 [<c015770e>] __rmqueue+0x1e/0x1f0
 [<fac75376>] _nv004192rm+0x10/0x41 [nvidia]
 [<fac752a5>] _nv004184rm+0x35/0x70 [nvidia]
 [<c015893a>] __alloc_pages+0x5a/0x350
 [<fac879ae>] _nv003779rm+0x18/0x6f [nvidia]
 [<c0117bf5>] __ioremap+0x195/0x1b0
 [<fad0947f>] _nv002881rm+0x10a/0x197 [nvidia]
 [<fac916b6>] _nv002892rm+0x144/0x42d [nvidia]
 [<fac8c477>] rm_init_adapter+0x8b/0xd9 [nvidia]
 [<fad26b36>] nv_kern_open+0x396/0x530 [nvidia]
 [<c017b4f5>] chrdev_open+0xc5/0x1c0
 [<c0176ddd>] __dentry_open+0xdd/0x1e0
 [<c0176fa7>] nameidata_to_filp+0x47/0x60
 [<c017b430>] chrdev_open+0x0/0x1c0
 [<c017700b>] do_filp_open+0x4b/0x60
 [<c0176cd6>] get_unused_fd_flags+0xb6/0xd0
 [<c017706c>] do_sys_open+0x4c/0xe0
 [<c017713c>] sys_open+0x1c/0x20
 [<c0104352>] syscall_call+0x7/0xb
 =======================
---[ end trace dc4de9d9659664bb ]---
towo| is offline   Reply With Quote
Old 02-27-08, 09:26 PM   #52
babosa_cerebral
Registered User
 
babosa_cerebral's Avatar
 
Join Date: Dec 2007
Posts: 9
Exclamation Re: 169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

thnxs confirm working with 96.43.05 and rc2
Code:
 BIOS-e820: 000000000fff0000 - 000000000fff3000 (ACPI NVS)
nvidia: module license 'NVIDIA' taints kernel.
NVRM: loading NVIDIA Linux x86 Kernel Module  96.43.05  Tue Jan 22 19:36:58 PST 2008
Linux myhost 2.6.25-rc2 #2 Wed Feb 27 13:51:22 ARST 2008 i686 AMD Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux
just one question for the kernel patchers/gurus , I didnt understand how did you manage the tlb cache flushes, could anything screw up if all the calls are commented out??

I just dislike cache flushes, and other caches operations , , well it main sound stupid superstition... but anything cache related on this box, is it's a sensitive type, I suppose the reason might be ==> http://www.theregister.co.uk/2002/01...linux_amd_bug/

thnxs again.
babosa_cerebral is offline   Reply With Quote
Old 02-28-08, 07:53 AM   #53
siddly
Registered User
 
Join Date: Jul 2003
Location: West Midlands, UK
Posts: 125
Default Re: 169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

It seems this is answer on LKML has set the position in stone and thrown the problem back to NVidia. There was a previous followup from Dave Airlie to the request that I wasn't sure was facetious, now I know it was.

Re: Reexport init_mm ?
From: Chris Snook
Date: Thu Feb 28 2008 - 02:23:52 EST
* In reply to: Dave Airlie: "Re: Reexport init_mm ?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

drago01 wrote:

init_mm is no longer exported in 2.6.25, because there are no in tree
modules that use it.
But the closed sources nvidia drivers are using it.
Is it possible to reexport this symbol to let the driver work with this kernel?


The fact that there are no in-tree modules that use init_mm is rather compelling evidence that it's not a necessary part of the kernel module API. Nvidia needs to fix their code. If this is a burden, perhaps they should publish their code under a GPLv2-compatible license so we can show them how to do it.

-- Chris
siddly is offline   Reply With Quote
Old 02-28-08, 01:52 PM   #54
Emopig
Registered User
 
Join Date: Feb 2008
Posts: 19
Default Re: 169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

Hi everyone,

I too have patched both the 169.12 and 100.14.23 drivers to work with 2.6.25-rc's. I've used #ifdef for the convenience of those like me who boot between multiple kernels and have to recompile regularly. I've tested on x86_64 + 2.6.25-rc3-git1.

Here are my patches:
http://andrew.nelless.net/patches/nv...3-kernel.patch
http://andrew.nelless.net/patches/nv...2-kernel.patch
http://andrew.nelless.net/patches/2....idia-fix.patch

I didn't seem to need to re-export the "init_mm" symbol, I assume this is a x86_32 only thing? I also haven't removed the global_flush_tlb() equivalent, just fixed it up, although to me (and I have a modest understanding of the code) it looks like the TLB's are being flushed twice on modern 2.6 kernels anyway.

I too get a (slightly different) ioremap/warn_on_slowpath trace coming out the blob when you start X, but it _appears_ to be harmless. Interestingly, I saw a thread on the kernel mailing list this morning about several bugs in the new ioremap implementation...so maybe this is a kernel bug?
Emopig is offline   Reply With Quote
Old 02-28-08, 02:11 PM   #55
PuckPoltergeist
Registered User
 
Join Date: Jan 2007
Posts: 42
Default Re: 169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

Sorry for the long delay. I have only little time to look into this, cause for the moment I have to work on other problems.

Quote:
Originally Posted by Emopig
I didn't seem to need to re-export the "init_mm" symbol, I assume this is a x86_32 only thing?
No, it also affects x86_64.

Quote:
I also haven't removed the global_flush_tlb() equivalent, just fixed it up, although to me (and I have a modest understanding of the code) it looks like the TLB's are being flushed twice on modern 2.6 kernels anyway.
All flushes are no hidden behind the set_memory_/set_pages_-interface. The kernel decides what memory (TLB/caches...) need to be flushed.

Quote:
I too get a (slightly different) ioremap/warn_on_slowpath trace coming out the blob when you start X, but it _appears_ to be harmless. Interestingly, I saw a thread on the kernel mailing list this morning about several bugs in the new ioremap implementation...so maybe this is a kernel bug?
Possible. With 2.6.25-rc1 this warning didn't appear.
PuckPoltergeist is offline   Reply With Quote
Old 02-28-08, 04:49 PM   #56
Emopig
Registered User
 
Join Date: Feb 2008
Posts: 19
Default Re: 169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

PuckPoltergeist:

Why does init_mm need to be exported? It has been working fine for me on x86_64 without exporting it since -rc2-git_something
Emopig is offline   Reply With Quote

Old 02-28-08, 07:30 PM   #57
JackieBrown
Registered User
 
Join Date: Dec 2004
Posts: 47
Default Re: 169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

Quote:
Originally Posted by Emopig
PuckPoltergeist:

Why does init_mm need to be exported? It has been working fine for me on x86_64 without exporting it since -rc2-git_something
It worked for me only using your patch, Emopig.

I didn't export init_mm either.

This is with the rc 3 kernel and the latest nvidia driver.
JackieBrown is offline   Reply With Quote
Old 02-28-08, 08:36 PM   #58
saltydog
Registered User
 
Join Date: Feb 2008
Posts: 4
Default Re: 169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

I am not sure what you guys are doing but I have been using the patch provided by jama in his post #46 above against the 169.09 driver code. With the addition of re-exporting init_mm in the kernel sources this patch has worked well for me for several days now.

Based on comments by emopig and jackiebrown I reverted the export and built a new kernel. I then attempted to build the Nvidia driver, but this effort failed with an init_mm unknown symbol error.

I am running the 32 bit version of the kernel (on an AMD 64 X2) and use GCC 4.1.2 to perform my builds. This exercise was done using the 2.6.25-rc3-git1 kernel source tree. Linking and such is done using binutils 2.18.0.

Now one word here – if you note that Linus has not participated on the mailing list for the past few days – it is very likely that he would have taken exception to Snook's trite and priggish response – there are more than a few developers such as Chris and Andi who really push the GPL line.

However in the past Linus has been more pragmatic, especially when it comes to breaking existing code.

One of you (and since I am a regular participant in the kernel development process as a tester I am kind of sleeping with the enemy here) might want to post another message to the LKML focusing on the following:

1. While it was not a part of the published kernel API – init_mm has been around for so long that it has become a “de facto” part of the kernel API.

2. A large number of Linux users purchased Nvidia-based cards based on the fact that there were vendor supported Linux drivers for them.

3. The change in policy about exporting init_mm will have a large impact on those who currently own Nvidia-based cards.

In the past this type of ball-busting and arm twisting has not been supported by Linus.

Hint – you might include the word “Regression” in the title of the post.

I can make no promises but the exportation of other symbols has been re-established in the past for just this type of reason.

As a closing note am I the only one who is a little disappointed with Nvidia's response to this who issue?
saltydog is offline   Reply With Quote
Old 02-28-08, 09:16 PM   #59
JackieBrown
Registered User
 
Join Date: Dec 2004
Posts: 47
Default Re: 169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

Maybe because you are grabbing from git? Also, I know Emopig posted a patch for both drivers but I only tried the 169.12 driver.

Also, I think we are both using a 64 bit kernel.

Either way, I agree; I would prefer Nvidia come out with at least a patch (if not a driver.) It's sad that the users are the ones doing this.
JackieBrown is offline   Reply With Quote
Old 02-28-08, 09:40 PM   #60
saltydog
Registered User
 
Join Date: Feb 2008
Posts: 4
Default Re: 169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

What is sad is that I don't see Nvidia pressing their case on the LKML - which as a part of my job I monitor several times a day.

I can understand why Nvidia (or other speciality chip makers) may not want to disclose the inner workings of their products and allow Open Source programmers complete access to their hardware API.

But unless the reason Linux has not posted for the past few days is that he is being wined and dined by Nvidia it would seem that they are just letting events run over them.
saltydog is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
Diablo 3 build guide: Barbarian, Demon Hunter, Monk, Witch Doctor and Wizard News Archived News Items 0 05-12-12 12:00 PM

All times are GMT -5. The time now is 04:46 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright ©1998 - 2014, nV News.