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
Hi Jeff!
First, some definitions:
downstream - away from the host processor
primary - number of the PCI bus closer to the host processor
secondary - number of the PCI bus on the downstream side of the PCI
bridge
subordinate - number of the highest-numbered bus on the downstream side
of
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... */
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
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
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
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
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
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
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
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
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]
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 -
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
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 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
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(),
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?
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
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
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
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
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
I am attaching the debug output on bootup after defining DEBUG in pci.c
and the i386 pci header file with test10-pre2
Note: this is a Dell Lattitude docking station. The devices which are
having resource problems are on the docking station. Works fine with 2.2
kernels.
Yes, this is on RH7 with
[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
I am attaching the debug output on bootup after defining DEBUG in pci.c
and the i386 pci header file with test10-pre2
Note: this is a Dell Lattitude docking station. The devices which are
having resource problems are on the docking station. Works fine with 2.2
kernels.
Yes, this is on RH7 with
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
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,
> - 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
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.
>
>
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
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 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
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
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 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 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
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
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]
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
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
45 matches
Mail list logo
