Bart Locanthi wrote:
> >>> btw every 2.4 kernel that i have installed on BP6 appears to ignore
> >>> append="noapic" (though it does seem to work on VP6's).
> >>
> >> Does the log file on 2.4 show that APICs are being used? I'd like to know
> >> how to check this, as I think I will have no joy with 2.4 with APICs
> >> enabled, never mind the corruption possibilities due to the weak CRC APICs
> >> use, as mentioned in the LKML FAQ.
> >
> > I think if you do a "cat /proc/interrupts" it tells you:
> >
> > % cat /proc/interrupts
> > CPU0 CPU1
> > 0: 137044893 0 XT-PIC timer
> > 1: 736186 0 XT-PIC keyboard
>
> hmm, same here:
>
> [bart@nemo bart]$ cat /proc/interrupts
> CPU0 CPU1
> 0: 21519783 0 XT-PIC timer
> 1: 21747 0 XT-PIC keyboard
> 2: 0 0 XT-PIC cascade
> 5: 641682 0 XT-PIC eth1
>
> so why is it i keep seeing APIC errors from both CPUs in the log? and
> frequently, too!
>
> May 23 22:07:16 nemo kernel: APIC error on CPU1: 08(04)
> May 23 22:07:55 nemo kernel: APIC error on CPU0: 04(04)
> May 23 22:07:55 nemo kernel: APIC error on CPU1: 04(08)
> May 23 22:08:13 nemo kernel: APIC error on CPU0: 04(04)
> May 23 22:08:13 nemo kernel: APIC error on CPU1: 08(02)
>
> perhaps it's time for someone who really knows what all this means to
> speak up. i don't have any explanation or understanding of what's going
> on at this point.
Hi,
I don't know much about the APIC, but I did write the code that prints
the messages you quote...
/home/wolff> cat /proc/interrupts
CPU0 CPU1
0: 172532223 0 XT-PIC timer
1: 1288226 0 XT-PIC keyboard
2: 0 0 XT-PIC cascade
3: 878637 0 XT-PIC serial
4: 1429446 0 XT-PIC serial
8: 1 0 XT-PIC rtc
11: 119295630 0 XT-PIC eth0
12: 9774750 0 XT-PIC PS/2 Mouse
14: 7243782 0 XT-PIC ide0
NMI: 0 0
LOC: 172536237 172536278
ERR: 438
MIS: 0
In an MP machine, the interrupts are not the only thing that requires
the APIC. Some inter processor communication also does. That's
probably LOC.
So, on my computer there have been 172 million APIC operations. Some
of these encounter a CRC error. That results in those messages getting
printed.
The code used to print the exact meaning of those bits. That made the
routine take too long, and caused lockups. You now have to look up the
bits in the source to find out what the APICs are really complaining
about.
/* Here is what the APIC error bits mean:
0: Send CS error
1: Receive CS error
2: Send accept error
3: Receive accept error
4: Reserved
5: Send illegal vector
6: Received illegal vector
7: Illegal register address
*/
recieve/send accept errors seem to be most common, but you also have a
recieve checksum error.
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
--
=- To unsubscribe, email [EMAIL PROTECTED] with the -=
=- body of "unsubscribe linux-abit". -=
