On Wed, Nov 22, 2000 at 05:58:14PM +, Alan Cox wrote:
> > > if(vendor!=INTEL && !has_apic)
> > > /* No SMP */
> >
> > And suddenly certain i486 systems do not work anymore? Well, I haven't
>
> i486 is an intel processor
... but is there a reason why for example AMD 486's
Alan,
Here is a patch that should fix the problem. I could trim down
verify_local_APIC() now, but given the code freeze I guess it's for
post-2.4.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+
Alan,
Here is a patch that should fix the problem. I could trim down
verify_local_APIC() now, but given the code freeze I guess it's for
post-2.4.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+
lt;[EMAIL PROTECTED]>, Ingo
Molnar
kernel.org <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Subject: Re: Linux
2.4.0test11-ac1
> > > And suddenly certain i486 systems do not work anymore? Well, I haven't
> > i486 is an intel processor
> >
> ... but doesn't announce itself as such.
Depends which stepping. We can check for and allow 'unknown' vendor too.
The socket7 chips all have cpuid or other id schemes.
Alan
-
Alan Cox wrote:
>
> > > if(vendor!=INTEL && !has_apic)
> > > /* No SMP */
> >
> > And suddenly certain i486 systems do not work anymore? Well, I haven't
>
> i486 is an intel processor
>
... but doesn't announce itself as such.
> > if (boot_cpu_id != -1U
> >
> > if(vendor!=INTEL && !has_apic)
> > /* No SMP */
>
> And suddenly certain i486 systems do not work anymore? Well, I haven't
i486 is an intel processor
> if (boot_cpu_id != -1U
> && APIC_INTEGRATED(apic_version[boot_cpu_id]) && !has_apic)
> /*
> APICs (probably due to the fact there was no standalone I/O APIC chip
> available at that time) so CPUs report no APIC flag. And it starts in the
> PIC mode as opposed to the Virtual Wire. I may send you his bootstrap log
> if you want to (but not today -- I don't have it handy).
Ok. That
On Tue, 21 Nov 2000, Alan Cox wrote:
> > It's not legal -- the MPS is very explicit the MP-table must reflect a
> > real configuration.
>
> Intel tell me otherwise. The real world also disagrees which makes the
> discussion a little pointless. We have to handle the real situation where
> this
On Wed, 22 Nov 2000, Alan Cox wrote:
> I know of no socket 7 board with an 82489DX, and no board on the planet which
> has 82489DX and works SMP with a non intel processor. I accept its a heuristic
> but so is the current behaviour, and the current heuristic isnt working for
> as many cases.
On Tue, 21 Nov 2000, Alan Cox wrote:
It's not legal -- the MPS is very explicit the MP-table must reflect a
real configuration.
Intel tell me otherwise. The real world also disagrees which makes the
discussion a little pointless. We have to handle the real situation where
this occurs
APICs (probably due to the fact there was no standalone I/O APIC chip
available at that time) so CPUs report no APIC flag. And it starts in the
PIC mode as opposed to the Virtual Wire. I may send you his bootstrap log
if you want to (but not today -- I don't have it handy).
Ok. That means
if(vendor!=INTEL !has_apic)
/* No SMP */
And suddenly certain i486 systems do not work anymore? Well, I haven't
i486 is an intel processor
if (boot_cpu_id != -1U
APIC_INTEGRATED(apic_version[boot_cpu_id]) !has_apic)
/* No SMP */
It
Alan Cox wrote:
if(vendor!=INTEL !has_apic)
/* No SMP */
And suddenly certain i486 systems do not work anymore? Well, I haven't
i486 is an intel processor
... but doesn't announce itself as such.
if (boot_cpu_id != -1U
And suddenly certain i486 systems do not work anymore? Well, I haven't
i486 is an intel processor
... but doesn't announce itself as such.
Depends which stepping. We can check for and allow 'unknown' vendor too.
The socket7 chips all have cpuid or other id schemes.
Alan
-
To
kernel.org [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: Linux
2.4.0test11-ac1
Alan Cox wrote:
>
>> I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed
out:
>>
>> /usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall
-Wstrict-prototypes
>> -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o
>> sched.o sched.c
>>
Followup to: <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> >
> > Nononono... the 82489DX is an *external* APIC, which should be usable
> > on any Socket 5/7 CPU...
>
> I know of no socket 7 board with an 82489DX, and no board on the planet
> > Intel stuff appears to always be happy poking in APIC space. I don't know
> > if this is related to the chip internals on the non APIC capable chips.
>
> Nononono... the 82489DX is an *external* APIC, which should be usable
> on any Socket 5/7 CPU...
I know of no socket 7 board with an
Followup to: <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> > > making any assumptions about APIC availability on a processor.
> >
> > OK, but how does it handle the 82489DX? There are valid configurations
> > using this kind of APIC,
> > MP table regardless of the capabilities of the CPU installed. Its apparently
> > legal to do so. There is an apic capability flag that should be tested before
> It's not legal -- the MPS is very explicit the MP-table must reflect a
> real configuration.
Intel tell me otherwise. The real
> I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed out:
>
> /usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
> -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o
> sched.o sched.c
> irq.c:182: conflicting types for
> > o Cleanup console_verbose() dunplication
> include/linux/kernel.h: if we are adding new inlines to kernel headers,
> they should be 'static inline'..
Agreed
> > o Epic100 update
>
> dhinds seemed to question the epic100 fix which is enclosed in
> CONFIG_CARDBUS... also I have
"Maciej W. Rozycki" wrote:
>
> On Tue, 21 Nov 2000, Alan Cox wrote:
>
> > Quite a few dual pentium socket 7 boards report dual cpu and apic in the
> > MP table regardless of the capabilities of the CPU installed. Its apparently
> > legal to do so. There is an apic capability flag that should be
On Tue, 21 Nov 2000, Alan Cox wrote:
> Quite a few dual pentium socket 7 boards report dual cpu and apic in the
> MP table regardless of the capabilities of the CPU installed. Its apparently
> legal to do so. There is an apic capability flag that should be tested before
It's not legal -- the
I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed out:
/usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o
sched.o sched.c
irq.c:182: conflicting types for
> Well, does any SMP board map anything into the local APIC space? After
> saying there a real APIC there??? Now *THAT* is completely unsafe. How
> is that supposed to work when there actually is an APIC-equipped CPU put
> in?
Quite a few dual pentium socket 7 boards report dual cpu and apic
Alan Cox wrote:
> Change Log
>
> o Cleanup console_verbose() dunplication
include/linux/kernel.h: if we are adding new inlines to kernel headers,
they should be 'static inline'..
> o 3c503 error return cleanup
> o 8390 seperate tx timeout path
> o Acenic update
> o
On Tue, 21 Nov 2000, Alan Cox wrote:
> Its completely unsafe. The CPU in question is NOT intel. It has no APIC
> instead you poke around randomly in MMIO space and the box dies. You have
> to check the cpu capabilities too
Well, does any SMP board map anything into the local APIC space? After
On Tue, 21 Nov 2000, Alan Cox wrote:
> > > o Dont crash on boot with a dual cpu board holding a non intel cpu
> >
> > Is this the patch to check for the Local APIC?
>
> Yep
Hmm, that's weird -- the check is already there for some time -- see
verify_local_APIC(). It works and it's reliable
> > > > o Dont crash on boot with a dual cpu board holding a non intel cpu
> > > Is this the patch to check for the Local APIC?
> > Yep
>
> Hmm, that's weird -- the check is already there for some time -- see
> verify_local_APIC(). It works and it's reliable even for the 82489DX.
Its
> On Tue, Nov 21, 2000, Alan Cox <[EMAIL PROTECTED]> wrote:
> > o Dont crash on boot with a dual cpu board holding a non intel cpu
>
> Is this the patch to check for the Local APIC?
Yep
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Tue, Nov 21, 2000, Alan Cox <[EMAIL PROTECTED]> wrote:
> o Dont crash on boot with a dual cpu board holding a non intel cpu
Is this the patch to check for the Local APIC?
JE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Differences between 2.4.0test11ac1 and 2.4.0test11, pretty much all merged
from stuff off the maintainers and kernel list.
For newcomers to these patches:
- You can find them on ftp.*.kernel.org/pub/linux/kernel/people/alan
- They are diffed against the base revision not cumulative
Differences between 2.4.0test11ac1 and 2.4.0test11, pretty much all merged
from stuff off the maintainers and kernel list.
For newcomers to these patches:
- You can find them on ftp.*.kernel.org/pub/linux/kernel/people/alan
- They are diffed against the base revision not cumulative
On Tue, Nov 21, 2000, Alan Cox [EMAIL PROTECTED] wrote:
o Dont crash on boot with a dual cpu board holding a non intel cpu
Is this the patch to check for the Local APIC?
JE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Tue, Nov 21, 2000, Alan Cox [EMAIL PROTECTED] wrote:
o Dont crash on boot with a dual cpu board holding a non intel cpu
Is this the patch to check for the Local APIC?
Yep
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
o Dont crash on boot with a dual cpu board holding a non intel cpu
Is this the patch to check for the Local APIC?
Yep
Hmm, that's weird -- the check is already there for some time -- see
verify_local_APIC(). It works and it's reliable even for the 82489DX.
Its completely
On Tue, 21 Nov 2000, Alan Cox wrote:
o Dont crash on boot with a dual cpu board holding a non intel cpu
Is this the patch to check for the Local APIC?
Yep
Hmm, that's weird -- the check is already there for some time -- see
verify_local_APIC(). It works and it's reliable even for
On Tue, 21 Nov 2000, Alan Cox wrote:
Its completely unsafe. The CPU in question is NOT intel. It has no APIC
instead you poke around randomly in MMIO space and the box dies. You have
to check the cpu capabilities too
Well, does any SMP board map anything into the local APIC space? After
Alan Cox wrote:
Change Log
o Cleanup console_verbose() dunplication
include/linux/kernel.h: if we are adding new inlines to kernel headers,
they should be 'static inline'..
o 3c503 error return cleanup
o 8390 seperate tx timeout path
o Acenic update
o
Well, does any SMP board map anything into the local APIC space? After
saying there a real APIC there??? Now *THAT* is completely unsafe. How
is that supposed to work when there actually is an APIC-equipped CPU put
in?
Quite a few dual pentium socket 7 boards report dual cpu and apic in
I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed out:
/usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o
sched.o sched.c
irq.c:182: conflicting types for
On Tue, 21 Nov 2000, Alan Cox wrote:
Quite a few dual pentium socket 7 boards report dual cpu and apic in the
MP table regardless of the capabilities of the CPU installed. Its apparently
legal to do so. There is an apic capability flag that should be tested before
It's not legal -- the MPS
"Maciej W. Rozycki" wrote:
On Tue, 21 Nov 2000, Alan Cox wrote:
Quite a few dual pentium socket 7 boards report dual cpu and apic in the
MP table regardless of the capabilities of the CPU installed. Its apparently
legal to do so. There is an apic capability flag that should be tested
o Cleanup console_verbose() dunplication
include/linux/kernel.h: if we are adding new inlines to kernel headers,
they should be 'static inline'..
Agreed
o Epic100 update
dhinds seemed to question the epic100 fix which is enclosed in
CONFIG_CARDBUS... also I have a big
I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed out:
/usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o
sched.o sched.c
irq.c:182: conflicting types for
MP table regardless of the capabilities of the CPU installed. Its apparently
legal to do so. There is an apic capability flag that should be tested before
It's not legal -- the MPS is very explicit the MP-table must reflect a
real configuration.
Intel tell me otherwise. The real world
Followup to: [EMAIL PROTECTED]
By author:Alan Cox [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
making any assumptions about APIC availability on a processor.
OK, but how does it handle the 82489DX? There are valid configurations
using this kind of APIC, including Pentium
Intel stuff appears to always be happy poking in APIC space. I don't know
if this is related to the chip internals on the non APIC capable chips.
Nononono... the 82489DX is an *external* APIC, which should be usable
on any Socket 5/7 CPU...
I know of no socket 7 board with an 82489DX,
Followup to: [EMAIL PROTECTED]
By author:Alan Cox [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Nononono... the 82489DX is an *external* APIC, which should be usable
on any Socket 5/7 CPU...
I know of no socket 7 board with an 82489DX, and no board on the planet which
has
Alan Cox wrote:
I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed
out:
/usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall
-Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o
sched.o sched.c
irq.c:182: conflicting
52 matches
Mail list logo
