Re: [PATCH] PCI-Devices and ServerWorks chipset
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 bus > of the first bridge + 1. PRIMARY(1) = SUBORDINATE(0) + 1; Yes, this holds for the registers, but not for the actual bus numbers in the dump sent by Adam -- it shows primary busses 00 and 02, registers of function 0 say 00--00, of function 1 it's 01--06. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ New PC concept: "plug and pray" - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 bus of the first bridge + 1. PRIMARY(1) = SUBORDINATE(0) + 1; Yes, this holds for the registers, but not for the actual bus numbers in the dump sent by Adam -- it shows primary busses 00 and 02, registers of function 0 say 00--00, of function 1 it's 01--06. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ New PC concept: "plug and pray" - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 chipset documentation at hand, but I think your
> patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
Another possible workaround for my problem is just not to call the
fixup routine for the chipset:
--- pci-pc.c~Thu Jun 22 16:17:16 2000
+++ pci-pc.cTue Jan 23 18:46:55 2001
@@ -927,7 +927,6 @@
struct pci_fixup pcibios_fixups[] = {
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82451NX,
pci_fixup_i450nx },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82454GX,
pci_fixup_i450gx },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_HE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_LE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_CMIC_HE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_6010,
pci_fixup_compaq },
This patch is against 2.4.0-ac10. Having the above line in the PCI devices do
not occur, leaving it out they appear.
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://a.home.dhs.org
-
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: [PATCH] PCI-Devices and ServerWorks chipset
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 chipset documentation at hand, but I think your
patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
Another possible workaround for my problem is just not to call the
fixup routine for the chipset:
--- pci-pc.c~Thu Jun 22 16:17:16 2000
+++ pci-pc.cTue Jan 23 18:46:55 2001
@@ -927,7 +927,6 @@
struct pci_fixup pcibios_fixups[] = {
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82451NX,
pci_fixup_i450nx },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82454GX,
pci_fixup_i450gx },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_HE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_LE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_CMIC_HE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_6010,
pci_fixup_compaq },
This patch is against 2.4.0-ac10. Having the above line in the PCI devices do
not occur, leaving it out they appear.
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://a.home.dhs.org
-
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: [PATCH] PCI-Devices and ServerWorks chipset
> > 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 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 bus of the first bridge + 1. PRIMARY(1) = SUBORDINATE(0) + 1; Tim - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 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 bus of the first bridge + 1. PRIMARY(1) = SUBORDINATE(0) + 1; Tim - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 sell CPU's fpr $100's and sell > chipsets at pennies. Sure, but they make specs for CPUs available as well. So the point is? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 sell CPU's fpr $100's and sell chipsets at pennies. Sure, but they make specs for CPUs available as well. So the point is? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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: [PATCH] PCI-Devices and ServerWorks chipset (fwd)
LKML, Here is Kim's response to the two issues and they are working on it. I removed address, email, phone numbers because it is my decission to do so to protect the positive entry points that I have made to prevent a flame mail box for this guy. Flame me, you will get it back. Evolution 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) Andre, We really appreciate your keeping this in front of us. As you can imagine, support personnel are stretched really thin here. The guy who is the expert on this is out today, and it may be next week before we can get the answers to the questions here. However, from your comments below, it appears that you understand we must defend our IP (the guts of it anyway) and that we must be making good parts that are finding their way into lots of servers. Linux is a keen focus here, as we do see it as the future, both as a platform and as a business model. It is putting pressure on proprietary software makers to clean up their acts. We are also hard at work getting ready for the next generation of Intel servers that will come out later this year. We are working to put the documentation for the open interfaces (e.g. ATA, AGP, SMBus) to our IP up on Linux web sites such as SourceForge so the Linux community can make use of it. Again, we appreciate your patience and hope you and the Linux community can bear with us while we modify our business model to better work with you folks. Kim VP, Business Development -Original Message- From: Andre Hedrick [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 18, 2001 9:58 AM To: Kim Subject: Re: [PATCH] PCI-Devices and ServerWorks chipset (fwd) Second series of questions to be answered. Cheers, Andre Hedrick Linux ATA Development -- Forwarded message -- Date: Thu, 18 Jan 2001 12:08:03 +0100 (MET) From: Maciej W. Rozycki <[EMAIL PROTECTED]> To: Andre Hedrick <[EMAIL PROTECTED]> Cc: Dan Hollis <[EMAIL PROTECTED]>, Martin Mares <[EMAIL PROTECTED]>, Adam Lackorzynski <[EMAIL PROTECTED]>, Kernel Mailing List <[EMAIL PROTECTED]> Subject: Re: [PATCH] PCI-Devices and ServerWorks chipset 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 available, for example. > In short no one person can see the entire design docs or will they get > them without a NDA. I have seen why this is the case, cause the toy are > cool. I don't need design docs -- I need programming specs. > > I was asking for a few I/O APIC details -- apparently there are problems > > with 8254 interoperability and we have to use the awkward through-8259A > > mode for the timer tick. > > Narrow the point. The output of the 8254's timer 0 does not appear to be connected to any I/O APIC input. It is connected to the IR0 line of the master 8259A as usual. The 8254, both 8259As and both I/O APICs are all internal to the chipset. The question is: "Is it possible to use the 8254 timer interrupt natively, i.e. is it possible to reconfigure the chipset to route the interrupt source to any I/O APIC with no 8259A logic in the way?" It's nice we have the through-8259A trick, but I developed it solely as a workaround to support the old Intel 82350 EISA chipset, commonly used for old APIC SMP systems, which did not route IRQ0 externally just because it was designed long before the 82489DX APIC. It just should not be used for modern systems -- it's too fragile. > > And I don't actually care. If they want to lose in the Linux area, it's > > their own choice. > > You don't get it, they OEM board designs for Compaq and Dell. > These guys will work with you on-site but in their sand-box not yours. What don't I get? If Compaq and Dell chose the ServerWorks chipset, then until (unless) docs are available, it's their problem to support Linux on their systems. It's certainly not mine. > I wish I could say more, but I have something more powerfully than any NDA > ever written. I have given my word and a handshake, and that has more > value to me than any stupid NDA. The very fact that I value this so much > and so many in the industry know this about me, I have been shown things > without NDA's that you never see otherwise. Nobody seems to push you to leak information you cannot give for a reason, and certainly neither do I. > They are very friendly to Linux, but can we be friendly to them? I'm neutral at the mome
Re: [PATCH] PCI-Devices and ServerWorks chipset
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 sell CPU's fpr $100's and sell chipsets at pennies. Cheers, Andre Hedrick Linux ATA Development - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 available, for example. > In short no one person can see the entire design docs or will they get > them without a NDA. I have seen why this is the case, cause the toy are > cool. I don't need design docs -- I need programming specs. > > I was asking for a few I/O APIC details -- apparently there are problems > > with 8254 interoperability and we have to use the awkward through-8259A > > mode for the timer tick. > > Narrow the point. The output of the 8254's timer 0 does not appear to be connected to any I/O APIC input. It is connected to the IR0 line of the master 8259A as usual. The 8254, both 8259As and both I/O APICs are all internal to the chipset. The question is: "Is it possible to use the 8254 timer interrupt natively, i.e. is it possible to reconfigure the chipset to route the interrupt source to any I/O APIC with no 8259A logic in the way?" It's nice we have the through-8259A trick, but I developed it solely as a workaround to support the old Intel 82350 EISA chipset, commonly used for old APIC SMP systems, which did not route IRQ0 externally just because it was designed long before the 82489DX APIC. It just should not be used for modern systems -- it's too fragile. > > And I don't actually care. If they want to lose in the Linux area, it's > > their own choice. > > You don't get it, they OEM board designs for Compaq and Dell. > These guys will work with you on-site but in their sand-box not yours. What don't I get? If Compaq and Dell chose the ServerWorks chipset, then until (unless) docs are available, it's their problem to support Linux on their systems. It's certainly not mine. > I wish I could say more, but I have something more powerfully than any NDA > ever written. I have given my word and a handshake, and that has more > value to me than any stupid NDA. The very fact that I value this so much > and so many in the industry know this about me, I have been shown things > without NDA's that you never see otherwise. Nobody seems to push you to leak information you cannot give for a reason, and certainly neither do I. > They are very friendly to Linux, but can we be friendly to them? I'm neutral at the moment. Their friendship appears to be purely declarational at the moment. They do neither provide docs nor answer specific question. I've already asked them the question I quoted above. I got no answer. Neither did the user of the system affected, who contacted them as well. So I'm just sitting and watching the situation. > You just can not barge in and demand to see their IP. I do not demand anything. I'm just not willing to work on problems with hardware the manufacturer refuses to document. Anyone feel free to undertake this task. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 soon, so > I haven't asked them for details. I recall someone writing here it's > restrictive, indeed. > > > The only people who have ever got info out of serverworks are the lm78 > > guys and (i think) andre hedrick. I can get any info needed, you just have to define the scope. Then will not can and will not give out details on a generic form. In short no one person can see the entire design docs or will they get them without a NDA. I have seen why this is the case, cause the toy are cool. > I was asking for a few I/O APIC details -- apparently there are problems > with 8254 interoperability and we have to use the awkward through-8259A > mode for the timer tick. Narrow the point. > > What magic incantations they chanted, or which mafia thugs they hired to > > manage this, I don't know... > > And I don't actually care. If they want to lose in the Linux area, it's > their own choice. You don't get it, they OEM board designs for Compaq and Dell. These guys will work with you on-site but in their sand-box not yours. I wish I could say more, but I have something more powerfully than any NDA ever written. I have given my word and a handshake, and that has more value to me than any stupid NDA. The very fact that I value this so much and so many in the industry know this about me, I have been shown things without NDA's that you never see otherwise. They are very friendly to Linux, but can we be friendly to them? You just can not barge in and demand to see their IP. Regards, Andre Hedrick Linux ATA Development - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 someone writing here it's restrictive, indeed. > The only people who have ever got info out of serverworks are the lm78 > guys and (i think) andre hedrick. I was asking for a few I/O APIC details -- apparently there are problems with 8254 interoperability and we have to use the awkward through-8259A mode for the timer tick. > What magic incantations they chanted, or which mafia thugs they hired to > manage this, I don't know... And I don't actually care. If they want to lose in the Linux area, it's their own choice. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 someone writing here it's restrictive, indeed. The only people who have ever got info out of serverworks are the lm78 guys and (i think) andre hedrick. I was asking for a few I/O APIC details -- apparently there are problems with 8254 interoperability and we have to use the awkward through-8259A mode for the timer tick. What magic incantations they chanted, or which mafia thugs they hired to manage this, I don't know... And I don't actually care. If they want to lose in the Linux area, it's their own choice. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 soon, so I haven't asked them for details. I recall someone writing here it's restrictive, indeed. The only people who have ever got info out of serverworks are the lm78 guys and (i think) andre hedrick. I can get any info needed, you just have to define the scope. Then will not can and will not give out details on a generic form. In short no one person can see the entire design docs or will they get them without a NDA. I have seen why this is the case, cause the toy are cool. I was asking for a few I/O APIC details -- apparently there are problems with 8254 interoperability and we have to use the awkward through-8259A mode for the timer tick. Narrow the point. What magic incantations they chanted, or which mafia thugs they hired to manage this, I don't know... And I don't actually care. If they want to lose in the Linux area, it's their own choice. You don't get it, they OEM board designs for Compaq and Dell. These guys will work with you on-site but in their sand-box not yours. I wish I could say more, but I have something more powerfully than any NDA ever written. I have given my word and a handshake, and that has more value to me than any stupid NDA. The very fact that I value this so much and so many in the industry know this about me, I have been shown things without NDA's that you never see otherwise. They are very friendly to Linux, but can we be friendly to them? You just can not barge in and demand to see their IP. Regards, Andre Hedrick Linux ATA Development - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 available, for example. In short no one person can see the entire design docs or will they get them without a NDA. I have seen why this is the case, cause the toy are cool. I don't need design docs -- I need programming specs. I was asking for a few I/O APIC details -- apparently there are problems with 8254 interoperability and we have to use the awkward through-8259A mode for the timer tick. Narrow the point. The output of the 8254's timer 0 does not appear to be connected to any I/O APIC input. It is connected to the IR0 line of the master 8259A as usual. The 8254, both 8259As and both I/O APICs are all internal to the chipset. The question is: "Is it possible to use the 8254 timer interrupt natively, i.e. is it possible to reconfigure the chipset to route the interrupt source to any I/O APIC with no 8259A logic in the way?" It's nice we have the through-8259A trick, but I developed it solely as a workaround to support the old Intel 82350 EISA chipset, commonly used for old APIC SMP systems, which did not route IRQ0 externally just because it was designed long before the 82489DX APIC. It just should not be used for modern systems -- it's too fragile. And I don't actually care. If they want to lose in the Linux area, it's their own choice. You don't get it, they OEM board designs for Compaq and Dell. These guys will work with you on-site but in their sand-box not yours. What don't I get? If Compaq and Dell chose the ServerWorks chipset, then until (unless) docs are available, it's their problem to support Linux on their systems. It's certainly not mine. I wish I could say more, but I have something more powerfully than any NDA ever written. I have given my word and a handshake, and that has more value to me than any stupid NDA. The very fact that I value this so much and so many in the industry know this about me, I have been shown things without NDA's that you never see otherwise. Nobody seems to push you to leak information you cannot give for a reason, and certainly neither do I. They are very friendly to Linux, but can we be friendly to them? I'm neutral at the moment. Their friendship appears to be purely declarational at the moment. They do neither provide docs nor answer specific question. I've already asked them the question I quoted above. I got no answer. Neither did the user of the system affected, who contacted them as well. So I'm just sitting and watching the situation. You just can not barge in and demand to see their IP. I do not demand anything. I'm just not willing to work on problems with hardware the manufacturer refuses to document. Anyone feel free to undertake this task. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 sell CPU's fpr $100's and sell chipsets at pennies. Cheers, Andre Hedrick Linux ATA Development - 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: [PATCH] PCI-Devices and ServerWorks chipset (fwd)
LKML, Here is Kim's response to the two issues and they are working on it. I removed address, email, phone numbers because it is my decission to do so to protect the positive entry points that I have made to prevent a flame mail box for this guy. Flame me, you will get it back. Evolution 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) Andre, We really appreciate your keeping this in front of us. As you can imagine, support personnel are stretched really thin here. The guy who is the expert on this is out today, and it may be next week before we can get the answers to the questions here. However, from your comments below, it appears that you understand we must defend our IP (the guts of it anyway) and that we must be making good parts that are finding their way into lots of servers. Linux is a keen focus here, as we do see it as the future, both as a platform and as a business model. It is putting pressure on proprietary software makers to clean up their acts. We are also hard at work getting ready for the next generation of Intel servers that will come out later this year. We are working to put the documentation for the open interfaces (e.g. ATA, AGP, SMBus) to our IP up on Linux web sites such as SourceForge so the Linux community can make use of it. Again, we appreciate your patience and hope you and the Linux community can bear with us while we modify our business model to better work with you folks. Kim VP, Business Development snip snip snip -Original Message- From: Andre Hedrick [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 18, 2001 9:58 AM To: Kim snip Subject: Re: [PATCH] PCI-Devices and ServerWorks chipset (fwd) Second series of questions to be answered. Cheers, Andre Hedrick Linux ATA Development -- Forwarded message -- Date: Thu, 18 Jan 2001 12:08:03 +0100 (MET) From: Maciej W. Rozycki [EMAIL PROTECTED] To: Andre Hedrick [EMAIL PROTECTED] Cc: Dan Hollis [EMAIL PROTECTED], Martin Mares [EMAIL PROTECTED], Adam Lackorzynski [EMAIL PROTECTED], Kernel Mailing List [EMAIL PROTECTED] Subject: Re: [PATCH] PCI-Devices and ServerWorks chipset 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 available, for example. In short no one person can see the entire design docs or will they get them without a NDA. I have seen why this is the case, cause the toy are cool. I don't need design docs -- I need programming specs. I was asking for a few I/O APIC details -- apparently there are problems with 8254 interoperability and we have to use the awkward through-8259A mode for the timer tick. Narrow the point. The output of the 8254's timer 0 does not appear to be connected to any I/O APIC input. It is connected to the IR0 line of the master 8259A as usual. The 8254, both 8259As and both I/O APICs are all internal to the chipset. The question is: "Is it possible to use the 8254 timer interrupt natively, i.e. is it possible to reconfigure the chipset to route the interrupt source to any I/O APIC with no 8259A logic in the way?" It's nice we have the through-8259A trick, but I developed it solely as a workaround to support the old Intel 82350 EISA chipset, commonly used for old APIC SMP systems, which did not route IRQ0 externally just because it was designed long before the 82489DX APIC. It just should not be used for modern systems -- it's too fragile. And I don't actually care. If they want to lose in the Linux area, it's their own choice. You don't get it, they OEM board designs for Compaq and Dell. These guys will work with you on-site but in their sand-box not yours. What don't I get? If Compaq and Dell chose the ServerWorks chipset, then until (unless) docs are available, it's their problem to support Linux on their systems. It's certainly not mine. I wish I could say more, but I have something more powerfully than any NDA ever written. I have given my word and a handshake, and that has more value to me than any stupid NDA. The very fact that I value this so much and so many in the industry know this about me, I have been shown things without NDA's that you never see otherwise. Nobody seems to push you to leak information you cannot give for a reason, and certainly neither do I. They are very friendly to Linux, but can we be friendly to them? I'm neutral at the moment. Their friendship appears to be purely declarational at the moment. They do neither provide docs nor answer specific question. I've alr
Re: [PATCH] PCI-Devices and ServerWorks chipset
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 primary buses and the code should scan > > both of them, but not the space between them. > Does anyone beside the manufacturer have these docs at all? Last time I > contacted them, they required an NDA, even though they weren't actually > Linux-hostile. They require not only an NDA, but that you also do all development on-site at their santa clara HQ under their direct supervision. The only people who have ever got info out of serverworks are the lm78 guys and (i think) andre hedrick. What magic incantations they chanted, or which mafia thugs they hired to manage this, I don't know... -Dan - 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: [PATCH] PCI-Devices and ServerWorks chipset
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, but not the space between them. Does anyone beside the manufacturer have these docs at all? Last time I contacted them, they required an NDA, even though they weren't actually Linux-hostile. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 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, but not the space between them. I was just inspired by the comment in this function and knew that this "patch" was probably wrong but it was enough to get someone else' eyes watching on it ... :-) BTW, one line of dmesg says: PCI: PCI BIOS revision 2.10 entry at 0xfd5cc, last bus=6 So that "6" in 0x45 made some sense to me... > Anyway, could you send me a `lspci -MH1 -vvx' and `lspci -vvxxx -s0:0', please? $ lspci -MH1 -vvx 00:00.0 Host bridge: ServerWorks CNB20HE (rev 21) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://a.home.dhs.org - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 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. Anyway, could you send me a `lspci -MH1 -vvx' and `lspci -vvxxx -s0:0', please? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ System going down at 5 pm to install scheduler bug. - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 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. Anyway, could you send me a `lspci -MH1 -vvx' and `lspci -vvxxx -s0:0', please? Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ System going down at 5 pm to install scheduler bug. - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 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, but not the space between them. I was just inspired by the comment in this function and knew that this "patch" was probably wrong but it was enough to get someone else' eyes watching on it ... :-) BTW, one line of dmesg says: PCI: PCI BIOS revision 2.10 entry at 0xfd5cc, last bus=6 So that "6" in 0x45 made some sense to me... Anyway, could you send me a `lspci -MH1 -vvx' and `lspci -vvxxx -s0:0', please? $ lspci -MH1 -vvx 00:00.0 Host bridge: ServerWorks CNB20HE (rev 21) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- 00: 66 11 08 00 00 00 00 00 21 00 00 06 08 60 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:00.1 Host bridge: ServerWorks CNB20HE (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- Latency: 96, cache line size 08 00: 66 11 08 00 47 01 00 22 01 00 00 06 08 60 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:00.2 Host bridge: ServerWorks: Unknown device 0006 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- 00: 66 11 06 00 42 01 00 22 00 00 00 06 08 60 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:00.3 Host bridge: ServerWorks: Unknown device 0006 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- 00: 66 11 06 00 42 01 00 22 00 00 00 06 08 60 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:01.0 SCSI storage controller: Adaptec 7896 Subsystem: Adaptec: Unknown device 080f Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 100 (9750ns min, 6250ns max), cache line size 08 Interrupt: pin A routed to IRQ 10 BIST result: 00 Region 0: I/O ports at 2000 Region 1: Memory at febff000 (64-bit, non-prefetchable) Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 05 90 5f 00 07 00 90 02 00 00 00 01 08 64 80 80 10: 01 20 00 00 04 f0 bf fe 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 05 90 0f 08 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 27 19 00:01.1 SCSI storage controller: Adaptec 7896 Subsystem: Adaptec: Unknown device 080f Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 100 (9750ns min, 6250ns max), cache line size 08 Interrupt: pin A routed to IRQ 10 BIST result: 00 Region 0: I/O ports at 2100 Region 1: Memory at febfe000 (64-bit, non-prefetchable) Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 05 90 5f 00 07 00 90 02 00 00 00 01 08 64 80 80 10: 01 21 00 00 04 e0 bf fe 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 05 90 0f 08 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 27 19 00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44) Subsystem: IBM: Unknown device 2000 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF-
Re: [PATCH] PCI-Devices and ServerWorks chipset
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, but not the space between them. Does anyone beside the manufacturer have these docs at all? Last time I contacted them, they required an NDA, even though they weren't actually Linux-hostile. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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: [PATCH] PCI-Devices and ServerWorks chipset
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 primary buses and the code should scan both of them, but not the space between them. Does anyone beside the manufacturer have these docs at all? Last time I contacted them, they required an NDA, even though they weren't actually Linux-hostile. They require not only an NDA, but that you also do all development on-site at their santa clara HQ under their direct supervision. The only people who have ever got info out of serverworks are the lm78 guys and (i think) andre hedrick. What magic incantations they chanted, or which mafia thugs they hired to manage this, I don't know... -Dan - 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/
