From: Dave Airlie on 2 Aug 2010 01:30 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 2 Aug 2010 03:00 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 2 Aug 2010 19:20 > > 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 2 Aug 2010 21:40 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 2 Aug 2010 23:20 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/
|
Next
|
Last
Pages: 1 2 3 4 5 6 Prev: linux-next: Tree for August 2 Next: [PATCH] New EPOLL flag: EPOLLHEAD |