doing a full (through-BIOS) reboot?

[Ivan Shmakov]

I've observed this behavior in Debian Wheezy, but I guess that
the problem is more related to the newer kernels that to any
particular distribution. Thus, I'm cross-posting to both
a.o.linux and a.o.l.debian.

The problem is that reboot(8) currently does a “shortened”
reboot. IOW, only the kernel gets restarted. However, it's
occasionally necessary to do a “full” reboot, starting with
BIOS POST and proceeding then to bootloader. In particular,
this is necessary should one wish to change bootloader settings,
or CMOS Setup settings, or simply to load another OS in dual-
and multi-system setups.

The question is: how do I do such a “full” reboot? Is
poweroff(8) and hardware reset the only option?

Another problem is that with the kernel mode setting feature
being active, the screen gets garbled, as the re-initializing
kernel assumes a VGA text mode, while it's in fact a graphics
mode. Thus, the initial (prior to the loading of the respective
framebuffer module) kernel messages couldn't be read.

Is there a way to force switching to a text mode either before
reboot, or at the early stage of kernel's initialization?

TIA.

--
FSF associate member #7257

[Shadow Raider]

I use Linux Mint 11 (it's a full driver and plugin ubuntu based), and when I reboot, it reboots properly. Some maniboards make a quick reboot if they are like to reboot in less an hour from the last power on, since there are no hardware changes.
This is a BIOS aspect, not Linux or Window or Mac.
Second question: yes, there is a way. Probably you are using GRUB boot loader. You have to modify the grub configuration file (grub.cfg, wherever your distro put it), and remove all graphic options, like (bootsplash, silent, etc..) in the line of your Linux boot option.

[Ivan Shmakov]

>>>>> Shadow Raider <anger...@gmail.com> writes:

> I use Linux Mint 11 (it's a full driver and plugin ubuntu based), and
> when I reboot, it reboots properly. Some maniboards make a quick
> reboot if they are like to reboot in less an hour from the last power
> on, since there are no hardware changes.

> This is a BIOS aspect, not Linux or Window or Mac.

Thanks, but I doubt so. Would the control be passed to BIOS, it
would then load and start a bootloaded (IOW, GRUB in my case.)
However, it is /not/ started at all.

Moreover, Debian Squeeze reboots properly on the very same
hardware.

> Second question: yes, there is a way. Probably you are using GRUB
> boot loader. You have to modify the grub configuration file
> (grub.cfg, wherever your distro put it), and remove all graphic
> options, like (bootsplash, silent, etc..) in the line of your Linux
> boot option.

My question was not on how to prevent the Linux framebuffer
implementation from ever touching the mode, but on how to
enforce a sane behavior when it does.

For the former, I've found that I have to add “i915.modeset=0”
to the kernel's command line. However, there're rumors that the
Linux Kernel Mode Setting (KMS) feature will become mandatory
for all the future versions of the X.org X server.

[Richard Kettlewell]

Ivan Shmakov <iv...@gray.siamics.net> writes:
> I've observed this behavior in Debian Wheezy, but I guess that
> the problem is more related to the newer kernels that to any
> particular distribution. Thus, I'm cross-posting to both
> a.o.linux and a.o.l.debian.
>
> The problem is that reboot(8) currently does a “shortened”
> reboot. IOW, only the kernel gets restarted. However, it's
> occasionally necessary to do a “full” reboot, starting with
> BIOS POST and proceeding then to bootloader. In particular,
> this is necessary should one wish to change bootloader settings,
> or CMOS Setup settings, or simply to load another OS in dual-
> and multi-system setups.
>
> The question is: how do I do such a “full” reboot? Is
> poweroff(8) and hardware reset the only option?

Do you by any chance have reboot=warm on the kernel command line?

--
http://www.greenend.org.uk/rjk/

[Ivan Shmakov]

>>>>> Richard Kettlewell <r...@greenend.org.uk> writes:
>>>>> Ivan Shmakov <iv...@gray.siamics.net> writes:

[…]

>> The problem is that reboot(8) currently does a “shortened” reboot.
>> IOW, only the kernel gets restarted.

[…]

> Do you by any chance have reboot=warm on the kernel command line?

Not at all:

$ fmt -w72 < /proc/cmdline
BOOT_IMAGE=/vmlinuz-2.6.39-2-amd64
bootfrom=/dev/mapper/vgx4e28feff-lvx4e29b08f ro boot=live config debug
ip=frommedia hostname=x4e29b08f.dummy.am-1.org locales=C username=live
nox11autologin i915.nomodeset=1
$

(But it still may have become a default for newer Debian
kernels.)

Moreover, from a quick Google search, I've got an impression
that reboot=warm is (or was?) used to make the kernel initiate a
reboot by JMP to one of the BIOS initialization vectors
(0xFFFF0, IIUC) instead of pulsing the CPU's RESET line (which
is reboot=cold.)

The issue I'm having is that BIOS is seemingly excluded from the
process altogether.

[Richard Kettlewell]

Ivan Shmakov <iv...@gray.siamics.net> writes:

>>>>>> Richard Kettlewell <r...@greenend.org.uk> writes:
>>>>>> Ivan Shmakov <iv...@gray.siamics.net> writes:
>
> […]
>
> >> The problem is that reboot(8) currently does a “shortened” reboot.
> >> IOW, only the kernel gets restarted.
>
> […]
>
> > Do you by any chance have reboot=warm on the kernel command line?
>
> Not at all:
>
> $ fmt -w72 < /proc/cmdline
> BOOT_IMAGE=/vmlinuz-2.6.39-2-amd64
> bootfrom=/dev/mapper/vgx4e28feff-lvx4e29b08f ro boot=live config debug
> ip=frommedia hostname=x4e29b08f.dummy.am-1.org locales=C username=live
> nox11autologin i915.nomodeset=1
> $
>
> (But it still may have become a default for newer Debian
> kernels.)

It's not the default in the upstream kernel and I don't see anything
about it in the Debian kernel changelog.

> Moreover, from a quick Google search, I've got an impression
> that reboot=warm is (or was?) used to make the kernel initiate a
> reboot by JMP to one of the BIOS initialization vectors
> (0xFFFF0, IIUC) instead of pulsing the CPU's RESET line (which
> is reboot=cold.)

As far as I can see the effect of reboot=warm is to set a word that
tells the BIOS to bypass some of its startup steps.

> The issue I'm having is that BIOS is seemingly excluded from the
> process altogether.

I can't see any code in the kernel's reboot implementation that would
achieve that effect, though I've not done more than skim-read it.

Next guess. Do you have kexec-tools installed?

--
http://www.greenend.org.uk/rjk/

[Ivan Shmakov]

>>>>> Richard Kettlewell <r...@greenend.org.uk> writes:
>>>>> Ivan Shmakov <iv...@gray.siamics.net> writes:

[…]

>> Moreover, from a quick Google search, I've got an impression that
>> reboot=warm is (or was?) used to make the kernel initiate a reboot
>> by JMP to one of the BIOS initialization vectors (0xFFFF0, IIUC)
>> instead of pulsing the CPU's RESET line (which is reboot=cold.)

> As far as I can see the effect of reboot=warm is to set a word that
> tells the BIOS to bypass some of its startup steps.

Well, most probably, as per [1] (which, however, dates back to
2003.)

[1] http://www.x86-64.org/pipermail/discuss/2003-May/003440.html

>> The issue I'm having is that BIOS is seemingly excluded from the
>> process altogether.

> I can't see any code in the kernel's reboot implementation that would
> achieve that effect, though I've not done more than skim-read it.

> Next guess. Do you have kexec-tools installed?

Indeed, I do, along with coldreboot(8). Thanks!

[Richard Kettlewell]

Ivan Shmakov <iv...@gray.siamics.net> writes:
> Richard Kettlewell <r...@greenend.org.uk> writes:

>> As far as I can see the effect of reboot=warm is to set a word that
>> tells the BIOS to bypass some of its startup steps.
>
> Well, most probably, as per [1] (which, however, dates back to
> 2003.)
>
> [1] http://www.x86-64.org/pipermail/discuss/2003-May/003440.html

You'd be better off looking at the actual code, not at a mailing list
message from most of a decade ago!

--
http://www.greenend.org.uk/rjk/

[Jasen Betts]

On 2011-10-25, Ivan Shmakov <iv...@gray.siamics.net> wrote:

> I've observed this behavior in Debian Wheezy, but I guess that
> the problem is more related to the newer kernels that to any
> particular distribution. Thus, I'm cross-posting to both
> a.o.linux and a.o.l.debian.

> The problem is that reboot(8) currently does a “shortened”
> reboot. IOW, only the kernel gets restarted. However, it's
> occasionally necessary to do a “full” reboot, starting with
> BIOS POST and proceeding then to bootloader. In particular,
> this is necessary should one wish to change bootloader settings,
> or CMOS Setup settings, or simply to load another OS in dual-
> and multi-system setups.
>
> The question is: how do I do such a “full” reboot? Is
> poweroff(8) and hardware reset the only option?

those commands are all faces of init(8)

AIUI Debian is moving away from sysv-init to some other init.
"dependency based booting" is a very vague term not sure what it
really means. ICBW


The bios itself provides two reboot mechanisms, which one is used
depends on a magic value (0x12,0x34 IIRC) being in a specific location
(0x000040?? sowmwhere IIRC) the magic value causes a "soft" reboot which
doesn't give all the POST stuff. full details in Ralf Browns interrupt
list.

> Another problem is that with the kernel mode setting feature
> being active, the screen gets garbled, as the re-initializing
> kernel assumes a VGA text mode, while it's in fact a graphics
> mode. Thus, the initial (prior to the loading of the respective
> framebuffer module) kernel messages couldn't be read.
>
> Is there a way to force switching to a text mode either before
> reboot, or at the early stage of kernel's initialization?

"VGA=3" used to give 80x25 colour text mode in a the very early part of
the bootup. have't tried recently, this video mode was selected by a
BIOS call (int 0x10,AX=0x0003 IIRC).


--
⚂⚃ 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---

[Jasen Betts]

On 2011-10-25, Ivan Shmakov <iv...@gray.siamics.net> wrote:

last I heard asserting the RESET line was am 80286 trick to exit from
protected mode, and modern CPUS could do all that was needed without
assisitance from the keyboard controller. (this ande more also covered
by Ralf Brown's document)

[Peter Köhlmann]

Jasen Betts wrote:

> On 2011-10-25, Ivan Shmakov <iv...@gray.siamics.net> wrote:
>>>>>>> Richard Kettlewell <r...@greenend.org.uk> writes:
>>>>>>> Ivan Shmakov <iv...@gray.siamics.net> writes:
>
>> Moreover, from a quick Google search, I've got an impression
>> that reboot=warm is (or was?) used to make the kernel initiate a
>> reboot by JMP to one of the BIOS initialization vectors
>> (0xFFFF0, IIUC) instead of pulsing the CPU's RESET line (which
>> is reboot=cold.)

No, that is a warm boot. Cold boot would force also mem-test and the
discovery of the connected hardware

>> The issue I'm having is that BIOS is seemingly excluded from the
>> process altogether.
>
> last I heard asserting the RESET line was am 80286 trick to exit from
> protected mode, and modern CPUS could do all that was needed without
> assisitance from the keyboard controller. (this ande more also covered
> by Ralf Brown's document)
>

It *was* a trick needed by 80286. Although later BIOS used a software trick:
They let the processor run into a triple fault, which also resets the
processor. That was faster by several miliseconds (which even then was eons
in processor time)
Starting from 80386 you could reset to "real mode" by using a opcode. That
was faster, since the BIOS did not need to run through several hundred
instructions to get to the real mode entry to continue

[Richard Kettlewell]

Jasen Betts <ja...@xnet.co.nz> writes:
> those commands are all faces of init(8)
>
> AIUI Debian is moving away from sysv-init to some other init.
> "dependency based booting" is a very vague term not sure what it
> really means. ICBW

It means that the order in which boot services are started is determined
at runtime by analysing the dependencies between the services, rather
than being statically configured.

The Debian implementation lies in the scripts invoked by init, not init
itself, which remains the traditional sysv-style init.

--
http://www.greenend.org.uk/rjk/

[Ivan Shmakov]

>>>>> Jasen Betts <ja...@xnet.co.nz> writes:
>>>>> On 2011-10-25, Ivan Shmakov <iv...@gray.siamics.net> wrote:

[…]

> The bios itself provides two reboot mechanisms, which one is used
> depends on a magic value (0x12,0x34 IIRC) being in a specific location
> (0x000040?? sowmwhere IIRC) the magic value causes a "soft" reboot which
> doesn't give all the POST stuff.

0x1234 (which is 0x34, 0x12 on LSB-first systems) stored at
0x00472 (absolute), as per P. Norton and R. Wilton, 1988.

> full details in Ralf Browns interrupt list.

[…]

>> Is there a way to force switching to a text mode either before
>> reboot, or at the early stage of kernel's initialization?

> "VGA=3" used to give 80x25 colour text mode in a the very early part
> of the bootup.

IIRC, it was used to be vga=3 (in lower case)?

Definitely worth trying (and probably adding to
/etc/default/kexec), thanks!

> have't tried recently, this video mode was selected by a BIOS call
> (int 0x10,AX=0x0003 IIRC).

That's correct.

[Ivan Shmakov]

>>>>> Ivan Shmakov <iv...@gray.siamics.net> writes:

[Removing news:alt.os.linux.debian, as I believe that the
solutions below are applicable to the other systems based on
Linux just as well.]

[…]

> Another problem

[… with Debian's kexec-tools package, which makes the system
perform a “shortened” reboot, completely bypassing BIOS.]

> is that with the kernel mode setting feature being active, the screen
> gets garbled, as the re-initializing kernel assumes a VGA text mode,
> while it's in fact a graphics mode. Thus, the initial (prior to the
> loading of the respective framebuffer module) kernel messages
> couldn't be read.

So far, I've found two ways to disable the Kernel mode-setting
feature, enabled by default in recent kernels shipped with
Debian (from 6.0 “Squeeze” onwards.)

These are outlined below.


Background

The Kernel mode-setting feature, somewhat recently added to the
Linux kernel, is intended to finally supersede the user-space
video adapter initialization (as historically done by an X.org
server), by the one residing in kernel-space.

The advantages of such a move are, firstly, that the kernel
becomes fully aware of the video mode changes, and is thus able
to save and restore the video mode when the system is suspended
or goes into hibernation. Secondly, it becomes possible to
switch to the graphics mode early in the boot process and never
change it afterwards.

The disadvantages are that the virtual terminals emulated in the
graphics mode are more flexible, and thus require additional
configuration. In particular, while the VGA text modes (as well
as the EGA and CGA ones) allow 8-pixel wide characters
(sometimes enlarged to 9-pixel wide by the video adapter itself)
exclusively, and are by default programmed to the 640-pixels
width text mode (thus giving the familiar 80-column text mode,
which is conventionally used since the age of teletypes), the
graphics mode selected by the KMS feature has typically much
higher resolution, resulting in, when using the same 8-pixel
wide font, in barely readable font.

Also, I haven't checked it as of yet, but I presume that the KMS
feature relies on the EDID [1] information available from the
modern video displays through the video adapter.

This information, however, may not be available if using either
a legacy hardware, or a Keyboard-Video-Mouse (KVM) switch, thus
resulting in an unsuitable video mode being selected. It could
be especially unfortunate if using a LCD display having an
unaligned native resolution (such as 1280x1024 LCD vs. the
1024x768 KMS default.)

Moreover, I know of no tools to change the video mode once the
KMS-supporting kernel module is initialized, while the existing
tools (such as SVGATextMode(8), vbetool(8), and fbset(1))
preasumably won't work with KMS.

The disadvantages stated above have provoked me to search for a
way to disable KMS entirely.

[1] http://en.wikipedia.org/wiki/EDID


Using a module option

The first one is to pass an appropriate option to the kernel's
module in charge. The option is modeset=0, and it could be
specified via either as a kernel command line argument (as:
MODULE.modeset=0), or a /etc/modprobe.d/ .conf file.

The modules supporting such an option (for the kernel shipped
with a recent Debian stable) are: i915, nouveau, radeon; as per
the following Shell code:

$ uname -r
2.6.32-5-amd64
$ cat < kernel-gpu-modeset.sh
#!/bin/bash
if [ $# -le 0 ] ; then
set -- /lib/modules/"$(uname -r)"/kernel/drivers/gpu/
fi
find -- "$@" -type f -name \*.ko \
| while read f ; do
/sbin/modinfo "$f" | grep -qF -- modeset: \
|| continue
printf %s\\n "$(basename "$f" .ko)"
done
$ bash kernel-gpu-modeset.sh | fmt -w72
i915 nouveau radeon
$

An example /boot/grub/grub.cfg line (tested) may be like:

linux /vmlinuz-2.6.32-5-amd64 root=/dev/mapper/vgsys-lvroot ro i915.modeset=0

(But please note that Debian's grub.cfg is autogenerated, and
such a kernel command line argument should instead be added to
/etc/default/grub.)

An example /etc/modprobe.d/disable-kms-radeon.conf (untested)
could then be:

options radeon modeset=0


Using blacklist

An alternative solution is to blacklist all the GPU drivers
shipped with the kernel. A corresponding /etc/modprobe.d/ file
could easily be generated with the following Shell code:

#!/bin/bash
find /lib/modules/2.6.32-5-amd64/kernel/drivers/gpu/ \
-type f -name \*.ko -printf %f\\n \
| sed -e '/\(.*\)\.ko$/!d; s//blacklist \1/' \
| LC_ALL=C sort -u

This effectively prevents the kernel (modprobe(8)? udev(7)?)
module autoloading mechanism from ever using these modules,
unless required to fulfil a dependency of some other module. As
a (wanted) side effect, KMS is also disabled.


Conclusion

Please note that both of the solutions are “fragile”, in the
sense that should the kernel upgrade bring into one's system a
module suitable for one's video adapter, the KMS will be back.
Thus, it's advisable to check if the module list has changed,
and update the blacklist (or module options) as necessary, on
each major kernel upgrade.

There're also some rumors that KMS may at one time become
necessary for running the X.org X window server. I could only
hope that the VESA driver (which I'm proud to use) will not be
removed from the distribution.

That being said, I still believe that for certain systems, such
as the servers which only occasionally get connected to a video
display (for maintenance purposes), the disadvantages of the
Kernel mode-setting could easily outweight its advantages.

This concludes my quest for the solution of the “KMS problem”
[2, 3].

[2] news:86ehzjv...@gray.siamics.net
[3] news:8662mtx...@gray.siamics.net (Gmane)

> Is there a way to force switching to a text mode either before
> reboot, or at the early stage of kernel's initialization?

It's my understanding that the vga= kernel command line option
(as in: vga=3, which was suggested to solve the issue) requires
switching to the (IA-32, AMD64) real mode, and thus isn't
available when using either kexec(8) or GRUB 2.

The solution is still sought.

[Ivan Shmakov]

Indeed, I've used to keep some recent Linux source around, but
these days I'm somewhat short on time.