Linux 2.4.24-pre1: Instant reboot

Linux 2.4.24-pre1: Instant reboot

[Kristofer T. Karas]

Hi Marcelo, et al,

Just wanted to report an instantaneous reboot problem with 2.4.24-pre1.

I don't even see any printk's to the screen; as soon as LILO is finished 
loading the new kernel, the screen blanks and the BIOS goes through its 
boot sequence again.  Since I seem to be the only one reporting this to 
LKML, I suspect I'll have to back out various patches to try to track 
this down. :-P

I'm using the same .config as in 2.4.23 with new questions left at their 
defaults (e.g. XFS=n, OOM_KILLER=n).  I've had no problems with this 
otherwise rock-stable platform for all varieties of 2.4.x, save for some 
early USB EHCI issues long ago.

At work now, so I don't have a full .config handy, but:
* Slackware 8.1 based; glibc 2.2.5; gcc 2.95.3
* Soltek SL-75DRV2 (UP, Athlon XP 1700, VIA KT266A [VT8366A/VT8233])
* Root = ext3 on IDE partition
* DevFS, DevPTS, IDE-SCSI=cdrom0, USBStorage, USB EHCI, VFAT
* RadeonFB, IPTables, Realtek-8139
Everything else in .config is pretty vanilla (e.g. Linus defaults or 
thereabouts).

Kris

Re: Linux 2.4.24-pre1: Instant reboot

[Richard B. Johnson]

On Tue, 16 Dec 2003, Kristofer T. Karas wrote:

> Hi Marcelo, et al,
>
> Just wanted to report an instantaneous reboot problem with 2.4.24-pre1.
>
> I don't even see any printk's to the screen; as soon as LILO is finished
> loading the new kernel, the screen blanks and the BIOS goes through its
> boot sequence again.  Since I seem to be the only one reporting this to
> LKML, I suspect I'll have to back out various patches to try to track
> this down. :-P
>
> I'm using the same .config as in 2.4.23 with new questions left at their
> defaults (e.g. XFS=n, OOM_KILLER=n).  I've had no problems with this
> otherwise rock-stable platform for all varieties of 2.4.x, save for some
> early USB EHCI issues long ago.
>
> At work now, so I don't have a full .config handy, but:
> * Slackware 8.1 based; glibc 2.2.5; gcc 2.95.3
> * Soltek SL-75DRV2 (UP, Athlon XP 1700, VIA KT266A [VT8366A/VT8233])
> * Root = ext3 on IDE partition
> * DevFS, DevPTS, IDE-SCSI=cdrom0, USBStorage, USB EHCI, VFAT
> * RadeonFB, IPTables, Realtek-8139
> Everything else in .config is pretty vanilla (e.g. Linus defaults or
> thereabouts).
>
> Kris
>

What CPU did you compile it for? The reboot stuff looks like
a CPU reset because of a triple fault, i.e., using CMOV when
there isn't any, etc. Try something more generic and see if
it boots.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Linux 2.4.24-pre1: Instant reboot

[Matthias Andree]

On Tue, 16 Dec 2003, Kristofer T. Karas wrote:

> Hi Marcelo, et al,
> 
> Just wanted to report an instantaneous reboot problem with 2.4.24-pre1.
> 
> I don't even see any printk's to the screen; as soon as LILO is finished 
> loading the new kernel, the screen blanks and the BIOS goes through its 
> boot sequence again.  Since I seem to be the only one reporting this to 
> LKML, I suspect I'll have to back out various patches to try to track 
> this down. :-P

I've seen this, too, with XFS=y and OOM_KILLER=n, but haven't yet gotten
around to "make clean" and try again with a fresh build (I had 2.4.23
code traces in the .o files). I also have device-manager 1.00.07
patched in (no rejects, no manual edits necessary). My version was
pulled from BK, I can look up the latest ChangeSet I pulled from the
official kernel if necessary. I'll now try a "make clean" build after
yet another BK pull.

> At work now, so I don't have a full .config handy, but:
> * Slackware 8.1 based; glibc 2.2.5; gcc 2.95.3
> * Soltek SL-75DRV2 (UP, Athlon XP 1700, VIA KT266A [VT8366A/VT8233])
> * Root = ext3 on IDE partition
> * DevFS, DevPTS, IDE-SCSI=cdrom0, USBStorage, USB EHCI, VFAT
> * RadeonFB, IPTables, Realtek-8139

SuSE Linux 8.2, gcc 3.3.1, Gigabyte 7ZX-R (VIA KT133 + Promise 20265R),
root ext3 on SCSI (sym53c8xx_2), no devfs, no usb storage, vfat, xfs.

However, I doubt the file systems matter, the machine apparently hasn't
probed my partitions when it reboots.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

[Answer] Re: Linux 2.4.24-pre1: Instant reboot

[Kristofer T. Karas]

Short answer to my previous post on this subject:

    CONFIG_EDD=y + Athlon + VIA KT266A = triple fault on boot.

Longer answer:

Dick Johnson asked,
> What CPU did you compile it for?

Compiled 2.4.24-pre1 for Athlon/K7.  I also tried it with generic i386,
which made no difference.

Matthias Andree wrote:
> I've seen this, too, with XFS=y and OOM_KILLER=n,

If I didn't have 2 hours sleep, I would have hacked rc.sysinit to
auto-compile my linux kernel with a binary search looking for the
culprit, iterating if the BIOS rebooted an old kernel; but I was too
tired today for scriping foo.  :-)  So I did it the old fashioned way.

Turns out, after about a dozen compile/reboot loops, I narrowed it down
repeatably to the "x86 BIOS Enhanced Disk Drive support" (CONFIG_EDD)
option.  I can turn off just about every .config option, turn that one
on, and the kernel triple faults upon boot.  This is the first time that
a 2.4.x kernel has ever triple faulted on boot on my system.  As
mentioned above, CPU choice makes no difference.

Marcelo:  Perhaps have the author of whatever patch interacts with
CONFIG_EDD work a bit more on getting the patch right for various
platforms.  The (EXPERIMENTAL) feature worked just fine for me on
2.4.22...24.2.23, but the current -pre1 bombs for athlon/via_kt266a.

Kris

Re: [Answer] Re: Linux 2.4.24-pre1: Instant reboot

[Tomas Szepe]

On Dec-17 2003, Wed, 01:07 -0500
Kristofer T. Karas <ktk@enterprise.bidmc.harvard.edu> wrote:

> Short answer to my previous post on this subject:
> 
>     CONFIG_EDD=y + Athlon + VIA KT266A = triple fault on boot.

Great work, thanks for the valuable info!

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: [Answer] Re: Linux 2.4.24-pre1: Instant reboot

[Mike Fedyk]

On Wed, Dec 17, 2003 at 01:07:21AM -0500, Kristofer T. Karas wrote:
> If I didn't have 2 hours sleep, I would have hacked rc.sysinit to
> auto-compile my linux kernel with a binary search looking for the
> culprit, iterating if the BIOS rebooted an old kernel; but I was too
> tired today for scriping foo.  :-)  So I did it the old fashioned way.

I think you would have had to do it manually anyway.  Your boot didn't even
get to the point of loading userspace, so you would have been indefinately
one kernel.