linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Tighten up serverworks workaround.
@ 2003-02-26 13:49 davej
  2003-02-26 16:27 ` Alan Cox
  0 siblings, 1 reply; 13+ messages in thread
From: davej @ 2003-02-26 13:49 UTC (permalink / raw)
  To: torvalds, alan; +Cc: linux-kernel

Aparently on rev6 of the LE and above, this workaround
isn't needed. Lets give it a try, and see what happens.

    Dave

diff -urpN --exclude-from=/home/davej/.exclude bk-linus/arch/i386/kernel/cpu/mtrr/main.c linux-2.5/arch/i386/kernel/cpu/mtrr/main.c
--- bk-linus/arch/i386/kernel/cpu/mtrr/main.c	2003-02-25 13:10:08.000000000 -0100
+++ linux-2.5/arch/i386/kernel/cpu/mtrr/main.c	2003-02-24 16:36:06.000000000 -0100
@@ -75,20 +75,24 @@ void set_mtrr_ops(struct mtrr_ops * ops)
 static int have_wrcomb(void)
 {
 	struct pci_dev *dev = NULL;
-
-	/* WTF is this?
-	 * Someone, please shoot me.
-	 */
-
-	/* ServerWorks LE chipsets have problems with write-combining 
-	   Don't allow it and leave room for other chipsets to be tagged */
+	u8 rev;
 
 	if ((dev = pci_find_class(PCI_CLASS_BRIDGE_HOST << 8, NULL)) != NULL) {
 		if ((dev->vendor == PCI_VENDOR_ID_SERVERWORKS) &&
 		    (dev->device == PCI_DEVICE_ID_SERVERWORKS_LE)) {
-			printk(KERN_INFO
-			       "mtrr: Serverworks LE detected. Write-combining disabled.\n");
-			return 0;
+
+			/* ServerWorks LE chipsets have problems with write-combining 
+			   Don't allow it and leave room for other chipsets to be tagged.
+			   Rumour has it that rev6 and above are ok. */
+			pci_read_config_byte(dev, PCI_CLASS_REVISION, &rev);  
+			if (rev > 5) {
+				printk ("mtrr: Serverworks LE rev %d detected. Earlier versions of this chipset had mtrr bugs\n", rev);
+				printk ("mtrr: Please send mail to linux-kernel@vger.kernel.org if this seems stable.\n");
+				return 1;
+			} else {
+				printk(KERN_INFO "mtrr: Serverworks LE detected. Write-combining disabled.\n");
+				return 0;
+			}
 		}
 	}
 	return (mtrr_if->have_wrcomb ? mtrr_if->have_wrcomb() : 0);

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Tighten up serverworks workaround.
  2003-02-26 13:49 Tighten up serverworks workaround davej
@ 2003-02-26 16:27 ` Alan Cox
  2003-02-26 16:29   ` Dave Jones
  0 siblings, 1 reply; 13+ messages in thread
From: Alan Cox @ 2003-02-26 16:27 UTC (permalink / raw)
  To: davej; +Cc: torvalds, alan, linux-kernel

> Aparently on rev6 of the LE and above, this workaround
> isn't needed. Lets give it a try, and see what happens

Only if serverworks confirm the rumour. This is a corruptor.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Tighten up serverworks workaround.
  2003-02-26 16:27 ` Alan Cox
@ 2003-02-26 16:29   ` Dave Jones
  2003-02-26 16:36     ` Alan Cox
  0 siblings, 1 reply; 13+ messages in thread
From: Dave Jones @ 2003-02-26 16:29 UTC (permalink / raw)
  To: Alan Cox; +Cc: torvalds, linux-kernel

On Wed, Feb 26, 2003 at 11:27:14AM -0500, Alan Cox wrote:
 > > Aparently on rev6 of the LE and above, this workaround
 > > isn't needed. Lets give it a try, and see what happens
 > 
 > Only if serverworks confirm the rumour. This is a corruptor.

I've reports of people with rev6's who have reported success
with that workaround commented out.  Could be they never
pushed the machine hard enough to trigger a bug, but I'd
have thought this breakage would show up pretty quickly.

My attempts to contact serverworks in the past have fallen on
deaf ears. maybe you have better luck ?

        Dave


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Tighten up serverworks workaround.
  2003-02-26 16:29   ` Dave Jones
@ 2003-02-26 16:36     ` Alan Cox
  2003-02-26 17:27       ` Kimball Brown
  0 siblings, 1 reply; 13+ messages in thread
From: Alan Cox @ 2003-02-26 16:36 UTC (permalink / raw)
  To: Dave Jones; +Cc: Alan Cox, torvalds, linux-kernel

> I've reports of people with rev6's who have reported success
> with that workaround commented out.  Could be they never
> pushed the machine hard enough to trigger a bug, but I'd
> have thought this breakage would show up pretty quickly.

It doesn't. It requires the right patterns and took Dell quite
some time to identify and pin down. If its like the 450NX one
which I suspect it is then you have to have pending misordered
stores to a write gathering target evicted by another read.

> My attempts to contact serverworks in the past have fallen on
> deaf ears. maybe you have better luck ?

I'll try. I got on ok with them for the OSB4 stuff but thats
a long time ago and they've been eaten since then

[Bcc'd to the person I suspect is the right starting point]

Alan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: Tighten up serverworks workaround.
  2003-02-26 16:36     ` Alan Cox
@ 2003-02-26 17:27       ` Kimball Brown
  2003-02-26 18:03         ` Alan Cox
  0 siblings, 1 reply; 13+ messages in thread
From: Kimball Brown @ 2003-02-26 17:27 UTC (permalink / raw)
  To: Alan Cox, davej; +Cc: torvalds, linux-kernel

How can e help?  Please give me a configuration and how the bug manifests
inself.

Kim Brown
VP, Business Development
kimball@serverworks.com
2451 Mission College Blvd
Santa Clara, CA 95054
(408)922-3174
(408)799-3500 (Mobile)
(408)922-3192 (FAX)

-----Original Message-----
From: Alan Cox [mailto:alan@redhat.com]
Sent: Wednesday, February 26, 2003 8:36 AM
To: davej@codemonkey.org.uk
Cc: alan@redhat.com; torvalds@transmeta.com; linux-kernel@vger.kernel.org
Subject: Re: Tighten up serverworks workaround.

> I've reports of people with rev6's who have reported success
> with that workaround commented out.  Could be they never
> pushed the machine hard enough to trigger a bug, but I'd
> have thought this breakage would show up pretty quickly.

It doesn't. It requires the right patterns and took Dell quite
some time to identify and pin down. If its like the 450NX one
which I suspect it is then you have to have pending misordered
stores to a write gathering target evicted by another read.

> My attempts to contact serverworks in the past have fallen on
> deaf ears. maybe you have better luck ?

I'll try. I got on ok with them for the OSB4 stuff but thats
a long time ago and they've been eaten since then

[Bcc'd to the person I suspect is the right starting point]

Alan



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Tighten up serverworks workaround.
  2003-02-26 17:27       ` Kimball Brown
@ 2003-02-26 18:03         ` Alan Cox
  2003-02-26 18:47           ` Jonathan Lundell
                             ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Alan Cox @ 2003-02-26 18:03 UTC (permalink / raw)
  To: Kimball Brown; +Cc: Alan Cox, davej, torvalds, linux-kernel

> How can e help?  Please give me a configuration and how the bug manifests
> inself.

OSB4 chipset system, some memory areas marked write combining with the
processor memory type range registers. A long time ago Dell (I
think) reported corruption from this and submitted changes to block the
use of write combining on OSB4. The question has arisen as to whether
thats a known thing, and if so which release of the chipset fixed it so that
people can only apply such a restriction to problem cases not all OSB4.

Alan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Tighten up serverworks workaround.
  2003-02-26 18:03         ` Alan Cox
@ 2003-02-26 18:47           ` Jonathan Lundell
  2003-02-27 12:14             ` Ingo Oeser
  2003-03-03  9:03           ` Mike A. Harris
  2003-03-03 10:45           ` Stephan von Krawczynski
  2 siblings, 1 reply; 13+ messages in thread
From: Jonathan Lundell @ 2003-02-26 18:47 UTC (permalink / raw)
  To: Alan Cox, Kimball Brown; +Cc: Alan Cox, davej, torvalds, linux-kernel

At 1:03pm -0500 2/26/03, Alan Cox wrote:
>  > How can e help?  Please give me a configuration and how the bug manifests
>>  inself.
>
>OSB4 chipset system, some memory areas marked write combining with the
>processor memory type range registers. A long time ago Dell (I
>think) reported corruption from this and submitted changes to block the
>use of write combining on OSB4. The question has arisen as to whether
>thats a known thing, and if so which release of the chipset fixed it so that
>people can only apply such a restriction to problem cases not all OSB4.

Presumably we're talking about CNB30 (the north bridge) rather than 
OSB4 (the south bridge).
-- 
/Jonathan Lundell.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Tighten up serverworks workaround.
  2003-02-26 18:47           ` Jonathan Lundell
@ 2003-02-27 12:14             ` Ingo Oeser
  0 siblings, 0 replies; 13+ messages in thread
From: Ingo Oeser @ 2003-02-27 12:14 UTC (permalink / raw)
  To: Jonathan Lundell; +Cc: Alan Cox, Kimball Brown, davej, torvalds, linux-kernel

Hello there,

On Wed, Feb 26, 2003 at 10:47:52AM -0800, Jonathan Lundell wrote:
> At 1:03pm -0500 2/26/03, Alan Cox wrote:
> >  > How can e help?  Please give me a configuration and how the bug manifests
> >>  inself.
> >
> >OSB4 chipset system, some memory areas marked write combining with the
> >processor memory type range registers. A long time ago Dell (I
> >think) reported corruption from this and submitted changes to block the
> >use of write combining on OSB4. The question has arisen as to whether
> >thats a known thing, and if so which release of the chipset fixed it so that
> >people can only apply such a restriction to problem cases not all OSB4.
> 
> Presumably we're talking about CNB30 (the north bridge) rather than 
> OSB4 (the south bridge).

No it's about CNB20LE. I'm one of the low performance victims.
And this is an ASUS board (CUR-DLS) (which proved not worth its
prices recently).

Regards

Ingo Oeser
-- 
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Tighten up serverworks workaround.
  2003-02-26 18:03         ` Alan Cox
  2003-02-26 18:47           ` Jonathan Lundell
@ 2003-03-03  9:03           ` Mike A. Harris
  2003-03-03 10:45           ` Stephan von Krawczynski
  2 siblings, 0 replies; 13+ messages in thread
From: Mike A. Harris @ 2003-03-03  9:03 UTC (permalink / raw)
  To: Alan Cox; +Cc: Kimball Brown, davej, torvalds, linux-kernel

On Wed, 26 Feb 2003, Alan Cox wrote:

>> How can e help?  Please give me a configuration and how the bug manifests
>> inself.
>
>OSB4 chipset system, some memory areas marked write combining with the
>processor memory type range registers. A long time ago Dell (I
>think) reported corruption from this and submitted changes to block the
>use of write combining on OSB4. The question has arisen as to whether
>thats a known thing, and if so which release of the chipset fixed it so that
>people can only apply such a restriction to problem cases not all OSB4.

I've got 2 OSB4 machines here, one a Tyan HEsl 2567 board. MTRRs 
have been disabled on this board for a couple years now with 
every kernel release, which I'm told is due to the MTRR problem 
described in this thread.

00:00.1 PCI bridge: ServerWorks CNB20LE (rev 01)

Kimball, we chatted before about AGP on this board and a few
other issues, but I don't know if we discussed the MTRR issue.  
Could you confirm this problem?  If the problem is anything
workaroundable, it would be nice to have MTRRs working on this
box sometime as video is quite slow.  I'm willing to test any 
potential workarounds if something creeps up.

TIA



-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Tighten up serverworks workaround.
  2003-02-26 18:03         ` Alan Cox
  2003-02-26 18:47           ` Jonathan Lundell
  2003-03-03  9:03           ` Mike A. Harris
@ 2003-03-03 10:45           ` Stephan von Krawczynski
  2003-03-03 12:02             ` Alan Cox
  2 siblings, 1 reply; 13+ messages in thread
From: Stephan von Krawczynski @ 2003-03-03 10:45 UTC (permalink / raw)
  To: Alan Cox; +Cc: kimball, alan, davej, torvalds, linux-kernel

On Wed, 26 Feb 2003 13:03:10 -0500 (EST)
Alan Cox <alan@redhat.com> wrote:

> > How can e help?  Please give me a configuration and how the bug manifests
> > inself.
> 
> OSB4 chipset system, some memory areas marked write combining with the
> processor memory type range registers. A long time ago Dell (I
> think) reported corruption from this and submitted changes to block the
> use of write combining on OSB4. The question has arisen as to whether
> thats a known thing, and if so which release of the chipset fixed it so that
> people can only apply such a restriction to problem cases not all OSB4.
> 
> Alan

While we are at the topic. What exactly is this:

00:00.2 Host bridge: ServerWorks: Unknown device 0006 (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-

00:00.3 Host bridge: ServerWorks: Unknown device 0006 (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-

00:0f.3 Host bridge: ServerWorks: Unknown device 0225
        Subsystem: ServerWorks: Unknown device 0230  
        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: 0

Taken from an Asus TRL-DLS.

-- 
Regards,
Stephan


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Tighten up serverworks workaround.
  2003-03-03 10:45           ` Stephan von Krawczynski
@ 2003-03-03 12:02             ` Alan Cox
  2003-03-03 12:46               ` Stephan von Krawczynski
  0 siblings, 1 reply; 13+ messages in thread
From: Alan Cox @ 2003-03-03 12:02 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: linux-kernel

You might want to take Kimball out of unrelated followups

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Tighten up serverworks workaround.
  2003-03-03 12:02             ` Alan Cox
@ 2003-03-03 12:46               ` Stephan von Krawczynski
  2003-03-03 14:42                 ` Alan Cox
  0 siblings, 1 reply; 13+ messages in thread
From: Stephan von Krawczynski @ 2003-03-03 12:46 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel

On Mon, 3 Mar 2003 07:02:47 -0500 (EST)
Alan Cox <alan@redhat.com> wrote:

> You might want to take Kimball out of unrelated followups

Hm, I am not all that sure that it is completely unrelated. From my point of
view the "big picture" looks like this:

Coming from a system based on VIA-chipset and working perfectly well, we
changed mb to serverworks based TRL-DLS. From that time we experienced and
discussed here:

- strange mtrr settings (solved)
- interrupt sharing problem ide/tg3 (solved)
- reproducably oops'ing cd mounts (on internal ide, with ide-scsi) (not solved)
- latest news: reproducably cold-booting during tar-backup on _second_ streamer
device (dev/st1) on board-internal adaptec controller.

Please note that basic installation/distribution is the same since the VIA
setup.
We are a bit astonished since we expected serverworks-based hardware to perform
_better_ than VIA...
The email you commented is only a small hint that within -pre5 there are still
declared-unknown parts of the chipset. Based on the theory that they are named
"unknown" because nobody around here knows them, it might have been an adequate
idea to ask someone from serverworks, or not? This is in no way meant offensive.

-- 
Regards,
Stephan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Tighten up serverworks workaround.
  2003-03-03 12:46               ` Stephan von Krawczynski
@ 2003-03-03 14:42                 ` Alan Cox
  0 siblings, 0 replies; 13+ messages in thread
From: Alan Cox @ 2003-03-03 14:42 UTC (permalink / raw)
  To: Stephan von Krawczynski; +Cc: Alan Cox, linux-kernel

> We are a bit astonished since we expected serverworks-based hardware to perform
> _better_ than VIA...

My experience is that in general it does.

> The email you commented is only a small hint that within -pre5 there are still
> declared-unknown parts of the chipset. Based on the theory that they are named
> "unknown" because nobody around here knows them, it might have been an adequate
> idea to ask someone from serverworks, or not? This is in no way meant offensive.

Sure, but lets not give senior folks at Serverworks a full blast of l/k.
Its better to sumarise the issues. In some cases vendors do have docs,
so the unknown device ids missing from lspci for example can be dealt with
outside already

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2003-03-03 14:32 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-26 13:49 Tighten up serverworks workaround davej
2003-02-26 16:27 ` Alan Cox
2003-02-26 16:29   ` Dave Jones
2003-02-26 16:36     ` Alan Cox
2003-02-26 17:27       ` Kimball Brown
2003-02-26 18:03         ` Alan Cox
2003-02-26 18:47           ` Jonathan Lundell
2003-02-27 12:14             ` Ingo Oeser
2003-03-03  9:03           ` Mike A. Harris
2003-03-03 10:45           ` Stephan von Krawczynski
2003-03-03 12:02             ` Alan Cox
2003-03-03 12:46               ` Stephan von Krawczynski
2003-03-03 14:42                 ` Alan Cox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).