v5.6 is still throwing a stack trace on boot.

v5.6 is still throwing a stack trace on boot.

[Rob Landley]

Run /init as init process
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at mm/slub.c:2468 ___slab_alloc.constprop.0+0x1f0/0x290

CPU: 0 PID: 1 Comm: swapper Not tainted 5.6.0 #2
PC is at ___slab_alloc.constprop.0+0x1f0/0x290
PR is at __slab_alloc.constprop.0+0x2e/0x54
PC  : 8c0a76c4 SP  : 8f829ea0 SR  : 400080f0
TEA : c0001240
R0  : 8c0a74d4 R1  : 00000100 R2  : 00000100 R3  : 00000000
R4  : 8f8020a0 R5  : 00000dc0 R6  : 8c01d678 R7  : 8fff5180
R8  : 8f8020a0 R9  : 8fff5180 R10 : 8c01d678 R11 : 80000000
R12 : 00007fff R13 : 00000dc0 R14 : 8f8020a0
MACH: 0000008b MACL: 0ae4849d GBR : 00000000 PR  : 8c0a7792

Call trace:
 [<(ptrval)>] mm_alloc+0xe/0x48
 [<(ptrval)>] do_IRQ+0x0/0x50
 [<(ptrval)>] __slab_alloc.constprop.0+0x2e/0x54
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] mm_init.isra.0+0xdc/0x138
 [<(ptrval)>] kmem_cache_alloc+0xd0/0x15c
 [<(ptrval)>] mm_init.isra.0+0xdc/0x138
 [<(ptrval)>] mm_init.isra.0+0xdc/0x138
 [<(ptrval)>] memset+0x0/0x8c
 [<(ptrval)>] __do_execve_file+0x22e/0x5d8
 [<(ptrval)>] kmem_cache_alloc+0x0/0x15c
 [<(ptrval)>] do_execve+0x16/0x24
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] printk+0x0/0x24
 [<(ptrval)>] kernel_init+0x34/0xe8
 [<(ptrval)>] ret_from_kernel_thread+0xc/0x14
 [<(ptrval)>] schedule_tail+0x0/0x5c
 [<(ptrval)>] kernel_init+0x0/0xe8

---[ end trace 76213c1325250d90 ]---

Re: v5.6 is still throwing a stack trace on boot.

[Rich Felker]

On Fri, Apr 03, 2020 at 06:49:00PM -0500, Rob Landley wrote:
> Run /init as init process
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at mm/slub.c:2468 ___slab_alloc.constprop.0+0x1f0/0x290
> 
> CPU: 0 PID: 1 Comm: swapper Not tainted 5.6.0 #2
> PC is at ___slab_alloc.constprop.0+0x1f0/0x290
> PR is at __slab_alloc.constprop.0+0x2e/0x54
> PC  : 8c0a76c4 SP  : 8f829ea0 SR  : 400080f0
> TEA : c0001240
> R0  : 8c0a74d4 R1  : 00000100 R2  : 00000100 R3  : 00000000
> R4  : 8f8020a0 R5  : 00000dc0 R6  : 8c01d678 R7  : 8fff5180
> R8  : 8f8020a0 R9  : 8fff5180 R10 : 8c01d678 R11 : 80000000
> R12 : 00007fff R13 : 00000dc0 R14 : 8f8020a0
> MACH: 0000008b MACL: 0ae4849d GBR : 00000000 PR  : 8c0a7792
> 
> Call trace:
>  [<(ptrval)>] mm_alloc+0xe/0x48
>  [<(ptrval)>] do_IRQ+0x0/0x50
>  [<(ptrval)>] __slab_alloc.constprop.0+0x2e/0x54
>  [<(ptrval)>] arch_local_irq_restore+0x0/0x24
>  [<(ptrval)>] mm_init.isra.0+0xdc/0x138
>  [<(ptrval)>] kmem_cache_alloc+0xd0/0x15c
>  [<(ptrval)>] mm_init.isra.0+0xdc/0x138
>  [<(ptrval)>] mm_init.isra.0+0xdc/0x138
>  [<(ptrval)>] memset+0x0/0x8c
>  [<(ptrval)>] __do_execve_file+0x22e/0x5d8
>  [<(ptrval)>] kmem_cache_alloc+0x0/0x15c
>  [<(ptrval)>] do_execve+0x16/0x24
>  [<(ptrval)>] arch_local_irq_restore+0x0/0x24
>  [<(ptrval)>] printk+0x0/0x24
>  [<(ptrval)>] kernel_init+0x34/0xe8
>  [<(ptrval)>] ret_from_kernel_thread+0xc/0x14
>  [<(ptrval)>] schedule_tail+0x0/0x5c
>  [<(ptrval)>] kernel_init+0x0/0xe8
> 
> ---[ end trace 76213c1325250d90 ]---

Which hardware is this on? The qemu emulated board you're using?

Rich

Re: v5.6 is still throwing a stack trace on boot.

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

On 4/3/20 7:07 PM, Rich Felker wrote:
> On Fri, Apr 03, 2020 at 06:49:00PM -0500, Rob Landley wrote:
>> Run /init as init process
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 1 at mm/slub.c:2468 ___slab_alloc.constprop.0+0x1f0/0x290
>>
>> CPU: 0 PID: 1 Comm: swapper Not tainted 5.6.0 #2
>> PC is at ___slab_alloc.constprop.0+0x1f0/0x290
>> PR is at __slab_alloc.constprop.0+0x2e/0x54
>> PC  : 8c0a76c4 SP  : 8f829ea0 SR  : 400080f0
>> TEA : c0001240
>> R0  : 8c0a74d4 R1  : 00000100 R2  : 00000100 R3  : 00000000
>> R4  : 8f8020a0 R5  : 00000dc0 R6  : 8c01d678 R7  : 8fff5180
>> R8  : 8f8020a0 R9  : 8fff5180 R10 : 8c01d678 R11 : 80000000
>> R12 : 00007fff R13 : 00000dc0 R14 : 8f8020a0
>> MACH: 0000008b MACL: 0ae4849d GBR : 00000000 PR  : 8c0a7792
>>
>> Call trace:
>>  [<(ptrval)>] mm_alloc+0xe/0x48
>>  [<(ptrval)>] do_IRQ+0x0/0x50
>>  [<(ptrval)>] __slab_alloc.constprop.0+0x2e/0x54
>>  [<(ptrval)>] arch_local_irq_restore+0x0/0x24
>>  [<(ptrval)>] mm_init.isra.0+0xdc/0x138
>>  [<(ptrval)>] kmem_cache_alloc+0xd0/0x15c
>>  [<(ptrval)>] mm_init.isra.0+0xdc/0x138
>>  [<(ptrval)>] mm_init.isra.0+0xdc/0x138
>>  [<(ptrval)>] memset+0x0/0x8c
>>  [<(ptrval)>] __do_execve_file+0x22e/0x5d8
>>  [<(ptrval)>] kmem_cache_alloc+0x0/0x15c
>>  [<(ptrval)>] do_execve+0x16/0x24
>>  [<(ptrval)>] arch_local_irq_restore+0x0/0x24
>>  [<(ptrval)>] printk+0x0/0x24
>>  [<(ptrval)>] kernel_init+0x34/0xe8
>>  [<(ptrval)>] ret_from_kernel_thread+0xc/0x14
>>  [<(ptrval)>] schedule_tail+0x0/0x5c
>>  [<(ptrval)>] kernel_init+0x0/0xe8
>>
>> ---[ end trace 76213c1325250d90 ]---
> 
> Which hardware is this on? The qemu emulated board you're using?

Yes, qemu -M r2d. Built with attached miniconf, and run via:

qemu-system-sh4 -M r2d -serial null -serial mon:stdio -nographic -no-reboot \
  -m 256 -append "panic=1 HOST=sh4 console=ttySC1 noiotrap" -kernel zImage \
  -initrd sh4.cpio.gz

Rob

[-- Attachment #2: sh4.miniconf --]
[-- Type: text/plain, Size: 1260 bytes --]

# make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=sh4.miniconf
# make ARCH=sh -j $(nproc)
# boot arch/sh/boot/zImage


CONFIG_CPU_SUBTYPE_SH7751R=y
CONFIG_MMU=y
CONFIG_MEMORY_START=0x0c000000
CONFIG_VSYSCALL=y
CONFIG_SH_FPU=y
CONFIG_SH_RTS7751R2D=y
CONFIG_RTS7751R2D_PLUS=y
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_CONSOLE=y

CONFIG_PCI=y
CONFIG_NET_VENDOR_REALTEK=y
CONFIG_8139CP=y

CONFIG_PCI=y
CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_ATA_SFF=y
CONFIG_ATA_BMDMA=y
CONFIG_PATA_PLATFORM=y

#CONFIG_SPI=y
#CONFIG_SPI_SH_SCI=y
#CONFIG_MFD_SM501=y

#CONFIG_RTC_CLASS=y
#CONFIG_RTC_DRV_R9701=y
#CONFIG_RTC_DRV_SH=y
#CONFIG_RTC_HCTOSYS=y


# CONFIG_EMBEDDED is not set
CONFIG_EARLY_PRINTK=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y

CONFIG_BLK_DEV_LOOP=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_UTF8=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y

CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IPV6=y
CONFIG_NETDEVICES=y
#CONFIG_NET_CORE=y
#CONFIG_NETCONSOLE=y
CONFIG_ETHERNET=y

Re: v5.6 is still throwing a stack trace on boot.

[Rich Felker]

On Fri, Apr 03, 2020 at 07:28:27PM -0500, Rob Landley wrote:
> On 4/3/20 7:07 PM, Rich Felker wrote:
> > On Fri, Apr 03, 2020 at 06:49:00PM -0500, Rob Landley wrote:
> >> Run /init as init process
> >> ------------[ cut here ]------------
> >> WARNING: CPU: 0 PID: 1 at mm/slub.c:2468 ___slab_alloc.constprop.0+0x1f0/0x290
> >>
> >> CPU: 0 PID: 1 Comm: swapper Not tainted 5.6.0 #2
> >> PC is at ___slab_alloc.constprop.0+0x1f0/0x290
> >> PR is at __slab_alloc.constprop.0+0x2e/0x54
> >> PC  : 8c0a76c4 SP  : 8f829ea0 SR  : 400080f0
> >> TEA : c0001240
> >> R0  : 8c0a74d4 R1  : 00000100 R2  : 00000100 R3  : 00000000
> >> R4  : 8f8020a0 R5  : 00000dc0 R6  : 8c01d678 R7  : 8fff5180
> >> R8  : 8f8020a0 R9  : 8fff5180 R10 : 8c01d678 R11 : 80000000
> >> R12 : 00007fff R13 : 00000dc0 R14 : 8f8020a0
> >> MACH: 0000008b MACL: 0ae4849d GBR : 00000000 PR  : 8c0a7792
> >>
> >> Call trace:
> >>  [<(ptrval)>] mm_alloc+0xe/0x48
> >>  [<(ptrval)>] do_IRQ+0x0/0x50
> >>  [<(ptrval)>] __slab_alloc.constprop.0+0x2e/0x54
> >>  [<(ptrval)>] arch_local_irq_restore+0x0/0x24
> >>  [<(ptrval)>] mm_init.isra.0+0xdc/0x138
> >>  [<(ptrval)>] kmem_cache_alloc+0xd0/0x15c
> >>  [<(ptrval)>] mm_init.isra.0+0xdc/0x138
> >>  [<(ptrval)>] mm_init.isra.0+0xdc/0x138
> >>  [<(ptrval)>] memset+0x0/0x8c
> >>  [<(ptrval)>] __do_execve_file+0x22e/0x5d8
> >>  [<(ptrval)>] kmem_cache_alloc+0x0/0x15c
> >>  [<(ptrval)>] do_execve+0x16/0x24
> >>  [<(ptrval)>] arch_local_irq_restore+0x0/0x24
> >>  [<(ptrval)>] printk+0x0/0x24
> >>  [<(ptrval)>] kernel_init+0x34/0xe8
> >>  [<(ptrval)>] ret_from_kernel_thread+0xc/0x14
> >>  [<(ptrval)>] schedule_tail+0x0/0x5c
> >>  [<(ptrval)>] kernel_init+0x0/0xe8
> >>
> >> ---[ end trace 76213c1325250d90 ]---
> > 
> > Which hardware is this on? The qemu emulated board you're using?
> 
> Yes, qemu -M r2d. Built with attached miniconf, and run via:
> 
> qemu-system-sh4 -M r2d -serial null -serial mon:stdio -nographic -no-reboot \
>   -m 256 -append "panic=1 HOST=sh4 console=ttySC1 noiotrap" -kernel zImage \
>   -initrd sh4.cpio.gz

OK. This is nbd, it's just some pedantry added in commit
128227e7fe4087b60f1bd31f762e61237eb23790. Essentially it's complaining
that something requested zero-filled slab memory when it's about to
run a constructor to fill in the memory. The backtrace is (as usual)
somewhat bogus looking and grep isn't helping me find where it's being
called from. I'll keep looking and see if I can track it down.

Rich

Re: v5.6 is still throwing a stack trace on boot.

[Geert Uytterhoeven]

Hi Rich,

On Sat, Apr 4, 2020 at 2:55 AM Rich Felker <dalias@libc.org> wrote:
> On Fri, Apr 03, 2020 at 07:28:27PM -0500, Rob Landley wrote:
> > On 4/3/20 7:07 PM, Rich Felker wrote:
> > > On Fri, Apr 03, 2020 at 06:49:00PM -0500, Rob Landley wrote:
> > >> Run /init as init process
> > >> ------------[ cut here ]------------
> > >> WARNING: CPU: 0 PID: 1 at mm/slub.c:2468 ___slab_alloc.constprop.0+0x1f0/0x290
> > >>
> > >> CPU: 0 PID: 1 Comm: swapper Not tainted 5.6.0 #2
> > >> PC is at ___slab_alloc.constprop.0+0x1f0/0x290
> > >> PR is at __slab_alloc.constprop.0+0x2e/0x54
> > >> PC  : 8c0a76c4 SP  : 8f829ea0 SR  : 400080f0
> > >> TEA : c0001240
> > >> R0  : 8c0a74d4 R1  : 00000100 R2  : 00000100 R3  : 00000000
> > >> R4  : 8f8020a0 R5  : 00000dc0 R6  : 8c01d678 R7  : 8fff5180
> > >> R8  : 8f8020a0 R9  : 8fff5180 R10 : 8c01d678 R11 : 80000000
> > >> R12 : 00007fff R13 : 00000dc0 R14 : 8f8020a0
> > >> MACH: 0000008b MACL: 0ae4849d GBR : 00000000 PR  : 8c0a7792
> > >>
> > >> Call trace:
> > >>  [<(ptrval)>] mm_alloc+0xe/0x48
> > >>  [<(ptrval)>] do_IRQ+0x0/0x50
> > >>  [<(ptrval)>] __slab_alloc.constprop.0+0x2e/0x54
> > >>  [<(ptrval)>] arch_local_irq_restore+0x0/0x24
> > >>  [<(ptrval)>] mm_init.isra.0+0xdc/0x138
> > >>  [<(ptrval)>] kmem_cache_alloc+0xd0/0x15c
> > >>  [<(ptrval)>] mm_init.isra.0+0xdc/0x138
> > >>  [<(ptrval)>] mm_init.isra.0+0xdc/0x138
> > >>  [<(ptrval)>] memset+0x0/0x8c
> > >>  [<(ptrval)>] __do_execve_file+0x22e/0x5d8
> > >>  [<(ptrval)>] kmem_cache_alloc+0x0/0x15c
> > >>  [<(ptrval)>] do_execve+0x16/0x24
> > >>  [<(ptrval)>] arch_local_irq_restore+0x0/0x24
> > >>  [<(ptrval)>] printk+0x0/0x24
> > >>  [<(ptrval)>] kernel_init+0x34/0xe8
> > >>  [<(ptrval)>] ret_from_kernel_thread+0xc/0x14
> > >>  [<(ptrval)>] schedule_tail+0x0/0x5c
> > >>  [<(ptrval)>] kernel_init+0x0/0xe8
> > >>
> > >> ---[ end trace 76213c1325250d90 ]---
> > >
> > > Which hardware is this on? The qemu emulated board you're using?
> >
> > Yes, qemu -M r2d. Built with attached miniconf, and run via:

IIRC, it happens on real hardware, too (Migo-R, Ecovec24, RTS7751R2D?).

> > qemu-system-sh4 -M r2d -serial null -serial mon:stdio -nographic -no-reboot \
> >   -m 256 -append "panic=1 HOST=sh4 console=ttySC1 noiotrap" -kernel zImage \
> >   -initrd sh4.cpio.gz
>
> OK. This is nbd, it's just some pedantry added in commit
> 128227e7fe4087b60f1bd31f762e61237eb23790. Essentially it's complaining
> that something requested zero-filled slab memory when it's about to
> run a constructor to fill in the memory. The backtrace is (as usual)
> somewhat bogus looking and grep isn't helping me find where it's being
> called from. I'll keep looking and see if I can track it down.

I have Willy's fix in my local tree:
https://marc.info/?l=linux-arch&m\x153337991312146&w=2
waiting for this being fixed upstream ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: v5.6 is still throwing a stack trace on boot.

[Rob Landley]

On 4/3/20 7:51 PM, Rich Felker wrote:
> On Fri, Apr 03, 2020 at 07:28:27PM -0500, Rob Landley wrote:
>>>> ---[ end trace 76213c1325250d90 ]---
>>>
>>> Which hardware is this on? The qemu emulated board you're using?
>>
>> Yes, qemu -M r2d. Built with attached miniconf, and run via:
>>
>> qemu-system-sh4 -M r2d -serial null -serial mon:stdio -nographic -no-reboot \
>>   -m 256 -append "panic=1 HOST=sh4 console=ttySC1 noiotrap" -kernel zImage \
>>   -initrd sh4.cpio.gz
> 
> OK. This is nbd, it's just some pedantry added in commit
> 128227e7fe4087b60f1bd31f762e61237eb23790. Essentially it's complaining
> that something requested zero-filled slab memory when it's about to
> run a constructor to fill in the memory. The backtrace is (as usual)
> somewhat bogus looking and grep isn't helping me find where it's being
> called from. I'll keep looking and see if I can track it down.

Did you?

Also, https://marc.info/?l=linux-sh&m\x158544749818664&w=2 still doesn't seem to
be upstream?

Rob

Re: v5.6 is still throwing a stack trace on boot.

[Rich Felker]

On Tue, Apr 07, 2020 at 09:21:26AM -0500, Rob Landley wrote:
> On 4/3/20 7:51 PM, Rich Felker wrote:
> > On Fri, Apr 03, 2020 at 07:28:27PM -0500, Rob Landley wrote:
> >>>> ---[ end trace 76213c1325250d90 ]---
> >>>
> >>> Which hardware is this on? The qemu emulated board you're using?
> >>
> >> Yes, qemu -M r2d. Built with attached miniconf, and run via:
> >>
> >> qemu-system-sh4 -M r2d -serial null -serial mon:stdio -nographic -no-reboot \
> >>   -m 256 -append "panic=1 HOST=sh4 console=ttySC1 noiotrap" -kernel zImage \
> >>   -initrd sh4.cpio.gz
> > 
> > OK. This is nbd, it's just some pedantry added in commit
> > 128227e7fe4087b60f1bd31f762e61237eb23790. Essentially it's complaining
> > that something requested zero-filled slab memory when it's about to
> > run a constructor to fill in the memory. The backtrace is (as usual)
> > somewhat bogus looking and grep isn't helping me find where it's being
> > called from. I'll keep looking and see if I can track it down.
> 
> Did you?
> 
> Also, https://marc.info/?l=linux-sh&m\x158544749818664&w=2 still doesn't seem to
> be upstream?

See Geert's reply,

Message-ID: <CAMuHMdVm-871S5tOdQw0KbRao+L0Wg46Rk3yNRyW45zJf3qt4w@mail.gmail.com>

I think the patch is correct but still don't thoroughly understand it
(in terms of where these functions are used and whether it preserves
the property that everything that needs zero-fill gets it). Will
follow up soon.

Rich

Re: v5.6 is still throwing a stack trace on boot.

[Rob Landley]

On 4/7/20 10:21 AM, Rich Felker wrote:
> On Tue, Apr 07, 2020 at 09:21:26AM -0500, Rob Landley wrote:
>> On 4/3/20 7:51 PM, Rich Felker wrote:
>>> On Fri, Apr 03, 2020 at 07:28:27PM -0500, Rob Landley wrote:
>>>>>> ---[ end trace 76213c1325250d90 ]---
>>>>>
>>>>> Which hardware is this on? The qemu emulated board you're using?
>>>>
>>>> Yes, qemu -M r2d. Built with attached miniconf, and run via:
>>>>
>>>> qemu-system-sh4 -M r2d -serial null -serial mon:stdio -nographic -no-reboot \
>>>>   -m 256 -append "panic=1 HOST=sh4 console=ttySC1 noiotrap" -kernel zImage \
>>>>   -initrd sh4.cpio.gz
>>>
>>> OK. This is nbd, it's just some pedantry added in commit
>>> 128227e7fe4087b60f1bd31f762e61237eb23790. Essentially it's complaining
>>> that something requested zero-filled slab memory when it's about to
>>> run a constructor to fill in the memory. The backtrace is (as usual)
>>> somewhat bogus looking and grep isn't helping me find where it's being
>>> called from. I'll keep looking and see if I can track it down.
>>
>> Did you?

[crickets]

>> Also, https://marc.info/?l=linux-sh&m\x158544749818664&w=2 still doesn't seem to
>> be upstream?
> 
> See Geert's reply,
> 
> Message-ID: <CAMuHMdVm-871S5tOdQw0KbRao+L0Wg46Rk3yNRyW45zJf3qt4w@mail.gmail.com>

404 error from
https://lkml.kernel.org/lkml/CAMuHMdVm-871S5tOdQw0KbRao+L0Wg46Rk3yNRyW45zJf3qt4w@mail.gmail.com/

No idea what else I'm supposed to do with a message ID other than that. I tried
googling for the message ID string and there were zero hits.

Do you mean Geert's March 15 message forwarding the alignment issue to arnd and
linux-arch, which predated my message cc-ing Linus before rc6 came out (I.E. not
the memory dump issue)? Are you saying "Geert forwarded it to somebody else last
month, therefore there's nothing to follow up on?" Because I just checked and
still nobody's replied to it on linux-arch:

  https://www.spinics.net/lists/linux-arch/

I'm not sure anybody saw it. And he only forwarded them the 2/2 patch, not the
first one.

> I think the patch is correct but still don't thoroughly understand it
> (in terms of where these functions are used and whether it preserves
> the property that everything that needs zero-fill gets it).

Do you still mean the two added align directives? If so, how is zeroing
involved? (Because if Geert replied about the stack dump issue, it was either
before March 1, or neither I nor the list were cc'd.)

> Will follow up soon.

Ok, I'll wait until -rc1 closes to send this reply...

Rob