"gpart show" stuck in loop

[Kevin Day]

We've had one of our boxes getting stuck with "gpart show" (called from rc startup scripts) consuming 100% cpu after each reboot. Manually running "gpart show" gives me:

# gpart show |more
=>       63  715571136  amrd0  MBR  (341G)
         63  715567167      1  freebsd  [active]  (341G)
  715567230       3969         - free -  (1.9M)

=>        0  715567167  amrd0s1  BSD  (341G)
          0  696254464        1  freebsd-ufs  (332G)
  696254464   19312703        2  freebsd-swap  (9.2G)

=>        63  5860573110  da0  MBR  (2.7T)
          63  2147472747    1  freebsd  [active]  (1.0T)
  2147472810  2147472810    2  freebsd  [active]  (1.0T)
  4294945620  -2729352721    3  freebsd  [active]  ()
  1565592899   581879911       - free -  (277G)
  2147472810  2147472810    2  freebsd  [active]  (1.0T)
  4294945620  -2729352721    3  freebsd  [active]  ()
  1565592899   581879911       - free -  (277G)
  2147472810  2147472810    2  freebsd  [active]  (1.0T)
  4294945620  -2729352721    3  freebsd  [active]  ()
  1565592899   581879911       - free -  (277G)
  2147472810  2147472810    2  freebsd  [active]  (1.0T)
  4294945620  -2729352721    3  freebsd  [active]  ()
  1565592899   581879911       - free -  (277G)
  2147472810  2147472810    2  freebsd  [active]  (1.0T)
  4294945620  -2729352721    3  freebsd  [active]  ()
  1565592899   581879911       - free -  (277G)
(repeating forever)


I'm guessing something is corrupt in the partition table. I'm happy to file a PR on this, but I can only leave this untouched for a day or two max before I'm going to have to wipe this and start over for a new customer who needs this storage array. Is there anything anyone could suggest looking at or preserving before I'm forced to delete this? 

The storage system came to me configured like this, I don't know what the previous owner was attempting to do, or how they ended up with the partitions like this.

-- Kevin



da0 at mpt0 bus 0 scbus0 target 0 lun 0
da0: <APPLE Xserve RAID 1.51> Fixed Direct Access SCSI-5 device 
da0: 100.000MB/s transfers
da0: Command Queueing enabled
da0: 2861608MB (5860573184 512 byte sectors: 255H 63S/T 364803C)


# fdisk da0
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=364803 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=364803 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 2147472747 (1048570 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 2147472810, size 2147472810 (1048570 Meg), flag 80 (active)
        beg: cyl 1023/ head 255/ sector 63;
        end: cyl 1023/ head 254/ sector 63
The data for partition 3 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 4294945620, size 1565614575 (764460 Meg), flag 80 (active)
        beg: cyl 1023/ head 255/ sector 63;
        end: cyl 1023/ head 165/ sector 59
The data for partition 4 is:
<UNUSED>