In article <CAGisHBdzjDazW7H_bcDmQ=aERqcuc=qdyvrkj7vqfqhuqy7...@mail.gmail.com>, Jose Luis Rodriguez Garcia <joseyl...@gmail.com> wrote: >I have been debuging this problem with gdb and printfs in the source >for locate the path. > >I have found it fails in: > >arch/amd64/amd64/machdep.c:dodumpsys does: psize = bdev_size(dumpdev); >kern/subr_devsw.c:bdev_size calls rv = (*d->d_psize)(dev) >In my case the dev has major 0 and minor 1 >(gdb) print bdevsw[0].d_psize >$1 = (int (*)(dev_t)) 0xffffffff80a0ad60 <wdsize> > >then d->d_psize is the function wdsize > >dev/ata/wd.c:wdsize does wd = device_lookup_private(&wd_cd, WDUNIT(dev)); >kern/subr_autoconf.c:device_lookup_private does return >device_private(device_lookup(cd, unit)); >kern/subr_autoconf.c:device_lookup fails and returns NULL. This is in >the sentence: > > >else if ((dv = cd->cd_devs[unit]) != NULL && dv->dv_del_gen != 0) > dv = NULL; > >config_alldevs_unlock(s); > > return dv; > >because cd->cd_devs[unit]) is null. > >I have checked these values with printf in the function and these are >(executing a reboot -d): >unit: 0 >cd->cd_ndevs: 4 >dv is assigned NULL in the asignement: dv = cd->cd_devs[unit]) > >If I check these values when the system is running cd->cd_devs[unit] isn't >NULL. >(gdb) print wd_cd->cd_devs[0] >$23 = (device_t) 0xfffffe8107cc6408 >(gdb) print (*wd_cd->cd_devs[0]).dv_del_gen >$24 = 0 > >It seems that in the ordered shutdow process this structure >(cd->cd_devs[unit] is destroyed, and the dump fails. > > > >This is the log from dmesg. It says "dump area unavailable" >(file src/sys/arch/amd64/amd64/machdep.c line 1156) >..... >wd0: detached >atabus0: detached > >dumping to dev 0,1 (offset=8410383, size=1046094): >dump area unavailable >rebooting... > >The swap device configuration seems ok: >pc2$ swapctl -z >dump device is wd0b > >
Perhaps we should prevent the dumping device from being detatched if RB_DUMP is set. christos
