On Thu, Sep 24, 2015 at 02:18:50PM +0300, Slawa Olhovchenkov wrote:
> On Thu, Sep 24, 2015 at 11:28:05AM +0300, Andrey V. Elsukov wrote:
> > On 23.09.2015 19:57, Andriy Gapon wrote:
> > > I do not have a strong opinion.  Either option, rc.d/dumpon change or 
> > > geom_dev
> > > change, is fine with me.
> > 
> > I added the ability to set dumpdev via loader. But I wasn't aware that
> > it was used in rc.d script.
> > 
> > If you have set dumpdev kenv, it will be already enabled in the time
> > when rc.d/dumpon  will be run. So, I think it is useless to try to
> > enable dumpdev again. I prefer remove this old code from rc.d script.
> rc.d script can redirect dump to device, not available at boot time,
> iSCSI disk, for examle.

No. Dump device is very special. It runs in an environment when kernel
already paniced, there are no interrupt, so there is no networking.
Storage controllers have special methods to handle dumping kernel memory
- it doesn't go through GEOM, it cannot go through GEOM as the scheduler
doesn't work too.

Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://mobter.com

Attachment: pgpfeiUIcx0t9.pgp
Description: PGP signature

Reply via email to