http://bugme.osdl.org/show_bug.cgi?id=328
Summary: The computer seems to hang after the kernel has
uncompressed and starts to boot.
Kernel Version: 2.5.59
Status: NEW
Severity: normal
Owner: [email protected]
Submitter: [email protected]
Distribution: RedHat 8.0
Hardware Environment: Acer Aspire 1300 laptop
Software Environment: RedHat 8.0, GCC 3.2, LILO
Problem Description: When I have compiled the kernel without problems and
restart the computer the only two lines that are printed are:
Booting 2.5.59
Uncompressing the kernel, Ok booting the kernel
then there is no more text printed out and the keyboard do not work. But I
can see some activity on the harddisk for about 10 seconds. When I reset
the computer fsck is run because the disk was not cleanly unmounted. It
seems like the system can almost boot but I can't see anything on the
screen.
On Sat, 8 Feb 2003, Martin J. Bligh wrote:
>
> http://bugme.osdl.org/show_bug.cgi?id=328
>
> Summary: The computer seems to hang after the kernel has
> uncompressed and starts to boot.
> Kernel Version: 2.5.59
> Status: NEW
> Severity: normal
> Owner: [email protected]
> Submitter: [email protected]
>
>
> Distribution: RedHat 8.0
> Hardware Environment: Acer Aspire 1300 laptop
> Software Environment: RedHat 8.0, GCC 3.2, LILO
> Problem Description: When I have compiled the kernel without problems and
> restart the computer the only two lines that are printed are:
>
> Booting 2.5.59
> Uncompressing the kernel, Ok booting the kernel
>
> then there is no more text printed out and the keyboard do not work. But I
> can see some activity on the harddisk for about 10 seconds. When I reset
> the computer fsck is run because the disk was not cleanly unmounted. It
> seems like the system can almost boot but I can't see anything on the
> screen.
I began to see this bug this weekend myself. I'm not sure of the cause,
but it can be worked around by configuring the kernel for built-in (not
modular) support of virtual terminals (CONFIG_VT) and support for console
on virtual terminals (CONFIG_VT_CONSOLE).
On Sat, Feb 08, 2003 at 03:00:43PM -0600, Thomas Molina wrote:
> I began to see this bug this weekend myself. I'm not sure of the cause,
> but it can be worked around by configuring the kernel for built-in (not
> modular) support of virtual terminals (CONFIG_VT) and support for console
> on virtual terminals (CONFIG_VT_CONSOLE).
Maybe unrelated, but there is some really ugly code in
char_dev.c:get_chrfops().
There, if one needs a character device that is not present
a request_module("char-major-%d") is done.
However, if the character device has TTY_MAJOR or TTYAUX_MAJOR
and a driver for this major is requested, and we already have
one, but it is the wrong one, then we also do the request_module.
Yecch.
The reason is of course that entirely different drivers cover
different fragments of the major space (4,1 is /dev/tty1 and
4,65 is /dev/ttyS1)
So, I could imagine that if one has neither module, and needs
one, get_chrfops() loads the wrong one. Speculation.
Andries