From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4698981233011257115==" MIME-Version: 1.0 From: Jiang Liu To: lkp@lists.01.org Subject: Re: [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0) Date: Mon, 30 Mar 2015 16:37:34 +0800 Message-ID: <55190B4E.7080708@linux.intel.com> In-Reply-To: <55190910.3010905@linux.intel.com> List-Id: --===============4698981233011257115== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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. 00000080 (mmc0) vs. 000000= 00 (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 =3D 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. 00000080 (mmc0) vs. >> 00000000 (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 >> >=20 --===============4698981233011257115==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753367AbbC3Ih5 (ORCPT ); Mon, 30 Mar 2015 04:37:57 -0400 Received: from mga14.intel.com ([192.55.52.115]:60594 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753152AbbC3Ihy (ORCPT ); Mon, 30 Mar 2015 04:37:54 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,492,1422950400"; d="scan'208";a="706025381" Message-ID: <55190B4E.7080708@linux.intel.com> Date: Mon, 30 Mar 2015 16:37:34 +0800 From: Jiang Liu Organization: Intel User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Li, Aubrey" , Huang Ying CC: Ingo Molnar , LKML , LKP ML Subject: Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0) References: <1426840693.5570.55.camel@intel.com> <550FB034.8030403@linux.intel.com> <1427158405.17170.3.camel@intel.com> <5510F77F.8080703@linux.intel.com> <1427268154.17170.40.camel@intel.com> <5513F807.7070304@linux.intel.com> <55190910.3010905@linux.intel.com> In-Reply-To: <55190910.3010905@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 00000080 (mmc0) vs. 00000000 (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. 00000080 (mmc0) vs. >> 00000000 (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 >> >