linux-kernel - Re: bisected regression: v3.6-rc1: resume from s2ram does not restore ata

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]

Message-ID: <20120814202650.01b056ce@sf>
Date:	Tue, 14 Aug 2012 20:26:50 +0300
From:	Sergei Trofimovich <slyich@...il.com>
To:	Aaron Lu <aaron.lwe@...il.com>
Cc:	Aaron Lu <ziqian.lu@...el.com>, Matthew Garrett <mjg@...hat.com>,
	Holger Macht <holger@...ac.de>, Lin Ming <minggr@...il.com>,
	Jeff Garzik <jgarzik@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: bisected regression: v3.6-rc1: resume from s2ram does not
 restore ata_piix (v3.5 worked)

On Tue, 14 Aug 2012 22:48:08 +0800
Aaron Lu <aaron.lwe@...il.com> wrote:

> On Tue, Aug 14, 2012 at 11:44:20AM +0300, Sergei Trofimovich wrote:
> > > The only problem I can see is the offending commit didn't do a gtm for
> > > IDE channel during init. It was used to be done in
> > > ata_acpi_associate_ide_port.
> > > 
> > > So can you please test if the following code fix your problem? Thanks.
> > 
> > Unfortunately, nothing changed. The same hangup after resume.
> > Did the bisected patch change the way kernel relies on ACPI
> > information? I have some complains in dmesg output about it
> > (attached whole dmesg) like that:
> > 
> > ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0x0000000000000004) is beyond end of object (20120711/exoparg2-418)
> > ACPI Error: Method parse/execution failed [\_SB_.C003.C09A._DOD] (Node ffff88007b82c988), AE_AML_PACKAGE_LIMIT (20120711/psparse-536)
> > ACPI Exception: AE_AML_PACKAGE_LIMIT, Evaluating _DOD (20120711/video-1149)
> 
> 
> And here is another try:

This one did the trick! Survived suspend/resume cycle.
Whole dmesg is attached.

> > ata1: ACPI get timing mode failed (AE 0x1001)
> Do you see this error message when using a working kernel?

Now with patched kernel I see

    ata1: ACPI set timing mode failed (status=0x300b)

after resume. No 'get timing' errors. Attached dmesg
with suspend/resume log.

I can boot to older unpatched kernels right before and after
offending commit and send you dmesg diff if you still need/like
to look at it.

Thanks for the fix!

> 
> diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
> index 902b5a4..fd9ecf7 100644
> --- a/drivers/ata/libata-acpi.c
> +++ b/drivers/ata/libata-acpi.c
> @@ -60,17 +60,7 @@ acpi_handle ata_ap_acpi_handle(struct ata_port *ap)
>  	if (ap->flags & ATA_FLAG_ACPI_SATA)
>  		return NULL;
>  
> -	/*
> -	 * If acpi bind operation has already happened, we can get the handle
> -	 * for the port by checking the corresponding scsi_host device's
> -	 * firmware node, otherwise we will need to find out the handle from
> -	 * its parent's acpi node.
> -	 */
> -	if (ap->scsi_host)
> -		return DEVICE_ACPI_HANDLE(&ap->scsi_host->shost_gendev);
> -	else
> -		return acpi_get_child(DEVICE_ACPI_HANDLE(ap->host->dev),
> -				ap->port_no);
> +	return acpi_get_child(DEVICE_ACPI_HANDLE(ap->host->dev), ap->port_no);
>  }
>  EXPORT_SYMBOL(ata_ap_acpi_handle);
>  
> @@ -1101,6 +1091,9 @@ static int ata_acpi_bind_host(struct ata_port *ap, acpi_handle *handle)
>  	if (!*handle)
>  		return -ENODEV;
>  
> +	if (ata_acpi_gtm(ap, &ap->__acpi_init_gtm) == 0)
> +		ap->pflags |= ATA_PFLAG_INIT_GTM_VALID;
> +
>  	return 0;
>  }
> 
> Thanks,
> Aaron


-- 

  Sergei

View attachment "dmesg.txt" of type "text/plain" (46693 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)