.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
> .config: http://www0.org/config
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.
michaelm said:
> That is on a p1 150MMX 32MB PC, specifically an IBM ThinkPad 560E. It
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/
Charles Lepple wrote:
>michaelm said:
>
>
>>That is on a p1 150MMX 32MB PC, specifically an IBM ThinkPad 560E. It
>>
>>
>
>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
>
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]>
Samuel Flory wrote:
> Charles Lepple wrote:
>
>>
>> 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
>>
> 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.
>
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]>
On Mon, 21 Jul 2003, Samuel Flory wrote:
> 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.
Before you can select those options in menuconfig you need to set
CONFIG_INPUT to be y
On Mon, Jul 21, 2003 at 05:42:51PM -0700, Samuel Flory wrote:
>
> 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
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,
On Mon, 21 Jul 2003, Samuel Flory wrote:
> 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.
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
--- drivers/char/Kconfig 14 Jul 2003 09:22:00 -0000 1.1.1.1
+++ drivers/char/Kconfig 22 Jul 2003 08:08:26 -0000
@@ -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
On Tue, Jul 22, 2003 at 11:50:47AM +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 21 Jul 2003, Samuel Flory wrote:
>
> > 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.
>
> 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.
Fine with me.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
> > 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.
>
> 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
> --- drivers/char/Kconfig 14 Jul 2003 09:22:00 -0000 1.1.1.1
> +++ drivers/char/Kconfig 22 Jul 2003 08:08:26 -0000
> @@ -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
What about the keyboard being built in. People will still not set that.
The proper solution would be to alter the build system on a default build
to scan the .config file for CONFIG_PC_KEYB, CONFIG_MOUSE, CONFIG_BUSMOUSE,
CONFIG_PSMOUSE etc. Then convert them to what is needed for 2.6.X. The same
for framebuffer console stuff. We can scan for CONFIG_FB and if
CONFIG_FRAMEBUFFER_CONSOLE is not present set it. We only would need to do
this for a default build.
Roman Zippel wrote:
>Hi,
>
>On Mon, 21 Jul 2003, Samuel Flory wrote:
>
>
>
>> 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.
>>
>>
>
>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.
>
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]>
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.
> The proper solution would be to alter the build system on a default build
> to scan the .config file for CONFIG_PC_KEYB, CONFIG_MOUSE, CONFIG_BUSMOUSE,
> CONFIG_PSMOUSE etc. Then convert them to what is needed for 2.6.X. The same
> for framebuffer console stuff. We can scan for CONFIG_FB and if
> CONFIG_FRAMEBUFFER_CONSOLE is not present set it. We only would need to do
> this for a default build.
If you really want that do it a a separate make updateconfig script instead
of bloating make oldconfig.
On Tue, Jul 22, 2003 at 07:17:46PM +0100, Christoph Hellwig wrote:
>
> 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
On Tue, Jul 22, 2003 at 11:00:31AM -0700, Samuel Flory wrote:
> 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!!
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
Sam Ravnborg wrote:
>On Tue, Jul 22, 2003 at 07:17:46PM +0100, Christoph Hellwig wrote:
>
>
>>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/
> 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.
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.
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.