2.6.5 and "Badness in pci_find_subsys"

[msillence]

Hi,

I have a micro-atx motherboard with a nforce2 chipset and onboard graphics card gforce4 mx. (Asus A7N8X-VM)
I downloaded the NVIDIA-Linux-x86-1.0-5336-pkg1.run package as I was having stability problems with the Xfree nv driver currently in debian testing.

However the nvidia driver causes kernel panics.

Subset of the stack trace below:

--
Thanks,
M


May 3 19:05:23 localhost kernel: 0: nvidia: loading NVIDIA Linux x86 NVIDIA Kernel Module 1.0-5336 Wed Jan 14 18:29:26 PST
2004
May 3 19:05:24 localhost kernel: x70 [nvidia]
May 3 19:05:24 localhost kernel: [<df02434b>] _nv001532rm+0x1f/0x28 [nvidia]
May 3 19:05:24 localhost kernel: [<defc91f8>] _nv002547rm+0x4c/0x58 [nvidia]
May 3 19:05:24 localhost kernel: [<def4dd0e>] _nv001370rm+0x2e/0xcc [nvidia]
May 3 19:05:24 localhost kernel: [<def4dd0e>] _nv001370rm+0x2e/0xcc [nvidia]
May 3 19:05:24 localhost kernel: [<df0242fc>] _nv001534rm+0x20/0x28 [nvidia]
May 3 19:05:24 localhost kernel: [<def87d9f>] _nv004739rm+0x2b/0x34 [nvidia]
May 3 19:05:24 localhost kernel: [<def4dd0e>] _nv001370rm+0x2e/0xcc [nvidia]
May 3 19:05:24 localhost kernel: [<df0242fc>] _nv001534rm+0x20/0x28 [nvidia]
May 3 19:05:24 localhost kernel: [<def63a19>] _nv004363rm+0x59/0x90 [nvidia]
May 3 19:05:24 localhost kernel: [<def87d9f>] _nv004739rm+0x2b/0x34 [nvidia]
May 3 19:05:24 localhost kernel: [<def9a4ce>] _nv004083rm+0x2776/0x313c [nvidia]
May 3 19:05:24 localhost kernel: [<def9a50f>] _nv004083rm+0x27b7/0x313c [nvidia]
May 3 19:05:24 localhost kernel: [<c0150ca5>] __find_get_block+0x45/0xb0
May 3 19:05:24 localhost kernel: [<c0150ca5>] __find_get_block+0x45/0xb0
May 3 19:05:24 localhost kernel: [<c0150d3b>] __getblk+0x2b/0x60
May 3 19:05:24 localhost kernel: [<c019cb05>] is_tree_node+0x65/0x70
May 3 19:05:24 localhost kernel: [<c019d145>] search_by_key+0x635/0xde0
May 3 19:05:24 localhost kernel: [<c01a5d78>] check_journal_end+0x178/0x290
May 3 19:05:24 localhost kernel: [<c01a6333>] do_journal_end+0xd3/0xc60
May 3 19:05:24 localhost kernel: [<c0151920>] __block_commit_write+0x80/0x90
May 3 19:05:24 localhost kernel: [<c01520da>] generic_commit_write+0x4a/0x90
May 3 19:05:24 localhost kernel: [<c018ca01>] reiserfs_commit_write+0x131/0x160
May 3 19:05:24 localhost kernel: [<df02448b>] _nv001556rm+0x5b/0x6c [nvidia]
May 3 19:05:24 localhost kernel: [<def4e595>] _nv001338rm+0x1d/0x24 [nvidia]
May 3 19:05:24 localhost kernel: [<df08d6ac>] _nv005722rm+0x888/0x960 [nvidia]
May 3 19:05:24 localhost kernel: [<def61267>] _nv005638rm+0x5f/0xb0 [nvidia]
May 3 19:05:24 localhost kernel: [<df006c2d>] _nv003795rm+0x309/0xaec [nvidia]
May 3 19:05:24 localhost kernel: [<def71267>] _nv004046rm+0x3a3/0x3b0 [nvidia]
May 3 19:05:24 localhost kernel: [<df072ba7>] _nv001476rm+0x277/0x45c [nvidia]
May 3 19:05:24 localhost kernel: [<def5b39a>] _nv000896rm+0x4a/0x64 [nvidia]
May 3 19:05:24 localhost kernel: [<def5cbb4>] rm_isr_bh+0xc/0x10 [nvidia]
May 3 19:05:24 localhost kernel: [<df0c1a91>] nv_kern_isr_bh+0xf/0x13 [nvidia]
May 3 19:05:24 localhost kernel: [<c0121c26>] tasklet_action+0x46/0x70
May 3 19:05:24 localhost kernel: [<c0121a50>] do_softirq+0x90/0xa0
May 3 19:05:24 localhost kernel: [<c0109673>] do_IRQ+0xc3/0xf0
May 3 19:05:24 localhost kernel: [<c0107ae8>] common_interrupt+0x18/0x20
May 3 19:05:24 localhost kernel:
May 3 19:05:24 localhost kernel: Badness in pci_find_subsys at drivers/pci/search.c:167
May 3 19:05:24 localhost kernel: Call Trace:
May 3 19:05:24 localhost kernel: [<c01bb537>] pci_find_subsys+0xc7/0xd0
May 3 19:05:24 localhost kernel: [<c01bb56f>] pci_find_device+0x2f/0x40
May 3 19:05:24 localhost kernel: [<c01bb3b8>] pci_find_slot+0x28/0x50

[LordMorgul]

Welcome to the board, and the hell that is 'pci_find_subsys'. Take a moment to search the board for this string and read through some of the longer threads for more information and what others have discovered (which unfortunately... is not much). The problem, afaik, is not fixed yet.

[MadEgg]

I'm back to using 4363 which works extremely well for me, no more Badness in pci_find_subsys, no more console garbage, no more lock-ups.
Worked a lot better than updating my video bios...

[msillence]

Thanks so much for the 4363 pointer.
Seems to have lasted twice the time of anything so far - 10 mins and counting...

I checked out the links. Tested my memory, turned off acpi and changed the pci probing optinos, found I had turned on framebuffer - but had no framebuffer driver.
Still the same problems with the 5336 driver and the nv driver in X 4.3 doesn't last longer than two or three mouse clicks.

Hope someone takes this seriously, I had been rather pleased with nviidia hardware in the past, hence the purchase of this board.

--
Thanks,
M

[msillence]

Spoke too soon, my kernel log is filling up with pci_find_subsys just the machine doesn't lock hard anymore...

Looks like it only lasted 1 second before things went wrong:

May 5 23:26:30 localhost kernel: 0: nvidia: loading NVIDIA Linux x86 nvidia.o K
ernel Module 1.0-4363 Sat Apr 19 17:46:46 PDT 2003
May 5 23:26:31 localhost kernel: > [<c0104648>] gunzip+0x68/0xa20
May 5 23:26:31 localhost kernel: [<c010717b>] syscall_call+0x7/0xb
May 5 23:26:31 localhost kernel: [<c0104648>] gunzip+0x68/0xa20
May 5 23:26:31 localhost kernel:
May 5 23:26:31 localhost kernel: Badness in pci_find_subsys at drivers/pci/sear
ch.c:167
May 5 23:26:31 localhost kernel: Call Trace:
May 5 23:26:31 localhost kernel: [<c01bb537>] pci_find_subsys+0xc7/0xd0




--
M

[msillence]

Ha!

Think I'm finally on to something... Found a thread, well several about memory and built in graphics card problems. Seem the list of supported memory for my motherboard is vital and the memory tests will work but the graphics card won't is a know "feature".
So a probable hardware issue.
See thread:
http://www.motherboard-forum.com/asu...ng_571205.html

So I'm off to buy another graphics card and see it that fixes it.
--
Thanks,
M

[msillence]

Bought a new graphics card (Nvidia mx4000) and low and behold problems are gone.
Using the same 5336 driver and 2.6.5 kernel and same mb/memory. Just not using the built in graphics card any more.

So it looks like for me at least it was a memory hardware issue, nasty in that without running anything graphical, memory tests passed OK.

Thanks and hope this saves someone some time.

--
M

[Ost99]

I found that using the 333MHz setting for ram (instead of 400MHz), stopped the system from crashing. (I use certified twin-packed dual chanel 400MHz 256MB dimms).

I still get random pci_find_subsys errors, but the system doesn't crash.

I've also read somewhere that setting the onboard GPU to use 128MB shared memory might help. I haven't tried this myself.

[MadEgg]

Originally Posted by msillence

Bought a new graphics card (Nvidia mx4000) and low and behold problems are gone.
Using the same 5336 driver and 2.6.5 kernel and same mb/memory. Just not using the built in graphics card any more.

So it looks like for me at least it was a memory hardware issue, nasty in that without running anything graphical, memory tests passed OK.

Thanks and hope this saves someone some time.

--
M

Hmmz, you're right. With 4363 the amount of problems with the driver have enormously decreased. But pci_find_subsys badness still occurs I found out yesterday. I tried to watch a movie using mplayer and it locked up my X.org 3 times. I didn't have another computer around to SSH in and kill X to omit a reboot but luckily I could get it to sync/umount/reboot quite nicely using the SysRq system.

Anyway, after the reboot I checked out my kernel-logfiles and it seems that at the time of the crash some nasty pci_find_subsys badnesses popped up.

I really hope this will get fixed soon. I'm able to get around the sometimes bad performance, the missing/partially-working/non-userfriendly features and that kind of stuff. But a stable driver that doesn't crash X should be a must within one or two months.

BTW, I read here and there that nVidia's drivers are made up by 90% code from a shared codebase across Windows/Linux/FreeBSD. The remaining 10% is OS-specific. Isn't that the part that IS opensource in the Linux-kernel driver?
Probably not, otherwise they would've been fixed already I suppose. Just a thought, I don't really know much about the inner workings of the nvidia-driver or any hardware driver at all...

[msillence]

Originally Posted by Ost99

I found that using the 333MHz setting for ram (instead of 400MHz), stopped the system from crashing. (I use certified twin-packed dual chanel 400MHz 256MB dimms).

I still get random pci_find_subsys errors, but the system doesn't crash.

I've also read somewhere that setting the onboard GPU to use 128MB shared memory might help. I haven't tried this myself.

I tried setting the memory to 128MB but it didn't help me.
I don't have any options to set the memory to 333MHz it correctly detects I have 333MHz memeory. I did check the spec of the board enough to know that it couldn't do 400MHz and on board graphics, I just didn't expect it to be so picky about the memory other than that.

Anyway I'm rather pleased that I bought another card, it definatly feels a lot snappier.

M

[LordMorgul]

Originally Posted by MadEgg

BTW, I read here and there that nVidia's drivers are made up by 90% code from a shared codebase across Windows/Linux/FreeBSD. The remaining 10% is OS-specific. Isn't that the part that IS opensource in the Linux-kernel driver?

No, the open source part of the 'code' is no more than glue to stick the nVIDIA code to the kernel and let them talk back and forth... there is essentially no 'code' for the driver there, it is all closed source.