From: Dave Airlie on
Hey guys,

Booted 2.6.35 + my drm-next tree this morning, happened with -rc6. Now
I changed graphics cards this morning, and my 2.6.32 based enterprise
kernels are booting fine, and I haven't had much time to bisect this,
but I thought it might be interesting to you guys. I've booted my
kernel on other machines with no problems which is why I suspect its
not a drm-next issue and is a real 2.6.35 issue.

I've attached the full dmesg up to the oops + lspci -vvv from this machine.

Let me know if you want any other info, and I'll try and get some
bisecting going on in the meanwhile.

Dave.

Now I can't swear this isn't something in my drm-next tree, but
[drm] radeon kernel modesetting enabled.
BUG: unable to handle kernel paging request at ffff9000
IP: [<c0417511>] ioapic_write_entry+0x41/0x7a
*pdpt = 00000000008ca001 *pde = 00000000008cb067 *pte = 0000000000000000
Oops: 0002 [#1] SMP
last sysfs file: /sys/devices/virtual/tty/tty9/uevent
Modules linked in: radeon(+) ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core

Pid: 607, comm: modprobe Not tainted 2.6.35+ #34 0UY253/Dell XPS710
EIP: 0060:[<c0417511>] EFLAGS: 00010086 CPU: 0
EIP is at ioapic_write_entry+0x41/0x7a
EAX: 00000296 EBX: 00000001 ECX: ffff9000 EDX: 03000000
ESI: 00000010 EDI: 00006000 EBP: 00000031 ESP: f77e6dfc
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process modprobe (pid: 607, ti=f77e6000 task=f77839c0 task.ti=f77e6000)
Stack:
0001a969 c08d427c 00000010 c07a6f7e 00000001 c0417857 0001a969 03000000
<0> 00000001 00000010 0001a969 03000000 00000001 00000010 c0827380 ffffffff
<0> c041793c c0827380 00000001 00000001 00000001 00000010 00000001 f7590000
Call Trace:
[<c0417857>] ? setup_IO_APIC_irq+0x270/0x27a
[<c041793c>] ? io_apic_set_pci_routing+0xdb/0xea
[<c0627d39>] ? pirq_enable_irq+0x16d/0x208
[<c0628337>] ? pcibios_enable_device+0x1f/0x24
[<c056a96c>] ? do_pci_enable_device+0x1f/0x34
[<c056a9c7>] ? __pci_enable_device_flags+0x46/0x56
[<f8705a72>] ? drm_get_pci_dev+0x8e/0x220 [drm]
[<c056abd7>] ? local_pci_probe+0xb/0xc
[<c056ad6a>] ? pci_device_probe+0x41/0x63
[<c05b2015>] ? driver_probe_device+0x7e/0xf6
[<c05b20cd>] ? __driver_attach+0x40/0x5b
[<c05b1a33>] ? bus_for_each_dev+0x37/0x60
[<c05b1ef2>] ? driver_attach+0x11/0x13
[<c05b208d>] ? __driver_attach+0x0/0x5b
[<c05b1507>] ? bus_add_driver+0xcd/0x201
[<c05b22d8>] ? driver_register+0x7a/0xdb
[<c056af1d>] ? __pci_register_driver+0x33/0x89
[<f9bc5000>] ? radeon_init+0x0/0xa9 [radeon]
[<c0401045>] ? do_one_initcall+0x44/0x120
[<c045566b>] ? sys_init_module+0x77/0x194
[<c04025cc>] ? sysenter_do_call+0x12/0x22
Code: 1c 89 04 24 b8 50 41 8d c0 e8 44 3a 29 00 8b 0c dd 44 35 8d c0
89 fa 8d 7b 05 c1 e7 0c 81 e1 ff 0f 00 00 03 0d 70 bd 83 c0 29 f9 <89>
29 89 51 10 8b 14 dd
From: Yinghai Lu on
On Sun, Aug 1, 2010 at 10:28 PM, Dave Airlie <airlied(a)gmail.com> wrote:
> Hey guys,
>
> Booted 2.6.35 + my drm-next tree this morning, happened with -rc6. Now
> I changed graphics cards this morning, and my 2.6.32 based enterprise
> kernels are booting fine, and I haven't had much time to bisect this,
> but I thought it might be interesting to you guys. I've booted my
> kernel on other machines with no problems which is why I suspect its

sata_nv 0000:00:0e.0: PCI->APIC IRQ transform: INT A -> IRQ 35
sata_nv 0000:00:0e.0: Using SWNCQ mode
scsi0 : sata_nv
scsi1 : sata_nv
ata1: SATA max UDMA/133 cmd 0xfe00 ctl 0xfe10 bmdma 0xfec0 irq 35
ata2: SATA max UDMA/133 cmd 0xfe20 ctl 0xfe30 bmdma 0xfec8 irq 35
sata_nv 0000:00:0e.1: PCI->APIC IRQ transform: INT B -> IRQ 35
sata_nv 0000:00:0e.1: Using SWNCQ mode
scsi2 : sata_nv
scsi3 : sata_nv
ata3: SATA max UDMA/133 cmd 0xfe40 ctl 0xfe50 bmdma 0xfed0 irq 35
ata4: SATA max UDMA/133 cmd 0xfe60 ctl 0xfe70 bmdma 0xfed8 irq 35
sata_nv 0000:00:0e.2: PCI->APIC IRQ transform: INT C -> IRQ 35
sata_nv 0000:00:0e.2: Using SWNCQ mode
scsi4 : sata_nv
scsi5 : sata_nv
ata5: SATA max UDMA/133 cmd 0xfe80 ctl 0xfe90 bmdma 0xfef0 irq 35
ata6: SATA max UDMA/133 cmd 0xfea0 ctl 0xfeb0 bmdma 0xfef8 irq 35

the kernel is using mptable, and the system have mcp55, so how come
with irq 35?
assume we should only have ioapic irq 0 - 23 ...

Can you send out boot log with "debug apic=debug pci=routeirq" with
2.6.32 and 2.6.35?

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dave Airlie on
>
> the kernel is using mptable, and the  system have mcp55, so how come
> with irq 35?
> assume we should only have ioapic irq 0 - 23 ...
>
> Can you send out boot log with "debug apic=debug pci=routeirq" with
> 2.6.32 and 2.6.35?

Okay el6log is from a RHEL6 2.6.32 kernel, but it should give a good
baseline, the 2.6.35 oops even earlier with all those options and is
in the second attachment.

Dave.
From: Yinghai Lu on
On 08/02/2010 04:17 PM, Dave Airlie wrote:
>>
>> the kernel is using mptable, and the system have mcp55, so how come
>> with irq 35?
>> assume we should only have ioapic irq 0 - 23 ...
>>
>> Can you send out boot log with "debug apic=debug pci=routeirq" with
>> 2.6.32 and 2.6.35?
>
> Okay el6log is from a RHEL6 2.6.32 kernel, but it should give a good
> baseline, the 2.6.35 oops even earlier with all those options and is
> in the second attachment.

please check

[PATCH] x86: fix pin_2_irq mapping

We should not twist gsi to irq mapping if acpi is not used.

Signed-off-by: Yinghai Lu <yinghai(a)kernel.org>

---
arch/x86/include/asm/io_apic.h | 14 ++++++++++++++
arch/x86/kernel/acpi/boot.c | 4 ++--
arch/x86/kernel/apic/io_apic.c | 5 +----
3 files changed, 17 insertions(+), 6 deletions(-)

Index: linux-2.6/arch/x86/include/asm/io_apic.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/io_apic.h
+++ linux-2.6/arch/x86/include/asm/io_apic.h
@@ -185,6 +185,20 @@ int mp_find_ioapic_pin(int ioapic, u32 g
void __init mp_register_ioapic(int id, u32 address, u32 gsi_base);
extern void __init pre_init_apic_IRQ0(void);

+#ifdef CONFIG_ACPI
+unsigned int gsi_to_irq(unsigned int gsi);
+u32 irq_to_gsi(int irq);
+#else
+static inline unsigned int gsi_to_irq(unsigned int gsi)
+{
+ return gsi;
+}
+static u32 irq_to_gsi(int irq)
+{
+ return irq;
+}
+#endif
+
#else /* !CONFIG_X86_IO_APIC */

#define io_apic_assign_pci_irqs 0
Index: linux-2.6/arch/x86/kernel/acpi/boot.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
+++ linux-2.6/arch/x86/kernel/acpi/boot.c
@@ -100,7 +100,7 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
};

-static unsigned int gsi_to_irq(unsigned int gsi)
+unsigned int gsi_to_irq(unsigned int gsi)
{
unsigned int irq = gsi + NR_IRQS_LEGACY;
unsigned int i;
@@ -123,7 +123,7 @@ static unsigned int gsi_to_irq(unsigned
return irq;
}

-static u32 irq_to_gsi(int irq)
+u32 irq_to_gsi(int irq)
{
unsigned int gsi;

Index: linux-2.6/arch/x86/kernel/apic/io_apic.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/apic/io_apic.c
+++ linux-2.6/arch/x86/kernel/apic/io_apic.c
@@ -1029,10 +1029,7 @@ static int pin_2_irq(int idx, int apic,
} else {
u32 gsi = mp_gsi_routing[apic].gsi_base + pin;

- if (gsi >= NR_IRQS_LEGACY)
- irq = gsi;
- else
- irq = gsi_top + gsi;
+ irq = gsi_to_irq(gsi);
}

#ifdef CONFIG_X86_32
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on
Yinghai Lu <yinghai(a)kernel.org> writes:

> On 08/02/2010 06:32 PM, Yinghai Lu wrote:
>> On 08/02/2010 04:17 PM, Dave Airlie wrote:
>>>>
>>>> the kernel is using mptable, and the system have mcp55, so how come
>>>> with irq 35?
>>>> assume we should only have ioapic irq 0 - 23 ...
>>>>
>>>> Can you send out boot log with "debug apic=debug pci=routeirq" with
>>>> 2.6.32 and 2.6.35?
>>>
>>> Okay el6log is from a RHEL6 2.6.32 kernel, but it should give a good
>>> baseline, the 2.6.35 oops even earlier with all those options and is
>>> in the second attachment.
>>
>

This patch is wrong and there is no reason to even suspect it will
affect this problem. At best this patch will trade one set of bugs
for another because at least on some platforms we always did something
like this. Having an irq 35 is odd and certainly a result of recent
changes, but in this case it doesn't look like it has anything to do
with the problem.

Nacked-by: "Eric W. Biederman" <ebiederm(a)xmission.com>

> please use this one instead..., forget to run quilt refresh before sending it.
>
> [PATCH -v2] x86: fix pin_2_irq mapping
>
> We should not twist gsi to irq mapping if acpi is not used.
>
> -v2 remove not used irq_to_gsi()
>
> Signed-off-by: Yinghai Lu <yinghai(a)kernel.org>
>
> ---
> arch/x86/include/asm/io_apic.h | 10 ++++++++++
> arch/x86/kernel/acpi/boot.c | 4 ++--
> arch/x86/kernel/apic/io_apic.c | 5 +----
> 3 files changed, 13 insertions(+), 6 deletions(-)
>
> Index: linux-2.6/arch/x86/include/asm/io_apic.h
> ===================================================================
> --- linux-2.6.orig/arch/x86/include/asm/io_apic.h
> +++ linux-2.6/arch/x86/include/asm/io_apic.h
> @@ -185,6 +185,16 @@ int mp_find_ioapic_pin(int ioapic, u32 g
> void __init mp_register_ioapic(int id, u32 address, u32 gsi_base);
> extern void __init pre_init_apic_IRQ0(void);
>
> +#ifdef CONFIG_ACPI
> +unsigned int gsi_to_irq(unsigned int gsi);
> +u32 irq_to_gsi(int irq);
> +#else
> +static inline unsigned int gsi_to_irq(unsigned int gsi)
> +{
> + return gsi;
> +}
> +#endif
> +
> #else /* !CONFIG_X86_IO_APIC */
>
> #define io_apic_assign_pci_irqs 0
> Index: linux-2.6/arch/x86/kernel/acpi/boot.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
> +++ linux-2.6/arch/x86/kernel/acpi/boot.c
> @@ -100,7 +100,7 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY
> 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
> };
>
> -static unsigned int gsi_to_irq(unsigned int gsi)
> +unsigned int gsi_to_irq(unsigned int gsi)
> {
> unsigned int irq = gsi + NR_IRQS_LEGACY;
> unsigned int i;
> @@ -123,7 +123,7 @@ static unsigned int gsi_to_irq(unsigned
> return irq;
> }
>
> -static u32 irq_to_gsi(int irq)
> +u32 irq_to_gsi(int irq)
> {
> unsigned int gsi;
>
> Index: linux-2.6/arch/x86/kernel/apic/io_apic.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/apic/io_apic.c
> +++ linux-2.6/arch/x86/kernel/apic/io_apic.c
> @@ -1029,10 +1029,7 @@ static int pin_2_irq(int idx, int apic,
> } else {
> u32 gsi = mp_gsi_routing[apic].gsi_base + pin;
>
> - if (gsi >= NR_IRQS_LEGACY)
> - irq = gsi;
> - else
> - irq = gsi_top + gsi;
> + irq = gsi_to_irq(gsi);
> }
>
> #ifdef CONFIG_X86_32
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/