Interrupt stom on cardbus device
Robert Noland
rnoland at FreeBSD.org
Sat Feb 28 08:38:43 PST 2009
On Sat, 2009-02-28 at 12:02 +0300, Nasonov Sergey wrote:
> > -----Original Message-----
> > From: Robert Noland [mailto:rnoland at FreeBSD.org]
> > Sent: Saturday, February 28, 2009 2:44 AM
> > To: Nasonov Sergey
> > Cc: John Baldwin; freebsd-current at freebsd.org
> > Subject: RE: Interrupt stom on cardbus device
> >
> > On Sat, 2009-02-28 at 00:09 +0300, Nasonov Sergey wrote:
> > > > -----Original Message-----
> > > > From: John Baldwin [mailto:jhb at freebsd.org]
> > > > Sent: Friday, February 27, 2009 10:04 PM
> > > > To: Robert Noland
> > > > Cc: freebsd-current at freebsd.org; Nasonov Sergey
> > > > Subject: Re: Interrupt stom on cardbus device
> > > >
> > > > On Friday 27 February 2009 1:50:28 pm Robert Noland wrote:
> > > > > On Fri, 2009-02-27 at 12:08 -0500, John Baldwin wrote:
> > > > > > On Friday 27 February 2009 9:30:06 am Sergey G Nasonov wrote:
> > > > > > > Hello all,
> > > > > > > I have get an issue after recent kernel recompile.
> > > > > > > The problem appears after switch from X to text console and
> back
> > > to
> > > > X11.
> > > > > > > After that vmstat -i show an interrupt storm on cardbus
> device:
> > > > > > >
> > > > > > > > vmstat -i
> > > > > > > interrupt total rate
> > > > > > > irq1: atkbd0 6483 3
> > > > > > > irq9: acpi0 3236 1
> > > > > > > irq12: psm0 347988 167
> > > > > > > irq14: ata0 16431 7
> > > > > > > irq16: cbb0 uhci2+ 13624982 6556
> > > > > > > irq20: uhci0 14 0
> > > > > > > irq22: ehci0 2 0
> > > > > > > cpu0: timer 4154687 1999
> > > > > > > irq256: em0 53736 25
> > > > > > > irq257: hdac0 5797 2
> > > > > > > cpu1: timer 4153683 1998
> > > > > > > irq258: vgapci0 235585 113
> > > > > > > Total 22602624 10877
> > > > > > >
> > > > > > > I suppose that the issue related with the latest MSI
> interrupt
> > > > > > > handler changes for intel graphics chipset. My laptop has
> > > i965GM.
> > > > > > > pciconf -lv:
> > > > > > >
> > > > > > > vgapci0 at pci0:0:2:0: class=0x030000 card=0x20b517aa
> > > > chip=0x2a028086
> > > > > > > rev=0x0c hdr=0x00
> > > > > > > vendor = 'Intel Corporation'
> > > > > > > device = 'Mobile 965 Express Integrated Graphics
> > > Controller'
> > > > > > > class = display
> > > > > > > subclass = VGA
> > > > > > >
> > > > > > > When I added my device to drm_msi_blacklist and recompile
> drm
> > > > modules
> > > > the
> > > > > > > problem disappear.
> > > > > > > Is it possible to resolve this problem without moving the
> device
> > > to
> > > > the
> > > > > > > drm_msi_blacklist?
> > > > > > > I can test any patches or provide additional detail if it is
> > > > required.
> > > > > > > Thanks.
> > > > > >
> > > > > > It seems the device is still interrupting on its INTx line
> perhaps
> > > in
> > > > addition
> > > > > > to the MSI interrupts.
> > > > >
> > > > > Hrm, I did most all of that development on a 965gm. When you VT
> > > switch,
> > > > > the irq handler gets uninstalled and reinstalled when you return
> to
> > > X.
> > > > > There was an eratta on the 965gm suggesting that msi didn't work
> > > right,
> > > > > but I was never able to produce the issue. Intel was having
> major
> > > > > issues with this on linux and I finally convinced them to turn
> msi
> > > back
> > > > > on. My irq handler and Eric's are very similar, so I'm not sure
> > > what
> > > > > could be going on here.
> > > > >
> > > > > There is however an issue with vblanks that might be related.
> Could
> > > you
> > > > > try
> http://people.freebsd.org/~rnoland/drm-move_vblank_init.patch
> > > and
> > > > > see if that helps?
> > >
> > > Ok, I tried it but result the same (problem not resolved).
> > > Can I check anything else?
> >
> > Ok, new patch... It is looking like we should actually deal with this
> in
> > the pci code, rather than drm, but let's try this patch and see if it
> > fixes the issue. Note that we are looking for interrupts to still
> work
> > (the msi ones anyway) and to not see the INTx ones.
> >
> > http://people.freebsd.org/~rnoland/i915_disable_INTx.patch
> >
> > robert.
>
> Unfortunately, your patch doesn't help. Maybe INTx is still enabled? But
> I think the problem somewhere herein.
> I compile DRM modules with DRM_DEBUG, but output is very large and find
> within it anything useful is hard.
Hrm, the intel driver is very noisy. If the problem really is INTx,
then the drm debugging won't know anything about that. Could you try
that patch that I posted later, without this patch to i915. I've looked
over the linux pci code and they do disable INTx when enabling MSI.
I stuck the patch up as
http://people.freebsd.org/~rnoland/pci_disable_intx.patch
robert.
> > > Thanks.
> > > >
> > > > In this case the issue isn't that MSI isn't working I think, but
> that
> > > the
> > > > hardware is sending interrupts via both routes (MSI and INTx). If
> > > that
> > > > happens, then you will see an interrupt storm on the INTx line,
> but
> > > > FreeBSD
> > > > will only notice if another device is sharing the same IRQ line.
> So
> > > if
> > > > your
> > > > test machine has vgapci0 on irq 22 and you have no other devices
> on
> > > IRQ
> > > > 22,
> > > > then the storm would go unnoticed. This is most likely a chip bug
> > > (unless
> > > > the driver has to explicitly disable INTx interrupts when using
> MSI).
> > > It
> > > > would probably be a good idea to add a hw.drm.msi_enable tunable
> (or
> > > > hw.drm.msi) that people can use to disable MSI perhaps.
> > > >
> > > > --
> > > > John Baldwin
> > --
> > Robert Noland <rnoland at FreeBSD.org>
> > FreeBSD
--
Robert Noland <rnoland at FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090228/c6578225/attachment.pgp
More information about the freebsd-current
mailing list