Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, Oct 25, 2000 at 05:59:39PM -0400, Jeff Garzik wrote:
> It may work, but the bridge secondary/subordinate numbers look wrong.
>
No, these numbers look correct for me. Read comment in drivers/pci/pci.c:
if (!is_cardbus) {
/* Now we can scan all subordinate buses... */
max = pci_do_scan_bus(child);
} else {
int i;
/*
* For CardBus bridges, we leave 4 bus numbers
* as cards with a PCI-to-PCI bridge can be
* inserted later.
*/
max += 3;
for (i = 0; i < 4; i++)
child->resource[i] = >resource[PCI_BRIDGE_RESOURCES+i];
}
(Well, comment should say "we leave 3 bus numbers" ;-)
Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Hi Jeff! > First, some definitions: > downstream - away from the host processor > primary - number of the PCI bus closer to the host processor > secondary - number of the PCI bus on the downstream side of the PCI > bridge > subordinate - number of the highest-numbered bus on the downstream side > of the PCI bridge Agreed. > > > 00:03.0 CardBus bridge: Texas Instruments PCI1131 (rev 01) > > Bus: primary=00, secondary=02, subordinate=05, sec-latency=0 > > First bridge on bus 0. > primary == 0 - ok > secondary == 2, should be 1 (bus #1 is behind this bridge) Why? Behind this bridge, there is bus #2, not bus #1. Bus #1 is behind the PCI-to-PCI bridge 00:11.0. > subordinate == 5, should be 2 (bus #2 follows us) The bus numbers assigned by the current kernel may look strange, but they are perfectly correct according to the definition above. The PCI specs don't enforce any specific ordering of bridges on the same bus, the only requirements are that that the secondary...subordinate ranges of the bridges don't overlap and that they are in the secondary+1...subordinate range of the parent bus (which is 01...FF for the root bus). > > 00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01) > > Bus: primary=00, secondary=06, subordinate=09, sec-latency=0 [...] > > 00:11.0 PCI bridge: Intel Corporation 82380FB (rev 01) (prog-if 80) > > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 [...] This gives us the following assignment: 00 root bus (01-FF allowed for its sub-busses) 01 secondary PCI 02-05 first cardbus 06-09 second cardbus which doesn't break the rules. > Second, will anything break if bus numbers change on x86? There exists > pcibios_assign_all_busses() on all platforms... but only Alpha defines > it to 1. All others define it to zero. Yes, it will break on any machine with multiple primary PCI busses, because the registers assigning bus number ranges to primary busses are chipset specific. In 2.5, I'd like to rewrite the resource + bus number assignment code to be able to re-layout the busses and resources even on i386 if it detects it's safe to do so (that is there is either only one primary bus or the host bridge is known). This will be needed for proper PCI hotplug and it will also help us to get rid of some more BIOS bugs (especially on some embedded systems). Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Hi Jeff! First, some definitions: downstream - away from the host processor primary - number of the PCI bus closer to the host processor secondary - number of the PCI bus on the downstream side of the PCI bridge subordinate - number of the highest-numbered bus on the downstream side of the PCI bridge Agreed. 00:03.0 CardBus bridge: Texas Instruments PCI1131 (rev 01) Bus: primary=00, secondary=02, subordinate=05, sec-latency=0 First bridge on bus 0. primary == 0 - ok secondary == 2, should be 1 (bus #1 is behind this bridge) Why? Behind this bridge, there is bus #2, not bus #1. Bus #1 is behind the PCI-to-PCI bridge 00:11.0. subordinate == 5, should be 2 (bus #2 follows us) The bus numbers assigned by the current kernel may look strange, but they are perfectly correct according to the definition above. The PCI specs don't enforce any specific ordering of bridges on the same bus, the only requirements are that that the secondary...subordinate ranges of the bridges don't overlap and that they are in the secondary+1...subordinate range of the parent bus (which is 01...FF for the root bus). 00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01) Bus: primary=00, secondary=06, subordinate=09, sec-latency=0 [...] 00:11.0 PCI bridge: Intel Corporation 82380FB (rev 01) (prog-if 80) Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 [...] This gives us the following assignment: 00 root bus (01-FF allowed for its sub-busses) 01 secondary PCI 02-05 first cardbus 06-09 second cardbus which doesn't break the rules. Second, will anything break if bus numbers change on x86? There exists pcibios_assign_all_busses() on all platforms... but only Alpha defines it to 1. All others define it to zero. Yes, it will break on any machine with multiple primary PCI busses, because the registers assigning bus number ranges to primary busses are chipset specific. In 2.5, I'd like to rewrite the resource + bus number assignment code to be able to re-layout the busses and resources even on i386 if it detects it's safe to do so (that is there is either only one primary bus or the host bridge is known). This will be needed for proper PCI hotplug and it will also help us to get rid of some more BIOS bugs (especially on some embedded systems). Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ "Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, Oct 25, 2000 at 05:59:39PM -0400, Jeff Garzik wrote:
It may work, but the bridge secondary/subordinate numbers look wrong.
No, these numbers look correct for me. Read comment in drivers/pci/pci.c:
if (!is_cardbus) {
/* Now we can scan all subordinate buses... */
max = pci_do_scan_bus(child);
} else {
int i;
/*
* For CardBus bridges, we leave 4 bus numbers
* as cards with a PCI-to-PCI bridge can be
* inserted later.
*/
max += 3;
for (i = 0; i 4; i++)
child-resource[i] = dev-resource[PCI_BRIDGE_RESOURCES+i];
}
(Well, comment should say "we leave 3 bus numbers" ;-)
Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
It may work, but the bridge secondary/subordinate numbers look wrong. I am pondering if the bus numbering/bridging stuff shouldn't be given a good looking-over. I have the wonderful _PCI System Architecture, 4th Ed._ in my hands, and it describes PCI-PCI bridge init in great detail, including several multi-bus, multi-bridge examples. (Martin, run don't walk to amazon to get this book.) Anyway, this book seems to imply that we are getting stuff really wrong somewhere. First, some definitions: downstream - away from the host processor primary - number of the PCI bus closer to the host processor secondary - number of the PCI bus on the downstream side of the PCI bridge subordinate - number of the highest-numbered bus on the downstream side of the PCI bridge > 00:03.0 CardBus bridge: Texas Instruments PCI1131 (rev 01) > Bus: primary=00, secondary=02, subordinate=05, sec-latency=0 First bridge on bus 0. primary == 0 - ok secondary == 2, should be 1 (bus #1 is behind this bridge) subordinate == 5, should be 2 (bus #2 follows us) > 00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01) > Bus: primary=00, secondary=06, subordinate=09, sec-latency=0 Second bridge on bus 0. primary == 0 - ok secondary == 6, should be 2 (bus #2 behind this bridge) subordinate == 9, should be 3 (bus #3 follows us) > 00:11.0 PCI bridge: Intel Corporation 82380FB (rev 01) (prog-if 80) > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Third bridge on bus 0. primary == 0 - ok secondary == 1, should be 3 (bus #3 behind this bridge) subordinate == 1, should be 3 (no bus follows, so subordinate==secondary) Now... this final bridge, the PCI (not CardBus) bridge, actually looks ok... if you imagine that the third bridge is configured before the CardBus bridges for some reason. Bus number 1 appears to be laid out correctly. However, the two CardBus bridges have totally wrong values for the secondary and subordinate bridge numbers, whatever the cause. Questions: Martin, any idea why the bridges are numbered like this? Second, will anything break if bus numbers change on x86? There exists pcibios_assign_all_busses() on all platforms... but only Alpha defines it to 1. All others define it to zero. include/asm-alpha/pci.h: /* Override the logic in pci_scan_bus for skipping already-configured bus numbers. */ #define pcibios_assign_all_busses() 1 And Jamal, can you privately e-mail me your 'dmesg' output (with debugging enabled in pci-i386.h), from -before- applying patches. Regards, Jeff -- Jeff Garzik| Raft naked... Building 1024 | It adds color to your cheeks. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On 24 Oct 2000, Eric W. Biederman wrote: > "David S. Miller" <[EMAIL PROTECTED]> writes: > > > > I bet PCI allows no such thing, thus to be totally safe I would > > conditionalize this feature on the specific bridge. Ie. only allow > > it for this bridge type, because I bet it is just some bug in the > > the address comparators which makes the bridge interpret zero ranges > > as "forward and respond to everything". > > I'm not certain of the details but I do know that it is legal. > To date I've only heard of it on ISA bridges, in particular the PIIXE. All ISA bridges use subtractive decode (== listen to whether somebody else claims it, and if not, take it yourself), and that's part of the spec. However, there can obviously be only one subtractive decoder on a bus: otherwise they'd end up fighting over the requests that don't have anybody on the primary bus. HOWEVER, you could potentially have multiple subtractive decoders if you have multiple buses, and that's actually kind of what my pseudo-patch tries to allow for. I'd like to see what the lspci outout is, but it is possible that the docking bridge is behind another PCI bridge, which would make subtractive decoding legal. The other alternative is that the docking bridge also is the ISA bridge, and knows where the ISA space is (not that hard - ISA IO space is 0x100-0x3ff, and ISA memory space is basically limited to 0xA-1M now that there are no machines with less than 16MB of RAM any more), and then acts as _one_ subtractive bridge, but forwards it to two different buses depending on what the range was. So there does seem to be "legal" ways of doing what the bridge may be doing. I'd still like to see what the PCI details on that system are, and if possible get some documentation on that particular bridge to see what that says.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd)
On Wed, Oct 25, 2000 at 12:20:58PM -0400, jamal wrote: > + child->resource[0,1,2] = dev->bus->resource[0,1,2]; Did C change while I was asleep, or is this statement equivalent to child->resource[2] = dev->bus->resource[2]; ? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
The problem is resolved. Mucho Gracias from me and a few (probably
hundreds of people in my workplace) who might want to boot 2.3/4 on these
Dell docking stations (actually we own a few thousand of them, i am just
trying to make sure Linux runs fine ;->)
The proper fix, which is i think what you meant to say is:
- }
+ } else {
+ /* Transparent bridge */
+ child->resource[0,1,2] = dev->bus->resource[0,1,2];
+ }
instead of "child->resource[0,1,2] = child->bus->resource[0,1,2];"
You might wanna throw in a DBG() in the else as well, just in case someone
else might have problems with this change.
I have attached the output of lspci in the current 2.4 for perusal. I have
also attached a diff with the 2.2 output (lspci -vvv on both)
cheers,
jamal
--- 2.2-lspci Wed Oct 25 08:04:02 2000
+++ 2.4-fixed Wed Oct 25 07:51:20 2000
@@ -2,15 +2,15 @@
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- (32-bit, non-prefetchable)
- Bus: primary=00, secondary=20, subordinate=22, sec-latency=176
+ Region 0: Memory at 1000 (32-bit, non-prefetchable) [size=4K]
+ Bus: primary=00, secondary=02, subordinate=05, sec-latency=0
Memory window 0: - (prefetchable)
Memory window 1: - (prefetchable)
I/O window 0: -0003
I/O window 1: -0003
- BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
- 16-bit legacy interface ports at 0001
+ BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt- PostWrite-
+ 16-bit legacy interface ports at 03e1
00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01)
Subsystem: Dell Computer Corporation: Unknown device 0074
@@ -33,14 +33,14 @@
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- (32-bit, non-prefetchable)
- Bus: primary=00, secondary=23, subordinate=25, sec-latency=176
+ Region 0: Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
+ Bus: primary=00, secondary=06, subordinate=09, sec-latency=0
Memory window 0: - (prefetchable)
Memory window 1: - (prefetchable)
I/O window 0: -0003
I/O window 1: -0003
- BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
- 16-bit legacy interface ports at 0001
+ BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt- PostWrite-
+ 16-bit legacy interface ports at 03e1
00:07.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping-
SERR+ FastB2B-
@@ -51,14 +51,14 @@
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR-
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (AGP
disabled) (rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset+ 16bInt- PostWrite-
16-bit legacy interface ports at 03e1
00: 4c 10 15 ac 07 00 00 02 01 00 07 06 08 20 82 00
10: 00 00 00 10 00 00 00 02 00 02 05 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 0b 01 40 03
40: 28 10 74 00 e1 03 00 00 00 00 00 00 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: 24 10 24 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 82 74 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01)
Subsystem: Dell Computer Corporation: Unknown device 0074
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt- PostWrite-
16-bit legacy interface ports at 03e1
00: 4c 10 15 ac 07 00 00 02 01 00 07 06 08 20 82 00
10: 00 10 00 10 00 00 00 02 00 06 09 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
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd)
Hello! [Sorry for the delay, I've been ill for two weeks and now I'm trying hard to catch up with the huge pile of mail...] > I'm not certain of the details but I do know that it is legal. > To date I've only heard of it on ISA bridges, in particular the PIIXE. > It's some kind of passive listening mode as opposed to actually claiming > the bus cycles. Yes, this is called subtractive address decoding, but as far as I remember, the PCI specifications allow only one subtractive decoder in the system which is in 99% of cases the ISA bridge. Jamal, can you send me "lspci -vvxxx" results on both 2.2 and 2.4, please? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
The problem is resolved. Mucho Gracias from me and a few (probably
hundreds of people in my workplace) who might want to boot 2.3/4 on these
Dell docking stations (actually we own a few thousand of them, i am just
trying to make sure Linux runs fine ;-)
The proper fix, which is i think what you meant to say is:
- }
+ } else {
+ /* Transparent bridge */
+ child-resource[0,1,2] = dev-bus-resource[0,1,2];
+ }
instead of "child-resource[0,1,2] = child-bus-resource[0,1,2];"
You might wanna throw in a DBG() in the else as well, just in case someone
else might have problems with this change.
I have attached the output of lspci in the current 2.4 for perusal. I have
also attached a diff with the 2.2 output (lspci -vvv on both)
cheers,
jamal
--- 2.2-lspci Wed Oct 25 08:04:02 2000
+++ 2.4-fixed Wed Oct 25 07:51:20 2000
@@ -2,15 +2,15 @@
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: 32 set
- Region 0: Memory at e000 (32-bit, prefetchable)
+ Region 0: Memory at e000 (32-bit, prefetchable) [size=256M]
00:02.0 VGA compatible controller: Neomagic Corporation NM2160 [MagicGraph 128XD]
(rev 01) (prog-if 00 [VGA])
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-
Interrupt: pin A routed to IRQ 11
- Region 0: Memory at f000 (32-bit, prefetchable) [disabled]
- Region 1: Memory at f500 (32-bit, non-prefetchable) [disabled]
- Region 2: Memory at f520 (32-bit, non-prefetchable) [disabled]
+ Region 0: Memory at f000 (32-bit, prefetchable) [disabled] [size=16M]
+ Region 1: Memory at f500 (32-bit, non-prefetchable) [disabled] [size=2M]
+ Region 2: Memory at f520 (32-bit, non-prefetchable) [disabled] [size=1M]
00:03.0 CardBus bridge: Texas Instruments PCI1131 (rev 01)
Subsystem: Dell Computer Corporation: Unknown device 0074
@@ -18,14 +18,14 @@
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 32 set, cache line size 08
Interrupt: pin A routed to IRQ 11
- Region 0: Memory at ignored (32-bit, non-prefetchable)
- Bus: primary=00, secondary=20, subordinate=22, sec-latency=176
+ Region 0: Memory at 1000 (32-bit, non-prefetchable) [size=4K]
+ Bus: primary=00, secondary=02, subordinate=05, sec-latency=0
Memory window 0: - (prefetchable)
Memory window 1: - (prefetchable)
I/O window 0: -0003
I/O window 1: -0003
- BridgeCtl: Parity- SERR- ISA- VGA- MAbort- Reset+ 16bInt+ PostWrite+
- 16-bit legacy interface ports at 0001
+ BridgeCtl: Parity- SERR- ISA- VGA- MAbort- Reset+ 16bInt- PostWrite-
+ 16-bit legacy interface ports at 03e1
00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01)
Subsystem: Dell Computer Corporation: Unknown device 0074
@@ -33,14 +33,14 @@
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 32 set, cache line size 08
Interrupt: pin B routed to IRQ 11
- Region 0: Memory at ignored (32-bit, non-prefetchable)
- Bus: primary=00, secondary=23, subordinate=25, sec-latency=176
+ Region 0: Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
+ Bus: primary=00, secondary=06, subordinate=09, sec-latency=0
Memory window 0: - (prefetchable)
Memory window 1: - (prefetchable)
I/O window 0: -0003
I/O window 1: -0003
- BridgeCtl: Parity- SERR- ISA- VGA- MAbort- Reset+ 16bInt+ PostWrite+
- 16-bit legacy interface ports at 0001
+ BridgeCtl: Parity- SERR- ISA- VGA- MAbort- Reset+ 16bInt- PostWrite-
+ 16-bit legacy interface ports at 03e1
00:07.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping-
SERR+ FastB2B-
@@ -51,14 +51,14 @@
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: 32 set
- Region 4: I/O ports at ffa0
+ Region 4: I/O ports at ffa0 [size=16]
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00
[UHCI])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF-
Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd)
On Wed, Oct 25, 2000 at 12:20:58PM -0400, jamal wrote: + child-resource[0,1,2] = dev-bus-resource[0,1,2]; Did C change while I was asleep, or is this statement equivalent to child-resource[2] = dev-bus-resource[2]; ? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
It may work, but the bridge secondary/subordinate numbers look wrong. I am pondering if the bus numbering/bridging stuff shouldn't be given a good looking-over. I have the wonderful _PCI System Architecture, 4th Ed._ in my hands, and it describes PCI-PCI bridge init in great detail, including several multi-bus, multi-bridge examples. (Martin, run don't walk to amazon to get this book.) Anyway, this book seems to imply that we are getting stuff really wrong somewhere. First, some definitions: downstream - away from the host processor primary - number of the PCI bus closer to the host processor secondary - number of the PCI bus on the downstream side of the PCI bridge subordinate - number of the highest-numbered bus on the downstream side of the PCI bridge 00:03.0 CardBus bridge: Texas Instruments PCI1131 (rev 01) Bus: primary=00, secondary=02, subordinate=05, sec-latency=0 First bridge on bus 0. primary == 0 - ok secondary == 2, should be 1 (bus #1 is behind this bridge) subordinate == 5, should be 2 (bus #2 follows us) 00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01) Bus: primary=00, secondary=06, subordinate=09, sec-latency=0 Second bridge on bus 0. primary == 0 - ok secondary == 6, should be 2 (bus #2 behind this bridge) subordinate == 9, should be 3 (bus #3 follows us) 00:11.0 PCI bridge: Intel Corporation 82380FB (rev 01) (prog-if 80) Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Third bridge on bus 0. primary == 0 - ok secondary == 1, should be 3 (bus #3 behind this bridge) subordinate == 1, should be 3 (no bus follows, so subordinate==secondary) Now... this final bridge, the PCI (not CardBus) bridge, actually looks ok... if you imagine that the third bridge is configured before the CardBus bridges for some reason. Bus number 1 appears to be laid out correctly. However, the two CardBus bridges have totally wrong values for the secondary and subordinate bridge numbers, whatever the cause. Questions: Martin, any idea why the bridges are numbered like this? Second, will anything break if bus numbers change on x86? There exists pcibios_assign_all_busses() on all platforms... but only Alpha defines it to 1. All others define it to zero. include/asm-alpha/pci.h: /* Override the logic in pci_scan_bus for skipping already-configured bus numbers. */ #define pcibios_assign_all_busses() 1 And Jamal, can you privately e-mail me your 'dmesg' output (with debugging enabled in pci-i386.h), from -before- applying patches. Regards, Jeff -- Jeff Garzik| Raft naked... Building 1024 | It adds color to your cheeks. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On 24 Oct 2000, Eric W. Biederman wrote: "David S. Miller" [EMAIL PROTECTED] writes: I bet PCI allows no such thing, thus to be totally safe I would conditionalize this feature on the specific bridge. Ie. only allow it for this bridge type, because I bet it is just some bug in the the address comparators which makes the bridge interpret zero ranges as "forward and respond to everything". I'm not certain of the details but I do know that it is legal. To date I've only heard of it on ISA bridges, in particular the PIIXE. All ISA bridges use subtractive decode (== listen to whether somebody else claims it, and if not, take it yourself), and that's part of the spec. However, there can obviously be only one subtractive decoder on a bus: otherwise they'd end up fighting over the requests that don't have anybody on the primary bus. HOWEVER, you could potentially have multiple subtractive decoders if you have multiple buses, and that's actually kind of what my pseudo-patch tries to allow for. I'd like to see what the lspci outout is, but it is possible that the docking bridge is behind another PCI bridge, which would make subtractive decoding legal. The other alternative is that the docking bridge also is the ISA bridge, and knows where the ISA space is (not that hard - ISA IO space is 0x100-0x3ff, and ISA memory space is basically limited to 0xA-1M now that there are no machines with less than 16MB of RAM any more), and then acts as _one_ subtractive bridge, but forwards it to two different buses depending on what the range was. So there does seem to be "legal" ways of doing what the bridge may be doing. I'd still like to see what the PCI details on that system are, and if possible get some documentation on that particular bridge to see what that says.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd)
Hello! [Sorry for the delay, I've been ill for two weeks and now I'm trying hard to catch up with the huge pile of mail...] I'm not certain of the details but I do know that it is legal. To date I've only heard of it on ISA bridges, in particular the PIIXE. It's some kind of passive listening mode as opposed to actually claiming the bus cycles. Yes, this is called subtractive address decoding, but as far as I remember, the PCI specifications allow only one subtractive decoder in the system which is in 99% of cases the ISA bridge. Jamal, can you send me "lspci -vvxxx" results on both 2.2 and 2.4, please? Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ "Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd)
"David S. Miller" <[EMAIL PROTECTED]> writes: >Date: Tue, 24 Oct 2000 13:50:10 -0700 (PDT) >From: Linus Torvalds <[EMAIL PROTECTED]> > >Does the above make it work for you? I don't know if PCI even has >the notion of transparent bridging, and quite frankly I doubt it >does. The above would be nothing but a hack that basically says "I >don't understand the resources of this bridge, so I'll just say it >bridges everything". > > I bet PCI allows no such thing, thus to be totally safe I would > conditionalize this feature on the specific bridge. Ie. only allow > it for this bridge type, because I bet it is just some bug in the > the address comparators which makes the bridge interpret zero ranges > as "forward and respond to everything". I'm not certain of the details but I do know that it is legal. To date I've only heard of it on ISA bridges, in particular the PIIXE. It's some kind of passive listening mode as opposed to actually claiming the bus cycles. > This only would make sense if the bridge snooped config space access > to devices behind it, so that it knew what addresses to forward and > respond to. Just responding to "everything" would not work for > obvious reasons. Right but I don't think you actually have to respond. Not that I think this is a good idea, but it does appear to be legal. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Tue, 24 Oct 2000, jamal wrote:
>
> (Now that i see Martin alive).
> Could we pursue this further?
The trouble definitely seems to be the fact that your PCI-PCI bridge does
not seem to have been set up for bridging:
bus res 0 0 -
bus res 1 0 -
bus res 2 1200 e400-e5ff
and it appears that the reason 2.2.x works is simply that 2.2.x doesn't
care because it doesn't keep track of resources at all - it just takes
what the devices say their resources are. And the bridge obviously
_works_, it just doesn't tell which area it bridges.
Can you do a "lspci -vvxxx" on a 2.2.x setup, so that I can take a look at
what the bridge claims it is doing.
I quite frankly have no idea what to do otherwise. We could special-case a
bridge resource that is all zeroes, and say that it's a "transparent"
bridge and just say that the resource is the same as the parent resource.
That might get you going. It's probably not the right thing to do, but you
_can_ try something like this in pci_read_bridge_bases(), where it does
if (base && base <= limit) {
res->flags |= ...
..
- }
+ } else {
+ /* Transparent bridge */
+ child->resource[0] = child->bus->resource[0];
+ }
..
(and do same thing for resource[1] and resource[2]..)
Does the above make it work for you? I don't know if PCI even has the
notion of transparent bridging, and quite frankly I doubt it does. The
above would be nothing but a hack that basically says "I don't understand
the resources of this bridge, so I'll just say it bridges everything".
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Linus, Martin (Now that i see Martin alive). Could we pursue this further? cheers, jamal -- Forwarded message -- Date: Sun, 15 Oct 2000 19:58:24 -0400 (EDT) From: jamal <[EMAIL PROTECTED]> To: Linus Torvalds <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], Martin Mares <[EMAIL PROTECTED]> Subject: Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd) Sorry for the delay, the docking station in question is a few kilometers away. On Fri, 13 Oct 2000, Linus Torvalds wrote: > And I don't find any code that would ever have done this, either. It must > be somewhere, if 2.2 works for you. > I can put up the 2.2 bootup with DEBUG in pci.c if this is of interest > Ehh. How about yet another debugging patch, to see what the bridge bases > are? In drivers/pci/pci.c, function pci_read_bridge_bases(), find the attached. cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #7 Sat Oct 14 12:18:35 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.472 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1095k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 IO base: 00c0 limit: 00c0 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning bus 02 Found 02:08 [102b/051b] 000300 00 Found 02:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 02:05.0 Found 02:38 [9004/6078] 000100 00 Found 02:40 [10b7/9050] 000200 00 Fixups for bus 02 PCI: Scanning for ghost devices on bus 2 IO base: limit: Bus scan for 02 returning with max=02 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource e780-e7ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Resource e500-e5ff (f=1208, d=0, p=0) PCI: Resource fbffc000-fbff (f=200, d=0, p=0) PCI: Cannot allocate resource region 1 of device 02:01.0 PCI: Resource fb00-fb7f (f=200
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Linus, Martin (Now that i see Martin alive). Could we pursue this further? cheers, jamal -- Forwarded message -- Date: Sun, 15 Oct 2000 19:58:24 -0400 (EDT) From: jamal [EMAIL PROTECTED] To: Linus Torvalds [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Martin Mares [EMAIL PROTECTED] Subject: Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd) Sorry for the delay, the docking station in question is a few kilometers away. On Fri, 13 Oct 2000, Linus Torvalds wrote: And I don't find any code that would ever have done this, either. It must be somewhere, if 2.2 works for you. I can put up the 2.2 bootup with DEBUG in pci.c if this is of interest Ehh. How about yet another debugging patch, to see what the bridge bases are? In drivers/pci/pci.c, function pci_read_bridge_bases(), find the attached. cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #7 Sat Oct 14 12:18:35 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.472 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1095k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 IO base: 00c0 limit: 00c0 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning bus 02 Found 02:08 [102b/051b] 000300 00 Found 02:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 02:05.0 Found 02:38 [9004/6078] 000100 00 Found 02:40 [10b7/9050] 000200 00 Fixups for bus 02 PCI: Scanning for ghost devices on bus 2 IO base: limit: Bus scan for 02 returning with max=02 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource e780-e7ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Resource e500-e5ff (f=1208, d=0, p=0) PCI: Resource fbffc000-fbff (f=200, d=0, p=0) PCI: Cannot allocate resource region 1 of device 02:01.0 PCI: Resource fb00-fb7f (f=200, d=0, p=0) PCI: Cannot allocate resource region 2
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Tue, 24 Oct 2000, jamal wrote:
(Now that i see Martin alive).
Could we pursue this further?
The trouble definitely seems to be the fact that your PCI-PCI bridge does
not seem to have been set up for bridging:
bus res 0 0 -
bus res 1 0 -
bus res 2 1200 e400-e5ff
and it appears that the reason 2.2.x works is simply that 2.2.x doesn't
care because it doesn't keep track of resources at all - it just takes
what the devices say their resources are. And the bridge obviously
_works_, it just doesn't tell which area it bridges.
Can you do a "lspci -vvxxx" on a 2.2.x setup, so that I can take a look at
what the bridge claims it is doing.
I quite frankly have no idea what to do otherwise. We could special-case a
bridge resource that is all zeroes, and say that it's a "transparent"
bridge and just say that the resource is the same as the parent resource.
That might get you going. It's probably not the right thing to do, but you
_can_ try something like this in pci_read_bridge_bases(), where it does
if (base base = limit) {
res-flags |= ...
..
- }
+ } else {
+ /* Transparent bridge */
+ child-resource[0] = child-bus-resource[0];
+ }
..
(and do same thing for resource[1] and resource[2]..)
Does the above make it work for you? I don't know if PCI even has the
notion of transparent bridging, and quite frankly I doubt it does. The
above would be nothing but a hack that basically says "I don't understand
the resources of this bridge, so I'll just say it bridges everything".
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd)
"David S. Miller" [EMAIL PROTECTED] writes: Date: Tue, 24 Oct 2000 13:50:10 -0700 (PDT) From: Linus Torvalds [EMAIL PROTECTED] Does the above make it work for you? I don't know if PCI even has the notion of transparent bridging, and quite frankly I doubt it does. The above would be nothing but a hack that basically says "I don't understand the resources of this bridge, so I'll just say it bridges everything". I bet PCI allows no such thing, thus to be totally safe I would conditionalize this feature on the specific bridge. Ie. only allow it for this bridge type, because I bet it is just some bug in the the address comparators which makes the bridge interpret zero ranges as "forward and respond to everything". I'm not certain of the details but I do know that it is legal. To date I've only heard of it on ISA bridges, in particular the PIIXE. It's some kind of passive listening mode as opposed to actually claiming the bus cycles. This only would make sense if the bridge snooped config space access to devices behind it, so that it knew what addresses to forward and respond to. Just responding to "everything" would not work for obvious reasons. Right but I don't think you actually have to respond. Not that I think this is a good idea, but it does appear to be legal. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Sorry for the delay, the docking station in question is a few kilometers away. On Fri, 13 Oct 2000, Linus Torvalds wrote: > And I don't find any code that would ever have done this, either. It must > be somewhere, if 2.2 works for you. > I can put up the 2.2 bootup with DEBUG in pci.c if this is of interest > Ehh. How about yet another debugging patch, to see what the bridge bases > are? In drivers/pci/pci.c, function pci_read_bridge_bases(), find the attached. cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #7 Sat Oct 14 12:18:35 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.472 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1095k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 IO base: 00c0 limit: 00c0 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning bus 02 Found 02:08 [102b/051b] 000300 00 Found 02:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 02:05.0 Found 02:38 [9004/6078] 000100 00 Found 02:40 [10b7/9050] 000200 00 Fixups for bus 02 PCI: Scanning for ghost devices on bus 2 IO base: limit: Bus scan for 02 returning with max=02 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource e780-e7ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Resource e500-e5ff (f=1208, d=0, p=0) PCI: Resource fbffc000-fbff (f=200, d=0, p=0) PCI: Cannot allocate resource region 1 of device 02:01.0 PCI: Resource fb00-fb7f (f=200, d=0, p=0) PCI: Cannot allocate resource region 2 of device 02:01.0 PCI: Resource fcf8-fcff (f=109, d=0, p=0) PCI: Cannot allocate resource region 0 of device 02:05.0 PCI: Resource fcf0-fcf3 (f=101, d=0, p=0) PCI: Cannot allocate resource region 1 of device 02:05.0 PCI: Resource fce0-fce7 (f=101, d=0, p=0) PCI: Cannot allocate resource region 2 of device 02:05.0 PCI: Resource fcd8-fcdb (f=109, d=0,
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, jamal wrote: > > This is in addition to the debug statements from the previous email > Weirder results (like bus 0x0a) Ok, thanks - this part didn't get anything new, the bus numbers are just different due to the re-allocation, the actual bus windows are the same broken ones. I wonder why they are so broken. And why did 2.2 work? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, jamal wrote:
>
> On Fri, 13 Oct 2000, Linus Torvalds wrote:>
> > Can you add the same extra debug code that I asked Dag Bakke to add for
> > his problem:
>
> Attached.
Thanks.
It looks like the bridge that your docking devices are behind (I assume
that's just a regular docking bridge) has not been set up correctly, and
has a serious lack of bridging windows, which causes the inability for
Linux to map any of the devices behind that bus. So you get printouts like
bus res 0 0 -
bus res 1 0 -
bus res 2 1200 e400-e5ff
device Matrox Graphics, Inc. MGA 2164W [Millennium II] resource 1 size 4000
PCI: Failed to allocate resource 1 for Matrox Graphics, Inc. MGA 2164W
[Millennium II]
The above means that of the three bus windows set up for the PCI-PCI
bridge for the docking, two are disabled, and the last one is a
prefetchable memory window which is unacceptable to most devices (the
Matrox want a non-prefetchable window for its command area).
The other cases all show the same.
Martin, what's up? It looks like PCI-PCI bridge windows are not enabled
and set up at all. At least on this particular machine.
And I don't find any code that would ever have done this, either. It must
be somewhere, if 2.2 works for you.
Ehh. How about yet another debugging patch, to see what the bridge bases
are? In drivers/pci/pci.c, function pci_read_bridge_bases(), find the
place where it reads the PCI_IO_BASE/LIMIT and the UPPER bits, and add
printk("IO base: %04x%04x limit: %04x%04x\n",
io_base_hi, io_base_lo,
io_limit_hi, io_limit_lo);
to before the sanity test for the resource[0] case (ie before the stuff
that says "if (base && base <= limit) {" etc).
And do the same for the mem_base stuff for the resource[1] and resource[2]
cases.
Martin, any ideas on why only the prefetchable memory case would show up?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote: > Oh, also, can you try to see what happens if you change the define for > > #define pcibios_assign_all_busses() 0 > > to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure > all buses, regardless of whether they have been set up some way by the > BIOS. Which might make a difference. > > But please do this separately from the extra debug code - I'd like to see > what the debug code says regardless of this change.. This is in addition to the debug statements from the previous email Weirder results (like bus 0x0a) cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 Fri Oct 13 18:06:10 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.478 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1095k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Scanning bus 0a Found 0a:08 [102b/051b] 000300 00 Found 0a:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 0a:05.0 Found 0a:38 [9004/6078] 000100 00 Found 0a:40 [10b7/9050] 000200 00 Fixups for bus 0a PCI: Scanning for ghost devices on bus 10 Bus scan for 0a returning with max=0a Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource e780-e7ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Resource e500-e5ff (f=1208, d=0, p=0) PCI: Resource fbffc000-fbff (f=200, d=0, p=0) PCI: Cannot allocate resource region 1 of device 0a:01.0 PCI: Resource fb00-fb7f (f=200, d=0, p=0) PCI: Cannot allocate resource region 2 of device 0a:01.0 PCI: Resource fcf8-fcff (f=109, d=0, p=0) PCI: Cannot allocate resource region 0 of device 0a:05.0 PCI: Resource fcf0-fcf3 (f=101, d=0, p=0) PCI: Cannot allocate resource region 1 of device 0a:05.0 PCI: Resource fce0-fce7 (f=101, d=0, p=0) PCI: Cannot allocate resource region 2 of device
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote:
> Can you add the same extra debug code that I asked Dag Bakke to add for
> his problem:
>
> -- snip from another email, because I'm lazy ---
>
> Please add a debug printk() to drivers/pci/setup-res.c to the very end of
> pci_assign_bus_resource(), just before the "return -EBUSY", something like
>
> printk("device %s resource %d size %08lx\n", dev->name, resno, size);
>
> just to see what it wants and why it fails..
>
> Also, it's probably worth printing out what the actual bus resources are,
> to possibly explain the failure. So add another line that says
>
> printk("bus res %d %x %08lx-%08lx\n", i, r->flags, r->start,
> r->end);
>
Attached.
cheers,
jamal
Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #5 Fri Oct 13 18:02:43 EDT 2000
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820: c000 @ 000c (reserved)
BIOS-e820: 0fef @ 0010 (usable)
BIOS-e820: 0001 @ 0fff (ACPI data)
BIOS-e820: 0006 @ 100a (reserved)
BIOS-e820: 0020 @ ffe0 (reserved)
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
Kernel command line:
Initializing CPU#0
Detected 498.471 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 992.87 BogoMIPS
Memory: 255768k/262080k available (1095k kernel code, 5924k reserved, 70k data, 188k
init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Intel Pentium III (Coppermine) stepping 03
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED])
PCI: BIOS32 Service Directory structure at 0xc00ffe80
PCI: BIOS32 Service Directory entry at 0xffe90
PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02
PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
Scanning bus 00
Found 00:00 [8086/7190] 000600 00
Found 00:08 [8086/7191] 000604 01
Found 00:18 [104c/ac1c] 000607 02
Found 00:19 [104c/ac1c] 000607 02
Found 00:38 [8086/7110] 000680 00
Found 00:39 [8086/7111] 000101 00
PCI: IDE base address fixup for 00:07.1
Found 00:3a [8086/7112] 000c03 00
Found 00:3b [8086/7113] 000680 00
Found 00:88 [8086/124b] 000604 01
Fixups for bus 00
PCI: Scanning for ghost devices on bus 0
Scanning behind PCI bridge 00:01.0, config 010100, pass 0
Scanning bus 01
Found 01:00 [10c8/0006] 000300 00
Found 01:01 [10c8/8006] 000401 00
Fixups for bus 01
PCI: Scanning for ghost devices on bus 1
Bus scan for 01 returning with max=01
Scanning behind PCI bridge 00:03.0, config 00, pass 0
Scanning behind PCI bridge 00:03.1, config 00, pass 0
Scanning behind PCI bridge 00:11.0, config 020200, pass 0
Scanning bus 02
Found 02:08 [102b/051b] 000300 00
Found 02:28 [1095/0646] 000101 00
PCI: IDE base address fixup for 02:05.0
Found 02:38 [9004/6078] 000100 00
Found 02:40 [10b7/9050] 000200 00
Fixups for bus 02
PCI: Scanning for ghost devices on bus 2
Bus scan for 02 returning with max=02
Scanning behind PCI bridge 00:01.0, config 010100, pass 1
Scanning behind PCI bridge 00:03.0, config 00, pass 1
Scanning behind PCI bridge 00:03.1, config 00, pass 1
Scanning behind PCI bridge 00:11.0, config 020200, pass 1
Bus scan for 00 returning with max=0a
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00fbd80
00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8
01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/
00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/
00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/
00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8
PCI: Bus 01 already known
PCI: Using IRQ router default [8086/1234] at 00:07.0
PCI: IRQ fixup
PCI: Allocating resources
PCI: Resource e000-e3ff (f=1208, d=0, p=0)
PCI: Resource 0860-086f (f=101, d=0, p=0)
PCI: Resource ece0-ecff (f=101, d=0, p=0)
PCI: Resource e780-e7ff (f=1208, d=0, p=0)
PCI: Resource fda0-fdaf (f=200, d=0, p=0)
PCI: Resource e500-e5ff (f=1208, d=0, p=0)
PCI: Resource fbffc000-fbff (f=200, d=0, p=0)
PCI: Cannot allocate resource region 1 of device 02:01.0
PCI: Resource fb00-fb7f (f=200, d=0, p=0)
PCI: Cannot allocate resource region 2 of device 02:01.0
PCI: Resource fcf8-fcff (f=109, d=0, p=0)
PCI: Cannot allocate resource region 0 of device 02:05.0
PCI: Resource fcf0-fcf3 (f=101, d=0, p=0)
PCI: Cannot allocate resource
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote: > > Can you add the same extra debug code that I asked Dag Bakke to add for > his problem: Oh, also, can you try to see what happens if you change the define for #define pcibios_assign_all_busses() 0 to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure all buses, regardless of whether they have been set up some way by the BIOS. Which might make a difference. But please do this separately from the extra debug code - I'd like to see what the debug code says regardless of this change.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Thu, 12 Oct 2000, jamal wrote:
>
> I am attaching the debug output on bootup after defining DEBUG in pci.c
> and the i386 pci header file with test10-pre2
> Note: this is a Dell Lattitude docking station. The devices which are
> having resource problems are on the docking station. Works fine with 2.2
> kernels.
Can you add the same extra debug code that I asked Dag Bakke to add for
his problem:
-- snip from another email, because I'm lazy ---
Please add a debug printk() to drivers/pci/setup-res.c to the very end of
pci_assign_bus_resource(), just before the "return -EBUSY", something like
printk("device %s resource %d size %08lx\n", dev->name, resno, size);
just to see what it wants and why it fails..
Also, it's probably worth printing out what the actual bus resources are,
to possibly explain the failure. So add another line that says
printk("bus res %d %x %08lx-%08lx\n", i, r->flags, r->start,
r->end);
just after the line that says
if (!r)
continue;
in the same function.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Thu, 12 Oct 2000, jamal wrote:
I am attaching the debug output on bootup after defining DEBUG in pci.c
and the i386 pci header file with test10-pre2
Note: this is a Dell Lattitude docking station. The devices which are
having resource problems are on the docking station. Works fine with 2.2
kernels.
Can you add the same extra debug code that I asked Dag Bakke to add for
his problem:
-- snip from another email, because I'm lazy ---
Please add a debug printk() to drivers/pci/setup-res.c to the very end of
pci_assign_bus_resource(), just before the "return -EBUSY", something like
printk("device %s resource %d size %08lx\n", dev-name, resno, size);
just to see what it wants and why it fails..
Also, it's probably worth printing out what the actual bus resources are,
to possibly explain the failure. So add another line that says
printk("bus res %d %x %08lx-%08lx\n", i, r-flags, r-start,
r-end);
just after the line that says
if (!r)
continue;
in the same function.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote: Can you add the same extra debug code that I asked Dag Bakke to add for his problem: Oh, also, can you try to see what happens if you change the define for #define pcibios_assign_all_busses() 0 to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure all buses, regardless of whether they have been set up some way by the BIOS. Which might make a difference. But please do this separately from the extra debug code - I'd like to see what the debug code says regardless of this change.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote: Oh, also, can you try to see what happens if you change the define for #define pcibios_assign_all_busses() 0 to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure all buses, regardless of whether they have been set up some way by the BIOS. Which might make a difference. But please do this separately from the extra debug code - I'd like to see what the debug code says regardless of this change.. This is in addition to the debug statements from the previous email Weirder results (like bus 0x0a) cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 Fri Oct 13 18:06:10 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.478 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1095k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Scanning bus 0a Found 0a:08 [102b/051b] 000300 00 Found 0a:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 0a:05.0 Found 0a:38 [9004/6078] 000100 00 Found 0a:40 [10b7/9050] 000200 00 Fixups for bus 0a PCI: Scanning for ghost devices on bus 10 Bus scan for 0a returning with max=0a Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource e780-e7ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Resource e500-e5ff (f=1208, d=0, p=0) PCI: Resource fbffc000-fbff (f=200, d=0, p=0) PCI: Cannot allocate resource region 1 of device 0a:01.0 PCI: Resource fb00-fb7f (f=200, d=0, p=0) PCI: Cannot allocate resource region 2 of device 0a:01.0 PCI: Resource fcf8-fcff (f=109, d=0, p=0) PCI: Cannot allocate resource region 0 of device 0a:05.0 PCI: Resource fcf0-fcf3 (f=101, d=0, p=0) PCI: Cannot allocate resource region 1 of device 0a:05.0 PCI: Resource fce0-fce7 (f=101, d=0, p=0) PCI: Cannot allocate resource region 2 of device 0a:05.0
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, jamal wrote:
On Fri, 13 Oct 2000, Linus Torvalds wrote:
Can you add the same extra debug code that I asked Dag Bakke to add for
his problem:
Attached.
Thanks.
It looks like the bridge that your docking devices are behind (I assume
that's just a regular docking bridge) has not been set up correctly, and
has a serious lack of bridging windows, which causes the inability for
Linux to map any of the devices behind that bus. So you get printouts like
bus res 0 0 -
bus res 1 0 -
bus res 2 1200 e400-e5ff
device Matrox Graphics, Inc. MGA 2164W [Millennium II] resource 1 size 4000
PCI: Failed to allocate resource 1 for Matrox Graphics, Inc. MGA 2164W
[Millennium II]
The above means that of the three bus windows set up for the PCI-PCI
bridge for the docking, two are disabled, and the last one is a
prefetchable memory window which is unacceptable to most devices (the
Matrox want a non-prefetchable window for its command area).
The other cases all show the same.
Martin, what's up? It looks like PCI-PCI bridge windows are not enabled
and set up at all. At least on this particular machine.
And I don't find any code that would ever have done this, either. It must
be somewhere, if 2.2 works for you.
Ehh. How about yet another debugging patch, to see what the bridge bases
are? In drivers/pci/pci.c, function pci_read_bridge_bases(), find the
place where it reads the PCI_IO_BASE/LIMIT and the UPPER bits, and add
printk("IO base: %04x%04x limit: %04x%04x\n",
io_base_hi, io_base_lo,
io_limit_hi, io_limit_lo);
to before the sanity test for the resource[0] case (ie before the stuff
that says "if (base base = limit) {" etc).
And do the same for the mem_base stuff for the resource[1] and resource[2]
cases.
Martin, any ideas on why only the prefetchable memory case would show up?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
I am attaching the debug output on bootup after defining DEBUG in pci.c and the i386 pci header file with test10-pre2 Note: this is a Dell Lattitude docking station. The devices which are having resource problems are on the docking station. Works fine with 2.2 kernels. Yes, this is on RH7 with kgcc. Please dont distract the subject header if you wanna attack that specifi issue. Just change the header and start a new thread. cheers, jamal -- Forwarded message -- Date: Tue, 10 Oct 2000 19:56:46 -0400 (EDT) From: jamal <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Martin Mares <[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]> Subject: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd) Ted, Please add this to your list. Linux is unusable in these machines. I have cc'ed Martin and Linus because they play in that PCI area. cheers, jamal -- Forwarded message -- Date: Thu, 5 Oct 2000 17:23:13 -0400 (EDT) From: jamal <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: test9 PCI resource collisions I have attached a few details of what appears to be a PCI resource alloc problem (IO ports from the look of it). Note: This is on a dell lattitude machine that never booted before with a docked setup. Enjoy! cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #4 Thu Oct 12 17:30:43 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.482 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1094k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning bus 02 Found 02:08 [102b/051b] 000300 00 Found 02:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 02:05.0 Found 02:38 [9004/6078] 000100 00 Found 02:40 [10b7/9050] 000200 00 Fixups for bus 02 PCI: Scanning for ghost devices on bus 2 Bus scan for 02 returning with max=02 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101,
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
Cort Dougan <[EMAIL PROTECTED]> said: > Horst von Brand on Wed, Oct 11, 2000 at 11:21:06PM -0400 said: [...] > } Oh, come on. The kernel (or glibc for that matter) is not about "inline > } asm()" at all! That is a tiny fraction of each. The kernel is different in > } that it has lots of hardware-dependent code, which leads to some rather > } strange contortions in C in order to be able to _avoid_ asm. The kernel > } also moves forward a lot faster than glibc, and grows a lot. A bug in glibc > } means an application goes down or screws up, a bug in the kernel can mean > } masive data loss in no time at all. > I don't think I understand your point. Are you saying that gcc cannot be > expected to keep up with the ways in which the kernel uses it? My argument > is that providing a compiler that actually regresses (old version compiles > kernel, redhat 7.0 included one does not) is not a good choice. What I'm stating is just the fact that the kernel isn't keeping up with the compiler. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Thu, Oct 12, 2000 at 06:26:57AM -0400, Horst von Brand wrote: > [EMAIL PROTECTED] said: > > Foolhardy as it may be, people do _use_ the operating system to run > > important applications and an "application goes down or screws up" can be > > quite serious. > > Yes. But "the kernel screws up and crashes" is more serious, as it takes > _all_ applications with it. And if it is "screws up and scribbles on de > disks" the losses are even much more serious. Really? More serious than a multithreaded data base failing to synchronize as promised? Get real. You can't do this type of ranking. If the compiler is bad, the entire system is a joke. Users don't care whether the accounting system fails and the telephone stops working because of a compiler error or a kernel crash. > -- > Horst von Brand [EMAIL PROTECTED] > Casilla 9G, Vin~a del Mar, Chile +56 32 672616 -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
[EMAIL PROTECTED] said: > On Wed, Oct 11, 2000 at 11:21:06PM -0400, Horst von Brand wrote: > > also moves forward a lot faster than glibc, and grows a lot. A bug in glibc > > means an application goes down or screws up, a bug in the kernel can mean > > masive data loss in no time at all. > Foolhardy as it may be, people do _use_ the operating system to run > important applications and an "application goes down or screws up" can be > quite serious. Yes. But "the kernel screws up and crashes" is more serious, as it takes _all_ applications with it. And if it is "screws up and scribbles on de disks" the losses are even much more serious. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, 11 Oct 2000, Nathan Paul Simons wrote: > On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote: > > Hardly. In fact the idea of distributing a different compiler for kernels > > comes from debian and the kgcc naming convention from Conectiva. > > What different compiler? If you're talking about the kernel-package > package of Debian, that's only scripts to generate a Debian kernel package > from custom source. % dpkg-awk Package:gcc272 Package: gcc272 Status: install ok installed Priority: optional Section: devel Installed-Size: 1588 Maintainer: Debian GCC maintainers <[EMAIL PROTECTED]> Version: 2.7.2.3-15 Replaces: gcc (<= 2.7.2.3-7), cpp (<= 2.7.2.3-7) Provides: c-compiler Depends: libc6, binutils (>= 2.8-1) Recommends: libc-dev Suggests: gcc272-docs Conflicts: libc5-dev, gcc (<= 2.7.2.3-7), cpp (<= 2.7.2.3-7) Description: The GNU C compiler. This is the old version of the GNU C compiler's C part. It should only be used for backward compatibility purposes. . The GNU C compiler is a fairly portable optimizing compiler that supports multiple languages. It includes (runtime) support for C. The g++ and ObjC compilers are not longer part of the current Debian release. Get the packages from the Debian 2.1 (slink) release. % dpkg -l gcc gcc272 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii gcc2.95.2-13 The GNU C compiler. ii gcc272 2.7.2.3-15 The GNU C compiler. % Grep debian-devel for gcc272 - switching default gcc to egcs (early unstable for potato, March '99 IIRC) required that because quite a few things didn't build correctly with 2.91 (and later 2.95). OTOH C++ side sucked badly and newer versions were clearly better in that area. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
[EMAIL PROTECTED] said: > The genuine Linux kernel distribution contains its own documentation > on how to build and configure it. Indeed it does. Documentation/Changes says: GCC --- You will need at least gcc 2.7.2 to compile the kernel. You currently have several options for gcc-derived compilers: gcc 2.7.2.3, various versions of egcs, the new gcc 2.95 and upcoming gcc 3.0, and experimental compilers like pgcc. For absolute stability, it is still recommended that gcc 2.7.2.3 be used to compile your kernel. egcs 1.1.2 should also work. gcc 2.95 is known to have problems, and using pgcc for your kernel is just asking for trouble. > The kgcc story looks to me like a lie from RedHat. In my opinion, they > just don't want to recognize that they have been loose. $ kgcc -v Reading specs from /usr/lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Looks true to me. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
> I don't think I understand your point. Are you saying that gcc cannot be > expected to keep up with the ways in which the kernel uses it? My argument > is that providing a compiler that actually regresses (old version compiles > kernel, redhat 7.0 included one does not) is not a good choice. The bugs are as far as I can tell in the kernel sources not in gcc. The code optimising has improved and that gets us little suprises. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
> What different compiler? If you're talking about the kernel-package > package of Debian, that's only scripts to generate a Debian kernel package > from custom source. The gcc272 package - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
What different compiler? If you're talking about the kernel-package package of Debian, that's only scripts to generate a Debian kernel package from custom source. The gcc272 package - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
I don't think I understand your point. Are you saying that gcc cannot be expected to keep up with the ways in which the kernel uses it? My argument is that providing a compiler that actually regresses (old version compiles kernel, redhat 7.0 included one does not) is not a good choice. The bugs are as far as I can tell in the kernel sources not in gcc. The code optimising has improved and that gets us little suprises. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, 11 Oct 2000, Nathan Paul Simons wrote: On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote: Hardly. In fact the idea of distributing a different compiler for kernels comes from debian and the kgcc naming convention from Conectiva. What different compiler? If you're talking about the kernel-package package of Debian, that's only scripts to generate a Debian kernel package from custom source. % dpkg-awk Package:gcc272 Package: gcc272 Status: install ok installed Priority: optional Section: devel Installed-Size: 1588 Maintainer: Debian GCC maintainers [EMAIL PROTECTED] Version: 2.7.2.3-15 Replaces: gcc (= 2.7.2.3-7), cpp (= 2.7.2.3-7) Provides: c-compiler Depends: libc6, binutils (= 2.8-1) Recommends: libc-dev Suggests: gcc272-docs Conflicts: libc5-dev, gcc (= 2.7.2.3-7), cpp (= 2.7.2.3-7) Description: The GNU C compiler. This is the old version of the GNU C compiler's C part. It should only be used for backward compatibility purposes. . The GNU C compiler is a fairly portable optimizing compiler that supports multiple languages. It includes (runtime) support for C. The g++ and ObjC compilers are not longer part of the current Debian release. Get the packages from the Debian 2.1 (slink) release. % dpkg -l gcc gcc272 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii gcc2.95.2-13 The GNU C compiler. ii gcc272 2.7.2.3-15 The GNU C compiler. % Grep debian-devel for gcc272 - switching default gcc to egcs (early unstable for potato, March '99 IIRC) required that because quite a few things didn't build correctly with 2.91 (and later 2.95). OTOH C++ side sucked badly and newer versions were clearly better in that area. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
[EMAIL PROTECTED] said: On Wed, Oct 11, 2000 at 11:21:06PM -0400, Horst von Brand wrote: also moves forward a lot faster than glibc, and grows a lot. A bug in glibc means an application goes down or screws up, a bug in the kernel can mean masive data loss in no time at all. Foolhardy as it may be, people do _use_ the operating system to run important applications and an "application goes down or screws up" can be quite serious. Yes. But "the kernel screws up and crashes" is more serious, as it takes _all_ applications with it. And if it is "screws up and scribbles on de disks" the losses are even much more serious. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Thu, Oct 12, 2000 at 06:26:57AM -0400, Horst von Brand wrote: [EMAIL PROTECTED] said: Foolhardy as it may be, people do _use_ the operating system to run important applications and an "application goes down or screws up" can be quite serious. Yes. But "the kernel screws up and crashes" is more serious, as it takes _all_ applications with it. And if it is "screws up and scribbles on de disks" the losses are even much more serious. Really? More serious than a multithreaded data base failing to synchronize as promised? Get real. You can't do this type of ranking. If the compiler is bad, the entire system is a joke. Users don't care whether the accounting system fails and the telephone stops working because of a compiler error or a kernel crash. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
Cort Dougan [EMAIL PROTECTED] said: Horst von Brand on Wed, Oct 11, 2000 at 11:21:06PM -0400 said: [...] } Oh, come on. The kernel (or glibc for that matter) is not about "inline } asm()" at all! That is a tiny fraction of each. The kernel is different in } that it has lots of hardware-dependent code, which leads to some rather } strange contortions in C in order to be able to _avoid_ asm. The kernel } also moves forward a lot faster than glibc, and grows a lot. A bug in glibc } means an application goes down or screws up, a bug in the kernel can mean } masive data loss in no time at all. I don't think I understand your point. Are you saying that gcc cannot be expected to keep up with the ways in which the kernel uses it? My argument is that providing a compiler that actually regresses (old version compiles kernel, redhat 7.0 included one does not) is not a good choice. What I'm stating is just the fact that the kernel isn't keeping up with the compiler. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
I am attaching the debug output on bootup after defining DEBUG in pci.c and the i386 pci header file with test10-pre2 Note: this is a Dell Lattitude docking station. The devices which are having resource problems are on the docking station. Works fine with 2.2 kernels. Yes, this is on RH7 with kgcc. Please dont distract the subject header if you wanna attack that specifi issue. Just change the header and start a new thread. cheers, jamal -- Forwarded message -- Date: Tue, 10 Oct 2000 19:56:46 -0400 (EDT) From: jamal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Martin Mares [EMAIL PROTECTED], Linus Torvalds [EMAIL PROTECTED] Subject: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd) Ted, Please add this to your list. Linux is unusable in these machines. I have cc'ed Martin and Linus because they play in that PCI area. cheers, jamal -- Forwarded message -- Date: Thu, 5 Oct 2000 17:23:13 -0400 (EDT) From: jamal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: test9 PCI resource collisions I have attached a few details of what appears to be a PCI resource alloc problem (IO ports from the look of it). Note: This is on a dell lattitude machine that never booted before with a docked setup. Enjoy! cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #4 Thu Oct 12 17:30:43 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.482 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1094k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning bus 02 Found 02:08 [102b/051b] 000300 00 Found 02:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 02:05.0 Found 02:38 [9004/6078] 000100 00 Found 02:40 [10b7/9050] 000200 00 Fixups for bus 02 PCI: Scanning for ghost devices on bus 2 Bus scan for 02 returning with max=02 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
} Andrea Arcangeli <[EMAIL PROTECTED]> said: } > On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote: } > > I honestly see nothing wrong with it. There are different parts of } > > the compiler stressed by the kernel build as opposed to most userland } > > compilation, and furthermore the desired compiler stability/feature } > > ratio is different for each task. [..] } } > Many userspace sources are using spinlocks and atomic SMP locking in } > inline asm just like kernel (I think glibc does that for pthreads } > too). Inline asm _must_ be 100% reliable not only for kernel. There's } > nothing foundamentally different between userspace and kernel needs, it } > just happens that "often" userspace is single threaded, doesn't need any } > atomic operation and in turn stresses the compiler much less then the } > kernel on that side. } } Oh, come on. The kernel (or glibc for that matter) is not about "inline } asm()" at all! That is a tiny fraction of each. The kernel is different in } that it has lots of hardware-dependent code, which leads to some rather } strange contortions in C in order to be able to _avoid_ asm. The kernel } also moves forward a lot faster than glibc, and grows a lot. A bug in glibc } means an application goes down or screws up, a bug in the kernel can mean } masive data loss in no time at all. I don't think I understand your point. Are you saying that gcc cannot be expected to keep up with the ways in which the kernel uses it? My argument is that providing a compiler that actually regresses (old version compiles kernel, redhat 7.0 included one does not) is not a good choice. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
Date: Thu, 12 Oct 2000 04:18:23 +0200 From: Andrea Arcangeli <[EMAIL PROTECTED]> I disagree the stability/feature ratio needs are different between kernel and userspace (at least excluding the FPU handling that of course doesn't matter for kernel :). Tell that to people who want a %100 standards compliant c++ compiler. :-) Offering that adds a certain amount of risk. It may be desirable to not take that risk for building the kernel, and the kernel has no c++ needs thus... Often, suitability of a compiler for the kernel is based upon time in widespread use. I have no arguments against your statements that 2.2.x, 2.4.x should be fixed to build with the newer compiler. It should be fixed as soon as possible, without question. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, Oct 11, 2000 at 11:21:06PM -0400, Horst von Brand wrote: > also moves forward a lot faster than glibc, and grows a lot. A bug in glibc > means an application goes down or screws up, a bug in the kernel can mean > masive data loss in no time at all. Foolhardy as it may be, people do _use_ the operating system to run important applications and an "application goes down or screws up" can be quite serious. -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
Andrea Arcangeli <[EMAIL PROTECTED]> said: > On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote: > > I honestly see nothing wrong with it. There are different parts of > > the compiler stressed by the kernel build as opposed to most userland > > compilation, and furthermore the desired compiler stability/feature > > ratio is different for each task. [..] > Many userspace sources are using spinlocks and atomic SMP locking in > inline asm just like kernel (I think glibc does that for pthreads > too). Inline asm _must_ be 100% reliable not only for kernel. There's > nothing foundamentally different between userspace and kernel needs, it > just happens that "often" userspace is single threaded, doesn't need any > atomic operation and in turn stresses the compiler much less then the > kernel on that side. Oh, come on. The kernel (or glibc for that matter) is not about "inline asm()" at all! That is a tiny fraction of each. The kernel is different in that it has lots of hardware-dependent code, which leads to some rather strange contortions in C in order to be able to _avoid_ asm. The kernel also moves forward a lot faster than glibc, and grows a lot. A bug in glibc means an application goes down or screws up, a bug in the kernel can mean masive data loss in no time at all. [...] > Now if the kernel is buggy then let's fix it, this is a start: Alan has stated that he is open to patches that fix overoptimizations and other such bugs in the kernel, sent it to him. So should H. J. Lu do with his patches posted earlier today. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote: > I honestly see nothing wrong with it. There are different parts of > the compiler stressed by the kernel build as opposed to most userland > compilation, and furthermore the desired compiler stability/feature > ratio is different for each task. [..] Many userspace sources are using spinlocks and atomic SMP locking in inline asm just like kernel (I think glibc does that for pthreads too). Inline asm _must_ be 100% reliable not only for kernel. There's nothing foundamentally different between userspace and kernel needs, it just happens that "often" userspace is single threaded, doesn't need any atomic operation and in turn stresses the compiler much less then the kernel on that side. I disagree the stability/feature ratio needs are different between kernel and userspace (at least excluding the FPU handling that of course doesn't matter for kernel :). > [..] So one way to solve these differing > needs is to simply use different compilers. Now if the kernel is buggy then let's fix it, this is a start: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.18pre15aa1/80_smp-locking-1 There may be a timeframe where the kernel needs to cameup with the fixes that a new correct compiler optimization can trigger (as it happened with egcs for example), but once those kernel bugs are fixes there's no point in having two different compilers and having only one will for sure increase the testing and in turn the robusteness of it as well as the correctness of the kernel. I don't think the kernel-compiler-toolkit way of the other unix is the best one. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
}Date: Wed, 11 Oct 2000 19:36:15 -0600 }From: Cort Dougan <[EMAIL PROTECTED]> } }I don't think "it's been done in UNIX before" is a }strong argument for something being done now :) } } True, but I think that "different things have different requirements" } is a strong argument. I merely pointed out that others did it as } well to show that perhaps others see it this way as well :-) } } And BTW, you don't need to play with makefiles or use special make } commpand line options with Alan's latest 2.2.x sources. } } Just spend a few moments trying to be flexible :-) Oh, no. I can't do that. That might introduce me to... "new ways". Is there any reason for changing the compilers with RedHat 7.0? I would RTFM if I had the FM but I'd like it if someone in-the-know would say why the new compiler was necessary for user-land apps. For that matter, why does the latest GCC not work with 2.4? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, 11 Oct 2000, Nathan Paul Simons wrote: > On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote: > > Hardly. In fact the idea of distributing a different compiler for kernels > > comes from debian and the kgcc naming convention from Conectiva. > > What different compiler? If you're talking about the kernel-package > package of Debian, that's only scripts to generate a Debian kernel package > from custom source. >... No, he's talking about the gcc272 package that includes version 2.7.2.3 of gcc: $ apt-cache show gcc272 Package: gcc272 Priority: extra Section: devel Installed-Size: 1596 Maintainer: Debian GCC maintainers <[EMAIL PROTECTED]> Version: 2.7.2.3-16 ... Description: The GNU C compiler. This is the old version of the GNU C compiler's C part. It should only be used for backward compatibility purposes. ... cu, Adrian -- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
Date: Wed, 11 Oct 2000 19:36:15 -0600 From: Cort Dougan <[EMAIL PROTECTED]> I don't think "it's been done in UNIX before" is a strong argument for something being done now :) True, but I think that "different things have different requirements" is a strong argument. I merely pointed out that others did it as well to show that perhaps others see it this way as well :-) And BTW, you don't need to play with makefiles or use special make commpand line options with Alan's latest 2.2.x sources. Just spend a few moments trying to be flexible :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
}Date: Wed, 11 Oct 2000 19:15:24 -0600 }From: Cort Dougan <[EMAIL PROTECTED]> } }It's not a new idea but that doesn't make it a good one. The idea }of distributing the _same_ compiler but different versions is }nutty. } } Actually, this is common practice even in the commercial UNIX world } for kernel development. I have seen several UNIX vendors who use a } specific version of a specific compiler for kernel development. When } you want to build a kernel, you check out the kernel build kit, and } this is the compiler that gets used. } } I honestly see nothing wrong with it. There are different parts of } the compiler stressed by the kernel build as opposed to most userland } compilation, and furthermore the desired compiler stability/feature } ratio is different for each task. So one way to solve these differing } needs is to simply use different compilers. I remember building kernels on SunOS systems and I don't remember it fondly. I don't think "it's been done in UNIX before" is a strong argument for something being done now :) I remember doing builds on redhat systems with 'make' but now what do I need to do? Tinker around with the Makefile, do 'make CC=kgcc' or what's the advised build methodology for the kernel with redhat now? I pray the PowerPC distributions don't follow in this path... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
Date:Wed, 11 Oct 2000 19:15:24 -0600 From: Cort Dougan <[EMAIL PROTECTED]> It's not a new idea but that doesn't make it a good one. The idea of distributing the _same_ compiler but different versions is nutty. Actually, this is common practice even in the commercial UNIX world for kernel development. I have seen several UNIX vendors who use a specific version of a specific compiler for kernel development. When you want to build a kernel, you check out the kernel build kit, and this is the compiler that gets used. I honestly see nothing wrong with it. There are different parts of the compiler stressed by the kernel build as opposed to most userland compilation, and furthermore the desired compiler stability/feature ratio is different for each task. So one way to solve these differing needs is to simply use different compilers. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
> Hardly. In fact the idea of distributing a different compiler for kernels > comes from debian and the kgcc naming convention from Conectiva. It's not a new idea but that doesn't make it a good one. The idea of distributing the _same_ compiler but different versions is nutty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote: > Hardly. In fact the idea of distributing a different compiler for kernels > comes from debian and the kgcc naming convention from Conectiva. What different compiler? If you're talking about the kernel-package package of Debian, that's only scripts to generate a Debian kernel package from custom source. As an aside, with all the griping that people do about gcc, i'm still impressed that it can be used to compile both apps and the kernel. Granted, this is mainly because of hacks in the kernel to make gcc compile it correctly, but it's still a decent C compiler. g++ on the other hand . . . -- Nathan Paul Simons, Junior Software Engineer for FSMLabs http://www.fsmlabs.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, 11 Oct 2000 09:56:46 -0400, Horst von Brand blurted forth: > - RH 7 ships a gcc patched from CVS sources in order to take advantage of >better (on ix86 mainly) optimizations on userland > - RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to >be broken and not compilable with new gcc's > - No, the kernel won't be fixed. The work is huge, and the risk is much too >high > - Yes, 2.4 should compile with new gcc's. But then again, it isn't (and >probably won't be, at least for some time) a supported configuration ah, thank you for setting the record straight. :) -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
> > On Red Hat 7.0, use "kgcc" for kernel compilation. This is > > really an FAQ... Instead of changing distributions, try reading > > manuals. > > What manuals ? The ones on the CD that come with it > The kgcc story looks to me like a lie from RedHat. In my opinion, they > just don't want to recognize that they have been loose. Hardly. In fact the idea of distributing a different compiler for kernels comes from debian and the kgcc naming convention from Conectiva. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, 11 Oct 2000 07:32:30 -0400, Jakub Jelinek blurted forth: > The fact that we recommend using kgcc (especially for 2.2 kernels) does not > mean that the default gcc is broken, but simply that using it for kernels > has not been tested yet too much and there can be e.g. bugs in the way > kernel uses inline assembly and the likes. Again, you miss the entire point, which you brush upon here: Redhat 7.0 is supposed to be a 'stable' release, suddenly thousands of people have been snagging the iso's for it, then there will be people who have problems compiling new kernels for it and they'll have problems for it once in awhile (i've seen quite a few cases reported on irc.. of course, i refer them to this list). Now, while this problem is being worked on and will eventually be solved, it just doesn't seem like a logical thing to me to call a buggy release 'stable'. But then, it's not my decision so I guess I'll just stop right there before someone else decides to flame me. ;) > See above, it does not sum up anything. The only thing is that if somebody > is reporting a bug on lkml, he'd just better first made sure it is > reproduceable with kgcc as well (bug reports for kernels compiled with > gcc 2.95 have been handled this way for a long time on lkml). Considering he's already stated that he's reproduced this on a few machines, I'd say that says it all right there. -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, 11 Oct 2000, Mike A. Harris wrote: > On 10 Oct 2000, Gnea wrote: > > >> Please add this to your list. Linux is unusable in these machines. > >> I have cc'ed Martin and Linus because they play in that PCI area. > > > >erm, looking at your list it says that you're using Redhat 7.0, which > >is known to ship with a buggy gcc, which is KNOWN to do nasty things > >with kernels. > > > >Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc > >version 2.96 2 > >731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 > > > >yeah, that pretty much sums it up right there.. you may want to try > >something else. > > Once again misinformation and FUD. > > On Red Hat 7.0, use "kgcc" for kernel compilation. This is > really an FAQ... Instead of changing distributions, try reading > manuals. What manuals ? The genuine Linux kernel distribution contains its own documentation on how to build and configure it. The kgcc story looks to me like a lie from RedHat. In my opinion, they just don't want to recognize that they have been loose. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
> - RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to > be broken and not compilable with new gcc's > - No, the kernel won't be fixed. The work is huge, and the risk is much too > high Actually I take the same attitude I took with 2.95. If you submit patches which fix cases where stuff got overoptimised or has wrong constraints I'll apply them but I still wont recommend using that gcc to build it Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Gnea <[EMAIL PROTECTED]> said: > On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth: [...] > erm, looking at your list it says that you're using Redhat 7.0, which > is known to ship with a buggy gcc, which is KNOWN to do nasty things > with kernels. OK, let's set a few things straight: - RH 7 ships a gcc patched from CVS sources in order to take advantage of better (on ix86 mainly) optimizations on userland - RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to be broken and not compilable with new gcc's - No, the kernel won't be fixed. The work is huge, and the risk is much too high - Yes, 2.4 should compile with new gcc's. But then again, it isn't (and probably won't be, at least for some time) a supported configuration -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, 11 Oct 2000, Alan Cox wrote: > The only case that 2.95 was at fault is strstr() miscompiles which 2.96 > snapshots actually got right. I couldn't get llabs() to compile correctly either on 2.95.2. There were other small problems when using long long, but I can't remember them right now. -Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Tue, Oct 10, 2000 at 11:32:43PM -0500, Gnea wrote: > > On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth: > > > > > Ted, > > > > Please add this to your list. Linux is unusable in these machines. > > I have cc'ed Martin and Linus because they play in that PCI area. > > erm, looking at your list it says that you're using Redhat 7.0, which > is known to ship with a buggy gcc, which is KNOWN to do nasty things > with kernels. Can you tell me (when it is KNOWN) what nasty things does that gcc do to kernels? The thing that it does not compile vanilla 2.2.x kernels is not its fault, and if you choose to either use K preprocessing in assembly (but then no GNU extensions) or ANSI preprocessing plus you export memset/memcpy, it will actually build and work, see H.J.'s patchlets: http://www.lucon.org/linux/linux-2.2.14-gcc.patch http://www.lucon.org/linux/linux-2.2.17-library.patch The fact that we recommend using kgcc (especially for 2.2 kernels) does not mean that the default gcc is broken, but simply that using it for kernels has not been tested yet too much and there can be e.g. bugs in the way kernel uses inline assembly and the likes. > > Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc > version 2.96 2 > 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 > > yeah, that pretty much sums it up right there.. you may want to try > something else. See above, it does not sum up anything. The only thing is that if somebody is reporting a bug on lkml, he'd just better first made sure it is reproduceable with kgcc as well (bug reports for kernels compiled with gcc 2.95 have been handled this way for a long time on lkml). Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
> erm, looking at your list it says that you're using Redhat 7.0, which > is known to ship with a buggy gcc, which is KNOWN to do nasty things > with kernels. Its not a buggy gcc. Well its a less buggy gcc than 2.95 or egcs 1.1.2 The problem is the *kernel* side of things. The compiler folks keep getting the blame for things that are not their fault. Every bug I've chased down bar one and every fix I've merged from others for gcc 2.95 support in 2.2.x for example has been the kernel code not stopping some legal but undesired optimisation or incorrect asm constraints The only case that 2.95 was at fault is strstr() miscompiles which 2.96 snapshots actually got right. > Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc > version 2.96 2 > 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 > > yeah, that pretty much sums it up right there.. you may want to try > something else. Build with kgcc. See the 7.0 release notes and/or tweak the Makefile. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. Its not a buggy gcc. Well its a less buggy gcc than 2.95 or egcs 1.1.2 The problem is the *kernel* side of things. The compiler folks keep getting the blame for things that are not their fault. Every bug I've chased down bar one and every fix I've merged from others for gcc 2.95 support in 2.2.x for example has been the kernel code not stopping some legal but undesired optimisation or incorrect asm constraints The only case that 2.95 was at fault is strstr() miscompiles which 2.96 snapshots actually got right. Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc version 2.96 2 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 yeah, that pretty much sums it up right there.. you may want to try something else. Build with kgcc. See the 7.0 release notes and/or tweak the Makefile. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Tue, Oct 10, 2000 at 11:32:43PM -0500, Gnea wrote: On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth: Ted, Please add this to your list. Linux is unusable in these machines. I have cc'ed Martin and Linus because they play in that PCI area. erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. Can you tell me (when it is KNOWN) what nasty things does that gcc do to kernels? The thing that it does not compile vanilla 2.2.x kernels is not its fault, and if you choose to either use KR preprocessing in assembly (but then no GNU extensions) or ANSI preprocessing plus you export memset/memcpy, it will actually build and work, see H.J.'s patchlets: http://www.lucon.org/linux/linux-2.2.14-gcc.patch http://www.lucon.org/linux/linux-2.2.17-library.patch The fact that we recommend using kgcc (especially for 2.2 kernels) does not mean that the default gcc is broken, but simply that using it for kernels has not been tested yet too much and there can be e.g. bugs in the way kernel uses inline assembly and the likes. Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc version 2.96 2 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 yeah, that pretty much sums it up right there.. you may want to try something else. See above, it does not sum up anything. The only thing is that if somebody is reporting a bug on lkml, he'd just better first made sure it is reproduceable with kgcc as well (bug reports for kernels compiled with gcc 2.95 have been handled this way for a long time on lkml). Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, 11 Oct 2000, Alan Cox wrote: The only case that 2.95 was at fault is strstr() miscompiles which 2.96 snapshots actually got right. I couldn't get llabs() to compile correctly either on 2.95.2. There were other small problems when using long long, but I can't remember them right now. -Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Gnea [EMAIL PROTECTED] said: On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth: [...] erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. OK, let's set a few things straight: - RH 7 ships a gcc patched from CVS sources in order to take advantage of better (on ix86 mainly) optimizations on userland - RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to be broken and not compilable with new gcc's - No, the kernel won't be fixed. The work is huge, and the risk is much too high - Yes, 2.4 should compile with new gcc's. But then again, it isn't (and probably won't be, at least for some time) a supported configuration -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
- RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to be broken and not compilable with new gcc's - No, the kernel won't be fixed. The work is huge, and the risk is much too high Actually I take the same attitude I took with 2.95. If you submit patches which fix cases where stuff got overoptimised or has wrong constraints I'll apply them but I still wont recommend using that gcc to build it Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, 11 Oct 2000, Mike A. Harris wrote: On 10 Oct 2000, Gnea wrote: Please add this to your list. Linux is unusable in these machines. I have cc'ed Martin and Linus because they play in that PCI area. erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc version 2.96 2 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 yeah, that pretty much sums it up right there.. you may want to try something else. Once again misinformation and FUD. On Red Hat 7.0, use "kgcc" for kernel compilation. This is really an FAQ... Instead of changing distributions, try reading manuals. What manuals ? The genuine Linux kernel distribution contains its own documentation on how to build and configure it. The kgcc story looks to me like a lie from RedHat. In my opinion, they just don't want to recognize that they have been loose. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, 11 Oct 2000 07:32:30 -0400, Jakub Jelinek blurted forth: The fact that we recommend using kgcc (especially for 2.2 kernels) does not mean that the default gcc is broken, but simply that using it for kernels has not been tested yet too much and there can be e.g. bugs in the way kernel uses inline assembly and the likes. Again, you miss the entire point, which you brush upon here: Redhat 7.0 is supposed to be a 'stable' release, suddenly thousands of people have been snagging the iso's for it, then there will be people who have problems compiling new kernels for it and they'll have problems for it once in awhile (i've seen quite a few cases reported on irc.. of course, i refer them to this list). Now, while this problem is being worked on and will eventually be solved, it just doesn't seem like a logical thing to me to call a buggy release 'stable'. But then, it's not my decision so I guess I'll just stop right there before someone else decides to flame me. ;) See above, it does not sum up anything. The only thing is that if somebody is reporting a bug on lkml, he'd just better first made sure it is reproduceable with kgcc as well (bug reports for kernels compiled with gcc 2.95 have been handled this way for a long time on lkml). Considering he's already stated that he's reproduced this on a few machines, I'd say that says it all right there. -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Red Hat 7.0, use "kgcc" for kernel compilation. This is really an FAQ... Instead of changing distributions, try reading manuals. What manuals ? The ones on the CD that come with it The kgcc story looks to me like a lie from RedHat. In my opinion, they just don't want to recognize that they have been loose. Hardly. In fact the idea of distributing a different compiler for kernels comes from debian and the kgcc naming convention from Conectiva. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, 11 Oct 2000 09:56:46 -0400, Horst von Brand blurted forth: - RH 7 ships a gcc patched from CVS sources in order to take advantage of better (on ix86 mainly) optimizations on userland - RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to be broken and not compilable with new gcc's - No, the kernel won't be fixed. The work is huge, and the risk is much too high - Yes, 2.4 should compile with new gcc's. But then again, it isn't (and probably won't be, at least for some time) a supported configuration ah, thank you for setting the record straight. :) -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote: Hardly. In fact the idea of distributing a different compiler for kernels comes from debian and the kgcc naming convention from Conectiva. What different compiler? If you're talking about the kernel-package package of Debian, that's only scripts to generate a Debian kernel package from custom source. As an aside, with all the griping that people do about gcc, i'm still impressed that it can be used to compile both apps and the kernel. Granted, this is mainly because of hacks in the kernel to make gcc compile it correctly, but it's still a decent C compiler. g++ on the other hand . . . -- Nathan Paul Simons, Junior Software Engineer for FSMLabs http://www.fsmlabs.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
Hardly. In fact the idea of distributing a different compiler for kernels comes from debian and the kgcc naming convention from Conectiva. It's not a new idea but that doesn't make it a good one. The idea of distributing the _same_ compiler but different versions is nutty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
Date:Wed, 11 Oct 2000 19:15:24 -0600 From: Cort Dougan [EMAIL PROTECTED] It's not a new idea but that doesn't make it a good one. The idea of distributing the _same_ compiler but different versions is nutty. Actually, this is common practice even in the commercial UNIX world for kernel development. I have seen several UNIX vendors who use a specific version of a specific compiler for kernel development. When you want to build a kernel, you check out the kernel build kit, and this is the compiler that gets used. I honestly see nothing wrong with it. There are different parts of the compiler stressed by the kernel build as opposed to most userland compilation, and furthermore the desired compiler stability/feature ratio is different for each task. So one way to solve these differing needs is to simply use different compilers. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
}Date: Wed, 11 Oct 2000 19:15:24 -0600 }From: Cort Dougan [EMAIL PROTECTED] } }It's not a new idea but that doesn't make it a good one. The idea }of distributing the _same_ compiler but different versions is }nutty. } } Actually, this is common practice even in the commercial UNIX world } for kernel development. I have seen several UNIX vendors who use a } specific version of a specific compiler for kernel development. When } you want to build a kernel, you check out the kernel build kit, and } this is the compiler that gets used. } } I honestly see nothing wrong with it. There are different parts of } the compiler stressed by the kernel build as opposed to most userland } compilation, and furthermore the desired compiler stability/feature } ratio is different for each task. So one way to solve these differing } needs is to simply use different compilers. I remember building kernels on SunOS systems and I don't remember it fondly. I don't think "it's been done in UNIX before" is a strong argument for something being done now :) I remember doing builds on redhat systems with 'make' but now what do I need to do? Tinker around with the Makefile, do 'make CC=kgcc' or what's the advised build methodology for the kernel with redhat now? I pray the PowerPC distributions don't follow in this path... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
Date: Wed, 11 Oct 2000 19:36:15 -0600 From: Cort Dougan [EMAIL PROTECTED] I don't think "it's been done in UNIX before" is a strong argument for something being done now :) True, but I think that "different things have different requirements" is a strong argument. I merely pointed out that others did it as well to show that perhaps others see it this way as well :-) And BTW, you don't need to play with makefiles or use special make commpand line options with Alan's latest 2.2.x sources. Just spend a few moments trying to be flexible :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, 11 Oct 2000, Nathan Paul Simons wrote: On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote: Hardly. In fact the idea of distributing a different compiler for kernels comes from debian and the kgcc naming convention from Conectiva. What different compiler? If you're talking about the kernel-package package of Debian, that's only scripts to generate a Debian kernel package from custom source. ... No, he's talking about the gcc272 package that includes version 2.7.2.3 of gcc: $ apt-cache show gcc272 Package: gcc272 Priority: extra Section: devel Installed-Size: 1596 Maintainer: Debian GCC maintainers [EMAIL PROTECTED] Version: 2.7.2.3-16 ... Description: The GNU C compiler. This is the old version of the GNU C compiler's C part. It should only be used for backward compatibility purposes. ... cu, Adrian -- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
}Date: Wed, 11 Oct 2000 19:36:15 -0600 }From: Cort Dougan [EMAIL PROTECTED] } }I don't think "it's been done in UNIX before" is a }strong argument for something being done now :) } } True, but I think that "different things have different requirements" } is a strong argument. I merely pointed out that others did it as } well to show that perhaps others see it this way as well :-) } } And BTW, you don't need to play with makefiles or use special make } commpand line options with Alan's latest 2.2.x sources. } } Just spend a few moments trying to be flexible :-) Oh, no. I can't do that. That might introduce me to... "new ways". Is there any reason for changing the compilers with RedHat 7.0? I would RTFM if I had the FM but I'd like it if someone in-the-know would say why the new compiler was necessary for user-land apps. For that matter, why does the latest GCC not work with 2.4? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote: I honestly see nothing wrong with it. There are different parts of the compiler stressed by the kernel build as opposed to most userland compilation, and furthermore the desired compiler stability/feature ratio is different for each task. [..] Many userspace sources are using spinlocks and atomic SMP locking in inline asm just like kernel (I think glibc does that for pthreads too). Inline asm _must_ be 100% reliable not only for kernel. There's nothing foundamentally different between userspace and kernel needs, it just happens that "often" userspace is single threaded, doesn't need any atomic operation and in turn stresses the compiler much less then the kernel on that side. I disagree the stability/feature ratio needs are different between kernel and userspace (at least excluding the FPU handling that of course doesn't matter for kernel :). [..] So one way to solve these differing needs is to simply use different compilers. Now if the kernel is buggy then let's fix it, this is a start: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.18pre15aa1/80_smp-locking-1 There may be a timeframe where the kernel needs to cameup with the fixes that a new correct compiler optimization can trigger (as it happened with egcs for example), but once those kernel bugs are fixes there's no point in having two different compilers and having only one will for sure increase the testing and in turn the robusteness of it as well as the correctness of the kernel. I don't think the kernel-compiler-toolkit way of the other unix is the best one. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
Andrea Arcangeli [EMAIL PROTECTED] said: On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote: I honestly see nothing wrong with it. There are different parts of the compiler stressed by the kernel build as opposed to most userland compilation, and furthermore the desired compiler stability/feature ratio is different for each task. [..] Many userspace sources are using spinlocks and atomic SMP locking in inline asm just like kernel (I think glibc does that for pthreads too). Inline asm _must_ be 100% reliable not only for kernel. There's nothing foundamentally different between userspace and kernel needs, it just happens that "often" userspace is single threaded, doesn't need any atomic operation and in turn stresses the compiler much less then the kernel on that side. Oh, come on. The kernel (or glibc for that matter) is not about "inline asm()" at all! That is a tiny fraction of each. The kernel is different in that it has lots of hardware-dependent code, which leads to some rather strange contortions in C in order to be able to _avoid_ asm. The kernel also moves forward a lot faster than glibc, and grows a lot. A bug in glibc means an application goes down or screws up, a bug in the kernel can mean masive data loss in no time at all. [...] Now if the kernel is buggy then let's fix it, this is a start: Alan has stated that he is open to patches that fix overoptimizations and other such bugs in the kernel, sent it to him. So should H. J. Lu do with his patches posted earlier today. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, Oct 11, 2000 at 11:21:06PM -0400, Horst von Brand wrote: also moves forward a lot faster than glibc, and grows a lot. A bug in glibc means an application goes down or screws up, a bug in the kernel can mean masive data loss in no time at all. Foolhardy as it may be, people do _use_ the operating system to run important applications and an "application goes down or screws up" can be quite serious. -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
Date: Thu, 12 Oct 2000 04:18:23 +0200 From: Andrea Arcangeli [EMAIL PROTECTED] I disagree the stability/feature ratio needs are different between kernel and userspace (at least excluding the FPU handling that of course doesn't matter for kernel :). Tell that to people who want a %100 standards compliant c++ compiler. :-) Offering that adds a certain amount of risk. It may be desirable to not take that risk for building the kernel, and the kernel has no c++ needs thus... Often, suitability of a compiler for the kernel is based upon time in widespread use. I have no arguments against your statements that 2.2.x, 2.4.x should be fixed to build with the newer compiler. It should be fixed as soon as possible, without question. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI
} Andrea Arcangeli [EMAIL PROTECTED] said: } On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote: } I honestly see nothing wrong with it. There are different parts of } the compiler stressed by the kernel build as opposed to most userland } compilation, and furthermore the desired compiler stability/feature } ratio is different for each task. [..] } } Many userspace sources are using spinlocks and atomic SMP locking in } inline asm just like kernel (I think glibc does that for pthreads } too). Inline asm _must_ be 100% reliable not only for kernel. There's } nothing foundamentally different between userspace and kernel needs, it } just happens that "often" userspace is single threaded, doesn't need any } atomic operation and in turn stresses the compiler much less then the } kernel on that side. } } Oh, come on. The kernel (or glibc for that matter) is not about "inline } asm()" at all! That is a tiny fraction of each. The kernel is different in } that it has lots of hardware-dependent code, which leads to some rather } strange contortions in C in order to be able to _avoid_ asm. The kernel } also moves forward a lot faster than glibc, and grows a lot. A bug in glibc } means an application goes down or screws up, a bug in the kernel can mean } masive data loss in no time at all. I don't think I understand your point. Are you saying that gcc cannot be expected to keep up with the ways in which the kernel uses it? My argument is that providing a compiler that actually regresses (old version compiles kernel, redhat 7.0 included one does not) is not a good choice. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On 10 Oct 2000, Gnea wrote: >> Please add this to your list. Linux is unusable in these machines. >> I have cc'ed Martin and Linus because they play in that PCI area. > >erm, looking at your list it says that you're using Redhat 7.0, which >is known to ship with a buggy gcc, which is KNOWN to do nasty things >with kernels. > >Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc >version 2.96 2 >731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 > >yeah, that pretty much sums it up right there.. you may want to try >something else. Once again misinformation and FUD. On Red Hat 7.0, use "kgcc" for kernel compilation. This is really an FAQ... Instead of changing distributions, try reading manuals. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Microsoft Windows(tm). A thirty-two bit extension and graphical shell to a sixteen bit patch to an eight bit operating system originally coded for a four bit microprocessor which was written by a two-bit company that can't stand one bit of competition. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth: > > Ted, > > Please add this to your list. Linux is unusable in these machines. > I have cc'ed Martin and Linus because they play in that PCI area. erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc version 2.96 2 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 yeah, that pretty much sums it up right there.. you may want to try something else. -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Ted, Please add this to your list. Linux is unusable in these machines. I have cc'ed Martin and Linus because they play in that PCI area. cheers, jamal -- Forwarded message -- Date: Thu, 5 Oct 2000 17:23:13 -0400 (EDT) From: jamal <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: test9 PCI resource collisions I have attached a few details of what appears to be a PCI resource alloc problem (IO ports from the look of it). Note: This is on a dell lattitude machine that never booted before with a docked setup. Enjoy! cheers, jamal pci.list.gz
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth: Ted, Please add this to your list. Linux is unusable in these machines. I have cc'ed Martin and Linus because they play in that PCI area. erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc version 2.96 2 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 yeah, that pretty much sums it up right there.. you may want to try something else. -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On 10 Oct 2000, Gnea wrote: Please add this to your list. Linux is unusable in these machines. I have cc'ed Martin and Linus because they play in that PCI area. erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc version 2.96 2 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 yeah, that pretty much sums it up right there.. you may want to try something else. Once again misinformation and FUD. On Red Hat 7.0, use "kgcc" for kernel compilation. This is really an FAQ... Instead of changing distributions, try reading manuals. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Microsoft Windows(tm). A thirty-two bit extension and graphical shell to a sixteen bit patch to an eight bit operating system originally coded for a four bit microprocessor which was written by a two-bit company that can't stand one bit of competition. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
