mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Torsten Kaiser <just.for.lkml@googlemail.com>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Tejun Heo <tj@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Robert Hancock <hancockrwd@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Yinghai Lu <yhlu.kernel@gmail.com>
Subject: Re: do_IRQ: 0.165 No irq handler for vector (irq -1)
Date: Tue, 2 Feb 2010 20:56:53 +0100	[thread overview]
Message-ID: <64bb37e1002021156s6e8e3ba7p6192e15bc431eb87@mail.gmail.com> (raw)
In-Reply-To: <1265136022.2793.33.camel@sbs-t61.sc.intel.com>

On Tue, Feb 2, 2010 at 7:40 PM, Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> On Mon, 2010-02-01 at 20:53 -0800, Eric W. Biederman wrote:
>> > It might be that the silicon implements MSI incorrectly and ends up
>> > sending out invalid MSI packets under certain circumstances.  The
>> > silicon hasn't changed for quite some time now and back when it came
>> > out MSI wasn't too popular and I don't think SIMG's proprietary
>> > drivers use it, so it's quite possible that the feature simply is
>> > broken.  Is there any specific reason why you want to enable MSI
>> > support?  It's not like MSI brings any actual benefit when the
>> > compatibility hardware is already there.

 19:      34618          3          2       4862   IO-APIC-fasteoi
sata_sil24, bttv0, Bt87x audio
[    6.038918] IRQ 19/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs

The interrupt that the sata_sil24 is currently using is shared, so I
thought that switching this to MSI might be a good idea.
And I wanted to test a new feature. ;-)

>> It also seems possible that some of the recent irq handling changes
>> missed something.
>
> No Eric. This particular report is with 2.6.33-rc kernels and also only
> when MSI support for sata_sil24 is enabled. Recent irq handling changes
> are all in -tip tree and getting tested. So this sounds like a different
> problem specific to this HW's MSI capabilities.

Just to repeat this so not get this information lost:
MSI seems to work an this system.
The drivers radeon (X300), HDA intel (onboard sound from the MCP55
chipset) and tg3 (two BCM5754) all work without any problems.

>> Usually the message "No irq handler for vector (irq -1)" means that the irq
>> was delivered to a cpu that was not ready for it.  I see that vector 165
>> is being delivered on all of the different cpus with vector 165,
>> and that you are getting interrupts delivered most of the time.
>
> Also I see this in the original report:
>
> On Sun, 2010-01-31 at 05:02 -0800, Torsten Kaiser wrote:
>> What is really strange: The vector 165 is stable. It never changed
>> even if I deactivate all other drivers in the kernel config (that
>> changes the MSI IRQ for sata_sil24 from 29 to 28!) or if I switch off
>> CONFIG_SPARSE_IRQ. In the kernel with the reduced number of drivers
>> the maximum vector that gets used in __assign_irq_vector is only 137.
>
> It looks like the HW under certain conditions is generating interrupts
> with wrong vector (165), especially when the __assign_irq_vector() never
> allocated the vector 165 (and hence we never setup the vector to irq
> mapping for this vector on any cpu). Torsten, can you please apply the
> appended patch and boot with "apic_phys" boot parameter and see if it
> makes any difference?

I tried the patch and the message from do_IRQ is gone, but reading the
file still fails with the same errors from libata.
(Earlier tests with writing a large file to this disk also failed with
timeouts, but never trigger the do_IRQ error)

I added a diff between the dmesg from the testrun with your patch to
the previous run at the end of the mail.

>> This smells like the initialization problems I was seeing in another
>> thread.  Suresh?
>
> No. Initialization problems in another thread happens in a small window
> during cpu online (in logical flat mode, we are setting up vector to irq
> mappings for the AP a little late after we have enabled interrupts).
> Here the problem is not actually triggered during cpu on-lining.

FWIW: # CONFIG_HOTPLUG_CPU is not set

I don't use suspend/resume on that system, so I never enabled CPU
hotplug in the .config.

Thanks for looking at this.

Torsten


The changes in dmesg from you patch:
1,2c1,2
< x Linux version 2.6.33-rc6 (root@treogen) (gcc version 4.4.2 (Gentoo
4.4.2 p1.0) ) #1 SMP Sat Jan 30 10:38:39 CET 2010
< x Command line: root=/dev/sdc1 console=ttyS0,115200 console=tty1
sata_sil24.msi=1 radeon.modeset=1 raid=noautodetect apic=debug
---
> x Linux version 2.6.33-rc6 (root@treogen) (gcc version 4.4.2 (Gentoo 4.4.2 p1.0) ) #2 SMP Tue Feb 2 20:22:21 CET 2010
> x Command line: root=/dev/sdc1 console=ttyS0,115200 console=tty1 sata_sil24.msi=1 radeon.modeset=1 raid=noautodetect apic=debug apic_phys
61a62
> x Setting APIC routing to physical flat.
130a132
> x Setting APIC routing to physical flat.
159c161
< x Kernel command line: root=/dev/sdc1 console=ttyS0,115200
console=tty1 sata_sil24.msi=1 radeon.modeset=1 raid=noautodetect
apic=debug
---
> x Kernel command line: root=/dev/sdc1 console=ttyS0,115200 console=tty1 sata_sil24.msi=1 radeon.modeset=1 raid=noautodetect apic=debug apic_phys
163,164c165,166
< x Node 0: aperture @ a7f2000000 size 32 MB
< x Aperture beyond 4GB. Ignoring.
---
> x Node 0: aperture @ 20000000 size 32 MB
> x Aperture pointing to e820 RAM. Ignoring.
202c204
< x Setting APIC routing to flat
---
> x Setting APIC routing to physical flat
234,235c236,237
< x ... lapic delta = 1249998
< x ... PM-Timer delta = 357954
---
> x ... lapic delta = 1249989
> x ... PM-Timer delta = 357951
237,241c239,243
< x ..... delta 1249998
< x ..... mult: 53687005
< x ..... calibration result: 1999996
< x ..... CPU clock speed is 2599.9959 MHz.
< x ..... host bus clock speed is 199.9996 MHz.
---
> x ..... delta 1249989
> x ..... mult: 53686618
> x ..... calibration result: 1999982
> x ..... CPU clock speed is 2599.9751 MHz.
> x ..... host bus clock speed is 199.9982 MHz.
248c250
< x Total of 4 processors activated (20800.14 BogoMIPS).
---
> x Total of 4 processors activated (20799.96 BogoMIPS).
430,431c432,433
< x ... APIC ICR: 000008fd
< x ... APIC ICR2: 08000000
---
> x ... APIC ICR: 000000fd
> x ... APIC ICR2: 03000000
437,438c439,440
< x ... APIC TMICT: 0001e847
< x ... APIC TMCCT: 000174b3
---
> x ... APIC TMICT: 0001e846
> x ... APIC TMCCT: 000185ee
462,476c464,478
< x  01 00F 0    0    0   0   0    1    1    31
< x  02 00F 0    0    0   0   0    1    1    30
< x  03 00F 0    0    0   0   0    1    1    33
< x  04 00F 0    0    0   0   0    1    1    34
< x  05 00F 1    0    0   0   0    1    1    35
< x  06 00F 0    0    0   0   0    1    1    36
< x  07 00F 0    0    0   0   0    1    1    37
< x  08 00F 0    0    0   0   0    1    1    38
< x  09 00F 0    1    0   0   0    1    1    39
< x  0a 00F 1    0    0   0   0    1    1    3A
< x  0b 00F 1    0    0   0   0    1    1    3B
< x  0c 00F 0    0    0   0   0    1    1    3C
< x  0d 00F 0    0    0   0   0    1    1    3D
< x  0e 00F 0    0    0   0   0    1    1    3E
< x  0f 00F 0    0    0   0   0    1    1    3F
---
> x  01 000 0    0    0   0   0    0    0    31
> x  02 000 0    0    0   0   0    0    0    30
> x  03 000 0    0    0   0   0    0    0    33
> x  04 000 0    0    0   0   0    0    0    34
> x  05 000 1    0    0   0   0    0    0    35
> x  06 000 0    0    0   0   0    0    0    36
> x  07 000 0    0    0   0   0    0    0    37
> x  08 000 0    0    0   0   0    0    0    38
> x  09 000 0    1    0   0   0    0    0    39
> x  0a 000 1    0    0   0   0    0    0    3A
> x  0b 000 1    0    0   0   0    0    0    3B
> x  0c 000 0    0    0   0   0    0    0    3C
> x  0d 000 0    0    0   0   0    0    0    3D
> x  0e 000 0    0    0   0   0    0    0    3E
> x  0f 000 0    0    0   0   0    0    0    3F

  reply	other threads:[~2010-02-02 19:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-31 13:02 Torsten Kaiser
2010-02-02  2:38 ` Tejun Heo
2010-02-02  4:53   ` Eric W. Biederman
2010-02-02 18:40     ` Suresh Siddha
2010-02-02 19:56       ` Torsten Kaiser [this message]
2010-02-13  9:25         ` Torsten Kaiser
2010-02-13 18:18           ` Suresh Siddha
2010-02-13 18:22             ` Robert Hancock
2010-02-13 21:34             ` Torsten Kaiser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=64bb37e1002021156s6e8e3ba7p6192e15bc431eb87@mail.gmail.com \
    --to=just.for.lkml@googlemail.com \
    --cc=ebiederm@xmission.com \
    --cc=hancockrwd@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=yhlu.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome