>> "Richard B. Johnson" wrote:
>> >
>> > 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.
>
And how is mentioning a machine as i386 when asking about Linux kernel code not
specific? And how would saying ix86 making it more 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.
>
So when a BIOS setting in one way can make something possible and in another
way make it non-possible makes it dependant on the BIOS, whether it is used or
not. That is the problem.
>> 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.
>
Uhm ... I don't get what you mean? When a BIOS has ISA PNP code in it it goes
out and initializes the cards in a way well described in the Plug-and-Play-HOWTO
where I didn't see any mentioning of card-position being relevant and I would
be very surprised if it did, but please elaborate if you want to.
Further, I have no knowledge about Microsoft's products and I believe the ISA
PNP specs were produced by Microsoft, Intel and Compaq in unison. It is a hack
of an outdated bus, yes, but it is unfortunately something some of us are stuck
with and hope to make work in a 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.
>
My mistake, I am sorry. When I said "PNP code" I meant Linux kernel PNP code,
which is dependant on BIOS settings, if any change of the settings there will
affect how the kernel is able to work. At least that is how I interpret the
meaning of the word "dependant".
>> 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.
>
Again, I am sorry I didn't specified that I meant Linux kernel PNP code when I
said PNP code. I would hope that after the Linux kernel PNP code finishes with
its initial resource management, all drivers that need access to for example
physical devices would be able to get them from the Linux kernel PNP code as a
service, instead of having to query the actual device itself. Otherwise I don't
see the purpose of PNP in the kernel?
All in all, it would be great if the kernel could start over with initializing
all hardware devices, possibly with a 'good start guess' from what was there
previously if it for example was an i386 with a PNP BIOS, but not limited to
that. When all devices were initialized, drivers that needs access to a device
would ask Linux kernel PNP for it and never know if it was a PCI, AGP, ISA, VME
or SBUS device for all I care.
Or is this not what PNP support and resource management in the Linux kernel
was meant to be?
>> > 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.
>
Good joke :-) (You are joking, right? :-) My machine is a 233MHz P5)
Thank you very much,
Peter
--
main(){char*s="O_>>^PQAHBbPQAHBbPOOH^^PAAHBJPAAHBbPA_H>BB";int i,j,k=1,l,m,n;
for(j=0;j<7;j++)for(l=0;m=l-6+j,i=m/6,n=j*6+i,k=1<<m%6,l<41-j;l++)
putchar(l<6-j?' ':l==40-j?'\n':k&&s[n]&k?'*':' ');}
-
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