Did PCI/IRQ allocation change significantly after 4.2 kernel?

From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Did PCI/IRQ allocation change significantly after 4.2 kernel?
Date: Tue, 29 Mar 2016 08:43:53 -0700	[thread overview]
Message-ID: <20160329154353.GA26108@kroah.com> (raw)
In-Reply-To: <1459265269.2010.7.camel@rtd-VirtualBox>

On Tue, Mar 29, 2016 at 11:27:49AM -0400, Rob Groner wrote:
> On Tue, 2016-03-29 at 07:43 -0700, Greg KH wrote:
> > On Tue, Mar 29, 2016 at 07:42:44AM -0700, Greg KH wrote:
> > > On Tue, Mar 29, 2016 at 02:15:23PM +0000, Rob Groner wrote:
> > > > I?m investigating why our drivers no longer work correctly after the 4.2
> > > > kernel.  I have verified that in the 4.4 kernel, interrupts no longer work for
> > > > us as they did before.  Here are the symptoms:
> > > 
> > > What drivers are these?  Do you have a pointer to the source for them?
> > > 
> > > And what platform are you having these problems on, x86, arm64,
> > > something else?
> 
> x86 only (we don't support other platforms).  An example of the code
> (this problem appears to be affecting all of our drivers so far) is on
> our website.
> 
> http://www.rtd.com/software/DM/DM35x18/DM35418_Linux_v03.00.00.tar.gz
> 
> If you end up looking at the driver code, I apologize in advance for all
> of the obvious errors you might find.  It's a little intimidating having
> one of the authors of LDD look at your code... I feel like I didn't
> study hard enough for this.  

Heh, no worries.  One question, why are you saving off the pci irq
before you call request_irq()?  You shouldn't care what the number is,
and with MSI and other fun, you might get a "different" irq number than
the main PCI device was because nothing was really assigned to it just
yet.

Also, why not submit this for inclusion in the main kernel tree?  That
will make your ongoing maintenance of the code much easier.

> > Also, can you use 'git bisect' to find the problem commit?  That might
> > be the easiest way forward.
> 
> Umm...yes!  As soon as I figure out what that means.  I'm a git newbie
> (we use svn), but I shall learn as quickly as I can.  I take it that it
> basically means "start with a kernel that worked and then start moving
> forward through commits until I find the one that broke", right?

Yes, but it uses a tree search, making it faster than just "one commit
after each other"  Read 'man git-bisect' for all of the details.

thanks,

greg k-h