Skip to contentSkip to conversation

Resume from hibernation fails with pata_it821x RAID volume

PATCH RESEND In review Ondrej Zary 3 participants 4 messages Feb 6, 2009 – Feb 7, 2009 libata

lore
Share & tools
lore
#0 lore raw

PATCH RESEND 1/1 Resume from hibernation fails with pata_it821x RAID volume

Hello,
hibernation didn't work for me since I started to use IT8212 controller. Now I did some debugging (booting with no_console_suspend init=/bin/sh).

Found that resume fails (2.6.28) with "serial number mismatch 'some garbage' != 'some other garbage'" and "revalidation failed" messages. That's because the controller firmware fills different serial number in the IDENTIFY every boot.

The patch below fixes the resume simply clearing the serial number. The proper fix would be probably to fill in the serial number of the RAID volume instead. I assume that there must be something like that stored on the drives but I don't know where.

Fix resume on pata_it821x RAID volume by clearing the serial number in IDENTIFY data, which is otherwise different on each boot.

--- linux-2.6.28-orig/drivers/ata/pata_it821x.c 2009-01-02 17:18:36.000000000
+0100
+++ linux/drivers/ata/pata_it821x.c 2009-02-02 17:47:57.000000000 +0100
@@ -561,6 +561,9 @@
id[83] |= 0x4400; /* Word 83 is valid and LBA48 */
id[86] |= 0x0400; /* LBA48 on */
id[ATA_ID_MAJOR_VER] |= 0x1F;
+ /* Clear the serial number because it's different each boot
+ which breaks validation on resume */
+ memset(&id[ATA_ID_SERNO], 0x20, ATA_ID_SERNO_LEN);
}
return err_mask;
}

Signature · 1 line
Ondrej Zary
#1 lore raw
Quoted 5 lines · Ondrej Zary

hibernation didn't work for me since I started to use IT8212 controller. Now I did some debugging (booting with no_console_suspend init=/bin/sh).

Found that resume fails (2.6.28) with "serial number mismatch 'some garbage' != 'some other garbage'" and "revalidation failed" messages. That's because the controller firmware fills different serial number in the IDENTIFY every boot.

The patch below fixes the resume simply clearing the serial number. The proper fix would be probably to fill in the serial number of the RAID volume instead.

I wonder why they just don't put it there (if they indeed have such
number). If I don't mistake, this is a RAID disk?

Quoted 10 lines

I assume that there must be something like that stored on the drives but I don't know where.

Fix resume on pata_it821x RAID volume by clearing the serial number in IDENTIFY data, which is otherwise different on each boot.

--- linux-2.6.28-orig/drivers/ata/pata_it821x.c 2009-01-02 17:18:36.000000000
+0100
+++ linux/drivers/ata/pata_it821x.c 2009-02-02 17:47:57.000000000 +0100

Review line 565

Quoted 5 lines
(quoted diff) +2 -0
@@ -561,6 +561,9 @@
 		id[83] |= 0x4400;	/* Word 83 is valid and LBA48 */
 		id[86] |= 0x0400;	/* LBA48 on */
 		id[ATA_ID_MAJOR_VER] |= 0x1F;
+		/* Clear the serial number because it's different each boot
+		   which breaks validation on resume */

See CodingStyle chapter 8 for the preferred multiline comment style.

Review line 566

Quoted 1 line
(quoted diff) +1 -0
+		memset(&id[ATA_ID_SERNO], 0x20, ATA_ID_SERNO_LEN);

Why not ' '?

MBR, Sergei

#2 lore raw
Quoted 7 lines

See CodingStyle chapter 8 for the preferred multiline comment style.

Review

Quoted 1 line
(quoted diff) +1 -0
+		memset(&id[ATA_ID_SERNO], 0x20, ATA_ID_SERNO_LEN);

Why not ' '?

MBR, Sergei

Digging into the docs the RAID serial number (and what that means isn't defined anywhere I can see) is byte offset 54-73 in each of the 4 128 byte blocks returned by the chip status query we do at boot (it821x_probe_firmware).

Alan

#3 lore raw
Quoted 6 lines · On Friday 06 February 2009 18:56:35 Alan Cox wrote:
Quoted 6 lines

See CodingStyle chapter 8 for the preferred multiline comment style.

Review

Quoted 1 line
(quoted diff) +1 -0
+		memset(&id[ATA_ID_SERNO], 0x20, ATA_ID_SERNO_LEN);

Why not ' '?

Quoted 6 lines
Quoted 1 line

MBR, Sergei

Digging into the docs the RAID serial number (and what that means isn't defined anywhere I can see) is byte offset 54-73 in each of the 4 128 byte blocks returned by the chip status query we do at boot (it821x_probe_firmware).

Yes, found it there. But it seems to be the same number as present in the IDENTIFY data. It contains date and time of boot (matches RAID_SERIAL_NUMBER structure found in iteraid.h in driver source from ITE) instead of date and time of RAID creation.

Signature · 1 line
Ondrej Zary