On Wed, Oct 25, 2000 at 05:59:39PM -0400, Jeff Garzik wrote:
> It may work, but the bridge secondary/subordinate numbers look wrong.
>
No, these numbers look correct for me. Read comment in drivers/pci/pci.c:
if (!is_cardbus) {
/* Now we can scan all subordinate buses... *
Hi Jeff!
> First, some definitions:
> downstream - away from the host processor
> primary - number of the PCI bus closer to the host processor
> secondary - number of the PCI bus on the downstream side of the PCI
> bridge
> subordinate - number of the highest-numbered bus on the downstream side
>
It may work, but the bridge secondary/subordinate numbers look wrong.
I am pondering if the bus numbering/bridging stuff shouldn't be given a
good looking-over. I have the wonderful _PCI System Architecture, 4th
Ed._ in my hands, and it describes PCI-PCI bridge init in great detail,
including se
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
On Wed, Oct 25, 2000 at 12:20:58PM -0400, jamal wrote:
> + child->resource[0,1,2] = dev->bus->resource[0,1,2];
Did C change while I was asleep, or is this statement equivalent to
child->resource[2] = dev->bus->resource[2];
?
Jeff
-
To unsubscribe from this list: send
The problem is resolved. Mucho Gracias from me and a few (probably
hundreds of people in my workplace) who might want to boot 2.3/4 on these
Dell docking stations (actually we own a few thousand of them, i am just
trying to make sure Linux runs fine ;->)
The proper fix, which is i think what yo
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 listen
"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
>do
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 -
ares <[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
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 thi
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 on
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
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 be
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(), j
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? Tha
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
[EMAIL PROTECTED], Martin Mares <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]>
Subject: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource
collisions (fwd)
Ted,
Please add this to your list. Linux is unusable in these machines.
I have cc'ed Martin and
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
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 an
[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.
> Foolha
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
[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 co
> 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 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 t
} 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
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
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_
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 desir
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
}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.
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 yo
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
}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 co
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
> 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
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,
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
> > 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
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
>
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, whi
> - 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
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 strai
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.
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,
> 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 k
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 d
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
Ted,
Please add this to your list. Linux is unusable in these machines.
I have cc'ed Martin and Linus because they play in that PCI area.
cheers,
jamal
-- Forwarded message --
Date: Thu, 5 Oct 2000 17:23:13 -0400 (EDT)
From: jamal <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subje
49 matches
Mail list logo
