[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rtl] RTAI: lockcpu<3.0.2.32.20001130122648.00885e60@linuxserver> <3.0.2.32.20001130140332.00885e00@linuxserver>
- To: Erwin.Rol@q-soft-engineering.com
- Subject: Re: [rtl] RTAI: lockcpu<3.0.2.32.20001130122648.00885e60@linuxserver> <3.0.2.32.20001130140332.00885e00@linuxserver>
- From: Zdenek Kabelac <kabi@fi.muni.cz>
- Date: Mon, 4 Dec 2000 21:56:07 GMT
- Newsgroups: cz.muni.redir.rtlinux
- Organization: unknown
- References: <3A265286.77299F13@q-soft-engineering.com>
- Sender: UNKNOWN@dual.fi.muni.cz
Erwin Rol wrote:
>
> huib wrote:
> >
> > The bp6 is known for those APIC errors, i read it somewhere.
> > If the lockcpu example is stressing the mainboard in a way
> > causing extra APIC errors, it could be the answer.
>
> Ok i didn't knew that, it was just a suggestion that those APIC
> error might be the problem.
>
I'm using RTL with BP6 for a year and APIC error are no problem.
However linux kernel is hardly broken in many places.
I'm having latest stable version as 2.2.17pre9 with my patch for irq
routine - this kernel was very stable - now I'm using 2.4.0-test12pre4
but this kernel has some serious problems with hdd - especialy hpt366
seems to be unhappy with this kernel.
> Just was an idea so you could check if (no realtime linux needed) you
> have
> those APIC errors, but it seems not needed when you already know that
> :-)
Well you shouldn't recieve any apic error if you are running with 66MHz
bus.
I'm starting to get them with 75MHz
> could those APIC errors be the problem ?
No at all - many kernel developer try to find some excuses for their
bugs :)....
--
There are three types of people in the world:
those who can count, and those who can't.
Zdenek Kabelac http://i.am/kabi/ kabi@i.am {debian.org; fi.muni.cz}