Hello!
> 0x44 is the primary bus number of the host bridge, and 0x45 is the
> subordinate bus number for the bridge. Just like a PCI-PCI bridge, but
> different :) Since there are two CNB30 functions, each has unique values
> for this. The primary bus of the second bridge must be the
Hello!
0x44 is the primary bus number of the host bridge, and 0x45 is the
subordinate bus number for the bridge. Just like a PCI-PCI bridge, but
different :) Since there are two CNB30 functions, each has unique values
for this. The primary bus of the second bridge must be the subordinate
On Wed Jan 17, 2001 at 09:52:21 +0100, Martin Mares wrote:
> Hello!
>
> > The patch below (against vanilla 2.4.0) makes Linux recognize
> > PCI-Devices sitting in another PCI bus than 0 (or 1).
> >
> > This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
>
> I don't have the
On Wed Jan 17, 2001 at 09:52:21 +0100, Martin Mares wrote:
Hello!
The patch below (against vanilla 2.4.0) makes Linux recognize
PCI-Devices sitting in another PCI bus than 0 (or 1).
This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
I don't have the ServerWorks
> > patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
> > 0x44 and 0x45 are probably ID's of two primary buses and the code should scan
> > both of them, but not the space between them.
>
0x44 is the primary bus number of the host bridge, and 0x45 is the
patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
0x44 and 0x45 are probably ID's of two primary buses and the code should scan
both of them, but not the space between them.
0x44 is the primary bus number of the host bridge, and 0x45 is the
subordinate bus
On Thu, 18 Jan 2001, Andre Hedrick wrote:
> > Weird. Others somehow are able to provide specs. Documentation for the
> > entire line of Intel chipsets is available, for example.
>
> This because the make chipsets to basically give away to sell processors.
> That should be very obvious, they
On Thu, 18 Jan 2001, Andre Hedrick wrote:
Weird. Others somehow are able to provide specs. Documentation for the
entire line of Intel chipsets is available, for example.
This because the make chipsets to basically give away to sell processors.
That should be very obvious, they they
is now the key now that Revolution is established.
Regards,
Andre Hedrick
Linux ATA Development
-- Forwarded message --
Date: Thu, 18 Jan 2001 14:44:00 -0800
From: Kim
To: Andre Hedrick <[EMAIL PROTECTED]>
Cc:
Subject: RE: [PATCH] PCI-Devices and ServerWorks chipset (fwd)
Andr
On Thu, 18 Jan 2001, Maciej W. Rozycki wrote:
> Weird. Others somehow are able to provide specs. Documentation for the
> entire line of Intel chipsets is available, for example.
This because the make chipsets to basically give away to sell processors.
That should be very obvious, they they
On Thu, 18 Jan 2001, Andre Hedrick wrote:
> I can get any info needed, you just have to define the scope.
Good.
> Then will not can and will not give out details on a generic form.
Weird. Others somehow are able to provide specs. Documentation for the
entire line of Intel chipsets is
On Thu, 18 Jan 2001, Maciej W. Rozycki wrote:
> On Wed, 17 Jan 2001, Dan Hollis wrote:
>
> > They require not only an NDA, but that you also do all development on-site
> > at their santa clara HQ under their direct supervision.
>
> I haven't went that far -- I'm not going to sign any NDA
On Wed, 17 Jan 2001, Dan Hollis wrote:
> They require not only an NDA, but that you also do all development on-site
> at their santa clara HQ under their direct supervision.
I haven't went that far -- I'm not going to sign any NDA anytime soon, so
I haven't asked them for details. I recall
On Wed, 17 Jan 2001, Dan Hollis wrote:
They require not only an NDA, but that you also do all development on-site
at their santa clara HQ under their direct supervision.
I haven't went that far -- I'm not going to sign any NDA anytime soon, so
I haven't asked them for details. I recall
On Thu, 18 Jan 2001, Maciej W. Rozycki wrote:
On Wed, 17 Jan 2001, Dan Hollis wrote:
They require not only an NDA, but that you also do all development on-site
at their santa clara HQ under their direct supervision.
I haven't went that far -- I'm not going to sign any NDA anytime
On Thu, 18 Jan 2001, Andre Hedrick wrote:
I can get any info needed, you just have to define the scope.
Good.
Then will not can and will not give out details on a generic form.
Weird. Others somehow are able to provide specs. Documentation for the
entire line of Intel chipsets is
On Thu, 18 Jan 2001, Maciej W. Rozycki wrote:
Weird. Others somehow are able to provide specs. Documentation for the
entire line of Intel chipsets is available, for example.
This because the make chipsets to basically give away to sell processors.
That should be very obvious, they they
is now the key now that Revolution is established.
Regards,
Andre Hedrick
Linux ATA Development
-- Forwarded message --
Date: Thu, 18 Jan 2001 14:44:00 -0800
From: Kim snip
To: Andre Hedrick [EMAIL PROTECTED]
Cc: snip
Subject: RE: [PATCH] PCI-Devices and ServerWorks chipset (fwd
On Wed, 17 Jan 2001, Maciej W. Rozycki wrote:
> On Wed, 17 Jan 2001, Martin Mares wrote:
> > I don't have the ServerWorks chipset documentation at hand, but I think your
> > patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
> > 0x44 and 0x45 are probably ID's of two
On Wed, 17 Jan 2001, Martin Mares wrote:
> I don't have the ServerWorks chipset documentation at hand, but I think your
> patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
> 0x44 and 0x45 are probably ID's of two primary buses and the code should scan
> both of
Hi!
On Wed Jan 17, 2001 at 09:52:21 +0100, Martin Mares wrote:
> > The patch below (against vanilla 2.4.0) makes Linux recognize
> > PCI-Devices sitting in another PCI bus than 0 (or 1).
> >
> > This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
>
> I don't have the
Hello!
> The patch below (against vanilla 2.4.0) makes Linux recognize
> PCI-Devices sitting in another PCI bus than 0 (or 1).
>
> This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
I don't have the ServerWorks chipset documentation at hand, but I think your
patch is wrong
Hello!
The patch below (against vanilla 2.4.0) makes Linux recognize
PCI-Devices sitting in another PCI bus than 0 (or 1).
This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
I don't have the ServerWorks chipset documentation at hand, but I think your
patch is wrong -- it
Hi!
On Wed Jan 17, 2001 at 09:52:21 +0100, Martin Mares wrote:
The patch below (against vanilla 2.4.0) makes Linux recognize
PCI-Devices sitting in another PCI bus than 0 (or 1).
This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
I don't have the ServerWorks
On Wed, 17 Jan 2001, Martin Mares wrote:
I don't have the ServerWorks chipset documentation at hand, but I think your
patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
0x44 and 0x45 are probably ID's of two primary buses and the code should scan
both of them,
On Wed, 17 Jan 2001, Maciej W. Rozycki wrote:
On Wed, 17 Jan 2001, Martin Mares wrote:
I don't have the ServerWorks chipset documentation at hand, but I think your
patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
0x44 and 0x45 are probably ID's of two
The patch below (against vanilla 2.4.0) makes Linux recognize
PCI-Devices sitting in another PCI bus than 0 (or 1).
This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
00:00.0 Host bridge: ServerWorks CNB20HE (rev 21)
00:00.1 Host bridge: ServerWorks CNB20HE (rev 01)
00:00.2
The patch below (against vanilla 2.4.0) makes Linux recognize
PCI-Devices sitting in another PCI bus than 0 (or 1).
This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
00:00.0 Host bridge: ServerWorks CNB20HE (rev 21)
00:00.1 Host bridge: ServerWorks CNB20HE (rev 01)
00:00.2
28 matches
Mail list logo
