[BUG?] AMD K5 and 2.4 (was Re: Updated 2.4 TODO List)

[Barry K. Nathan]

(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)

[Linus Torvalds]

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)

[Martin Mares]

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)

[Eric W. Biederman]

"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)

[Linus Torvalds]

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)

[jamal]

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-

Re: Updated 2.4 TODO List

[Pavel Machek]

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

[Dunlap, Randy]

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 -- new addition WAS(test9 PCI resourcecollisions (fwd)

[jamal]

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

[Pavel Machek]

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)

[Linus Torvalds]

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...]

[Dunlap, Randy]

> > 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...]

[Linus Torvalds]

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)

[Linus Torvalds]

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...]

[Dunlap, Randy]

> 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)

[jamal]

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)

[jamal]

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 region

Re: Updated 2.4 TODO List - more on PCI resources...]

[Dag B]

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...]

[David Hinds]

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...]

[Dunlap, Randy]

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)

[Linus Torvalds]

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)

[Linus Torvalds]

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...]

[Linus Torvalds]

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

[Keith Owens]

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...]

[Linus Torvalds]

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) s

Re: Updated 2.4 TODO List

[Oliver Xymoron]

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

[Chris Swiedler]

> 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

[Horst von Brand]

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

[yodaiken]

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...]

[Dag Bakke]

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

Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI

[Horst von Brand]

[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

[Alexander Viro]

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)

[David Woodhouse]

[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

[Alan Cox]

> 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

[Alan Cox]

>   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

[Rogier Wolff]

[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

[Cort Dougan]

} 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

[David S. Miller]

   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

[yodaiken]

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

[Horst von Brand]

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

[Andrea Arcangeli]

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

[Cort Dougan]

}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

[Adrian Bunk]

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

[David S. Miller]

   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

[Cort Dougan]

}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

[David S. Miller]

   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

[Cort Dougan]

> 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

[Nathan Paul Simons]

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

[Keith Owens]

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

[Jan Niehusmann]

> 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

[Keith Owens]

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

[Alan Cox]

> 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

[Jens Axboe]

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

[tytso]

   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

[tytso]

   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)

[Gnea]

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...

[Linus Torvalds]

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

[tytso]

   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

[Alan Cox]

> > 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...

[Dag B]

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: Failed

Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)

[Gnea]

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)

[Gérard Roudier]

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

[tytso]

   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...

[Linus Torvalds]

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...

[Dag B]

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" i

Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)

[Alan Cox]

> - 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)

[Horst von Brand]

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

[Byron Stanoszek]

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)

[Jakub Jelinek]

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&R 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

[Alan Cox]

> 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)

[Mike A. Harris]

On 10 Oct 2000, Gnea wrote:

>>  Please add this to your list. Linux is unusable in these machines.
>>  I have cc'ed Martin and Linus because they play in that PCI area.
>
>erm, looking at your list it says that you're using Redhat 7.0, which
>is known to ship with a buggy gcc, which is KNOWN to do nasty things
>with kernels.  
>
>Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc
>version 2.96 2
>731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000
>
>yeah, that pretty much sums it up right there.. you may want to try
>something else.

Once again misinformation and FUD.

On Red Hat 7.0, use "kgcc" for kernel compilation.  This is
really an FAQ...  Instead of changing distributions, try reading
manuals.

--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

Microsoft Windows(tm). A thirty-two bit extension and graphical shell
to a sixteen bit patch to an eight bit operating system originally
coded for a four bit microprocessor which was written by a two-bit
company that can't stand one bit of competition.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)

[Gnea]

On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth:

> 
>  Ted,
>  
>  Please add this to your list. Linux is unusable in these machines.
>  I have cc'ed Martin and Linus because they play in that PCI area.

erm, looking at your list it says that you're using Redhat 7.0, which
is known to ship with a buggy gcc, which is KNOWN to do nasty things
with kernels.  

Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc
version 2.96 2
731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000

yeah, that pretty much sums it up right there.. you may want to try
something else.

-- 
.oO gnea at rochester dot rr dot com Oo.
.oO url: http://garson.org/~gnea Oo.

"You can tune a filesystem, but you can't tuna fish" -unknown

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Updated 2.4 TODO List

[Alan Cox]

> It is not a configuration that I currently test.  I am told it mostly
> works, though some client drivers are not SMP safe.  It is something
> that should be fixed eventually, for sure, but given the number of
> open issues with PCMCIA in 2.4, I don't think it is high on the list.
> If you want to say that PCMCIA on SMP is unsupported until someone
> carefully checks it out and fixes these things, I suppose that's fine.

If we wish to do this then we might as well be honest about the current code
and say
'power management doesnt work on SMP either'

alternatively the right thing to do is to fix both PM and the pcmcia. Most of
the PCMCIA can be fixed for 2.4 by dropping lock_kernel() around the relevant
areas. Sure its ugly but PCMCIA hot swapping is not a critical performance code
path.

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

[Rik van Riel]

On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:

> 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 ?

> 9. To Do
> 
>  * mm->rss is modified in some places without holding the
>page_table_lock (sct)

Probably not a show-stopper, but we're looking for
volunteers to fix this one anyway ;)

>  * VM: Out of Memory handling {CRITICAL}

Seems to work now, except for the fact that it is possible
to end up with a heavily thrashing system that /just/ didn't
run out of memory and doesn't get anything killed.

Then again, you can end up with a heavily thrashing system
where you can't get anything done without running out of swap
anyway ... the proper fix for this is probably some form of
thrashing control...

>  * 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 ?

>  * VM: page->mapping->flush() callback in page_lauder() for easier
>integration with journaling filesystem and maybe the network
>filesystems

Possibly a 2.5 issue, or something to merge later in 2.4,
since we don't have journaling filesystems in the kernel
anyway. I guess we'll want it for the network filesystems
though.

But this is a fairly simple thing to integrate:
1) have an appropriate function in the filesystems
2) insert function pointer in the right struct
3) call the function from vmscan.c::page_launder()

>  * VM: maybe rebalance the swapper a bit... we do page aging now so
>maybe refill_inactive_scan() / shm_swap() and swap_out() need to
>be rebalanced a bit

I'll try to look into this (3 days to go before I have to
leave for Miami) and see how things can be improved here.

> 11. To Check
> 
>  * VFS?VM - mmap/write deadlock (demo code seems to show lock is
>there)

Does anyone have the demo code at hand so we can verify if this
still happens ?

>  * Stressing the VM (IOPS SPEC SFS) with HIGHMEM turned on can hang
>system (linux-2.4.0test5, Ying Chen, Rik van Riel)

Ditto. Can this still be reproduced with the latest VM or was
it simply a side effect of something else in the VM that got
fixed recently ?

(the highmem code itself looks ok so the bug might well have
been caused by a side effect of something else)

> 12. Probably Post 2.4
> 
>  * addres_space needs a VM pressure/flush callback (Ingo)

[duplicate item?]

We may want this to better support the journaling filesystems
in 2.4  but I agree that it should probably be post 2.4.0.

>  * VM: physical->virtual reverse mapping, so we can do much better
>page aging with less CPU usage spikes
>  * VM: better IO clustering for swap (and filesystem) IO
>  * VM: move all the global VM variables, lists, etc. into the pgdat
>struct for better NUMA scalability
>  * VM: (maybe) some QoS things, as far as they are major improvements
>with minor intrusion

These 4 seem /definate/ 2.5 issues, though I hope to have them
(except maybe QoS?) ready in an patch before 2.5.0 is split off.

>  * VM: thrashing control, maybe process suspension with some forced
>swapping ?
>  * VM: include Ben LaHaise's code, which moves readahead to the VMA
>level, this way we can do streaming swap IO, complete with
>drop_behind()

These two are fairly simple and may well be done in the next
few weeks. If no bug reports about the current 2.4 VM pop up,
I'll probably look into some of the issues above...


FYI, my personal VM TODO list:
- see if refill_inactive_scan(), swapout_shm(), swap_out(), etc...
  need rebalancing
- anti-thrashing code  (if no hidden nasties are present)
- better IO clustering + readahead at VMA level

AFAIK Juan Quintela is already looking into the ->flush()
callback for journaling filesystems.

And one more TODO item:

* pinned page reservation system for journaling filesystems


regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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

[David Hinds]

On Tue, Oct 10, 2000 at 02:08:45PM -0400, [EMAIL PROTECTED] wrote:
> 
> I am one of those people that uses PCMCIA on an SMP machine, I also
> use 2.4. Aside from the very occasional problem, I don't see any
> locking issues. Is it possible to just leave it as is with a warning? 

I think the configuration should still permit it; the probability of
hitting the locking issue in the ds module is vanishingly small.  The
problem of non-SMP-tested PCMCIA drivers is more serious, but I'd
really call all the 2.4 PCMCIA code "experimental" at this point.

-- 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

[mmangino]

> > So I propose that this item be removed simply by stating "Linux 2.4 does
> > not support PCMCIA on multiprocessors".   Comments, David?
> 
> There are some people who use PCMCIA on SMP desktop boxes; many
> wireless network cards are only made as PCMCIA cards, and the "desktop
> version" consists of an ISA or PCI card reader plus a card.
> 
> It is not a configuration that I currently test.  I am told it mostly
> works, though some client drivers are not SMP safe.  It is something
> that should be fixed eventually, for sure, but given the number of
> open issues with PCMCIA in 2.4, I don't think it is high on the list.
> If you want to say that PCMCIA on SMP is unsupported until someone
> carefully checks it out and fixes these things, I suppose that's fine.
> 
> -- Dave


I am one of those people that uses PCMCIA on an SMP machine, I also use 2.4. Aside 
from the very occasional problem, I don't see any locking issues. Is it possible to 
just leave it as is with a warning?

If someone is willing to help get me started? I'll go through and try to clean up the 
SMP safeness issues.

Mike
-- 
Mike ManginoSenior Software Engineer 
Home: (614) 428-7565Work: (614) 659-8710
[EMAIL PROTECTED][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

[David Hinds]

On Wed, Oct 11, 2000 at 12:04:22AM +1100, Andrew Morton wrote:

> >  * Misc locking problems
> >   + drivers/pcmcia/ds.c: ds_read & ds_write. SMP locks are
> > missing, on UP the sleep_on() use is unsafe.
> 
> It is my understanding that hen's teeth easily outnumber SMP PCMCIA
> systems.  spinlocks in drivers/pcmcia/ and drivers/net/pcmcia/ are
> almost nonexistent.
> 
> So I propose that this item be removed simply by stating "Linux 2.4 does
> not support PCMCIA on multiprocessors".   Comments, David?

There are some people who use PCMCIA on SMP desktop boxes; many
wireless network cards are only made as PCMCIA cards, and the "desktop
version" consists of an ISA or PCI card reader plus a card.

It is not a configuration that I currently test.  I am told it mostly
works, though some client drivers are not SMP safe.  It is something
that should be fixed eventually, for sure, but given the number of
open issues with PCMCIA in 2.4, I don't think it is high on the list.
If you want to say that PCMCIA on SMP is unsupported until someone
carefully checks it out and fixes these things, I suppose that's fine.

-- 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

[Andrew Morton]

[EMAIL PROTECTED] wrote:
> 
> 3. Security
> 
>  * Fix module remove race bug (still to be done: TTY, ldisc, I2C,
>video_device - Al Viro) (Rogier Wolff will handle ATM)

Patch for tty and ldisc is in your inbox...

> ...
> 
> 8. Fix Exists But Isnt Merged
> 
> ...
>  * Many network device drivers don't call MOD_INC_USE_COUNT in
>dev->open. (Paul Gortmaker has patches)

This should be rephrased "Many network device drivers call
MOD_INC_USE_COUNT too late in dev->open()".

And it has been proposed (frequently, by me) that the
dev_hold()/dev_put()/unregister_netdevice() logic ensures that netdevice
drivers are _not_ race prone wrt module removal and so no development is
needed here.

Unless someone squeaks I suggest you take the red pen to this one.

> ...
> 9. To Do
> 
> ...
>  * Misc locking problems
>   + drivers/pcmcia/ds.c: ds_read & ds_write. SMP locks are
> missing, on UP the sleep_on() use is unsafe.


It is my understanding that hen's teeth easily outnumber SMP PCMCIA
systems.  spinlocks in drivers/pcmcia/ and drivers/net/pcmcia/ are
almost nonexistent.

So I propose that this item be removed simply by stating "Linux 2.4 does
not support PCMCIA on multiprocessors".   Comments, David?
-
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

[Decklin Foster]

Mitchell Blank Jr writes:

> [EMAIL PROTECTED] wrote:
> > 4. Boot Time Failures
> [...]
> >  * 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.



You are correct -- I was able to resolve this problem as you outlined
in your message (the responses I got might have gotten lost in the
vger move). So this issue can be removed from the list.

-- 
There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There
are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
-
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: [linux-usb-devel] RE: Updated 2.4 TODO List

[Matthew Dharm]

On Mon, Oct 09, 2000 at 04:17:01PM -0700, Dunlap, Randy wrote:
> . OOPS in usb-storage from the error-recovery handler. {CRITICAL}
>   (Matthew Dharm; [EMAIL PROTECTED])

This is fixed as of test9.

Matt

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

What the hell are you?
-- Pitr to Dust Puppy 
User Friendly, 12/3/1997

 PGP signature

RE: Updated 2.4 TODO List

[Dunlap, Randy]

Hi Ted,

Here's an updated USB 2.4 TODO list.

The new entries (changes) are marked with '+'.

~Randy


USB Status/Problems in 2.4.0-test9
2000-October-09



1.  Should [already] Be Fixed

. hid joystick handling (patch from Vojtech) (2.4.0.9.4)
. cpia_usb module doesn't handle "no bandwidth" returns (OOPS) (2.4.0.9.4)
. microtek memory handling (patch from Oliver Neukum) (2.4.0.9.4)
+ hotplug (PNP) and module autoloader support
+ OHCI root-hub-timer does not restart on resume {CRITICAL}
  (Paul Mackerras) (2.4.0-test9)
+ add bandwidth allocation support to usb-uhci HCD (2.4.0-test9)
+ usb-ohci needs to null urb->dev to avoid various reboots/hangs/oopses
{CRITICAL}
  (David Brownell; [EMAIL PROTECTED]) (2.4.0-test9)
+ speed up device enumeration (hub driver has large delays in it)

2.  Capable of corrupting your FS

. Problems with USB storage drives (ORB, maybe Zip) during APM sleep/suspend
. OOPS in usb-storage from the error-recovery handler. {CRITICAL}
  (Matthew Dharm; [EMAIL PROTECTED])

3.  Security

4.  Boot-Time Failures

5.  Compile-Time Failures

6.  In Progress

7.  Obvious Projects for People (well if you have the hardware..)

8.  Fix Exists But Isn't Merged

9.  To Do

. race conditions on devices in use and being unplugged
. SANE backend can't communicate to its scanner (sometimes, some scanners)
. OHCI memory corruption problem
. Fix differences in UHCI and OHCI HCD behaviors/semantics:
.   OHCI doesn't do URB timeouts
.   OHCI always does BULK_QUEUE (as David.B said, Bulk queueing is a
UHCI notion; not needed in OHCI; fix not needed)
. Misc locking problems
  - fix MOD_INC races in plusb.c and uss720.c
  - fix concurrent read/write and other SMP like bugs in:
acm.c
printer.c
scanner.c
uss720.c
serial/ftdi_sio.c
serial/omninet.c
. fix USB_QUEUE_BULK problem in uhci.c (oopsen after a while) {CRITICAL}
. system hang with USB audio driver {CRITICAL}
  (David Woodhouse; [EMAIL PROTECTED])
. usb-ohci needs to null urb->dev to avoid various reboots/hangs/oopses
{CRITICAL}
  (David Brownell; [EMAIL PROTECTED])
. printer Device ID string should not be static; printers can update it
. Fix serial/omninet.c to not require a small mtu setting in order to
  get a PPP link to work properly (as reported by Bernhard Reiter)
. pegasus: avoid warning spewage on disconnect
. OHCI optional zero length packet (USB_DISABLE_SPD at send)
. consistent short packet handling OHCI/UHCI (including 0-length packets)
(Roman)
. consistent URB next pointer handling by OHCI/UHCI (Roman)
. booting with USB compiled into kernel causes a lot of syslog entries
  as the root hubs are probed by all drivers (this is especially
  obnoxious as the usb-serial drivers start up)
. pegasus driver locks up on slow OHCI machine; sometimes cannot be
  rmmod-ed (Cyrille Chepelov; [EMAIL PROTECTED])
+ fix setting urb->dev in printer, acm, bluetooth, all serial drivers
  (Greg KH) {CRITICAL}
+ fix usbdevfs memset() on IOC_WRITE (Dan Streetman) {CRITICAL}
+ fix setting urb->dev in plusb, wacom, mdc800) (Greg KH) {CRITICAL}
+ fix usb-uhci setting urb->dev = NULL at correct places only {CRITICAL}
+ fix hub driver allocation/usage of portstr & tempstr (D. Brownell)
  (causes oops and memory corruptoin) {CRITICAL}
+ USB mouse stopped working (2.4.0-test9) ([EMAIL PROTECTED])
+ oops on boot with 2.4.0-test9, usb-uhci, pegasus (in process_transfer)
  ([EMAIL PROTECTED])
+ pegasus driver version 0.4.12: update to work with HCD changes; fix module
  use counting & dev refcounting; fix to work with dhcpd (Petko) {CRITICAL}

10. To Do But Non-Showstopper

. acm (modem) driver is slow compared to Windows drivers for same modems
  (maybe an HCD problem, not acm driver, or acm should use bulk queueing)
. add devfs support to drivers that don't have it
. add DocBook info to main USB driver interfaces (usb.c)
. Printer stalls at random places when printing large graphics.
  When printing big pictures (10..50 meg) the printer stalls halfway. The
  point where it stalls is random but the fact that it stalls is
  reproducable. Printing the same pictures using the parallel interface
  is ok. Printing text is ok anyway.
  Frank van Maarseveen: [EMAIL PROTECTED]
. Misc locking problems: fix concurrent read/write and other SMP-like
  bugs in:
bluetooth.c
mdc800.c
rio800.c
serial/keyspan.c
serial/whiteheat.c
. fix usb_unlink_urb() bug when called with an urb that was used on a
  device that is no longer registered in the USB system.
. control pipe locking (mutual exclusion)
. use pci_alloc_consistent throughout (mostly OHCI; some people want
  UHCI also)

11. To Check

12. Probably Post 2.4

. spread out interrupt frames for devices that use the same
  interrupt period (interval)
. add USB 2.0 EHCI HCD

~Fixed

. usb-uhci not use set PCI Latency Timer register to 0
. printer driver aborts on out-of-paper or off-line con

TODO UPDATE: RE: Updated 2.4 TODO List

[Dunlap, Randy]

Ted,

Here are some corrections to the published list.
I'm working on new additions now.

~Randy


> 6. In Progress
> 
>  * USB: hotplug (PNP) and module autoloader support
+ Move to "1. Should Be Fixed".  We want more testing of it, of course.

> 9. To Do
> 
>  * USB: OHCI root-hub-timer does not restart on resume {CRITICAL}
>(Paul Mackerras)
+ Move to "1. Should be Fixed".

>  * USB: add bandwidth allocation support to usb-uhci HCD
+ Move to "1. Should be Fixed".

>  * USB: Fix differences in UHCI and OHCI HCD behaviors/semantics:
>   + Only uhci.c does EARLY_COMPLETE (drop EARLY_COMPLETE ?)
+ Move to "Fixed" (actually deleted).

>  * USB: usb-ohci needs to null urb->dev to avoid various
>reboots/hangs/oopses {CRITICAL} (David Brownell;
>[EMAIL PROTECTED])
+ Move to "1. Should be Fixed".

> 10. To Do But Non Showstopper
> 
>  * USB: speed up device enumeration (hub driver has large 
> delays in it)
+ Move to "1. Should be Fixed".


Other updates from linux-usb-devel people?

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

[Thomas Sailer]

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

Tom
-
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

[Shane Shrybman]

>  * RTL 8139 cards sometimes stop responding. Both drivers don't
>handle this quite good enough yet. (reported by Rogier Wolff,
>tentatively reported as fixed by David Ford.)

2.4.0-test9   Spontaneous reboots under network load with this
  driver. Sorry, no more info.

2.4.0-t9-p7   No reboots but lots of errors on the interface. But,
  it does work.

A diff between the two 8139too.c files in these kernels reveals
no differences.


shane

-
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

[Guest section DW]

On Mon, Oct 09, 2000 at 12:19:26AM -0400, [EMAIL PROTECTED] wrote:
> 
>  Linux 2.4 Status/TODO Page
> 
>* 2.4.0-test2 breaks the behaviour of the ether=0,0,eth1 boot
>  parameter (dwguest)

This has been fixed.
-
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

[Alan Cox]

> 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

> 6. In Progress
>  * Finish I2O merge (Intel/Alan)

Assume this is done for 2.4.0. There are things to look at but it works well
enough to be counted as enhancing not fixing. The order of scsi/i2o does need
checking and double checking though

>  * Misc locking problems
>   + drivers/pcmcia/ds.c: ds_read & ds_write. SMP locks are
> missing, on UP the sleep_on() use is unsafe.

Add:  Power management locking needs implementing properly

>  * 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]

-
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

[Tigran Aivazian]

On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
>  * Writing to tapes > 2.4G causes tar to fail with EIO (using
>2.4.0-test7-pre5; it works under 2.4.0-test1-ac18 --- Tigran
>Aivazian)

this has now been working since test8 and certainly in test9. Why it
failed on test7-pre5? Probably some generic scsi-related problem and st
was just "in the way". What is important -- it works now.

Regards,
Tigran

-
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

[Udo A. Steinberg]

[EMAIL PROTECTED] wrote:
> 
> 8. Fix Exists But Isnt Merged

>  * 2.4.0-test8 has a BUG at ll_rw_blk:711. (Johnny Accot, Steffen
>Luitz) (Al Viro has a patch)

Said patch has already been merged in the test9-pre and -final series
and the bug can be considered fixed.

-Udo.
-
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

[Mitchell Blank Jr]

[EMAIL PROTECTED] wrote:
> 4. Boot Time Failures
[...]
>  * 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.

Decklin - please try to reproduce this with CONFIG_M386.  Also you might
try looking in /proc/cpuinfo and make sure that laptop has the CPU you
think it has.  The reason I know which kernel version this problem appeared
in is because I spent an entire evening chasing this same "kernel bug"
a couple months ago.  Turned out the machine I could have _sworn_ was a
Celeron was a K6 :-)

-Mitch
-
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

[Simon Richter]

On Sun, 8 Oct 2000, David Ford wrote:

> > >  Linux 2.4 Status/TODO Page

> > >  * RTL 8139 cards sometimes stop responding.

> > (2.2.18pre) Both drivers oops a lot for me, so there seems to be a more
> > serious problem here.

> This is the 2.4 status/todo page, see title ;)

I know. These oopses still need investigation for 2.4, as the drivers are
not really different from what is in 2.2.18pre7.

   Simon

-- 
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: A319 A60F 20F6 C8A4 3C86  54B4 99CD AC6E 79D1 B1E7
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

-
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

[David Ford]

Simon Richter wrote:

> On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
>
> >  Linux 2.4 Status/TODO Page
>
> >  * RTL 8139 cards sometimes stop responding. Both drivers don't
> >handle this quite good enough yet. (reported by Rogier Wolff,
> >tentatively reported as fixed by David Ford.)
>
> (2.2.18pre) Both drivers oops a lot for me, so there seems to be a more
> serious problem here.

This is the 2.4 status/todo page, see title ;)

-d


--
  "There is a natural aristocracy among men. The grounds of this are
  virtue and talents", Thomas Jefferson [1742-1826], 3rd US President



-
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

[Simon Richter]

On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:

>  Linux 2.4 Status/TODO Page

>  * RTL 8139 cards sometimes stop responding. Both drivers don't
>handle this quite good enough yet. (reported by Rogier Wolff,
>tentatively reported as fixed by David Ford.)

(2.2.18pre) Both drivers oops a lot for me, so there seems to be a more
serious problem here.

>  * ACPI hangs on boot for some systems (Are there any cases left ?)

We had no reports of that for quite some time on the acpi4linux ML.

   Simon

-- 
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: A319 A60F 20F6 C8A4 3C86  54B4 99CD AC6E 79D1 B1E7
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

-
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/