dumpsys/savecore on AF-4Kn drives?

[Pokala, Ravi]

Hi folks,

Does anyone out there have AF-4Kn drives (both logical and physical sector
size is 4KB)? Have you been able to drop a core to one, and successfully
save the core on the way back up?

I'm working on adding AF-4Kn support to an older version of FreeBSD (based
on 7 - yeah, I know... :-P), using -CURRENT as a reference. Things look
good at the GEOM level and higher; the GEOM utils report correct sizes,
UFS runs fine, etc. If I manually break into the debugger and 'call
doadump', it appears to work; at least, it does not report any errors. But
when I reboot, `savecore' complains:

    error reading dump header at offset 0 in /dev/mirror/gm1: Invalid
argument

(Yes, it's dumping to a mirror; no, that's not the problem: the mirror is
configured using the 'prefer' balancing algorithm, as described in
gmirror(8), and we've been doing this without issue for years.)

I'm trying to figure out if the problem is on the dumpsys side, the
savecore side, or if they're both broken for AF-4Kn. In particular,
'struct kerneldumpheader' is 512 bytes, and it looks like most calls to
dump_write() in the full-dump context (not minidumps) pass either the size
of the structure, or an explicit 512, for the 'length' argument. That's
the case in both the 7-ish version I'm porting to, and in -CURRENT.

There's no AF-4Kn-aware bootstrap in the version we're using (emaste@ -
does the new UEFI bootstrap in 10-STABLE work w/ AF-4Kn drives?), so one
of the drives is 512n, and I could probably find some space on there to
save the core to. But that device is small, and we have other uses for it,
so I'd like to avoid reserving a large chunk of it.

Any thoughts?

Thanks,

Ravi