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 coul
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
-
T
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)
> /* N
On Wed, 22 Nov 2000, Alan Cox wrote:
> I think it reports 1.1 apics from memory. Its simply hardcoded in the bios
> rather than the configurable flash area.
So we might check for it. Good!
> The following change should make all of this work
>
> if(vendor!=INTEL && !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 me
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.
Do
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:
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
> > 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 82489
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, includi
> > 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 wor
> 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 `gl
> > 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 M
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 `global_irq_loc
> 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 ev
> > > > 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 com
> 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 [EMAI
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 PROTE
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
28 matches
Mail list logo
