On Thu, 9 Mar 2000, Peter Leif Rasmussen wrote:
> "Richard B. Johnson" wrote:
> >
> > On Thu, 9 Mar 2000, Peter Leif Rasmussen wrote:
[SNIPPED...]
> >
> > I don't understand how you could possibly have an AGP card on an i386 or
> > any PCI or USB. Perhaps you are referring to "ix86"??
> If you want to split hairs I could say I don't know what architecture your
> i686 is? One of the architectures in the standard Linux kernel tree is
> listed as "i386" (without the quotes), but there is no i686.
Was not splitting hairs. If somebody has a problem, it helps to be
specific.
> >
> > The keyboard/mouse/serial/parallel are all handled by the kernel. There
> > is no dependence upon the BIOS. I note that startup code insists in using
> > the BIOS to set the keyboard repeat-rate, but that can be handled by
> > the kernel after the system is booted so even it it didn't work it can
> > be fixed once the system is up.
> So what you are saying is that there is no dependance on the BIOS at all or
> for the keyboard/mouse/serial/parallel part only?
Correct. The BIOS is never used.
> >
> > >
> > > And here I don't seem to be able to specify for the kernel what IRQ, DMA
> > > and IO port I want to go where. For example an ISA-PNP soundcard no longer
> > > lets me tell it what IRQ, DMA and IO I want it to use because it gets it from
> > > the PNP code. And I can't see that I am able to tell the PNP code what
> > > resources I want to go where?
> >
> > Once the kernel is booted, it does not use the BIOS. However, when it
> > is starting, still in 'real' mode, the boot code gets and saves
> > information about the system from the BIOS. Often this information is
> > wrong. For instance, there is a short word that is supposed to contain
> > the total memory in kilobytes. 65535 * 1024 = 67,107,864. What happens
> > if you have more? Simple, there is another BIOS hack that is supposed
> > to handle it. However, some do, some don't.
> >
> > You can override possibly bad information, for drivers that support
> > command-lines, by adding the appropriate command into the LILO loader
> > configuration file.
> >
> > Some drivers don't support parameters that are different from their
> > defaults because:
> >
> > (1) Physical connections do not exist, i.e., if a port is at 0x300,
> > it's at 0x300. Nothing can be done about it. Same thing for some
> > IRQs.
> >
> > (2) Old drivers, especially for ISA, may never have been envisioned
> > for this capability. In particular, shared interrupts were not available
> > until recently. They require the APIC because, even though the 8259
> > could be set up for level, the ISA bus had pull-up resistors making
> > sharing an IRQ line impossible.
> >
> > (3) Some information is simply wrong and you get a better chance by
> > just turning OFF PNP in the BIOS. For instance, I have a BusLogic
> > SCSI controller which, although the BIOS finds it, the kernel won't
> > unless PNP is turned OFF. The ASUS P2B-D/P2B-DS AGP mainboard BIOS
> > has this problem.
> >
> > I just let the kernel find it without being confused by the bad info
> > it has picked up during boot. I just turn OFF PNP.
> >
> Turning off PNP in an i386 BIOS usually means turning off ISA PNP and as far
> as I can see we don't limit ourselves to just that.
>
Sure. But remember "Plug and Play" (Plug and Pray) never worked for
anybody, expecially Micro$oft. The drivers all go out and probe. The
major reason is that there are often not enough physical traces on the
motherboard going to the slots. Often (usually) you have to move cards
around to have them found, and found in some useful way.
> What you are saying above is that the PNP code *is* dependant on the BIOS and
> that is what worries me because it makes it pretty non-general.
That's your interpretation. I stated that information from the BIOS is
made available to the kernel. I also stated that you can sometimes
override this information. I can't understand how you could interpret me
differently.
> I also have
> an AXP (UDB/Multia) where I can't set anything in the BIOS (or whatever you
> call it there), but I still have both PCI and IDE busses. Incidentally, that
> machine is pretty limited, eg. with only one PCI slot so I have no problems
> with resource conflicts, but it is also a bad reference system for that
> purpose. The PC I mentioned above has almost everything and every IRQ is or
> should be in use, so there I need the management that I hoped PNP could or
> eventually will provide.
>
> And then you are telling me that some drivers use and some don't use the
> services provided by PNP and that I can override bad info on the command line
> with some drivers? But I don't think that a driver can or should change
> for example the IRQ, DMA or IO port the physical device has been initialized
> with, because that is what the PNP code does, right?
>
There are no "services" provided by PNP. There are a bunch of software
hacks in the BIOS, many of which can't possibly work. That's why PNP
doesn't work. The kernel code attempts to work around these problems.
The setting up of the APIC is the first step. The second step is
done by specific driver initialization.
> > The kernels support initialization of the APIC, this is where it gets
> > information about the devices.
> I don't exactly know what an APIC is.
>
This is the chip-set that supports the PCI/AGP "bridge". It is the thing
that connects the hardware to specific IRQs and specific I/O addresses.
It also has a timer and interrupt-controller as part of the same device.
> > Penguin : Linux version 2.3.41 on an i686 machine (800.63 BogoMips).
> Linux version 2.3.50 on an i386 machine (466.94 BogoMips). And what does that
> tell us? :-)
>
Erm... I have a Dual SMP machine with a 400Hz internal clock. You have a
single CPU, that's supposed to run at 400 MHz, but it seems to be
overclocked. Further, you are running an experimental version that
probably has fewer bugs than mine.
Cheers,
Dick Johnson
Penguin : Linux version 2.3.41 on an i686 machine (800.63 BogoMips).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:16 EST