lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 12 Mar 2010 22:01:03 +0100
From:	Marcus Lell <marcus.lell@...glemail.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Clear abnormal poweroff flag on VIA southbridges, fix 
	resume

oh, googlemail fucked the lat one up...
I hope this patch looks better.
when not let us blame google... :-)

On Fri, Mar 12, 2010 at 7:41 PM, Marcus Lell <marcus.lell@...glemail.com> wrote:
> hi all,
>
> [please cc me, as I am not subscribed to lkml]
>
> maybe this patch got lost...
>
>>Mon, 19 Jun 2006 23:01:48 -0700
>>Andrew Morton wrote:
>>
>>>On Sun, 18 Jun 2006 20:14:22 +0100
>>>Matthew Garrett <[EMAIL PROTECTED]> wrote:
>>>
>>> Some VIA southbridges contain a flag in the ACPI register space that
>>> indicates whether an abnormal poweroff has occured, presumably with the
>>> intention that it can be cleared on clean shutdown. Some BIOSes check
>>> this flag at resume time, and will re-POST the system rather than jump
>>> back to the OS if it's set. Clearing it at boot time appears to be
>>> sufficient. I'm not sure if drivers/pci/quirks.c is the right place to
>>> do it, but I'm not sure where would be cleaner.
>>>
>>> Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]>
>>>
>>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>>> index 7537260..2f9f996 100644
>>> --- a/drivers/pci/quirks.c
>>> +++ b/drivers/pci/quirks.c
>>> @@ -660,6 +660,33 @@ static void __devinit quirk_vt82c598_id(
>>>  }
>>>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C597_0,
>>> quirk_vt82c598_id );
>>>
>>> +#ifdef CONFIG_ACPI
>>> +
>>> +/* Some VIA systems boot with the abnormal status flag set. This can
> cause
>>> + * the BIOS to re-POST the system on resume rather than passing control
>>> + * back to the OS. Clear the flag on boot
>>> + */
>>> +
>>> +static void __devinit quirk_via_abnormal_poweroff(struct pci_dev *dev)
>>> +{
>>> +     u32 reg;
>>> +
>>> +     acpi_hw_register_read (ACPI_MTX_DO_NOT_LOCK,
> ACPI_REGISTER_PM1_STATUS,
>>> +                                         &reg);
>>> +
>>> +      if (reg & 0x800) {
>>> +             printk ("Clearing abnormal poweroff flag\n");
>>> +                         acpi_hw_register_write (ACPI_MTX_DO_NOT_LOCK,
>>> +                         ACPI_REGISTER_PM1_STATUS,
>>> +                          (u16)0x800);
>>> +     }
>>> +}
>>> +
>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_VIA, PCI_DEVICE_ID_VIA_8235,
>>> quirk_via_abnormal_poweroff);
>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_VIA, PCI_DEVICE_ID_VIA_8237,
>>> quirk_via_abnormal_poweroff);
>>> +
>>> +#endif
>>
>>Is CONFIG_ACPI the right thing to use here?  As opposed to, say,
>>CONFIG_PM?
>>Or CONFIG_ACPI_SLEEP??
>
> I am still (@2010) not able to boot for a suspended (STR) system. my
> pc reboots normally
> instead of resuming. maybe this patch fixes this.
> (I did a 's/register/reg/' in the orginal patch for obvious reasons...)
>
> unfortunately I am not able to port it to 2.6.33, I don't know the kernel api...
>
> I tried to test it, but it doesn't compile on 2.6.24.7 or 2.6.25.20,
> but was posted in 2.6.25 time line for sure. (iirc it was based on the
> 2.6.25-mm2 patch)
>
> as I don't know, what I can do about it, I am posting it here.
> I hope, that someone comes in with advises, or better, patches, that
> apply to 2.6.33 or 2.6.34-rc1. :-)
>
> of course, I will be very glad to test patches, or will try to port
> this patch, thus it is be more unlikely, that I am able to.
>
>
> marcus lell
>
> --
> return to the point of no return._
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ