2.6.0-test1 won't go further than "uncompressing" on a p1/32MB pc

.config: http://www0.org/config

That is on a p1 150MMX 32MB PC, specifically an IBM ThinkPad 560E. It will keep showing "booting the kernel, uncompressing" without going any further. There will be some disk activity for at least 5-7 minutes after that on a 5-10 seconds interval period, without change on the screen. I tried removing framebuffer support or keep it but set CONFIG_VIDEO_SELECT to 'n', but there is still the same output.

The bzimage is around 919Kb, I tried to make it as modular and small as it gets to be "usefull" since I suspect this is too old to run 2.5, but the bzimage still can't be less than 800-810 kilobytes.

-michael

First your CONFIG_INPUT is modular. You will not have keyboard support when you boot. Also no keyboard or mouse is configured. Turn them on by selecting Serio IO support. Then select i8042 chipset and then enable keyboard and mouse support. After that you need to enable CONFIG_VT in the Characters device menu. Then after that in the framebuffer menu you go into the Console menu and select Framebuffer console. Then you should be ready to go.

I just did a diff between your configuration, and that of my ThinkPad 770 (233 MHz Pentium MMX).

Note to defconfig maintainers: can these options be enabled by default on i386 (like they were in 2.4)?

Things that you might want to enable:

CONFIG_ISA=y

CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_INPUT_AT_KEYBOARD=y

CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y

You also might want to turn off Trident FB support, and turn on generic VESA support. I have had good luck with the VESA driver, but odd, irreproducible errors with the Trident code (several versions back; haven't retested).

Charles Lepple <ghz.cc!clepple>
http://www.ghz.cc/charles/

Actual the i386 defconfig does this:
[root@grendel linux-2.6.0-test1]# grep -e VT -e HW_CONSOLE -e SERIO -e INPUT_AT_KEYBOARD arch/i386/defconfig CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
[root@grendel linux-2.6.0-test1]#

However a "make oldconfig" on a 2.4 .config doesn't pick this up. In
fact it appears to be impossible to select CONFIG_VT CONFIG_VT_CONSOLE in make menuconfig.

Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <[email protected]>

Try this in 2.6.0-test1:
rm .config
make mrproper
make menuconfig

There is no option for CONFIG_VT, and CONFIG_VT_CONSOLE under
character devices in "make menuconfig.

This works:
rm .config
make mrproper
cp arch/i386/defconfig .config
make menuconfig

Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <[email protected]>

The preferred way to achieve the default configuration is to use:
make defconfig

See also "make help" for a list of more options.

Sam

Hi,

Try enabling CONFIG_INPUT.

Vojtech, how about the patch below? This way CONFIG_VT isn't hidden behind CONFIG_INPUT, but CONFIG_INPUT is selected if needed.

Index: drivers/char/Kconfig
===================================================================
RCS file: /home/other/cvs/linux/linux-2.6/drivers/char/Kconfig,v retrieving revision 1.1.1.1

diff -u -p -r1.1.1.1 Kconfig
@@ -6,7 +6,7 @@ menu "Character devices"
 
 config VT
 	bool "Virtual terminal"
-	requires INPUT=y
+	select INPUT
 	---help---
 	  If you say Y here, you will get support for terminal devices with
 	  display and keyboard devices. These are called "virtual" because you

Fine with me.

Vojtech Pavlik
SuSE Labs, SuSE CR

Why not? With this change they will get asked for keyboard support now. Now that they actually are asked we can expect them to give the proper answer.

If you really want that do it a a separate make updateconfig script instead of bloating make oldconfig.

updateconfig is definetely more acceptable than bloating oldconfig. But would we end up with lots of hacks - and where do we stop. Do we want to go the whole way back to a 2.0 .config and do an acceptable .config using:
make updateconfig

Or is this limited to 2.4 -> 2.6?

Sam

Well there are 2 issues here:

1) How to handle "make oldconfig" on 2.4 config files. Which may not be fixable in a manner that doesn't involve really ugly code.

2) That make menuconfig|xconfig on a clean 2.6 tree results in a kernel that doesn't have console support. This will be something that will come up over and over again in the future, and does not require ugly hacks to fix.

Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <[email protected]>

please drop my email from the cc line-- I'll catch up on this thread later.

thanks,

Charles Lepple <[email protected]>
http://www.ghz.cc/charles/

Instead of hacking up a oldconfig why not have the system detect old config files and refuse to build it and tell the user to start from scratch. I think this is acceptable.

In article <[email protected]>, James Simmons <[email protected]> wrote:

| 
| >   Well there are 2 issues here:
| > 
| > 1) How to handle "make oldconfig" on 2.4 config files.  Which may not be 
| > fixable in a manner that doesn't involve really ugly code.
| > 
| > 2) That make menuconfig|xconfig on a clean 2.6 tree results in a kernel 
| > that doesn't have console support.   This will be something that will 
| > come up over and over again in the future, and does not require ugly 
| > hacks to fix.
| 
| Instead of hacking up a oldconfig why not have the system detect old 
| config files and refuse to build it and tell the user to start from 
| scratch. I think this is acceptable.

I would say defconfig first, then menuconfig, but whatever. If you can't do it right, don't do it at all. The problems introduced by almost-right conversions are often harder to find than starting from default.

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

In article <[email protected]>,
Christoph Hellwig <[email protected]> wrote:

| On Tue, Jul 22, 2003 at 05:47:04PM +0100, James Simmons wrote:
| > What about the keyboard being built in. People will still not set that. 
| 
| Why not?  With this change they will get asked for keyboard support now.
| Now that they actually are asked we can expect them to give the proper
| answer.

If the user selects an Intel CPU why isn't the typical PC setup set by default? Time to stop pretending that there are enough non-PC setups to justify having these choices done manually each time, and make the PC the default Intel config.

Anyone running other is going to have to do a bunch of configs anyway.

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Now that's very confusing. So in order to enable something under the
Character devices menu you need to 1st enable something under "Input device support". Which for some reason is configured as a module? It says something that I resorted to editing .config by hand.

Is it too much to ask to make the defaults give us a working
console? Otherwise we will be answering the question of "why does screen go blank after uncompressing" for the entire 2.6 cycle!! The number of people who don't want to enable config_vt is fairly small, and they will be wanting to remove a number of our defaults any way.

Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <[email protected]>

I'm the 'beginner' that started the thread and I was wondering what *I* wanted to have in place. Well, I don't think the way the scripts work now should change, that would make an ugly newbiefication on something that works. On the other hand as already mentioned, 'if you need keyboard support at boot, then you just need to include keyboard support into the kernel' which I guess is a good way into pushing the use of some common sense. Also the problem is probably here partly because people are used to older kernel configs which brings two thoughts. Firstly, people who are compiling 2.5 are *supposed* to have some experience and secondly, people using 2.6 will eventually learn how to use the new features.

Some '*** WARNING:'s would the job without making the scripts too newbiefied IMO. Most linux end-users don't compile kernels in these days and the ones that do, prefer rawness.

- end of message

Before you can select those options in menuconfig you need to set CONFIG_INPUT to be y