Mailing List Archive

Peter Bartke wrote:
>
> If vga=ask is given I can interactively decide on the video mode. After
> giving the video mode, eg mode number 1 an pressing RET, cursor goes to
> the next line. From this point in time there is no input possible and no
> sign of running stage 2 is to be seen.
>

Interesting. This implies that the failure is very early in stage 2, or
during the transition from stage 1 (setup) to stage 2 (decompression.)
This is also the point at which transition happens from 16-bit real mode
to 32-bit protected mode.

This could imply either that something is going on clobbering high
memory, or the protected mode transition failed. Either is a Very Bad
Thing.

Are you using the syslinux menu system at all? If so, does it work on
this machine?

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Peter Bartke wrote:
>
> These really time consuming tests led to the conclusion that the
> problem is determined by three conditions:
> - the (eventually buggy?) hard- and firmware of my P4/ASUS PGGD2 computer
> - patched Kernel 2.6.21.5 from Slax RC4/5/6
> - Boot from CD by syslinux with isolinux.bin
> If one or more of these conditions are not met, the CD boots.
>

By the way, I really appreciate your assistance in debugging this.
These kinds of things are always incredibly nasty.

Could you send me your isolinux.cfg, and also let me know what version
of isolinux this uses?

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin schrieb am Sun, Jul 29, 2007 at 09:04:12PM -0700:
>
> Interesting. This implies that the failure is very early in stage 2, or
> during the transition from stage 1 (setup) to stage 2 (decompression.)
> This is also the point at which transition happens from 16-bit real mode
> to 32-bit protected mode.
>

Can you imagine a sitation that at this point initrd.gz, a file needed
to be uncompressed to ramdisk, ist not found?

> This could imply either that something is going on clobbering high
> memory, or the protected mode transition failed. Either is a Very Bad
> Thing.

I cannot believe that this happens. Remember that the same vmlinuz and
initrd.gz start with eltorito from grub. isolinux would be made
responsible for doing something with high memory. No.

>
> Are you using the syslinux menu system at all? If so, does it work on
> this machine?
>

As I understand it, the isolinux.bin uses isolinux.cfg to show the
content of the latter file by means of vesamenu.c32 on linux
framebuffer. This works perfectly.
Maybe that's not the whole story? I didn't think syslinux is in the way
when you boot by CD.

Booting by syslinux from USB would be the next step in testing Slax,
when CD boot works. It's a little bit clumsy with this BIOS, you have to
press F8 early to get to the boot menu. Sorry, no experience with
syslinux on USB yet.


Peter

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin schrieb am Sun, Jul 29, 2007 at 09:15:15PM -0700:
>
> Could you send me your isolinux.cfg, and also let me know what version
> of isolinux this uses?

I will send these files by direct mail, not to mess up the mailing list.
Slax 6.0 is based on Slackware current, which is Slackware 12.0 now for
RC4, RC5 and RC6. It uses syslinux-3.36. I also tried the isolinux.bin
from slackware 11 (syslinux-2.13) and the newest one from your site,
syslinux-3.51.

Peter

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

I made a BIOS update for the motherboard ASUS P5GD2 from version 1005 to
latest 1007 (2/2006) and tried to reconstruct all the BIOS settings from
memory as before.

The problem remains.

Is there a kernel debug mode? Could I compile kernel 2.6.21.5 (with
Slax filesystem patches) to make a `vmlinuz' which tells us what it is
doing? Or could you suggest files where we could insert `early_printk'
messages at definite places?

Peter

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Peter Bartke wrote:
> I made a BIOS update for the motherboard ASUS P5GD2 from version 1005 to
> latest 1007 (2/2006) and tried to reconstruct all the BIOS settings from
> memory as before.
>
> The problem remains.
>
> Is there a kernel debug mode? Could I compile kernel 2.6.21.5 (with
> Slax filesystem patches) to make a `vmlinuz' which tells us what it is
> doing? Or could you suggest files where we could insert `early_printk'
> messages at definite places?
>

early_printk() doesn't exist yet at the point where your stuff is
failing. With the 2.6.23-rc1 kernel you can put printf() in the setup
code in the kernel, but in earlier versions that mean hacking assembly.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.