[BUG?] AMD K5 and 2.4 (was Re: Updated 2.4 TODO List)
(I'm replying to a message from about a month ago, but it's relevant to a problem I'm having now.) [EMAIL PROTECTED] wrote: >Date: Mon, 09 Oct 2000 20:13:35 +0200 >From: Thomas Sailer <[EMAIL PROTECTED]> > [snip] >My Asus P55TP4 (i430FX)/AMD K5 PC also crashes after "Booting the >kernel..." >and before printing anything else > > Are you sure it was compiled with the correct CPU? If you configure the > CPU incorrectly (686 when you only have a 586, etc.) the kernel *will* > refuse to boot. I have a Compaq Presario 425 here, with a K5 upgrade (by Evergreen Technologies) in it. It reboots immediately after "Booting the kernel..." with Linux 2.4.0test10 (I haven't tried test11preX on this machine) if the kernel is compiled for 586/K5/etc. If I compile for 486, then it boots. If I compile for 586/K5/etc. with 2.2.17, it boots. (This is all with egcs 1.1.2.) Is this a real bug or just a documentation bug? -Barry K. Nathan <[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/
[BUG?] AMD K5 and 2.4 (was Re: Updated 2.4 TODO List)
(I'm replying to a message from about a month ago, but it's relevant to a problem I'm having now.) [EMAIL PROTECTED] wrote: Date: Mon, 09 Oct 2000 20:13:35 +0200 From: Thomas Sailer [EMAIL PROTECTED] [snip] My Asus P55TP4 (i430FX)/AMD K5 PC also crashes after "Booting the kernel..." and before printing anything else Are you sure it was compiled with the correct CPU? If you configure the CPU incorrectly (686 when you only have a 586, etc.) the kernel *will* refuse to boot. I have a Compaq Presario 425 here, with a K5 upgrade (by Evergreen Technologies) in it. It reboots immediately after "Booting the kernel..." with Linux 2.4.0test10 (I haven't tried test11preX on this machine) if the kernel is compiled for 586/K5/etc. If I compile for 486, then it boots. If I compile for 586/K5/etc. with 2.2.17, it boots. (This is all with egcs 1.1.2.) Is this a real bug or just a documentation bug? -Barry K. Nathan [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 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 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
Hi! > While you should report drivers or other kernel functions > that don't work, I don't think that just saying that > something is broken is sufficient. Well, that driver really is broken. It uses tq_scheduler in strange way, so it has unbound ping times. (Up to 20 seconds). It breaks under heavy load. Pavel > > Hi! > > > > > 7. Obvious Projects For People (well if you have the hardware..) > > > > > > * Make syncppp use new ppp code > > > * Fix SPX socket code > > > > USB: plusb is b0rken. > > Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [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
Pavel, While you should report drivers or other kernel functions that don't work, I don't think that just saying that something is broken is sufficient. ~Randy > Hi! > > > 7. Obvious Projects For People (well if you have the hardware..) > > > > * Make syncppp use new ppp code > > * Fix SPX socket code > > USB: plusb is b0rken. > Pavel - 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
Pavel, While you should report drivers or other kernel functions that don't work, I don't think that just saying that something is broken is sufficient. ~Randy Hi! 7. Obvious Projects For People (well if you have the hardware..) * Make syncppp use new ppp code * Fix SPX socket code USB: plusb is b0rken. Pavel - 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
Hi! While you should report drivers or other kernel functions that don't work, I don't think that just saying that something is broken is sufficient. Well, that driver really is broken. It uses tq_scheduler in strange way, so it has unbound ping times. (Up to 20 seconds). It breaks under heavy load. Pavel Hi! 7. Obvious Projects For People (well if you have the hardware..) * Make syncppp use new ppp code * Fix SPX socket code USB: plusb is b0rken. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [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)
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
Hi! > 7. Obvious Projects For People (well if you have the hardware..) > > * Make syncppp use new ppp code > * Fix SPX socket code USB: plusb is b0rken. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [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
Hi! 7. Obvious Projects For People (well if you have the hardware..) * Make syncppp use new ppp code * Fix SPX socket code USB: plusb is b0rken. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [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 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 - more on PCI resources...]
> > I agree. I would expect it to be 8 instead of 32. > > Actually I just checked on a new Thinkpad T20 with a TI > > PCI 1450 CardBus controller *on a different OS* > > and it is 8. > > I'll fix it to be 8. > > Thanks, > > Linus Well, preferably to what David said: L1_CACHE_BYTES / 4 Thanks, ~Randy - 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 - more on PCI resources...]
On Fri, 13 Oct 2000, Dunlap, Randy wrote: > > I agree. I would expect it to be 8 instead of 32. > Actually I just checked on a new Thinkpad T20 with a TI > PCI 1450 CardBus controller *on a different OS* > and it is 8. I'll fix it to be 8. Thanks, 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 - more on PCI resources...]
> On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote: > > I'm not familiar with yenta controllers/devices, > > and I'm not trying to throw you a tasty red herring, > > but... > > > > yenta_config_init() does > > config_writeb(socket, PCI_CACHE_LINE_SIZE, 32); > > > > Is this writing to the CardBus bridge or to the device's > > CacheLineSize register? > > It is writing to the bridge. I think it should probably actually be > L1_CACHE_BYTES/4. I am not sure about the impact of an incorrect > setting. Maybe Linus knows. > > -- Dave I agree. I would expect it to be 8 instead of 32. Actually I just checked on a new Thinkpad T20 with a TI PCI 1450 CardBus controller *on a different OS* and it is 8. ~Randy - 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 - more on PCI resources...]
I have tested Linus' patch and it makes a difference: cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 Found 06:00 [115d/0003] 000200 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 0 1200 1c00-1fff PCI: Error while updating region 06:00.0/6 (1c01 != 1801) PCI: Enabling device 06:00.0 ( -> 0003) Found 06:01 [115d/0103] 000300 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 0 1200 1c00-1fff PCI: Error while updating region 06:00.1/6 (1c004001 != 18004001) PCI: Enabling device 06:00.1 ( -> 0003) VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 192k freed Warning: unable to open an initial console. cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 0x370-0x37f 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. eth0: first available media type: MII tulip_attach(06:00.0) PCI: Enabling bus mastering for device 06:00.0 PCI: Setting latency timer of device 06:00.0 to 64 xircom_tulip_cb.c:v0.91 4/14/99 [EMAIL PROTECTED] (modified by [EMAIL PROTECTED] for XIRCOM CBE, fixed by Doug Ledford) eth1: Xircom Cardbus Adapter (DEC 21143 compatible mode) rev 3 at 0x1800, 00:00:00:00:00:00, IRQ 11. lspci: 06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) Subsystem: Xircom Cardbus Ethernet 10/100 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at 1800 [size=128] Memory at 2000 (32-bit, non-prefetchable) [size=2K] Memory at 2800 (32-bit, non-prefetchable) [size=2K] Expansion ROM at 1c00 [size=16K] Capabilities: [dc] Power Management version 1 06:00.1 VGA compatible controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) (prog-if 02) Subsystem: Xircom CBEM56G-100 Ethernet + 56k Modem Flags: medium devsel, IRQ 11 I/O ports at 1880 [size=8] Memory at 20001000 (32-bit, non-prefetchable) [size=2K] Memory at 20001800 (32-bit, non-prefetchable) [size=2K] Expansion ROM at 1c004000 [size=16K] Capabilities: [dc] Power Management version 1 It still doesn't work. It looks very much like a stuck bit, but at least we get a slightly "better" error message and the expansion ROM now gets enabled. progress! Linus wants to "debug this to death" (his words, not mine) but I don't have access to the suspect hardware for the next five weeks, and it will probably be serviced some time during those weeks. Thank you for being patient, Linus. And sorry for not being able to provide more debug data. Dag B - 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 - more on PCI resources...]
On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote: > I'm not familiar with yenta controllers/devices, > and I'm not trying to throw you a tasty red herring, > but... > > yenta_config_init() does > config_writeb(socket, PCI_CACHE_LINE_SIZE, 32); > > Is this writing to the CardBus bridge or to the device's > CacheLineSize register? It is writing to the bridge. I think it should probably actually be L1_CACHE_BYTES/4. I am not sure about the impact of an incorrect setting. Maybe Linus knows. -- Dave - 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 - more on PCI resources...]
I'm not familiar with yenta controllers/devices, and I'm not trying to throw you a tasty red herring, but... yenta_config_init() does config_writeb(socket, PCI_CACHE_LINE_SIZE, 32); Is this writing to the CardBus bridge or to the device's CacheLineSize register? If the latter, and given that PCI_CACHE_LINE_SIZE is in units of 4-byte "words", is 32 [= 128 bytes] a good value to use? If so, why? Or is it OK because it is setting a PCI bridge device's cache line size? >From TI's PCI1451 GJG CardBus controller spec: 4.8 Cache Line Size Register The cache line size register is programmed by host software to indicate the system cache line size. Thanks, ~Randy - 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 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 - more on PCI resources...]
On Fri, 13 Oct 2000, Dag Bakke wrote:
>
> This patch enables the expansion ROM, but it still doesn't make the card
> work.
Ok. It seems that your stuck bit is really stuck, and I was wrong: it's
not the cardbus bridge that does something strange, it actually looks like
your hardware has a data line that is stuck at 0.
> non-working case:
> -
> cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003
> Found 06:00 [115d/0003] 000200 00
> bus res 0 1200 1c00-1fff
> bus res 1 200 2000-23ff
> bus res 2 100 1800-18ff
> bus res 0 1200 1c00-1fff
> bus res 1 200 2000-23ff
> bus res 0 1200 1c00-1fff
> bus res 1 200 2000-23ff
> bus res 0 1200 1c00-1fff
> PCI: Error while updating region 06:00.0/6 (1c01 != 1801)
Notice how it's bit 0x0400 again. The 0x1801 value is the one we
read back afterr having written the region address: we wrote 0x1c01,
and bit 0x0400 simply doesn't stick - the above is a debug message
telling us that we read back something different. See the code in
arch/i386/kernel/pci-i386.c: pcibios_update_resource() if you're
interested in seeing exactly what the logic is.
So I'm afraid that it's really starting to look like that particular
hardware really has either a broken line somewhere on the motherboard (or
a docking connector with a broken pin or similar), or there is some other
hardware limitation (maybe the bridge is limited to 64MB and just isn't a
valid PCI-PCI bridge).
The fact that you apparently have an identical machine that does work
makes me suspect it's not a chip limitation, but truly a broken connector
or line.
In which case there would be no way to make it work - whenever we'd write
data to the card, it would lose one bit.
If I remember correctly, you said that this card worked under Windows. Was
that on the _same_ machine? That would be an important data-point: if it
works under Windows, that means that I'm wrong, and that it's some quirk
that windows knows how to work around.
I have one final test you could do: considering that the lost bit seems to
be the same bit that we use as the size of the MEM resource bridge window,
and assuming that it is not a physically broken connector or something,
but really is some strange quirk of the bridge itself and interactions
with the memory window, you could try to change the alignment of the
window allocation such that it's always given a window where the upper bit
won't matter.
The way to do that would be in the same place where you changed the size
in drivers/pcmcia/yenta.c: make the alignment be double what the size is,
so do something like
size = 128*1024*1024;
align = size << 1;
in yenta_allocate_res() for the MEM case (leave the IO case at 256 and
1024).
(The reason I'm saying 128*1024*1024 is to see if the "stuck bit" moves).
Oh, and also, to see the stuck bit more clearly, please add a line like
printk("base=%08x, size=%08x\n", base, size);
to drivers/pci/pci.c: pci_size() just before the return.
Ok? I'm getting the feeling that your hardware simply is broken, but I
want to debug this to death. Thanks for being patient,
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 - more on PCI resources...]
On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote: I'm not familiar with yenta controllers/devices, and I'm not trying to throw you a tasty red herring, but... yenta_config_init() does config_writeb(socket, PCI_CACHE_LINE_SIZE, 32); Is this writing to the CardBus bridge or to the device's CacheLineSize register? It is writing to the bridge. I think it should probably actually be L1_CACHE_BYTES/4. I am not sure about the impact of an incorrect setting. Maybe Linus knows. -- Dave I agree. I would expect it to be 8 instead of 32. Actually I just checked on a new Thinkpad T20 with a TI PCI 1450 CardBus controller *on a different OS* and it is 8. ~Randy - 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 - more on PCI resources...]
On Fri, 13 Oct 2000, Dunlap, Randy wrote: I agree. I would expect it to be 8 instead of 32. Actually I just checked on a new Thinkpad T20 with a TI PCI 1450 CardBus controller *on a different OS* and it is 8. I'll fix it to be 8. Thanks, 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 - more on PCI resources...]
I agree. I would expect it to be 8 instead of 32. Actually I just checked on a new Thinkpad T20 with a TI PCI 1450 CardBus controller *on a different OS* and it is 8. I'll fix it to be 8. Thanks, Linus Well, preferably to what David said: L1_CACHE_BYTES / 4 Thanks, ~Randy - 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
On Thu, 12 Oct 2000 11:02:50 -0400, "Chris Swiedler" <[EMAIL PROTECTED]> wrote: >But the kernel should be able to write directly to the screen, even if it's >extremely minimal information. Something like how LILO does it: test the >common hang-on-boot conditions (like wrong CPU type) and print a single >character after each test. You miss the point. The generated C code for any part of the kernel can contains instructions that break on older boxes. Compiling bits of the kernel in 386 and bits in 686 mode is not a long term solution, you will be forever tracking down which bits can be compiled with which options. printk() itself is not reliable under these circumstances so you would have to use a special I/O routine to log these problems. Also the code that detects the problem must never use the new instructions itself. That means the detect and warn code must be separate from the main kernel, either as part of the boot loader or as part of the 16 bit setup code. Any such code must not use printk() for IO. BTW, your ISP is sending mail from a server with no reverse DNS. That puts it in the same category as 99% of the spam sources on the net, please ask them to fix their DNS. Received: from [216.162.44.3] ([216.162.44.3]:13574 "EHLO challenge.atlanticweb.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 - more on PCI resources...]
On Thu, 12 Oct 2000, Dag Bakke wrote:
>
> Linus,
> I realized there was one more test to do before deeming the hardware sane.
>
> PCMCIA (16-bit) in my laptop is tested and works fine with three different
> types of cards.
> Another Xircom card behaved just the same (non-functional) in my latop.
> My Xircom card was tested in another laptop and found working.
>
> Today I took my card *and* disk and tested it in an identical laptop.
> It works.
>
> So it appears that the *cardbus* logic is broken on my machine. Plain, old
> hardware defect. And I have been wasting your time. Sorry about that.
No problem. This was good to have it out of the way. And I don't think you
actually wasted my time: this may still be a Linux bug. See more below.
> In any case, debug output follows for both the non-working and the working
> case. Feel free to pin-point the hw-bug or flat out ignore it.
Yup, bug pin-pointed, and clear: these are the resources for the failing
case:
> device PCI device 115d:0003 resource 1 size 04000800
> device PCI device 115d:0003 resource 2 size 04000800
> device PCI device 115d:0003 resource 6 size 04004000
> device PCI device 115d:0003 resource 6 size 04004000
> device PCI device 115d:0103 resource 1 size 04000800
> device PCI device 115d:0103 resource 2 size 04000800
> device PCI device 115d:0103 resource 6 size 04004000
> device PCI device 115d:0103 resource 6 size 04004000
While I'll bet you $20 that the working case (which doesn't print out the
same printk because it doesn't fail) has the exact same resources, except
the "size" field doesn't have that pesky high bit set, so the sizes are
all 0x0800 of 0x4000 instead of being 64MB+.
Now, that said, I do think that this is a linux bug. Sure, your hardware
is strange too, and hardware obviously _does_ make a difference, but there
is no way a non-power-of-two size field can ever be valid, and Linux is
buggy for allowing the hardware to confuse it this way.
What seems to be happening is that somehow your cardbus bridge (or docking
station bridge) is set up so that it doesn't let through that high bit
that defines the size of the PCI bridge map, and the way Linux calculates
the size is basically the simplistic
write all 1's to the base register
read the base register
sz = ~(base & mask) & maxmask;
and while that works most of the time in normal situations, it's really
not correct. What we _should_ do is more akin to this patch. Can you test
this on your broken system, and see if the system magically comes to life?
NOTE! I do worry about the masking off of a bit in the bridge. There may
be a real hardware bug there - but the fact that the mask seems to move
depending on how big a bridge window there is (judging by your past mails
about how behaviour did actually change when changing the cardbus window
size) implies to me that it's not something as simple as a stuck bit.
If it is a stuck bit somehow, then you're screwed, and the patch below
won't help you at all. But if it's the bridge snooping (and modifying) the
decode window sizes, then the patch below should make a difference.
Thanks,
Linus
--- v2.4.0-test9/linux/drivers/pci/pci.cSun Oct 8 10:50:20 2000
+++ linux/drivers/pci/pci.c Thu Oct 12 09:52:07 2000
@@ -474,6 +474,16 @@
return IORESOURCE_MEM;
}
+/*
+ * Find the extent of a PCI decode..
+ */
+static u32 pci_size(u32 base, u32 mask)
+{
+ u32 size = mask & base; /* Find the significant bits */
+ size = size & ~(size-1);/* Get the lowest of them to find the decode
+size */
+ return size-1; /* extent = size - 1 */
+}
+
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int rom)
{
unsigned int pos, reg, next;
@@ -501,10 +511,10 @@
l = 0;
if ((l & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY) {
res->start = l & PCI_BASE_ADDRESS_MEM_MASK;
- sz = ~(sz & PCI_BASE_ADDRESS_MEM_MASK);
+ sz = pci_size(sz, PCI_BASE_ADDRESS_MEM_MASK);
} else {
res->start = l & PCI_BASE_ADDRESS_IO_MASK;
- sz = ~(sz & PCI_BASE_ADDRESS_IO_MASK) & 0x;
+ sz = pci_size(sz, PCI_BASE_ADDRESS_IO_MASK & 0x);
}
res->end = res->start + (unsigned long) sz;
res->flags |= (l & 0xf) | pci_calc_resource_flags(l);
@@ -543,7 +553,7 @@
res->flags = (l & PCI_ROM_ADDRESS_ENABLE) |
IORESOURCE_MEM | IORESOURCE_PREFETCH | IORESOURCE_READONLY |
IORESOURCE_CACHEABLE;
res->start = l & PCI_ROM_ADDRESS_MASK;
- sz = ~(sz & PCI_ROM_ADDRESS_MASK);
+ sz = pci_size(sz, PCI_ROM_ADDRESS_MASK);
res->end = res->start + (unsigned long)
Re: Updated 2.4 TODO List
On Thu, 12 Oct 2000, Keith Owens wrote: > If anything is going to detect the mismatch and complain, it has to be > the boot loader, after uncompressing and before entering the kernel > proper. Perhaps we can add the processor type to linux_banner and print it from setup.S. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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
> On Wed, 11 Oct 2000 18:10:40 -0400,
> [EMAIL PROTECTED] wrote:
> >Are you sure it was compiled with the correct CPU? If you configure the
> >CPU incorrectly (686 when you only have a 586, etc.) the kernel *will*
> >refuse to boot.
> >
> >Maybe we should have the kernel print the CPU information it was
> >compiled with before it does anything else. It'll make it easier to
> >catch what may be a fairly common set of PEBCAK case
>
> Unfortunately any code like this
> if (a)
> b = 99;
> generates conditional move (cmove) instructions on 686. In vsprintf.c
> there are several of these constructs, in particular strnlen generates
> it. So printk("%s", text) tends to fault as well. Some people have
> argued that critical routines should always be compiled with -i386,
> unfortunately that includes all of printk and all console handling
> (both serial and screen), not really an option.
>
> If anything is going to detect the mismatch and complain, it has to be
> the boot loader, after uncompressing and before entering the kernel
> proper.
But the kernel should be able to write directly to the screen, even if it's
extremely minimal information. Something like how LILO does it: test the
common hang-on-boot conditions (like wrong CPU type) and print a single
character after each test.
chris
-
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/
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 - more on PCI resources...]
Linus Torvalds wrote: > > On Wed, 11 Oct 2000, Dag B wrote: > > [snip] > > Expansion ROM at 1800 [disabled] [size=32M] > > Capabilities: [dc] Power Management version 1 > > There's something really wrong going on with your ethernet controller. It > seems to try to take up all available space. > > Please add a debug printk() to drivers/pci/setup-res.c to the very end of Linus, I realized there was one more test to do before deeming the hardware sane. PCMCIA (16-bit) in my laptop is tested and works fine with three different types of cards. Another Xircom card behaved just the same (non-functional) in my latop. My Xircom card was tested in another laptop and found working. Today I took my card *and* disk and tested it in an identical laptop. It works. So it appears that the *cardbus* logic is broken on my machine. Plain, old hardware defect. And I have been wasting your time. Sorry about that. In any case, debug output follows for both the non-working and the working case. Feel free to pin-point the hw-bug or flat out ignore it. Thanks, Dag B Non-working case: [] 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:68 [10b7/9050] 000200 00 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/0005] 000300 00 Found 01:01 [10c8/8005] 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: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 Bus scan for 00 returning with max=09 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbda0 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 f400-f7ff (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 ec80-ecbf (f=101, d=0, p=0) PCI: Resource f900-f9ff (f=1208, d=0, p=0) PCI: Resource fdc0-fdff (f=200, d=0, p=0) PCI: Resource fdb0-fdbf (f=200, d=0, p=0) PCI: Resource f8c0-f8ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) bus res 0 100 - bus res 1 200 - bus res 0 100 - bus res 1 200 - bus res 0 100 - bus res 1 200 - device 3Com Corporation 3c905 100BaseTX [Boomerang] resource 6 size 0001 bus res 0 100 - bus res 1 200 - Limiting direct PCI/PCI transfers. [] cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 Found 06:00 [115d/0003] 000200 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 1 size 04000800 PCI: Failed to allocate resource 1 for PCI device 115d:0003 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 2 size 04000800 PCI: Failed to allocate resource 2 for PCI device 115d:0003 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 6 size 04004000 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 6 size 04004000 PCI: Failed to allocate resource 6 for PCI device 115d:0003 PCI: Enabling device 06:00.0 ( -> 0003) Found 06:01 [115d/0103] 000300 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0103 resource 1 size 04000800 PCI: Failed to allocate resource 1 for PCI device 115d:0103 bus res 0 1200 1c00-1fff bus res
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
[EMAIL PROTECTED] wrote: > Maybe we should have the kernel print the CPU information it was > compiled with before it does anything else. It'll make it easier to > catch what may be a fairly common set of PEBCAK case I was told that "printing" anything was out of the question, as the "printing" routine doesn't work: It would contain 686 instructions, which wouldn't work on the Pentium. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - 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
[EMAIL PROTECTED] wrote: Maybe we should have the kernel print the CPU information it was compiled with before it does anything else. It'll make it easier to catch what may be a fairly common set of PEBCAK case I was told that "printing" anything was out of the question, as the "printing" routine doesn't work: It would contain 686 instructions, which wouldn't work on the Pentium. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - 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 - more on PCI resources...]
Linus Torvalds wrote: On Wed, 11 Oct 2000, Dag B wrote: [snip] Expansion ROM at 1800 [disabled] [size=32M] Capabilities: [dc] Power Management version 1 There's something really wrong going on with your ethernet controller. It seems to try to take up all available space. Please add a debug printk() to drivers/pci/setup-res.c to the very end of Linus, I realized there was one more test to do before deeming the hardware sane. PCMCIA (16-bit) in my laptop is tested and works fine with three different types of cards. Another Xircom card behaved just the same (non-functional) in my latop. My Xircom card was tested in another laptop and found working. Today I took my card *and* disk and tested it in an identical laptop. It works. So it appears that the *cardbus* logic is broken on my machine. Plain, old hardware defect. And I have been wasting your time. Sorry about that. In any case, debug output follows for both the non-working and the working case. Feel free to pin-point the hw-bug or flat out ignore it. Thanks, Dag B Non-working case: [] 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:68 [10b7/9050] 000200 00 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/0005] 000300 00 Found 01:01 [10c8/8005] 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: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 Bus scan for 00 returning with max=09 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbda0 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 f400-f7ff (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 ec80-ecbf (f=101, d=0, p=0) PCI: Resource f900-f9ff (f=1208, d=0, p=0) PCI: Resource fdc0-fdff (f=200, d=0, p=0) PCI: Resource fdb0-fdbf (f=200, d=0, p=0) PCI: Resource f8c0-f8ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) bus res 0 100 - bus res 1 200 - bus res 0 100 - bus res 1 200 - bus res 0 100 - bus res 1 200 - device 3Com Corporation 3c905 100BaseTX [Boomerang] resource 6 size 0001 bus res 0 100 - bus res 1 200 - Limiting direct PCI/PCI transfers. [] cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 Found 06:00 [115d/0003] 000200 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 1 size 04000800 PCI: Failed to allocate resource 1 for PCI device 115d:0003 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 2 size 04000800 PCI: Failed to allocate resource 2 for PCI device 115d:0003 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 6 size 04004000 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 6 size 04004000 PCI: Failed to allocate resource 6 for PCI device 115d:0003 PCI: Enabling device 06:00.0 ( - 0003) Found 06:01 [115d/0103] 000300 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0103 resource 1 size 04000800 PCI: Failed to allocate resource 1 for PCI device 115d:0103 bus res 0 1200 1c00-1fff bus res 1 200
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/
RE: Updated 2.4 TODO List
On Wed, 11 Oct 2000 18:10:40 -0400,
[EMAIL PROTECTED] wrote:
Are you sure it was compiled with the correct CPU? If you configure the
CPU incorrectly (686 when you only have a 586, etc.) the kernel *will*
refuse to boot.
Maybe we should have the kernel print the CPU information it was
compiled with before it does anything else. It'll make it easier to
catch what may be a fairly common set of PEBCAK case
Unfortunately any code like this
if (a)
b = 99;
generates conditional move (cmove) instructions on 686. In vsprintf.c
there are several of these constructs, in particular strnlen generates
it. So printk("%s", text) tends to fault as well. Some people have
argued that critical routines should always be compiled with -i386,
unfortunately that includes all of printk and all console handling
(both serial and screen), not really an option.
If anything is going to detect the mismatch and complain, it has to be
the boot loader, after uncompressing and before entering the kernel
proper.
But the kernel should be able to write directly to the screen, even if it's
extremely minimal information. Something like how LILO does it: test the
common hang-on-boot conditions (like wrong CPU type) and print a single
character after each test.
chris
-
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
On Thu, 12 Oct 2000, Keith Owens wrote: If anything is going to detect the mismatch and complain, it has to be the boot loader, after uncompressing and before entering the kernel proper. Perhaps we can add the processor type to linux_banner and print it from setup.S. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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 - more on PCI resources...]
On Thu, 12 Oct 2000, Dag Bakke wrote:
Linus,
I realized there was one more test to do before deeming the hardware sane.
PCMCIA (16-bit) in my laptop is tested and works fine with three different
types of cards.
Another Xircom card behaved just the same (non-functional) in my latop.
My Xircom card was tested in another laptop and found working.
Today I took my card *and* disk and tested it in an identical laptop.
It works.
So it appears that the *cardbus* logic is broken on my machine. Plain, old
hardware defect. And I have been wasting your time. Sorry about that.
No problem. This was good to have it out of the way. And I don't think you
actually wasted my time: this may still be a Linux bug. See more below.
In any case, debug output follows for both the non-working and the working
case. Feel free to pin-point the hw-bug or flat out ignore it.
Yup, bug pin-pointed, and clear: these are the resources for the failing
case:
device PCI device 115d:0003 resource 1 size 04000800
device PCI device 115d:0003 resource 2 size 04000800
device PCI device 115d:0003 resource 6 size 04004000
device PCI device 115d:0003 resource 6 size 04004000
device PCI device 115d:0103 resource 1 size 04000800
device PCI device 115d:0103 resource 2 size 04000800
device PCI device 115d:0103 resource 6 size 04004000
device PCI device 115d:0103 resource 6 size 04004000
While I'll bet you $20 that the working case (which doesn't print out the
same printk because it doesn't fail) has the exact same resources, except
the "size" field doesn't have that pesky high bit set, so the sizes are
all 0x0800 of 0x4000 instead of being 64MB+.
Now, that said, I do think that this is a linux bug. Sure, your hardware
is strange too, and hardware obviously _does_ make a difference, but there
is no way a non-power-of-two size field can ever be valid, and Linux is
buggy for allowing the hardware to confuse it this way.
What seems to be happening is that somehow your cardbus bridge (or docking
station bridge) is set up so that it doesn't let through that high bit
that defines the size of the PCI bridge map, and the way Linux calculates
the size is basically the simplistic
write all 1's to the base register
read the base register
sz = ~(base mask) maxmask;
and while that works most of the time in normal situations, it's really
not correct. What we _should_ do is more akin to this patch. Can you test
this on your broken system, and see if the system magically comes to life?
NOTE! I do worry about the masking off of a bit in the bridge. There may
be a real hardware bug there - but the fact that the mask seems to move
depending on how big a bridge window there is (judging by your past mails
about how behaviour did actually change when changing the cardbus window
size) implies to me that it's not something as simple as a stuck bit.
If it is a stuck bit somehow, then you're screwed, and the patch below
won't help you at all. But if it's the bridge snooping (and modifying) the
decode window sizes, then the patch below should make a difference.
Thanks,
Linus
--- v2.4.0-test9/linux/drivers/pci/pci.cSun Oct 8 10:50:20 2000
+++ linux/drivers/pci/pci.c Thu Oct 12 09:52:07 2000
@@ -474,6 +474,16 @@
return IORESOURCE_MEM;
}
+/*
+ * Find the extent of a PCI decode..
+ */
+static u32 pci_size(u32 base, u32 mask)
+{
+ u32 size = mask base; /* Find the significant bits */
+ size = size ~(size-1);/* Get the lowest of them to find the decode
+size */
+ return size-1; /* extent = size - 1 */
+}
+
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int rom)
{
unsigned int pos, reg, next;
@@ -501,10 +511,10 @@
l = 0;
if ((l PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY) {
res-start = l PCI_BASE_ADDRESS_MEM_MASK;
- sz = ~(sz PCI_BASE_ADDRESS_MEM_MASK);
+ sz = pci_size(sz, PCI_BASE_ADDRESS_MEM_MASK);
} else {
res-start = l PCI_BASE_ADDRESS_IO_MASK;
- sz = ~(sz PCI_BASE_ADDRESS_IO_MASK) 0x;
+ sz = pci_size(sz, PCI_BASE_ADDRESS_IO_MASK 0x);
}
res-end = res-start + (unsigned long) sz;
res-flags |= (l 0xf) | pci_calc_resource_flags(l);
@@ -543,7 +553,7 @@
res-flags = (l PCI_ROM_ADDRESS_ENABLE) |
IORESOURCE_MEM | IORESOURCE_PREFETCH | IORESOURCE_READONLY |
IORESOURCE_CACHEABLE;
res-start = l PCI_ROM_ADDRESS_MASK;
- sz = ~(sz PCI_ROM_ADDRESS_MASK);
+ sz = pci_size(sz, PCI_ROM_ADDRESS_MASK);
res-end = res-start + (unsigned long) sz;
}
res-name =
Re: Updated 2.4 TODO List
On Thu, 12 Oct 2000 11:02:50 -0400, "Chris Swiedler" [EMAIL PROTECTED] wrote: But the kernel should be able to write directly to the screen, even if it's extremely minimal information. Something like how LILO does it: test the common hang-on-boot conditions (like wrong CPU type) and print a single character after each test. You miss the point. The generated C code for any part of the kernel can contains instructions that break on older boxes. Compiling bits of the kernel in 386 and bits in 686 mode is not a long term solution, you will be forever tracking down which bits can be compiled with which options. printk() itself is not reliable under these circumstances so you would have to use a special I/O routine to log these problems. Also the code that detects the problem must never use the new instructions itself. That means the detect and warn code must be separate from the main kernel, either as part of the boot loader or as part of the 16 bit setup code. Any such code must not use printk() for IO. BTW, your ISP is sending mail from a server with no reverse DNS. That puts it in the same category as 99% of the spam sources on the net, please ask them to fix their DNS. Received: from [216.162.44.3] ([216.162.44.3]:13574 "EHLO challenge.atlanticweb.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. 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
On Thu, 12 Oct 2000 02:20:15 +0200, Jan Niehusmann <[EMAIL PROTECTED]> wrote: >> argued that critical routines should always be compiled with -i386, >> unfortunately that includes all of printk and all console handling >> (both serial and screen), not really an option. > >Neither printk nor console handling should be too performance >critical, and the performance of console i/o is probably not limited >by processor speed, so compiling them for i386 should not make a big >difference. >(Note that this is a guess - I did no benchmarks!) AFAICT, compiling console I/O for -i386 means that all of serial.o must be compiled with -i386. People with high speed serial links will not thank you for that. - 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
> argued that critical routines should always be compiled with -i386, > unfortunately that includes all of printk and all console handling > (both serial and screen), not really an option. Neither printk nor console handling should be too performance critical, and the performance of console i/o is probably not limited by processor speed, so compiling them for i386 should not make a big difference. (Note that this is a guess - I did no benchmarks!) Jan - 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
On Wed, 11 Oct 2000 18:10:40 -0400,
[EMAIL PROTECTED] wrote:
>Are you sure it was compiled with the correct CPU? If you configure the
>CPU incorrectly (686 when you only have a 586, etc.) the kernel *will*
>refuse to boot.
>
>Maybe we should have the kernel print the CPU information it was
>compiled with before it does anything else. It'll make it easier to
>catch what may be a fairly common set of PEBCAK case
Unfortunately any code like this
if (a)
b = 99;
generates conditional move (cmove) instructions on 686. In vsprintf.c
there are several of these constructs, in particular strnlen generates
it. So printk("%s", text) tends to fault as well. Some people have
argued that critical routines should always be compiled with -i386,
unfortunately that includes all of printk and all console handling
(both serial and screen), not really an option.
If anything is going to detect the mismatch and complain, it has to be
the boot loader, after uncompressing and before entering the kernel
proper.
-
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
> The bug report said that it was verified under both SCSI and ATAPI MO, > and that uses a different driver than the SCSI CD-ROM code, I think ATAPI Magneto Optical is SCSI disk. The same thing applies to disk and CD, it isnt just a CD-ROM path item. Both work in 2.2 - 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
On Wed, Oct 11 2000, [EMAIL PROTECTED] wrote: >Date: Mon, 9 Oct 2000 16:24:24 +0100 (BST) >From: Alan Cox <[EMAIL PROTECTED]> > >> * FAT filesystem doesn't support 2kb sector sizes (did under 2.2.16, >>doesn't under 2.4.0test7. Kazu Makashima, alan) > >[Same as the CDROM bug listed earlier I think] > > The bug report said that it was verified under both SCSI and ATAPI MO, > and that uses a different driver than the SCSI CD-ROM code, I think Right, ide-cd are totally separate wrt file system issues. ide-cd works just fine with < 2KB sector sizes. > (Speaking of which, Jens Axboe said he was going to fix the SCSI-CDROM > driver to work on filesystems less than 2k --- i.e. 1k ext2 filesystems, > since this worked under 2.2. Has this gotten fixed yet?) That he said, and no it's not fixed just yet. Haven't had time yet, but it will be fixed Soon. -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - 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
Date: Sun, 8 Oct 2000 23:24:49 -0700 From: Mitchell Blank Jr <[EMAIL PROTECTED]> > * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for >more info) I _highly_ suspect that this is not a 2.4 bug but is instead user error. I've seen it several times. On all kernel versions prior to 2.3.11 if you compiled with the CPU set to a newer model then you had (for instance, of you selected "Pentium Pro" and you actually had a 486) you would get a kernel that worked fine albiet not optimally. On kernels 2.3.11 you will have an unbootable kernel. Yup, that sounds like it. Could someone with a Thinkpad 390 confirm that they can boot with a properly configured kernel? Many thanks. (Bug now moved to "Should be fixed, confirmation wanted") - Ted - 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
Date: Mon, 9 Oct 2000 16:24:24 +0100 (BST) From: Alan Cox <[EMAIL PROTECTED]> > * FAT filesystem doesn't support 2kb sector sizes (did under 2.2.16, >doesn't under 2.4.0test7. Kazu Makashima, alan) [Same as the CDROM bug listed earlier I think] The bug report said that it was verified under both SCSI and ATAPI MO, and that uses a different driver than the SCSI CD-ROM code, I think (Speaking of which, Jens Axboe said he was going to fix the SCSI-CDROM driver to work on filesystems less than 2k --- i.e. 1k ext2 filesystems, since this worked under 2.2. Has this gotten fixed yet?) - Ted - 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 - more on PCI resources...
On Wed, 11 Oct 2000, Dag B wrote:
>
> > drivers/pcmcia/yenta.c to allocate more than 4MB of PCI memory window.
> [snip]
>
> > align = size = 32*1024*1024;
> Done.
> Didn't work. But it certainly made a difference.
>
> lspci -v now says:
>
> 06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03)
> Subsystem: Xircom Cardbus Ethernet 10/100
> Flags: medium devsel, IRQ 11
> I/O ports at 1800 [size=128]
> [virtual] Memory at 1800 (32-bit, non-prefetchable)
> [size=32M]
> [virtual] Memory at 1800 (32-bit, non-prefetchable)
> [size=32M]
> Expansion ROM at 1800 [disabled] [size=32M]
> Capabilities: [dc] Power Management version 1
There's something really wrong going on with your ethernet controller. It
seems to try to take up all available space.
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
Date: Mon, 09 Oct 2000 20:13:35 +0200 From: Thomas Sailer <[EMAIL PROTECTED]> Alan Cox wrote: > > > 4. Boot Time Failures > > > > * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for > >more info) > > Add Palmax PD1100 hangs during boot since 2.4.0-test9 My Asus P55TP4 (i430FX)/AMD K5 PC also crashes after "Booting the kernel..." and before printing anything else Are you sure it was compiled with the correct CPU? If you configure the CPU incorrectly (686 when you only have a 586, etc.) the kernel *will* refuse to boot. Maybe we should have the kernel print the CPU information it was compiled with before it does anything else. It'll make it easier to catch what may be a fairly common set of PEBCAK case - Ted - 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 - more on PCI resources...
Linus Torvalds wrote: > > On Wed, 11 Oct 2000, Dag B wrote: > > 2.4.0-test9/10p1 > > Can you do another test with this (ie in-kernel pcmcia), AND enable > debugging in both drivers/pci/pci.c and in arch/i386/kernel/pci-i386.h (in [snip] > drivers/pcmcia/yenta.c to allocate more than 4MB of PCI memory window. [snip] > align = size = 32*1024*1024; Done. Didn't work. But it certainly made a difference. lspci -v now says: 06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) Subsystem: Xircom Cardbus Ethernet 10/100 Flags: medium devsel, IRQ 11 I/O ports at 1800 [size=128] [virtual] Memory at 1800 (32-bit, non-prefetchable) [size=32M] [virtual] Memory at 1800 (32-bit, non-prefetchable) [size=32M] Expansion ROM at 1800 [disabled] [size=32M] Capabilities: [dc] Power Management version 1 What used to be a 4M expansion ROM is now 32M. Just for grins, I made a version with align = size = 64*1024*1024; and got [virtual] Memory at 2000 (32-bit, non-prefetchable) [size=64M] Expansion ROM at 2000 [disabled] [size=64M] debug output from boot follows: dagblap:~# dmesg | more Linux version 2.4.0-test9 (root@dagblap) (gcc version 2.95.2 19991024 (release)) #3 Wed Oct 11 22:0 6:48 CEST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 05ef @ 0010 (usable) BIOS-e820: 0001 @ 05ff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 24560 zone(0): 4096 pages. zone(1): 20464 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=test10p1a ro root=/dev/discs/disc0/part5 pci=rom [...] 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:68 [10b7/9050] 000200 00 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/0005] 000300 00 Found 01:01 [10c8/8005] 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: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 Bus scan for 00 returning with max=09 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbda0 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 f400-f7ff (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 ec80-ecbf (f=101, d=0, p=0) PCI: Resource fb00-fbff (f=1208, d=0, p=0) PCI: Resource fdc0-fdff (f=200, d=0, p=0) PCI: Resource fdb0-fdbf (f=200, d=0, p=0) PCI: Resource fac0-faff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.4 [...] NeoMagic 256AV/256ZX audio driver, version 1.1 NM256: Found card signature in video RAM: 0x27ec00 Trying to free nonexistent resource NM256: Mapping port 1 from 0x266c00 - 0x27ec00 Initialized NeoMagic 256AV audio in PCI native mode Initialized AC97 mixer Done installing NM256 audio driver. Linux PCMCIA Card Services 3.1.20 options: [pci] [cardbus] [pm] devfs: v0.102 (2622) Richard Gooch ([EMAIL PROTECTED]) devfs: boot_options: 0x2 kmem_create: Forcing size word alignment - nfs_fh Yenta IRQ list 0298, PCI irq11 Socket status: 3006 Yenta IRQ list 0298, PCI irq11 Socket status: 3020 ACPI: support found ACPI: PBLK 1 @ 0x0810:0 ACPI: S1 supported ACPI: S5 supported cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 Found 06:00 [115d/0003] 000200 00 PCI: Failed to allocate resource 1 for PCI device 115d:0003 PCI: Failed to allocate resource 2 for PCI device 115d:0003 PCI: Failed to allocate resource 6 for PCI device 115d:0003 PCI: Enabling device 06:00.0 ( -> 0003) Found 06:01 [115d/0103] 000300 00 PCI:
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
Date: Tue, 10 Oct 2000 17:53:57 -0300 (BRST)
From: Rik van Riel <[EMAIL PROTECTED]>
> 2. Capable Of Corrupting Your FS/data
>
> * Non-atomic page-map operations can cause loss of dirty bit on
>pages (sct, alan)
Is anybody looking into fixing this bug ?
According to sct (who's sitting next to me in my hotel room at ALS) Ben
LaHaise has a bugfix for this, but it hasn't been merged.
> * VM: Fix the highmem deadlock, where the swapper cannot create low
>memory bounce buffers OR swap out low memory because it has
>consumed all resources {CRITICAL} (old bug, already reported in
>2.4.0test6)
Haven't been able to reproduce it on my 1GB test machine,
but it might still be there. Can anyone confirm if this
bug is still present ?
Note: all of the issues on the TODO list with the "VM:" prefix are from
a VM todo list you posted a week or two ago; so I'm assuming that you
know more about those issues than I do. (feel free to send me an
updated list and I'll merge it into the 2.4 TODO list.)
- Ted
-
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 - more on PCI resources...
On Wed, 11 Oct 2000, Dag B wrote: > > Tested with: > 2.2.18pre15 + pcmcia-cs 3.1.21 > 2.4.0-test9/10p1 Can you do another test with this (ie in-kernel pcmcia), AND enable debugging in both drivers/pci/pci.c and in arch/i386/kernel/pci-i386.h (in both cases, just change the #undef DEBUG to a #define DEBUG and recompile the kernel). In addition, you might want to change the yenta_allocate_res() thing in drivers/pcmcia/yenta.c to allocate more than 4MB of PCI memory window. Change the line that says align = size = 4*1024*1024; to something like align = size = 32*1024*1024; and see if that makes any difference.. But the DEBUG output is the most interesting part. 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 - more on PCI resources...
Keywords: cardbus, dell, xircom, pci, resources In short: Xircom Realport cardbus cards still do not work under Linux in (my) Dell Latitude CPi laptop. A problem indication shows up even before loading the xircom driver. This is not the Latitude docking-station problem, which has been noted by others. AFAICT. Tested with: 2.2.18pre15 + pcmcia-cs 3.1.21 2.4.0-test9/10p1 2.4.0-test9 + pcmcia-cs 3.1.21 quite a few other combinations, including older versions of 2.2 and 2.4-test* kernels and pcmcia-cs. I have tried every combination of "rom,bios,direct" as options to the "pci=" kernel boot-option, 3 different BIOS versions, with and without the docking (which has never caused me any grief, mind you), with cardbus support compiled-in and as modules, and quite a few other tricks and stupidities. No go. As soon as I insert the card (or if the card was inserted prior to boot, during boot-time), I get: cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 PCI: Failed to allocate resource 1 for PCI device 115d:0003 PCI: Failed to allocate resource 2 for PCI device 115d:0003 PCI: Failed to allocate resource 6 for PCI device 115d:0003 PCI: Enabling device 06:00.0 ( -> 0003) PCI: Failed to allocate resource 1 for PCI device 115d:0103 PCI: Failed to allocate resource 2 for PCI device 115d:0103 PCI: Failed to allocate resource 6 for PCI device 115d:0103 PCI: Enabling device 06:00.1 ( -> 0003) (-test9) or, in the case of 2.2.18pre15+pcmcia-cs 3.1.21: Oct 8 20:58:56 dagblap pcmcia: Starting PCMCIA services: Oct 8 20:58:56 dagblap pcmcia: modules Oct 8 20:58:57 dagblap kernel: Linux PCMCIA Card Services 3.1.21 Oct 8 20:58:57 dagblap kernel: kernel build: 2.2.18pre15 #1 Sun Oct 8 20:31:01 CEST 2000 Oct 8 20:58:57 dagblap kernel: options: [pci] [cardbus] [apm] [pnp] Oct 8 20:58:57 dagblap kernel: PCI routing table version 1.0 at 0xfbda0 Oct 8 20:58:57 dagblap kernel: 00:03.0 -> irq 11 Oct 8 20:58:57 dagblap kernel: 00:03.1 -> irq 11 Oct 8 20:58:57 dagblap kernel: PnP: PNP BIOS installation structure at 0xc00fe2d0 Oct 8 20:58:57 dagblap kernel: PnP: PNP BIOS version 1.0, entry at f:e2f4, dseg at 40 Oct 8 20:58:57 dagblap kernel: Intel PCIC probe: Oct 8 20:58:57 dagblap kernel: TI 1225 rev 01 PCI-to-CardBus at slot 00:03, mem 0x6800 Oct 8 20:58:57 dagblap kernel: host opts [0]: [ring] [serial pci & irq] [pci irq 11] [lat 32/32] [bus 32/34] Oct 8 20:58:57 dagblap kernel: host opts [1]: [ring] [serial pci & irq] [pci irq 11] [lat 32/32] [bus 35/37] Oct 8 20:58:57 dagblap kernel: ISA irqs (scanned) = 3,7,9 PCI status changes Oct 8 20:58:57 dagblap pcmcia: cardmgr. Oct 8 20:58:57 dagblap rc: Starting pcmcia succeeded Oct 8 20:58:57 dagblap cardmgr[481]: starting, version is 3.1.21 Oct 8 20:58:57 dagblap kernel: cs: cb_alloc(bus 35): vendor 0x115d, device 0x0003 Oct 8 20:58:57 dagblap cardmgr[481]: watching 2 sockets Oct 8 20:58:57 dagblap kernel: cs: IO port probe 0x1000-0x17ff: clean. Oct 8 20:58:57 dagblap kernel: cs: IO port probe 0x0100-0x04ff: clean. Oct 8 20:58:57 dagblap kernel: cs: IO port probe 0x0a00-0x0aff: clean. Oct 8 20:58:57 dagblap cardmgr[481]: initializing socket 1 Oct 8 20:58:57 dagblap kernel: cs: no valid ROM images found! Oct 8 20:58:57 dagblap cardmgr[481]: unsupported card in socket 1 Oct 8 20:58:57 dagblap cardmgr[481]: no product info available Oct 8 20:58:57 dagblap cardmgr[481]: PCI id: 0x115d, 0x0003 The hardware is functional. (Tested on NT4.) lspci -v says: 06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) Subsystem: Xircom Cardbus Ethernet 10/100 Flags: medium devsel, IRQ 11 I/O ports at 1800 [size=128] [virtual] Memory at 1100 (32-bit, non-prefetchable) [size=4M] [virtual] Memory at 1100 (32-bit, non-prefetchable) [size=4M] Expansion ROM at 1100 [disabled] [size=4M] Capabilities: [dc] Power Management version 1 06:00.1 VGA compatible controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) (prog-if 02) Subsystem: Xircom CBEM56G-100 Ethernet + 56k Modem Flags: medium devsel, IRQ 11 I/O ports at 1880 [size=8] [virtual] Memory at 1100 (32-bit, non-prefetchable) [size=4M] [virtual] Memory at 1100 (32-bit, non-prefetchable) [size=4M] Expansion ROM at 1100 [disabled] [size=4M] Capabilities: [dc] Power Management version 1 This line: "Expansion ROM at 1100 [disabled] [size=4M]" doesn't look very positive. Can the PCI resource allocation code handle a 4M ROM image? (To the extent which the PCI code cares...?) I do know other users with the exact same type of Xircom card, so this is quite possible some quirk with this particular laptop model. (CPiA 366XT) Any takers? Let me know what debug-switches and knobs I can turn on, and what information I can provide. Regards, Dag B - To unsubscribe from this list: send the line "unsubscribe linux-kernel"
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/
