[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52DDE49C.6080205@gmail.com>
Date: Mon, 20 Jan 2014 21:08:12 -0600
From: Robert Hancock <hancockrwd@...il.com>
To: John Twideldum <twideldums_throwaway@....at>,
Jan Kara <jack@...e.cz>
CC: linux-kernel@...r.kernel.org, ide <linux-ide@...r.kernel.org>
Subject: Re: 3.12-rc5 and overwritten partition table - by powertop?
On 10/29/2013 04:32 PM, John Twideldum wrote:
>>>>> The first ~170kb of /dev/sda got blown away with what seems to be a logging output
>>>>> by Powertop, when I was playing with the tuneables.
>>>>
>>>> So did you log the output to some file? I'm just trying to understand how
>>>> it could get onto your disk in the first place...
>>>
>>> Attached a dump of the first 1Mb of the disk, HTH.
>>> It looks like a powertop log?
>>> (I have powertop 2.4)
>>
>> Yes, likely. But it is strange the corruption doesn't even end at any
>> sensible boundary (data ends at offset 0x27b53). Shrug...
>
> My recollection what I did is this:
>
> I was looking into powertop and observing how -rc5 works now with Haswell.
> I saw the tuneable parameters and quite a few were "bad", so I set them to "good".
> Power usage dropped about one third - yay!
> However, changing "SATA link power" threw up complaints:
>
> Oct 29 09:09:21 localhost kernel: [ 3697.423868] ata1.00: exception Emask 0x10 SAct 0x1 SErr 0xc0000 action 0x6 frozen
> Oct 29 09:09:21 localhost kernel: [ 3697.423873] ata1.00: irq_stat 0x08000000, interface fatal error
> Oct 29 09:09:21 localhost kernel: [ 3697.423877] ata1: SError: { CommWake 10B8B }
> Oct 29 09:09:21 localhost kernel: [ 3697.423880] ata1.00: failed command: WRITE FPDMA QUEUED
> Oct 29 09:09:21 localhost kernel: [ 3697.423886] ata1.00: cmd 61/38:00:01:9e:a4/01:00:00:00:00/40 tag 0 ncq 159744 out
> Oct 29 09:09:21 localhost kernel: [ 3697.423886] res 50/01:00:01:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error)
> Oct 29 09:09:21 localhost kernel: [ 3697.423888] ata1.00: status: { DRDY }
> Oct 29 09:09:21 localhost kernel: [ 3697.423894] ata1: hard resetting link
> Oct 29 09:09:22 localhost kernel: [ 3697.743196] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> Oct 29 09:09:22 localhost kernel: [ 3697.744707] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
> Oct 29 09:09:22 localhost kernel: [ 3697.744719] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
> Oct 29 09:09:22 localhost kernel: [ 3697.744725] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
> Oct 29 09:09:22 localhost kernel: [ 3697.744813] ata1.00: ACPI cmd ef/10:09:00:00:00:a0 (SET FEATURES) succeeded
> Oct 29 09:09:22 localhost kernel: [ 3697.745212] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
> Oct 29 09:09:22 localhost kernel: [ 3697.746694] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
> Oct 29 09:09:22 localhost kernel: [ 3697.746705] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
> Oct 29 09:09:22 localhost kernel: [ 3697.746711] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
> Oct 29 09:09:22 localhost kernel: [ 3697.746779] ata1.00: ACPI cmd ef/10:09:00:00:00:a0 (SET FEATURES) succeeded
> Oct 29 09:09:22 localhost kernel: [ 3697.747286] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
> Oct 29 09:09:22 localhost kernel: [ 3697.747432] ata1.00: configured for UDMA/133
> Oct 29 09:09:22 localhost kernel: [ 3697.763181] ata1: EH complete
>
> I did not know yet about what "frozen" means, so I did not investigate and
> very soon powered down as I had to leave.
> Next time I boot up.... I did not boot.
> So data probable is just the size because as long as I had powertop running...
(CCing linux-ide)
It seems like most likely either the SATA host controller or drive
doesn't play nice with link power management enabled. Can you post the
full dmesg boot log?
--
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