|
Interrupt stom on cardbus device
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@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.
--
Best Regards,
Nasonov Sergey
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-currentTo unsubscribe, send any mail to " freebsd-current-unsubscribe@..."
|
|
Re: Interrupt stom on cardbus device
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@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.
--
John Baldwin
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-currentTo unsubscribe, send any mail to " freebsd-current-unsubscribe@..."
|
|
Re: Interrupt stom on cardbus device
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@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?
robert.
--
Robert Noland < rnoland@...>
FreeBSD
|
|
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@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?
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
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-currentTo unsubscribe, send any mail to " freebsd-current-unsubscribe@..."
|
|
Re: Interrupt stom on cardbus device
On Fri, 2009-02-27 at 14:03 -0500, John Baldwin wrote:
> 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@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?
>
> 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.
Ok, I do have docs on the 965, so I'll look at this. The linux version
does not do this, unless the OS does it in the background somewhere.
I thought about adding a tuneable, but I have to figure out how that
works first... ;)
robert.
--
Robert Noland < rnoland@...>
FreeBSD
|
|
Re: Interrupt stom on cardbus device
On Friday 27 February 2009 2:11:04 pm Robert Noland wrote:
> On Fri, 2009-02-27 at 14:03 -0500, John Baldwin wrote:
> > 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@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?
> >
> > 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.
>
> Ok, I do have docs on the 965, so I'll look at this. The linux version
> does not do this, unless the OS does it in the background somewhere.
Perhaps Eric can help to answer a question about the hardware in this case.
> I thought about adding a tuneable, but I have to figure out how that
> works first... ;)
You can basically do something like this:
int drm_msi = 1; /* Enable by default. */
TUNABLE_INT("hw.drm.msi", &drm_msi);
And later don't enable msi if it is zero.
--
John Baldwin
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-currentTo unsubscribe, send any mail to " freebsd-current-unsubscribe@..."
|
|
RE: Interrupt stom on cardbus device
> -----Original Message-----
> From: John Baldwin [mailto: jhb@...]
> Sent: Friday, February 27, 2009 10:04 PM
> To: Robert Noland
> Cc: freebsd-current@...; 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@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.patchand
> > see if that helps?
Ok, I tried it but result the same (problem not resolved).
Can I check anything else?
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
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-currentTo unsubscribe, send any mail to " freebsd-current-unsubscribe@..."
|
|
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@...]
> > Sent: Friday, February 27, 2009 10:04 PM
> > To: Robert Noland
> > Cc: freebsd-current@...; 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@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.patchrobert.
> 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@...>
FreeBSD
|
|
Re: Interrupt stom on cardbus device
On Fri, 2009-02-27 at 15:02 -0500, John Baldwin wrote:
> On Friday 27 February 2009 2:11:04 pm Robert Noland wrote:
> > On Fri, 2009-02-27 at 14:03 -0500, John Baldwin wrote:
> > > 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@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?
> > >
> > > 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.
> >
> > Ok, I do have docs on the 965, so I'll look at this. The linux version
> > does not do this, unless the OS does it in the background somewhere.
Ok, so I looked over the 965 docs again and noticed PCIR_COMMAND bit 10.
Then I pulled up the AMD docs on their PCIE cards and they also have
this bit. I made an test patch for just the i915 driver to ensure that
this fixes the issue, but it seems like a more general fix is in order.
I'm proposing to disable INTx when we setup MSI/MSIX interrupts. I
talked with scottl@ about this a bit last night and this seems like the
right thing to do, or at least it shouldn't hurt much...
John, what do you think of the attached patch?
robert.
> Perhaps Eric can help to answer a question about the hardware in this case.
>
> > I thought about adding a tuneable, but I have to figure out how that
> > works first... ;)
>
> You can basically do something like this:
>
> int drm_msi = 1; /* Enable by default. */
> TUNABLE_INT("hw.drm.msi", &drm_msi);
>
> And later don't enable msi if it is zero.
>
--
Robert Noland < rnoland@...>
FreeBSD
[pci_disable_intx.patch]
Index: dev/pci/pci.c
===================================================================
--- dev/pci/pci.c (revision 189044)
+++ dev/pci/pci.c (working copy)
@@ -2864,6 +2864,8 @@
}
mte->mte_handlers++;
}
+ /* Disable INTx if we are using MSI/MSIX */
+ pci_set_command_bit(dev, child, PCIM_CMD_INTxDIS);
bad:
if (error) {
(void)bus_generic_teardown_intr(dev, child, irq,
@@ -2918,6 +2920,8 @@
if (mte->mte_handlers == 0)
pci_mask_msix(child, rid - 1);
}
+ /* Restore INTx capability for MSI/MSIX */
+ pci_clear_command_bit(dev, child, PCIM_CMD_INTxDIS);
}
error = bus_generic_teardown_intr(dev, child, irq, cookie);
if (device_get_parent(child) == dev && rid > 0)
Index: dev/pci/pcireg.h
===================================================================
--- dev/pci/pcireg.h (revision 189044)
+++ dev/pci/pcireg.h (working copy)
@@ -60,6 +60,7 @@
#define PCIM_CMD_PERRESPEN 0x0040
#define PCIM_CMD_SERRESPEN 0x0100
#define PCIM_CMD_BACKTOBACK 0x0200
+#define PCIM_CMD_INTxDIS 0x0400
#define PCIR_STATUS 0x06
#define PCIM_STATUS_CAPPRESENT 0x0010
#define PCIM_STATUS_66CAPABLE 0x0020
|
|
RE: Interrupt stom on cardbus device
> -----Original Message-----
> From: Robert Noland [mailto: rnoland@...]
> Sent: Saturday, February 28, 2009 2:44 AM
> To: Nasonov Sergey
> Cc: John Baldwin; freebsd-current@...
> 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@...]
> > > Sent: Friday, February 27, 2009 10:04 PM
> > > To: Robert Noland
> > > Cc: freebsd-current@...; 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@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.
>
> > 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@...>
> FreeBSD
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-currentTo unsubscribe, send any mail to " freebsd-current-unsubscribe@..."
|
|
RE: Interrupt stom on cardbus device
On Sat, 2009-02-28 at 12:02 +0300, Nasonov Sergey wrote:
> > -----Original Message-----
> > From: Robert Noland [mailto: rnoland@...]
> > Sent: Saturday, February 28, 2009 2:44 AM
> > To: Nasonov Sergey
> > Cc: John Baldwin; freebsd-current@...
> > 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@...]
> > > > Sent: Friday, February 27, 2009 10:04 PM
> > > > To: Robert Noland
> > > > Cc: freebsd-current@...; 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@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.patchrobert.
> > > 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@...>
> > FreeBSD
--
Robert Noland < rnoland@...>
FreeBSD
|
|
RE: Interrupt stom on cardbus device
|
|
RE: Interrupt stom on cardbus device
On Sat, 2009-02-28 at 20:38 +0300, Nasonov Sergey wrote:
> > 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>
> Great! After applying this patch the problem was resolved. Switch to VT
> an then back to X11 now work fine. Thanks!
Can you confirm that:
1. Interrupts are still working (the msi ones)
2. Interrupts are still working for other devices on the shared INTx
robert.
Robert Noland < rnoland@...>
FreeBSD
|
|
RE: Interrupt stom on cardbus device
> -----Original Message-----
> From: Robert Noland [mailto: rnoland@...]
> Sent: Saturday, February 28, 2009 8:50 PM
> To: Nasonov Sergey
> Cc: freebsd-current@...
> Subject: RE: Interrupt stom on cardbus device
>
> On Sat, 2009-02-28 at 20:38 +0300, Nasonov Sergey wrote:
> > > 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> >
> > Great! After applying this patch the problem was resolved. Switch to
VT
> > an then back to X11 now work fine. Thanks!
>
> Can you confirm that:
>
> 1. Interrupts are still working (the msi ones)
Yes, there is pciconf output:
> vmstat -i
interrupt total rate
irq1: atkbd0 1838 1
irq9: acpi0 2117 1
irq12: psm0 74850 58
irq14: ata0 10143 7
irq16: cbb0 uhci2+ 34852 27
irq19: ehci1 2 0
irq20: uhci0 13 0
irq22: ehci0 2 0
cpu0: timer 2570905 1999
irq256: em0 19 0
irq257: hdac0 28 0
cpu1: timer 2569860 1998
irq258: vgapci0 2523 1
Total 5267152 4095
and pciconf -lvc:
vgapci0@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
cap 05[90] = MSI supports 1 message
cap 01[d0] = powerspec 3 supports D0 D3 current D0
And from console (output after start X server):
drm0: <Intel i965GM> on vgapci0
[drm:pid1408:drm_attach] MSI count = 1
info: [drm] MSI enabled 1 message(s)
[drm:pid1408:drm_load]
[drm:pid1408:drm_addmap] offset = 0xf8100000, size = 0x00100000, type =
1
[drm:pid1408:drm_addmap] Added map 1 0xf8100000/0x100000
[drm:pid1408:i915_init_phys_hws] Enabled hardware status page
[drm:pid1408:drm_vblank_init]
vgapci0: child drm0 requested pci_enable_busmaster
[drm:pid1408:drm_agp_init] agp_available = 1
info: [drm] AGP at 0xe0000000 256MB
[drm:pid1408:drm_ctxbitmap_next] drm_ctxbitmap_next bit : 0
[drm:pid1408:drm_ctxbitmap_init] drm_ctxbitmap_init : 0
info: [drm] Initialized i915 1.6.0 20080730
> 2. Interrupts are still working for other devices on the shared INTx
Hmm, How to determine which device need to be checked?
Em0, hdac0 and ubsa0 modem work fine.
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-currentTo unsubscribe, send any mail to " freebsd-current-unsubscribe@..."
|
|
RE: Interrupt stom on cardbus device
On Sat, 2009-02-28 at 21:40 +0300, Nasonov Sergey wrote:
>
> > -----Original Message-----
> > From: Robert Noland [mailto: rnoland@...]
> > Sent: Saturday, February 28, 2009 8:50 PM
> > To: Nasonov Sergey
> > Cc: freebsd-current@...
> > Subject: RE: Interrupt stom on cardbus device
> >
> > On Sat, 2009-02-28 at 20:38 +0300, Nasonov Sergey wrote:
> > > > 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> > >
> > > Great! After applying this patch the problem was resolved. Switch to
> VT
> > > an then back to X11 now work fine. Thanks!
> >
> > Can you confirm that:
> >
> > 1. Interrupts are still working (the msi ones)
>
> Yes, there is pciconf output:
> > vmstat -i
> interrupt total rate
> irq1: atkbd0 1838 1
> irq9: acpi0 2117 1
> irq12: psm0 74850 58
> irq14: ata0 10143 7
> irq16: cbb0 uhci2+ 34852 27
> irq19: ehci1 2 0
> irq20: uhci0 13 0
> irq22: ehci0 2 0
> cpu0: timer 2570905 1999
> irq256: em0 19 0
> irq257: hdac0 28 0
> cpu1: timer 2569860 1998
> irq258: vgapci0 2523 1
> Total 5267152 4095
Ok, I'll wait for John to review this, but hopefully we can commit
something like this next week. I think this is a case of a loose
interpretation of the pci spec. It states that a device using MSI is
prohibited from using INTx, but I'm guessing that at least some of the
hardware guys felt that it was the drivers job to enforce that, while
others do it in hardware.
> and pciconf -lvc:
> vgapci0@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
> cap 05[90] = MSI supports 1 message
> cap 01[d0] = powerspec 3 supports D0 D3 current D0
>
> And from console (output after start X server):
>
> drm0: <Intel i965GM> on vgapci0
> [drm:pid1408:drm_attach] MSI count = 1
> info: [drm] MSI enabled 1 message(s)
> [drm:pid1408:drm_load]
> [drm:pid1408:drm_addmap] offset = 0xf8100000, size = 0x00100000, type =
> 1
> [drm:pid1408:drm_addmap] Added map 1 0xf8100000/0x100000
> [drm:pid1408:i915_init_phys_hws] Enabled hardware status page
> [drm:pid1408:drm_vblank_init]
> vgapci0: child drm0 requested pci_enable_busmaster
> [drm:pid1408:drm_agp_init] agp_available = 1
> info: [drm] AGP at 0xe0000000 256MB
> [drm:pid1408:drm_ctxbitmap_next] drm_ctxbitmap_next bit : 0
> [drm:pid1408:drm_ctxbitmap_init] drm_ctxbitmap_init : 0
> info: [drm] Initialized i915 1.6.0 20080730
>
> > 2. Interrupts are still working for other devices on the shared INTx
>
> Hmm, How to determine which device need to be checked?
> Em0, hdac0 and ubsa0 modem work fine.
From the above vmstat output, it looks like you are still seeing
interrupts on irq 16, which is where the storm was, so I think things
are good.
robert.
Robert Noland < rnoland@...>
FreeBSD
|
|
Re: Interrupt stom on cardbus device
On Sat, Feb 28, 2009 at 11:50:13AM -0600, Robert Noland wrote:
> On Sat, 2009-02-28 at 20:38 +0300, Nasonov Sergey wrote:
> > > 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> >
> > Great! After applying this patch the problem was resolved. Switch to VT
> > an then back to X11 now work fine. Thanks!
>
> Can you confirm that:
>
> 1. Interrupts are still working (the msi ones)
> 2. Interrupts are still working for other devices on the shared INTx
>
Yes (me too).
I haven't noticed that (no console message 'interrupt storm', perhaps
the system is too fast :).
vgapci0@pci0:0:2:0: class=0x030000 card=0x82761043 chip=0x29c28086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '(Bearlake) Integrated Graphics Controller'
class = display
subclass = VGA
vmstat -i with:
~> uname -a
FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Feb 28 22:23:23 CET 2009 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64
interrupt total rate
irq1: atkbd0 35447 0
irq6: fdc0 1 0
irq16: uhci0+ 1286979669 13345
irq18: uhci2 ehci* 46833 0
irq20: fwohci0 2 0
irq22: atapci1 835480 8
cpu0: timer 192790855 1999
irq256: vgapci0 125358 1
irq257: hdac0 38 0
irq258: mskc0 1728607 17
cpu1: timer 192779996 1999
Total 1675322286 17372
vmstat -i with the same sources and your patch:
interrupt total rate
irq1: atkbd0 505 3
irq6: fdc0 1 0
irq16: uhci0+ 12191 72
irq18: uhci2 ehci* 837 4
irq20: fwohci0 2 0
irq22: atapci1 2410 14
cpu0: timer 334089 1988
irq256: vgapci0 2064 12
irq257: hdac0 39 0
irq258: mskc0 103 0
cpu1: timer 324595 1932
Total 676836 4028
Thanks!
Alexey.
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-currentTo unsubscribe, send any mail to " freebsd-current-unsubscribe@..."
|
|
Re: Interrupt stom on cardbus device
Hello.
I also had such problems with interrupt storm @ IRQ 16. Hardware is Lenovo T400 (X4500,GM45) Patch greatly helped, although it introduces other problem. As long as output from glxgears is at ttyv0, it is working fine. I output is @ xterm window, it stutters while writing the FPS count. If output is at ttyv0 and I switch terminal from X11 to ttyv0 while glxgears is working glxgears stutters too.
dmesg
drm0: <Mobile IntelÂŽ GM45 Express Chipset> on vgapci0
info: [drm] MSI enabled 1 message(s)
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] AGP at 0xd0000000 256MB
info: [drm] Initialized i915 1.6.0 20080730
drm0: [ITHREAD]
error: [drm:pid26643:gm45_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
drm0: [ITHREAD]
drm0: [ITHREAD]
drm0: [ITHREAD]
best regards,
Jakub Lach
|
|
Re: Interrupt stom on cardbus device
On Sun, 2009-03-01 at 01:15 -0800, Jakub Lach wrote:
> Hello.
>
> I also had such problems with interrupt storm @ IRQ 16. Hardware is Lenovo
> T400 (X4500,GM45) Patch greatly helped, although it introduces other
> problem. As long as output from glxgears is at ttyv0, it is working fine. I
> output is @ xterm window, it stutters while writing the FPS count. If output
> is at ttyv0 and I switch terminal from X11 to ttyv0 while glxgears is
> working glxgears stutters too.
Ok, I can try to look into this at some point, but right now it is not
high priority. When you VT switch, the irq handler gets uninstalled,
and the vblank counters get reset in hardware. We attempt to deal with
that case, but it's not optimal. As for stutter when printing while in
X, it could be text rendering performance ( which kinda sucks right now,
at least on intel ), it could also be that the G45 handles vblank
counters differently.
But I'm glad that the patch resolved the interrupt storm. It's likely
that it will help other devices than graphics cards as well...
robert.
> dmesg
>
> drm0: <Mobile IntelÂŽ GM45 Express Chipset> on vgapci0
> info: [drm] MSI enabled 1 message(s)
> vgapci0: child drm0 requested pci_enable_busmaster
> info: [drm] AGP at 0xd0000000 256MB
> info: [drm] Initialized i915 1.6.0 20080730
> drm0: [ITHREAD]
> error: [drm:pid26643:gm45_get_vblank_counter] *ERROR* trying to get vblank
> count for disabled pipe 0
> drm0: [ITHREAD]
> drm0: [ITHREAD]
> drm0: [ITHREAD]
>
> best regards,
> Jakub Lach
--
Robert Noland < rnoland@...>
FreeBSD
|
|
Re: Interrupt stom on cardbus device
By stuttering I mean that animated gears stop, and FPS count is greatly reduced 900FPS->20FPS
However, in real 3D accelerated apliccations FPS count is the same as before, so I'm happy.
best regards,
-Jakub Lach
Robert Noland wrote:
On Sun, 2009-03-01 at 01:15 -0800, Jakub Lach wrote:
> Hello.
>
> I also had such problems with interrupt storm @ IRQ 16. Hardware is Lenovo
> T400 (X4500,GM45) Patch greatly helped, although it introduces other
> problem. As long as output from glxgears is at ttyv0, it is working fine. I
> output is @ xterm window, it stutters while writing the FPS count. If output
> is at ttyv0 and I switch terminal from X11 to ttyv0 while glxgears is
> working glxgears stutters too.
Ok, I can try to look into this at some point, but right now it is not
high priority. When you VT switch, the irq handler gets uninstalled,
and the vblank counters get reset in hardware. We attempt to deal with
that case, but it's not optimal. As for stutter when printing while in
X, it could be text rendering performance ( which kinda sucks right now,
at least on intel ), it could also be that the G45 handles vblank
counters differently.
But I'm glad that the patch resolved the interrupt storm. It's likely
that it will help other devices than graphics cards as well...
robert.
> dmesg
>
> drm0: <Mobile IntelÂŽ GM45 Express Chipset> on vgapci0
> info: [drm] MSI enabled 1 message(s)
> vgapci0: child drm0 requested pci_enable_busmaster
> info: [drm] AGP at 0xd0000000 256MB
> info: [drm] Initialized i915 1.6.0 20080730
> drm0: [ITHREAD]
> error: [drm:pid26643:gm45_get_vblank_counter] *ERROR* trying to get vblank
> count for disabled pipe 0
> drm0: [ITHREAD]
> drm0: [ITHREAD]
> drm0: [ITHREAD]
>
> best regards,
> Jakub Lach
--
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
|
|
Re: Interrupt stom on cardbus device
On Friday 27 February 2009 8:35:59 pm Robert Noland wrote:
> On Fri, 2009-02-27 at 15:02 -0500, John Baldwin wrote:
> > On Friday 27 February 2009 2:11:04 pm Robert Noland wrote:
> > > On Fri, 2009-02-27 at 14:03 -0500, John Baldwin wrote:
> > > > 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@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?
> > > >
> > > > 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.
> > >
> > > Ok, I do have docs on the 965, so I'll look at this. The linux version
> > > does not do this, unless the OS does it in the background somewhere.
>
> Ok, so I looked over the 965 docs again and noticed PCIR_COMMAND bit 10.
> Then I pulled up the AMD docs on their PCIE cards and they also have
> this bit. I made an test patch for just the i915 driver to ensure that
> this fixes the issue, but it seems like a more general fix is in order.
> I'm proposing to disable INTx when we setup MSI/MSIX interrupts. I
> talked with scottl@ about this a bit last night and this seems like the
> right thing to do, or at least it shouldn't hurt much...
>
> John, what do you think of the attached patch?
Looks good and is something that was on my low-priority todo list. :)
--
John Baldwin
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-currentTo unsubscribe, send any mail to " freebsd-current-unsubscribe@..."
|
signature.asc (203 bytes) 