View Full Version : DMA Error with newest drivers
SubTexel
01-31-03, 08:15 PM
Ok, just installed the new drivers and now I get this error when trying to load X up:
Code:
------------------------------------------------------------------------------------
(EE) NVIDIA(0): Failed to allocate config DMA context
(EE) Screens found, but none have useable configuration
Fatal Server Error
no screens found
------------------------------------------------------------------------------------
Does anyone have an idea how to fix this (this same card works just fine under XP...) :(
System:
Gentoo Linux 1.4_rc2
Kernel 2.4.20
PNY Geforce4 4200 64MB version
Athlon XP 1700+
1GB PC2700 DDR RAM
MSI KT3 Ultra 2 Motherboard
Well, this (or something very much like it) is in the README:
Q: X fails with error "Failed to allocate LUT context DMA"
A: This is one of the possible consequences of compiling the open files
in the NVIDIA_kernel package with a different gcc version than used
to compile the Linux kernel (see above). And "above", it says:
Q: Compiling the NVIDIA kernel module gives this error:
You appear to be compiling the NVIDIA kernel module with
a compiler different from the one that was used to compile
the running kernel. This may be perfectly fine, but there
are cases where this can lead to unexpected behaviour and
system crashes.
If you know what you are doing and want to override this
check, you can do so by setting IGNORE_CC_MISMATCH.
In any other case, set the CC environment variable to the
name of the compiler that was used to compile the kernel.
A: You should compile the NVIDIA kernel module with the same compiler
version that was used to compile your kernel. Some Linux kernel data
structures are dependent on the version of gcc used to compile it;
for example, in include/linux/spinlock.h:
...
* Most gcc versions have a nasty bug with empty initializers.
*/
#if (__GNUC__ > 2)
typedef struct { } rwlock_t;
#define RW_LOCK_UNLOCKED (rwlock_t) { }
#else
typedef struct { int gcc_is_buggy; } rwlock_t;
#define RW_LOCK_UNLOCKED (rwlock_t) { 0 }
#endif
If the kernel is compiled with gcc 2.x, but gcc 3.x is used when the
open files in the NVIDIA_kernel package are built (or vice versa),
the size of rwlock_t will vary, and things like ioremap will fail.
To check what version of gcc was used to compile your kernel, you
can examine the output of:
cat /proc/version
To check what version of gcc is currently in your $PATH, you can
examine the output of:
gcc -v So do that (check /proc/version and cc -v -- although not gcc -v, as the two can sometimes be different).
SubTexel
02-01-03, 08:29 PM
Well, I compiled under GCC 3.2.1r7... (Both the Kernel AND Nvidia drivers...) Any other ideas? :confused:
No, not really, I don't have source.
Maybe someone from nVidia knows what can cause that message?
SubTexel
02-02-03, 12:41 PM
Hey well, I kind of fixed my problem.. At least now I can load up gnome now.. Anyhow, I installed the latest Xfree version (4.2.99 I believe, I have 4.2.1 or whatever the current one was before 4.2.99) I can only use the stock NV driver (which I couldnt do before at all, X would always dump errors on me) Now the Nvidia drivers cause my screen to go black and do nothing at all. Maybe I should try the older drivers? (3123?) Hopefully Nvidia fixes this problem soon, as this proves it wasnt a hardware problem (whew!) I'd reccomend trying out this new Xfree.. Anyhow, I'll let you guys know how it goes in terms of trying other drivers.
Thanks for the help!
I just "solved" the problem... the driver works fine with 512 mb ram but fails with 1gb ram...
here the text from kern.log...
( old drivers also don't work )
any ideas ?
Mar 10 10:04:08 omega 0: nvidia: loading NVIDIA Linux x86 nvidia.o Kernel Module 1.0-4191 Mon Dec 9 11:49:01 PST 2002
Mar 10 10:05:17 omega Unable to handle kernel paging request at virtual address fad6806c
Mar 10 10:05:17 omega printing eip:
Mar 10 10:05:17 omega f886a4f6
Mar 10 10:05:17 omega *pde = 00000000
Mar 10 10:05:17 omega Oops: 0000
Mar 10 10:05:17 omega CPU: 0
Mar 10 10:05:17 omega EIP: 0010:[<f886a4f6>] Tainted: P
Mar 10 10:05:17 omega EFLAGS: 00013206
Mar 10 10:05:17 omega eax: 0000001b ebx: c1d00001 ecx: 4001b000 edx: 3ad68000
Mar 10 10:05:17 omega esi: d0000000 edi: f89cd760 ebp: f79c7ae0 esp: f79c7ae0
Mar 10 10:05:17 omega ds: 0018 es: 0018 ss: 0018
Mar 10 10:05:17 omega Process X (pid: 4586, stackpage=f79c7000)
Mar 10 10:05:17 omega Stack: f79c7b04 f887dceb 4001b000 c1d00001 00000000 00000000 f89aeb60 04000000
Mar 10 10:05:17 omega de000000 f79c7b58 f886fdc4 f7580000 00000000 00000000 f763fbe8 00000fff
Mar 10 10:05:17 omega f763fbf0 f763fc1c f79c7e64 f89af0e0 00000000 bffff970 00000000 f7588600
Mar 10 10:05:17 omega Call Trace: [<f887dceb>] [<f89aeb60>] [<f886fdc4>] [<f89af0e0>] [<f89af0e0>]
Mar 10 10:05:17 omega [<f886bb75>] [<f88805c7>] [<f89af0e0>] [<f89af0e0>] [<f88810c8>] [<f88810c8>]
Mar 10 10:05:17 omega [<f890c6e9>] [<f89baac0>] [<c01f921d>] [<c01fc7e8>] [<c01f9ab7>] [<c01fc7e8>]
Mar 10 10:05:17 omega [<c0120b95>] [<c0120c23>] [<c010d5fa>] [<c011cf0e>] [<c011cd9e>] [<c0109922>]
Mar 10 10:05:17 omega [<c010bb87>] [<c0135e60>] [<c01328f8>] [<f888007d>] [<f89af0e0>] [<f8869acf>]
Mar 10 10:05:17 omega [<f89af0e0>] [<c01296fe>] [<c012ac71>] [<c012ac85>] [<c0129e24>] [<c0244624>]
Mar 10 10:05:17 omega [<c0150c58>] [<c0244624>] [<c010876f>] [<c0244624>]
Mar 10 10:05:17 omega
Mar 10 10:05:17 omega Code: 8b 84 82 00 00 00 c0 a8 81 74 13 89 c2 81 e2 00 f0 ff ff 89
Run that through ksymoops to get a usable stack backtrace (i.e. something other than just memory addresses).
When you had a gig of ram in there, were you using a kernel that had CONFIG_HIGHMEM compiled into it? If not, that might be the cause.
Originally posted by bwkaz
Run that through ksymoops to get a usable stack backtrace (i.e. something other than just memory addresses).
When you had a gig of ram in there, were you using a kernel that had CONFIG_HIGHMEM compiled into it? If not, that might be the cause.
ok .. I will do that when I'm back at home (at work right now).
I never used this program but i guess i will figure out how I have to use it :)
Yes .. afaik I have High Memory Support enabled with the default option in the memory amount setting.
The default setting (according to arch/i386/defconfig) is Off. The possibilities are Off, 4GB, and 64GB; you probably want 4GB.
Originally posted by bwkaz
The default setting (according to arch/i386/defconfig) is Off. The possibilities are Off, 4GB, and 64GB; you probably want 4GB.
I have
x x (4GB) High Memory Support x x
x x (3GB) User address space size x x
I'm emergeing ksymoops right now :)
omega linux # ksymoops -v /usr/src/linux-2.4.20-gentoo-r1/vmlinux oops
ksymoops 2.4.8 on i686 2.4.20-gentoo-r1. Options used
-v /usr/src/linux-2.4.20-gentoo-r1/vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.20-gentoo-r1/ (default)
-m /usr/src/linux/System.map (default)
f886a4f6
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<f886a4f6>] Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00013206
eax: 0000001b ebx: c1d00001 ecx: 4001b000 edx: 3ad68000
esi: d0000000 edi: f89cd760 ebp: f79c7ae0 esp: f79c7ae0
ds: 0018 es: 0018 ss: 0018
Process X (pid: 4586, stackpage=f79c7000)
Stack: f79c7b04 f887dceb 4001b000 c1d00001 00000000 00000000 f89aeb60 04000000
de000000 f79c7b58 f886fdc4 f7580000 00000000 00000000 f763fbe8 00000fff
f763fbf0 f763fc1c f79c7e64 f89af0e0 00000000 bffff970 00000000 f7588600
Call Trace: [<f887dceb>] [<f89aeb60>] [<f886fdc4>] [<f89af0e0>] [<f89af0e0>]
[<f886bb75>] [<f88805c7>] [<f89af0e0>] [<f89af0e0>] [<f88810c8>] [<f88810c8>]
[<f890c6e9>] [<f89baac0>] [<c01f921d>] [<c01fc7e8>] [<c01f9ab7>] [<c01fc7e8>]
[<c0120b95>] [<c0120c23>] [<c010d5fa>] [<c011cf0e>] [<c011cd9e>] [<c0109922>]
[<c010bb87>] [<c0135e60>] [<c01328f8>] [<f888007d>] [<f89af0e0>] [<f8869acf>]
[<f89af0e0>] [<c01296fe>] [<c012ac71>] [<c012ac85>] [<c0129e24>] [<c0244624>]
[<c0150c58>] [<c0244624>] [<c010876f>] [<c0244624>]
Code: 8b 84 82 00 00 00 c0 a8 81 74 13 89 c2 81 e2 00 f0 ff ff 89
>>EIP; f886a4f6 <END_OF_CODE+17e7b2af/????> <=====
>>ebx; c1d00001 <_end+199c951/205049b0>
>>esi; d0000000 <_end+fc9c950/205049b0>
Trace; f887dceb <END_OF_CODE+17e8eaa4/????>
Trace; f89aeb60 <END_OF_CODE+17fbf919/????>
Trace; f886fdc4 <END_OF_CODE+17e80b7d/????>
Trace; f89af0e0 <END_OF_CODE+17fbfe99/????>
Trace; f89af0e0 <END_OF_CODE+17fbfe99/????>
Trace; f886bb75 <END_OF_CODE+17e7c92e/????>
Trace; f88805c7 <END_OF_CODE+17e91380/????>
Trace; f89af0e0 <END_OF_CODE+17fbfe99/????>
Trace; f89af0e0 <END_OF_CODE+17fbfe99/????>
Trace; f88810c8 <END_OF_CODE+17e91e81/????>
Trace; f88810c8 <END_OF_CODE+17e91e81/????>
Trace; f890c6e9 <END_OF_CODE+17f1d4a2/????>
Trace; f89baac0 <END_OF_CODE+17fcb879/????>
Trace; c01f921d <ide_build_sglist+88/198>
Trace; c01fc7e8 <via82cxxx_dmaproc+16/e8>
Trace; c01f9ab7 <ide_dmaproc+1ae/2ae>
Trace; c01fc7e8 <via82cxxx_dmaproc+16/e8>
Trace; c0120b95 <update_process_times+23/29>
Trace; c0120c23 <do_timer+68/6a>
Trace; c010d5fa <do_timer_interrupt+3d/c3>
Trace; c011cf0e <tasklet_hi_action+3a/59>
Trace; c011cd9e <do_softirq+b2/b5>
Trace; c0109922 <do_IRQ+c0/d0>
Trace; c010bb87 <call_do_IRQ+5/a>
Trace; c0135e60 <__alloc_pages+86/2a2>
Trace; c01328f8 <lru_cache_add+111/133>
Trace; f888007d <END_OF_CODE+17e90e36/????>
Trace; f89af0e0 <END_OF_CODE+17fbfe99/????>
Trace; f8869acf <END_OF_CODE+17e7a888/????>
Trace; f89af0e0 <END_OF_CODE+17fbfe99/????>
Trace; c01296fe <__vma_link+4a/ab>
Trace; c012ac71 <vma_link+2f/52>
Trace; c012ac85 <vma_link+43/52>
Trace; c0129e24 <do_mmap_pgoff+58e/7dc>
Trace; c0244624 <tcp_sendmsg+a49/ee8>
Trace; c0150c58 <sys_ioctl+ca/1a9>
Trace; c0244624 <tcp_sendmsg+a49/ee8>
Trace; c010876f <system_call+33/38>
Trace; c0244624 <tcp_sendmsg+a49/ee8>
Code; f886a4f6 <END_OF_CODE+17e7b2af/????>
00000000 <_EIP>:
Code; f886a4f6 <END_OF_CODE+17e7b2af/????> <=====
0: 8b 84 82 00 00 00 c0 mov 0xc0000000(%edx,%eax,4),%eax <=====
Code; f886a4fd <END_OF_CODE+17e7b2b6/????>
7: a8 81 test $0x81,%al
Code; f886a4ff <END_OF_CODE+17e7b2b8/????>
9: 74 13 je 1e <_EIP+0x1e>
Code; f886a501 <END_OF_CODE+17e7b2ba/????>
b: 89 c2 mov %eax,%edx
Code; f886a503 <END_OF_CODE+17e7b2bc/????>
d: 81 e2 00 f0 ff ff and $0xfffff000,%edx
Code; f886a509 <END_OF_CODE+17e7b2c2/????>
13: 89 00 mov %eax,(%eax)
omega linux #
Originally posted by DaFire
I have
x x (4GB) High Memory Support x x
x x (3GB) User address space size x x What is that? Something Gentoo-specific? Look at /usr/src/linux-<version>/.config, for the various HIGHMEM switches; I have:
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set But that's because I have it disabled. You should have NOHIGHMEM commented out, and either the 4G or the 64G one set to y (and uncommented). If you have to change that, run make oldconfig and then recompile the kernel ("make dep bzImage modules modules_install" or similar).
Trace; f887dceb <END_OF_CODE+17e8eaa4/????> Umm... *scratches head*
Your kernel is calling off into never-never land, from the looks of things. Where from, I wonder...
Trace; c01f921d <ide_build_sglist+88/198>
Trace; c01fc7e8 <via82cxxx_dmaproc+16/e8>
Trace; c01f9ab7 <ide_dmaproc+1ae/2ae>
Trace; c01fc7e8 <via82cxxx_dmaproc+16/e8> From the IDE layer. Nice. Well, that's not related to the nVidia driver -- at least not directly, but it was called in an interrupt context, so let's go further back:
Trace; f888007d <END_OF_CODE+17e90e36/????> Hmm, more never-never-land calling...
Trace; c01296fe <__vma_link+4a/ab>
Trace; c012ac71 <vma_link+2f/52>
Trace; c012ac85 <vma_link+43/52>
Trace; c0129e24 <do_mmap_pgoff+58e/7dc>
Trace; c0244624 <tcp_sendmsg+a49/ee8>
Trace; c0150c58 <sys_ioctl+ca/1a9>
Trace; c0244624 <tcp_sendmsg+a49/ee8>
Trace; c010876f <system_call+33/38>
Trace; c0244624 <tcp_sendmsg+a49/ee8> Looks like the sendmsg() syscall. Not at all related to the nVidia drivers, although that vma_link thing might be doing memory allocation, which would be affected by them (in ways completely unknown, BTW).
What was running at the time that was using TCP?
I'm not really sure other than that...
Hmm.. the part of .config looks like:
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
CONFIG_1GB=y
# CONFIG_2GB is not set
# CONFIG_3GB is not set
# CONFIG_05GB is not set
CONFIG_HIGHIO=y
it's the gentoo high perfomance kernel with lots of patches attached.. I will install a vanilla kernel now and try again .
Well.. the only network thing running in the background was an apache2 ... but idle :)
bastian
Ok ... no more crashes.. I don't know if it's because I took the vanilla kernel sources now or because I did something different in the .config... I will investigate it later :)
thanks for your help
I'm having the same problem with gentoo-sources-2.4.20-gentoo-r1. I also have himem support on :
line72 linux # grep -in highmem .config
69:# CONFIG_NOHIGHMEM is not set
70:CONFIG_HIGHMEM4G=y
71:# CONFIG_HIGHMEM64G is not set
72:CONFIG_HIGHMEM=y
1037:# CONFIG_DEBUG_HIGHMEM is not set
Anyway to get this to work. I'd like to keep a kernel with pre-empt on.
vBulletin® v3.7.1, Copyright ©2000-2012, Jelsoft Enterprises Ltd.