Seems like Linux 2.4.x has PCI initialization issues when you start
having funky PCI bus setups. Now before you point a finger at
the BIOs please read on...
In other words Linux needs a lot of help from the bios and if it doesnt
get it things get messed up. When the bios initializes _all_ the mp table
or acpi stuff things work great.
For example Linux doesnt seem to be very smart about things like second
level pci bridges...
Example:
------
]0;root@localhost:~[root@localhost root]# lspci -tv
-[00]-+-00.0 Intel Corp. e7500 DRAM Controller
+-00.1 Intel Corp. e7500 DRAM Controller Error Reporting
+-02.0-[01-04]--+-1c.0 Intel Corp. 82870P2 P64H2 I/OxAPIC
| +-1d.0-[02]--
| +-1e.0 Intel Corp. 82870P2 P64H2 I/OxAPIC
| \-1f.0-[03-04]----01.0-[04]--+-04.0 Digital
Equipment Corporation DECchip 21142/43
| +-05.0 Digital
Equipment Corporation DECchip 21142/43
| +-06.0 Digital
Equipment Corporation DECchip 21142/43
| \-07.0 Digital
Equipment Corporation DECchip 21142/43
+-03.0-[05-07]--+-1c.0 Intel Corp. 82870P2 P64H2 I/OxAPIC
| +-1d.0-[06]--+-01.0 Intel Corp.: Unknown device
100f
| | +-02.0 Intel Corp.: Unknown device
1010
| | \-02.1 Intel Corp.: Unknown device
1010
| +-1e.0 Intel Corp. 82870P2 P64H2 I/OxAPIC
| \-1f.0-[07]--
+-1d.0 Intel Corp. 82801CA/CAM USB (Hub
+-1d.1 Intel Corp. 82801CA/CAM USB (Hub
+-1d.2 Intel Corp. 82801CA/CAM USB (Hub
+-1e.0-[08]--+-01.0 ATI Technologies Inc Rage XL
| +-02.0 Intel Corp. 82557/8/9 [Ethernet Pro 100]
| \-03.0 Intel Corp. 82557/8/9 [Ethernet Pro 100]
+-1f.0 Intel Corp. 82801CA ISA Bridge (LPC)
+-1f.1 Intel Corp. 82801CA IDE U100
\-1f.3 Intel Corp. 82801CA/CAM SMBus
-------------
See those DECchip 21142/43 devices? They are about 3 layers down
from the root and theyll never work properly unless the BIOS is capable
of initializing everything. The first of the 4 devices will receive
interupts correctly, the rest dont.
-------
]0;root@localhost:~[root@localhost root]# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 441198 441826 442361 439749 IO-APIC-edge timer
1: 1 0 0 1 IO-APIC-edge keyboard
2: 0 0 0 0 XT-PIC cascade
4: 75 78 82 52 IO-APIC-edge serial
8: 1 0 0 0 IO-APIC-edge rtc
14: 2000 1787 1960 1535 IO-APIC-edge ide0
15: 1860 1750 2021 1603 IO-APIC-edge ide1
17: 3396 3440 3400 3415 IO-APIC-level eth0
18: 6 2 2 3 IO-APIC-level eth1
24: 5 3 5 3 IO-APIC-level eth5,
eth6, eth7, eth8
96: 426 424 425 424 IO-APIC-level eth2
100: 427 424 424 425 IO-APIC-level eth3
101: 425 424 425 423 IO-APIC-level eth4
NMI: 0 0 0 0
LOC: 1762876 1762850 1762971 1762970
ERR: 0
MIS: 0
--------------
Interupt routing as can be seen above is really messed for that device.
The workaround is to move the board so the the DECchip 21142/43 devices
are at a depth not to exceed 3.
Seems this has been an ongoing problem on Linux.
http://www.tux.org/hypermail/linux-tulip/2002-Aug/0000.html
The above is the same motherboard as mentioned in the thread above except
the two processors have hyperthreading capability.
Q1: How do we resolve this other than moving around boards?
Q2: Should we really be dependent on bios this bad?
According to that thread things dont work on the BSDs either but work fine
on WinXP (shudder). Does this mean winxp doesnt depend on BIOS?
Should we really be dependent on the BIOS this much?
Shouldnt things like second level pci bridge be part of Linux discovery?
cheers,
jamal
On Sun, Mar 02, 2003 at 12:44:06PM -0500, jamal wrote:
> Interupt routing as can be seen above is really messed for that device.
Indeed. Quad tulip cards usually have irq pin A of each chip routed
to pins A-D on the connector, so they cannot have the same irq unless
all four irq pins are shared in the parent slot, which is unlikely in
this case.
> Q1: How do we resolve this other than moving around boards?
Here's [completely untested] patch that attempts to validate BIOS irq
assignments. This may break "good" irqs for other devices, but it's
interesting to see if it changes something.
> Q2: Should we really be dependent on bios this bad?
We certainly shouldn't wrt PCI IO and MMIO allocations, but irq routing
appears to be so horribly overcomplexed on x86 that dependence on
BIOS seems almost unavoidable here...
Other architectures don't have such kind of problems, BTW.
Ivan.
--- 2.4/arch/i386/kernel/pci-irq.c Fri Feb 28 16:46:28 2003
+++ linux/arch/i386/kernel/pci-irq.c Mon Mar 3 13:42:04 2003
@@ -730,7 +730,7 @@ void __init pcibios_fixup_irqs(void)
*/
if (io_apic_assign_pci_irqs)
{
- int irq;
+ int irq, irq1 = -1;
if (pin) {
pin--; /* interrupt pins are numbered starting from 1 */
@@ -741,15 +741,19 @@ void __init pcibios_fixup_irqs(void)
* parent slot, and pin number. The SMP code detects such bridged
* busses itself so we should get into this branch reliably.
*/
- if (irq < 0 && dev->bus->parent) { /* go back to the bridge */
+ if (dev->bus->parent) { /* go back to the bridge */
struct pci_dev * bridge = dev->bus->self;
pin = (pin + PCI_SLOT(dev->devfn)) % 4;
- irq = IO_APIC_get_PCI_irq_vector(bridge->bus->number,
+ irq1 = IO_APIC_get_PCI_irq_vector(bridge->bus->number,
PCI_SLOT(bridge->devfn), pin);
- if (irq >= 0)
- printk(KERN_WARNING "PCI: using PPB(B%d,I%d,P%d) to get irq %d\n",
- bridge->bus->number, PCI_SLOT(bridge->devfn), pin, irq);
+ }
+ if (irq1 >= 0 && irq1 != irq) {
+ /* IRQ listed in MP-table doesn't match one for parent slot.
+ Use that we've found instead. */
+ irq = irq1;
+ printk(KERN_WARNING "PCI: using PPB(B%d,I%d,P%d) to get irq %d\n",
+ bridge->bus->number, PCI_SLOT(bridge->devfn), pin, irq);
}
if (irq >= 0) {
printk(KERN_INFO "PCI->APIC IRQ transform: (B%d,I%d,P%d) -> %d\n",
On Mon, 2003-03-03 at 04:14, Ivan Kokshaysky wrote:
> > Q2: Should we really be dependent on bios this bad?
>
> We certainly shouldn't wrt PCI IO and MMIO allocations, but irq routing
> appears to be so horribly overcomplexed on x86 that dependence on
> BIOS seems almost unavoidable here...
> Other architectures don't have such kind of problems, BTW.
Actually, for issues like that one Jamal is pointing out, I believe
there is something we can do.
What varies so much from motherboard to motherboard on x86 is how
the interrupts are wired up. So for example, this tells us that
PCI slot X maps to x86 IRQ Y. If we know that, we can figure out
where his deeply bridged tulips will send IRQs.
If the mp tables don't give exactly this kind of information,
then Ivan is right :(
Anyone know if FreeBSD fares better in situations like this?
What do they do if so?
On Mon, 3 Mar 2003, David S. Miller wrote:
> Anyone know if FreeBSD fares better in situations like this?
All BSDs apparently have this problem. Ive heard rumors of windows XP
working just fine with the same setup on these mboards.
Unfortunately up north we have igloos so i cant verify these rumors ;->
cheers,
jamal
Ivan,
Patch was applied; no luck at all. Below is dmesg output with
debug turned on in the pci-irq.c file.
--------
Mar 3 18:01:39 localhost kernel: PCI: PCI BIOS revision 2.10 entry at
0xfd875last bus=8
Mar 3 18:01:39 localhost kernel: PCI: Using configuration type 1
Mar 3 18:01:39 localhost kernel: PCI: Probing PCI hardware
Mar 3 18:01:39 localhost kernel: PCI: Probing PCI hardware
Mar 3 18:01:39 localhost kernel: Transparent bridge - Intel Corp.
82801BA/CA/ PCI Bridge
Mar 3 18:01:39 localhost kernel: PCI: Discovered primary peer bus 10
[IRQ]
Mar 3 18:01:39 localhost kernel: PCI: Discovered primary peer bus 11
[IRQ]
Mar 3 18:01:39 localhost kernel: PCI: Discovered primary peer bus 12
[IRQ]
Mar 3 18:01:39 localhost kernel: PCI: Using IRQ router PIIX [8086/2480]
at 00f.0
Mar 3 18:01:39 localhost kernel: PCI: IRQ fixup
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B0,I29,P0) ->
16
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B0,I29,P1) ->
19
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B0,I29,P2) ->
18
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B2,I1,P1) ->
48
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B3,I1,P1) ->
24
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B3,I1,P2) ->
25
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B6,I4,P0) ->
96
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B6,I5,P1) ->
96
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B6,I6,P2) ->
96
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B6,I7,P3) ->
96
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B8,I1,P1) ->
16
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B8,I2,P2) ->
17
Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B8,I3,P3) ->
18
---------------
BIOS irq assignments i suppose are validated.
I have a feeling the reason it works in windows is because of a
functional ACPI.
What next? ;->
cheers,
jamal
On Mon, Mar 03, 2003 at 08:48:16PM -0500, jamal wrote:
> Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B6,I4,P0) ->
> 96
> Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B6,I5,P1) ->
> 96
> Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B6,I6,P2) ->
> 96
> Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B6,I7,P3) ->
> 96
...
> BIOS irq assignments i suppose are validated.
No, this means that mp tables are broken in a way I didn't expect...
Also, it's unclear whether or not the IOxAPIC routing is broken as well.
Probably full dmesg output (especially things related to IO_APICs setup
and irq<->pin mapping) could shed some light on this.
> I have a feeling the reason it works in windows is because of a
> functional ACPI.
Perhaps.
Ivan.
Ivan,
Here is the full messages output for a system with this problem. I had
only provided part of the
messages file to him earlier. This is the entire output.
(See attached file: messages)
David
Ivan Kokshaysky
<[email protected] To: jamal
<[email protected]>
rk.msu.ru> cc: Greg KH
<[email protected]>, Linus Torvalds
<[email protected]>, Jeff Garzik
<[email protected]>,
[email protected], [email protected],
Robert Olsson
03/04/2003 10:28 <[email protected]>,
Donald Becker <[email protected]>,
AM
[email protected], [email protected],
[email protected]
Subject: Re: PCI init issues
On Mon, Mar 03, 2003 at 08:48:16PM -0500, jamal wrote:
> Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B6,I4,P0) ->
> 96
> Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B6,I5,P1) ->
> 96
> Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B6,I6,P2) ->
> 96
> Mar 3 18:01:39 localhost kernel: PCI->APIC IRQ transform: (B6,I7,P3) ->
> 96
...
> BIOS irq assignments i suppose are validated.
No, this means that mp tables are broken in a way I didn't expect...
Also, it's unclear whether or not the IOxAPIC routing is broken as well.
Probably full dmesg output (especially things related to IO_APICs setup
and irq<->pin mapping) could shed some light on this.
> I have a feeling the reason it works in windows is because of a
> functional ACPI.
Perhaps.
Ivan.
(See attached file: messages)
On Tue, 4 Mar 2003 [email protected] wrote:
>
> Here is the full messages output for a system with this problem. I had
> only provided part of the
> messages file to him earlier. This is the entire output.
Well, the interesting parts are missing, because your klogd output has
been truncated due to the huge output from the md layer etc. However, I
suspect strongly that the issue is in IO_APIC_get_PCI_irq_vector() in
arch/i386/kernel/io_apic.c, and I would further guess that it's the fact
that your MP tables don't have the full mapping or we're somehow screwing
it up.
Can you add a printk() to the case where we return "best_guess" at the end
of that function? We have that fuzzy match thing where if we cannot find
the exact entry in the MP table we instead use the first entry that
matches in everything but the <pin> number, and it would be interesting to
hear if that's the logic that triggers.
It's also quite possible that your MP tables just aren't right, and the
reason XP works on the machine is that XP uses the ACPI irq lookup stuff.
You could try enabling ACPI bootup support (I've never used it on 2.4.x
myself, but it's required for at least one of my machines and works fine
on 2.5.x).
Linus
Mar 4 18:39:33 kernel syslog: syslogd startup succeeded
Mar 4 18:39:33 kernel syslog: klogd startup succeeded
Mar 4 18:39:33 kernel kernel: klogd 1.4.1, log source = /proc/kmsg started.
Mar 4 18:39:33 kernel kernel: Linux version 2.4.18-24.8.0custom ([email protected]) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #4 SMP Mon Mar 3 16:55:40 CET 2003
Mar 4 18:39:33 kernel kernel: BIOS-provided physical RAM map:
Mar 4 18:39:33 kernel kernel: BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
Mar 4 18:39:33 kernel kernel: BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
Mar 4 18:39:33 kernel kernel: BIOS-e820: 00000000000d8000 - 00000000000e0000 (reserved)
Mar 4 18:39:33 kernel kernel: BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
Mar 4 18:39:33 kernel kernel: BIOS-e820: 0000000000100000 - 000000007fef0000 (usable)
Mar 4 18:39:33 kernel kernel: BIOS-e820: 000000007fef0000 - 000000007fefc000 (ACPI data)
Mar 4 18:39:33 kernel kernel: BIOS-e820: 000000007fefc000 - 000000007ff00000 (ACPI NVS)
Mar 4 18:39:33 kernel kernel: BIOS-e820: 000000007ff00000 - 000000007ff80000 (usable)
Mar 4 18:39:33 kernel keytable: Loading keymap:
Mar 4 18:39:33 kernel kernel: BIOS-e820: 000000007ff80000 - 0000000080000000 (reserved)
Mar 4 18:39:33 kernel keytable:
Mar 4 18:39:33 kernel kernel: BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
Mar 4 18:39:33 kernel keytable:
Mar 4 18:39:33 kernel kernel: BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
Mar 4 18:39:33 kernel rc: Starting keytable: succeeded
Mar 4 18:39:33 kernel kernel: BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved)
Mar 4 18:39:33 kernel kernel: BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
Mar 4 18:39:33 kernel kernel: 1151MB HIGHMEM available.
Mar 4 18:39:33 kernel kernel: 896MB LOWMEM available.
Mar 4 18:39:33 kernel kernel: found SMP MP-table at 000f7040
Mar 4 18:39:33 kernel random: Initializing random number generator: succeeded
Mar 4 18:39:33 kernel kernel: hm, page 000f7000 reserved twice.
Mar 4 18:39:33 kernel kernel: hm, page 000f8000 reserved twice.
Mar 4 18:39:33 kernel kernel: hm, page 0009f000 reserved twice.
Mar 4 18:39:33 kernel kernel: hm, page 000a0000 reserved twice.
Mar 4 18:39:33 kernel kernel: On node 0 totalpages: 524160
Mar 4 18:39:33 kernel kernel: zone(0): 4096 pages.
Mar 4 18:39:33 kernel kernel: zone(1): 225280 pages.
Mar 4 18:39:33 kernel kernel: zone(2): 294784 pages.
Mar 4 18:39:33 kernel kernel: ACPI: Searched entire block, no RSDP was found.
Mar 4 18:39:33 kernel kernel: ACPI: RSDP located at physical address c00f70a0
Mar 4 18:39:33 kernel kernel: RSD PTR v0 [PTLTD ]
Mar 4 18:39:33 kernel kernel: __va_range(0x7fef850d, 0x68): idx=8 mapped at ffff6000
Mar 4 18:39:33 kernel kernel: ACPI table found: RSDT v1 [PTLTD RSDT 1540.0]
Mar 4 18:39:33 kernel kernel: __va_range(0x7fefbe78, 0x24): idx=8 mapped at ffff6000
Mar 4 18:39:33 kernel kernel: __va_range(0x7fefbe78, 0x74): idx=8 mapped at ffff6000
Mar 4 18:39:33 kernel kernel: ACPI table found: FACP v1 [INTEL K_CANYON 1540.0]
Mar 4 18:39:33 kernel autofs: automount startup succeeded
Mar 4 18:39:33 kernel kernel: __va_range(0x7fefbeec, 0x24): idx=8 mapped at ffff6000
Mar 4 18:39:33 kernel kernel: __va_range(0x7fefbeec, 0x9c): idx=8 mapped at ffff6000
Mar 4 18:39:33 kernel kernel: ACPI table found: APIC v1 [PTLTD ^I APIC 1540.0]
Mar 4 18:39:33 kernel kernel: __va_range(0x7fefbeec, 0x9c): idx=8 mapped at ffff6000
Mar 4 18:39:33 kernel kernel: LAPIC (acpi_id[0x0000] id[0x0] enabled[1])
Mar 4 18:39:34 kernel kernel: CPU 0 (0x0000) enabledProcessor #0 Pentium 4(tm) XEON(tm) APIC version 16
Mar 4 18:39:34 kernel kernel:
Mar 4 18:39:34 kernel kernel: LAPIC (acpi_id[0x0001] id[0x6] enabled[1])
Mar 4 18:39:34 kernel kernel: CPU 1 (0x0600) enabledProcessor #6 Pentium 4(tm) XEON(tm) APIC version 16
Mar 4 18:39:34 kernel kernel:
Mar 4 18:39:34 kernel kernel: LAPIC (acpi_id[0x0002] id[0x1] enabled[1])
Mar 4 18:39:34 kernel kernel: CPU 2 (0x0100) enabledProcessor #1 Pentium 4(tm) XEON(tm) APIC version 16
Mar 4 18:39:34 kernel kernel:
Mar 4 18:39:34 kernel kernel: LAPIC (acpi_id[0x0003] id[0x7] enabled[1])
Mar 4 18:39:34 kernel kernel: CPU 3 (0x0700) enabledProcessor #7 Pentium 4(tm) XEON(tm) APIC version 16
Mar 4 18:39:34 kernel kernel:
Mar 4 18:39:34 kernel kernel: IOAPIC (id[0x2] address[0xfec00000] global_irq_base[0x0])
Mar 4 18:39:34 kernel kernel: IOAPIC (id[0x3] address[0xfec80000] global_irq_base[0x18])
Mar 4 18:39:34 kernel kernel: IOAPIC (id[0x4] address[0xfec80400] global_irq_base[0x30])
Mar 4 18:39:34 kernel kernel: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x1] trigger[0x1])
Mar 4 18:39:34 kernel kernel: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x1] trigger[0x3])
Mar 4 18:39:34 kernel kernel: LAPIC_NMI (acpi_id[0x0000] polarity[0x1] trigger[0x1] lint[0x1])
Mar 4 18:39:34 kernel kernel: LAPIC_NMI (acpi_id[0x0001] polarity[0x1] trigger[0x1] lint[0x1])
Mar 4 18:39:34 kernel kernel: LAPIC_NMI (acpi_id[0x0002] polarity[0x1] trigger[0x1] lint[0x1])
Mar 4 18:39:34 kernel kernel: LAPIC_NMI (acpi_id[0x0003] polarity[0x1] trigger[0x1] lint[0x1])
Mar 4 18:39:34 kernel kernel: 4 CPUs total
Mar 4 18:39:34 kernel kernel: Local APIC address fee00000
Mar 4 18:39:34 kernel kernel: __va_range(0x7fefbf88, 0x24): idx=8 mapped at ffff6000
Mar 4 18:39:34 kernel kernel: __va_range(0x7fefbf88, 0x28): idx=8 mapped at ffff6000
Mar 4 18:39:34 kernel kernel: ACPI table found: BOOT v1 [PTLTD $SBFTBL$ 1540.0]
Mar 4 18:39:34 kernel kernel: __va_range(0x7fefbfb0, 0x24): idx=8 mapped at ffff6000
Mar 4 18:39:34 kernel kernel: __va_range(0x7fefbfb0, 0x50): idx=8 mapped at ffff6000
Mar 4 18:39:34 kernel kernel: ACPI table found: SPCR v1 [PTLTD $UCRTBL$ 1540.0]
Mar 4 18:39:34 kernel kernel: Enabling the CPU's according to the ACPI table
Mar 4 18:39:34 kernel kernel: Intel MultiProcessor Specification v1.4
Mar 4 18:39:34 kernel kernel: Virtual Wire compatibility mode.
Mar 4 18:39:34 kernel kernel: OEM ID: Product ID: Kings Canyon APIC at: 0xFEE00000
Mar 4 18:39:34 kernel kernel: I/O APIC #2 Version 32 at 0xFEC00000.
Mar 4 18:39:34 kernel kernel: I/O APIC #3 Version 32 at 0xFEC80000.
Mar 4 18:39:34 kernel kernel: I/O APIC #4 Version 32 at 0xFEC80400.
Mar 4 18:39:34 kernel kernel: Processors: 4
Mar 4 18:39:34 kernel kernel: Kernel command line: ro root=LABEL=/ pirq="58,57,56,55,54,53,52,51,50"
Mar 4 18:39:34 kernel kernel: PIRQ redirection, working around broken MP-BIOS.
Mar 4 18:39:34 kernel kernel: Initializing CPU#0
Mar 4 18:39:34 kernel sshd: Starting sshd:
Mar 4 18:39:34 kernel kernel: Detected 2395.865 MHz processor.
Mar 4 18:39:34 kernel kernel: Speakup v-1.00 CVS: Tue Jun 11 14:22:53 EDT 2002 : initialized
Mar 4 18:39:34 kernel kernel: Console: colour VGA+ 80x25
Mar 4 18:39:34 kernel kernel: Calibrating delay loop... 4750.85 BogoMIPS
Mar 4 18:39:34 kernel kernel: Memory: 2059336k/2096640k available (1451k kernel code, 32628k reserved, 1090k data, 200k init, 1179072k highmem)
Mar 4 18:39:34 kernel kernel: Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Mar 4 18:39:34 kernel kernel: Inode cache hash table entries: 131072 (order: 8, 1048576 bytes)
Mar 4 18:39:34 kernel kernel: Mount cache hash table entries: 32768 (order: 6, 262144 bytes)
Mar 4 18:39:34 kernel kernel: Buffer cache hash table entries: 131072 (order: 7, 524288 bytes)
Mar 4 18:39:34 kernel kernel: Page-cache hash table entries: 524288 (order: 9, 2097152 bytes)
Mar 4 18:39:34 kernel kernel: CPU: L1 I cache: 0K, L1 D cache: 8K
Mar 4 18:39:34 kernel kernel: CPU: L2 cache: 512K
Mar 4 18:39:34 kernel kernel: CPU: Physical Processor ID: 0
Mar 4 18:39:34 kernel kernel: Intel machine check architecture supported.
Mar 4 18:39:34 kernel kernel: Intel machine check reporting enabled on CPU#0.
Mar 4 18:39:34 kernel kernel: Enabling fast FPU save and restore... done.
Mar 4 18:39:34 kernel kernel: Enabling unmasked SIMD FPU exception support... done.
Mar 4 18:39:34 kernel kernel: Checking 'hlt' instruction... OK.
Mar 4 18:39:34 kernel kernel: POSIX conformance testing by UNIFIX
Mar 4 18:39:34 kernel kernel: mtrr: v1.40 (20010327) Richard Gooch ([email protected])
Mar 4 18:39:34 kernel kernel: mtrr: detected mtrr type: Intel
Mar 4 18:39:34 kernel kernel: CPU: L1 I cache: 0K, L1 D cache: 8K
Mar 4 18:39:34 kernel kernel: CPU: L2 cache: 512K
Mar 4 18:39:34 kernel kernel: CPU: Physical Processor ID: 0
Mar 4 18:39:34 kernel kernel: Intel machine check reporting enabled on CPU#0.
Mar 4 18:39:34 kernel kernel: CPU0: Intel(R) XEON(TM) CPU 2.40GHz stepping 04
Mar 4 18:39:34 kernel kernel: per-CPU timeslice cutoff: 1462.93 usecs.
Mar 4 18:39:34 kernel kernel: task migration cache decay timeout: 1 msecs.
Mar 4 18:39:34 kernel kernel: enabled ExtINT on CPU#0
Mar 4 18:39:34 kernel kernel: ESR value before enabling vector: 00000000
Mar 4 18:39:34 kernel kernel: ESR value after enabling vector: 00000000
Mar 4 18:39:34 kernel kernel: Booting processor 1/1 eip 2000
Mar 4 18:39:34 kernel kernel: Initializing CPU#1
Mar 4 18:39:34 kernel kernel: masked ExtINT on CPU#1
Mar 4 18:39:34 kernel kernel: ESR value before enabling vector: 00000000
Mar 4 18:39:34 kernel kernel: ESR value after enabling vector: 00000000
Mar 4 18:39:34 kernel kernel: Calibrating delay loop... 4784.26 BogoMIPS
Mar 4 18:39:34 kernel kernel: CPU: L1 I cache: 0K, L1 D cache: 8K
Mar 4 18:39:34 kernel kernel: CPU: L2 cache: 512K
Mar 4 18:39:34 kernel kernel: CPU: Physical Processor ID: 0
Mar 4 18:39:34 kernel kernel: Intel machine check reporting enabled on CPU#1.
Mar 4 18:39:34 kernel kernel: CPU1: Intel(R) XEON(TM) CPU 2.40GHz stepping 04
Mar 4 18:39:34 kernel kernel: Booting processor 2/6 eip 2000
Mar 4 18:39:34 kernel kernel: Initializing CPU#2
Mar 4 18:39:34 kernel kernel: masked ExtINT on CPU#2
Mar 4 18:39:34 kernel kernel: ESR value before enabling vector: 00000000
Mar 4 18:39:34 kernel kernel: ESR value after enabling vector: 00000000
Mar 4 18:39:34 kernel kernel: Calibrating delay loop... 4784.26 BogoMIPS
Mar 4 18:39:34 kernel kernel: CPU: L1 I cache: 0K, L1 D cache: 8K
Mar 4 18:39:34 kernel kernel: CPU: L2 cache: 512K
Mar 4 18:39:34 kernel kernel: CPU: Physical Processor ID: 3
Mar 4 18:39:34 kernel kernel: Intel machine check reporting enabled on CPU#2.
Mar 4 18:39:34 kernel kernel: CPU2: Intel(R) XEON(TM) CPU 2.40GHz stepping 04
Mar 4 18:39:34 kernel kernel: Booting processor 3/7 eip 2000
Mar 4 18:39:34 kernel kernel: Initializing CPU#3
Mar 4 18:39:34 kernel kernel: masked ExtINT on CPU#3
Mar 4 18:39:34 kernel kernel: ESR value before enabling vector: 00000000
Mar 4 18:39:34 kernel kernel: ESR value after enabling vector: 00000000
Mar 4 18:39:34 kernel kernel: Calibrating delay loop... 4784.26 BogoMIPS
Mar 4 18:39:34 kernel kernel: CPU: L1 I cache: 0K, L1 D cache: 8K
Mar 4 18:39:34 kernel kernel: CPU: L2 cache: 512K
Mar 4 18:39:34 kernel kernel: CPU: Physical Processor ID: 3
Mar 4 18:39:34 kernel kernel: Intel machine check reporting enabled on CPU#3.
Mar 4 18:39:34 kernel kernel: CPU3: Intel(R) XEON(TM) CPU 2.40GHz stepping 04
Mar 4 18:39:34 kernel kernel: Total of 4 processors activated (19103.65 BogoMIPS).
Mar 4 18:39:34 kernel kernel: cpu_sibling_map[0] = 1
Mar 4 18:39:34 kernel kernel: cpu_sibling_map[1] = 0
Mar 4 18:39:34 kernel kernel: cpu_sibling_map[2] = 3
Mar 4 18:39:34 kernel kernel: cpu_sibling_map[3] = 2
Mar 4 18:39:34 kernel kernel: ENABLING IO-APIC IRQs
Mar 4 18:39:34 kernel kernel: Setting 2 in the phys_id_present_map
Mar 4 18:39:34 kernel kernel: ...changing IO-APIC physical APIC ID to 2 ... ok.
Mar 4 18:39:34 kernel kernel: Setting 3 in the phys_id_present_map
Mar 4 18:39:34 kernel kernel: ...changing IO-APIC physical APIC ID to 3 ... ok.
Mar 4 18:39:34 kernel kernel: Setting 4 in the phys_id_present_map
Mar 4 18:39:34 kernel kernel: ...changing IO-APIC physical APIC ID to 4 ... ok.
Mar 4 18:39:34 kernel kernel: ..TIMER: vector=0x31 pin1=2 pin2=0
Mar 4 18:39:34 kernel kernel: testing the IO APIC.......................
Mar 4 18:39:34 kernel kernel:
Mar 4 18:39:34 kernel kernel: WARNING: unexpected IO-APIC, please mail
Mar 4 18:39:34 kernel kernel: to [email protected]
Mar 4 18:39:34 kernel kernel:
Mar 4 18:39:34 kernel kernel:
Mar 4 18:39:34 kernel kernel: .................................... done.
Mar 4 18:39:34 kernel kernel: Using local APIC timer interrupts.
Mar 4 18:39:34 kernel kernel: calibrating APIC timer ...
Mar 4 18:39:34 kernel kernel: ..... CPU clock speed is 2395.0997 MHz.
Mar 4 18:39:34 kernel kernel: ..... host bus clock speed is 99.1587 MHz.
Mar 4 18:39:34 kernel kernel: cpu: 0, clocks: 194934, slice: 38986
Mar 4 18:39:34 kernel kernel: CPU0<T0:194928,T1:155936,D:6,S:38986,C:194934>
Mar 4 18:39:34 kernel kernel: cpu: 1, clocks: 194934, slice: 38986
Mar 4 18:39:34 kernel kernel: cpu: 3, clocks: 194934, slice: 38986
Mar 4 18:39:34 kernel kernel: cpu: 2, clocks: 194934, slice: 38986
Mar 4 18:39:34 kernel kernel: CPU1<T0:194928,T1:116944,D:12,S:38986,C:194934>
Mar 4 18:39:34 kernel kernel: CPU2<T0:194928,T1:77968,D:2,S:38986,C:194934>
Mar 4 18:39:34 kernel kernel: CPU3<T0:194928,T1:38976,D:8,S:38986,C:194934>
Mar 4 18:39:34 kernel kernel: checking TSC synchronization across CPUs: passed.
Mar 4 18:39:34 kernel kernel: migration_task 0 on cpu=0
Mar 4 18:39:34 kernel kernel: migration_task 1 on cpu=1
Mar 4 18:39:34 kernel kernel: migration_task 2 on cpu=2
Mar 4 18:39:34 kernel kernel: migration_task 3 on cpu=3
Mar 4 18:39:34 kernel kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd8c5, last bus=5
Mar 4 18:39:34 kernel kernel: PCI: Using configuration type 1
Mar 4 18:39:34 kernel kernel: PCI: Probing PCI hardware
Mar 4 18:39:34 kernel kernel: Transparent bridge - Intel Corp. 82801BA/CA/DB PCI Bridge
Mar 4 18:39:34 kernel kernel: PCI: Discovered primary peer bus 10 [IRQ]
Mar 4 18:39:34 kernel kernel: PCI: Discovered primary peer bus 11 [IRQ]
Mar 4 18:39:34 kernel kernel: PCI: Discovered primary peer bus 12 [IRQ]
Mar 4 18:39:34 kernel kernel: PCI: Using IRQ router PIIX [8086/2480] at 00:1f.0
Mar 4 18:39:34 kernel kernel: PCI->APIC IRQ transform: (B0,I29,P0) -> 16
Mar 4 18:39:34 kernel kernel: PCI->APIC IRQ transform: (B0,I29,P1) -> 19
Mar 4 18:39:34 kernel kernel: PCI->APIC IRQ transform: (B0,I29,P2) -> 18
Mar 4 18:39:34 kernel kernel: PCI->APIC IRQ transform: (B3,I4,P0) -> 48
Mar 4 18:39:34 kernel kernel: PCI->APIC IRQ transform: (B3,I5,P1) -> 48
Mar 4 18:39:34 kernel kernel: PCI->APIC IRQ transform: (B3,I6,P2) -> 48
Mar 4 18:39:34 kernel kernel: PCI->APIC IRQ transform: (B3,I7,P3) -> 48
Mar 4 18:39:34 kernel kernel: PCI->APIC IRQ transform: (B4,I2,P2) -> 28
Mar 4 18:39:34 kernel kernel: PCI->APIC IRQ transform: (B4,I2,P3) -> 29
Mar 4 18:39:34 kernel kernel: PCI->APIC IRQ transform: (B4,I4,P0) -> 31
Mar 4 18:39:34 kernel kernel: PCI->APIC IRQ transform: (B5,I1,P1) -> 16
Mar 4 18:39:34 kernel kernel: PCI->APIC IRQ transform: (B5,I2,P2) -> 17
Mar 4 18:39:34 kernel kernel: isapnp: Scanning for PnP cards...
Mar 4 18:39:34 kernel kernel: isapnp: No Plug & Play device found
Mar 4 18:39:34 kernel kernel: speakup: initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
Mar 4 18:39:34 kernel kernel: Linux NET4.0 for Linux 2.4
Mar 4 18:39:34 kernel kernel: Based upon Swansea University Computer Society NET3.039
Mar 4 18:39:34 kernel kernel: Initializing RT netlink socket
Mar 4 18:39:34 kernel kernel: apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16)
Mar 4 18:39:34 kernel kernel: apm: disabled - APM is not SMP safe.
Mar 4 18:39:34 kernel kernel: Starting kswapd
Mar 4 18:39:34 kernel kernel: allocated 64 pages and 64 bhs reserved for the highmem bounces
Mar 4 18:39:34 kernel kernel: VFS: Diskquotas version dquot_6.5.0 initialized
Mar 4 18:39:34 kernel kernel: Detected PS/2 Mouse Port.
Mar 4 18:39:34 kernel kernel: pty: 2048 Unix98 ptys configured
Mar 4 18:39:34 kernel kernel: Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
Mar 4 18:39:34 kernel kernel: ttyS0 at 0x03f8 (irq = 4) is a 16550A
Mar 4 18:39:34 kernel kernel: ttyS1 at 0x02f8 (irq = 3) is a 16550A
Mar 4 18:39:34 kernel kernel: Real Time Clock Driver v1.10e
Mar 4 18:39:34 kernel kernel: oprofile: can't get RTC I/O Ports
Mar 4 18:39:34 kernel kernel: block: 1024 slots per queue, batch=256
Mar 4 18:39:34 kernel kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31
Mar 4 18:39:34 kernel kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Mar 4 18:39:34 kernel kernel: PIIX4: IDE controller on PCI bus 00 dev f9
Mar 4 18:39:35 kernel kernel: PCI: No IRQ known for interrupt pin A of device 00:1f.1. Probably buggy MP table.
Mar 4 18:39:35 kernel kernel: PIIX4: chipset revision 2
Mar 4 18:39:35 kernel kernel: PIIX4: not 100%% native mode: will probe irqs later
Mar 4 18:39:35 kernel kernel: ide0: BM-DMA at 0x1460-0x1467, BIOS settings: hda:pio, hdb:pio
Mar 4 18:39:35 kernel kernel: ide1: BM-DMA at 0x1468-0x146f, BIOS settings: hdc:pio, hdd:pio
Mar 4 18:39:35 kernel kernel: hdc: MATSHITA CR-177, ATAPI CD/DVD-ROM drive
Mar 4 18:39:35 kernel kernel: ide1 at 0x170-0x177,0x376 on irq 15
Mar 4 18:39:35 kernel kernel: ide-floppy driver 0.99.newide
Mar 4 18:39:35 kernel kernel: Floppy drive(s): fd0 is 1.44M
Mar 4 18:39:35 kernel kernel: FDC 0 is a post-1991 82077
Mar 4 18:39:35 kernel kernel: NET4: Frame Diverter 0.46
Mar 4 18:39:35 kernel kernel: RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Mar 4 18:39:35 kernel kernel: ide-floppy driver 0.99.newide
Mar 4 18:39:35 kernel kernel: md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
Mar 4 18:39:35 kernel kernel: md: Autodetecting RAID arrays.
Mar 4 18:39:35 kernel kernel: md: autorun ...
Mar 4 18:39:35 kernel kernel: md: ... autorun DONE.
Mar 4 18:39:35 kernel kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.4
Mar 4 18:39:35 kernel kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Mar 4 18:39:35 kernel kernel: IP Protocols: ICMP, UDP, TCP, IGMP
Mar 4 18:39:35 kernel kernel: IP: routing cache hash table of 16384 buckets, 128Kbytes
Mar 4 18:39:35 kernel kernel: TCP: Hash tables configured (established 262144 bind 65536)
Mar 4 18:39:35 kernel kernel: Linux IP multicast router 0.06 plus PIM-SM
Mar 4 18:39:35 kernel kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Mar 4 18:39:35 kernel kernel: RAMDISK: Compressed image found at block 0
Mar 4 18:39:35 kernel kernel: Freeing initrd memory: 257k freed
Mar 4 18:39:35 kernel kernel: VFS: Mounted root (ext2 filesystem).
Mar 4 18:39:35 kernel kernel: SCSI subsystem driver Revision: 1.00
Mar 4 18:39:35 kernel kernel: kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
Mar 4 18:39:35 kernel kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
Mar 4 18:39:35 kernel kernel: <Adaptec aic7899 Ultra160 SCSI adapter>
Mar 4 18:39:35 kernel kernel: aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
Mar 4 18:39:35 kernel kernel:
Mar 4 18:39:35 kernel kernel: scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
Mar 4 18:39:35 kernel kernel: <Adaptec aic7899 Ultra160 SCSI adapter>
Mar 4 18:39:35 kernel kernel: aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
Mar 4 18:39:35 kernel kernel:
Mar 4 18:39:35 kernel kernel: blk: queue c45f8418, I/O limit 4095Mb (mask 0xffffffff)
Mar 4 18:39:35 kernel kernel: Vendor: SEAGATE Model: ST336607LC Rev: 0004
Mar 4 18:39:35 kernel kernel: Type: Direct-Access ANSI SCSI revision: 03
Mar 4 18:39:35 kernel kernel: blk: queue c2d9fe18, I/O limit 4095Mb (mask 0xffffffff)
Mar 4 18:39:35 kernel kernel: Vendor: SDR Model: GEM318 Rev: 0
Mar 4 18:39:35 kernel kernel: Type: Processor ANSI SCSI revision: 02
Mar 4 18:39:35 kernel kernel: blk: queue c2d7cc18, I/O limit 4095Mb (mask 0xffffffff)
Mar 4 18:39:35 kernel kernel: scsi0:A:1:0: Tagged Queuing enabled. Depth 253
Mar 4 18:39:35 kernel kernel: blk: queue c2d7cc18, I/O limit 4095Mb (mask 0xffffffff)
Mar 4 18:39:35 kernel kernel: Attached scsi disk sda at scsi0, channel 0, id 1, lun 0
Mar 4 18:39:35 kernel kernel: (scsi0:A:1): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Mar 4 18:39:35 kernel kernel: SCSI device sda: 71687372 512-byte hdwr sectors (36704 MB)
Mar 4 18:39:35 kernel kernel: Partition check:
Mar 4 18:39:35 kernel kernel: sda: sda1 sda2 sda3
Mar 4 18:39:35 kernel kernel: Journalled Block Device driver loaded
Mar 4 18:39:35 kernel kernel: kjournald starting. Commit interval 5 seconds
Mar 4 18:39:35 kernel kernel: EXT3-fs: mounted filesystem with ordered data mode.
Mar 4 18:39:35 kernel kernel: Freeing unused kernel memory: 200k freed
Mar 4 18:39:35 kernel kernel: EXT3 FS 2.4-0.9.18, 14 May 2002 on sd(8,3), internal journal
Mar 4 18:39:35 kernel kernel: Adding Swap: 2040244k swap-space (priority -1)
Mar 4 18:39:35 kernel kernel: kjournald starting. Commit interval 5 seconds
Mar 4 18:39:35 kernel kernel: EXT3 FS 2.4-0.9.18, 14 May 2002 on sd(8,1), internal journal
Mar 4 18:39:35 kernel kernel: EXT3-fs: mounted filesystem with ordered data mode.
Mar 4 18:39:35 kernel kernel: ohci1394: pci_module_init failed
Mar 4 18:39:35 kernel kernel: ip_tables: (C) 2000-2002 Netfilter core team
Mar 4 18:39:35 kernel kernel: ip_conntrack (8192 buckets, 65536 max)
Mar 4 18:39:35 kernel kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
Mar 4 18:39:35 kernel kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[email protected]> and others
Mar 4 18:39:35 kernel kernel: eth0: OEM i82557/i82558 10/100 Ethernet, 00:30:48:24:B9:2B, IRQ 17.
Mar 4 18:39:35 kernel kernel: Board assembly 000000-000, Physical connectors present: RJ45
Mar 4 18:39:35 kernel kernel: Primary interface chip i82555 PHY #1.
Mar 4 18:39:35 kernel kernel: General self-test: passed.
Mar 4 18:39:35 kernel kernel: Serial sub-system self-test: passed.
Mar 4 18:39:35 kernel kernel: Internal registers self-test: passed.
Mar 4 18:39:35 kernel kernel: ROM checksum self-test: passed (0xb874c1d3).
Mar 4 18:39:35 kernel sshd: succeeded
Mar 4 18:39:35 kernel sshd:
Mar 4 18:39:35 kernel rc: Starting sshd: succeeded
Mar 4 18:39:11 kernel rc.sysinit: Mounting proc filesystem: succeeded
Mar 4 18:39:11 kernel rc.sysinit: Unmounting initrd: succeeded
Mar 4 18:39:11 kernel sysctl: net.ipv4.conf.all.send_redirects = 0
Mar 4 18:39:11 kernel sysctl: net.ipv4.conf.all.secure_redirects = 0
Mar 4 18:39:11 kernel sysctl: net.ipv4.conf.all.accept_redirects = 0
Mar 4 18:39:11 kernel sysctl: net.ipv4.conf.all.accept_source_route = 0
Mar 4 18:39:11 kernel sysctl: net.ipv4.icmp_echo_ignore_broadcasts = 1
Mar 4 18:39:11 kernel sysctl: net.ipv4.ip_forward = 0
Mar 4 18:39:11 kernel sysctl: net.ipv4.conf.default.rp_filter = 1
Mar 4 18:39:11 kernel sysctl: kernel.sysrq = 0
Mar 4 18:39:11 kernel sysctl: kernel.core_uses_pid = 1
Mar 4 18:39:11 kernel rc.sysinit: Configuring kernel parameters: succeeded
Mar 4 18:39:11 kernel date: Tue Mar 4 18:39:11 CET 2003
Mar 4 18:39:11 kernel rc.sysinit: Setting clock (localtime): Tue Mar 4 18:39:11 CET 2003 succeeded
Mar 4 18:39:11 kernel rc.sysinit: Loading default keymap succeeded
Mar 4 18:39:11 kernel rc.sysinit: Setting default font (latarcyrheb-sun16): succeeded
Mar 4 18:39:11 kernel rc.sysinit: Setting hostname kernel.netland.nl: succeeded
Mar 4 18:39:11 kernel rc.sysinit: Remounting root filesystem in read-write mode: succeeded
Mar 4 18:39:35 kernel crond: crond startup succeeded
Mar 4 18:39:11 kernel rc.sysinit: Activating swap partitions: succeeded
Mar 4 18:39:13 kernel rc.sysinit: Finding module dependencies: succeeded
Mar 4 18:39:13 kernel rc.sysinit: Mounting local filesystems: succeeded
Mar 4 18:39:36 kernel anacron: anacron startup succeeded
Mar 4 18:39:13 kernel rc.sysinit: Enabling local filesystem quotas: succeeded
Mar 4 18:39:14 kernel rc.sysinit: Enabling swap space: succeeded
Mar 4 18:39:15 kernel init: Entering runlevel: 3
Mar 4 18:39:16 kernel kudzu: Updating /etc/fstab succeeded
Mar 4 18:39:30 kernel kudzu: succeeded
Mar 4 18:39:30 kernel rc: Starting iptables: succeeded
Mar 4 18:39:30 kernel S10firewall[220]: Firewall starting
Mar 4 18:39:30 kernel S10firewall[220]: Firewall started
Mar 4 18:39:30 kernel rc: Starting firewall: succeeded
Mar 4 18:39:30 kernel sysctl: net.ipv4.conf.all.send_redirects = 0
Mar 4 18:39:30 kernel sysctl: net.ipv4.conf.all.secure_redirects = 0
Mar 4 18:39:30 kernel sysctl: net.ipv4.conf.all.accept_redirects = 0
Mar 4 18:39:30 kernel sysctl: net.ipv4.conf.all.accept_source_route = 0
Mar 4 18:39:30 kernel sysctl: net.ipv4.icmp_echo_ignore_broadcasts = 1
Mar 4 18:39:30 kernel sysctl: net.ipv4.ip_forward = 0
Mar 4 18:39:30 kernel sysctl: net.ipv4.conf.default.rp_filter = 1
Mar 4 18:39:30 kernel sysctl: kernel.sysrq = 0
Mar 4 18:39:30 kernel sysctl: kernel.core_uses_pid = 1
Mar 4 18:39:30 kernel network: Setting network parameters: succeeded
Mar 4 18:39:31 kernel network: Bringing up loopback interface: succeeded
Mar 4 18:39:33 kernel network: Bringing up interface eth0: succeeded
On Mon, 3 Mar 2003, Ivan Kokshaysky wrote:
> On Sun, Mar 02, 2003 at 12:44:06PM -0500, jamal wrote:
> > Interupt routing as can be seen above is really messed for that device.
>
> Indeed. Quad tulip cards usually have irq pin A of each chip routed
> to pins A-D on the connector, so they cannot have the same irq unless
Incorrect.
Most quad Tulip boards have the bus bridge wired so that all interrupts
are sent on the INTA output of the board.
The tulip.c driver has worked around the BIOS bug on x86 machines for
years. It should really be handled in the generic PCI quirks code, but
has not yet been correctly handled in the kernel's code.
--
Donald Becker [email protected]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Scyld Beowulf cluster system
Annapolis MD 21403 410-990-9993
On Tue, Mar 04, 2003 at 06:54:02PM +0100, Ron Arts wrote:
> It may not be complete, so I also included part of /var/log/messages.
It's complete, thanks.
> IO APIC #4......
...
> .... IRQ redirection table:
> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
> 00 00F 0F 1 1 0 1 0 1 1 C1
> 01 000 00 1 0 0 0 0 0 0 00
> 02 000 00 1 0 0 0 0 0 0 00
> 03 000 00 1 0 0 0 0 0 0 00
...
> IRQ to pin mappings:
...
> IRQ48 -> 2:0
Indeed, looks like only pin 0 (INT_A of that card) is connected. :-(
Ivan.
On Tue, 4 Mar 2003, Ivan Kokshaysky wrote:
>
> Indeed, looks like only pin 0 (INT_A of that card) is connected. :-(
Well, I'd say it looks like the MP table _claims_ that only pin0 is
connected. Remember: the claim was that this machine worked on WinXP.
So there are at least two potential reasons for that:
- The MP table is simply wrong, and WinXP gets the routing information
from somewhere else (ie most likely ACPI)
- The MP table is right, and only pin0 is connected, and WinXP only uses
pin0 (ie it puts the card in some state where all irqs are shared
across all of the four tulip chips).
Maybe somebody can come up with other schenarios.
It would be interesting to hear what "Device Manager" (or whatever it is
called) unde WinXP claims the interrupts are on this machine... Are they
all on irq 48 on XP too? Or has XP gotten magic knowledge somewhere
(ACPI?) and they are on different irq's?
Linus
Linus Torvalds wrote:
> On Tue, 4 Mar 2003, Ivan Kokshaysky wrote:
>
>>Indeed, looks like only pin 0 (INT_A of that card) is connected. :-(
>
>
> Well, I'd say it looks like the MP table _claims_ that only pin0 is
> connected. Remember: the claim was that this machine worked on WinXP.
>
Well, I submitted the dmseg and messages because Jamal requested
it (same motherboard, same 4-port card and same strange IRQ
assignments), but this particular machine is not tested with XP,
and I don't think we have that.
I think we still have a disk with Win2000 on it. Would that help?
Should have to wait until tomorrow though, I'm on Central European Time,
and the machine is located elsewhere.
Ron
> So there are at least two potential reasons for that:
>
> - The MP table is simply wrong, and WinXP gets the routing information
> from somewhere else (ie most likely ACPI)
>
> - The MP table is right, and only pin0 is connected, and WinXP only uses
> pin0 (ie it puts the card in some state where all irqs are shared
> across all of the four tulip chips).
>
> Maybe somebody can come up with other schenarios.
>
> It would be interesting to hear what "Device Manager" (or whatever it is
> called) unde WinXP claims the interrupts are on this machine... Are they
> all on irq 48 on XP too? Or has XP gotten magic knowledge somewhere
> (ACPI?) and they are on different irq's?
>
> Linus
I added the following line just before "return best_guess;" in the
io_apic.c file:
printk("IO_APIC: APIC:%d, BUS:%d, SLOT:%d, IRQ BEST_GUESS: %d\n",apic, bus,
slot, best_guess);
I also increased the size of the kernel syslog ring buffer so the important
information would not be lost.
Here is the whole messages file including the debug output (search for
BEST_GUESS):
(See attached file: msg)
I'll try the ACPI irq lookup stuff to see if it makes a difference.
David
Linus Torvalds
<torvalds@transm To:
[email protected]
eta.com> cc: Ivan Kokshaysky
<[email protected]>, <[email protected]>,
Donald
Becker <[email protected]>,
Greg KH <[email protected]>, jamal <[email protected]>,
Jeff
03/04/2003 11:41 Garzik <[email protected]>,
<[email protected]>,
<[email protected]>,
AM <[email protected]>,
Robert Olsson <[email protected]>
Subject: Re: PCI init issues
On Tue, 4 Mar 2003 [email protected] wrote:
>
> Here is the full messages output for a system with this problem. I
had
> only provided part of the
> messages file to him earlier. This is the entire output.
Well, the interesting parts are missing, because your klogd output has
been truncated due to the huge output from the md layer etc. However, I
suspect strongly that the issue is in IO_APIC_get_PCI_irq_vector() in
arch/i386/kernel/io_apic.c, and I would further guess that it's the fact
that your MP tables don't have the full mapping or we're somehow screwing
it up.
Can you add a printk() to the case where we return "best_guess" at the end
of that function? We have that fuzzy match thing where if we cannot find
the exact entry in the MP table we instead use the first entry that
matches in everything but the <pin> number, and it would be interesting to
hear if that's the logic that triggers.
It's also quite possible that your MP tables just aren't right, and the
reason XP works on the machine is that XP uses the ACPI irq lookup stuff.
You could try enabling ACPI bootup support (I've never used it on 2.4.x
myself, but it's required for at least one of my machines and works fine
on 2.5.x).
Linus
(See attached file: msg)
On Tue, Mar 04, 2003 at 01:16:22PM -0500, Donald Becker wrote:
> Incorrect.
> Most quad Tulip boards have the bus bridge wired so that all interrupts
> are sent on the INTA output of the board.
This can be true for older cards, but post-1998 hardware must follow
the spec.
PCI-to-PCI Bridge Architecture Specification, Rev 1.1, Dec 18, 1998,
pp 113-114:
"... The interrupt binding defined in this table is mandatory for
expansion boards utilizing a bridge.
[table skipped]
Device 0 on a secondary bus will have its INTA# line connected to
the INTA# line of the connector. Device 1 will have its INTA# line
connected to INTB# of the connector. This sequence continues and
then wraps around once INTD# has been assigned."
I know for a fact that at least D-Link card mentioned in some reports
utilizes all four INT# lines, because I have one.
Ivan.
On Tue, Mar 04, 2003 at 10:54:21AM -0800, Linus Torvalds wrote:
> Well, I'd say it looks like the MP table _claims_ that only pin0 is
> connected. Remember: the claim was that this machine worked on WinXP.
It seems that "IRQ redirection table" is gathered directly from
IO_APIC hardware (I may be wrong though), and it conforms to other
data...
> So there are at least two potential reasons for that:
>
> - The MP table is simply wrong, and WinXP gets the routing information
> from somewhere else (ie most likely ACPI)
>
> - The MP table is right, and only pin0 is connected, and WinXP only uses
> pin0 (ie it puts the card in some state where all irqs are shared
> across all of the four tulip chips).
>
> Maybe somebody can come up with other schenarios.
- XP is able to reprogramm the IO_APIC so that all four pins are
routed properly.
Sounds a bit heretical, I know. :-)
Ivan.
On Tue, 4 Mar 2003, Ron Arts wrote:
> > So there are at least two potential reasons for that:
> >
> > - The MP table is simply wrong, and WinXP gets the routing information
> > from somewhere else (ie most likely ACPI)
> >
> > - The MP table is right, and only pin0 is connected, and WinXP only uses
> > pin0 (ie it puts the card in some state where all irqs are shared
> > across all of the four tulip chips).
> >
> > Maybe somebody can come up with other schenarios.
> >
> > It would be interesting to hear what "Device Manager" (or whatever it is
> > called) unde WinXP claims the interrupts are on this machine... Are they
> > all on irq 48 on XP too? Or has XP gotten magic knowledge somewhere
> > (ACPI?) and they are on different irq's?
> >
> > Linus
How about using 'mptable' (Authored by Pete Zaitcev) to view the
bus,pin and ioapic layout? It showed all the INTA,B,C,D pins on a
troublesome system of mine and helped track down the problem.
http://people.redhat.com/zaitcev/linux/mptable-2.0.15a-1.i386.rpm
http://people.redhat.com/zaitcev/linux/mptable-2.0.15a-1.src.rpm
Regards,
Zwane
--
function.linuxpower.ca
Hello!
> I know for a fact that at least D-Link card mentioned in some reports
> utilizes all four INT# lines, because I have one.
I confirm, my Znyx card (pci subsys 110d:0029) is wired correctly to INTA/B/C/D
and works nicely with plain flat motherboards.
Look at Jamal's mail: the cards work well when attached to primary
bus. They stop to work when connected via one more bridge (which is
common for server motherboards).
Alexey
Hello!
> - XP is able to reprogramm the IO_APIC so that all four pins are
> routed properly.
>
> Sounds a bit heretical, I know. :-)
Let me to cite message from Znyx engineer.
>>The question is important. Looking into our implemenation, I see
>>that it is strongly bound to correctness of mp table.
>
>We had a similar problem in about 1994, when we designed
>the first multi-port adapters with a bridge. Most BIOSes at that
>point did not initialize PPBs, or they did not do it correctly. We
>decided to build the required support into our drivers. That meant
>that some vendors with broken BIOS would point to us and say 'see
>it works'. Our advantage in selling these people adapters, but
>maybe it took a bit longer for the market to force vendors to fix
>BIOSes.
So, maybe the workaround is in znyx driver for XP. :-)
BIOSes were fixed to understand the first level bridges,
but I guess none of them construct correct tables
for second level bridges.
Alexey
===============================================================================
MPTable, version 2.0.15 Linux
-------------------------------------------------------------------------------
MP Floating Pointer Structure:
location: BIOS
physical address: 0x000f7040
signature: '_MP_'
length: 16 bytes
version: 1.4
checksum: 0x2e
mode: Virtual Wire
-------------------------------------------------------------------------------
MP Config Table Header:
physical address: 0x0x9f970
signature: 'PCMP'
base table length: 412
version: 1.4
checksum: 0x5b
OEM ID: ' '
Product ID: 'Kings Canyon'
OEM table pointer: 0x00000000
OEM table size: 0
entry count: 40
local APIC address: 0xfee00000
extended table length: 0
extended table checksum: 0
-------------------------------------------------------------------------------
MP Config Base Table Entries:
--
Processors: APIC ID Version State Family Model Step Flags
0 0x14 BSP, usable 15 2 4 0x3febfbff
6 0x14 AP, usable 15 2 4 0x3febfbff
1 0x14 AP, usable 15 2 4 0x3febfbff
7 0x14 AP, usable 15 2 4 0x3febfbff
--
Bus: Bus ID Type
0 PCI
1 PCI
2 PCI
3 PCI
4 PCI
5 PCI
6 ISA
--
I/O APICs: APIC ID Version State Address
2 0x20 usable 0xfec00000
3 0x20 usable 0xfec80000
4 0x20 usable 0xfec80400
--
I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#
ExtINT active-hi edge 6 0 2 0
INT active-hi edge 6 1 2 1
INT active-hi edge 6 0 2 2
INT active-hi edge 6 3 2 3
INT active-hi edge 6 4 2 4
INT active-hi edge 6 5 2 5
INT active-hi edge 6 6 2 6
INT active-lo level 0 29:C 2 18
INT active-hi edge 6 8 2 8
INT active-hi edge 6 9 2 9
INT active-lo level 0 29:B 2 19
INT active-lo level 0 29:A 2 16
INT active-lo level 5 2:A 2 17
INT active-hi edge 6 13 2 13
INT active-hi edge 6 14 2 14
INT active-hi edge 6 15 2 15
INT active-lo level 3 4:A 4 0
INT active-lo level 3 5:A 4 0
INT active-lo level 3 6:A 4 0
INT active-lo level 3 7:A 4 0
INT active-lo level 4 2:A 3 4
INT active-lo level 4 2:B 3 5
INT active-lo level 4 4:A 3 7
INT active-lo level 5 1:A 2 16
--
Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#
ExtINT active-hi edge 6 0 255 0
NMI active-hi edge 6 0 255 1
-------------------------------------------------------------------------------
dmesg output:
(TM) CPU 2.40GHz stepping 04
Total of 4 processors activated (19103.65 BogoMIPS).
cpu_sibling_map[0] = 1
cpu_sibling_map[1] = 0
cpu_sibling_map[2] = 3
cpu_sibling_map[3] = 2
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
Setting 3 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 3 ... ok.
Setting 4 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 4 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-7, 2-10, 2-11, 2-12, 2-20, 2-21, 2-22, 2-23, 3-0, 3-1, 3-2, 3-3, 3-6, 3-8, 3-9, 3-10, 3-11, 3-12, 3-13, 3-14, 3-15, 3-16, 3-17, 3-18, 3-19, 3-20, 3-21, 3-22, 3-23, 4-1, 4-2, 4-3, 4-4, 4-5, 4-6, 4-7, 4-8, 4-9, 4-10, 4-11, 4-12, 4-13, 4-14, 4-15, 4-16, 4-17, 4-18, 4-19, 4-20, 4-21, 4-22, 4-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 24.
number of IO-APIC #2 registers: 24.
number of IO-APIC #3 registers: 24.
number of IO-APIC #4 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02008000
....... : physical APIC id: 02
WARNING: unexpected IO-APIC, please mail
to [email protected]
.... register #01: 00178020
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0020
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 00F 0F 0 0 0 0 0 1 1 39
02 008 08 0 0 0 0 0 1 1 31
03 00F 0F 0 0 0 0 0 1 1 41
04 00F 0F 0 0 0 0 0 1 1 49
05 00F 0F 0 0 0 0 0 1 1 51
06 00F 0F 0 0 0 0 0 1 1 59
07 000 00 1 0 0 0 0 0 0 00
08 00F 0F 0 0 0 0 0 1 1 61
09 00F 0F 0 0 0 0 0 1 1 69
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 00F 0F 0 0 0 0 0 1 1 71
0e 00F 0F 0 0 0 0 0 1 1 79
0f 00F 0F 0 0 0 0 0 1 1 81
10 00F 0F 1 1 0 1 0 1 1 89
11 00F 0F 1 1 0 1 0 1 1 91
12 00F 0F 1 1 0 1 0 1 1 99
13 00F 0F 1 1 0 1 0 1 1 A1
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IO APIC #3......
.... register #00: 03000000
....... : physical APIC id: 03
.... register #01: 00178020
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0020
.... register #02: 03000000
....... : arbitration: 03
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 000 00 1 0 0 0 0 0 0 00
02 000 00 1 0 0 0 0 0 0 00
03 000 00 1 0 0 0 0 0 0 00
04 00F 0F 1 1 0 1 0 1 1 A9
05 00F 0F 1 1 0 1 0 1 1 B1
06 000 00 1 0 0 0 0 0 0 00
07 00F 0F 1 1 0 1 0 1 1 B9
08 000 00 1 0 0 0 0 0 0 00
09 000 00 1 0 0 0 0 0 0 00
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 000 00 1 0 0 0 0 0 0 00
0e 000 00 1 0 0 0 0 0 0 00
0f 000 00 1 0 0 0 0 0 0 00
10 000 00 1 0 0 0 0 0 0 00
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IO APIC #4......
.... register #00: 04000000
....... : physical APIC id: 04
.... register #01: 00178020
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0020
.... register #02: 04000000
....... : arbitration: 04
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 00F 0F 1 1 0 1 0 1 1 C1
01 000 00 1 0 0 0 0 0 0 00
02 000 00 1 0 0 0 0 0 0 00
03 000 00 1 0 0 0 0 0 0 00
04 000 00 1 0 0 0 0 0 0 00
05 000 00 1 0 0 0 0 0 0 00
06 000 00 1 0 0 0 0 0 0 00
07 000 00 1 0 0 0 0 0 0 00
08 000 00 1 0 0 0 0 0 0 00
09 000 00 1 0 0 0 0 0 0 00
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 000 00 1 0 0 0 0 0 0 00
0e 000 00 1 0 0 0 0 0 0 00
0f 000 00 1 0 0 0 0 0 0 00
10 000 00 1 0 0 0 0 0 0 00
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ18 -> 0:18
IRQ19 -> 0:19
IRQ28 -> 1:4
IRQ29 -> 1:5
IRQ31 -> 1:7
IRQ48 -> 2:0
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 2395.0997 MHz.
..... host bus clock speed is 99.1587 MHz.
cpu: 0, clocks: 194934, slice: 38986
CPU0<T0:194928,T1:155936,D:6,S:38986,C:194934>
cpu: 1, clocks: 194934, slice: 38986
cpu: 3, clocks: 194934, slice: 38986
cpu: 2, clocks: 194934, slice: 38986
CPU1<T0:194928,T1:116944,D:12,S:38986,C:194934>
CPU2<T0:194928,T1:77968,D:2,S:38986,C:194934>
CPU3<T0:194928,T1:38976,D:8,S:38986,C:194934>
checking TSC synchronization across CPUs: passed.
migration_task 0 on cpu=0
migration_task 1 on cpu=1
migration_task 2 on cpu=2
migration_task 3 on cpu=3
PCI: PCI BIOS revision 2.10 entry at 0xfd8c5, last bus=5
PCI: Using configuration type 1
PCI: Probing PCI hardware
Transparent bridge - Intel Corp. 82801BA/CA/DB PCI Bridge
PCI: Discovered primary peer bus 10 [IRQ]
PCI: Discovered primary peer bus 11 [IRQ]
PCI: Discovered primary peer bus 12 [IRQ]
PCI: Using IRQ router PIIX [8086/2480] at 00:1f.0
PCI->APIC IRQ transform: (B0,I29,P0) -> 16
PCI->APIC IRQ transform: (B0,I29,P1) -> 19
PCI->APIC IRQ transform: (B0,I29,P2) -> 18
PCI->APIC IRQ transform: (B3,I4,P0) -> 48
PCI->APIC IRQ transform: (B3,I5,P1) -> 48
PCI->APIC IRQ transform: (B3,I6,P2) -> 48
PCI->APIC IRQ transform: (B3,I7,P3) -> 48
PCI->APIC IRQ transform: (B4,I2,P2) -> 28
PCI->APIC IRQ transform: (B4,I2,P3) -> 29
PCI->APIC IRQ transform: (B4,I4,P0) -> 31
PCI->APIC IRQ transform: (B5,I1,P1) -> 16
PCI->APIC IRQ transform: (B5,I2,P2) -> 17
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
speakup: initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16)
apm: disabled - APM is not SMP safe.
Starting kswapd
allocated 64 pages and 64 bhs reserved for the highmem bounces
VFS: Diskquotas version dquot_6.5.0 initialized
Detected PS/2 Mouse Port.
pty: 2048 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS0 at 0x03f8 (irq = 4) is a 16550A
ttyS1 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10e
oprofile: can't get RTC I/O Ports
block: 1024 slots per queue, batch=256
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev f9
PCI: No IRQ known for interrupt pin A of device 00:1f.1. Probably buggy MP table.
PIIX4: chipset revision 2
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1460-0x1467, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x1468-0x146f, BIOS settings: hdc:pio, hdd:pio
hdc: MATSHITA CR-177, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
ide-floppy driver 0.99.newide
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
NET4: Frame Diverter 0.46
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
ide-floppy driver 0.99.newide
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
pci_hotplug: PCI Hot Plug PCI Core version: 0.4
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 16384 buckets, 128Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 257k freed
VFS: Mounted root (ext2 filesystem).
SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
blk: queue c45f8418, I/O limit 4095Mb (mask 0xffffffff)
Vendor: SEAGATE Model: ST336607LC Rev: 0004
Type: Direct-Access ANSI SCSI revision: 03
blk: queue c2d9fe18, I/O limit 4095Mb (mask 0xffffffff)
Vendor: SDR Model: GEM318 Rev: 0
Type: Processor ANSI SCSI revision: 02
blk: queue c2d7cc18, I/O limit 4095Mb (mask 0xffffffff)
scsi0:A:1:0: Tagged Queuing enabled. Depth 253
blk: queue c2d7cc18, I/O limit 4095Mb (mask 0xffffffff)
Attached scsi disk sda at scsi0, channel 0, id 1, lun 0
(scsi0:A:1): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sda: 71687372 512-byte hdwr sectors (36704 MB)
Partition check:
sda: sda1 sda2 sda3
Journalled Block Device driver loaded
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Freeing unused kernel memory: 200k freed
EXT3 FS 2.4-0.9.18, 14 May 2002 on sd(8,3), internal journal
Adding Swap: 2040244k swap-space (priority -1)
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.18, 14 May 2002 on sd(8,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ohci1394: pci_module_init failed
ip_tables: (C) 2000-2002 Netfilter core team
ip_conntrack (8192 buckets, 65536 max)
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[email protected]> and others
divert: allocating divert_blk for eth0
eth0: OEM i82557/i82558 10/100 Ethernet, 00:30:48:24:B9:2B, IRQ 17.
Board assembly 000000-000, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0xb874c1d3).
iptables: LDROP IN=eth0 OUT= MAC=00:30:48:24:b9:2b:00:c0:95:e0:a2:fa:08:00 SRC=211.184.226.193 DST=217.170.33.118 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=10288 DF PROTO=TCP SPT=42855 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
iptables: LDROP IN=eth0 OUT= MAC=00:30:48:24:b9:2b:00:c0:95:e0:a2:fa:08:00 SRC=211.184.226.193 DST=217.170.33.118 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=10289 DF PROTO=TCP SPT=42855 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
iptables: LDROP IN=eth0 OUT= MAC=00:30:48:24:b9:2b:00:c0:95:e0:a2:fa:08:00 SRC=64.191.52.220 DST=217.170.33.118 LEN=40 TOS=0x10 PREC=0x00 TTL=242 ID=37872 PROTO=TCP SPT=60142 DPT=3128 WINDOW=16384 RES=0x00 SYN URGP=0
iptables: LDROP IN=eth0 OUT= MAC=00:30:48:24:b9:2b:00:c0:95:e0:a2:fa:08:00 SRC=64.191.52.220 DST=217.170.33.118 LEN=40 TOS=0x10 PREC=0x00 TTL=242 ID=9057 PROTO=TCP SPT=19241 DPT=6588 WINDOW=16384 RES=0x00 SYN URGP=0
iptables: LDROP IN=eth0 OUT= MAC=00:30:48:24:b9:2b:00:c0:95:e0:a2:fa:08:00 SRC=64.191.52.220 DST=217.170.33.118 LEN=40 TOS=0x10 PREC=0x00 TTL=242 ID=37385 PROTO=TCP SPT=20112 DPT=8080 WINDOW=16384 RES=0x00 SYN URGP=0
iptables: LDROP IN=eth0 OUT= MAC=00:30:48:24:b9:2b:00:c0:95:e0:a2:fa:08:00 SRC=211.41.128.70 DST=217.170.33.118 LEN=40 TOS=0x00 PREC=0x00 TTL=123 ID=16638 PROTO=TCP SPT=1524 DPT=1524 WINDOW=8620 RES=0x00 SYN URGP=0
Intel(R) PRO/1000 Network Driver - version 4.4.19-k2
Copyright (c) 1999-2002 Intel Corporation.
divert: allocating divert_blk for eth1
eth1: Intel(R) PRO/1000 Network Connection
Linux Tulip driver version 0.9.15-pre11 (May 11, 2002)
tulip0: EEPROM default media type Autosense.
tulip0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block.
tulip0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block.
tulip0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block.
tulip0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block.
divert: allocating divert_blk for eth2
eth2: Digital DS21143 Tulip rev 65 at 0xf899c000, 00:C0:95:E6:69:B0, IRQ 48.
tulip1: EEPROM default media type Autosense.
tulip1: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block.
tulip1: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block.
tulip1: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block.
tulip1: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block.
divert: allocating divert_blk for eth3
eth3: Digital DS21143 Tulip rev 65 at 0xf899e400, 00:C0:95:E6:69:B1, IRQ 48.
tulip2: EEPROM default media type Autosense.
tulip2: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block.
tulip2: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block.
tulip2: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block.
tulip2: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block.
divert: allocating divert_blk for eth4
eth4: Digital DS21143 Tulip rev 65 at 0xf89f6800, 00:C0:95:E6:69:B2, IRQ 48.
tulip3: EEPROM default media type Autosense.
tulip3: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block.
tulip3: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block.
tulip3: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block.
tulip3: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block.
divert: allocating divert_blk for eth5
eth5: Digital DS21143 Tulip rev 65 at 0xf89f8c00, 00:C0:95:E6:69:B3, IRQ 48.
---------------
scanpci output:
pci bus 0x0000 cardnum 0x00 function 0x00: vendor 0x8086 device 0x2540
Intel Device unknown
pci bus 0x0000 cardnum 0x00 function 0x01: vendor 0x8086 device 0x2541
Intel Device unknown
pci bus 0x0000 cardnum 0x02 function 0x00: vendor 0x8086 device 0x2543
Intel Device unknown
pci bus 0x0000 cardnum 0x1d function 0x00: vendor 0x8086 device 0x2482
Intel Device unknown
pci bus 0x0000 cardnum 0x1d function 0x01: vendor 0x8086 device 0x2484
Intel Device unknown
pci bus 0x0000 cardnum 0x1d function 0x02: vendor 0x8086 device 0x2487
Intel Device unknown
pci bus 0x0000 cardnum 0x1e function 0x00: vendor 0x8086 device 0x244e
Intel Device unknown
pci bus 0x0000 cardnum 0x1f function 0x00: vendor 0x8086 device 0x2480
Intel Device unknown
pci bus 0x0000 cardnum 0x1f function 0x01: vendor 0x8086 device 0x248b
Intel Device unknown
pci bus 0x0000 cardnum 0x1f function 0x03: vendor 0x8086 device 0x2483
Intel Device unknown
pci bus 0x0001 cardnum 0x1c function 0x00: vendor 0x8086 device 0x1461
Intel Device unknown
pci bus 0x0001 cardnum 0x1d function 0x00: vendor 0x8086 device 0x1460
Intel Device unknown
pci bus 0x0001 cardnum 0x1e function 0x00: vendor 0x8086 device 0x1461
Intel Device unknown
pci bus 0x0001 cardnum 0x1f function 0x00: vendor 0x8086 device 0x1460
Intel Device unknown
pci bus 0x0002 cardnum 0x01 function 0x00: vendor 0x1011 device 0x0024
Digital DC21152
pci bus 0x0003 cardnum 0x04 function 0x00: vendor 0x1011 device 0x0019
Digital DC21142 10/100 Mb/s Ethernet
pci bus 0x0003 cardnum 0x05 function 0x00: vendor 0x1011 device 0x0019
Digital DC21142 10/100 Mb/s Ethernet
pci bus 0x0003 cardnum 0x06 function 0x00: vendor 0x1011 device 0x0019
Digital DC21142 10/100 Mb/s Ethernet
pci bus 0x0003 cardnum 0x07 function 0x00: vendor 0x1011 device 0x0019
Digital DC21142 10/100 Mb/s Ethernet
pci bus 0x0004 cardnum 0x02 function 0x00: vendor 0x9005 device 0x00cf
Adaptec Device unknown
pci bus 0x0004 cardnum 0x02 function 0x01: vendor 0x9005 device 0x00cf
Adaptec Device unknown
pci bus 0x0004 cardnum 0x04 function 0x00: vendor 0x8086 device 0x100d
Intel Device unknown
pci bus 0x0005 cardnum 0x01 function 0x00: vendor 0x1002 device 0x4752
ATI Mach64 GR
pci bus 0x0005 cardnum 0x02 function 0x00: vendor 0x8086 device 0x1229
Intel 82557/8/9 10/100MBit network controller
-----------------
/proc/pci output:
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Intel Corp. e7500 (Plumas) DRAM Controller (rev 3).
Bus 0, device 0, function 1:
Class ff00: Intel Corp. e7500 (Plumas) DRAM Controller Error Reporting (rev 3).
Bus 0, device 2, function 0:
PCI bridge: Intel Corp. e7500 (Plumas) HI_B Virtual PCI-to-PCI Bridge (F0) (rev 3).
Master Capable. Latency=64. Min Gnt=4.
Bus 0, device 29, function 0:
USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 2).
IRQ 16.
I/O at 0x1400 [0x141f].
Bus 0, device 29, function 1:
USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 2).
IRQ 19.
I/O at 0x1420 [0x143f].
Bus 0, device 29, function 2:
USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 2).
IRQ 18.
I/O at 0x1440 [0x145f].
Bus 0, device 30, function 0:
PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 66).
Master Capable. No bursts. Min Gnt=12.
Bus 0, device 31, function 0:
ISA bridge: Intel Corp. 82801CA ISA Bridge (LPC) (rev 2).
Bus 0, device 31, function 1:
IDE interface: Intel Corp. 82801CA IDE U100 (rev 2).
I/O at 0x1460 [0x146f].
Non-prefetchable 32 bit memory at 0x80000000 [0x800003ff].
Bus 0, device 31, function 3:
SMBus: Intel Corp. 82801CA/CAM SMBus (rev 2).
I/O at 0x1100 [0x111f].
Bus 1, device 28, function 0:
PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 3).
Non-prefetchable 32 bit memory at 0xfc100000 [0xfc100fff].
Bus 1, device 30, function 0:
PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (#2) (rev 3).
Non-prefetchable 32 bit memory at 0xfc101000 [0xfc101fff].
Bus 1, device 29, function 0:
PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 3).
Master Capable. Latency=64. Min Gnt=36.
Bus 1, device 31, function 0:
PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (#2) (rev 3).
Master Capable. Latency=64. Min Gnt=36.
Bus 2, device 1, function 0:
PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 3).
Master Capable. Latency=64. Min Gnt=4.
Bus 3, device 4, function 0:
Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 65).
IRQ 48.
Master Capable. Latency=165. Min Gnt=20.Max Lat=40.
I/O at 0x2000 [0x207f].
Non-prefetchable 32 bit memory at 0xfc200000 [0xfc2003ff].
Bus 3, device 5, function 0:
Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (#2) (rev 65).
IRQ 48.
Master Capable. Latency=165. Min Gnt=20.Max Lat=40.
I/O at 0x2080 [0x20ff].
Non-prefetchable 32 bit memory at 0xfc200400 [0xfc2007ff].
Bus 3, device 6, function 0:
Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (#3) (rev 65).
IRQ 48.
Master Capable. Latency=165. Min Gnt=20.Max Lat=40.
I/O at 0x2400 [0x247f].
Non-prefetchable 32 bit memory at 0xfc200800 [0xfc200bff].
Bus 3, device 7, function 0:
Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (#4) (rev 65).
IRQ 48.
Master Capable. Latency=165. Min Gnt=20.Max Lat=40.
I/O at 0x2480 [0x24ff].
Non-prefetchable 32 bit memory at 0xfc200c00 [0xfc200fff].
Bus 4, device 2, function 0:
SCSI storage controller: Adaptec AIC-7899P U160/m (rev 1).
IRQ 28.
Master Capable. Latency=64. Min Gnt=40.Max Lat=25.
I/O at 0x3000 [0x30ff].
Non-prefetchable 64 bit memory at 0xfc340000 [0xfc340fff].
Bus 4, device 2, function 1:
SCSI storage controller: Adaptec AIC-7899P U160/m (#2) (rev 1).
IRQ 29.
Master Capable. Latency=64. Min Gnt=40.Max Lat=25.
I/O at 0x3400 [0x34ff].
Non-prefetchable 64 bit memory at 0xfc341000 [0xfc341fff].
Bus 4, device 4, function 0:
Ethernet controller: Intel Corp. 82544GC Gigabit Ethernet Controller (rev 2).
IRQ 31.
Master Capable. Latency=64. Min Gnt=255.
Non-prefetchable 32 bit memory at 0xfc320000 [0xfc33ffff].
Non-prefetchable 32 bit memory at 0xfc300000 [0xfc31ffff].
I/O at 0x3800 [0x381f].
Bus 5, device 1, function 0:
VGA compatible controller: ATI Technologies Inc Rage XL (rev 39).
IRQ 16.
Master Capable. Latency=64. Min Gnt=8.
Non-prefetchable 32 bit memory at 0xfd000000 [0xfdffffff].
I/O at 0x4000 [0x40ff].
Non-prefetchable 32 bit memory at 0xfc400000 [0xfc400fff].
Bus 5, device 2, function 0:
Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 13).
IRQ 17.
Master Capable. Latency=64. Min Gnt=8.Max Lat=56.
Non-prefetchable 32 bit memory at 0xfc401000 [0xfc401fff].
I/O at 0x4400 [0x443f].
Non-prefetchable 32 bit memory at 0xfc420000 [0xfc43ffff].
------------------------
/proc/interrupts output:
CPU0 CPU1 CPU2 CPU3
0: 2578705 2579945 2579879 2579906 IO-APIC-edge timer
1: 1 0 1 1 IO-APIC-edge keyboard
2: 0 0 0 0 XT-PIC cascade
8: 1 0 0 0 IO-APIC-edge rtc
15: 1 0 0 1 IO-APIC-edge ide1
17: 12260 12348 12338 12225 IO-APIC-level eth0
28: 1194 1251 1197 1228 IO-APIC-level aic7xxx
29: 4 4 4 4 IO-APIC-level aic7xxx
31: 13 12 12 12 IO-APIC-level eth1
48: 11 8 8 9 IO-APIC-level eth2, eth3, eth4, eth5
NMI: 0 0 0 0
LOC: 10318937 10318977 10318977 10318976
ERR: 0
MIS: 0
===============================================================================
On Wed, 5 Mar 2003, Ivan Kokshaysky wrote:
> On Tue, Mar 04, 2003 at 01:16:22PM -0500, Donald Becker wrote:
> > Incorrect.
> > Most quad Tulip boards have the bus bridge wired so that all interrupts
> > are sent on the INTA output of the board.
>
> This can be true for older cards, but post-1998 hardware must follow
> the spec.
> PCI-to-PCI Bridge Architecture Specification, Rev 1.1, Dec 18, 1998,
The reality is that most quad Tulip boards were designed before 1999,
and therefore act as I described.
Most of the experience is with quad Ethernet adapters, as there are few
other common PCI boards with bus bridges.
> I know for a fact that at least D-Link card mentioned in some reports
> utilizes all four INT# lines, because I have one.
The D-Link board is
> Device 0 on a secondary bus will have its INTA# line connected to
> the INTA# line of the connector. Device 1 will have its INTA# line
> connected to INTB# of the connector. This sequence continues and
> then wraps around once INTD# has been assigned."
This seems to be what most x86 BIOSes assume (almost all BIOSes use the
Intel reference code for PCI setup), even from 1995-era machines.
But again, this does not match how _most_ of the quad boards are wired.
Curiously, non-x86 machines usually work fine without the work-around,
meaning that they have a different interpretation.
--
Donald Becker [email protected]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Scyld Beowulf cluster system
Annapolis MD 21403 410-990-9993
On Wed, 5 Mar 2003, Ron Arts wrote:
> I hope this adds anything.
> Attached is the output of `mptable -dmesg -extra`
I can't really help much but here is a quick interpretation, this is your
card with all the irqs wired to PIN A which seems to correspond with what
Donald Becker said.
INT active-lo level 3 4:A 4 0
INT active-lo level 3 5:A 4 0
INT active-lo level 3 6:A 4 0
INT active-lo level 3 7:A 4 0
IO-APIC (apicid-pin) 2-0, <-- doesn't that actually mean pin0 on the
ioapic servicing that card is not connected? (or due to mptables again)
Zwane
--
function.linuxpower.ca
On Wed, Mar 05, 2003 at 02:12:50AM +0300, [email protected] wrote:
> So, maybe the workaround is in znyx driver for XP. :-)
Quite possible.
> BIOSes were fixed to understand the first level bridges,
> but I guess none of them construct correct tables
> for second level bridges.
OTOH, there are rumors that PCI resource management has been
vastly improved in XP. I believe Alan and Russell tried that
with rather long chain of of bridges using PCI expansion
chassis and windows had no problems with it.
Not sure about details though (i.e. what version of windows
and whether additional drivers were required or not).
Ivan.
Linus Torvalds wrote:
> On Tue, 4 Mar 2003, Ivan Kokshaysky wrote:
>
>>Indeed, looks like only pin 0 (INT_A of that card) is connected. :-(
>
>
> Well, I'd say it looks like the MP table _claims_ that only pin0 is
> connected. Remember: the claim was that this machine worked on WinXP.
>
> So there are at least two potential reasons for that:
>
> - The MP table is simply wrong, and WinXP gets the routing information
> from somewhere else (ie most likely ACPI)
>
> - The MP table is right, and only pin0 is connected, and WinXP only uses
> pin0 (ie it puts the card in some state where all irqs are shared
> across all of the four tulip chips).
>
> Maybe somebody can come up with other schenarios.
>
> It would be interesting to hear what "Device Manager" (or whatever it is
> called) unde WinXP claims the interrupts are on this machine... Are they
> all on irq 48 on XP too? Or has XP gotten magic knowledge somewhere
> (ACPI?) and they are on different irq's?
>
> Linus
I installed Win 2000 on this machine. It assigned every port its own interrupt,
(IRQ 48-51), but it reported 'device is not functioning properly' on the
first port (IRQ 48).
Ron Arts
--
Netland Internet Services
bedrijfsmatige internetoplossingen
http://www.netland.nl Kruislaan 419 1098 VA Amsterdam
info: 020-5628282 servicedesk: 020-5628280 fax: 020-5628281
Sorry Rabbit, Phasers are for kids...
Well, the BIOS on those systems is unable to handle add-on
PCI bridges properly.
The idea is to search the mp tables for at least one valid irq
entry either for such bridge itself or for any of its children.
This entry tells us at least how this PCI slot is wired to IO APIC.
Assuming that 4 INT pins inside the slot are 1:1 mapped to APIC
pins, we can add missing irq entries for this bridge to the kernel
mp tables, reprogram the APIC accordingly and use these new
entries to find correct irqs for devices behind that bridge.
The patch is for 2.4 only. In 2.5 most interesting ioapic
functions are defined for ACPI only - someone else ought to
look into that.
It cannot handle more than one level of external bridges as yet
(i.e. things like expansion chassis). This can be easily fixed though.
Ron Arts tested this on SuperMicro P4DPR-6GM-Q Dual Xeon motherboard
with Adaptec Duralink 64 and ZNYX ZX346Q quad port cards, both worked
fine.
Ron says that ZNYX board didn't worked under XP, so apparently
rumors about XP goodness are exaggerated. ;-)
Ivan.
--- 2.4.21p5/include/asm-i386/mpspec.h Thu Mar 6 16:36:54 2003
+++ linux/include/asm-i386/mpspec.h Thu Mar 6 16:36:36 2003
@@ -218,6 +218,7 @@ extern int mp_current_pci_id;
extern unsigned long mp_lapic_addr;
extern int pic_mode;
extern int using_apic_timer;
+extern int max_irq_sources;
#endif
--- 2.4.21p5/include/asm-i386/io_apic.h Fri Mar 7 13:58:20 2003
+++ linux/include/asm-i386/io_apic.h Fri Mar 7 13:30:15 2003
@@ -132,6 +132,9 @@ static inline void io_apic_sync(unsigned
(void) *(IO_APIC_BASE(apic)+4);
}
+/* Setup one irq redirection entry. */
+extern int setup_one_IO_APIC_irq(int apic, int pin);
+
/* 1 if "noapic" boot option passed */
extern int skip_ioapic_setup;
--- 2.4.21p5/arch/i386/kernel/pci-irq.c Fri Nov 29 02:53:09 2002
+++ linux/arch/i386/kernel/pci-irq.c Fri Mar 7 13:48:14 2003
@@ -701,6 +701,89 @@ void __init pcibios_irq_init(void)
}
}
+#ifdef CONFIG_X86_IO_APIC
+static void __init
+bridge_fixup_irqs(struct pci_dev *dev)
+{
+ int apic, pin, i, slot;
+ struct pci_dev *parent;
+ struct mpc_config_intsrc m;
+
+ parent = dev->bus->self;
+
+ /* HACK. We need a generic way to detect the built-in bridges;
+ the "bridge swizzle" rule cannot be applied for those.
+ For now check for P64H/P64H2 bridges only. */
+ if (!parent || (parent->class >> 8) != PCI_CLASS_BRIDGE_PCI ||
+ parent->vendor != PCI_VENDOR_ID_INTEL ||
+ (parent->device & ~0x700) != 0x1060)
+ return;
+
+ slot = PCI_SLOT(dev->devfn) << 2;
+
+ /* Check that there are mp irq entries either for this bridge itself
+ or for its children. */
+ for (i = 0; i < mp_irq_entries; i++) {
+ int srcbus = mp_irqs[i].mpc_srcbus;
+ int srcslot = mp_irqs[i].mpc_srcbusirq & ~3;
+
+ if (mp_irqs[i].mpc_irqtype != mp_INT)
+ continue;
+
+ if ((srcbus == dev->bus->number && srcslot == slot) ||
+ (srcbus >= dev->subordinate->number &&
+ srcbus <= dev->subordinate->subordinate))
+ break;
+ }
+ if (i >= mp_irq_entries) {
+ printk(KERN_WARNING "PCI: no IRQ routing found for bridge %s\n",
+ dev->slot_name);
+ return;
+ }
+
+ /* Template for new entries. */
+ m = mp_irqs[i];
+ m.mpc_srcbus = dev->bus->number;
+ m.mpc_srcbusirq = slot;
+ m.mpc_dstirq &= ~3; /* Assume 1:1 mapping. */
+
+ for (apic = 0; apic < nr_ioapics; apic++) {
+ if (mp_ioapics[apic].mpc_apicid == m.mpc_dstapic)
+ break;
+ }
+ if (apic >= nr_ioapics) {
+ printk(KERN_WARNING "PCI: no I/O APIC found for bridge %s\n",
+ dev->slot_name);
+ return;
+ }
+
+ for (pin = 0; pin < 4; pin++) {
+ /* Check whether or not we have matching mp entry. */
+ for (i = 0; i < mp_irq_entries; i++)
+ if (mp_irqs[i].mpc_irqtype == mp_INT &&
+ mp_irqs[i].mpc_dstapic == m.mpc_dstapic &&
+ mp_irqs[i].mpc_srcbusirq == slot + pin &&
+ mp_irqs[i].mpc_srcbus == dev->bus->number)
+ break;
+ if (i < mp_irq_entries)
+ continue;
+ if (mp_irq_entries + 1 == max_irq_sources)
+ return; /* No room in mp irq table. */
+
+ /* Create a new mp irq entry. */
+ printk(KERN_INFO "PCI: external bridge %s, INT%c fixup\n",
+ dev->slot_name, pin + 'A');
+ mp_irqs[mp_irq_entries] = m;
+ mp_irqs[mp_irq_entries].mpc_srcbusirq += pin;
+ mp_irqs[mp_irq_entries].mpc_dstirq += pin;
+ ++mp_irq_entries;
+
+ /* Now update the irq redirection entry. */
+ setup_one_IO_APIC_irq(apic, m.mpc_dstirq + pin);
+ }
+}
+#endif
+
void __init pcibios_fixup_irqs(void)
{
struct pci_dev *dev;
@@ -730,9 +813,14 @@ void __init pcibios_fixup_irqs(void)
*/
if (io_apic_assign_pci_irqs)
{
- int irq;
+ int irq, irq1 = -1;
+
+ if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI)
+ bridge_fixup_irqs(dev);
if (pin) {
+ struct pci_dev *bridge = dev->bus->self;
+
pin--; /* interrupt pins are numbered starting from 1 */
irq = IO_APIC_get_PCI_irq_vector(dev->bus->number, PCI_SLOT(dev->devfn), pin);
/*
@@ -741,15 +829,18 @@ void __init pcibios_fixup_irqs(void)
* parent slot, and pin number. The SMP code detects such bridged
* busses itself so we should get into this branch reliably.
*/
- if (irq < 0 && dev->bus->parent) { /* go back to the bridge */
- struct pci_dev * bridge = dev->bus->self;
+ if (dev->bus->parent) { /* go back to the bridge */
pin = (pin + PCI_SLOT(dev->devfn)) % 4;
- irq = IO_APIC_get_PCI_irq_vector(bridge->bus->number,
+ irq1 = IO_APIC_get_PCI_irq_vector(bridge->bus->number,
PCI_SLOT(bridge->devfn), pin);
- if (irq >= 0)
- printk(KERN_WARNING "PCI: using PPB(B%d,I%d,P%d) to get irq %d\n",
- bridge->bus->number, PCI_SLOT(bridge->devfn), pin, irq);
+ }
+ if (irq1 >= 0 && irq1 != irq) {
+ /* IRQ for this device doesn't match one for parent slot.
+ Use the latter. */
+ irq = irq1;
+ printk(KERN_WARNING "PCI: using PPB(B%d,I%d,P%d) to get irq %d\n",
+ bridge->bus->number, PCI_SLOT(bridge->devfn), pin, irq);
}
if (irq >= 0) {
printk(KERN_INFO "PCI->APIC IRQ transform: (B%d,I%d,P%d) -> %d\n",
--- 2.4.21p5/arch/i386/kernel/io_apic.c Thu Mar 6 15:58:25 2003
+++ linux/arch/i386/kernel/io_apic.c Thu Mar 6 16:00:23 2003
@@ -614,78 +614,88 @@ extern void (*interrupt[NR_IRQS])(void);
static struct hw_interrupt_type ioapic_level_irq_type;
static struct hw_interrupt_type ioapic_edge_irq_type;
-void __init setup_IO_APIC_irqs(void)
+int __init setup_one_IO_APIC_irq(int apic, int pin)
{
struct IO_APIC_route_entry entry;
- int apic, pin, idx, irq, first_notcon = 1, vector;
+ int idx, irq, vector;
unsigned long flags;
+ idx = find_irq_entry(apic,pin,mp_INT);
+ if (idx < 0)
+ return idx;
+ /*
+ * add it to the IO-APIC irq-routing table:
+ */
+ memset(&entry,0,sizeof(entry));
+
+ entry.delivery_mode = INT_DELIVERY_MODE;
+ entry.dest_mode = (INT_DEST_ADDR_MODE != 0);
+ entry.mask = 0; /* enable IRQ */
+ entry.dest.logical.logical_dest = target_cpus();
+
+ entry.trigger = irq_trigger(idx);
+ entry.polarity = irq_polarity(idx);
+
+ if (irq_trigger(idx)) {
+ entry.trigger = 1;
+ entry.mask = 1;
+ }
+
+ irq = pin_2_irq(idx, apic, pin);
+ /*
+ * skip adding the timer int on secondary nodes, which causes
+ * a small but painful rift in the time-space continuum
+ */
+ if ((clustered_apic_mode == CLUSTERED_APIC_NUMAQ)
+ && (apic != 0) && (irq == 0))
+ return 0;
+ else
+ add_pin_to_irq(irq, apic, pin);
+
+ if (!apic && !IO_APIC_IRQ(irq))
+ return 0;
+
+ if (IO_APIC_IRQ(irq)) {
+ vector = assign_irq_vector(irq);
+ entry.vector = vector;
+
+ if (IO_APIC_irq_trigger(irq))
+ irq_desc[irq].handler = &ioapic_level_irq_type;
+ else
+ irq_desc[irq].handler = &ioapic_edge_irq_type;
+
+ set_intr_gate(vector, interrupt[irq]);
+
+ if (!apic && (irq < 16))
+ disable_8259A_irq(irq);
+ }
+ spin_lock_irqsave(&ioapic_lock, flags);
+ io_apic_write(apic, 0x11+2*pin, *(((int *)&entry)+1));
+ io_apic_write(apic, 0x10+2*pin, *(((int *)&entry)+0));
+ spin_unlock_irqrestore(&ioapic_lock, flags);
+
+ return 0;
+}
+
+void __init setup_IO_APIC_irqs(void)
+{
+ int apic, pin, first_notcon = 1;
+
printk(KERN_DEBUG "init IO_APIC IRQs\n");
for (apic = 0; apic < nr_ioapics; apic++) {
- for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) {
+ for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) {
- /*
- * add it to the IO-APIC irq-routing table:
- */
- memset(&entry,0,sizeof(entry));
-
- entry.delivery_mode = INT_DELIVERY_MODE;
- entry.dest_mode = (INT_DEST_ADDR_MODE != 0);
- entry.mask = 0; /* enable IRQ */
- entry.dest.logical.logical_dest = target_cpus();
+ if (setup_one_IO_APIC_irq(apic, pin) >= 0)
+ continue;
- idx = find_irq_entry(apic,pin,mp_INT);
- if (idx == -1) {
if (first_notcon) {
- printk(KERN_DEBUG " IO-APIC (apicid-pin) %d-%d", mp_ioapics[apic].mpc_apicid, pin);
+ printk(KERN_DEBUG " IO-APIC (apicid-pin) %d-%d",
+ mp_ioapics[apic].mpc_apicid, pin);
first_notcon = 0;
} else
printk(", %d-%d", mp_ioapics[apic].mpc_apicid, pin);
- continue;
- }
-
- entry.trigger = irq_trigger(idx);
- entry.polarity = irq_polarity(idx);
-
- if (irq_trigger(idx)) {
- entry.trigger = 1;
- entry.mask = 1;
- }
-
- irq = pin_2_irq(idx, apic, pin);
- /*
- * skip adding the timer int on secondary nodes, which causes
- * a small but painful rift in the time-space continuum
- */
- if ((clustered_apic_mode == CLUSTERED_APIC_NUMAQ)
- && (apic != 0) && (irq == 0))
- continue;
- else
- add_pin_to_irq(irq, apic, pin);
-
- if (!apic && !IO_APIC_IRQ(irq))
- continue;
-
- if (IO_APIC_IRQ(irq)) {
- vector = assign_irq_vector(irq);
- entry.vector = vector;
-
- if (IO_APIC_irq_trigger(irq))
- irq_desc[irq].handler = &ioapic_level_irq_type;
- else
- irq_desc[irq].handler = &ioapic_edge_irq_type;
-
- set_intr_gate(vector, interrupt[irq]);
-
- if (!apic && (irq < 16))
- disable_8259A_irq(irq);
}
- spin_lock_irqsave(&ioapic_lock, flags);
- io_apic_write(apic, 0x11+2*pin, *(((int *)&entry)+1));
- io_apic_write(apic, 0x10+2*pin, *(((int *)&entry)+0));
- spin_unlock_irqrestore(&ioapic_lock, flags);
- }
}
if (!first_notcon)
Ivan!
Thanks very much for your efforts.
Is there more testing youd like to see done?
Could we get this patch in to Marcello for inclusion in the pre 2.4.21?
cheers,
jamal
On Mon, Mar 10, 2003 at 01:43:50PM -0500, jamal wrote:
> Is there more testing youd like to see done?
Yes, it would be interesting to test this on similar motherboards
(with E7500 chipset) which do work without that patch, just to make
sure it doesn't break something.
> Could we get this patch in to Marcello for inclusion in the pre 2.4.21?
Why not, but I'd like to clean it up first (will do in a next
couple of days).
Ivan.