Re: kernel-4.7 bug in Intel sound and/or ACPI
On 2016-06-30 05:30, Wim Osterholt wrote: On Wed, Jun 29, 2016 at 04:34:14AM -0400, Sinan Kaya wrote: > I posted this [PATCH V2 0/4] ACPI,PCI,IRQ: correct ISA penalty calculation Can you test this and give me a tested-by? Kernel-4.7-rc5 plus this patch works like a charm on my Inspiron 4100. Dmesg output is quite similar to the one from kernel-4.6 . Tested-by: Wim Osterholt. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel-4.7 bug in Intel sound and/or ACPI
On Wed, Jun 29, 2016 at 04:34:14AM -0400, Sinan Kaya wrote: > > > > I posted this [PATCH V2 0/4] ACPI,PCI,IRQ: correct ISA penalty calculation > > Can you test this and give me a tested-by? Kernel-4.7-rc5 plus this patch works like a charm on my Inspiron 4100. Dmesg output is quite similar to the one from kernel-4.6 . Tested-by: Wim Osterholt.
Re: kernel-4.7 bug in Intel sound and/or ACPI
On 6/27/2016 5:05 PM, ok...@codeaurora.org wrote: > On 2016-06-27 16:04, Wim Osterholt wrote: >> On Mon, Jun 27, 2016 at 04:22:18AM -0400, ok...@codeaurora.org wrote: >>> > However, an earlier try on my Inspiron 510m did not work. >>> > I'll do a clean retry later today, just to make sure. >>> >>> >>> Ok, let me know. I can post a clean patch series. I was trying to get >>> you something to test before posting the official version. >> >> The 510m just finished compiling and now it works fine too. >> Thanks. >> > > Nice, I will post the official version and let you know. > I posted this [PATCH V2 0/4] ACPI,PCI,IRQ: correct ISA penalty calculation Can you test this and give me a tested-by? Alex, If you could also review this, it would be great. Sinan >> >> >> Regards, Wim. >> >> >> - w...@djo.tudelft.nl - >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: kernel-4.7 bug in Intel sound and/or ACPI
On 2016-06-27 16:04, Wim Osterholt wrote: On Mon, Jun 27, 2016 at 04:22:18AM -0400, ok...@codeaurora.org wrote: > However, an earlier try on my Inspiron 510m did not work. > I'll do a clean retry later today, just to make sure. Ok, let me know. I can post a clean patch series. I was trying to get you something to test before posting the official version. The 510m just finished compiling and now it works fine too. Thanks. Nice, I will post the official version and let you know. Regards, Wim. - w...@djo.tudelft.nl - -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel-4.7 bug in Intel sound and/or ACPI
On Mon, Jun 27, 2016 at 04:22:18AM -0400, ok...@codeaurora.org wrote: > > However, an earlier try on my Inspiron 510m did not work. > > I'll do a clean retry later today, just to make sure. > > > Ok, let me know. I can post a clean patch series. I was trying to get > you something to test before posting the official version. The 510m just finished compiling and now it works fine too. Thanks. Regards, Wim. - w...@djo.tudelft.nl -
Re: kernel-4.7 bug in Intel sound and/or ACPI
On 2016-06-27 02:27, Wim Osterholt wrote: On Sat, Jun 25, 2016 at 04:51:03AM -0400, ok...@codeaurora.org wrote: On 2016-06-24 21:39, Wim Osterholt wrote: Please apply the patches on top of clean 4.7-rc4 tree and apply them in order with git am 0001... git am 0002... It doesn't work that way. Beginners problems with git. Tried all kinds of things, including a new git clone to no avail. Took a long time to discover that in the above example these were the names of the 'attachments'. It didn't work. Error 'could not find out the kind of patch' or some such. Took much longer to find out that in that mail and in the saved attachments there were lines beginning with '>From' that were the culprit. Still not found out how to make patch work without errors. Anyway, by doing it with more manual intervention om a stock kernel-4.7-rc4 on my (very slow) Inspiron 4100 it seems to work like before. Hooray. However, an earlier try on my Inspiron 510m did not work. I'll do a clean retry later today, just to make sure. Ok, let me know. I can post a clean patch series. I was trying to get you something to test before posting the official version. regards, Wim. - w...@djo.tudelft.nl - -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel-4.7 bug in Intel sound and/or ACPI
On Sat, Jun 25, 2016 at 04:51:03AM -0400, ok...@codeaurora.org wrote: > On 2016-06-24 21:39, Wim Osterholt wrote: > > Please apply the patches on top of clean 4.7-rc4 tree and apply them in > order with > > git am 0001... > git am 0002... It doesn't work that way. Beginners problems with git. Tried all kinds of things, including a new git clone to no avail. Took a long time to discover that in the above example these were the names of the 'attachments'. It didn't work. Error 'could not find out the kind of patch' or some such. Took much longer to find out that in that mail and in the saved attachments there were lines beginning with '>From' that were the culprit. Still not found out how to make patch work without errors. Anyway, by doing it with more manual intervention om a stock kernel-4.7-rc4 on my (very slow) Inspiron 4100 it seems to work like before. Hooray. However, an earlier try on my Inspiron 510m did not work. I'll do a clean retry later today, just to make sure. regards, Wim. - w...@djo.tudelft.nl -
Re: kernel-4.7 bug in Intel sound and/or ACPI
On 2016-06-24 21:39, Wim Osterholt wrote: On Fri, Jun 24, 2016 at 02:09:15AM -0400, Sinan Kaya wrote: Can you give it a try? Whell, I tried to no avail. Wether it is on 4.6 or 4.7, with or without your previous patch, I keep getting rejected hunks. For example, here the line to be deleted is nowhere to be found: diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c index 714ba4d..c2f22c9 100644 --- a/drivers/acpi/pci_link.c +++ b/drivers/acpi/pci_link.c @@ -497,7 +497,7 @@ static int acpi_irq_get_penalty(int irq) int penalty = 0; if (irq < ACPI_MAX_ISA_IRQS) - penalty += acpi_isa_irq_penalty[irq]; + return acpi_isa_irq_penalty[irq]; /* * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict Regards, Wim. - w...@djo.tudelft.nl - Please apply the patches on top of clean 4.7-rc4 tree and apply them in order with git am 0001... git am 0002...
Re: kernel-4.7 bug in Intel sound and/or ACPI
On Fri, Jun 24, 2016 at 02:09:15AM -0400, Sinan Kaya wrote: > > Can you give it a try? Whell, I tried to no avail. Wether it is on 4.6 or 4.7, with or without your previous patch, I keep getting rejected hunks. For example, here the line to be deleted is nowhere to be found: > diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c > index 714ba4d..c2f22c9 100644 > --- a/drivers/acpi/pci_link.c > +++ b/drivers/acpi/pci_link.c > @@ -497,7 +497,7 @@ static int acpi_irq_get_penalty(int irq) > int penalty = 0; > > if (irq < ACPI_MAX_ISA_IRQS) > - penalty += acpi_isa_irq_penalty[irq]; > + return acpi_isa_irq_penalty[irq]; > > /* > * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict Regards, Wim. - w...@djo.tudelft.nl -
Re: kernel-4.7 bug in Intel sound and/or ACPI
On 6/23/2016 7:25 PM, Wim Osterholt wrote:
> On Thu, Jun 23, 2016 at 11:45:47AM -0400, Sinan Kaya wrote:
>>>
>>> Sure, let me get a patch for you.
>>
>> Here it is
>
> http://webserver.djo.tudelft.nl/dmesg460+printpatch2
>
Thanks, this was very helpful. I was able to fix the problem by using
the values in your log.
Can you give it a try?
>
>> I am trying to find a system with similar characteristics for debug
>
> All from the same laptop, Dell Inspiron 4100.
> The same problem arises at a Dell Inspiron 510m.
> I've not seen it on a workstation Dell XW4300.
>
>
>
> Groeten, Wim.
>
>
> - w...@djo.tudelft.nl -
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
>From 44dabd4b7413a4edee4b7399f95f6ce10c8bbd27 Mon Sep 17 00:00:00 2001
From: Sinan Kaya
Date: Fri, 24 Jun 2016 01:04:05 -0400
Subject: [PATCH 2/4] Revert "ACPI,PCI,IRQ: remove redundant code in
acpi_irq_penalty_init()"
Trying to make the ISA and PCI init functionality common turned out to be
a bad idea. ISA path depends on external functionality. Restoring the
previous behavior and limiting the refactoring to PCI interrupts only.
This reverts commit 1fcb6a813c4f ("ACPI,PCI,IRQ: remove redundant code in
acpi_irq_penalty_init()").
Signed-off-by: Sinan Kaya
---
arch/x86/pci/acpi.c | 1 +
drivers/acpi/pci_link.c | 36
include/acpi/acpi_drivers.h | 1 +
3 files changed, 38 insertions(+)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index b2a4e2a..3cd6983 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -396,6 +396,7 @@ int __init pci_acpi_init(void)
return -ENODEV;
printk(KERN_INFO "PCI: Using ACPI for IRQ routing\n");
+ acpi_irq_penalty_init();
pcibios_enable_irq = acpi_pci_irq_enable;
pcibios_disable_irq = acpi_pci_irq_disable;
x86_init.pci.init_irq = x86_init_noop;
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index f2b69e3..714ba4d 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -517,6 +517,42 @@ static int acpi_irq_get_penalty(int irq)
return penalty;
}
+int __init acpi_irq_penalty_init(void)
+{
+ struct acpi_pci_link *link;
+ int i;
+
+ /*
+* Update penalties to facilitate IRQ balancing.
+*/
+ list_for_each_entry(link, &acpi_link_list, list) {
+
+ /*
+* reflect the possible and active irqs in the penalty table --
+* useful for breaking ties.
+*/
+ if (link->irq.possible_count) {
+ int penalty =
+ PIRQ_PENALTY_PCI_POSSIBLE /
+ link->irq.possible_count;
+
+ for (i = 0; i < link->irq.possible_count; i++) {
+ if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS)
+ acpi_isa_irq_penalty[link->irq.
+possible[i]] +=
+ penalty;
+ }
+
+ } else if (link->irq.active &&
+ (link->irq.active < ACPI_MAX_ISA_IRQS)) {
+ acpi_isa_irq_penalty[link->irq.active] +=
+ PIRQ_PENALTY_PCI_POSSIBLE;
+ }
+ }
+
+ return 0;
+}
+
static int acpi_irq_balance = -1; /* 0: static, 1: balance */
static int acpi_pci_link_allocate(struct acpi_pci_link *link)
diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
index 797ae2e..29c6912 100644
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -78,6 +78,7 @@
/* ACPI PCI Interrupt Link (pci_link.c) */
+int acpi_irq_penalty_init(void);
int acpi_pci_link_allocate_irq(acpi_handle handle, int index, int *triggering,
int *polarity, char **name);
int acpi_pci_link_free_irq(acpi_handle handle);
--
1.8.2.1
>From 81acb01ea4950d5f87c9f1b43f396f798d512b89 Mon Sep 17 00:00:00 2001
From: Sinan Kaya
Date: Fri, 24 Jun 2016 01:31:04 -0400
Subject: [PATCH 3/4] ACPI,PCI,IRQ: separate ISA penalty calculation
Since commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
the penalty values are calculated on the fly rather than boot time.
This works fine for PCI interrupts but not so well for the ISA interrupts.
Whether an ISA interrupt is in use or not information is not available
inside the pci_link.c file. This information gets sent externally via
acpi_penalize_isa_irq function. If active is true, then the IRQ
Re: kernel-4.7 bug in Intel sound and/or ACPI
On Thu, Jun 23, 2016 at 11:45:47AM -0400, Sinan Kaya wrote: > > > > Sure, let me get a patch for you. > > Here it is http://webserver.djo.tudelft.nl/dmesg460+printpatch2 > I am trying to find a system with similar characteristics for debug All from the same laptop, Dell Inspiron 4100. The same problem arises at a Dell Inspiron 510m. I've not seen it on a workstation Dell XW4300. Groeten, Wim. - w...@djo.tudelft.nl -
Re: kernel-4.7 bug in Intel sound and/or ACPI
On Thu, 23 Jun 2016 11:21:58 -0500
Bjorn Helgaas wrote:
> [+cc Alex, FYI]
>
> This thread is about a regression that we'll want to fix before v4.7
> releases. It looks like it's related to these changes which were
> merged via the ACPI tree:
>
> 9e5ed6d1fb87 ACPI,PCI,IRQ: remove SCI penalize function
> 1fcb6a813c4f ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()
> 5c5087a55390 ACPI,PCI,IRQ: reduce static IRQ array size to 16
> 103544d86976 ACPI,PCI,IRQ: reduce resource requirements
>
> If that turns out to be the case, it probably makes sense to merge the fix
> via the ACPI tree as well. But in the unlikely event the fix turns out to
> be in PCI, Alex will probably have to merge it because I'll be on vacation.
> So I'm adding Alex to the CC: list in case that happens.
Thanks, I'm watching it now. I'll also encourage anyone posting other
fixes that they feel are relevant to v4.7 while Bjorn is away to please
proactively poke me. Bjorn is pretty strict about only accepting
regression fixes after the merge window and I intend to do the same.
Thanks,
Alex
> On Thu, Jun 23, 2016 at 11:45:47AM -0400, Sinan Kaya wrote:
> > On 6/23/2016 10:55 AM, Sinan Kaya wrote:
> > > On 6/23/2016 10:12 AM, Wim Osterholt wrote:
> > >> On Wed, Jun 22, 2016 at 11:54:39PM -0400, ok...@codeaurora.org wrote:
> > >>> On 2016-06-21 18:13, Wim Osterholt wrote:
> > >
> > > pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__,
> > > irq,
> > > penalty);
> > >
> >
> > This produced some 60 lines extra
> > >>>
> > >>> Thanks, let's go back to 4.6 and add a very similar printf to every
> > >>> single place where the array is modified and also right before the
> > >>> enabled message.
> > >>>
> > >>
> > >> I don't get this right.
> > >> Assuming that you're still talking about the same file, I find a few
> > >> instances of 'enabled', most of them in if-statements and one where it
> > >> might
> > >> be set, so it looks. However, that's already in a printk statement.
> > >> I don't know about arrays and even less where these are set. Even worse,
> > >> I
> > >> don't know what to put in a 'similar' line if you don't mean 'exactly the
> > >> same'.
> > >> So please state file and line numbers and the line to be inserted.
> > >>
> > >
> > > Sure, let me get a patch for you. I was hoping to do it yesterday.
> > > I ran out of time. I typed the message from my phone.
> > >
> >
> > Here it is
> >
> >
> >
> > --
> > Sinan Kaya
> > Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> > Foundation Collaborative Project
>
> > diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> > index ededa90..228b61f 100644
> > --- a/drivers/acpi/pci_link.c
> > +++ b/drivers/acpi/pci_link.c
> > @@ -487,15 +487,18 @@ int __init acpi_irq_penalty_init(void)
> > link->irq.possible_count;
> >
> > for (i = 0; i < link->irq.possible_count; i++) {
> > - if (link->irq.possible[i] < ACPI_MAX_ISA_IRQ)
> > + if (link->irq.possible[i] < ACPI_MAX_ISA_IRQ) {
> > acpi_irq_penalty[link->irq.
> > possible[i]] +=
> > penalty;
> > + pr_info("%s:%d acpi_irq_penalty[%d] =
> > 0x%x\n", __func__, __LINE__, link->irq.possible[i],
> > acpi_irq_penalty[link->irq.possible[i]]);
> > + }
> > }
> >
> > } else if (link->irq.active) {
> > acpi_irq_penalty[link->irq.active] +=
> > PIRQ_PENALTY_PCI_POSSIBLE;
> > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n",
> > __func__, __LINE__, link->irq.active, acpi_irq_penalty[link->irq.active]);
> > }
> > }
> >
> > @@ -548,8 +551,11 @@ static int acpi_pci_link_allocate(struct acpi_pci_link
> > *link)
> > */
> > for (i = (link->irq.possible_count - 1); i >= 0; i--) {
> > if (acpi_irq_penalty[irq] >
> > - acpi_irq_penalty[link->irq.possible[i]])
> > + acpi_irq_penalty[link->irq.possible[i]]) {
> > + pr_info("%s:%d
> > acpi_irq_penalty[irq=%d](0x%x) vs. acpi_irq_penalty[%d](0x%x)\n",
> > + __func__, __LINE__, irq,
> > acpi_irq_penalty[irq], link->irq.possible[i],
> > acpi_irq_penalty[link->irq.possible[i]]);
> > irq = link->irq.possible[i];
> > + }
> > }
> > }
> > if (acpi_irq_penalty[irq] >= PIRQ_PENALTY_ISA_ALWAYS) {
> > @@ -569,6 +575,7 @@ static int acpi_pci_link_allocate(struct acpi_pci_link
Re: kernel-4.7 bug in Intel sound and/or ACPI
[+cc Alex, FYI]
This thread is about a regression that we'll want to fix before v4.7
releases. It looks like it's related to these changes which were
merged via the ACPI tree:
9e5ed6d1fb87 ACPI,PCI,IRQ: remove SCI penalize function
1fcb6a813c4f ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()
5c5087a55390 ACPI,PCI,IRQ: reduce static IRQ array size to 16
103544d86976 ACPI,PCI,IRQ: reduce resource requirements
If that turns out to be the case, it probably makes sense to merge the fix
via the ACPI tree as well. But in the unlikely event the fix turns out to
be in PCI, Alex will probably have to merge it because I'll be on vacation.
So I'm adding Alex to the CC: list in case that happens.
On Thu, Jun 23, 2016 at 11:45:47AM -0400, Sinan Kaya wrote:
> On 6/23/2016 10:55 AM, Sinan Kaya wrote:
> > On 6/23/2016 10:12 AM, Wim Osterholt wrote:
> >> On Wed, Jun 22, 2016 at 11:54:39PM -0400, ok...@codeaurora.org wrote:
> >>> On 2016-06-21 18:13, Wim Osterholt wrote:
> >
> > pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__,
> > irq,
> > penalty);
> >
>
> This produced some 60 lines extra
> >>>
> >>> Thanks, let's go back to 4.6 and add a very similar printf to every
> >>> single place where the array is modified and also right before the
> >>> enabled message.
> >>>
> >>
> >> I don't get this right.
> >> Assuming that you're still talking about the same file, I find a few
> >> instances of 'enabled', most of them in if-statements and one where it
> >> might
> >> be set, so it looks. However, that's already in a printk statement.
> >> I don't know about arrays and even less where these are set. Even worse, I
> >> don't know what to put in a 'similar' line if you don't mean 'exactly the
> >> same'.
> >> So please state file and line numbers and the line to be inserted.
> >>
> >
> > Sure, let me get a patch for you. I was hoping to do it yesterday.
> > I ran out of time. I typed the message from my phone.
> >
>
> Here it is
>
>
>
> --
> Sinan Kaya
> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index ededa90..228b61f 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -487,15 +487,18 @@ int __init acpi_irq_penalty_init(void)
> link->irq.possible_count;
>
> for (i = 0; i < link->irq.possible_count; i++) {
> - if (link->irq.possible[i] < ACPI_MAX_ISA_IRQ)
> + if (link->irq.possible[i] < ACPI_MAX_ISA_IRQ) {
> acpi_irq_penalty[link->irq.
>possible[i]] +=
> penalty;
> + pr_info("%s:%d acpi_irq_penalty[%d] =
> 0x%x\n", __func__, __LINE__, link->irq.possible[i],
> acpi_irq_penalty[link->irq.possible[i]]);
> + }
> }
>
> } else if (link->irq.active) {
> acpi_irq_penalty[link->irq.active] +=
> PIRQ_PENALTY_PCI_POSSIBLE;
> + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n",
> __func__, __LINE__, link->irq.active, acpi_irq_penalty[link->irq.active]);
> }
> }
>
> @@ -548,8 +551,11 @@ static int acpi_pci_link_allocate(struct acpi_pci_link
> *link)
>*/
> for (i = (link->irq.possible_count - 1); i >= 0; i--) {
> if (acpi_irq_penalty[irq] >
> - acpi_irq_penalty[link->irq.possible[i]])
> + acpi_irq_penalty[link->irq.possible[i]]) {
> + pr_info("%s:%d
> acpi_irq_penalty[irq=%d](0x%x) vs. acpi_irq_penalty[%d](0x%x)\n",
> + __func__, __LINE__, irq,
> acpi_irq_penalty[irq], link->irq.possible[i],
> acpi_irq_penalty[link->irq.possible[i]]);
> irq = link->irq.possible[i];
> + }
> }
> }
> if (acpi_irq_penalty[irq] >= PIRQ_PENALTY_ISA_ALWAYS) {
> @@ -569,6 +575,7 @@ static int acpi_pci_link_allocate(struct acpi_pci_link
> *link)
> return -ENODEV;
> } else {
> acpi_irq_penalty[link->irq.active] += PIRQ_PENALTY_PCI_USING;
> + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__,
> __LINE__, link->irq.active, acpi_irq_penalty[link->irq.active]);
> printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
> acpi_device_name(link->device),
> acpi_device_bid(link->device), link->irq.active);
> @@ -804,6 +811,8 @@ static int __init acpi_
Re: kernel-4.7 bug in Intel sound and/or ACPI
On 6/23/2016 10:55 AM, Sinan Kaya wrote:
> On 6/23/2016 10:12 AM, Wim Osterholt wrote:
>> On Wed, Jun 22, 2016 at 11:54:39PM -0400, ok...@codeaurora.org wrote:
>>> On 2016-06-21 18:13, Wim Osterholt wrote:
>
> pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq,
> penalty);
>
This produced some 60 lines extra
>>>
>>> Thanks, let's go back to 4.6 and add a very similar printf to every
>>> single place where the array is modified and also right before the
>>> enabled message.
>>>
>>
>> I don't get this right.
>> Assuming that you're still talking about the same file, I find a few
>> instances of 'enabled', most of them in if-statements and one where it might
>> be set, so it looks. However, that's already in a printk statement.
>> I don't know about arrays and even less where these are set. Even worse, I
>> don't know what to put in a 'similar' line if you don't mean 'exactly the
>> same'.
>> So please state file and line numbers and the line to be inserted.
>>
>
> Sure, let me get a patch for you. I was hoping to do it yesterday.
> I ran out of time. I typed the message from my phone.
>
Here it is
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index ededa90..228b61f 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -487,15 +487,18 @@ int __init acpi_irq_penalty_init(void)
link->irq.possible_count;
for (i = 0; i < link->irq.possible_count; i++) {
- if (link->irq.possible[i] < ACPI_MAX_ISA_IRQ)
+ if (link->irq.possible[i] < ACPI_MAX_ISA_IRQ) {
acpi_irq_penalty[link->irq.
possible[i]] +=
penalty;
+ pr_info("%s:%d acpi_irq_penalty[%d] =
0x%x\n", __func__, __LINE__, link->irq.possible[i],
acpi_irq_penalty[link->irq.possible[i]]);
+ }
}
} else if (link->irq.active) {
acpi_irq_penalty[link->irq.active] +=
PIRQ_PENALTY_PCI_POSSIBLE;
+ pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n",
__func__, __LINE__, link->irq.active, acpi_irq_penalty[link->irq.active]);
}
}
@@ -548,8 +551,11 @@ static int acpi_pci_link_allocate(struct acpi_pci_link
*link)
*/
for (i = (link->irq.possible_count - 1); i >= 0; i--) {
if (acpi_irq_penalty[irq] >
- acpi_irq_penalty[link->irq.possible[i]])
+ acpi_irq_penalty[link->irq.possible[i]]) {
+ pr_info("%s:%d
acpi_irq_penalty[irq=%d](0x%x) vs. acpi_irq_penalty[%d](0x%x)\n",
+ __func__, __LINE__, irq,
acpi_irq_penalty[irq], link->irq.possible[i],
acpi_irq_penalty[link->irq.possible[i]]);
irq = link->irq.possible[i];
+ }
}
}
if (acpi_irq_penalty[irq] >= PIRQ_PENALTY_ISA_ALWAYS) {
@@ -569,6 +575,7 @@ static int acpi_pci_link_allocate(struct acpi_pci_link
*link)
return -ENODEV;
} else {
acpi_irq_penalty[link->irq.active] += PIRQ_PENALTY_PCI_USING;
+ pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__,
__LINE__, link->irq.active, acpi_irq_penalty[link->irq.active]);
printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
acpi_device_name(link->device),
acpi_device_bid(link->device), link->irq.active);
@@ -804,6 +811,8 @@ static int __init acpi_irq_penalty_update(char *str, int
used)
else
acpi_irq_penalty[irq] = PIRQ_PENALTY_PCI_AVAILABLE;
+ pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__,
__LINE__, irq, acpi_irq_penalty[irq]);
+
if (retval != 2)/* no next number */
break;
}
@@ -824,11 +833,16 @@ void acpi_penalize_isa_irq(int irq, int active)
acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_USED;
else
acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING;
+
+ pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__,
__LINE__, irq, acpi_irq_penalty[irq]);
}
}
bool acpi_isa_irq_available(int irq)
{
+ if (irq >= 0 && (irq < ARRAY_SIZE(acpi_irq_penalty)))
+ pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__,
__LINE__, irq, acpi_irq_pena
Re: kernel-4.7 bug in Intel sound and/or ACPI
On 6/23/2016 10:12 AM, Wim Osterholt wrote:
> On Wed, Jun 22, 2016 at 11:54:39PM -0400, ok...@codeaurora.org wrote:
>> On 2016-06-21 18:13, Wim Osterholt wrote:
pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq,
penalty);
>>>
>>> This produced some 60 lines extra
>>
>> Thanks, let's go back to 4.6 and add a very similar printf to every
>> single place where the array is modified and also right before the
>> enabled message.
>>
>
> I don't get this right.
> Assuming that you're still talking about the same file, I find a few
> instances of 'enabled', most of them in if-statements and one where it might
> be set, so it looks. However, that's already in a printk statement.
> I don't know about arrays and even less where these are set. Even worse, I
> don't know what to put in a 'similar' line if you don't mean 'exactly the
> same'.
> So please state file and line numbers and the line to be inserted.
>
Sure, let me get a patch for you. I was hoping to do it yesterday.
I ran out of time. I typed the message from my phone.
>
>
> Groeten, Wim.
>
>
> - w...@djo.tudelft.nl -
>
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
Re: kernel-4.7 bug in Intel sound and/or ACPI
On Wed, Jun 22, 2016 at 11:54:39PM -0400, ok...@codeaurora.org wrote:
> On 2016-06-21 18:13, Wim Osterholt wrote:
> >>
> >>pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq,
> >>penalty);
> >>
> >
> > This produced some 60 lines extra
>
> Thanks, let's go back to 4.6 and add a very similar printf to every
> single place where the array is modified and also right before the
> enabled message.
>
I don't get this right.
Assuming that you're still talking about the same file, I find a few
instances of 'enabled', most of them in if-statements and one where it might
be set, so it looks. However, that's already in a printk statement.
I don't know about arrays and even less where these are set. Even worse, I
don't know what to put in a 'similar' line if you don't mean 'exactly the
same'.
So please state file and line numbers and the line to be inserted.
Groeten, Wim.
- w...@djo.tudelft.nl -
Re: kernel-4.7 bug in Intel sound and/or ACPI
On 2016-06-21 18:13, Wim Osterholt wrote:
On Tue, Jun 21, 2016 at 09:40:10AM -0400, Sinan Kaya wrote:
Thanks, It was a guess with no proof.
Let's undo the change above and start adding some print statements to
collect
data from your system.
Can you add this to the end of acpi_irq_get_penalty function and then
send
the output?
pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq,
penalty);
This produced some 60 lines extra. Too much to include here.
The entire dmesg file is here:
http://webserver.djo.tudelft.nl/dmesg474+printpenalty
Thanks, let's go back to 4.6 and add a very similar printf to every
single place where the array is modified and also right before the
enabled message.
I am trying to find a system with similar characteristics for debug
Regards, Wim.
- w...@djo.tudelft.nl -
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel-4.7 bug in Intel sound and/or ACPI
On Tue, Jun 21, 2016 at 09:40:10AM -0400, Sinan Kaya wrote:
>
> Thanks, It was a guess with no proof.
>
> Let's undo the change above and start adding some print statements to collect
> data from your system.
>
> Can you add this to the end of acpi_irq_get_penalty function and then send
> the output?
>
> pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq,
> penalty);
>
This produced some 60 lines extra. Too much to include here.
The entire dmesg file is here:
http://webserver.djo.tudelft.nl/dmesg474+printpenalty
Regards, Wim.
- w...@djo.tudelft.nl -
Re: kernel-4.7 bug in Intel sound and/or ACPI
On 6/21/2016 8:47 AM, Wim Osterholt wrote:
>> Can you try the following and see if it makes any difference?
>>
>>
>> --- a/drivers/acpi/pci_link.c
>> +++ b/drivers/acpi/pci_link.c
>> @@ -500,7 +500,7 @@ static int acpi_irq_get_penalty(int irq)
>> int penalty = 0;
>>
>> if (irq < ACPI_MAX_ISA_IRQS)
>> - penalty += acpi_isa_irq_penalty[irq];
>> + return acpi_isa_irq_penalty[irq];
>>
>> /*
>> * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
>> @@ -586,6 +586,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link
>> *link)
>> acpi_device_bid(link->device));
>> return -ENODEV;
>> } else {
>> + if (irq < ACPI_MAX_ISA_IRQS)
>> + acpi_isa_irq_penalty[irq] =
>> acpi_irq_get_penalty(irq) +
>> +
>> PIRQ_PENALTY_PCI_USING;
>> +
>>
>>
>>
>>> Bjorn
>
>
> I tried this on kernel 4.7.0-rc4, but that didn't help. It still tried to
> grab irq7.
>
>
Thanks, It was a guess with no proof.
Let's undo the change above and start adding some print statements to collect
data from your system.
Can you add this to the end of acpi_irq_get_penalty function and then send
the output?
pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq,
penalty);
> Regards, Wim.
>
>
> - w...@djo.tudelft.nl -
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
Re: kernel-4.7 bug in Intel sound and/or ACPI
> Can you try the following and see if it makes any difference?
>
>
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -500,7 +500,7 @@ static int acpi_irq_get_penalty(int irq)
> int penalty = 0;
>
> if (irq < ACPI_MAX_ISA_IRQS)
> - penalty += acpi_isa_irq_penalty[irq];
> + return acpi_isa_irq_penalty[irq];
>
> /*
> * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> @@ -586,6 +586,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link
> *link)
> acpi_device_bid(link->device));
> return -ENODEV;
> } else {
> + if (irq < ACPI_MAX_ISA_IRQS)
> + acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq)
> +
> +
> PIRQ_PENALTY_PCI_USING;
> +
>
>
>
> > Bjorn
I tried this on kernel 4.7.0-rc4, but that didn't help. It still tried to
grab irq7.
Regards, Wim.
- w...@djo.tudelft.nl -
Re: kernel-4.7 bug in Intel sound and/or ACPI
On 6/20/2016 5:25 PM, Bjorn Helgaas wrote:
> [+cc Sinan]
>
> On Mon, Jun 20, 2016 at 03:02:57AM +0200, Rafael J. Wysocki wrote:
>> You should CC the linux-pci too (done now)
>>
>> On Monday, June 20, 2016 02:35:30 AM Wim Osterholt wrote:
>>> L.S.
>>> up to vanilla kernel-4.6.2 sound was working fine.
>>> Switching to kernel-4.7.0-rc3 made sound disappear. No /dev/mixer etc.
>>> There appears to be a bug in the Intel sound driver and/or ACPI driver.
>>> Dmesg shows interesting lines like:
>>> [ 11.498592] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7
>>> [ 11.498605] PCI: setting IRQ 7 as level-triggered
>>> [ 11.543903] parport0: PC-style at 0x378 (0x778), irq 7
>>> [PCSPP,TRISTATE,EPP]
>>> [ 12.757735] genirq: Flags mismatch irq 7. 0080 (snd_intel8x0m) vs.
>>> (parport0)
>>> [ 12.757751] snd_intel8x0m :00:1f.6: unable to grab IRQ 7
>>> [ 12.757875] snd_intel8x0m: probe of :00:1f.6 failed with error -16
>>> [ 12.900171] genirq: Flags mismatch irq 7. 0080 (snd_intel8x0) vs.
>>> (parport0)
>>> [ 12.900189] snd_intel8x0 :00:1f.5: unable to grab IRQ 7
>>> [ 12.900389] snd_intel8x0: probe of :00:1f.5 failed with error -16
>>> [ 12.922554] genirq: Flags mismatch irq 7. 0080 (ipw2200) vs.
>>> (parport0)
>>> [ 12.922559] ipw2200: Error allocating IRQ 7
>>>
>>> If I boot kernel-4.7.0-rc3 with acpi=off then sound is back!
>>>
>>> If you need the full dmesg outputs then please get them here:
>>> http://webserver.djo.tudelft.nl/dmesg460+ACPI
>>> http://webserver.djo.tudelft.nl/dmesg473+ACPI
>>> http://webserver.djo.tudelft.nl/dmesg473noACPI
>>> (with excuses for the silly hostname which is out of our control)
>
> I think snd_intel8x0 (00:1f.5) is connected to LNKB, and in v4.6 LNKB
> was set to IRQ 5, while in v4.7 LNKB is connected to IRQ7. It looks
> like IRQ7 is already in use by parport, which doesn't want to share
> it.
>
> This might be related to Sinan's changes to pci_link.c, which
> were merged for 4.7:
>
> 9e5ed6d1fb87 ACPI,PCI,IRQ: remove SCI penalize function
> 1fcb6a813c4f ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()
> 5c5087a55390 ACPI,PCI,IRQ: reduce static IRQ array size to 16
> 103544d86976 ACPI,PCI,IRQ: reduce resource requirements
>
> I don't think we intended to change any behavior with those patches,
> but maybe we did. Could you confirm/deny that those patches are
> related? If they're not, bisection might be the quickest way to
> find the problem.
>
I agree. The intention was not to change the existing behavior.
I am trying to decode what this means.
[0.305642] ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11)
[0.306365] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11
[0.307078] ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11)
[0.307791] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11)
It looks like the syntax is ((possible irqs) *active irq)
It looks like both 5 and 7 are possible for LNKB and 11 is the active IRQ.
Since 5 and 7 are listed as possible, I don't understand what makes 7
not a good IRQ.
Anyhow, I did some code inspection. I am seeing some problems around the
acpi_irq_get_penalty function. The acpi_irq_get_penalty function
is both a get and set function for PCI IRQs. However, it looks like
we are accounting the penalty twice when using ISA IRQs.
Can you try the following and see if it makes any difference?
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -500,7 +500,7 @@ static int acpi_irq_get_penalty(int irq)
int penalty = 0;
if (irq < ACPI_MAX_ISA_IRQS)
- penalty += acpi_isa_irq_penalty[irq];
+ return acpi_isa_irq_penalty[irq];
/*
* Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
@@ -586,6 +586,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link
*link)
acpi_device_bid(link->device));
return -ENODEV;
} else {
+ if (irq < ACPI_MAX_ISA_IRQS)
+ acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
+ PIRQ_PENALTY_PCI_USING;
+
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
Re: kernel-4.7 bug in Intel sound and/or ACPI
[+cc Sinan] On Mon, Jun 20, 2016 at 03:02:57AM +0200, Rafael J. Wysocki wrote: > You should CC the linux-pci too (done now) > > On Monday, June 20, 2016 02:35:30 AM Wim Osterholt wrote: > > L.S. > > up to vanilla kernel-4.6.2 sound was working fine. > > Switching to kernel-4.7.0-rc3 made sound disappear. No /dev/mixer etc. > > There appears to be a bug in the Intel sound driver and/or ACPI driver. > > Dmesg shows interesting lines like: > > [ 11.498592] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7 > > [ 11.498605] PCI: setting IRQ 7 as level-triggered > > [ 11.543903] parport0: PC-style at 0x378 (0x778), irq 7 > > [PCSPP,TRISTATE,EPP] > > [ 12.757735] genirq: Flags mismatch irq 7. 0080 (snd_intel8x0m) vs. > > (parport0) > > [ 12.757751] snd_intel8x0m :00:1f.6: unable to grab IRQ 7 > > [ 12.757875] snd_intel8x0m: probe of :00:1f.6 failed with error -16 > > [ 12.900171] genirq: Flags mismatch irq 7. 0080 (snd_intel8x0) vs. > > (parport0) > > [ 12.900189] snd_intel8x0 :00:1f.5: unable to grab IRQ 7 > > [ 12.900389] snd_intel8x0: probe of :00:1f.5 failed with error -16 > > [ 12.922554] genirq: Flags mismatch irq 7. 0080 (ipw2200) vs. > > (parport0) > > [ 12.922559] ipw2200: Error allocating IRQ 7 > > > > If I boot kernel-4.7.0-rc3 with acpi=off then sound is back! > > > > If you need the full dmesg outputs then please get them here: > > http://webserver.djo.tudelft.nl/dmesg460+ACPI > > http://webserver.djo.tudelft.nl/dmesg473+ACPI > > http://webserver.djo.tudelft.nl/dmesg473noACPI > > (with excuses for the silly hostname which is out of our control) I think snd_intel8x0 (00:1f.5) is connected to LNKB, and in v4.6 LNKB was set to IRQ 5, while in v4.7 LNKB is connected to IRQ7. It looks like IRQ7 is already in use by parport, which doesn't want to share it. This might be related to Sinan's changes to pci_link.c, which were merged for 4.7: 9e5ed6d1fb87 ACPI,PCI,IRQ: remove SCI penalize function 1fcb6a813c4f ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init() 5c5087a55390 ACPI,PCI,IRQ: reduce static IRQ array size to 16 103544d86976 ACPI,PCI,IRQ: reduce resource requirements I don't think we intended to change any behavior with those patches, but maybe we did. Could you confirm/deny that those patches are related? If they're not, bisection might be the quickest way to find the problem. Bjorn
Re: kernel-4.7 bug in Intel sound and/or ACPI
You should CC the linux-pci too (done now) On Monday, June 20, 2016 02:35:30 AM Wim Osterholt wrote: > L.S. > up to vanilla kernel-4.6.2 sound was working fine. > Switching to kernel-4.7.0-rc3 made sound disappear. No /dev/mixer etc. > There appears to be a bug in the Intel sound driver and/or ACPI driver. > Dmesg shows interesting lines like: > [ 11.498592] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7 > [ 11.498605] PCI: setting IRQ 7 as level-triggered > [ 11.543903] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] > [ 12.757735] genirq: Flags mismatch irq 7. 0080 (snd_intel8x0m) vs. > (parport0) > [ 12.757751] snd_intel8x0m :00:1f.6: unable to grab IRQ 7 > [ 12.757875] snd_intel8x0m: probe of :00:1f.6 failed with error -16 > [ 12.900171] genirq: Flags mismatch irq 7. 0080 (snd_intel8x0) vs. > (parport0) > [ 12.900189] snd_intel8x0 :00:1f.5: unable to grab IRQ 7 > [ 12.900389] snd_intel8x0: probe of :00:1f.5 failed with error -16 > [ 12.922554] genirq: Flags mismatch irq 7. 0080 (ipw2200) vs. > (parport0) > [ 12.922559] ipw2200: Error allocating IRQ 7 > > If I boot kernel-4.7.0-rc3 with acpi=off then sound is back! > > If you need the full dmesg outputs then please get them here: > http://webserver.djo.tudelft.nl/dmesg460+ACPI > http://webserver.djo.tudelft.nl/dmesg473+ACPI > http://webserver.djo.tudelft.nl/dmesg473noACPI > (with excuses for the silly hostname which is out of our control) > > Regards, Wim. > > > - w...@djo.tudelft.nl -
kernel-4.7 bug in Intel sound and/or ACPI
L.S. up to vanilla kernel-4.6.2 sound was working fine. Switching to kernel-4.7.0-rc3 made sound disappear. No /dev/mixer etc. There appears to be a bug in the Intel sound driver and/or ACPI driver. Dmesg shows interesting lines like: [ 11.498592] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7 [ 11.498605] PCI: setting IRQ 7 as level-triggered [ 11.543903] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] [ 12.757735] genirq: Flags mismatch irq 7. 0080 (snd_intel8x0m) vs. (parport0) [ 12.757751] snd_intel8x0m :00:1f.6: unable to grab IRQ 7 [ 12.757875] snd_intel8x0m: probe of :00:1f.6 failed with error -16 [ 12.900171] genirq: Flags mismatch irq 7. 0080 (snd_intel8x0) vs. (parport0) [ 12.900189] snd_intel8x0 :00:1f.5: unable to grab IRQ 7 [ 12.900389] snd_intel8x0: probe of :00:1f.5 failed with error -16 [ 12.922554] genirq: Flags mismatch irq 7. 0080 (ipw2200) vs. (parport0) [ 12.922559] ipw2200: Error allocating IRQ 7 If I boot kernel-4.7.0-rc3 with acpi=off then sound is back! If you need the full dmesg outputs then please get them here: http://webserver.djo.tudelft.nl/dmesg460+ACPI http://webserver.djo.tudelft.nl/dmesg473+ACPI http://webserver.djo.tudelft.nl/dmesg473noACPI (with excuses for the silly hostname which is out of our control) Regards, Wim. - w...@djo.tudelft.nl -
