Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
On 2015/3/30 16:37, Jiang Liu wrote: > On 2015/3/30 16:28, Li, Aubrey wrote: >> Ying, >> >> can you please try this patch to see if the problem is gone on your side? > Hi Aubrey, > I would be better if we could change RTC driver instead. Hey Gerry, IRQ8 for RTC is for history reason. If we dynamically assign IRQ to RTC, it might be a mess for legacy machine. If we still use IRQ8 for RTC but dynamically assign IRQ to other components, then there is a race IRQ8 being used before RTC driver is loaded. So, statically assigning IRQ is the best choice in my mind, this also matches the original IRQ assign policy. Thanks, -Aubrey > Thanks! > Gerry >> >> Thanks, >> -Aubrey >> >> >> On 2015/3/26 20:13, Li, Aubrey wrote: >>> On 2015/3/25 15:22, Huang Ying wrote: [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0) >>> >>> okay, I replicated this on my side now. >>> >>> Firstly, I don't think the patch did anything wrong. However, the patch >>> exposes a few issues FWICT currently: >>> >>> - Should we enable RTC Alarm the kind of Fixed hardware event in >>> hardware-reduced ACPI mode? I found RTC required registers in ACPI PM >>> block are not valid(register address = 0) >>> >>> - I checked RTC device in ACPI table, there is no interrupt resource >>> under RTC(firmware bug?), So irq 8 should be a hardcoded number. The >>> question is, shouldn't we update bitmap of allocated_irqs here? Or we >>> assume irq0~15 is reserved? If we assume IRQ0~15 is reserved, then >>> requesting IRQ8 without updating bitmap of allocated_irqs is fine. >>> >>> - Because we don't update bitmap of allocated_irqs when RTC request >>> IRQ8, so when MMC driver allocate irq resource, it's possible it gets >>> irq8, so we saw "genirq: Flags mismatch irq 8. 0080 (mmc0) vs. >>> (rtc0)". So here is another question, when we dynamically >>> allocate irq from irq domain, shouldn't we start from IRQ16? Yes, if >>> allocated_irqs bitmap is updated, then it should be fine if we start >>> from IRQ1. >>> >>> What the patch does is, it changes the behavior of how we allocate irq >>> from irq domain. Previously we have legacy IRQs so we statically assign >>> IRQ numbers for IOAPICs to host legacy IRQs, and now we allocate every >>> IRQ dynamically. >>> >>> For me I think I can deliver a patch against RTC driver to update >>> allocated_irqs bitmap, also, we should free irq when we found RTC ACPI >>> registers are not valid. >>> >>> Certainly I'm open to any suggestions. >>> >>> Thanks, >>> -Aubrey >>> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
On 2015/3/30 16:28, Li, Aubrey wrote: > Ying, > > can you please try this patch to see if the problem is gone on your side? Hi Aubrey, I would be better if we could change RTC driver instead. Thanks! Gerry > > Thanks, > -Aubrey > > > On 2015/3/26 20:13, Li, Aubrey wrote: >> On 2015/3/25 15:22, Huang Ying wrote: >>> [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. >>> (rtc0) >> >> okay, I replicated this on my side now. >> >> Firstly, I don't think the patch did anything wrong. However, the patch >> exposes a few issues FWICT currently: >> >> - Should we enable RTC Alarm the kind of Fixed hardware event in >> hardware-reduced ACPI mode? I found RTC required registers in ACPI PM >> block are not valid(register address = 0) >> >> - I checked RTC device in ACPI table, there is no interrupt resource >> under RTC(firmware bug?), So irq 8 should be a hardcoded number. The >> question is, shouldn't we update bitmap of allocated_irqs here? Or we >> assume irq0~15 is reserved? If we assume IRQ0~15 is reserved, then >> requesting IRQ8 without updating bitmap of allocated_irqs is fine. >> >> - Because we don't update bitmap of allocated_irqs when RTC request >> IRQ8, so when MMC driver allocate irq resource, it's possible it gets >> irq8, so we saw "genirq: Flags mismatch irq 8. 0080 (mmc0) vs. >> (rtc0)". So here is another question, when we dynamically >> allocate irq from irq domain, shouldn't we start from IRQ16? Yes, if >> allocated_irqs bitmap is updated, then it should be fine if we start >> from IRQ1. >> >> What the patch does is, it changes the behavior of how we allocate irq >> from irq domain. Previously we have legacy IRQs so we statically assign >> IRQ numbers for IOAPICs to host legacy IRQs, and now we allocate every >> IRQ dynamically. >> >> For me I think I can deliver a patch against RTC driver to update >> allocated_irqs bitmap, also, we should free irq when we found RTC ACPI >> registers are not valid. >> >> Certainly I'm open to any suggestions. >> >> Thanks, >> -Aubrey >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
Ying, can you please try this patch to see if the problem is gone on your side? Thanks, -Aubrey On 2015/3/26 20:13, Li, Aubrey wrote: > On 2015/3/25 15:22, Huang Ying wrote: >> [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. >> (rtc0) > > okay, I replicated this on my side now. > > Firstly, I don't think the patch did anything wrong. However, the patch > exposes a few issues FWICT currently: > > - Should we enable RTC Alarm the kind of Fixed hardware event in > hardware-reduced ACPI mode? I found RTC required registers in ACPI PM > block are not valid(register address = 0) > > - I checked RTC device in ACPI table, there is no interrupt resource > under RTC(firmware bug?), So irq 8 should be a hardcoded number. The > question is, shouldn't we update bitmap of allocated_irqs here? Or we > assume irq0~15 is reserved? If we assume IRQ0~15 is reserved, then > requesting IRQ8 without updating bitmap of allocated_irqs is fine. > > - Because we don't update bitmap of allocated_irqs when RTC request > IRQ8, so when MMC driver allocate irq resource, it's possible it gets > irq8, so we saw "genirq: Flags mismatch irq 8. 0080 (mmc0) vs. > (rtc0)". So here is another question, when we dynamically > allocate irq from irq domain, shouldn't we start from IRQ16? Yes, if > allocated_irqs bitmap is updated, then it should be fine if we start > from IRQ1. > > What the patch does is, it changes the behavior of how we allocate irq > from irq domain. Previously we have legacy IRQs so we statically assign > IRQ numbers for IOAPICs to host legacy IRQs, and now we allocate every > IRQ dynamically. > > For me I think I can deliver a patch against RTC driver to update > allocated_irqs bitmap, also, we should free irq when we found RTC ACPI > registers are not valid. > > Certainly I'm open to any suggestions. > > Thanks, > -Aubrey > >From 46524ace94eaf68c9719725472ab4ea28d079a7b Mon Sep 17 00:00:00 2001 From: Aubrey Li Date: Mon, 30 Mar 2015 10:50:09 -0500 Subject: [PATCH] x86/platform, acpi: Statically assign IRQ numbers in ACPI hardware reduced mode We should be able to dynamically assign IRQ number on the platform in ACPI Hardware-reduced mode, but on the Bay Trail-T(ASUS-T100) platform, there is a RTC device still using the legacy hardcoded IRQ8, which could cause the following error: 7486341a98f: genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0) So we want to statically assign IRQ numbers in ACPI hardware reduced mode to fix this error Signed-off-by: Li Aubrey Cc: Alan Cox Cc: Len Brown Cc: Rafael J. Wysocki Cc: Arjan van de Ven --- arch/x86/kernel/acpi/boot.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 803b684..4cd0761 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -460,8 +460,12 @@ acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned long end) acpi_table_print_madt_entry(header); - /* Statically assign IRQ numbers for IOAPICs hosting legacy IRQs */ - if (ioapic->global_irq_base < nr_legacy_irqs()) + /* + * Statically assign IRQ numbers for IOAPICs hosting legacy IRQs, + * Or for the platform in Hardware-reduced ACPI model + */ + if (ioapic->global_irq_base < nr_legacy_irqs() || + acpi_gbl_reduced_hardware) cfg.type = IOAPIC_DOMAIN_LEGACY; mp_register_ioapic(ioapic->id, ioapic->address, ioapic->global_irq_base, -- 1.9.1
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
Ying, can you please try this patch to see if the problem is gone on your side? Thanks, -Aubrey On 2015/3/26 20:13, Li, Aubrey wrote: On 2015/3/25 15:22, Huang Ying wrote: [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0) okay, I replicated this on my side now. Firstly, I don't think the patch did anything wrong. However, the patch exposes a few issues FWICT currently: - Should we enable RTC Alarm the kind of Fixed hardware event in hardware-reduced ACPI mode? I found RTC required registers in ACPI PM block are not valid(register address = 0) - I checked RTC device in ACPI table, there is no interrupt resource under RTC(firmware bug?), So irq 8 should be a hardcoded number. The question is, shouldn't we update bitmap of allocated_irqs here? Or we assume irq0~15 is reserved? If we assume IRQ0~15 is reserved, then requesting IRQ8 without updating bitmap of allocated_irqs is fine. - Because we don't update bitmap of allocated_irqs when RTC request IRQ8, so when MMC driver allocate irq resource, it's possible it gets irq8, so we saw genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0). So here is another question, when we dynamically allocate irq from irq domain, shouldn't we start from IRQ16? Yes, if allocated_irqs bitmap is updated, then it should be fine if we start from IRQ1. What the patch does is, it changes the behavior of how we allocate irq from irq domain. Previously we have legacy IRQs so we statically assign IRQ numbers for IOAPICs to host legacy IRQs, and now we allocate every IRQ dynamically. For me I think I can deliver a patch against RTC driver to update allocated_irqs bitmap, also, we should free irq when we found RTC ACPI registers are not valid. Certainly I'm open to any suggestions. Thanks, -Aubrey From 46524ace94eaf68c9719725472ab4ea28d079a7b Mon Sep 17 00:00:00 2001 From: Aubrey Li aubrey...@intel.com Date: Mon, 30 Mar 2015 10:50:09 -0500 Subject: [PATCH] x86/platform, acpi: Statically assign IRQ numbers in ACPI hardware reduced mode We should be able to dynamically assign IRQ number on the platform in ACPI Hardware-reduced mode, but on the Bay Trail-T(ASUS-T100) platform, there is a RTC device still using the legacy hardcoded IRQ8, which could cause the following error: 7486341a98f: genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0) So we want to statically assign IRQ numbers in ACPI hardware reduced mode to fix this error Signed-off-by: Li Aubrey aubrey...@linux.intel.com Cc: Alan Cox a...@linux.intel.com Cc: Len Brown len.br...@intel.com Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com Cc: Arjan van de Ven ar...@linux.intel.com --- arch/x86/kernel/acpi/boot.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 803b684..4cd0761 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -460,8 +460,12 @@ acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned long end) acpi_table_print_madt_entry(header); - /* Statically assign IRQ numbers for IOAPICs hosting legacy IRQs */ - if (ioapic-global_irq_base nr_legacy_irqs()) + /* + * Statically assign IRQ numbers for IOAPICs hosting legacy IRQs, + * Or for the platform in Hardware-reduced ACPI model + */ + if (ioapic-global_irq_base nr_legacy_irqs() || + acpi_gbl_reduced_hardware) cfg.type = IOAPIC_DOMAIN_LEGACY; mp_register_ioapic(ioapic-id, ioapic-address, ioapic-global_irq_base, -- 1.9.1
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
On 2015/3/30 16:28, Li, Aubrey wrote: Ying, can you please try this patch to see if the problem is gone on your side? Hi Aubrey, I would be better if we could change RTC driver instead. Thanks! Gerry Thanks, -Aubrey On 2015/3/26 20:13, Li, Aubrey wrote: On 2015/3/25 15:22, Huang Ying wrote: [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0) okay, I replicated this on my side now. Firstly, I don't think the patch did anything wrong. However, the patch exposes a few issues FWICT currently: - Should we enable RTC Alarm the kind of Fixed hardware event in hardware-reduced ACPI mode? I found RTC required registers in ACPI PM block are not valid(register address = 0) - I checked RTC device in ACPI table, there is no interrupt resource under RTC(firmware bug?), So irq 8 should be a hardcoded number. The question is, shouldn't we update bitmap of allocated_irqs here? Or we assume irq0~15 is reserved? If we assume IRQ0~15 is reserved, then requesting IRQ8 without updating bitmap of allocated_irqs is fine. - Because we don't update bitmap of allocated_irqs when RTC request IRQ8, so when MMC driver allocate irq resource, it's possible it gets irq8, so we saw genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0). So here is another question, when we dynamically allocate irq from irq domain, shouldn't we start from IRQ16? Yes, if allocated_irqs bitmap is updated, then it should be fine if we start from IRQ1. What the patch does is, it changes the behavior of how we allocate irq from irq domain. Previously we have legacy IRQs so we statically assign IRQ numbers for IOAPICs to host legacy IRQs, and now we allocate every IRQ dynamically. For me I think I can deliver a patch against RTC driver to update allocated_irqs bitmap, also, we should free irq when we found RTC ACPI registers are not valid. Certainly I'm open to any suggestions. Thanks, -Aubrey -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
On 2015/3/30 16:37, Jiang Liu wrote: On 2015/3/30 16:28, Li, Aubrey wrote: Ying, can you please try this patch to see if the problem is gone on your side? Hi Aubrey, I would be better if we could change RTC driver instead. Hey Gerry, IRQ8 for RTC is for history reason. If we dynamically assign IRQ to RTC, it might be a mess for legacy machine. If we still use IRQ8 for RTC but dynamically assign IRQ to other components, then there is a race IRQ8 being used before RTC driver is loaded. So, statically assigning IRQ is the best choice in my mind, this also matches the original IRQ assign policy. Thanks, -Aubrey Thanks! Gerry Thanks, -Aubrey On 2015/3/26 20:13, Li, Aubrey wrote: On 2015/3/25 15:22, Huang Ying wrote: [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0) okay, I replicated this on my side now. Firstly, I don't think the patch did anything wrong. However, the patch exposes a few issues FWICT currently: - Should we enable RTC Alarm the kind of Fixed hardware event in hardware-reduced ACPI mode? I found RTC required registers in ACPI PM block are not valid(register address = 0) - I checked RTC device in ACPI table, there is no interrupt resource under RTC(firmware bug?), So irq 8 should be a hardcoded number. The question is, shouldn't we update bitmap of allocated_irqs here? Or we assume irq0~15 is reserved? If we assume IRQ0~15 is reserved, then requesting IRQ8 without updating bitmap of allocated_irqs is fine. - Because we don't update bitmap of allocated_irqs when RTC request IRQ8, so when MMC driver allocate irq resource, it's possible it gets irq8, so we saw genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0). So here is another question, when we dynamically allocate irq from irq domain, shouldn't we start from IRQ16? Yes, if allocated_irqs bitmap is updated, then it should be fine if we start from IRQ1. What the patch does is, it changes the behavior of how we allocate irq from irq domain. Previously we have legacy IRQs so we statically assign IRQ numbers for IOAPICs to host legacy IRQs, and now we allocate every IRQ dynamically. For me I think I can deliver a patch against RTC driver to update allocated_irqs bitmap, also, we should free irq when we found RTC ACPI registers are not valid. Certainly I'm open to any suggestions. Thanks, -Aubrey -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
On 2015/3/25 15:22, Huang Ying wrote: > [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. > (rtc0) okay, I replicated this on my side now. Firstly, I don't think the patch did anything wrong. However, the patch exposes a few issues FWICT currently: - Should we enable RTC Alarm the kind of Fixed hardware event in hardware-reduced ACPI mode? I found RTC required registers in ACPI PM block are not valid(register address = 0) - I checked RTC device in ACPI table, there is no interrupt resource under RTC(firmware bug?), So irq 8 should be a hardcoded number. The question is, shouldn't we update bitmap of allocated_irqs here? Or we assume irq0~15 is reserved? If we assume IRQ0~15 is reserved, then requesting IRQ8 without updating bitmap of allocated_irqs is fine. - Because we don't update bitmap of allocated_irqs when RTC request IRQ8, so when MMC driver allocate irq resource, it's possible it gets irq8, so we saw "genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0)". So here is another question, when we dynamically allocate irq from irq domain, shouldn't we start from IRQ16? Yes, if allocated_irqs bitmap is updated, then it should be fine if we start from IRQ1. What the patch does is, it changes the behavior of how we allocate irq from irq domain. Previously we have legacy IRQs so we statically assign IRQ numbers for IOAPICs to host legacy IRQs, and now we allocate every IRQ dynamically. For me I think I can deliver a patch against RTC driver to update allocated_irqs bitmap, also, we should free irq when we found RTC ACPI registers are not valid. Certainly I'm open to any suggestions. Thanks, -Aubrey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
On 2015/3/25 15:22, Huang Ying wrote: [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0) okay, I replicated this on my side now. Firstly, I don't think the patch did anything wrong. However, the patch exposes a few issues FWICT currently: - Should we enable RTC Alarm the kind of Fixed hardware event in hardware-reduced ACPI mode? I found RTC required registers in ACPI PM block are not valid(register address = 0) - I checked RTC device in ACPI table, there is no interrupt resource under RTC(firmware bug?), So irq 8 should be a hardcoded number. The question is, shouldn't we update bitmap of allocated_irqs here? Or we assume irq0~15 is reserved? If we assume IRQ0~15 is reserved, then requesting IRQ8 without updating bitmap of allocated_irqs is fine. - Because we don't update bitmap of allocated_irqs when RTC request IRQ8, so when MMC driver allocate irq resource, it's possible it gets irq8, so we saw genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0). So here is another question, when we dynamically allocate irq from irq domain, shouldn't we start from IRQ16? Yes, if allocated_irqs bitmap is updated, then it should be fine if we start from IRQ1. What the patch does is, it changes the behavior of how we allocate irq from irq domain. Previously we have legacy IRQs so we statically assign IRQ numbers for IOAPICs to host legacy IRQs, and now we allocate every IRQ dynamically. For me I think I can deliver a patch against RTC driver to update allocated_irqs bitmap, also, we should free irq when we found RTC ACPI registers are not valid. Certainly I'm open to any suggestions. Thanks, -Aubrey -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
On 2015/3/24 8:53, Huang Ying wrote: > On Mon, 2015-03-23 at 14:18 +0800, Li, Aubrey wrote: >> On 2015/3/20 16:38, Huang Ying wrote: >>> FYI, we noticed the below changes on >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master >>> commit 7486341a98f26857f383aec88ffa10950087c3a1 ("x86/platform, acpi: >>> Bypass legacy PIC and PIT in ACPI hardware reduced mode") >>> >>> >>> +-+++ >>> | | 394838c960 | 7486341a98 | >>> +-+++ >>> | boot_successes | 10 | 10 | >>> | early-boot-hang | 1 | 1 | >>> +-+++ >>> >>> >>> [ 28.682462] microcode: CPU3 sig=0x30673, pf=0x2, revision=0x31e >>> [ 28.692739] microcode: Microcode Update Driver: v2.00 >>> , Peter Oruba >>> [ 28.739947] mmc0: Reset 0x1 never completed. >>> [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. >>> (rtc0) >> >> mmc driver requests IRQ 8? >> From surface it looks like either a firmware issue or ACPI get the wrong >> IRQ resource. >> I failed to replicate this issue with the attached config file on my >> side, which platform is the test running? > > Sorry for late. The test was running on an ASUS T100TA. I'm running on ASUS T100TA as well, is this replicable every time on your side? can you please send out the acpi table on your machine? Thanks, -Aubrey > > Best Regards, > Huang, Ying > >> Thanks, >> -Aubrey >>> [ 28.753151] CPU: 1 PID: 138 Comm: systemd-udevd Not tainted >>> 4.0.0-rc4-wl-03426-gdba586f #1 >>> [ 28.753156] 880076683480 8800764ffa78 818b2eb3 >>> 0007 >>> [ 28.753159] 88006d006800 8800764ffad8 810d37af >>> 8800764ffad8 >>> [ 28.753162] 0246 810d394a 880053bdc400 >>> >>> [ 28.753163] Call Trace: >>> [ 28.753174] [] dump_stack+0x4c/0x65 >>> [ 28.753180] [] __setup_irq+0x57f/0x5d0 >>> [ 28.753183] [] ? request_threaded_irq+0xaa/0x1b0 >>> [ 28.753191] [] ? sdhci_request+0x200/0x200 [sdhci] >>> [ 28.753194] [] request_threaded_irq+0xf4/0x1b0 >>> [ 28.753199] [] sdhci_add_host+0x800/0xf90 [sdhci] >>> [ 28.753205] [] sdhci_acpi_probe+0x348/0x440 >>> [sdhci_acpi] >>> [ 28.753210] [] platform_drv_probe+0x34/0xa0 >>> [ 28.753215] [] driver_probe_device+0x90/0x3e0 >>> [ 28.753218] [] __driver_attach+0x9b/0xa0 >>> [ 28.753221] [] ? __device_attach+0x40/0x40 >>> [ 28.753231] [] bus_for_each_dev+0x6b/0xb0 >>> [ 28.753234] [] driver_attach+0x1e/0x20 >>> [ 28.753237] [] bus_add_driver+0x180/0x250 >>> [ 28.753240] [] ? 0xa002e000 >>> [ 28.753243] [] driver_register+0x64/0xf0 >>> [ 28.753246] [] __platform_driver_register+0x4a/0x50 >>> [ 28.753250] [] sdhci_acpi_driver_init+0x17/0x1000 >>> [sdhci_acpi] >>> [ 28.753254] [] do_one_initcall+0xc0/0x1f0 >>> [ 28.753259] [] ? kmem_cache_alloc_trace+0x1cc/0x240 >>> [ 28.753262] [] ? do_init_module+0x28/0x1dd >>> [ 28.753266] [] do_init_module+0x61/0x1dd >>> [ 28.753270] [] load_module+0x189f/0x1be0 >>> [ 28.753274] [] ? store_uevent+0x40/0x40 >>> [ 28.753279] [] SyS_finit_module+0x86/0xb0 >>> [ 28.753283] [] system_call_fastpath+0x12/0x17 >>> [ 28.753700] mmc0: Failed to request IRQ 8: -16 >>> [ 28.975382] IOAPIC[0]: Set routing entry (8-16 -> 0x32 -> IRQ 13 Mode:1 >>> Active:1 Dest:15) >>> [ 28.975934] sdhci-acpi: probe of INT33BB:00 failed with error -16 >>> >>> >>> Thanks, >>> Ying Huang >>> >>> >>> >>> ___ >>> LKP mailing list >>> l...@linux.intel.com >>> >> > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
On Mon, 2015-03-23 at 14:18 +0800, Li, Aubrey wrote: > On 2015/3/20 16:38, Huang Ying wrote: > > FYI, we noticed the below changes on > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > commit 7486341a98f26857f383aec88ffa10950087c3a1 ("x86/platform, acpi: > > Bypass legacy PIC and PIT in ACPI hardware reduced mode") > > > > > > +-+++ > > | | 394838c960 | 7486341a98 | > > +-+++ > > | boot_successes | 10 | 10 | > > | early-boot-hang | 1 | 1 | > > +-+++ > > > > > > [ 28.682462] microcode: CPU3 sig=0x30673, pf=0x2, revision=0x31e > > [ 28.692739] microcode: Microcode Update Driver: v2.00 > > , Peter Oruba > > [ 28.739947] mmc0: Reset 0x1 never completed. > > [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. > > (rtc0) > > mmc driver requests IRQ 8? > From surface it looks like either a firmware issue or ACPI get the wrong > IRQ resource. > I failed to replicate this issue with the attached config file on my > side, which platform is the test running? Sorry for late. The test was running on an ASUS T100TA. Best Regards, Huang, Ying > Thanks, > -Aubrey > > [ 28.753151] CPU: 1 PID: 138 Comm: systemd-udevd Not tainted > > 4.0.0-rc4-wl-03426-gdba586f #1 > > [ 28.753156] 880076683480 8800764ffa78 818b2eb3 > > 0007 > > [ 28.753159] 88006d006800 8800764ffad8 810d37af > > 8800764ffad8 > > [ 28.753162] 0246 810d394a 880053bdc400 > > > > [ 28.753163] Call Trace: > > [ 28.753174] [] dump_stack+0x4c/0x65 > > [ 28.753180] [] __setup_irq+0x57f/0x5d0 > > [ 28.753183] [] ? request_threaded_irq+0xaa/0x1b0 > > [ 28.753191] [] ? sdhci_request+0x200/0x200 [sdhci] > > [ 28.753194] [] request_threaded_irq+0xf4/0x1b0 > > [ 28.753199] [] sdhci_add_host+0x800/0xf90 [sdhci] > > [ 28.753205] [] sdhci_acpi_probe+0x348/0x440 > > [sdhci_acpi] > > [ 28.753210] [] platform_drv_probe+0x34/0xa0 > > [ 28.753215] [] driver_probe_device+0x90/0x3e0 > > [ 28.753218] [] __driver_attach+0x9b/0xa0 > > [ 28.753221] [] ? __device_attach+0x40/0x40 > > [ 28.753231] [] bus_for_each_dev+0x6b/0xb0 > > [ 28.753234] [] driver_attach+0x1e/0x20 > > [ 28.753237] [] bus_add_driver+0x180/0x250 > > [ 28.753240] [] ? 0xa002e000 > > [ 28.753243] [] driver_register+0x64/0xf0 > > [ 28.753246] [] __platform_driver_register+0x4a/0x50 > > [ 28.753250] [] sdhci_acpi_driver_init+0x17/0x1000 > > [sdhci_acpi] > > [ 28.753254] [] do_one_initcall+0xc0/0x1f0 > > [ 28.753259] [] ? kmem_cache_alloc_trace+0x1cc/0x240 > > [ 28.753262] [] ? do_init_module+0x28/0x1dd > > [ 28.753266] [] do_init_module+0x61/0x1dd > > [ 28.753270] [] load_module+0x189f/0x1be0 > > [ 28.753274] [] ? store_uevent+0x40/0x40 > > [ 28.753279] [] SyS_finit_module+0x86/0xb0 > > [ 28.753283] [] system_call_fastpath+0x12/0x17 > > [ 28.753700] mmc0: Failed to request IRQ 8: -16 > > [ 28.975382] IOAPIC[0]: Set routing entry (8-16 -> 0x32 -> IRQ 13 Mode:1 > > Active:1 Dest:15) > > [ 28.975934] sdhci-acpi: probe of INT33BB:00 failed with error -16 > > > > > > Thanks, > > Ying Huang > > > > > > > > ___ > > LKP mailing list > > l...@linux.intel.com > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
On 2015/3/20 16:38, Huang Ying wrote: > FYI, we noticed the below changes on > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > commit 7486341a98f26857f383aec88ffa10950087c3a1 ("x86/platform, acpi: Bypass > legacy PIC and PIT in ACPI hardware reduced mode") > > > +-+++ > | | 394838c960 | 7486341a98 | > +-+++ > | boot_successes | 10 | 10 | > | early-boot-hang | 1 | 1 | > +-+++ > > > [ 28.682462] microcode: CPU3 sig=0x30673, pf=0x2, revision=0x31e > [ 28.692739] microcode: Microcode Update Driver: v2.00 > , Peter Oruba > [ 28.739947] mmc0: Reset 0x1 never completed. > [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. > (rtc0) mmc driver requests IRQ 8? >From surface it looks like either a firmware issue or ACPI get the wrong IRQ resource. I failed to replicate this issue with the attached config file on my side, which platform is the test running? Thanks, -Aubrey > [ 28.753151] CPU: 1 PID: 138 Comm: systemd-udevd Not tainted > 4.0.0-rc4-wl-03426-gdba586f #1 > [ 28.753156] 880076683480 8800764ffa78 818b2eb3 > 0007 > [ 28.753159] 88006d006800 8800764ffad8 810d37af > 8800764ffad8 > [ 28.753162] 0246 810d394a 880053bdc400 > > [ 28.753163] Call Trace: > [ 28.753174] [] dump_stack+0x4c/0x65 > [ 28.753180] [] __setup_irq+0x57f/0x5d0 > [ 28.753183] [] ? request_threaded_irq+0xaa/0x1b0 > [ 28.753191] [] ? sdhci_request+0x200/0x200 [sdhci] > [ 28.753194] [] request_threaded_irq+0xf4/0x1b0 > [ 28.753199] [] sdhci_add_host+0x800/0xf90 [sdhci] > [ 28.753205] [] sdhci_acpi_probe+0x348/0x440 [sdhci_acpi] > [ 28.753210] [] platform_drv_probe+0x34/0xa0 > [ 28.753215] [] driver_probe_device+0x90/0x3e0 > [ 28.753218] [] __driver_attach+0x9b/0xa0 > [ 28.753221] [] ? __device_attach+0x40/0x40 > [ 28.753231] [] bus_for_each_dev+0x6b/0xb0 > [ 28.753234] [] driver_attach+0x1e/0x20 > [ 28.753237] [] bus_add_driver+0x180/0x250 > [ 28.753240] [] ? 0xa002e000 > [ 28.753243] [] driver_register+0x64/0xf0 > [ 28.753246] [] __platform_driver_register+0x4a/0x50 > [ 28.753250] [] sdhci_acpi_driver_init+0x17/0x1000 > [sdhci_acpi] > [ 28.753254] [] do_one_initcall+0xc0/0x1f0 > [ 28.753259] [] ? kmem_cache_alloc_trace+0x1cc/0x240 > [ 28.753262] [] ? do_init_module+0x28/0x1dd > [ 28.753266] [] do_init_module+0x61/0x1dd > [ 28.753270] [] load_module+0x189f/0x1be0 > [ 28.753274] [] ? store_uevent+0x40/0x40 > [ 28.753279] [] SyS_finit_module+0x86/0xb0 > [ 28.753283] [] system_call_fastpath+0x12/0x17 > [ 28.753700] mmc0: Failed to request IRQ 8: -16 > [ 28.975382] IOAPIC[0]: Set routing entry (8-16 -> 0x32 -> IRQ 13 Mode:1 > Active:1 Dest:15) > [ 28.975934] sdhci-acpi: probe of INT33BB:00 failed with error -16 > > > Thanks, > Ying Huang > > > > ___ > LKP mailing list > l...@linux.intel.com > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
On 2015/3/20 16:38, Huang Ying wrote: FYI, we noticed the below changes on git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 7486341a98f26857f383aec88ffa10950087c3a1 (x86/platform, acpi: Bypass legacy PIC and PIT in ACPI hardware reduced mode) +-+++ | | 394838c960 | 7486341a98 | +-+++ | boot_successes | 10 | 10 | | early-boot-hang | 1 | 1 | +-+++ [ 28.682462] microcode: CPU3 sig=0x30673, pf=0x2, revision=0x31e [ 28.692739] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba [ 28.739947] mmc0: Reset 0x1 never completed. [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0) mmc driver requests IRQ 8? From surface it looks like either a firmware issue or ACPI get the wrong IRQ resource. I failed to replicate this issue with the attached config file on my side, which platform is the test running? Thanks, -Aubrey [ 28.753151] CPU: 1 PID: 138 Comm: systemd-udevd Not tainted 4.0.0-rc4-wl-03426-gdba586f #1 [ 28.753156] 880076683480 8800764ffa78 818b2eb3 0007 [ 28.753159] 88006d006800 8800764ffad8 810d37af 8800764ffad8 [ 28.753162] 0246 810d394a 880053bdc400 [ 28.753163] Call Trace: [ 28.753174] [818b2eb3] dump_stack+0x4c/0x65 [ 28.753180] [810d37af] __setup_irq+0x57f/0x5d0 [ 28.753183] [810d394a] ? request_threaded_irq+0xaa/0x1b0 [ 28.753191] [a006ddc0] ? sdhci_request+0x200/0x200 [sdhci] [ 28.753194] [810d3994] request_threaded_irq+0xf4/0x1b0 [ 28.753199] [a006b790] sdhci_add_host+0x800/0xf90 [sdhci] [ 28.753205] [a00295a8] sdhci_acpi_probe+0x348/0x440 [sdhci_acpi] [ 28.753210] [81558ab4] platform_drv_probe+0x34/0xa0 [ 28.753215] [815567f0] driver_probe_device+0x90/0x3e0 [ 28.753218] [81556c1b] __driver_attach+0x9b/0xa0 [ 28.753221] [81556b80] ? __device_attach+0x40/0x40 [ 28.753231] [815545cb] bus_for_each_dev+0x6b/0xb0 [ 28.753234] [8155626e] driver_attach+0x1e/0x20 [ 28.753237] [81555e30] bus_add_driver+0x180/0x250 [ 28.753240] [a002e000] ? 0xa002e000 [ 28.753243] [81557424] driver_register+0x64/0xf0 [ 28.753246] [815589fa] __platform_driver_register+0x4a/0x50 [ 28.753250] [a002e017] sdhci_acpi_driver_init+0x17/0x1000 [sdhci_acpi] [ 28.753254] [81002130] do_one_initcall+0xc0/0x1f0 [ 28.753259] [811cb86c] ? kmem_cache_alloc_trace+0x1cc/0x240 [ 28.753262] [818afb3c] ? do_init_module+0x28/0x1dd [ 28.753266] [818afb75] do_init_module+0x61/0x1dd [ 28.753270] [810fe9af] load_module+0x189f/0x1be0 [ 28.753274] [810f9e50] ? store_uevent+0x40/0x40 [ 28.753279] [810fee96] SyS_finit_module+0x86/0xb0 [ 28.753283] [818bb109] system_call_fastpath+0x12/0x17 [ 28.753700] mmc0: Failed to request IRQ 8: -16 [ 28.975382] IOAPIC[0]: Set routing entry (8-16 - 0x32 - IRQ 13 Mode:1 Active:1 Dest:15) [ 28.975934] sdhci-acpi: probe of INT33BB:00 failed with error -16 Thanks, Ying Huang ___ LKP mailing list l...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
On Mon, 2015-03-23 at 14:18 +0800, Li, Aubrey wrote: On 2015/3/20 16:38, Huang Ying wrote: FYI, we noticed the below changes on git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 7486341a98f26857f383aec88ffa10950087c3a1 (x86/platform, acpi: Bypass legacy PIC and PIT in ACPI hardware reduced mode) +-+++ | | 394838c960 | 7486341a98 | +-+++ | boot_successes | 10 | 10 | | early-boot-hang | 1 | 1 | +-+++ [ 28.682462] microcode: CPU3 sig=0x30673, pf=0x2, revision=0x31e [ 28.692739] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba [ 28.739947] mmc0: Reset 0x1 never completed. [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0) mmc driver requests IRQ 8? From surface it looks like either a firmware issue or ACPI get the wrong IRQ resource. I failed to replicate this issue with the attached config file on my side, which platform is the test running? Sorry for late. The test was running on an ASUS T100TA. Best Regards, Huang, Ying Thanks, -Aubrey [ 28.753151] CPU: 1 PID: 138 Comm: systemd-udevd Not tainted 4.0.0-rc4-wl-03426-gdba586f #1 [ 28.753156] 880076683480 8800764ffa78 818b2eb3 0007 [ 28.753159] 88006d006800 8800764ffad8 810d37af 8800764ffad8 [ 28.753162] 0246 810d394a 880053bdc400 [ 28.753163] Call Trace: [ 28.753174] [818b2eb3] dump_stack+0x4c/0x65 [ 28.753180] [810d37af] __setup_irq+0x57f/0x5d0 [ 28.753183] [810d394a] ? request_threaded_irq+0xaa/0x1b0 [ 28.753191] [a006ddc0] ? sdhci_request+0x200/0x200 [sdhci] [ 28.753194] [810d3994] request_threaded_irq+0xf4/0x1b0 [ 28.753199] [a006b790] sdhci_add_host+0x800/0xf90 [sdhci] [ 28.753205] [a00295a8] sdhci_acpi_probe+0x348/0x440 [sdhci_acpi] [ 28.753210] [81558ab4] platform_drv_probe+0x34/0xa0 [ 28.753215] [815567f0] driver_probe_device+0x90/0x3e0 [ 28.753218] [81556c1b] __driver_attach+0x9b/0xa0 [ 28.753221] [81556b80] ? __device_attach+0x40/0x40 [ 28.753231] [815545cb] bus_for_each_dev+0x6b/0xb0 [ 28.753234] [8155626e] driver_attach+0x1e/0x20 [ 28.753237] [81555e30] bus_add_driver+0x180/0x250 [ 28.753240] [a002e000] ? 0xa002e000 [ 28.753243] [81557424] driver_register+0x64/0xf0 [ 28.753246] [815589fa] __platform_driver_register+0x4a/0x50 [ 28.753250] [a002e017] sdhci_acpi_driver_init+0x17/0x1000 [sdhci_acpi] [ 28.753254] [81002130] do_one_initcall+0xc0/0x1f0 [ 28.753259] [811cb86c] ? kmem_cache_alloc_trace+0x1cc/0x240 [ 28.753262] [818afb3c] ? do_init_module+0x28/0x1dd [ 28.753266] [818afb75] do_init_module+0x61/0x1dd [ 28.753270] [810fe9af] load_module+0x189f/0x1be0 [ 28.753274] [810f9e50] ? store_uevent+0x40/0x40 [ 28.753279] [810fee96] SyS_finit_module+0x86/0xb0 [ 28.753283] [818bb109] system_call_fastpath+0x12/0x17 [ 28.753700] mmc0: Failed to request IRQ 8: -16 [ 28.975382] IOAPIC[0]: Set routing entry (8-16 - 0x32 - IRQ 13 Mode:1 Active:1 Dest:15) [ 28.975934] sdhci-acpi: probe of INT33BB:00 failed with error -16 Thanks, Ying Huang ___ LKP mailing list l...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)
On 2015/3/24 8:53, Huang Ying wrote: On Mon, 2015-03-23 at 14:18 +0800, Li, Aubrey wrote: On 2015/3/20 16:38, Huang Ying wrote: FYI, we noticed the below changes on git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 7486341a98f26857f383aec88ffa10950087c3a1 (x86/platform, acpi: Bypass legacy PIC and PIT in ACPI hardware reduced mode) +-+++ | | 394838c960 | 7486341a98 | +-+++ | boot_successes | 10 | 10 | | early-boot-hang | 1 | 1 | +-+++ [ 28.682462] microcode: CPU3 sig=0x30673, pf=0x2, revision=0x31e [ 28.692739] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba [ 28.739947] mmc0: Reset 0x1 never completed. [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0) mmc driver requests IRQ 8? From surface it looks like either a firmware issue or ACPI get the wrong IRQ resource. I failed to replicate this issue with the attached config file on my side, which platform is the test running? Sorry for late. The test was running on an ASUS T100TA. I'm running on ASUS T100TA as well, is this replicable every time on your side? can you please send out the acpi table on your machine? Thanks, -Aubrey Best Regards, Huang, Ying Thanks, -Aubrey [ 28.753151] CPU: 1 PID: 138 Comm: systemd-udevd Not tainted 4.0.0-rc4-wl-03426-gdba586f #1 [ 28.753156] 880076683480 8800764ffa78 818b2eb3 0007 [ 28.753159] 88006d006800 8800764ffad8 810d37af 8800764ffad8 [ 28.753162] 0246 810d394a 880053bdc400 [ 28.753163] Call Trace: [ 28.753174] [818b2eb3] dump_stack+0x4c/0x65 [ 28.753180] [810d37af] __setup_irq+0x57f/0x5d0 [ 28.753183] [810d394a] ? request_threaded_irq+0xaa/0x1b0 [ 28.753191] [a006ddc0] ? sdhci_request+0x200/0x200 [sdhci] [ 28.753194] [810d3994] request_threaded_irq+0xf4/0x1b0 [ 28.753199] [a006b790] sdhci_add_host+0x800/0xf90 [sdhci] [ 28.753205] [a00295a8] sdhci_acpi_probe+0x348/0x440 [sdhci_acpi] [ 28.753210] [81558ab4] platform_drv_probe+0x34/0xa0 [ 28.753215] [815567f0] driver_probe_device+0x90/0x3e0 [ 28.753218] [81556c1b] __driver_attach+0x9b/0xa0 [ 28.753221] [81556b80] ? __device_attach+0x40/0x40 [ 28.753231] [815545cb] bus_for_each_dev+0x6b/0xb0 [ 28.753234] [8155626e] driver_attach+0x1e/0x20 [ 28.753237] [81555e30] bus_add_driver+0x180/0x250 [ 28.753240] [a002e000] ? 0xa002e000 [ 28.753243] [81557424] driver_register+0x64/0xf0 [ 28.753246] [815589fa] __platform_driver_register+0x4a/0x50 [ 28.753250] [a002e017] sdhci_acpi_driver_init+0x17/0x1000 [sdhci_acpi] [ 28.753254] [81002130] do_one_initcall+0xc0/0x1f0 [ 28.753259] [811cb86c] ? kmem_cache_alloc_trace+0x1cc/0x240 [ 28.753262] [818afb3c] ? do_init_module+0x28/0x1dd [ 28.753266] [818afb75] do_init_module+0x61/0x1dd [ 28.753270] [810fe9af] load_module+0x189f/0x1be0 [ 28.753274] [810f9e50] ? store_uevent+0x40/0x40 [ 28.753279] [810fee96] SyS_finit_module+0x86/0xb0 [ 28.753283] [818bb109] system_call_fastpath+0x12/0x17 [ 28.753700] mmc0: Failed to request IRQ 8: -16 [ 28.975382] IOAPIC[0]: Set routing entry (8-16 - 0x32 - IRQ 13 Mode:1 Active:1 Dest:15) [ 28.975934] sdhci-acpi: probe of INT33BB:00 failed with error -16 Thanks, Ying Huang ___ LKP mailing list l...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/