* [PATCH] PCI-Devices and ServerWorks chipset
@ 2001-01-16 17:12 Adam Lackorzynski
2001-01-17 8:52 ` Martin Mares
0 siblings, 1 reply; 13+ messages in thread
From: Adam Lackorzynski @ 2001-01-16 17:12 UTC (permalink / raw)
To: Kernel Mailing List
The patch below (against vanilla 2.4.0) makes Linux recognize
PCI-Devices sitting in another PCI bus than 0 (or 1).
This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
00:00.0 Host bridge: ServerWorks CNB20HE (rev 21)
00:00.1 Host bridge: ServerWorks CNB20HE (rev 01)
00:00.2 Host bridge: ServerWorks: Unknown device 0006
00:00.3 Host bridge: ServerWorks: Unknown device 0006
00:01.0 SCSI storage controller: Adaptec 7896
00:01.1 SCSI storage controller: Adaptec 7896
00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
00:06.0 VGA compatible controller: S3 Inc. Trio 64 3D (rev 01)
00:0f.0 ISA bridge: ServerWorks OSB4 (rev 4f)
00:0f.1 IDE interface: ServerWorks: Unknown device 0211
00:0f.2 USB Controller: ServerWorks: Unknown device 0220 (rev 04)
02:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
02:06.0 RAID bus controller: IBM: Unknown device 01bd
The last two lines do not occur without the patch.
diff -ur linux-2.4.0/linux/arch/i386/kernel/pci-pc.c linux/arch/i386/kernel/pci-pc.c
--- linux-2.4.0/linux/arch/i386/kernel/pci-pc.c Thu Jun 22 16:17:16 2000
+++ linux/arch/i386/kernel/pci-pc.c Tue Jan 16 18:10:30 2001
@@ -849,10 +849,13 @@
* ServerWorks host bridges -- Find and scan all secondary buses.
* Register 0x44 contains first, 0x45 last bus number routed there.
*/
- u8 busno;
- pci_read_config_byte(d, 0x44, &busno);
- printk("PCI: ServerWorks host bridge: secondary bus %02x\n", busno);
- pci_scan_bus(busno, pci_root_ops, NULL);
+ u8 busno_first, busno_last, i;
+ pci_read_config_byte(d, 0x44, &busno_first);
+ pci_read_config_byte(d, 0x45, &busno_last);
+ for (i = busno_first; i <= busno_last; i++) {
+ printk("PCI: ServerWorks host bridge: secondary bus %02x\n", i);
+ pci_scan_bus(i, pci_root_ops, NULL);
+ }
pcibios_last_bus = -1;
}
Adam
--
Adam al10@inf.tu-dresden.de
Lackorzynski http://a.home.dhs.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] PCI-Devices and ServerWorks chipset
2001-01-16 17:12 [PATCH] PCI-Devices and ServerWorks chipset Adam Lackorzynski
@ 2001-01-17 8:52 ` Martin Mares
2001-01-17 10:14 ` Adam Lackorzynski
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Martin Mares @ 2001-01-17 8:52 UTC (permalink / raw)
To: Adam Lackorzynski; +Cc: Kernel Mailing List
Hello!
> The patch below (against vanilla 2.4.0) makes Linux recognize
> PCI-Devices sitting in another PCI bus than 0 (or 1).
>
> This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
I don't have the ServerWorks chipset documentation at hand, but I think your
patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
0x44 and 0x45 are probably ID's of two primary buses and the code should scan
both of them, but not the space between them.
Anyway, could you send me a `lspci -MH1 -vvx' and `lspci -vvxxx -s0:0', please?
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> <mj@suse.cz> http://atrey.karlin.mff.cuni.cz/~mj/
System going down at 5 pm to install scheduler bug.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] PCI-Devices and ServerWorks chipset
2001-01-17 8:52 ` Martin Mares
@ 2001-01-17 10:14 ` Adam Lackorzynski
2001-01-17 11:25 ` Maciej W. Rozycki
2001-01-23 18:18 ` Adam Lackorzynski
2 siblings, 0 replies; 13+ messages in thread
From: Adam Lackorzynski @ 2001-01-17 10:14 UTC (permalink / raw)
To: Martin Mares; +Cc: Kernel Mailing List
Hi!
On Wed Jan 17, 2001 at 09:52:21 +0100, Martin Mares wrote:
> > The patch below (against vanilla 2.4.0) makes Linux recognize
> > PCI-Devices sitting in another PCI bus than 0 (or 1).
> >
> > This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
>
> I don't have the ServerWorks chipset documentation at hand, but I think your
> patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
> 0x44 and 0x45 are probably ID's of two primary buses and the code should scan
> both of them, but not the space between them.
I was just inspired by the comment in this function and knew that this
"patch" was probably wrong but it was enough to get someone else' eyes
watching on it ... :-)
BTW, one line of dmesg says:
PCI: PCI BIOS revision 2.10 entry at 0xfd5cc, last bus=6
So that "6" in 0x45 made some sense to me...
> Anyway, could you send me a `lspci -MH1 -vvx' and `lspci -vvxxx -s0:0', please?
$ lspci -MH1 -vvx
00:00.0 Host bridge: ServerWorks CNB20HE (rev 21)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00: 66 11 08 00 00 00 00 00 21 00 00 06 08 60 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:00.1 Host bridge: ServerWorks CNB20HE (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 96, cache line size 08
00: 66 11 08 00 47 01 00 22 01 00 00 06 08 60 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:00.2 Host bridge: ServerWorks: Unknown device 0006
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
00: 66 11 06 00 42 01 00 22 00 00 00 06 08 60 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:00.3 Host bridge: ServerWorks: Unknown device 0006
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
00: 66 11 06 00 42 01 00 22 00 00 00 06 08 60 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:01.0 SCSI storage controller: Adaptec 7896
Subsystem: Adaptec: Unknown device 080f
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 100 (9750ns min, 6250ns max), cache line size 08
Interrupt: pin A routed to IRQ 10
BIST result: 00
Region 0: I/O ports at 2000
Region 1: Memory at febff000 (64-bit, non-prefetchable)
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 05 90 5f 00 07 00 90 02 00 00 00 01 08 64 80 80
10: 01 20 00 00 04 f0 bf fe 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 05 90 0f 08
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 27 19
00:01.1 SCSI storage controller: Adaptec 7896
Subsystem: Adaptec: Unknown device 080f
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 100 (9750ns min, 6250ns max), cache line size 08
Interrupt: pin A routed to IRQ 10
BIST result: 00
Region 0: I/O ports at 2100
Region 1: Memory at febfe000 (64-bit, non-prefetchable)
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 05 90 5f 00 07 00 90 02 00 00 00 01 08 64 80 80
10: 01 21 00 00 04 e0 bf fe 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 05 90 0f 08
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 27 19
00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
Subsystem: IBM: Unknown device 2000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 100 (6000ns min, 6000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 2200
Region 1: Memory at febfdc00 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
00: 22 10 00 20 47 01 90 02 44 00 00 02 00 64 00 00
10: 01 22 00 00 00 dc bf fe 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 14 10 00 20
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 18 18
00:06.0 VGA compatible controller: S3 Inc. Trio 64 3D (rev 01) (prog-if 00 [VGA])
Subsystem: IBM Integrated Trio3D
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 96 (1000ns min, 63750ns max)
Interrupt: pin ? routed to IRQ 255
Region 0: Memory at f8000000 (32-bit, non-prefetchable)
Capabilities: [44] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 33 53 04 89 07 00 10 02 01 00 00 03 00 60 00 00
10: 00 00 00 f8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 14 10 db 00
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 04 ff
00:0f.0 ISA bridge: ServerWorks OSB4 (rev 4f)
Subsystem: ServerWorks OSB4
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00: 66 11 00 02 47 01 00 02 4f 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 66 11 00 02
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:0f.1 IDE interface: ServerWorks: Unknown device 0211 (prog-if 8a [Master SecP PriP])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Region 4: I/O ports at 0840
00: 66 11 11 02 45 01 00 02 00 8a 01 01 00 40 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 41 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:0f.2 USB Controller: ServerWorks: Unknown device 0220 (rev 04) (prog-if 10 [OHCI])
Subsystem: ServerWorks: Unknown device 0220
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 96 (20000ns max), cache line size 08
Interrupt: pin A routed to IRQ 15
Region 0: Memory at febfc000 (32-bit, non-prefetchable)
00: 66 11 20 02 57 01 80 02 04 10 03 0c 08 60 80 00
10: 00 c0 bf fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 66 11 20 02
30: 00 00 00 00 00 00 00 00 00 00 00 00 0f 01 00 50
02:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Subsystem: Accton Technology Corporation Cheetah Fast Ethernet
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 100 (5000ns min, 10000ns max), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 2280
Region 1: Memory at f7fffc00 (32-bit, non-prefetchable)
00: 11 10 19 00 57 01 80 02 41 00 00 02 08 64 00 00
10: 81 22 00 00 00 fc ff f7 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 13 11 07 12
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 14 28
02:06.0 RAID bus controller: IBM: Unknown device 01bd
Subsystem: IBM: Unknown device 01bf
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 96, cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at f5ffe000 (32-bit, prefetchable)
00: 14 10 bd 01 56 01 80 02 00 00 04 01 08 60 00 00
10: 08 e0 ff f5 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 14 10 bf 01
30: 00 00 00 00 80 00 00 00 00 00 00 00 0a 01 00 00
Summary of buses:
00: Primary host bus
02: Secondary host bus (?)
$ lspci -vvxxx -s0:0
00:00.0 Host bridge: ServerWorks CNB20HE (rev 21)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00: 66 11 08 00 00 00 00 00 21 00 00 06 08 60 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 01 06 00 00 00 61 01 33 00 00 00 00
50: 00 00 00 00 03 00 00 00 00 00 00 10 00 00 00 00
60: 00 00 c0 10 00 01 07 04 00 00 00 00 00 00 00 00
70: 08 aa 0a aa c0 0f ff 2f 01 18 00 00 06 00 00 00
80: 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 01 f9 1a 5f 00 10 00 00 00 10 00 00 00 00 00 00
a0: 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 43 00 98 58 00 00 00 01 a6 78 83 08 12 ac 49 84
c0: 00 02 af 08 b0 08 5f 0f 60 0f 7f 0f 15 00 c0 fe
d0: 20 22 fc ff 24 42 a4 28 00 00 00 00 01 00 00 00
e0: 04 00 00 00 00 96 00 00 03 00 00 96 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 c0 00 00 00
00:00.1 Host bridge: ServerWorks CNB20HE (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 96, cache line size 08
00: 66 11 08 00 47 01 00 22 01 00 00 06 08 60 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 f8 00 00 00 00 43 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 02 00 20 00 01 02 00 10 41 3c 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 5a 00 45 02 80 0f 7f 0f 80 0f ff 0f 10 00 00 00
d0: 00 00 1c 22 00 00 00 00 00 00 00 00 01 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 54 40 7e f1 ec 9f 4a b0 00 00 00 00 c2 08 00 00
00:00.2 Host bridge: ServerWorks: Unknown device 0006
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
00: 66 11 06 00 42 01 00 22 00 00 00 06 08 60 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 02 06 f8 00 02 ff 00 04 00 00 00 00
50: 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 aa 0a aa c0 0f ff 0f 00 00 80 00 00 00 00 00
80: 20 00 00 00 fd b9 fb ef ff ff ff ff 00 00 00 00
90: dc ff fc 6f 74 39 fc ff 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 02 af 08 b0 08 5f 0f 60 0f 7f 0f 15 00 00 00
d0: 20 22 fc ff fc bf b8 6d dc ff fc fb 01 00 00 00
e0: ff ff ff ef 00 00 00 00 00 00 00 00 c4 00 00 00
f0: 40 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:00.3 Host bridge: ServerWorks: Unknown device 0006
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
00: 66 11 06 00 42 01 00 22 00 00 00 06 08 60 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 01 01 f8 00 12 ff 00 04 00 00 00 00
50: 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 aa 0a aa c0 0f ff 0f 00 00 80 00 00 00 00 00
80: 20 00 00 00 fd b9 fb ef ff ff ff ff 00 00 00 00
90: f8 fd bc ef fc ff dc 5f 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: fd ff ff ff 60 0f 5f 0f 80 0f 7f 0f 00 00 00 00
d0: 20 22 1c 22 dc ff fc ef fc ff ec ff 00 00 00 00
e0: 7f fb bf fd 00 00 00 00 00 00 00 00 c6 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Adam
--
Adam al10@inf.tu-dresden.de
Lackorzynski http://a.home.dhs.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] PCI-Devices and ServerWorks chipset
2001-01-17 8:52 ` Martin Mares
2001-01-17 10:14 ` Adam Lackorzynski
@ 2001-01-17 11:25 ` Maciej W. Rozycki
2001-01-17 21:17 ` Dan Hollis
2001-01-23 3:01 ` Tim Hockin
2001-01-23 18:18 ` Adam Lackorzynski
2 siblings, 2 replies; 13+ messages in thread
From: Maciej W. Rozycki @ 2001-01-17 11:25 UTC (permalink / raw)
To: Martin Mares; +Cc: Adam Lackorzynski, Kernel Mailing List
On Wed, 17 Jan 2001, Martin Mares wrote:
> I don't have the ServerWorks chipset documentation at hand, but I think your
> patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
> 0x44 and 0x45 are probably ID's of two primary buses and the code should scan
> both of them, but not the space between them.
Does anyone beside the manufacturer have these docs at all? Last time I
contacted them, they required an NDA, even though they weren't actually
Linux-hostile.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] PCI-Devices and ServerWorks chipset
2001-01-17 11:25 ` Maciej W. Rozycki
@ 2001-01-17 21:17 ` Dan Hollis
2001-01-18 8:37 ` Maciej W. Rozycki
2001-01-23 3:01 ` Tim Hockin
1 sibling, 1 reply; 13+ messages in thread
From: Dan Hollis @ 2001-01-17 21:17 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Martin Mares, Adam Lackorzynski, Kernel Mailing List
On Wed, 17 Jan 2001, Maciej W. Rozycki wrote:
> On Wed, 17 Jan 2001, Martin Mares wrote:
> > I don't have the ServerWorks chipset documentation at hand, but I think your
> > patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
> > 0x44 and 0x45 are probably ID's of two primary buses and the code should scan
> > both of them, but not the space between them.
> Does anyone beside the manufacturer have these docs at all? Last time I
> contacted them, they required an NDA, even though they weren't actually
> Linux-hostile.
They require not only an NDA, but that you also do all development on-site
at their santa clara HQ under their direct supervision.
The only people who have ever got info out of serverworks are the lm78
guys and (i think) andre hedrick.
What magic incantations they chanted, or which mafia thugs they hired to
manage this, I don't know...
-Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] PCI-Devices and ServerWorks chipset
2001-01-17 21:17 ` Dan Hollis
@ 2001-01-18 8:37 ` Maciej W. Rozycki
2001-01-18 10:01 ` Andre Hedrick
0 siblings, 1 reply; 13+ messages in thread
From: Maciej W. Rozycki @ 2001-01-18 8:37 UTC (permalink / raw)
To: Dan Hollis; +Cc: Martin Mares, Adam Lackorzynski, Kernel Mailing List
On Wed, 17 Jan 2001, Dan Hollis wrote:
> They require not only an NDA, but that you also do all development on-site
> at their santa clara HQ under their direct supervision.
I haven't went that far -- I'm not going to sign any NDA anytime soon, so
I haven't asked them for details. I recall someone writing here it's
restrictive, indeed.
> The only people who have ever got info out of serverworks are the lm78
> guys and (i think) andre hedrick.
I was asking for a few I/O APIC details -- apparently there are problems
with 8254 interoperability and we have to use the awkward through-8259A
mode for the timer tick.
> What magic incantations they chanted, or which mafia thugs they hired to
> manage this, I don't know...
And I don't actually care. If they want to lose in the Linux area, it's
their own choice.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] PCI-Devices and ServerWorks chipset
2001-01-18 8:37 ` Maciej W. Rozycki
@ 2001-01-18 10:01 ` Andre Hedrick
2001-01-18 11:08 ` Maciej W. Rozycki
0 siblings, 1 reply; 13+ messages in thread
From: Andre Hedrick @ 2001-01-18 10:01 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Dan Hollis, Martin Mares, Adam Lackorzynski, Kernel Mailing List
On Thu, 18 Jan 2001, Maciej W. Rozycki wrote:
> On Wed, 17 Jan 2001, Dan Hollis wrote:
>
> > They require not only an NDA, but that you also do all development on-site
> > at their santa clara HQ under their direct supervision.
>
> I haven't went that far -- I'm not going to sign any NDA anytime soon, so
> I haven't asked them for details. I recall someone writing here it's
> restrictive, indeed.
>
> > The only people who have ever got info out of serverworks are the lm78
> > guys and (i think) andre hedrick.
I can get any info needed, you just have to define the scope.
Then will not can and will not give out details on a generic form.
In short no one person can see the entire design docs or will they get
them without a NDA. I have seen why this is the case, cause the toy are
cool.
> I was asking for a few I/O APIC details -- apparently there are problems
> with 8254 interoperability and we have to use the awkward through-8259A
> mode for the timer tick.
Narrow the point.
> > What magic incantations they chanted, or which mafia thugs they hired to
> > manage this, I don't know...
>
> And I don't actually care. If they want to lose in the Linux area, it's
> their own choice.
You don't get it, they OEM board designs for Compaq and Dell.
These guys will work with you on-site but in their sand-box not yours.
I wish I could say more, but I have something more powerfully than any NDA
ever written. I have given my word and a handshake, and that has more
value to me than any stupid NDA. The very fact that I value this so much
and so many in the industry know this about me, I have been shown things
without NDA's that you never see otherwise.
They are very friendly to Linux, but can we be friendly to them?
You just can not barge in and demand to see their IP.
Regards,
Andre Hedrick
Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] PCI-Devices and ServerWorks chipset
2001-01-18 10:01 ` Andre Hedrick
@ 2001-01-18 11:08 ` Maciej W. Rozycki
2001-01-18 17:40 ` Andre Hedrick
0 siblings, 1 reply; 13+ messages in thread
From: Maciej W. Rozycki @ 2001-01-18 11:08 UTC (permalink / raw)
To: Andre Hedrick
Cc: Dan Hollis, Martin Mares, Adam Lackorzynski, Kernel Mailing List
On Thu, 18 Jan 2001, Andre Hedrick wrote:
> I can get any info needed, you just have to define the scope.
Good.
> Then will not can and will not give out details on a generic form.
Weird. Others somehow are able to provide specs. Documentation for the
entire line of Intel chipsets is available, for example.
> In short no one person can see the entire design docs or will they get
> them without a NDA. I have seen why this is the case, cause the toy are
> cool.
I don't need design docs -- I need programming specs.
> > I was asking for a few I/O APIC details -- apparently there are problems
> > with 8254 interoperability and we have to use the awkward through-8259A
> > mode for the timer tick.
>
> Narrow the point.
The output of the 8254's timer 0 does not appear to be connected to any
I/O APIC input. It is connected to the IR0 line of the master 8259A as
usual. The 8254, both 8259As and both I/O APICs are all internal to the
chipset.
The question is: "Is it possible to use the 8254 timer interrupt
natively, i.e. is it possible to reconfigure the chipset to route the
interrupt source to any I/O APIC with no 8259A logic in the way?" It's
nice we have the through-8259A trick, but I developed it solely as a
workaround to support the old Intel 82350 EISA chipset, commonly used for
old APIC SMP systems, which did not route IRQ0 externally just because it
was designed long before the 82489DX APIC. It just should not be used for
modern systems -- it's too fragile.
> > And I don't actually care. If they want to lose in the Linux area, it's
> > their own choice.
>
> You don't get it, they OEM board designs for Compaq and Dell.
> These guys will work with you on-site but in their sand-box not yours.
What don't I get? If Compaq and Dell chose the ServerWorks chipset, then
until (unless) docs are available, it's their problem to support Linux on
their systems. It's certainly not mine.
> I wish I could say more, but I have something more powerfully than any NDA
> ever written. I have given my word and a handshake, and that has more
> value to me than any stupid NDA. The very fact that I value this so much
> and so many in the industry know this about me, I have been shown things
> without NDA's that you never see otherwise.
Nobody seems to push you to leak information you cannot give for a
reason, and certainly neither do I.
> They are very friendly to Linux, but can we be friendly to them?
I'm neutral at the moment. Their friendship appears to be purely
declarational at the moment. They do neither provide docs nor answer
specific question. I've already asked them the question I quoted above.
I got no answer. Neither did the user of the system affected, who
contacted them as well. So I'm just sitting and watching the situation.
> You just can not barge in and demand to see their IP.
I do not demand anything. I'm just not willing to work on problems with
hardware the manufacturer refuses to document. Anyone feel free to
undertake this task.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] PCI-Devices and ServerWorks chipset
2001-01-18 11:08 ` Maciej W. Rozycki
@ 2001-01-18 17:40 ` Andre Hedrick
2001-01-19 12:24 ` Maciej W. Rozycki
0 siblings, 1 reply; 13+ messages in thread
From: Andre Hedrick @ 2001-01-18 17:40 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Dan Hollis, Martin Mares, Adam Lackorzynski, Kernel Mailing List
On Thu, 18 Jan 2001, Maciej W. Rozycki wrote:
> Weird. Others somehow are able to provide specs. Documentation for the
> entire line of Intel chipsets is available, for example.
This because the make chipsets to basically give away to sell processors.
That should be very obvious, they they sell CPU's fpr $100's and sell
chipsets at pennies.
Cheers,
Andre Hedrick
Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] PCI-Devices and ServerWorks chipset
2001-01-18 17:40 ` Andre Hedrick
@ 2001-01-19 12:24 ` Maciej W. Rozycki
0 siblings, 0 replies; 13+ messages in thread
From: Maciej W. Rozycki @ 2001-01-19 12:24 UTC (permalink / raw)
To: Andre Hedrick
Cc: Dan Hollis, Martin Mares, Adam Lackorzynski, Kernel Mailing List
On Thu, 18 Jan 2001, Andre Hedrick wrote:
> > Weird. Others somehow are able to provide specs. Documentation for the
> > entire line of Intel chipsets is available, for example.
>
> This because the make chipsets to basically give away to sell processors.
> That should be very obvious, they they sell CPU's fpr $100's and sell
> chipsets at pennies.
Sure, but they make specs for CPUs available as well. So the point is?
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] PCI-Devices and ServerWorks chipset
2001-01-17 11:25 ` Maciej W. Rozycki
2001-01-17 21:17 ` Dan Hollis
@ 2001-01-23 3:01 ` Tim Hockin
2001-02-08 8:34 ` Martin Mares
1 sibling, 1 reply; 13+ messages in thread
From: Tim Hockin @ 2001-01-23 3:01 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Martin Mares, Adam Lackorzynski, Kernel Mailing List
> > patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
> > 0x44 and 0x45 are probably ID's of two primary buses and the code should scan
> > both of them, but not the space between them.
>
0x44 is the primary bus number of the host bridge, and 0x45 is the
subordinate bus number for the bridge. Just like a PCI-PCI bridge, but
different :) Since there are two CNB30 functions, each has unique values
for this. The primary bus of the second bridge must be the subordinate bus
of the first bridge + 1. PRIMARY(1) = SUBORDINATE(0) + 1;
Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] PCI-Devices and ServerWorks chipset
2001-01-17 8:52 ` Martin Mares
2001-01-17 10:14 ` Adam Lackorzynski
2001-01-17 11:25 ` Maciej W. Rozycki
@ 2001-01-23 18:18 ` Adam Lackorzynski
2 siblings, 0 replies; 13+ messages in thread
From: Adam Lackorzynski @ 2001-01-23 18:18 UTC (permalink / raw)
To: Martin Mares; +Cc: Kernel Mailing List
On Wed Jan 17, 2001 at 09:52:21 +0100, Martin Mares wrote:
> Hello!
>
> > The patch below (against vanilla 2.4.0) makes Linux recognize
> > PCI-Devices sitting in another PCI bus than 0 (or 1).
> >
> > This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
>
> I don't have the ServerWorks chipset documentation at hand, but I think your
> patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
Another possible workaround for my problem is just not to call the
fixup routine for the chipset:
--- pci-pc.c~ Thu Jun 22 16:17:16 2000
+++ pci-pc.c Tue Jan 23 18:46:55 2001
@@ -927,7 +927,6 @@
struct pci_fixup pcibios_fixups[] = {
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82451NX, pci_fixup_i450nx },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454GX, pci_fixup_i450gx },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_LE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_CMIC_HE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_6010, pci_fixup_compaq },
This patch is against 2.4.0-ac10. Having the above line in the PCI devices do
not occur, leaving it out they appear.
Adam
--
Adam al10@inf.tu-dresden.de
Lackorzynski http://a.home.dhs.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] PCI-Devices and ServerWorks chipset
2001-01-23 3:01 ` Tim Hockin
@ 2001-02-08 8:34 ` Martin Mares
0 siblings, 0 replies; 13+ messages in thread
From: Martin Mares @ 2001-02-08 8:34 UTC (permalink / raw)
To: Tim Hockin; +Cc: Maciej W. Rozycki, Adam Lackorzynski, Kernel Mailing List
Hello!
> 0x44 is the primary bus number of the host bridge, and 0x45 is the
> subordinate bus number for the bridge. Just like a PCI-PCI bridge, but
> different :) Since there are two CNB30 functions, each has unique values
> for this. The primary bus of the second bridge must be the subordinate bus
> of the first bridge + 1. PRIMARY(1) = SUBORDINATE(0) + 1;
Yes, this holds for the registers, but not for the actual bus numbers
in the dump sent by Adam -- it shows primary busses 00 and 02, registers
of function 0 say 00--00, of function 1 it's 01--06.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> <mj@suse.cz> http://atrey.karlin.mff.cuni.cz/~mj/
New PC concept: "plug and pray"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2001-02-08 8:34 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-01-16 17:12 [PATCH] PCI-Devices and ServerWorks chipset Adam Lackorzynski
2001-01-17 8:52 ` Martin Mares
2001-01-17 10:14 ` Adam Lackorzynski
2001-01-17 11:25 ` Maciej W. Rozycki
2001-01-17 21:17 ` Dan Hollis
2001-01-18 8:37 ` Maciej W. Rozycki
2001-01-18 10:01 ` Andre Hedrick
2001-01-18 11:08 ` Maciej W. Rozycki
2001-01-18 17:40 ` Andre Hedrick
2001-01-19 12:24 ` Maciej W. Rozycki
2001-01-23 3:01 ` Tim Hockin
2001-02-08 8:34 ` Martin Mares
2001-01-23 18:18 ` Adam Lackorzynski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).