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

Newegg Daily Deals

Reply
 
Thread Tools
Old 02-13-04, 06:48 PM   #1
tamran
Registered User
 
Join Date: Feb 2004
Location: Ft. Myers, FL
Posts: 67
Default Badness in pci_find_subsys at drivers/pci/search.c

I'm getting crashes on a daily basis with the nvidia driver (5332) on Gentoo-AMD64. I have a dual opteron system with 1 gig of ram and an NVIDIA Geforce4 TI 4800SE card. This is getting awefully frustrating. Pasted below is the error in /var/log/messages.

Basically is what happens is the screen, keyboard and mouse lock up. I have to hit reset. I have tried everything under the sun - I'vedisabled acpi, apic ... neither of which are recommended for dual processors. Disabling AGP works, but that makes things slow and I need the video horsepower. Does ANYONE have a possible fix for this? I've seen similar messages all throughout these forums.


Feb 13 19:37:12 gen2 Badness in pci_find_subsys at drivers/pci/search.c:167
Feb 13 19:37:12 gen2
Feb 13 19:37:12 gen2 Call Trace:<IRQ> <ffffffff8020f753>{pci_find_subsys+83} <ffffffff8020f600>{pci_find_slot+48}
Feb 13 19:37:12 gen2 <ffffffffa03bc298>{:nvidias_pci_init_handle+40 } <ffffffffa03d7dae>{:nvidia:_nv000904rm+24}
Feb 13 19:37:12 gen2 <ffffffffa052db7b>{:nvidia:_nv000711rm+897} <ffffffff802e0b45>{dev_queue_xmit+309}
Feb 13 19:37:12 gen2 <ffffffffa04adce7>{:nvidia:_nv001272rm+51} <ffffffffa04ace5c>{:nvidia:_nv001217rm+28}
Feb 13 19:37:12 gen2 <ffffffffa052d5ca>{:nvidia:_nv000704rm+46} <ffffffffa048ffa2>{:nvidia:_nv002988rm+438}
Feb 13 19:37:12 gen2 <ffffffffa03f5e92>{:nvidia:_nv004381rm+114} <ffffffffa04ad136>{:nvidia:_nv002812rm+16}
Feb 13 19:37:12 gen2 <ffffffffa049fabf>{:nvidia:_nv001834rm+2317} <ffffffffa04aca54>{:nvidia:_nv001214rm+112}
Feb 13 19:37:12 gen2 <ffffffffa03d90fe>{:nvidia:_nv000719rm+62} <ffffffffa03d9383>{:nvidia:_nv000858rm+103}
Feb 13 19:37:12 gen2 <ffffffffa048e535>{:nvidia:_nv002967rm+1907} <ffffffffa04aca54>{:nvidia:_nv001214rm+112}
Feb 13 19:37:12 gen2 <ffffffffa03d9526>{:nvidia:_nv000884rm+16} <ffffffffa04fbb1b>{:nvidia:_nv001134rm+723}
Feb 13 19:37:12 gen2 <ffffffffa03dae9e>{:nvidia:_nv005317rm+112} <ffffffffa03dc83d>{:nvidia:rm_isr_bh+9}
Feb 13 19:37:12 gen2 <ffffffff8013c21f>{tasklet_action+111} <ffffffff8013befb>{do_softirq+123}
Feb 13 19:37:12 gen2 <ffffffff8011384f>{do_IRQ+463} <ffffffff80110f8d>{ret_from_intr+0}
Feb 13 19:37:12 gen2 <EOI> <ffffffff80110a14>{system_call+124}
Feb 13 19:37:12 gen2 Badness in pci_find_subsys at drivers/pci/search.c:167
Feb 13 19:37:12 gen2
Feb 13 19:37:12 gen2 Call Trace:<IRQ> <ffffffff8020f753>{pci_find_subsys+83} <ffffffff8020f600>{pci_find_slot+48}
Feb 13 19:37:12 gen2 <ffffffffa03bc298>{:nvidias_pci_init_handle+40 } <ffffffffa03d7dae>{:nvidia:_nv000904rm+24}
Feb 13 19:37:12 gen2 <ffffffffa04915c4>{:nvidia:_nv002969rm+178} <ffffffff8020f825>{pci_find_subsys+293}
Feb 13 19:37:12 gen2 <ffffffffa04ff90f>{:nvidia:_nv001148rm+121} <ffffffffa052dbc0>{:nvidia:_nv000711rm+966}
Feb 13 19:37:12 gen2 <ffffffff802e0b45>{dev_queue_xmit+309} <ffffffffa04adce7>{:nvidia:_nv001272rm+51}
Feb 13 19:37:12 gen2 <ffffffffa04ace5c>{:nvidia:_nv001217rm+28} <ffffffffa052d5ca>{:nvidia:_nv000704rm+46}
Feb 13 19:37:12 gen2 <ffffffffa048ffa2>{:nvidia:_nv002988rm+438} <ffffffffa03f5e92>{:nvidia:_nv004381rm+114}
Feb 13 19:37:12 gen2 <ffffffffa04ad136>{:nvidia:_nv002812rm+16} <ffffffffa049fabf>{:nvidia:_nv001834rm+2317}
Feb 13 19:37:12 gen2 <ffffffffa04aca54>{:nvidia:_nv001214rm+112} <ffffffffa03d90fe>{:nvidia:_nv000719rm+62}
Feb 13 19:37:12 gen2 <ffffffffa03d9383>{:nvidia:_nv000858rm+103} <ffffffffa048e535>{:nvidia:_nv002967rm+1907}
Feb 13 19:37:12 gen2 <ffffffffa04aca54>{:nvidia:_nv001214rm+112} <ffffffffa03d9526>{:nvidia:_nv000884rm+16}
Feb 13 19:37:12 gen2 <ffffffffa04fbb1b>{:nvidia:_nv001134rm+723} <ffffffffa03dae9e>{:nvidia:_nv005317rm+112}
Feb 13 19:37:12 gen2 <ffffffffa03dc83d>{:nvidia:rm_isr_bh+9} <ffffffff8013c21f>{tasklet_action+111}
Feb 13 19:37:12 gen2 <ffffffff8013befb>{do_softirq+123} <ffffffff8011384f>{do_IRQ+463}
Feb 13 19:37:12 gen2 <ffffffff80110f8d>{ret_from_intr+0} <EOI> <ffffffff80110a14>{system_call+124}
tamran is offline   Reply With Quote
Old 02-16-04, 09:46 PM   #2
technikolor
Registered User
 
Join Date: Jul 2003
Posts: 18
Default

I've got the same problem. I'm running Dual AthlonMP 1.2G's with a GeForce4 4600.
I've had this same type of problem for ages, but on 5336 it's unbearable. Quake3 will lock up sometimes for 30-60 seconds at a time, assuming it comes back at all.
When it locks up my system, the keyboard, mouse and video are involved, so the only way to clear things up (short of rebooting) is to log in from some other system, kill and restart X, then back on my system I have control back.

I've tried the ACPI and APIC changes as well, but they cause more problems than they solve.
I'm running kernel 2.6.2.

here's my trace:
<pre>
Feb 16 01:36:25 nexus6 Badness in pci_find_subsys at drivers/pci/search.c:167
Feb 16 01:36:25 nexus6 Call Trace:
Feb 16 01:36:25 nexus6 [<c02d3ef5>] pci_find_subsys+0x115/0x120
Feb 16 01:36:25 nexus6 [<c02d3f2f>] pci_find_device+0x2f/0x40
Feb 16 01:36:25 nexus6 [<c02d3ce8>] pci_find_slot+0x28/0x50
Feb 16 01:36:25 nexus6 [<e1cff46a>] os_pci_init_handle+0x3a/0x65 [nvidia]
Feb 16 01:36:25 nexus6 [<e1b9385f>] _nv001243rm+0x1f/0x24 [nvidia]
Feb 16 01:36:25 nexus6 [<e1cda115>] _nv000816rm+0x2f5/0x384 [nvidia]
Feb 16 01:36:25 nexus6 [<e1c4292c>] _nv003801rm+0xd8/0x100 [nvidia]
Feb 16 01:36:25 nexus6 [<e1cd9c4f>] _nv000809rm+0x2f/0x34 [nvidia]
Feb 16 01:36:25 nexus6 [<e1c71b48>] _nv003606rm+0xe4/0x114 [nvidia]
Feb 16 01:36:25 nexus6 [<e1c717f9>] _nv003564rm+0x7c9/0x908 [nvidia]
Feb 16 01:36:25 nexus6 [<e1bac267>] _nv004046rm+0x3a3/0x3b0 [nvidia]
Feb 16 01:36:25 nexus6 [<e1cadb03>] _nv001476rm+0x1d3/0x45c [nvidia]
Feb 16 01:36:25 nexus6 [<e1b9639a>] _nv000896rm+0x4a/0x64 [nvidia]
Feb 16 01:36:25 nexus6 [<e1b97bb4>] rm_isr_bh+0xc/0x10 [nvidia]
Feb 16 01:36:25 nexus6 [<e1cfcc32>] nv_kern_isr_bh+0x11/0x13 [nvidia]
Feb 16 01:36:25 nexus6 [<c01264a8>] tasklet_action+0x68/0xc0
Feb 16 01:36:25 nexus6 [<c01261ec>] do_softirq+0xcc/0xd0
Feb 16 01:36:25 nexus6 [<c010bdcd>] do_IRQ+0x14d/0x1a0
Feb 16 01:36:25 nexus6 [<c0109f48>] common_interrupt+0x18/0x20
Feb 16 01:36:25 nexus6 [<c0125759>] sys_gettimeofday+0x19/0xe0
Feb 16 01:36:25 nexus6 [<c01095db>] syscall_call+0x7/0xb
Feb 16 01:36:25 nexus6
Feb 16 01:36:25 nexus6 Badness in pci_find_subsys at drivers/pci/search.c:167
Feb 16 01:36:25 nexus6 Call Trace:
Feb 16 01:36:25 nexus6 [<c02d3ef5>] pci_find_subsys+0x115/0x120
Feb 16 01:36:25 nexus6 [<c02d3f2f>] pci_find_device+0x2f/0x40
Feb 16 01:36:25 nexus6 [<c02d3ce8>] pci_find_slot+0x28/0x50
Feb 16 01:36:25 nexus6 [<e1cff46a>] os_pci_init_handle+0x3a/0x65 [nvidia]
Feb 16 01:36:25 nexus6 [<e1b9385f>] _nv001243rm+0x1f/0x24 [nvidia]
Feb 16 01:36:25 nexus6 [<e1c44a5d>] _nv003797rm+0xa9/0x128 [nvidia]
Feb 16 01:36:25 nexus6 [<e1cb14a1>] _nv001490rm+0x55/0xe4 [nvidia]
Feb 16 01:36:25 nexus6 [<e1cda154>] _nv000816rm+0x334/0x384 [nvidia]
Feb 16 01:36:25 nexus6 [<e1c4292c>] _nv003801rm+0xd8/0x100 [nvidia]
Feb 16 01:36:25 nexus6 [<e1cd9c4f>] _nv000809rm+0x2f/0x34 [nvidia]
Feb 16 01:36:25 nexus6 [<e1c71b48>] _nv003606rm+0xe4/0x114 [nvidia]
Feb 16 01:36:25 nexus6 [<e1c717f9>] _nv003564rm+0x7c9/0x908 [nvidia]
Feb 16 01:36:25 nexus6 [<e1bac267>] _nv004046rm+0x3a3/0x3b0 [nvidia]
Feb 16 01:36:25 nexus6 [<e1cadb03>] _nv001476rm+0x1d3/0x45c [nvidia]
Feb 16 01:36:25 nexus6 [<e1b9639a>] _nv000896rm+0x4a/0x64 [nvidia]
Feb 16 01:36:25 nexus6 [<e1b97bb4>] rm_isr_bh+0xc/0x10 [nvidia]
Feb 16 01:36:25 nexus6 [<e1cfcc32>] nv_kern_isr_bh+0x11/0x13 [nvidia]
Feb 16 01:36:25 nexus6 [<c01264a8>] tasklet_action+0x68/0xc0
Feb 16 01:36:25 nexus6 [<c01261ec>] do_softirq+0xcc/0xd0
Feb 16 01:36:25 nexus6 [<c010bdcd>] do_IRQ+0x14d/0x1a0
Feb 16 01:36:25 nexus6 [<c0109f48>] common_interrupt+0x18/0x20
Feb 16 01:36:25 nexus6 [<c0125759>] sys_gettimeofday+0x19/0xe0
Feb 16 01:36:25 nexus6 [<c01095db>] syscall_call+0x7/0xb
</pre>
__________________
Tyan ThunderK7
Dual AthlonMP 1.2G
1GB PC2100 Reg ECC
XFX 6600GT AGP
TrueCombat: Q3A Mod - truecombat.com
technikolor is offline   Reply With Quote
Old 02-17-04, 06:16 AM   #3
tamran
Registered User
 
Join Date: Feb 2004
Location: Ft. Myers, FL
Posts: 67
Default I might be on to something ...

Hey there technikolor.

I'm also using 2.6.2 kernel right now, but the problem seemed to be kernel independant. I have been going stead for 3 full days now and I think perhaps I might have found the source of the problem. Question ... do you have framebuffer support in your kernel? I had bootsplash, but tried disabling that for now. Here's how I've got it set up at the moment.

Using the kernels 'make menuconfig':

Under Device Drivers -> Graphics Support:
[ ] Support for frame buffer devices (Turned off)

and under console display driver support

--- VGA text console
[ ] Video mode selection support
< > MDA text console (dual-headed) (EXPERIMENTAL)

Also, are you using agpgart or nvidias agp driver (NvAGP "2" or "1" respectively)? You can find out by typing the following as root:

# cat /proc/driver/nvidia/agp/status

I'm using agpgart because it's the only one available on amd64 drivers at the moment. However, I have found that using NVIDIA's agp driver (NvAGP "1") seemed to stop lockups on my other system ... which was having the same problem a while back.

Also, I notice your output is a little different than mine. Are you using the "nv" driver, or "nvidia"? I find it interesting that you've also got the Geforce4 ti card.

Regards,

Tamran
tamran is offline   Reply With Quote
Old 02-17-04, 12:54 PM   #4
technikolor
Registered User
 
Join Date: Jul 2003
Posts: 18
Default

Yes, I do use the FB, but I use VesaFB, not RivaFB. If you think you have improved things by disabling the FB I'm going to be saddened. RivaFB has always been full of problems, but VesaFB worked pretty nicely.

Yes, I'm using the NVidia module and driver. I backrev'ed to 5328 last night after locking up 3 times: once while trying to play Quake3 and twice in X. But 5328 is no better, I woke up this morning to a locked X.

I'm using NV AGP (NvAGP = 1). I build AGPGART as a module now just in case, but found better stablity on NV AGP.


I really don't want to disable the FB.. I'm developing for the FB, and already pissed that RivaFB sucks ass.

technikolor.
__________________
Tyan ThunderK7
Dual AthlonMP 1.2G
1GB PC2100 Reg ECC
XFX 6600GT AGP
TrueCombat: Q3A Mod - truecombat.com
technikolor is offline   Reply With Quote
Old 02-17-04, 01:52 PM   #5
Spudman
Registered User
 
Join Date: Jan 2004
Posts: 10
Default

I'm also getting the 'Badness in pci_find_subsys at drivers/pci/search.c:167'

I've two machines running the 2.6.2 kernel & 4363 drivers (I need working overscan), but only one of them is giving me the error. I even tried a quick test & copied the kernel image from the error free machine, but it didn't solve the problem. Neither one is using the framebuffer.

The machine without a problem is an A7N8X-Deluxe with MX460(AGP) & MX420(PCI). The one with the problem is a Shuttle SN41G2 with onboard MX420. I'm still playing with settings to try to figure out what the difference between them is. Apart from an ever growing syslog, I haven't really had a problem & it just keeps on running.


Feb 17 19:30:06 julia kernel: Badness in pci_find_subsys at drivers/pci/search.c:167
Feb 17 19:30:06 julia kernel: Call Trace:
Feb 17 19:30:06 julia kernel: [<c0229e28>] pci_find_subsys+0xe8/0xf0
Feb 17 19:30:06 julia kernel: [<c0229e5f>] pci_find_device+0x2f/0x40
Feb 17 19:30:06 julia kernel: [<c0229c68>] pci_find_slot+0x28/0x50
Feb 17 19:30:06 julia kernel: [<dec07dc9>] os_pci_init_handle+0x39/0x70 [nvidia]
Feb 17 19:30:06 julia kernel: [<deaedacf>] __nvsym00015+0x1f/0x24 [nvidia]
Feb 17 19:30:06 julia kernel: [<debb4b2b>] __nvsym03985+0x1f/0x24 [nvidia]
Feb 17 19:30:06 julia kernel: [<deb91a20>] __nvsym03792+0x208/0x1c38 [nvidia]
Feb 17 19:30:06 julia kernel: [<c0127946>] update_process_times+0x46/0x60
Feb 17 19:30:06 julia kernel: [<c01277ab>] update_wall_time+0xb/0x40
Feb 17 19:30:06 julia kernel: [<c0127c1f>] do_timer+0xdf/0xf0
Feb 17 19:30:06 julia kernel: [<c0110dce>] timer_interrupt+0x4e/0x120
Feb 17 19:30:06 julia kernel: [<c010ccaa>] handle_IRQ_event+0x3a/0x70
Feb 17 19:30:06 julia kernel: [<deafb3ba>] __nvsym01479+0x3a/0x70 [nvidia]
Feb 17 19:30:06 julia kernel: [<c02a26b4>] kfree_skbmem+0x24/0x30
Feb 17 19:30:06 julia kernel: [<c02a2710>] __kfree_skb+0x50/0xc0
Feb 17 19:30:06 julia kernel: [<c02ed1d0>] packet_rcv_spkt+0x1a0/0x260
Feb 17 19:30:06 julia kernel: [<deafb3ba>] __nvsym01479+0x3a/0x70 [nvidia]
Feb 17 19:30:06 julia kernel: [<deafb3ba>] __nvsym01479+0x3a/0x70 [nvidia]
Feb 17 19:30:06 julia kernel: [<deb18964>] __nvsym01474+0x28/0x34 [nvidia]
Feb 17 19:30:06 julia kernel: [<deafb439>] __nvsym01439+0x49/0x90 [nvidia]
Feb 17 19:30:06 julia kernel: [<deb18a2b>] __nvsym01359+0x2b/0x34 [nvidia]
Feb 17 19:30:06 julia kernel: [<deafad64>] __nvsym01482+0x58/0x68 [nvidia]
Feb 17 19:30:06 julia kernel: [<deafacaf>] __nvsym01427+0x27/0x44 [nvidia]
Feb 17 19:30:06 julia kernel: [<deb18c23>] __nvsym01306+0x37/0x40 [nvidia]
Feb 17 19:30:06 julia kernel: [<deb946a3>] __nvsym03801+0x1253/0x1260 [nvidia]
Feb 17 19:30:06 julia kernel: [<deb91766>] __nvsym03794+0x20e/0x2c0 [nvidia]
Feb 17 19:30:06 julia kernel: [<deb96d0d>] __nvsym03839+0xc5/0x418 [nvidia]
Feb 17 19:30:06 julia kernel: [<deb96c00>] __nvsym03823+0x68/0xb0 [nvidia]
Feb 17 19:30:06 julia kernel: [<deb8ca5d>] __nvsym00553+0x85/0x944 [nvidia]
Feb 17 19:30:06 julia kernel: [<c010d064>] do_IRQ+0xb4/0x130
Feb 17 19:30:06 julia kernel: [<c011b31e>] recalc_task_prio+0x8e/0x1b0
Feb 17 19:30:06 julia kernel: [<debb750a>] __nvsym00630+0x9a/0x17c [nvidia]
Feb 17 19:30:06 julia kernel: [<deaeff89>] __nvsym00746+0xd/0x1c [nvidia]
Feb 17 19:30:06 julia kernel: [<deaf0bd0>] rm_isr_bh+0xc/0x10 [nvidia]
Feb 17 19:30:06 julia kernel: [<c0123936>] tasklet_action+0x46/0x70
Feb 17 19:30:06 julia kernel: [<c0123750>] do_softirq+0x90/0xa0
Feb 17 19:30:06 julia kernel: [<c010d0ad>] do_IRQ+0xfd/0x130
Feb 17 19:30:06 julia kernel: [<c010b3f4>] common_interrupt+0x18/0x20
Feb 17 19:30:06 julia kernel: [<c0108753>] default_idle+0x23/0x30
Feb 17 19:30:06 julia kernel: [<c0116a29>] apm_cpu_idle+0x89/0x130
Feb 17 19:30:06 julia kernel: [<c0105000>] _stext+0x0/0x60
Feb 17 19:30:06 julia kernel: [<c01087bc>] cpu_idle+0x2c/0x40
Feb 17 19:30:06 julia kernel: [<c03c873a>] start_kernel+0x17a/0x1b0
Feb 17 19:30:06 julia kernel: [<c03c8480>] unknown_bootoption+0x0/0x100
Spudman is offline   Reply With Quote
Old 02-17-04, 03:22 PM   #6
technikolor
Registered User
 
Join Date: Jul 2003
Posts: 18
Default

Do you play games at all? Have you ever had brief lockups, afterwhich everything is fine?

Maybe the fact that you don't use the FB is why you get the error but aren't actually feeling the effects.
__________________
Tyan ThunderK7
Dual AthlonMP 1.2G
1GB PC2100 Reg ECC
XFX 6600GT AGP
TrueCombat: Q3A Mod - truecombat.com
technikolor is offline   Reply With Quote
Old 02-17-04, 07:07 PM   #7
tamran
Registered User
 
Join Date: Feb 2004
Location: Ft. Myers, FL
Posts: 67
Default More info .. Solved maybe?

I have been up for over 3 days now by disabling framebuffer. It was VesaFB that I was using btw.

I think it was the combination of agpgart, framebuffer and nvidia. Anyway, I've got agpgart and nvidia and it seems more stable.


technikolor: have you tried NvAGP "1" in your XF86Config-4 file, and disabled agpgart in the kernel? That fix worked for me on my other system with the same problems. I can't do it with amd64 though, as nvidia's agp driver doesn't work for that platform.

Tamran
tamran is offline   Reply With Quote
Old 02-18-04, 04:25 AM   #8
technikolor
Registered User
 
Join Date: Jul 2003
Posts: 18
Default

I rebuilt 2.6.2 and used NVidia module 5336... I played Q3A mods for about 20 minutes and while I hit several snags (a 10-40 second lag in play during which time the system spews the errors wer're mentioning) I didn't have any unrecoverable hangs. But that could also be luck. It's still a major pita.

I don't know whats going on here. The NV driver guys haven't addressed this problems (verbally or otherwise), or at least I haven't seen any record of them doing so, and the kernel guys are still admiate that it's not their problem.

I'm almost tempted to just turn the FB back on and use the XFree86 NV driver dispite it's many flaws.

And tamran, as I pointed out earlier, I am using NV AGP...... which means that NvAGP is set to 1.
__________________
Tyan ThunderK7
Dual AthlonMP 1.2G
1GB PC2100 Reg ECC
XFX 6600GT AGP
TrueCombat: Q3A Mod - truecombat.com
technikolor is offline   Reply With Quote

Old 02-18-04, 09:01 AM   #9
zander
NVIDIA Corporation
 
zander's Avatar
 
Join Date: Aug 2002
Posts: 3,740
Default

The Badness in pci_find_subsys at drivers/pci/search.c problem really is one of many possible symptoms of common stability problems; it has been discussed here and elsewhere in the past.

Many of the stability problems are old "friends" and neither kernel nor driver version dependent (many are Linux specific in the sense that they do not reproduce on Windows). The warning message itself is harmless: the actual problem has already occured by the time it is printed, was detected by the NVIDIA driver and a recovery attempt is being made; note that the warning is not necessarily followed by a hard system lockup, in many cases the error condition can be corrected and normal operation resumed (the system may be rendered unresponsive for a few seconds when this happens). There is no single works-for-all solution or even workaround for those who experience this or similar stability problems: the best one can do to solve them is to eliminate possible error sources one by one. It is unfortunate that one needs to deal with this at all, but it seems that this still is one of the prices one pays for using GNU/Linux...

The most common error sources are bad AGP/ACPI/APIC configurations (hardware/software), conflicts with vesafb/rivafb (using two independent drivers for a single piece of hardware is asking for trouble), ..., heavily patched (experimental) kernels, bad RAM and thermal stress (excess heat) due to insufficient cooling. There's the possibility of bugs in the NVIDIA driver as well, naturally, but they seem to account for no more than a fraction of the stability problems encountered.

If you find that your system doesn't work reliably, try to approach the problem systematically: disable ACPI and/or APIC support, disable vesafb (or rivafb), check the RAM with a dedicated memory test such as memtest86, ..., monitor the CPU and case temperatures, check if disabling AGP works (if it does, experiment with the configuration (switch the AGP GART driver, disable FW/SBA, throttle the transfer rate, check the README for additional things to try)), try different (older, newer, less experimental) kernels, try a different driver release, ... . These are just some suggestions, you will find more in the official documentation, on forums (such as this one), ..., and mailing lists.
zander is offline   Reply With Quote
Old 02-18-04, 02:22 PM   #10
technikolor
Registered User
 
Join Date: Jul 2003
Posts: 18
Default

I've followed a number of those routes, lists, forums (like this one), IRC, docs, etc.

The problem is finding a balance of functionality. I was running fine, at least 95% of the time, on 2.4.x. Things get better with the FB disabled. etc, etc. The killer is that most of the normal fixes are problematic for me.. such as I need an FB, VESA or Riva, for development. Disabling APIC/APCI on SMP systems can cause more problems than it solves (at least for me). And running older kernels means giving up alot of functionality and speed improvements.

I tend to play games for about 30 minutes to an hour each night to unwind after working on various projects, and it looks like the best solution ultimately is to reboot into a 2.4.20+ kernel pruned specifically for the job, which imho is impractical.

Thanx for the post zander. But i'd still much rather hear a "oh, found it! here's te fix" responce. Oh well.

technikolor
__________________
Tyan ThunderK7
Dual AthlonMP 1.2G
1GB PC2100 Reg ECC
XFX 6600GT AGP
TrueCombat: Q3A Mod - truecombat.com
technikolor is offline   Reply With Quote
Old 02-18-04, 03:10 PM   #11
zander
NVIDIA Corporation
 
zander's Avatar
 
Join Date: Aug 2002
Posts: 3,740
Default

For what it's worth, it typically is UP I/O APIC configurations that are broken, SMP systems should work fine. ACPI mileage varies with the system BIOS and system software (i.e. the kernel), the latter is still not as mature as one would like it to be, the former broken more often than not. The problem with vesafb is highly configuration (hardware, BIOS, kernel, driver) dependent and supposedly got worse with recent NVIDIA driver releases, 1.0-4365 and earlier have been reported to be able to coexist with vesafb where 1.0-4496 and later releases fail; most of the fbdev related problems occur at the time of the initial startup or in response to vt switches, though. I don't know how well the vesafb vs. nvidia interaction difficulties are understood, but since neither driver is aware of the other, trouble is to be expected.
zander is offline   Reply With Quote
Old 02-18-04, 04:27 PM   #12
darkhelmet03
Registered User
 
Join Date: Jul 2003
Posts: 62
Default

Had exactly the same problem with you on 2.6.2
Thus KDE 3.2 is not the cause, it seems driver specific

See my post on "2.6.2 Kernel Bandess ..." for more info...
darkhelmet03 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


All times are GMT -5. The time now is 08:27 PM.


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