Badness in pci_find_subsys

Badness in pci_find_subsys

[Robin Rosenberg]

There is a regular error (2.6.1,2.6.2) that locks up my X although I don't know if it has anything to
do with X per se other than that after every lockup i find an error in syslog.

Feb 22 18:23:25 h6n2fls33o811 kernel: Badness in pci_find_subsys at drivers/pci/search.c:167
Feb 22 18:23:25 h6n2fls33o811 kernel: Call Trace:
Feb 22 18:23:25 h6n2fls33o811 kernel:  [pci_find_subsys+215/224] pci_find_subsys+0xd7/0xe0
Feb 22 18:23:25 h6n2fls33o811 kernel:  [<c01c5897>] pci_find_subsys+0xd7/0xe0
Feb 22 18:23:25 h6n2fls33o811 kernel:  [pci_find_device+24/32] pci_find_device+0x18/0x20
Feb 22 18:23:25 h6n2fls33o811 kernel:  [<c01c58b8>] pci_find_device+0x18/0x20
Feb 22 18:23:25 h6n2fls33o811 kernel:  [pci_find_slot+26/96] pci_find_slot+0x1a/0x60
Feb 22 18:23:25 h6n2fls33o811 kernel:  [<c01c56fa>] pci_find_slot+0x1a/0x60
Feb 22 18:23:25 h6n2fls33o811 kernel:  [__crc___lock_sock+2862576/4902775] 0xe1301876
	:
	:
Feb 22 18:23:25 h6n2fls33o811 kernel:  [__crc___lock_sock+2854065/4902775] 0xe12ff737
Feb 22 18:23:25 h6n2fls33o811 kernel:  [<e12ff737>] 0xe12ff737
Feb 22 18:23:25 h6n2fls33o811 kernel:  [tasklet_action+57/112] tasklet_action+0x39/0x70
Feb 22 18:23:25 h6n2fls33o811 kernel:  [<c0126559>] tasklet_action+0x39/0x70
Feb 22 18:23:25 h6n2fls33o811 kernel:  [do_softirq+97/192] do_softirq+0x61/0xc0
Feb 22 18:23:25 h6n2fls33o811 kernel:  [<c0126321>] do_softirq+0x61/0xc0
Feb 22 18:23:25 h6n2fls33o811 kernel:  [do_IRQ+229/256] do_IRQ+0xe5/0x100
Feb 22 18:23:25 h6n2fls33o811 kernel:  [<c010d855>] do_IRQ+0xe5/0x100
Feb 22 18:23:25 h6n2fls33o811 kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
Feb 22 18:23:25 h6n2fls33o811 kernel:  [<c010bf38>] common_interrupt+0x18/0x20

The stack dump comes out twice with the same time stamp (same in dmesg so I assume the
error occurs twice).

My hardware  is a Dell Dimension XPS T700 and lspci

-[00]-+-00.0  Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge
      +-01.0-[01]----00.0  nVidia Corporation NV10 [GeForce 256 SDR]
      +-07.0  Intel Corp. 82371AB/EB/MB PIIX4 ISA
      +-07.1  Intel Corp. 82371AB/EB/MB PIIX4 IDE
      +-07.2  Intel Corp. 82371AB/EB/MB PIIX4 USB
      +-07.3  Intel Corp. 82371AB/EB/MB PIIX4 ACPI
      +-0d.0  3Com Corporation 3c905C-TX/TX-M [Tornado]
      +-0e.0  Brooktree Corporation Bt878 Video Capture
      +-0e.1  Brooktree Corporation Bt878 Audio Capture
      +-0f.0  Artop Electronic Corp AEC6712D SCSI
      +-10.0  Creative Labs SB Live! EMU10k1
      \-10.1  Creative Labs SB Live! MIDI/Game Port

More info @ http://qa.mandrakesoft.com/show_bug.cgi?id=6856

-- robin

Re: Badness in pci_find_subsys

[Prakash K. Cheemplavam]

Robin Rosenberg wrote:
> There is a regular error (2.6.1,2.6.2) that locks up my X although I don't know if it has anything to
> do with X per se other than that after every lockup i find an error in syslog.
> 
> Feb 22 18:23:25 h6n2fls33o811 kernel: Badness in pci_find_subsys at drivers/pci/search.c:167
> Feb 22 18:23:25 h6n2fls33o811 kernel: Call Trace:
> Feb 22 18:23:25 h6n2fls33o811 kernel:  [pci_find_subsys+215/224] pci_find_subsys+0xd7/0xe0
>
[snip]

It is Nvidia binary driver doing some crap.

Prakash

Re: Badness in pci_find_subsys

[vishwas manral]

Hi Robin/Prakash,

I was checking the pci documentation and it said under the heading Obsolete function

pci_find_subsys() - Superseded by pci_get_subsys() as the former is not Hot plug safe.

Could this be related to the problem?

Thanks,
Vishwas

--------- Original Message ---------

DATE: Sun, 22 Feb 2004 18:52:11
From: "Prakash K. Cheemplavam" <PrakashKC@gmx.de>
To: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Cc: Linux kernel <linux-kernel@vger.kernel.org>

>Robin Rosenberg wrote:
>> There is a regular error (2.6.1,2.6.2) that locks up my X although I don't know if it has anything to
>> do with X per se other than that after every lockup i find an error in syslog.
>> 
>> Feb 22 18:23:25 h6n2fls33o811 kernel: Badness in pci_find_subsys at drivers/pci/search.c:167
>> Feb 22 18:23:25 h6n2fls33o811 kernel: Call Trace:
>> Feb 22 18:23:25 h6n2fls33o811 kernel:  [pci_find_subsys+215/224] pci_find_subsys+0xd7/0xe0
>>
>[snip]
>
>It is Nvidia binary driver doing some crap.
>
>Prakash
>


____________________________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

Re: Badness in pci_find_subsys

[vishwas manral]

Hi Robin/Prakash,

I was checking the pci documentation and it said under the heading Obsolete function

pci_find_subsys() - Superseded by pci_get_subsys() as the former is not Hot plug safe.

Could this be related to the problem?

Thanks,
Vishwas

--------- Original Message ---------

DATE: Sun, 22 Feb 2004 18:52:11
From: "Prakash K. Cheemplavam" <PrakashKC@gmx.de>
To: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Cc: Linux kernel <linux-kernel@vger.kernel.org>

>Robin Rosenberg wrote:
>> There is a regular error (2.6.1,2.6.2) that locks up my X although I don't know if it has anything to
>> do with X per se other than that after every lockup i find an error in syslog.
>> 
>> Feb 22 18:23:25 h6n2fls33o811 kernel: Badness in pci_find_subsys at drivers/pci/search.c:167
>> Feb 22 18:23:25 h6n2fls33o811 kernel: Call Trace:
>> Feb 22 18:23:25 h6n2fls33o811 kernel:  [pci_find_subsys+215/224] pci_find_subsys+0xd7/0xe0
>>
>[snip]
>
>It is Nvidia binary driver doing some crap.
>
>Prakash
>


____________________________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

Re: Badness in pci_find_subsys

[Robin Rosenberg]

On Monday 23 February 2004 05.44, vishwas manral wrote:
> Hi Robin/Prakash,
> 
> I was checking the pci documentation and it said under the heading Obsolete function
> pci_find_subsys() - Superseded by pci_get_subsys() as the former is not Hot plug safe.
> Could this be related to the problem

You WHAT? Read the documentation! :-) I thought the ones calling the function should do that.

I dunno, I'm not hotplugging anything and it crashes anyway, The functionality is there since
I want to hotplug a camera sometimes. but I'm not always "doing it" during uptimes that have
the crash. Anyway I assume the crux here is PCI hotplug that my machine does not do; you
need special support on the motherboard for that, right?

I found some options to try out, but no conclusive info, at the nvidia linux discussion forum.

-- robin

Re: Badness in pci_find_subsys

[Martin]

On Monday 23 February 2004 06:39, Robin Rosenberg wrote:

> > I was checking the pci documentation and it said under the heading
> > Obsolete function pci_find_subsys() - Superseded by pci_get_subsys() as
> > the former is not Hot plug safe. Could this be related to the problem
>
> You WHAT? Read the documentation! :-) I thought the ones calling the
> function should do that.

Reading the documentation (ie. source code) it appears the problem is 
triggered by the line

WARN_ON(in_interrupt());

Looks like the driver calls pci_find_subsys() from inside an interrupt on 
occasions which apparently it shouldn't. The problem seems to be on 
nvidia's side, not kernel development. I have emailed nvidia about it some 
time ago, so far no reaction... 

I got the problem with nvidia modules 4496, 5328, 5336 and with kernels 
2.6.0, 2.6.1, 2.6.2, never with 2.4.X. I have stopped using the nvidia 
kernel module for now.

> I found some options to try out, but no conclusive info, at the nvidia
> linux discussion forum.

Is this www.nvnews.net you are talking about? I can't find any proper 
contacts on the nvidia web site. I'll go over and add a comment right 
now. ;-)

cu Martin

Re: Badness in pci_find_subsys

[Robin Rosenberg]

On Monday 23 February 2004 08.30, Martin wrote:
> Reading the documentation (ie. source code) it appears the problem is 
> triggered by the line
> 
> WARN_ON(in_interrupt());
> 
> Looks like the driver calls pci_find_subsys() from inside an interrupt on 
> occasions which apparently it shouldn't. The problem seems to be on 
> nvidia's side, not kernel development. I have emailed nvidia about it some 
> time ago, so far no reaction... 

Tracing the stack, I see:

pci_find_subsys is deprecated which is called from
pci_find_device which is deprecated which is called from
pci_find_slot, which is NOT deprecated.

-- robin

Re: Badness in pci_find_subsys

[Greg KH]

On Mon, Feb 23, 2004 at 08:30:44AM +0100, Martin wrote:
> On Monday 23 February 2004 06:39, Robin Rosenberg wrote:
> 
> > > I was checking the pci documentation and it said under the heading
> > > Obsolete function pci_find_subsys() - Superseded by pci_get_subsys() as
> > > the former is not Hot plug safe. Could this be related to the problem
> >
> > You WHAT? Read the documentation! :-) I thought the ones calling the
> > function should do that.
> 
> Reading the documentation (ie. source code) it appears the problem is 
> triggered by the line
> 
> WARN_ON(in_interrupt());
> 
> Looks like the driver calls pci_find_subsys() from inside an interrupt on 
> occasions which apparently it shouldn't. The problem seems to be on 
> nvidia's side, not kernel development. I have emailed nvidia about it some 
> time ago, so far no reaction... 

This is correct, that function should not be called from within an
interrupt.  That is just stupid programming...

thanks,

greg k-h

Re: Badness in pci_find_subsys

[Tobias Oed]

Date: Mon, 23 Feb 2004 11:51:45 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Please cc me as I'm not subscribed to the list.

Robin Rosenberg wrote:

>Tracing the stack, I see:
>
>pci_find_subsys is deprecated which is called from
>pci_find_device which is deprecated which is called from
>pci_find_slot, which is NOT deprecated.
>

I noticed that a while ago and modified the nvidia kernel interface 
(os-interface.c): I save a reference to struct pci_dev and return that when 
called in interrupt context [*]. Unfortunately it doesn't fix the problem: 
the badness goes away as expected but X is still frozen.
>From what I understand it's an agp related problem (specially on via 
chipset). The driver is hopelessly confused and tries to reinit itself and 
the card. Limiting my agp rate to x2in the bios makes things stable. With 
that even gaim runs stable. (gaim triggers the problem  systematically when 
displaying the buddy list if I use agp x4).
btw I'm running 4620 as all later releases of the driver have terrible 
performance with my tnt2.

[*]
Do I need to hold the pci_bus_lock spinlock for the following (checks for 
NULL omitted here)
dev = pci_find_slot(bus, PCI_DEVFN(slot, function));
dev = pci_dev_get(dev);
I'd rater use pci_get_slot instead of pci_find_slot, but I don't know how to 
get a struct pci_bus *  from an int.

Tobias.

_________________________________________________________________
Watch high-quality video with fast playback at MSN Video. Free! 
http://click.atdmt.com/AVE/go/onm00200365ave/direct/01/

Re: Badness in pci_find_subsys

[Greg KH]

On Mon, Feb 23, 2004 at 08:51:45AM -0800, Tobias Oed wrote:
> [*]
> Do I need to hold the pci_bus_lock spinlock for the following (checks for 
> NULL omitted here)
> dev = pci_find_slot(bus, PCI_DEVFN(slot, function));
> dev = pci_dev_get(dev);
> I'd rater use pci_get_slot instead of pci_find_slot, but I don't know how to 
> get a struct pci_bus *  from an int.

You should never need to use those functions at all anyway.  Just use
the proper pci_register_driver() call and be done with it.

thanks,

greg k-h

Re: Badness in pci_find_subsys

[Tobias Oed]

Greg KH wrote:

>On Mon, Feb 23, 2004 at 08:51:45AM -0800, Tobias Oed wrote:
>>[*]
>>Do I need to hold the pci_bus_lock spinlock for the following (checks for
>>NULL omitted here)
>>dev = pci_find_slot(bus, PCI_DEVFN(slot, function));
>>dev = pci_dev_get(dev);
>>I'd rater use pci_get_slot instead of pci_find_slot, but I don't know how
>>to
>>get a struct pci_bus *  from an int.
>
>You should never need to use those functions at all anyway.  Just use
>the proper pci_register_driver() call and be done with it.
>
>thanks,
>
>greg k-h

Thanks for pointing that out. I don't know what I'm doing and starting by 
trying to fix a closed source driver is not making it any easier.
As Robin Rosenberg said elsethread, you may want to consider the following 
patch to warn programmers more consistently
Cheers, Tobias.
--- search.c.orig       2004-02-23 18:05:41.627162872 -0500
+++ search.c    2004-02-23 18:06:24.292676728 -0500
@@ -90,6 +90,10 @@
  * is located in system global list of PCI devices.  If the device
  * is found, a pointer to its data structure is returned.  If no
  * device is found, %NULL is returned.
+ *
+ * NOTE: Do not use this function anymore, use pci_get_slot() instead, as
+ * the pci device returned by this function can disappear at any moment in
+ * time.
  */
struct pci_dev *
pci_find_slot(unsigned int bus, unsigned int devfn)

_________________________________________________________________
Dream of owning a home? Find out how in the First-time Home Buying Guide. 
http://special.msn.com/home/firsthome.armx