> > The only reasonable option, there seems to be 0x4 reset code which means
> > "execute int 0x19". Unfortunately, when using this code BIOSes do not
> > reset interrupt vectors and other stuff needed to boot-up so it would not
> > work.
>
> at the moment, I use the 0x9 code which makes the bios do some very little
> hardware initialization and does a RETF from a stack passed by my program.
Well, in that case you could use 0xa, which is handled by all i386 and
newer BIOSes, AFAIK, and requires less messing. Neither are safe, anyway,
because they require RAM contents to be valid which might not be the case.
And executing from clobbered RAM mau cause further destruction -- e.g.
some unwanted hard disk writes.
> > Other options are either not defined precisely or need data from RAM,
> > which might already be trashed. In the latter case it's better to halt or
> > reboot than to try to recover.
>
> I've found only one case in which it would be interesting to try to recover,
> it's when the user sees his host going down, and first wants to get the dump,
> and after that, he'd like to try to unmount his filesystems, but... it's too
> late. People must know well that by pressing Alt-SysRq-D, they won't be able
> to get back.
Writing "to recover" I meant to start the boot loader, which might in
turn dump the memory to swap, for example, just as it's done by OSes for
non-ia32 platforms.
> > In fact what we really need is a code that means "initialize all hardware
> > but leave memory intact". PC BIOSes haven't got such an option.
>
> That was my problem, and that's why I have to redo most of the hardware init
> at reset time. Moreover, I've noticed that under 2.3.5, my patches has some
> trouble with floppies: I get an error 4 (sector not found) when trying to
> read and/or write to them. I haven't verified yet, but would it be possible
> that some memory has been intentionnaly modified by the kernel (eg: 0:0x78),
> or should I investigate in other ways ?
You still are not sure all components are back to whatever settings BIOS
would like to use. Note that for the case of a floppy you might need to
set up some values within BIOS data area, not only interrupt vectors.
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/