169.09 Nvidia.ko build fails on newest 2.6.24 snapshot

[siddly]

Originally Posted by coolphoenix

well, i think when the 2.6.25 is final there will be an update/patch for sure

i hope they just wait until the first rc, then there will not be so many changes so fast and developing a patch will make more sense (even more if it's a big patch not done in 30mins or so)

With all the changes going into 2.6.25, I reckon it'll be quite some time before we see it making final.

[NightOwl]

169.09 doesn't load in 2.6.24.2 - which is an official release for the 2.6.24 line.

[zander]

@NightOwl: that sounds like a different problem; please start a new thread and include all relevant information (see http://www.nvnews.net/vbulletin/showthread.php?t=46678).

[towo|]

Originally Posted by NightOwl

169.09 doesn't load in 2.6.24.2 - which is an official release for the 2.6.24 line.

I have no problem with nvidia driver and 2.6.24.2

Host/Kernel/OS  "Defiant" running Linux 2.6.24.2-towo-1 i686 [ Debian GNU/Linux lenny/sid ]
CPU Info        (1) Intel Pentium 4 1024 KB cache flags( sse3 ) clocked at [ 2992.513 MHz ]
                (2) Intel Pentium 4 1024 KB cache flags( sse3 ) clocked at [ 2992.513 MHz ]
Videocard       nVidia NV43 [GeForce 6600 GT]  X.Org 1.4.0.90  [ 1280x1024@60.0hz ]
Network cards   Intel 82562EZ 10/100 Ethernet Controller, at port: df40 
Processes 130 | Uptime 1day | Memory 739.3/2025.7MB | HDD ATA ST3200826A,ATA WDC WD1600JB-75G Size 360GB (49%used) | GLX Renderer GeForce 6600 GT/AGP/SSE2 | 
GLX Version 2.1.2 NVIDIA 169.09 | Direct rendering Yes | Client Shell | Infobash v3.01

[NightOwl]

Yep. My bad. I had a relook at my boot logs. It seems after the restart some of my laptop's components didn't cleanly initialize so usb and more importantly, i2c modules didn't come up. I've just had the chance to do a cold reboot and the NVidia module builds and loads cleanly. Phew!

[JackieBrown]

Originally Posted by zander

Unfortunately, an unexpected (mostly political) problem came up that's still unresolved.

I know it's an election year but .....

Are we looking at a few more weeks or do we just need to wait for the next release? If you have already said all you can then that will have to do.

[Dragoran]

Originally Posted by zander

Unfortunately, an unexpected (mostly political) problem came up that's still unresolved.

What does this exactly mean?
GPL only symbol that the nvidia driver can't use?

Edit:
does setting CONFIG_PCI_LEGACY help?
I have heard that it solves the problem for the ATI drivers.

[zander]

@Dragoran: the 'init_mm' symbol is no longer exported in arch/x86; it's not clear what the solution for this problem will be, yet. I don't currently have an update on this, but will follow up on this thread when I do.

[Dragoran]

Originally Posted by zander

@Dragoran: the 'init_mm' symbol is no longer exported in arch/x86; it's not clear what the solution for this problem will be, yet. I don't currently have an update on this, but will follow up on this thread when I do.

OK, thx for keeping us up to date.

[PuckPoltergeist]

Originally Posted by zander

@Dragoran: the 'init_mm' symbol is no longer exported in arch/x86; it's not clear what the solution for this problem will be, yet. I don't currently have an update on this, but will follow up on this thread when I do.

Thank you for the info. But I don't think, that this was a political reason, as the changelog says:

x86: nuke a ton of unused exports

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

Seems that nothing else than the propritary drivers used this. After re-exporting init_mm and changing nv-vm.c to use set_memory_...() instead of change_page_attr(), the driver works with 2.6.25-rc1. But I get lots of warnings like

------------[ cut here ]------------
WARNING: at arch/x86/mm/pageattr.c:102 change_page_attr_set_clr+0x207/0x210()
Modules linked in: nvidia(P) snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device arc4 ecb snd_hda_intel snd_pcm snd_timer zd1211rw mac80211 firewire_ohci firewire_core crc_itu_t snd soundcore snd_page_alloc cfg80211 sr_mod sg cdrom [last unloaded: nvidia]
Pid: 9773, comm: X Tainted: P 2.6.25-rc1 #3

Call Trace:
[<ffffffff80235054>] warn_on_slowpath+0x64/0x90
[<ffffffff80222df0>] __cpa_flush_range+0x0/0x10
[<ffffffff80222ee9>] virt_to_highmap+0x9/0x20
[<ffffffff802235be>] __change_page_attr+0x6be/0x790
[<ffffffff88306118>] :nvidia:_nv008123rm+0x66/0xce
[<ffffffff80223967>] change_page_attr_set_clr+0x207/0x210
[<ffffffff88305e84>] :nvidia:_nv008048rm+0x3d/0xdb
[<ffffffff88305d59>] :nvidia:_nv008051rm+0xbb/0xc9
[<ffffffff884ebb8c>] :nvidia:nv_vm_free_pages+0x1bc/0x200
[<ffffffff884e7e3d>] :nvidia:nv_free_pages+0x1dd/0x220
[<ffffffff88434da3>] :nvidia:_nv003851rm+0x2e/0x33
[<ffffffff883b6305>] :nvidia:_nv005704rm+0x59/0xc3
[<ffffffff88158e85>] :nvidia:_nv014108rm+0x17d/0x1c5
[<ffffffff883d08d7>] :nvidia:_nv002914rm+0xbd/0x242
[<ffffffff883cf389>] :nvidia:_nv002932rm+0x18c/0x2cf
[<ffffffff883caf6c>] :nvidia:_nv005042rm+0x72/0x9f
[<ffffffff88272c15>] :nvidia:_nv002879rm+0x1e5/0x6f9
[<ffffffff8843c622>] :nvidia:rm_ioctl+0x2f/0x67
[<ffffffff884e8bcb>] :nvidia:nv_kern_ioctl+0x12b/0x3a0
[<ffffffff884e8e8c>] :nvidia:nv_kern_unlocked_ioctl+0x1c/0x30
[<ffffffff8029844f>] vfs_ioctl+0x2f/0xa0
[<ffffffff80298720>] do_vfs_ioctl+0x260/0x2e0
[<ffffffff803ac192>] __up_write+0x22/0x130
[<ffffffff802987e9>] sys_ioctl+0x49/0x80
[<ffffffff80276465>] sys_munmap+0x55/0x80
[<ffffffff8020b57b>] system_call_after_swapgs+0x7b/0x80
---[ end trace 0d5a99c308c50234 ]---

So I don't think, that simply change to set_memory_...() will fix it.

For the init_mm-struct, in old kernels (2.0) init_mm wasn't exported too. So there was a workaround for those modules, which needed it:

static struct mm_struct *init_mm_ptr;
#define init_mm (*init_mm_ptr) /* spaetere ifdefs vermeiden */

static void retrieve_init_mm_ptr(void)
{
struct task_struct *p;

for (p = current ; (p = p->next_task) != current ; )
if (p->pid == 0)
break;

init_mm_ptr = p->mm;
}

The code is from the german version of "Linux Device Drivers" by Alessandro Rubini & Jonathan Corbet. It can be found in chapter 13 (Backward Compatibility).

edit: Ok, I was a little to fast. A short look into the sources shows, that it seems to be an alignment-problem:

WARN_ON(PAGE_ALIGN(start) != start);

edit2: Aaaaarrrrgggggghhhh, my fault!
If I use the wrong functions, I must be happy if it even compiles. Not set_memory_uc() and set_memory_wb() must be used, but set_pages_uc() and set_pages_wb(). Now the warnings are gone.

[PuckPoltergeist]

zander:

init_task is still exported, which contains the mm_struct you need (init_task->active_mm, if I'm correct). So this should be fixed easily, if I'm not wrong.

[zander]

@PuckPoltergeist: although it is initialized that way, init_task->active_mm doesn't necessarily point to init_mm in the different contexts in which access to the latter is currently needed. The set_pages_{uc,wb} interface worked OK in my limited testing.