Date: Tue, 19 Nov 1996 13:55:50 -0700 From: Steve Passe <smp@csn.net> To: Tor Egge <Tor.Egge@idt.ntnu.no> Cc: smp@freebsd.org Subject: Re: Can test again... Message-ID: <199611192055.NAA19886@clem.systemsix.com> In-Reply-To: Your message of "Tue, 19 Nov 1996 20:32:22 %2B0100." <199611191932.UAA16615@pat.idt.unit.no>
index | next in thread | previous in thread | raw e-mail
Hi,
Tor Egge wrote:
>I performed more tests with the lastest SMP-kernel but without APIC_IO
>enabled.
>
>- CPU usage accounting is broken. The numbers are way too low. They
known problem, just not high on the list of things to fix.
---
>- syscons & psm conflict is the worst I've ever seen. Makes X
> unusable. I cannot remember any normal -current kernel showing
> this conflict to that degree.
I'm guessing you are probably first SMP tester to use a psm mouse.
---
>- Interrupts are lost. e.g. rtc stopped generating interrupts due
> to a lost interrupt.
I wouldn't expect this on a NON APIC_IO kernel, but who knows???
---
>I just tried a kernel compiled with APIC_IO enabled. I got the message
>about reset NOW or press return to continue. I pressed return, and
>nothing happened. I'll probably look into this more closely next
>week.
>
>The values of imen and apiciomask were both 0xff2925.
this is the INT mask for INTs 0-23, so INTs 1,3,4,6,7,9,10,12,14,15 are
unmasked.
INTs 2 & 8 (hardclock & RTC) are unmasked later in the boot process.
This looks right for the hardware you show in the dmesg you sent.
I think you hit the problem I said to expect, Asus has chosen an "odd" way
to label the PCI INTs in the mptable:
your dmesg:
ahc0 <Adaptec 2940 SCSI host adapter> rev 0 int a irq 9 on pci0:11
^ ^ ^^
your mptable:
Bus: Bus ID Type
0 PCI
1 ISA
I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT#
INT active-lo level 1 9 2 17
^ ^ ^^
should(?) be: 0 11:A 17
This entry effectivly says that ISA bus INT9 is connected to APIC INT17.
My belief is that it should say PCI bus device11:INTA goes to APIC INT17.
The problem is that the current PCI code (sys/pci/pci.c) asks the
MP sub-system (get_pci_apic_irq (bus_no, device, pciint)) for the APIC
INT to which the device (ahc0) is connected. Since the above entry
doesn't parse to a PCI bus entry, it returns "not found". This causes the code
to assume case #1 (see below). So it believes the PCI redirection register
contents (which will contain INT9) and programs everything to occur on INT9,
while the line is evidently attached to APIC INT17.
---
Every other PCI bus machine I have encountered either:
-
1: doesn't route the PCI INTs to upper (ie above ISA INT15) APIC INT pins,
instead depending on the PCI-ISA IRQ redirection hardware to make it work.
-
2: routes the PCI INTs to individual upper APIC pins, declaring them like:
Bus: Bus ID Type
0 ISA
1 PCI
I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT#
INT active-lo level 1 12:A 2 19
^ ^^ ^ ^^
-
Is there anything in the BIOS that looks like it might affect this behavior?
---
My guess is that if you wait for a minute or 2 after hitting return, you will
get a timeout from the adaptec controller, ie you're locked because you are
missing disk INTs.
So, its debate time, is this MP declaration that Asus is using on
its P/I-P65UP5/C-P6ND motherboard correct? I checked the database
and they DO NOT do this on either the P54NP4 or P55P2T4D (both EISA/PCI).
I'm going back to re-read the spec to see if I can find this variation.
If its legal I'll redo the code to make it work. If it's bogus I'll
have to add some sort of "rogue hardware" patch that is enabled with
a kernel config option.
Opinions???
--
Steve Passe | powered by
smp@csn.net | FreeBSD
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE
04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX
WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR
tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+
=ds99
-----END PGP PUBLIC KEY BLOCK-----
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611192055.NAA19886>