lkml.org 
[lkml]   [2008]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ACPI: Do not modify SCI_EN directly
From
Date
On Tue, 2008-12-30 at 22:59 +0100, Rafael J. Wysocki wrote:
> On Monday 29 December 2008, Maxim Levitsky wrote:
> > On Mon, 2008-12-29 at 19:19 +0100, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rjw@sisk.pl>
> > >
> > > According to the ACPI specification the SCI_EN flag is controlled by
> > > the hardware, which sets this flag to inform the kernel that ACPI is
> > > enabled. For this reason, we shouldn't try to modify SCI_EN
> > > directly. Also, we don't need to do it in irqrouter_resume(), since
> > > lower-level resume code takes care of enabling ACPI in case it hasn't
> > > been enabled by the BIOS before passing control to the kernel (which
> > > by the way is against the ACPI specification).
> >
> >
> > Hi,
>
> Hi,
>
> > I am an unfortunate owner of an acer notebook ( aspire 5720 if this
> > matters) and it doesn't come back after second suspend, subsequently I
> > figured out that bios doesn't pass control to linux at all, after second
> > resume, and moreover, a suspend to disk , 'fixes' this and enables me to
> > do another suspend/resume cycle. This is a poor man workaround I use
> > now.
>
> I suspect there may be a problem with interrupts handling on your system.
>
> There is http://bugzilla.kernel.org/show_bug.cgi?id=11698 describing a very
> similar (if not the same) issue. Please attach a boot log and the contents
> of /proc/interrupts to that bug.
>
> > I already told about this here, and many peoples from here (including
> > you) tried to help me, but unfortunately this is very weird issue, and
> > nether me nor you can do much about, it is all about guesswork,
> > something, at least something is 'armed' on resume, so it confuses bios
> > then (it could be that yet, the critical part that confuses bios happens
> > in second suspend time)
> >
> > Needless to say that nothing useful appears in the logs, and everything
> > seems to work fine following each successful resume (both disk and ram).
> >
> > so I have a question, do you have a git branch to pull that includes all
> > patches like this to test, so I build it weekly, and who knows, maybe
> > something like above will fix it.
>
> Unfortunately, I don't. If I have any patches that can possibly fix the
> problem, I'll let you know.
>
> > Anyway I would gladly test any patch that you suspect might be involved
> > here.
> >
> > Also, I tried to do a I/O port and PCI config dump before and after a
> > resume, aka in 'armed' and 'unarmed' state.
> >
> > While there were many I/O port registers changes, and I yet to process
> > it bit after bit (and unfortunately there are plenty of undocumented
> > stuff), I noticed a meaningful change between bad and good state:
>
> Please check if the appended patch from Len changes anything.
>
> Thanks,
> Rafael
>
> ---
> Author: Len Brown <len.brown@intel.com>
> Date: Sat Dec 20 12:50:23 2008 +0100
>
> ACPI: PCI Interrupt Links -- disable when unused
>
> We start the system off with disabled links.
> Here we enable the reference counting
> on the links so that when drivers free IRQs
> the links can return to the disabled state.
>
> Drivers free their IRQ and reference on a link
> when they unload. They may also do so upon
> suspend. However, if they don't, irqrouter_resume()
> will still resume any links that were
> not disabled before suspend.
>
> Signed-off-by: Len Brown <len.brown@intel.com>
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 595b131..0f7722d 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -693,18 +693,7 @@ int acpi_pci_link_free_irq(acpi_handle handle)
> printk(KERN_ERR PREFIX "Link isn't initialized\n");
> return -1;
> }
> -#ifdef FUTURE_USE
> - /*
> - * The Link reference count allows us to _DISable an unused link
> - * and suspend time, and set it again on resume.
> - * However, 2.6.12 still has irq_router.resume
> - * which blindly restores the link state.
> - * So we disable the reference count method
> - * to prevent duplicate acpi_pci_link_set()
> - * which would harm some systems
> - */
> link->refcnt--;
> -#endif
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> "Link %s is dereferenced %d\n",
> acpi_device_bid(link->device), link->refcnt));
>

As usual, same hang after resume.
Just to note, this isn't a regression, it even appears in 2.6.19.


Best regards,
Maxim Levitsky



\
 
 \ /
  Last update: 2008-12-30 23:35    [W:0.087 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site