[Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure

[Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure

[Nicholas Thomas]

Hi all,

Migrating from:

/opt/qemu-1.4.1/bin/qemu-system-x86_64 -M pc -watchdog i6300esb
-watchdog-action reset [...] 

to:

/opt/qemu-1.5.0/bin/qemu-system-x86_64 -M pc-i440fx-1.4 -watchdog
i6300esb -watchdog-action reset [...] 

I get: 

qemu: warning: error while loading state for instance 0x0 of device
'0000:00:06.0/i6300esb_wdt'
load of migration failed

Perhaps a similar issue to the network device one? I'm afraid I'm not
sure how to debug these...

/Nick

Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure

[Andreas Färber]

Hi,

Am 21.05.2013 13:33, schrieb Nicholas Thomas:
> Migrating from:
> 
> /opt/qemu-1.4.1/bin/qemu-system-x86_64 -M pc -watchdog i6300esb
> -watchdog-action reset [...] 
> 
> to:
> 
> /opt/qemu-1.5.0/bin/qemu-system-x86_64 -M pc-i440fx-1.4 -watchdog
> i6300esb -watchdog-action reset [...] 
> 
> I get: 
> 
> qemu: warning: error while loading state for instance 0x0 of device
> '0000:00:06.0/i6300esb_wdt'
> load of migration failed
> 
> Perhaps a similar issue to the network device one?

Negative, the watchdog has not undergone anything like the virtio
refactorings. Are you using any virtio devices so that device numbering
might somehow be different?

Andreas

> I'm afraid I'm not
> sure how to debug these...
> 
> /Nick

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure

[Nicholas Thomas]

On Tue, 2013-05-21 at 13:55 +0200, Andreas Färber wrote:
> Hi,
> 
> Am 21.05.2013 13:33, schrieb Nicholas Thomas:
> > Migrating from:
> > 
> > /opt/qemu-1.4.1/bin/qemu-system-x86_64 -M pc -watchdog i6300esb
> > -watchdog-action reset [...] 
> > 
> > to:
> > 
> > /opt/qemu-1.5.0/bin/qemu-system-x86_64 -M pc-i440fx-1.4 -watchdog
> > i6300esb -watchdog-action reset [...] 
> > 
> > I get: 
> > 
> > qemu: warning: error while loading state for instance 0x0 of device
> > '0000:00:06.0/i6300esb_wdt'
> > load of migration failed
> > 
> > Perhaps a similar issue to the network device one?
> 
> Negative, the watchdog has not undergone anything like the virtio
> refactorings. Are you using any virtio devices so that device numbering
> might somehow be different?

Virtio networking, discs, and the balloon device too. The full command
line looks like this:

/opt/qemu-1.4.1/bin/qemu-system-x86_64 -enable-kvm -S -name test -M pc
-watchdog i6300esb -watchdog-action reset -smp 1 -m 1024M
-L /opt/qemu-1.4.1/share/qemu -balloon virtio -vga cirrus -vnc
127.0.0.1:0, -drive
file=nbd:unix:/tmp/vm.test/disc-vda.sock,serial=vda,format=raw,if=virtio
-monitor unix:/tmp/vm.test/monitor,server -serial
unix:/tmp/vm.test/serial,server,nowait -boot order=ndc -usb -usbdevice
tablet -net user,vlan=50,name=user,restrict=y -k en-gb -net
nic,model=virtio,macaddr=fe:ff:fe:00:01:64,name=t35600,vlan=896 -net
tap,script=no,downscript=no,name=t35600,vlan=896,ifname=t35600 -rtc
base=utc,clock=host

lspci in the guest on 1.4.1:

00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Ethernet controller: Qumranet, Inc. Device 1000
00:04.0 Unclassified device [00ff]: Qumranet, Inc. Device 1002
00:05.0 SCSI storage controller: Qumranet, Inc. Device 1001
00:06.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer

lspci on 1.5.0:
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Ethernet controller: Qumranet, Inc. Device 1000
00:04.0 Unclassified device [00ff]: Qumranet, Inc. Device 1002
00:05.0 SCSI storage controller: Qumranet, Inc. Device 1001
00:06.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer

lspci -vvv on 1.4.1:
[...]
00:06.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer
	Subsystem: Qumranet, Inc. Device 1100
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
	Region 0: Memory at febf3000 (32-bit, non-prefetchable) [size=16]

lspci -vvv on 1.5.0:
[...]
00:06.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer
	Subsystem: Qumranet, Inc. Device 1100
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Region 0: Memory at febf3000 (32-bit, non-prefetchable) [size=16]

So they seem to be identical from the guest's point of view?

/Nick

Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure

[mdroth]

On Tue, May 21, 2013 at 12:33:38PM +0100, Nicholas Thomas wrote:
> Hi all,
> 
> Migrating from:
> 
> /opt/qemu-1.4.1/bin/qemu-system-x86_64 -M pc -watchdog i6300esb
> -watchdog-action reset [...] 
> 
> to:
> 
> /opt/qemu-1.5.0/bin/qemu-system-x86_64 -M pc-i440fx-1.4 -watchdog
> i6300esb -watchdog-action reset [...] 
> 
> I get: 
> 
> qemu: warning: error while loading state for instance 0x0 of device
> '0000:00:06.0/i6300esb_wdt'
> load of migration failed
> 
> Perhaps a similar issue to the network device one? I'm afraid I'm not
> sure how to debug these...

Doesn't look like it, here's a dump of the SaveStateEntry's (i just
added some debug statements in vmstate_register_with_alias_id):

verison: 1.4.1, se->idstr: timer, se->instance_id: 0
verison: 1.4.1, se->idstr: cpu_common, se->instance_id: 0
verison: 1.4.1, se->idstr: kvm-tpr-opt, se->instance_id: 0
verison: 1.4.1, se->idstr: apic, se->instance_id: 0
verison: 1.4.1, se->idstr: kvmclock, se->instance_id: 0
verison: 1.4.1, se->idstr: fw_cfg, se->instance_id: 0
verison: 1.4.1, se->idstr: PCIBUS, se->instance_id: 0
verison: 1.4.1, se->idstr: 0000:00:00.0/I440FX, se->instance_id: 0
verison: 1.4.1, se->idstr: 0000:00:01.0/PIIX3, se->instance_id: 0
verison: 1.4.1, se->idstr: i8259, se->instance_id: 0
verison: 1.4.1, se->idstr: i8259, se->instance_id: 1
verison: 1.4.1, se->idstr: ioapic, se->instance_id: 0
verison: 1.4.1, se->idstr: 0000:00:02.0/vga, se->instance_id: 0
verison: 1.4.1, se->idstr: hpet, se->instance_id: 0
verison: 1.4.1, se->idstr: mc146818rtc, se->instance_id: 0
verison: 1.4.1, se->idstr: i8254, se->instance_id: 0
verison: 1.4.1, se->idstr: serial, se->instance_id: 0
verison: 1.4.1, se->idstr: ps2kbd, se->instance_id: 0
verison: 1.4.1, se->idstr: ps2mouse, se->instance_id: 0
verison: 1.4.1, se->idstr: pckbd, se->instance_id: 0
verison: 1.4.1, se->idstr: vmmouse, se->instance_id: 0
verison: 1.4.1, se->idstr: port92, se->instance_id: 0
verison: 1.4.1, se->idstr: dma, se->instance_id: 0
verison: 1.4.1, se->idstr: dma, se->instance_id: 1
verison: 1.4.1, se->idstr: fdc, se->instance_id: 0
verison: 1.4.1, se->idstr: 0000:00:01.1/ide, se->instance_id: 0
verison: 1.4.1, se->idstr: i2c_bus, se->instance_id: 0
verison: 1.4.1, se->idstr: 0000:00:01.3/piix4_pm, se->instance_id: 0
verison: 1.4.1, se->idstr: 0000:00:06.0/i6300esb_wdt, se->instance_id: 0

version: 1.5.0, se->idstr: timer, se->instance_id: 0
version: 1.5.0, se->idstr: cpu_common, se->instance_id: 0
version: 1.5.0, se->idstr: cpu, se->instance_id: 0
version: 1.5.0, se->idstr: kvm-tpr-opt, se->instance_id: 0
version: 1.5.0, se->idstr: apic, se->instance_id: 0
version: 1.5.0, se->idstr: kvmclock, se->instance_id: 0
version: 1.5.0, se->idstr: fw_cfg, se->instance_id: 0
version: 1.5.0, se->idstr: PCIBUS, se->instance_id: 0
version: 1.5.0, se->idstr: 0000:00:00.0/I440FX, se->instance_id: 0
version: 1.5.0, se->idstr: 0000:00:01.0/PIIX3, se->instance_id: 0
version: 1.5.0, se->idstr: i8259, se->instance_id: 0
version: 1.5.0, se->idstr: i8259, se->instance_id: 1
version: 1.5.0, se->idstr: ioapic, se->instance_id: 0
version: 1.5.0, se->idstr: 0000:00:02.0/vga, se->instance_id: 0
version: 1.5.0, se->idstr: hpet, se->instance_id: 0
version: 1.5.0, se->idstr: mc146818rtc, se->instance_id: 0
version: 1.5.0, se->idstr: i8254, se->instance_id: 0
version: 1.5.0, se->idstr: serial, se->instance_id: 0
version: 1.5.0, se->idstr: ps2kbd, se->instance_id: 0
version: 1.5.0, se->idstr: ps2mouse, se->instance_id: 0
version: 1.5.0, se->idstr: pckbd, se->instance_id: 0
version: 1.5.0, se->idstr: vmmouse, se->instance_id: 0
version: 1.5.0, se->idstr: port92, se->instance_id: 0
version: 1.5.0, se->idstr: dma, se->instance_id: 0
version: 1.5.0, se->idstr: dma, se->instance_id: 1
version: 1.5.0, se->idstr: fdc, se->instance_id: 0
version: 1.5.0, se->idstr: 0000:00:01.1/ide, se->instance_id: 0
version: 1.5.0, se->idstr: i2c_bus, se->instance_id: 0
version: 1.5.0, se->idstr: 0000:00:01.3/piix4_pm, se->instance_id: 0
version: 1.5.0, se->idstr: 0000:00:06.0/i6300esb_wdt, se->instance_id: 0

Seems like the actual load is failing, but the VMSD hasn't changed so
i'm not sure what's going on.

> 
> /Nick
> 
> 
> 

Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure

[mdroth]

On Tue, May 21, 2013 at 11:55:56AM -0500, mdroth wrote:
> On Tue, May 21, 2013 at 12:33:38PM +0100, Nicholas Thomas wrote:
> > Hi all,
> > 
> > Migrating from:
> > 
> > /opt/qemu-1.4.1/bin/qemu-system-x86_64 -M pc -watchdog i6300esb
> > -watchdog-action reset [...] 
> > 
> > to:
> > 
> > /opt/qemu-1.5.0/bin/qemu-system-x86_64 -M pc-i440fx-1.4 -watchdog
> > i6300esb -watchdog-action reset [...] 
> > 
> > I get: 
> > 
> > qemu: warning: error while loading state for instance 0x0 of device
> > '0000:00:06.0/i6300esb_wdt'
> > load of migration failed
> > 
> > Perhaps a similar issue to the network device one? I'm afraid I'm not
> > sure how to debug these...
> 
> Doesn't look like it, here's a dump of the SaveStateEntry's (i just
> added some debug statements in vmstate_register_with_alias_id):
> 
> verison: 1.4.1, se->idstr: timer, se->instance_id: 0
> verison: 1.4.1, se->idstr: cpu_common, se->instance_id: 0
> verison: 1.4.1, se->idstr: kvm-tpr-opt, se->instance_id: 0
> verison: 1.4.1, se->idstr: apic, se->instance_id: 0
> verison: 1.4.1, se->idstr: kvmclock, se->instance_id: 0
> verison: 1.4.1, se->idstr: fw_cfg, se->instance_id: 0
> verison: 1.4.1, se->idstr: PCIBUS, se->instance_id: 0
> verison: 1.4.1, se->idstr: 0000:00:00.0/I440FX, se->instance_id: 0
> verison: 1.4.1, se->idstr: 0000:00:01.0/PIIX3, se->instance_id: 0
> verison: 1.4.1, se->idstr: i8259, se->instance_id: 0
> verison: 1.4.1, se->idstr: i8259, se->instance_id: 1
> verison: 1.4.1, se->idstr: ioapic, se->instance_id: 0
> verison: 1.4.1, se->idstr: 0000:00:02.0/vga, se->instance_id: 0
> verison: 1.4.1, se->idstr: hpet, se->instance_id: 0
> verison: 1.4.1, se->idstr: mc146818rtc, se->instance_id: 0
> verison: 1.4.1, se->idstr: i8254, se->instance_id: 0
> verison: 1.4.1, se->idstr: serial, se->instance_id: 0
> verison: 1.4.1, se->idstr: ps2kbd, se->instance_id: 0
> verison: 1.4.1, se->idstr: ps2mouse, se->instance_id: 0
> verison: 1.4.1, se->idstr: pckbd, se->instance_id: 0
> verison: 1.4.1, se->idstr: vmmouse, se->instance_id: 0
> verison: 1.4.1, se->idstr: port92, se->instance_id: 0
> verison: 1.4.1, se->idstr: dma, se->instance_id: 0
> verison: 1.4.1, se->idstr: dma, se->instance_id: 1
> verison: 1.4.1, se->idstr: fdc, se->instance_id: 0
> verison: 1.4.1, se->idstr: 0000:00:01.1/ide, se->instance_id: 0
> verison: 1.4.1, se->idstr: i2c_bus, se->instance_id: 0
> verison: 1.4.1, se->idstr: 0000:00:01.3/piix4_pm, se->instance_id: 0
> verison: 1.4.1, se->idstr: 0000:00:06.0/i6300esb_wdt, se->instance_id: 0
> 
> version: 1.5.0, se->idstr: timer, se->instance_id: 0
> version: 1.5.0, se->idstr: cpu_common, se->instance_id: 0
> version: 1.5.0, se->idstr: cpu, se->instance_id: 0
> version: 1.5.0, se->idstr: kvm-tpr-opt, se->instance_id: 0
> version: 1.5.0, se->idstr: apic, se->instance_id: 0
> version: 1.5.0, se->idstr: kvmclock, se->instance_id: 0
> version: 1.5.0, se->idstr: fw_cfg, se->instance_id: 0
> version: 1.5.0, se->idstr: PCIBUS, se->instance_id: 0
> version: 1.5.0, se->idstr: 0000:00:00.0/I440FX, se->instance_id: 0
> version: 1.5.0, se->idstr: 0000:00:01.0/PIIX3, se->instance_id: 0
> version: 1.5.0, se->idstr: i8259, se->instance_id: 0
> version: 1.5.0, se->idstr: i8259, se->instance_id: 1
> version: 1.5.0, se->idstr: ioapic, se->instance_id: 0
> version: 1.5.0, se->idstr: 0000:00:02.0/vga, se->instance_id: 0
> version: 1.5.0, se->idstr: hpet, se->instance_id: 0
> version: 1.5.0, se->idstr: mc146818rtc, se->instance_id: 0
> version: 1.5.0, se->idstr: i8254, se->instance_id: 0
> version: 1.5.0, se->idstr: serial, se->instance_id: 0
> version: 1.5.0, se->idstr: ps2kbd, se->instance_id: 0
> version: 1.5.0, se->idstr: ps2mouse, se->instance_id: 0
> version: 1.5.0, se->idstr: pckbd, se->instance_id: 0
> version: 1.5.0, se->idstr: vmmouse, se->instance_id: 0
> version: 1.5.0, se->idstr: port92, se->instance_id: 0
> version: 1.5.0, se->idstr: dma, se->instance_id: 0
> version: 1.5.0, se->idstr: dma, se->instance_id: 1
> version: 1.5.0, se->idstr: fdc, se->instance_id: 0
> version: 1.5.0, se->idstr: 0000:00:01.1/ide, se->instance_id: 0
> version: 1.5.0, se->idstr: i2c_bus, se->instance_id: 0
> version: 1.5.0, se->idstr: 0000:00:01.3/piix4_pm, se->instance_id: 0
> version: 1.5.0, se->idstr: 0000:00:06.0/i6300esb_wdt, se->instance_id: 0
> 
> Seems like the actual load is failing, but the VMSD hasn't changed so
> i'm not sure what's going on.
> 

Ehhh...

static const VMStateDescription vmstate_i6300esb = {
    .name = "i6300esb_wdt",
    .version_id = sizeof(I6300State),
    .minimum_version_id = sizeof(I6300State),
    .minimum_version_id_old = sizeof(I6300State),
    .fields      = (VMStateField []) {
        VMSTATE_PCI_DEVICE(dev, I6300State),
        VMSTATE_INT32(reboot_enabled, I6300State),
        VMSTATE_INT32(clock_scale, I6300State),
        VMSTATE_INT32(int_type, I6300State),
        VMSTATE_INT32(free_run, I6300State),
        VMSTATE_INT32(locked, I6300State),
        VMSTATE_INT32(enabled, I6300State),
        VMSTATE_TIMER(timer, I6300State),
        VMSTATE_UINT32(timer1_preload, I6300State),
        VMSTATE_UINT32(timer2_preload, I6300State),
        VMSTATE_INT32(stage, I6300State),
        VMSTATE_INT32(unlock_state, I6300State),
        VMSTATE_INT32(previous_reboot_flag, I6300State),
        VMSTATE_END_OF_LIST()
    }
};

apparently minimum version ID is set the size of the device struct?

Almost certain that's the problem.

> > 
> > /Nick
> > 
> > 
> > 

Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure

[Peter Maydell]

On 21 May 2013 18:26, mdroth <mdroth@linux.vnet.ibm.com> wrote:
> static const VMStateDescription vmstate_i6300esb = {
>     .name = "i6300esb_wdt",
>     .version_id = sizeof(I6300State),
>     .minimum_version_id = sizeof(I6300State),
>     .minimum_version_id_old = sizeof(I6300State),

> apparently minimum version ID is set the size of the device struct?
>
> Almost certain that's the problem.

Haha, yeah, that's totally busted. Interestingly it's been
like that since 2009. I think to fix this we probably need to:
 * set version_id to something fixed but larger than
   the worst sizeof() has ever been for this device.
   Since we have plenty of space in an int we might as
   well set it to 10000.
 * set minimum_version_id and minimum_version_id_old to 1
   [this is safe, I think, since the fields haven't ever
   changed, but needs testing]
 * add a big fat comment about why the weird version ID

This then brings it into line with everything else, and
the standard rules about when to bump vmstate version
and marking up new fields with first-version-present and
so on all apply as usual.

thanks
-- PMM

Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure

[mdroth]

On Tue, May 21, 2013 at 06:50:23PM +0100, Peter Maydell wrote:
> On 21 May 2013 18:26, mdroth <mdroth@linux.vnet.ibm.com> wrote:
> > static const VMStateDescription vmstate_i6300esb = {
> >     .name = "i6300esb_wdt",
> >     .version_id = sizeof(I6300State),
> >     .minimum_version_id = sizeof(I6300State),
> >     .minimum_version_id_old = sizeof(I6300State),
> 
> > apparently minimum version ID is set the size of the device struct?
> >
> > Almost certain that's the problem.
> 
> Haha, yeah, that's totally busted. Interestingly it's been
> like that since 2009. I think to fix this we probably need to:
>  * set version_id to something fixed but larger than
>    the worst sizeof() has ever been for this device.
>    Since we have plenty of space in an int we might as
>    well set it to 10000.
>  * set minimum_version_id and minimum_version_id_old to 1
>    [this is safe, I think, since the fields haven't ever
>    changed, but needs testing]
>  * add a big fat comment about why the weird version ID
> 
> This then brings it into line with everything else, and
> the standard rules about when to bump vmstate version
> and marking up new fields with first-version-present and
> so on all apply as usual.

Makes sense, but apparently version IDs for incoming device state are
not allowed to exceed the destination's version, so we can't bump it
beyond the value in 1.5 without breaking migration from 1.5+ -> 1.5

So I think our only option for version ID is to lock in the 1.5 value,
which seems to be 1936 (hopefully that's consistent across builds...).

But reseting minimum version ID to 1 does seem to fix 1.4 -> 1.5+

> 
> thanks
> -- PMM
> 

Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure

[Peter Maydell]

On 21 May 2013 21:43, mdroth <mdroth@linux.vnet.ibm.com> wrote:
> Makes sense, but apparently version IDs for incoming device state are
> not allowed to exceed the destination's version, so we can't bump it
> beyond the value in 1.5 without breaking migration from 1.5+ -> 1.5

We care about backwards migration? That sounds like a pain.

> So I think our only option for version ID is to lock in the 1.5 value,
> which seems to be 1936 (hopefully that's consistent across builds...).

Yeah, I'm not convinced that's going to be consistent across builds,
compilers, 64 vs 32 bit, etc etc etc. That's why I suggested a really
high number.

thanks
-- PMM

Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure

[mdroth]

On Tue, May 21, 2013 at 10:16:48PM +0100, Peter Maydell wrote:
> On 21 May 2013 21:43, mdroth <mdroth@linux.vnet.ibm.com> wrote:
> > Makes sense, but apparently version IDs for incoming device state are
> > not allowed to exceed the destination's version, so we can't bump it
> > beyond the value in 1.5 without breaking migration from 1.5+ -> 1.5
> 
> We care about backwards migration? That sounds like a pain.

As a best effort at least, hence subsections and whatnot, but not
always. This case for instance...

> 
> > So I think our only option for version ID is to lock in the 1.5 value,
> > which seems to be 1936 (hopefully that's consistent across builds...).
> 
> Yeah, I'm not convinced that's going to be consistent across builds,
> compilers, 64 vs 32 bit, etc etc etc. That's why I suggested a really
> high number.

Yah, it's more important to ensure old->new. Playing guessing games
about struct sizes to try to maintain new->old is likely to conflict
with that, so I guess we don't have much choice here. I'll send a patch
out shortly.

> 
> thanks
> -- PMM
>