Bug 61721

Please provide the output of dmidecode. Could you try old kernel and check whether this is a regression?

Just installed the oldest F18 kernel I can find, 3.6.something, and it happens with that too. Which isn't how I remembered it, but...that's how it appears to be. Will attach dmidecode from 3.10 in a minute.

The system's disk activity light seems to be on a lot while it's in the 'stuck' state, but I'm not sure what that could be (and I can't tell if the 'disk' is actually doing something by the time-honoured 'hold your ear to the case' technique, as it's an SSD).

Created attachment 109341 [details]
dmidecode from 3.10.12

Created attachment 109351 [details]
debug.patch

Please try this patch. Thanks.

Will do, but note that VPCZ112GD is an *extremely* specific model number. There are many 'variants' of the VPCZ11 line which are pretty much identical - just different loadouts of RAM and CPU spec sold in different markets, I think, and I'd be very surprised if they didn't suffer the same issue. The Z12 and Z13 models were minor spec bumps over the Z11, sold in the same chassis, and may well have it too.

There is actually a Linux-on-Vaio Z mailing list which is still somewhat active, and there's a thread there which rather looks like this issue (I rather suspect they were too impatient to discover it actually *does* reboot if you wait long enough):

https://lists.launchpad.net/sony-vaio-z-series/msg02964.html

The OP there has a different Z11 sub-model, and another poster mentions a Z13 which 'hangs' on reboot:

https://lists.launchpad.net/sony-vaio-z-series/msg02968.html

This older thread has several similar reports from Z11 and Z13 owners:

https://lists.launchpad.net/sony-vaio-z-series/msg02868.html

so you may want to go with a more general match than my specific submodel of the Z11 :)

VPCZ14 and Z15 seem to exist but by the Google results may be Japan-only, I don't know anything about them.

also - I'm not familiar with the code in question and the name reboot.c may be misleading, I suppose, but note this bug affects poweroff too: would a similar patch be needed to a 'poweroff.c' file or something? :)

Passing on a report from list member Brett Howard:

"Thanks much for the work kind sir.  I've not got a Bugzilla account so I can't post this to the bug but I will state that my VPCZ12CGX also has this issue and it is resolved by passing the kernel parameter.  

Here is my output from dmidecode:

...
System Information
	Manufacturer: Sony Corporation
	Product Name: VPCZ12CGX
	Version: J004A1P1
	Serial Number: 54024526-0001410
	UUID: B04FA3FA-E388-DF11-9C53-0024BED6DF9D
	Wake-up Type: Power Switch
	SKU Number: N/A
	Family: VAIO
...
"

I can attach the full dmidecode output he sent me if it's needed for anything.

Another report:

"Thank you! My VPC-Z11C5E now reboots normally."

And one more:

"The parameter fixed the reboot hang/looonnng-reboot. The shutdown worked well. The details on my model:"

...
System Information
        Manufacturer: Sony Corporation
        Product Name: VPCZ13M9E
        Version: J004CYHD
        Serial Number: XXXX
        UUID: XXXX
        Wake-up Type: Power Switch
        SKU Number: N/A
        Family: VAIO
...

I don't know what pattern matching style is used for these things, but I think what we want is roughly:

DMI_MATCH(DMI_PRODUCT_NAME, "VPCZ1[1-5]???"),

I think that should be safe and match most/all affected systems (I'm not 100% sure of whether the VPCZ16 and VPCZ17 actually exist or not; there's some results indicating they exist in Australia/New Zealand, but nothing definitive).

The code uses strstr(...) to match machine. Please see dmi_matches() in the drivers/firmware/dmi_scan.c.

We can use 'DMI_MATCH(DMI_PRODUCT_NAME, "VPCZ1")' to match all these machine.

Created attachment 110441 [details]
de

Please try the patch. Thanks.

Just 'VPCZ1' may match some older models that don't need the patch. I'll have to look it up. I will test the patch when I can - sorry I didn't yet, I've been crazy busy lately :(

(In reply to Adam Williamson from comment #14)
> Just 'VPCZ1' may match some older models that don't need the patch. I'll
> have to look it up. I will test the patch when I can - sorry I didn't yet,

I think one entry for one machine is comparative secure. Could gou collect these machines dmidecode? Thanks.

> I've been crazy busy lately :(

ping ...

Sorry for the delay, I am building a test kernel for this fix right now.

I've also been looking at model numbers. It looks like, after all, just 'VPCZ1' should be OK. Looking at https://en.wikipedia.org/wiki/Sony_Vaio_Z_series and other sources, I think all other series of 'Z' have different model names:

late 2011 'VPCZ2.....'
2012 'SVZ1....'
2008-9 'VGNZ....'

So I believe 'VPCZ1' should be a unique identifier for the 2010 series, and the feedback I gathered seems to indicate pretty strongly that all VPCZ1 models are affected by the bug.

Will update shortly with test results.

Patch doesn't seem to work :/ after dropping 'reboot=pci' from cmdline, I get a slow reboot.

Huh - my second reboot with the new kernel was fast...odd.

Next four reboots have all been good too, so I probably just hit something else on my first try. Fix looks good.

Ok. Thanks for test.
The fix patch has been sent to x86 and ACPI maillist. So mark this bug as code fix.
https://patchwork.kernel.org/patch/3090271/

Reopen this bug since the patch is not acceptable.

Hi Adam:
        Could you provide the output of acpidump?

Hi Adam:
        I found another power off issue on the Acer Aspire V5-573G and the issue cause it that the SATA host controller's pci master bit is cleared during shutdown. Could you please try the patch in the bug 63861's Comment 11 to check whether this bug is the same bug?
        https://bugzilla.kernel.org/show_bug.cgi?id=63861

thanks lan - i'll throw it on the list of Things I Really Ought To Be Doing But Which Aren't Fedora 20 Validation So I Never Get Around To Doing Them :)

Ok. I get it. So mark this bug as WILL_FIX_LATER and feel free to reopen it when you have time.