dump LOB status

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

dump LOB status

Jose Soares
Hi!

I am getting the following output from dump:

 # dump -0au -f /dev/nrst0 /dev/rsd0d
  DUMP: Date of this level 0 dump: Tue Sep 15 16:23:09 2020
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rsd0d to /dev/nrst0
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 2843256661 tape blocks.
  DUMP: Volume 1 started at: Tue Sep 15 16:24:11 2020
  DUMP: Child 97414 returns LOB status 213

Could you please explain the meaning of "LOB status 213"?

Here is the dmesg:
OpenBSD 6.6 (GENERIC.MP) #4: Thu Sep  3 19:46:18 MDT 2020
    [hidden email]:/usr/src/sys/arch/amd64/compile/
GENERIC.MP
real mem = 8568889344 (8171MB)
avail mem = 8296476672 (7912MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xdfcfa000 (65 entries)
bios0: vendor Intel Corporation version
"S3200X38.86B.00.00.0052.112920101508" date 11/29/2010
bios0: Intel Corporation S3210SH
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT SLIC FACP APIC WDDT MCFG HPET SPCR SSDT SSDT SSDT SSDT
SSDT HEST BERT ERST EINJ
acpi0: wakeup devices SLPB(S5) NPE1(S5) NPE6(S5) P32_(S5) PS2M(S1) PS2K(S1)
ILAN(S5) PEX0(S5) PXHV(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5)
UHC1(S1) UHC2(S1) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.86 MHz, 06-17-06
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 332MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.50 MHz, 06-17-06
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 6MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 5 pa 0xfec00000, version 20, 24 pins, remapped
ioapic1 at mainbus0: apid 6 pa 0xfec10000, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf0000000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (NPE1)
acpiprt2 at acpi0: bus 2 (NPE6)
acpiprt3 at acpi0: bus 6 (P32_)
acpiprt4 at acpi0: bus 3 (PEX0)
acpiprt5 at acpi0: bus 4 (PXHV)
acpiprt6 at acpi0: bus -1 (PEX1)
acpiprt7 at acpi0: bus -1 (PEX2)
acpiprt8 at acpi0: bus -1 (PEX3)
acpiprt9 at acpi0: bus 5 (PEX4)
acpiprt10 at acpi0: bus -1 (PEX5)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
"PNP0C33" at acpi0 not configured
acpipci0 at acpi0 PCI0: _OSC failed
acpicmos0 at acpi0
"PNP0003" at acpi0 not configured
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 2992 MHz: speeds: 3000, 2000 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 3200/3210 Host" rev 0x00
ppb0 at pci0 dev 1 function 0 "Intel 3200/3210 PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
mfi0 at pci1 dev 0 function 0 "Symbios Logic MegaRAID SAS2108 GEN2" rev
0x04: apic 5 int 16
mfi0: "PERC H700 Integrated", firmware 12.10.6-0001, 512MB cache
scsibus1 at mfi0: 64 targets
sd0 at scsibus1 targ 0 lun 0: <DELL, PERC H700, 2.10>
naa.6842b2b009c2360026373e4c0bb58c37
sd0: 11445248MB, 512 bytes/sector, 23439867904 sectors
ppb1 at pci0 dev 6 function 0 "Intel 3210 PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
mpii0 at pci2 dev 0 function 0 "Symbios Logic SAS2008" rev 0x03: msi
mpii0: PERC H200A, firmware 7.15.8.0 IR, MPI 2.0
scsibus2 at mpii0: 42 targets
em0 at pci0 dev 25 function 0 "Intel ICH9 IGP AMT" rev 0x02: msi, address
00:15:17:9d:9b:49
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 5 int 18
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 5 int 21
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 5 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev
2.00/1.00 addr 1
ppb2 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
ppb3 at pci3 dev 0 function 0 "Intel 6702PXH PCIE-PCIX" rev 0x09
pci4 at ppb3 bus 4
ppb4 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi
pci5 at ppb4 bus 5
5:0:0: rom address conflict 0xffff0000/0x10000
vga1 at pci5 dev 0 function 0 "Matrox MGA G200e" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
uhci2 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 5 int 23
uhci3 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 5 int 19
uhci4 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x02: apic 5 int 18
ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x02: apic 5 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev
2.00/1.00 addr 1
ppb5 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92
pci6 at ppb5 bus 6
em1 at pci6 dev 2 function 0 "Intel 82541GI" rev 0x05: apic 5 int 18,
address 00:15:17:9d:9b:47
pcib0 at pci0 dev 31 function 0 "Intel 82801IR LPC" rev 0x02
pciide0 at pci0 dev 31 function 2 "Intel 82801I SATA" rev 0x02: DMA,
channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using apic 5 int 21 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: <ST340014AS>
wd0: 16-sector PIO, LBA48, 38146MB, 78125000 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 5 int
18
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM ECC PC2-6400CL6
spdmem1 at iic0 addr 0x51: 2GB DDR2 SDRAM ECC PC2-6400CL6
spdmem2 at iic0 addr 0x52: 2GB DDR2 SDRAM ECC PC2-6400CL6
spdmem3 at iic0 addr 0x53: 2GB DDR2 SDRAM ECC PC2-6400CL6
pciide1 at pci0 dev 31 function 5 "Intel 82801I SATA" rev 0x02: DMA,
channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide1: using apic 5 int 21 for native-PCI interrupt
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
usb6 at uhci4: USB revision 1.0
uhub6 at usb6 configuration 1 interface 0 "Intel UHCI root hub" rev
1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
st0 at scsibus2 targ 9 lun 0: <QUANTUM, ULTRIUM-HH5, H971> removable
naa.500507631213cecb
root on wd0a (da916793f14f9657.a) swap on wd0b dump on wd0b

Thank you.

José Soares
Reply | Threaded
Open this post in threaded view
|

Re: dump LOB status

Stuart Henderson
On 2020-09-15, Jose Soares <[hidden email]> wrote:

> Hi!
>
> I am getting the following output from dump:
>
>  # dump -0au -f /dev/nrst0 /dev/rsd0d
>   DUMP: Date of this level 0 dump: Tue Sep 15 16:23:09 2020
>   DUMP: Date of last level 0 dump: the epoch
>   DUMP: Dumping /dev/rsd0d to /dev/nrst0
>   DUMP: mapping (Pass I) [regular files]
>   DUMP: mapping (Pass II) [directories]
>   DUMP: estimated 2843256661 tape blocks.
>   DUMP: Volume 1 started at: Tue Sep 15 16:24:11 2020
>   DUMP: Child 97414 returns LOB status 213
>
> Could you please explain the meaning of "LOB status 213"?

LOB=low-order byte

What 213 represents, I'm not sure...


Reply | Threaded
Open this post in threaded view
|

Re: dump LOB status

Jose Soares
Thank you, Stuart.

I am facing this when issuing the dump command of a "large" file system
(2.7TB).
dump command has finished successfully for the other smaller file systems.

# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/wd0a      2.0G    237M    1.6G    12%    /
/dev/sd0d     10.8T    2.7T    7.6T    26%    /home
/dev/wd0d      3.9G    146K    3.7G     0%    /tmp
/dev/wd0f      3.9G    956M    2.8G    25%    /usr
/dev/wd0g      2.0G    253M    1.6G    13%    /usr/X11R6
/dev/wd0h      5.9G   15.6M    5.6G     0%    /usr/local
/dev/wd0j      3.1G    2.0K    3.0G     0%    /usr/obj
/dev/wd0i      2.0G    2.0K    1.9G     0%    /usr/src
/dev/wd0e      5.9G    106M    5.5G     2%    /var

The only contribution I was able to find via Google was
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244470 where a similar
problem was being reported also regarding a dump of a large file system,
but for FreeBSD.

Any suggestion to get the dump working or to better understand what is
happening?

Jose Soares



On Tue, Sep 15, 2020 at 4:47 PM Stuart Henderson <[hidden email]>
wrote:

> On 2020-09-15, Jose Soares <[hidden email]> wrote:
> > Hi!
> >
> > I am getting the following output from dump:
> >
> >  # dump -0au -f /dev/nrst0 /dev/rsd0d
> >   DUMP: Date of this level 0 dump: Tue Sep 15 16:23:09 2020
> >   DUMP: Date of last level 0 dump: the epoch
> >   DUMP: Dumping /dev/rsd0d to /dev/nrst0
> >   DUMP: mapping (Pass I) [regular files]
> >   DUMP: mapping (Pass II) [directories]
> >   DUMP: estimated 2843256661 tape blocks.
> >   DUMP: Volume 1 started at: Tue Sep 15 16:24:11 2020
> >   DUMP: Child 97414 returns LOB status 213
> >
> > Could you please explain the meaning of "LOB status 213"?
>
> LOB=low-order byte
>
> What 213 represents, I'm not sure...
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: dump LOB status

Juha Erkkilä

> On 15. Sep 2020, at 18.54, Jose Soares <[hidden email]> wrote:
>
> Thank you, Stuart.
>
> I am facing this when issuing the dump command of a "large" file system
> (2.7TB).
> dump command has finished successfully for the other smaller file systems.
>
> # df -h
> Filesystem     Size    Used   Avail Capacity  Mounted on
> /dev/wd0a      2.0G    237M    1.6G    12%    /
> /dev/sd0d     10.8T    2.7T    7.6T    26%    /home
> /dev/wd0d      3.9G    146K    3.7G     0%    /tmp
> /dev/wd0f      3.9G    956M    2.8G    25%    /usr
> /dev/wd0g      2.0G    253M    1.6G    13%    /usr/X11R6
> /dev/wd0h      5.9G   15.6M    5.6G     0%    /usr/local
> /dev/wd0j      3.1G    2.0K    3.0G     0%    /usr/obj
> /dev/wd0i      2.0G    2.0K    1.9G     0%    /usr/src
> /dev/wd0e      5.9G    106M    5.5G     2%    /var
>
> The only contribution I was able to find via Google was
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244470 where a similar
> problem was being reported also regarding a dump of a large file system,
> but for FreeBSD.
>
> Any suggestion to get the dump working or to better understand what is
> happening?

Segfault on dump, tape.c line 335 spcl.c_addr[I], it overflows.

A workaround is to raise TP_BSIZE from 1024 to
something bigger (maybe 8192?) in /usr/include/protocols/dumprestore.h
and recompile dump. Not a proper fix!

(Also happened to me maybe a week ago, recent -current,
indeed the filesystem was big (2 terabytes)).

Reply | Threaded
Open this post in threaded view
|

Re: dump LOB status

Kenneth Gober
In reply to this post by Jose Soares
On Tue, Sep 15, 2020 at 12:04 PM Jose Soares <[hidden email]>
wrote:

> I am facing this when issuing the dump command of a "large" file system
> (2.7TB).
> dump command has finished successfully for the other smaller file systems.
>
> On Tue, Sep 15, 2020 at 4:47 PM Stuart Henderson <[hidden email]>
> wrote:
> > On 2020-09-15, Jose Soares <[hidden email]> wrote:
> > >   DUMP: Child 97414 returns LOB status 213
> > >
> > > Could you please explain the meaning of "LOB status 213"?
> >
> > LOB=low-order byte
> >
> > What 213 represents, I'm not sure...
>

I took a very quick look at the source and it appears that 213 is shown in
octal.  I believe that the 200 bit indicates that a core file was produced,
and 13 is probably a signal number (13 octal equals 11 decimal which would
be SIGSEGV).  I am not sure whether the size of the file system is itself
the cause, I have been using dump(8) to back up a large (currently 6.7TB)
volume to tape for years (several tapes, actually) and it works fine,
although that system is still on 6.1/amd64.  I looked in CVS and didn't see
any obvious diffs between 6.1 and 6.6 that jumped out at me as potential
causes, so perhaps the issue has been latent for a long time and I haven't
seen it because it's triggered by the particulars of one or more files
rather than the overall file system size.  Maybe if an individual file gets
too big, or is too 'sparse' or something?

-ken
Reply | Threaded
Open this post in threaded view
|

Re: dump LOB status

Juha Erkkilä

> On 16. Sep 2020, at 0.18, Kenneth Gober <[hidden email]> wrote:
> I took a very quick look at the source and it appears that 213 is shown in
> octal.  I believe that the 200 bit indicates that a core file was produced,
> and 13 is probably a signal number (13 octal equals 11 decimal which would
> be SIGSEGV).  I am not sure whether the size of the file system is itself
> the cause, I have been using dump(8) to back up a large (currently 6.7TB)
> volume to tape for years (several tapes, actually) and it works fine,
> although that system is still on 6.1/amd64.  I looked in CVS and didn't see
> any obvious diffs between 6.1 and 6.6 that jumped out at me as potential
> causes, so perhaps the issue has been latent for a long time and I haven't
> seen it because it's triggered by the particulars of one or more files
> rather than the overall file system size.  Maybe if an individual file gets
> too big, or is too 'sparse' or something?

I can reproduce this on -current from Fri Sep 11 11:30:09
with a freshly created and an empty filesystem of 2 terabytes.

Reply | Threaded
Open this post in threaded view
|

Re: dump LOB status

Sebastien Marie-3
In reply to this post by Stuart Henderson
On Tue, Sep 15, 2020 at 03:19:25PM -0000, Stuart Henderson wrote:

> On 2020-09-15, Jose Soares <[hidden email]> wrote:
> > Hi!
> >
> > I am getting the following output from dump:
> >
> >  # dump -0au -f /dev/nrst0 /dev/rsd0d
> >   DUMP: Date of this level 0 dump: Tue Sep 15 16:23:09 2020
> >   DUMP: Date of last level 0 dump: the epoch
> >   DUMP: Dumping /dev/rsd0d to /dev/nrst0
> >   DUMP: mapping (Pass I) [regular files]
> >   DUMP: mapping (Pass II) [directories]
> >   DUMP: estimated 2843256661 tape blocks.
> >   DUMP: Volume 1 started at: Tue Sep 15 16:24:11 2020
> >   DUMP: Child 97414 returns LOB status 213
> >
> > Could you please explain the meaning of "LOB status 213"?
>
> LOB=low-order byte
>
> What 213 represents, I'm not sure...
 
The message comes from sbin/dump/tape.c

   592  #ifdef TDEBUG
   593                  msg("Tape: %d; parent process: %d child process %d\n",
   594                          tapeno+1, parentpid, childpid);
   595  #endif /* TDEBUG */
   596                  while ((waitingpid = wait(&status)) != childpid)
   597                          msg("Parent %d waiting for child %d has another child %d return\n",
   598                                  parentpid, childpid, waitingpid);
   599                  if (status & 0xFF) {
   600                          msg("Child %d returns LOB status %o\n",
   601                                  childpid, status&0xFF);
   602                  }

213 is octal number (139, 0x8b) of exit code of child process.

As the status is &0xFF, I am not 100% sure, but usually an exit code
of 139 means that the process terminated due to receipt of signal 11,
and generated a coredump.

Do you have a dump.core file ? Can you extract the backtrace ?

Thanks.
--
Sebastien Marie