forked from Minki/linux
7f0dbbc08d
> That helped a lot, the system seems to work normally now. > > Here's the relevant snippet from dmesg: > > [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> > [ 0.108006] ..... (found apic 0 pin 2) ...<3> failed. > [ 0.108006] ...trying to set up timer as Virtual Wire IRQ...<3> works. > > and the whole thing is at: http://www.sisk.pl/kernel/debug/20080618/dmesg-2.log Hmm, that only proved the 8259A is indeed wired to the pin #2 of the I/O APIC. > I, personally, don't have any and AMD only has SB600 documentation on its > web page (it's still marked as "AMD confidential" ;-)). Well, the IC block is most likely the same as that's not rocket science and once done there is no need to fiddle with that. That written, I am afraid there is nothing useful about the IC in the document, except that it's there and consists of an I/O APIC providing 24 inputs and the usual pair of 8259A cores. Thanks for the reference anyway. > There is an interrupt controller in there, but I'm not sure if there's any > 8259A. The northbridge is on the CPU, actually. I will praise the day someone ships an x86 machine without an 8259A core! As expressed in another mail I suspect there may actually be a direct route from the 8254 to INTIN0 in the southbridge -- this is what other bootstrap logs seen in the Internet suggest. This would mean this particular BIOS is buggy (is it the latest version?) and provides an incorrect IRQ override in its ACPI tables, for example because the responsible block has been blindly copied from a machine using a commoner wiring. This could be moderately easily fixed up with a quirk based on the PCI ID (after checking it again, we actually used to have a quirk for ATI in this area, but the way it was done suggests the issue was not understood well enough). Could you please remove the hack sent yesterday and test the patch provided below? I do hope it builds, but I have no immediate means to check it. Please report the output. The intent is to test INTIN0 directly before testing INTIN2 through the 8259A. Thanks. Aside of that, what I have gathered from your reports (please correct me if I have got it wrong) is that when the through-8259A mode is used, then after a while 8254 timer interrupts stop arriving. What's interesting, the "Virtual Wire IRQ" seems to work for you correctly (that's quite an odd setup where a local APIC input is used in the native mode -- please post /proc/interrupts for confirmation), which in turn implies the master 8259A drives its INT output as we expect. Why would the I/O APIC input have problems then? Hmm... [ mingo@elte.hu: revert the "x86: fix IO APIC breakage on HP nx6325" version. ] Signed-off-by: Ingo Molnar <mingo@elte.hu> |
||
|---|---|---|
| .. | ||
| boot | ||
| configs | ||
| crypto | ||
| ia32 | ||
| kernel | ||
| kvm | ||
| lguest | ||
| lib | ||
| mach-default | ||
| mach-es7000 | ||
| mach-generic | ||
| mach-rdc321x | ||
| mach-visws | ||
| mach-voyager | ||
| math-emu | ||
| mm | ||
| oprofile | ||
| pci | ||
| power | ||
| vdso | ||
| video | ||
| xen | ||
| Kconfig | ||
| Kconfig.cpu | ||
| Kconfig.debug | ||
| Makefile | ||
| Makefile_32.cpu | ||