Hi there,
We are using an old Gigabyte motherboard with latest BIOS release, K6-2
350 processor and Sis5591 chipset with onboard USB as a fileserver using
Mandrake 8.1 (Linux 2.4.8-mdk20).
The problem I have is that when I set the "Plug and Play OS" option in
the BIOS to yes, the system becomes very unreliable and most times never
gets as far as allowing me to login before 'oopsing'.
Similarly, when I enable USB in the BIOS using usb-ohci and try to use our
ADSL Speedtouch modem (using Benoit's driver, not the kernel patch) the
kernel will oops again whilst trying to make a connection using PPP.
I have downloaded the latest 2.4.13 kernel and compiled the source to see
if this solves the problem, but exactly the same problem occurs under
2.4.13.
I think that there may be something wrong in the BIOS code which handles
the SiS chipset as we have tried the same setup on another Intel chipset
machine and both the PnP OS option and USB work fine.
Incidentally whilst compiling the 2.4.13 kernel to test, with PnP set to
'No', I encountered many segment faults which required me to restart gcc
- can't find a trace of one of these at the moment, but I may be able to
dig out something if someone would find them useful. So maybe this is just
a problem that is enhanced by using PnP in the BIOS?
I have included the 2.4.8 oops traces after running through ksymoops as
detailed in the Documentation folder. The first section contains the
'oops' which occurs when PnP OS is set to 'Yes' in the BIOS. The second
section contains the 'oops' which occur when I enable USB and try to
connect via PPP (I have no other USB devices to test with). I hope this is
the correct thing to do.
If anyone can help, please email me off-list and I will try and do my
best to assist - I do not know enough about this side of things to know
what to do next.
Cheers,
Mark.
On Thursday, November 15, 2001, at 10:39 , Mark Cave-Ayland wrote:
> Incidentally whilst compiling the 2.4.13 kernel to test, with
> PnP set to
> 'No', I encountered many segment faults which required me to
> restart gcc
Run memtest86. That sounds like bad memory.
Also, some Gigabyte boards in my experience have been extremely
unhappy when the multiple DIMMs on the board are not identical.
The reason you are having these problems is this:
To set the "Plug and Play OS" firmware option to "yes"
is to tell the firmware not to configure any ISA-PnP-
configurable devices except for those required
to boot the OS.
When you do this, Linux oopses at boot time because some
of your devices are in an uninitialized state when Linux
tries to access them.
There are several solutions to this, the more straightforward
of which is to un-set the "Plug and Play OS" option.
Linux sets the "PnP OS" bootflag when it starts; then
subsequent boots of Linux (or other operating systems)
will occur without the firmware configuring devices. I
believe that this is a Bad Idea. First of all, the
reason for setting the bootflag seems to be the belief
that it speeds up the boot process; but I think that
what takes a significant amount of time is POST, not
configuration, and POST is disabled using an entirely
different bootflag. Second, even if PnP configuration
takes time, it's safer than not configuring, as your
experience proves. Configured devices can always be
reconfigured, but unconfigured devices cause oopses.
Leaving the "PnP OS" bootflag unset should be the
default option. Third, it makes no sense for Linux
to set the bootflag anyway, because it cannot possibly
know what operating system will boot *next* time!
A further problem is that the bootflag-setting code in
arch/i386/kernel/bootflag.c is compiled in conditionally
upon the definition of CONFIG_PNPBIOS. This is wrong.
It is not the pnpbios driver that makes Linux a PnP OS.
If anything, it is the isa-pnp driver that makes it so---
i.e., that gives Linux the ability to do what the BIOS
doesn't do when the "PnP OS" bootflag is set, namely,
configure devices by PnP methods. Indeed, if one is
making use of the pnpbios driver it means that the OS
is going to use the firmware to configure devices and
so presumably is *not* a PnP OS!
I presented these arguments in an earlier thread, but
the reply I got was that if I don't like the way the
flag is set then I should clear it myself after Linux
boots. Unfortunately I have no utility program that can
do that. Once such a program is available, Linux
should cease to futz with the PnP OS bootflag and leave
it up to the user to decide if s/he wants to set it.
I worked around the problem by masking the PnP OS
boot flag; my firmware setup program gives me the
option to do that.
Thomas Hood