System is a AMD K6-III/450. This is actually a 2.6.25-rcX issue
that I'm just getting around to reporting. Sorry about that...------------[ cut here ]------------
WARNING: at arch/x86/pci/irq.c:263 pirq_via586_get+0x23/0x42()
Modules linked in: snd_emu10k1(+) snd_rawmidi firmware_class snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore ipv6 usbmouse usbhid ff_memless uhci_hcd ehci_hcd usbcore binfmt_misc
Pid: 1784, comm: modprobe Not tainted 2.6.25-rc7 #1
[<c0115b43>] warn_on_slowpath+0x40/0x4f
[<c012755b>] run_hrtimer_pending+0xac/0xc5
[<c011cc32>] run_timer_softirq+0x152/0x16b
[<c0119b8c>] __do_softirq+0x59/0x85
[<c027246b>] pci_conf1_read+0xac/0xc5
[<c027334f>] raw_pci_read+0x3f/0x47
[<c027246b>] pci_conf1_read+0xac/0xc5
[<c027334f>] raw_pci_read+0x3f/0x47
[<c0273421>] pci_read+0x1c/0x23
[<c01f5bce>] pci_bus_read_config_byte+0x37/0x6c
[<c01f5be8>] pci_bus_read_config_byte+0x51/0x6c
[<c0272cef>] pirq_via586_get+0x23/0x42
[<c0272ccc>] pirq_via586_get+0x0/0x42
[<c0272fa7>] pcibios_lookup_irq+0x1da/0x355
[<c0273152>] pirq_enable_irq+0x30/0x91
[<c0273403>] pcibios_enable_device+0x21/0x23
[<c01f798b>] do_pci_enable_device+0x1f/0x34
[<c01f79f8>] __pci_enable_device_flags+0x58/0x64
[<d8c51bb6>] snd_emu10k1_create+0x2f/0x5fb [snd_emu10k1]
[<d8b87f5b>] snd_card_new+0x1f6/0x24a [snd]
[<d8c5196e>] snd_card_emu10k1_probe+0xd2/0x2eb [snd_emu10k1]
[<c01f8d59>] pci_device_probe+0x36/0x57
[<c022f7d7>] driver_probe_device+0xb7/0x128
[<c022f8d5>] __driver_attach+0x0/0x75
[<c022f919>] __driver_attach+0x44/0x75
[<c022ede5>] bus_for_each_dev+0x38/0x5a
[<c022f670>] driver_attach+0x11/0x13
[<c022f8d5>] __driver_attach+0x0/0x75
[<c022f493>] bus_add_driver+0x8f/0x1ac
[<c022fae2>] driver_register+0x45/0x99
[<c01f8f46>] __pci_r...
[Added Ingo and Thomas to Cc:]
Not necessarily a regression, it's just that the WARN_ON_ONCE didn't
--
Hm, the warnings seem to be a bit broken. They were added in
7d409d6057c7244f8757ce15245f6df27271be0c "x86: add some pirq debugging".In pirq_via586_{get,set} and pirq_ite_{get,set}, they're missing the
fact that we're using pirq-1 to index the array. So it's spitting out
warnings for valid cases. So Bob's warning can very well be completely
bogus.In pirq_ali_{get,set} there's probably the same problem, but I can't
really tell for sure, because pirq isn't used to index the array
directly, and the comment above that functions tells me not to guess
anything.For pirq_vlsi_{get,set} I just wondered why that ">= 9" instead of "> 8"
as it is on the next line, but well, that's just style nit-picking...Björn
--
Bj
The conditions for the warnings simply ignored the fact that we later actually
use the original value minus 1, so the warning triggered even for valid values.Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
[Sorry for the resend, I messed up the first one with a Reply-To insteadOK, so I made a guess anyway, the new condition at least makes more
sense to me.arch/x86/pci/irq.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index a871586..579745c 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -200,7 +200,7 @@ static int pirq_ali_get(struct pci_dev *router, struct pci_dev *dev, int pirq)
{
static const unsigned char irqmap[16] = { 0, 9, 3, 10, 4, 5, 7, 6, 1, 11, 0, 12, 0, 14, 0, 15 };- WARN_ON_ONCE(pirq >= 16);
+ WARN_ON_ONCE(pirq > 16);
return irqmap[read_config_nybble(router, 0x48, pirq-1)];
}@@ -209,7 +209,7 @@ static int pirq_ali_set(struct pci_dev *router, struct pci_dev *dev, int pirq, i
static const unsigned char irqmap[16] = { 0, 8, 0, 2, 4, 5, 7, 6, 0, 1, 3, 9, 11, 0, 13, 15 };
unsigned int val = irqmap[irq];- WARN_ON_ONCE(pirq >= 16);
+ WARN_ON_ONCE(pirq > 16);
if (val) {
write_config_nybble(router, 0x48, pirq-1, val);
return 1;
@@ -260,7 +260,7 @@ static int pirq_via586_get(struct pci_dev *router, struct pci_dev *dev, int pirq
{
static const unsigned int pirqmap[5] = { 3, 2, 5, 1, 1 };- WARN_ON_ONCE(pirq >= 5);
+ WARN_ON_ONCE(pirq > 5);
return read_config_nybble(router, 0x55, pirqmap[pirq-1]);
}@@ -268,7 +268,7 @@ static int pirq_via586_set(struct pci_dev *router, struct pci_dev *dev, int pirq
{
static const unsigned int pirqmap[5] = { 3, 2, 5, 1, 1 };- WARN_ON_ONCE(pirq >= 5);
+ WARN_ON_ONCE(pirq > 5);
write_config_nybble(router, 0x55, pirqmap[pirq-1], irq);
return 1;
}
@@ -282,7 +282,7 @@ static int pirq_ite_get(struct pci_dev *router, struct pci_dev *dev, int pirq)
...
| Amit K. Arora | [RFC] Heads up on sys_fallocate() |
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Nicolas Pitre | Re: [RFC patch 08/18] cnt32_to_63 should use smp_rmb() |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Natalie Protasevich | [BUG] New Kernel Bugs |
