linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Athlon bug stomping #2
@ 2001-09-13 12:31 VDA
  2001-09-14  2:56 ` Roberto Jung Drebes
  0 siblings, 1 reply; 38+ messages in thread
From: VDA @ 2001-09-13 12:31 UTC (permalink / raw)
  To: linux-kernel

Hi,

It seems there is some misunderstanding about my previous post.
Further reports aren't very much needed now.
( If you insist, send them to me not to lkml.
  Include lspci -vvvxxx dump from *both* good and bad BIOS.
  Booting with K7 optimized kernel is not needed)

It is time to fiddle with chipset config registers.
We need volunteers to do the testing.
I don't have the hardware.

Meanwhile, I figured out where fix should go:
to arch/i386/kernel/pci-pc.c

This is an example (see below how to modify):
=========================================================
--- pci-pc.c    Fri Apr 20 03:57:06 2001
+++ new-pci-pc.c        Thu Sep 13 14:13:25 2001
@@ -987,6 +987,15 @@
        }
 }
 
+static void __init pci_fixup_athlon_bug(struct pci_dev *d)
+{
+       printk("Trying to stomp on Athlon bug...\n");
+       u8 v;
+       pci_read_config_byte(d, 0x52, &v);
+       v |= 0x80; /* set 52.7: Disconnect Enable When STPGNT Detected */
+       pci_write_config_byte(d, 0x52, v);
+}
+
 
 struct pci_fixup pcibios_fixups[] = {
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_82451NX,    pci_fixup_i450nx },
@@ -1010,6 +1019,7 @@
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      PCI_DEVICE_ID_VIA_82C686_4,     pci_fixup_via_acpi },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      PCI_DEVICE_ID_VIA_82C691,       pci_fixup_via691 },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      PCI_DEVICE_ID_VIA_82C598_1,     pci_fixup_via691_2 },
+       { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      PCI_DEVICE_ID_VIA_8363_0,       pci_fixup_athlon_bug },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_82371AB_3,  pci_fixup_piix4_acpi },
        { 0 }
 };
====================================================
There's no point in modifying registers which are known
to work fine, so use info below to figure out which
registers can be responsible for the bug and
modify them in pci_fixup_athlon_bug().
Then compile K7 optimized kernel with this fix
and give it a try. Try again with next register
until you find which one is guilty.

Okay, this is a heavily modified printouts of
1) lspci -vvvxxx made on VIA KT133A based mainboard
   with BIOS version 3R flashed in (this system is
   exhibiting Athlon bug)
2) and on the same system with BIOS version YH
   (which do not trigger bug).
   
Each chipset config register which is changed between these two BIOSes
is underlined with carets "^" with programming details immediately
below.
Each suspicious register is then commented with:
*** 3R BIOS: settings made by 3R BIOS
*** YH BIOS: settings made by YH BIOS
*** TODO: is this relevant and what to do
========================================================
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev
03)
        Subsystem: ABIT Computer Corp.: Unknown device a401
                
YH 00: 06 11 05 03 06 00 10 22 03 00 00 06 00 00 00 00
3R 00: 06 11 05 03 06 00 10 22 03 00 00 06 00 08 00 00
                                              ^^
Device 0 Offset D - Latency Timer (00h)(RW)
Specifies the latency timer value in PCI bus clocks.
7-3 Guaranteed Time Slice for CPU. default=0
2-0 Reserved (fixed granularity of 8 clks). always read 0
    Bits 2-1 are writeable but read 0 for PCI specification
    compatibility. The programmed value may be read
    back in Offset 75 bits 5-4 (PCI Arbitration 1).
*** 3R BIOS: bits 7-3=00001
*** YH BIOS: bits 7-3=00000
*** TODO: probably does not matter

YH 10: 08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00
3R 10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00
       ^^^^^^^^^^^
Device 0 Offset 13-10 - Graphics Aperture Base
    (00000008h) (RW)
31-28 Upper Programmable Base Address Bits. default=0
27-20 Lower Programmable Base Address Bits. default=0
    These bits behave as if hardwired to 0 if the
    corresponding Graphics Aperture Size register bit
    (Device 0 Offset 84h) is 0.
    27 26 25 24 23 22 21 20 (This Register)
     7  6  5  4  3  2  1  0 (Gr Aper Size)
    RW RW RW RW RW RW RW RW 1M
    RW RW RW RW RW RW RW  0 2M
    RW RW RW RW RW RW  0  0 4M
    RW RW RW RW RW  0  0  0 8M
    RW RW RW RW  0  0  0  0 16M
    RW RW RW  0  0  0  0  0 32M
    RW RW  0  0  0  0  0  0 64M
    RW  0  0  0  0  0  0  0 128M
     0  0  0  0  0  0  0  0 256M
19-0 Reserved. always reads 00008
    Note: The locations in the address range defined by this
    register are prefetchable.

*** 3R BIOS: addr: E0000000
*** YH BIOS: addr: D0000000
*** TODO: probably does not matter

YH 50: 16 f4 eb
3R 50: 16 f4 6b
             ^^
Device 0 Offset 52 - S2K Timing Control III..................RW
    The contents of this register are preserved during suspend.
    Bits 2-0 have no default value.
7 Disconnect Enable When STPGNT Detected
6 Write to Read Delay. default = 1
5-4 Read to Write Delay. default = 11b
3 1ns Skew Between Even / Odd Clock Group For Data (Strapped
  from MAB3)
    0 Disable (default if no strap on MAB3)
    1 Enable
2-0 Write Data Delay from SYSDC to CPU Data
  Output (WrDataDly)
*** 3R BIOS: bit 7=0
*** YH BIOS: bit 7=1 
*** TODO: try to set bit 7 to 1.

YH 50: .. .. .. b4 06
3R 50: .. .. .. b4 47
                   ^^
Device 0 Offset 54 - BIU Control (RW)
7 SDRAM Self-Refresh When Disconnected
    0 Disable (default)  1 Enable
6 Probe Next Tag State T1 When PCI Master Read
 Cacheing Enabled
    0 Disable (default)  1 Enable
5 S2K Data Input Buffer
    0 Disable (default
)  1 Enable
4 S2K Data Output Enable Timing
    0 1T Setup / Hold (default)  1 1/2T Setup / Hold
3 DRAM Speculative Read for PCI Master Read
 (Before Probe Result is Known)
    0 Disable (default)  1 Enable
2 PCI Master Pipeline Request
    0 Disable (default)  1 Enable
1 PCI-to-CPU / CPU-to-PCI (P2C / C2P)
 Concurrency
    0 Disable (default)  1 Enable
0 Fast Write-to-Read Turnaround
    0 Disable (default)  1 Enable
*** 3R BIOS: enabled 6,2,1,0 bits only.
*** YH BIOS: enabled   2,1   bits only.
*** TODO: try disabling bits 6,0.
    bit 0 is most interesting. Try it first.
    
YH 50: .. .. .. .. .. 00 04 04 00 00 01 02 03 04 04 04
3R 50: .. .. .. .. .. 89 04 04 00 00 01 02 03 04 04 04
                      ^^
Device 0 Offset 55 - Debug (RW)
7-0 Reserved (do not program). default = 0
*** 3R BIOS: non-zero!?
*** YH BIOS: zero.
*** TODO: try to set to 0.

YH 60: 0f 0a 00 20 e4 e4 d4 c4 50 28 65 0d 08 5f 00 00
3R 60: 0f 0a 00 20 e4 e4 d4 00 50 08 65 0d 08 5f 00 00
                                  ^^
Device 0 Offset 69 - DRAM Clock Select (00h) (RW)
7 Reserved. always reads 0
6 DRAM Operating Frequency Faster Than CPU
    0 DRAM Same As or Equal to CPU (default)
    1 DRAM Faster Than CPU by 33 MHz
    Rx68[0] Rx69[6] CPU / DRAM
          0       0 100 / 100
          0       1 100 / 133
          1       0 133 / 133 (default)
          1       1 -reserved-
5 Write Recovery Time For Write With Auto-Precharge
    0 1T (default)  1 2T
4 DRAM Controller Command Register Output
    0 Disable (default)  1 Enable
3 Fast DRAM Precharge for Different Bank
    0 Disable (default)  1 Enable
2 DRAM 4K Page Enable (for 64Mbit DRAM)
    0 Disable (default)  1 Enable
1 DIMM Type
    0 Unbuffered (default)  1 Registered
0 AutoPrecharge on CPU Writeback / TLB Lookup
    0 Disable (default)  1 Enable
*** 3R BIOS: bit 5 is 0
*** YH BIOS: bit 5 is 1
*** TODO: try setting it back to 1

YH 70: d4 88 cc 0c 0e 81 d2 00 01 b4 19 02 00 00 00 00
3R 70: d8 88 cc 0c 0e 81 d2 00 01 b4 19 02 00 00 00 00
       ^^
Device 0 Offset 70 - PCI Buffer Control (00h) (RW)
7 CPU to PCI Post-Write
    0 Disable (default)  1 Enable
6 PCI Master to DRAM Post-Write
    0 Disable (default)  1 Enable
5 Reserved. always reads 0
4 PCI Master to DRAM Prefetch
    0 Enable (default)  1 Disable
3 Enhance CPU-to-PCI Write
    0 Normal operation (default)
    1 Reduce 1 cycle when the CPU-to-PCI buffer
      becomes available after being full (PCI and AGP buses)
2 PCI Master Read Caching
    0 Disable (default)  1 Enable
1 Delay Transaction
    0 Disable (default)  1 Enable
0 Slave Device Stopped Idle Cycle Reduction
    0 Normal Operation (default)
    1 Reduce 1 PCI idle cycle when stopped by a
      slave device (PCI and AGP buses)
*** 3R BIOS: bit 4=1, 3=0
*** YH BIOS: bit 4=0, 3=1
*** TODO: probably doesn't matter

YH a0: 02 c0 20 00 03 02 00 1f 00 00 00 00 2b 12 00 00
3R a0: 02 c0 20 00 03 02 00 1f 00 00 00 00 2f 12 00 00
                                           ^^
Device 0 Offset AC - AGP Control (00h) (RW)
7 Reserved. always reads 0
6 CPU Stall on AGP Command FIFO GART
 Address Request
    0 Disable (default)  1 Enable
5 AGP Read Snoop DRAM Post-Write Buffer
    0 Disable (default)  1 Enable
4 GREQ# Priority Becomes Higher When Arbiter is
 Parked at AGP Master
    0 Disable (default)  1 Enable
3 2X Rate Supported (read also at RxA4[1])
    0 Not supported (default)  1 Supported
2 LPR In-Order Access (Force Fence)
    0 Fence/Flush functions not guaranteed. AGP
      read requests (low/normal priority and
      high priority) may be executed
      before previously issued write requests
      (default)
    1 Force all requests to be executed in order
      (automatically enables Fence/Flush functions).
      Low (i.e., normal) priority AGP read requests
      will never be executed before previously
      issued writes. High priority AGP read requests
      may still be executed prior to previously issued
      write requests as required.
1 AGP Arbitration Parking
    0 Disable (default)
    1 Enable (GGNT# remains asserted until either
      GREQ# de-asserts or data phase ready)
0 AGP to PCI Master or CPU to PCI Turnaround Cycle
    0 2T or 3T Timing (default)
    1 1T Timing
*** 3R BIOS: bit 2=1
*** YH BIOS: bit 2=0
*** TODO: probably doesn't matter
    
YH b0: db 63 02
3R b0: db 63 1a
             ^^
Device 0 Offset B2 - AGP Pad Drive / Delay Control (RW)
7 GD/GBE/GDS, SBA/SBS Control
  1.5V (Bit-1 = 0)
    0 SBA/SBS = no cap (default)
      GD/GBE/GDS = no cap
    1 SBA/SBS = no cap
      GD/GBE/GDS = cap
  3.3V (Bit-1 = 1)
    0 SBA/SBS = cap (default)
      GD/GBE/GDS = no cap
    1 SBA/SBS = cap
      GD/GBE/GDS = cap
6 Reserved. always reads 0
5 S2K Slew Rate Control. strapped from SRASA#
    0 Enable (default)  1 Disable
4 GD[31-16] Staggered Delay
    0 None (default)  1 GD[31:16] delayed by 1 ns
3 Reserved. always reads 0
2 AGP Preamble Control
    0 Disable (default)  1 Enable
1 AGP Voltage
    0 1.5V (default)  1 3.3V
0 GDS Output Delay
    0 None (default)
    1 GDS[1-0] & GDS[1-0]# delayed by 0.4 ns
      (GDS1 & GDS1# will be delayed an additional
      1ns if bit-4 = 1)
*** 3R BIOS: 1A=00011010
*** YH BIOS: 02=00000010
*** TODO: probably doesn't matter

YH b0: .. .. .. 50 31 ff 80 0a 67 00 00 00 00 00 00 00
3R b0: .. .. .. 50 31 ff 80 0b 67 00 00 00 00 00 00 00
                            ^^
Device 0 Offset B7 - S2K Compensation Result 3 (RO)
7-5 Reserved. always reads 0
4-0 S2K Strobe Delay from DLL Counter (Auto)
    default = 0
*** TODO: readonly. doesn't matter

YH f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 00 00
3R f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 80 00 00
                                              ^^
Device 0 Offset FD - Back-DoorControl 2 (00h) ........... RW
7-5 Reserved. always reads 0
4-0 Max # of AGP Requests. default = 0
    00000 1 Request
    00001 2 Requests
    00010 3 Requests
    ..... ........
    11111 32 Requests
    (see also RxA7 and RxFC[1])
*** 3R BIOS: 80
*** YH BIOS: 00
*** TODO: probably doesn't matter
    Curious how "always zero" bit 7 happen to become 1
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/



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

* Re: Athlon bug stomping #2
  2001-09-13 12:31 Athlon bug stomping #2 VDA
@ 2001-09-14  2:56 ` Roberto Jung Drebes
  2001-09-14  4:02   ` Chris Vandomelen
  0 siblings, 1 reply; 38+ messages in thread
From: Roberto Jung Drebes @ 2001-09-14  2:56 UTC (permalink / raw)
  To: VDA; +Cc: linux-kernel

On Thu, 13 Sep 2001, VDA wrote:

> Device 0 Offset 55 - Debug (RW)
> 7-0 Reserved (do not program). default = 0
> *** 3R BIOS: non-zero!?
> *** YH BIOS: zero.
> *** TODO: try to set to 0.

I tryed sequentially to test the values given. It only worked when I set
offset 0x55 to 0, and then stopped. I don't need to set any other value in
other addresses. This is enough.

It's weird when your system only works when changing a "do not
program" value. :)

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/


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

* Re: Athlon bug stomping #2
  2001-09-14  2:56 ` Roberto Jung Drebes
@ 2001-09-14  4:02   ` Chris Vandomelen
  2001-09-14  5:51     ` Eric W. Biederman
  0 siblings, 1 reply; 38+ messages in thread
From: Chris Vandomelen @ 2001-09-14  4:02 UTC (permalink / raw)
  To: linux-kernel

> On Thu, 13 Sep 2001, VDA wrote:
>
> > Device 0 Offset 55 - Debug (RW)
> > 7-0 Reserved (do not program). default = 0
> > *** 3R BIOS: non-zero!?
> > *** YH BIOS: zero.
> > *** TODO: try to set to 0.
>
> I tryed sequentially to test the values given. It only worked when I set
> offset 0x55 to 0, and then stopped. I don't need to set any other value in
> other addresses. This is enough.
>
> It's weird when your system only works when changing a "do not
> program" value. :)

Makes me wonder just a little: my system is perfectly fine with 0x02
written to offset 0x55. (Yes, it is an Athlon compiled kernel.. something
I've been doing ever since I've been using this machine). It had it's
problems when I originally got it

>
> --
> Roberto Jung Drebes <drebes@inf.ufrgs.br>
> Porto Alegre, RS - Brasil
> http://www.inf.ufrgs.br/~drebes/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


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

* Re: Athlon bug stomping #2
  2001-09-14  4:02   ` Chris Vandomelen
@ 2001-09-14  5:51     ` Eric W. Biederman
  2001-09-14  7:34       ` Roberto Jung Drebes
  0 siblings, 1 reply; 38+ messages in thread
From: Eric W. Biederman @ 2001-09-14  5:51 UTC (permalink / raw)
  To: Chris Vandomelen; +Cc: linux-kernel, VDA

Chris Vandomelen <chrisv@b0rked.dhs.org> writes:

> > On Thu, 13 Sep 2001, VDA wrote:
> >
> > > Device 0 Offset 55 - Debug (RW)
> > > 7-0 Reserved (do not program). default = 0
> > > *** 3R BIOS: non-zero!?
> > > *** YH BIOS: zero.
> > > *** TODO: try to set to 0.
> >
> > I tryed sequentially to test the values given. It only worked when I set
> > offset 0x55 to 0, and then stopped. I don't need to set any other value in
> > other addresses. This is enough.
> >
> > It's weird when your system only works when changing a "do not
> > program" value. :)
> 
> Makes me wonder just a little: my system is perfectly fine with 0x02
> written to offset 0x55. (Yes, it is an Athlon compiled kernel.. something
> I've been doing ever since I've been using this machine). It had it's
> problems when I originally got it

So we have two confirmations that setting this register clears the problem.
Anyone want to generate a kernel patch so this fix can get some wider
testing?

Eric

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

* Re: Athlon bug stomping #2
  2001-09-14  5:51     ` Eric W. Biederman
@ 2001-09-14  7:34       ` Roberto Jung Drebes
  2001-09-14  8:27         ` Athlon: Try this (was: Re: Athlon bug stomping #2) Roberto Jung Drebes
  2001-09-14  9:26         ` Jeff Lightfoot
  0 siblings, 2 replies; 38+ messages in thread
From: Roberto Jung Drebes @ 2001-09-14  7:34 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Chris Vandomelen, linux-kernel, VDA

On 13 Sep 2001, Eric W. Biederman wrote:

> Anyone want to generate a kernel patch so this fix can get some wider
> testing?

I'll try to isolate the single bit in the register that is causing the
fault and will send the diff.

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/


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

* Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-14  7:34       ` Roberto Jung Drebes
@ 2001-09-14  8:27         ` Roberto Jung Drebes
  2001-09-14 18:19           ` Byron Stanoszek
                             ` (2 more replies)
  2001-09-14  9:26         ` Jeff Lightfoot
  1 sibling, 3 replies; 38+ messages in thread
From: Roberto Jung Drebes @ 2001-09-14  8:27 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Chris Vandomelen, linux-kernel, VDA

On Fri, 14 Sep 2001, Roberto Jung Drebes wrote:

> On 13 Sep 2001, Eric W. Biederman wrote:
> 
> > Anyone want to generate a kernel patch so this fix can get some wider
> > testing?
> 
> I'll try to isolate the single bit in the register that is causing the
> fault and will send the diff.

I tested here and it seems that bit 7 is responsible. Here is the diff to
pci-pc.c:

=================================================
--- linux-2.4.9/arch/i386/kernel/pci-pc.c.orig	Fri Sep 14 05:03:59 2001
+++ linux-2.4.9/arch/i386/kernel/pci-pc.c	Fri Sep 14 05:12:28 2001
@@ -701,6 +701,22 @@
 	return rt;
 }
 
+/* Fixes some oopses on fast_copy_page when it uses 'movntq's
+ * instead of 'movq's on Athlon/Duron optimized kernels. 
+ * Bit 7 at offset 0x55 seems to be responsible. 
+ * > Device 0 Offset 55 - Debug (RW)
+ * > 7-0 Reserved (do not program). default = 0
+ * > *** ABIT KT7A 3R BIOS: non-zero!? (oopses)
+ * > *** ABIT KT7A YH BIOS: zero. (works)
+ */
+static void __init pci_fixup_athlon_bug(struct pci_dev *d)
+{ 
+       u8 v; 
+       printk("Trying to stomp on Athlon bug...\n");
+       pci_read_config_byte(d, 0x55, &v);
+       v &= 0x7f; /* clear bit 55.7 */
+       pci_write_config_byte(d, 0x55, v);
+}
 
 int pcibios_set_irq_routing(struct pci_dev *dev, int pin, int irq)
 {
@@ -966,6 +982,8 @@
 	{ PCI_FIXUP_HEADER,	PCI_ANY_ID,		PCI_ANY_ID,			pci_fixup_ide_bases },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_SI,	PCI_DEVICE_ID_SI_5597,		pci_fixup_latency },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_SI,	PCI_DEVICE_ID_SI_5598,		pci_fixup_latency },
+	{ PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,   PCI_DEVICE_ID_VIA_8363_0,
+     pci_fixup_athlon_bug }, 
  	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82371AB_3,	pci_fixup_piix4_acpi },
 	{ 0 }
 };
=================================================

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/


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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-14  7:34       ` Roberto Jung Drebes
  2001-09-14  8:27         ` Athlon: Try this (was: Re: Athlon bug stomping #2) Roberto Jung Drebes
@ 2001-09-14  9:26         ` Jeff Lightfoot
  1 sibling, 0 replies; 38+ messages in thread
From: Jeff Lightfoot @ 2001-09-14  9:26 UTC (permalink / raw)
  To: Roberto Jung Drebes; +Cc: linux-kernel

On Fri, 14 Sep 2001 05:27:49 -0300 (EST)
Roberto Jung Drebes <drebes@inf.ufrgs.br> wrote:

> I tested here and it seems that bit 7 is responsible. Here is the diff
> to pci-pc.c:

[snip patch]

I tried it with my IWill 266 Plus and Althon 1.4G

Things now boot up normally with Athlon Optimizations turned on.

Before this, those same optimizations would produce oops galore on
system startup.

Let me know if you want more system info.

-- 
Jeff Lightfoot   --    jeffml at pobox.com   --   http://thefoots.com/
    "How can I sing like a girl and not be stigmatized by the rest of
    the world?" -- TMBG

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-14  8:27         ` Athlon: Try this (was: Re: Athlon bug stomping #2) Roberto Jung Drebes
@ 2001-09-14 18:19           ` Byron Stanoszek
  2001-09-15 18:00             ` Liakakis Kostas
  2001-09-15  7:15           ` brian
  2001-09-16 21:53           ` Carsten Leonhardt
  2 siblings, 1 reply; 38+ messages in thread
From: Byron Stanoszek @ 2001-09-14 18:19 UTC (permalink / raw)
  To: Roberto Jung Drebes
  Cc: Eric W. Biederman, Chris Vandomelen, linux-kernel, VDA

On Fri, 14 Sep 2001, Roberto Jung Drebes wrote:

> +/* Fixes some oopses on fast_copy_page when it uses 'movntq's
> + * instead of 'movq's on Athlon/Duron optimized kernels.
> + * Bit 7 at offset 0x55 seems to be responsible.
> + * > Device 0 Offset 55 - Debug (RW)
> + * > 7-0 Reserved (do not program). default = 0
> + * > *** ABIT KT7A 3R BIOS: non-zero!? (oopses)
> + * > *** ABIT KT7A YH BIOS: zero. (works)
> + */

I'm using the ZT bios with ABIT KT7A and I have not encountered any OOPSes or
anything with Athlon/Duron optimized kernels. I've been using the -ac kernels
since 2.4.0, upgrading regularly. I'm running a 1200 MHz TBird.  I'm reluctant
to try later BIOSes because #1: Mine works as it is now, and #2: I'm afraid of
'increased memory stability' changes that would decrease performance or raise
CPU temperature (as one BIOS changelog had mentioned).

Output of /proc/bus/pci/00/00.0:

000:  06 11 05 03 06 00 10 22  03 00 00 06 00 08 00 00         "
010:  08 00 00 d8 00 00 00 00  00 00 00 00 00 00 00 00
020:  00 00 00 00 00 00 00 00  00 00 00 00 7b 14 01 a4              {
030:  00 00 00 00 a0 00 00 00  00 00 00 00 00 00 00 00
040:  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
050:  18 a3 ec b4 47 89 10 10  08 80 00 00 08 08 0c 10      G
060:  3c 2a 00 20 52 52 52 c6  45 0c 43 0f 08 5f 00 00  <*  RRR E C  _
070:  dc 88 cc 0c 0e 80 d2 00  01 b4 19 02 00 00 00 00
080:  0f 40 00 00 c0 00 00 00  02 00 00 00 00 00 00 00   @
090:  00 00 00 00 00 00 00 00  00 00 00 00 00 32 00 00               2
0A0:  02 c0 20 00 17 02 00 1f  00 00 00 00 2f 12 14 00              /
0B0:  49 da 88 58 31 ff 80 05  67 00 00 00 00 00 00 00  I  X1   g
0C0:  01 00 02 00 00 00 00 00  00 00 00 00 00 00 00 00
0D0:  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
*
0F0:  00 00 00 00 00 03 03 00  22 00 00 00 00 00 91 06          "

The ZT bios has bit 7 of offset 0x55 set, too.

This is an unmodified 2.4.8-ac7.

 -Byron

-- 
Byron Stanoszek                         Ph: (330) 644-3059
Systems Programmer                      Fax: (330) 644-8110
Commercial Timesharing Inc.             Email: byron@comtime.com


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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-14  8:27         ` Athlon: Try this (was: Re: Athlon bug stomping #2) Roberto Jung Drebes
  2001-09-14 18:19           ` Byron Stanoszek
@ 2001-09-15  7:15           ` brian
  2001-09-19  1:30             ` brian
  2001-09-19 13:10             ` Re[2]: " VDA
  2001-09-16 21:53           ` Carsten Leonhardt
  2 siblings, 2 replies; 38+ messages in thread
From: brian @ 2001-09-15  7:15 UTC (permalink / raw)
  To: Roberto Jung Drebes
  Cc: Eric W. Biederman, Chris Vandomelen, linux-kernel, VDA

> > On 13 Sep 2001, Eric W. Biederman wrote:
> > > Anyone want to generate a kernel patch so this fix can get some wider
> > > testing?

> On Fri, 14 Sep 2001, Roberto Jung Drebes wrote:
> > I'll try to isolate the single bit in the register that is causing the
> > fault and will send the diff.

On Fri, Sep 14, 2001 at 05:27:49AM -0300, Roberto Jung Drebes wrote:
> I tested here and it seems that bit 7 is responsible. Here is the diff to
> pci-pc.c:

I just tried the patch and for the first time I've been able to
successfully boot and run a 2.4 kernel with Athlon optimizations.

I have 11 machines all of which oops to death trying to boot
2.4.9ac5 with Athlon optimizations.

The machine that has been successful, and the only one I tried, is an
800 MHz Duron system with an Epox 8KTA3+ MB which is now running fine
with linux 2.4.9ac10 + the Athlon Bug stomper #2 bit 7 patch version 1.

I'll try some more of the machines on Monday.

-- 
Brian Litzinger <brian@worldcontrol.com>

    Copyright (c) 2000 By Brian Litzinger, All Rights Reserved

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-14 18:19           ` Byron Stanoszek
@ 2001-09-15 18:00             ` Liakakis Kostas
  2001-09-15 20:28               ` VDA
  0 siblings, 1 reply; 38+ messages in thread
From: Liakakis Kostas @ 2001-09-15 18:00 UTC (permalink / raw)
  To: linux-kernel


Hate to post a me-too, but my Asus A7V133 does have 55.7 set (reg 55 ==
0x89) and is running fine with 2.4.9-ac9 and K7 optimizations. BIOS
revision is 1005A, memory is 3x256MB noname DIMMs. 

-K.


On Fri, 14 Sep 2001, Byron Stanoszek wrote:

> I'm using the ZT bios with ABIT KT7A and I have not encountered any OOPSes or
> anything with Athlon/Duron optimized kernels. I've been using the -ac kernels
> since 2.4.0, upgrading regularly. I'm running a 1200 MHz TBird.  I'm reluctant
> to try later BIOSes because #1: Mine works as it is now, and #2: I'm afraid of
[snip]


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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-15 18:00             ` Liakakis Kostas
@ 2001-09-15 20:28               ` VDA
  0 siblings, 0 replies; 38+ messages in thread
From: VDA @ 2001-09-15 20:28 UTC (permalink / raw)
  To: Liakakis Kostas; +Cc: linux-kernel

Hello Liakakis,
Saturday, September 15, 2001, 9:00:41 PM, you wrote:
LK> Hate to post a me-too, but my Asus A7V133 does have 55.7 set (reg 55 ==
LK> 0x89) and is running fine with 2.4.9-ac9 and K7 optimizations. BIOS
LK> revision is 1005A, memory is 3x256MB noname DIMMs.

Ok, but we don't see KT133A mobos with Athlon/Duron and 55.7=1
to fail always. It can start failing with faster CPU, different
memory or once in a blue moon - nobody knows.

It is better to turn that bit off for good,
unless VIA and BIOS writers will enlighten
us what is 55.7 (and 55.6-0 too).
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/



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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-14  8:27         ` Athlon: Try this (was: Re: Athlon bug stomping #2) Roberto Jung Drebes
  2001-09-14 18:19           ` Byron Stanoszek
  2001-09-15  7:15           ` brian
@ 2001-09-16 21:53           ` Carsten Leonhardt
  2001-09-19  3:55             ` Dan Hollis
  2 siblings, 1 reply; 38+ messages in thread
From: Carsten Leonhardt @ 2001-09-16 21:53 UTC (permalink / raw)
  To: linux-kernel

Roberto Jung Drebes <drebes@inf.ufrgs.br> writes:

> I tested here and it seems that bit 7 is responsible. Here is the
> diff to pci-pc.c:

I tried it here on my Tyan Trinity KT-A (S2390B), and it works!

Very nice!

Thanks,
  leo

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-15  7:15           ` brian
@ 2001-09-19  1:30             ` brian
  2001-09-19 13:10             ` Re[2]: " VDA
  1 sibling, 0 replies; 38+ messages in thread
From: brian @ 2001-09-19  1:30 UTC (permalink / raw)
  To: Roberto Jung Drebes, Eric W. Biederman, Chris Vandomelen,
	linux-kernel, VDA

I just tried the 'Athlon Bug stomper #2 bit 7 patch version 1' on a 2nd
matchine, 900 MHz Duron system with an Epox 8KTA3+ MB, and it too
is now running fine with an Athlon optimized kernel, when before it
would oops to death on boot.

Shall I keep posting success reports or are people convinced this
fix works?

> > > On 13 Sep 2001, Eric W. Biederman wrote:
> > > > Anyone want to generate a kernel patch so this fix can get some wider
> > > > testing?
> 
> > On Fri, 14 Sep 2001, Roberto Jung Drebes wrote:
> > > I'll try to isolate the single bit in the register that is causing the
> > > fault and will send the diff.
> 
> On Fri, Sep 14, 2001 at 05:27:49AM -0300, Roberto Jung Drebes wrote:
> > I tested here and it seems that bit 7 is responsible. Here is the diff to
> > pci-pc.c:
> 
On Sat, Sep 15, 2001 at 12:15:30AM -0700, brian@worldcontrol.com wrote:
> I just tried the patch and for the first time I've been able to
> successfully boot and run a 2.4 kernel with Athlon optimizations.
> ...
> The machine that has been successful, and the only one I tried, is an
> 800 MHz Duron system with an Epox 8KTA3+ MB which is now running fine
> with linux 2.4.9ac10 + the Athlon Bug stomper #2 bit 7 patch version 1.


-- 
Brian Litzinger <brian@worldcontrol.com>

    Copyright (c) 2000 By Brian Litzinger, All Rights Reserved

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-16 21:53           ` Carsten Leonhardt
@ 2001-09-19  3:55             ` Dan Hollis
  0 siblings, 0 replies; 38+ messages in thread
From: Dan Hollis @ 2001-09-19  3:55 UTC (permalink / raw)
  To: Carsten Leonhardt; +Cc: linux-kernel

On 16 Sep 2001, Carsten Leonhardt wrote:
> Roberto Jung Drebes <drebes@inf.ufrgs.br> writes:
> > I tested here and it seems that bit 7 is responsible. Here is the
> > diff to pci-pc.c:
> I tried it here on my Tyan Trinity KT-A (S2390B), and it works!

Has anyone compared memcopy speed with it on and with it off?
Eg does it slow down memory accesses even slower than non-optimized
memcopy?

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]


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

* Re[2]: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-15  7:15           ` brian
  2001-09-19  1:30             ` brian
@ 2001-09-19 13:10             ` VDA
  2001-09-19 23:56               ` Nicholas Knight
  1 sibling, 1 reply; 38+ messages in thread
From: VDA @ 2001-09-19 13:10 UTC (permalink / raw)
  To: brian; +Cc: linux-kernel

Hello brian,
Wednesday, September 19, 2001, 4:30:17 AM, you wrote:
bwc> I just tried the 'Athlon Bug stomper #2 bit 7 patch version 1' on a 2nd
bwc> matchine, 900 MHz Duron system with an Epox 8KTA3+ MB, and it too
bwc> is now running fine with an Athlon optimized kernel, when before it
bwc> would oops to death on boot.
bwc> Shall I keep posting success reports or are people convinced this
bwc> fix works?

It is pleasant to hear success stories.
However, now we are pretty sure fix is ok,
so only failure reports to lkml please.
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/



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

* Re: Re[2]: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-19 13:10             ` Re[2]: " VDA
@ 2001-09-19 23:56               ` Nicholas Knight
  2001-09-20  3:17                 ` Nicholas Knight
  0 siblings, 1 reply; 38+ messages in thread
From: Nicholas Knight @ 2001-09-19 23:56 UTC (permalink / raw)
  To: VDA, brian; +Cc: linux-kernel

On Wednesday 19 September 2001 06:10 am, VDA wrote:
> Hello brian,
> Wednesday, September 19, 2001, 4:30:17 AM, you wrote:
> bwc> I just tried the 'Athlon Bug stomper #2 bit 7 patch version 1' on
> a 2nd bwc> matchine, 900 MHz Duron system with an Epox 8KTA3+ MB, and
> it too bwc> is now running fine with an Athlon optimized kernel, when
> before it bwc> would oops to death on boot.
> bwc> Shall I keep posting success reports or are people convinced this
> bwc> fix works?
>
> It is pleasant to hear success stories.
> However, now we are pretty sure fix is ok,
> so only failure reports to lkml please.

Reports of loss of performance due to this patch would be good too.

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

* Re: Re[2]: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-19 23:56               ` Nicholas Knight
@ 2001-09-20  3:17                 ` Nicholas Knight
  2001-09-20 12:34                   ` Alan Cox
  0 siblings, 1 reply; 38+ messages in thread
From: Nicholas Knight @ 2001-09-20  3:17 UTC (permalink / raw)
  To: VDA, brian; +Cc: linux-kernel

Here's a new one:
http://zerowing.idsoftware.com/linux/q3a/
I have an AMD CPU and a kernel 2.4.*, Quake III Arena is slowing down to 
a complete stop after a while?

It seems the 3DNow! copy routines have issues with the southbridge chip 
in the KT133A, this results in performances degrading while playing for a 
while. Re-compile your kernel without 3DNow! instructions to avoid the 
problem, and wait for newer kernels with better support for 3DNow! / 
KT133A.


Anyone know further details on this and if it's in any way connected with 
the current K7 optimization problems in the kernel?

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

* Re: Re[2]: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-20  3:17                 ` Nicholas Knight
@ 2001-09-20 12:34                   ` Alan Cox
  0 siblings, 0 replies; 38+ messages in thread
From: Alan Cox @ 2001-09-20 12:34 UTC (permalink / raw)
  To: tegeran; +Cc: VDA, brian, linux-kernel

> It seems the 3DNow! copy routines have issues with the southbridge chip 
> in the KT133A, this results in performances degrading while playing for a 
> while. Re-compile your kernel without 3DNow! instructions to avoid the 
> problem, and wait for newer kernels with better support for 3DNow! / 
> KT133A.> 

I have no data of any kind to remotely substantiate that claim. I would
have expected to see such data if it existed.

Alan

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-14 18:43 ` VDA
  2001-09-14 23:16   ` Alan Cox
@ 2001-09-20 23:38   ` bill davidsen
  1 sibling, 0 replies; 38+ messages in thread
From: bill davidsen @ 2001-09-20 23:38 UTC (permalink / raw)
  To: linux-kernel

In article <1292125035.20010914214303@port.imtp.ilyichevsk.odessa.ua> you write:

| +               printk(KERN_NOTICE "Stomping on Athlon bug.\n");

Okay, I'm pedantic. It's not an Athlon bug, is it? It's a chipset bug?
No? If so should say so! 

-- 
bill davidsen (davidsen@prodigy.com)
  Prodigy Internet Server Group
  Project Leader, USENET news
  914-448-1241

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-16  8:08         ` Jan Niehusmann
@ 2001-09-19  3:47           ` Albert D. Cahalan
  0 siblings, 0 replies; 38+ messages in thread
From: Albert D. Cahalan @ 2001-09-19  3:47 UTC (permalink / raw)
  To: Jan Niehusmann; +Cc: Steffen Persvold, Petr Vandrovec, linux-kernel, VDA, alan

Jan Niehusmann writes:

> Sure. I did crash a computer running an old kernel (not 2.2 but 
> 2.4.0-testX without the optimised fast_copy_page) from a non-privileged
> user space program containing the same code as the optimised fast_copy_page.

Port this to Windows if you want to raise Hell. Call it something
nasty (like "AMD/VIA bug exploit") to get attention.

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-16  1:52     ` Petr Vandrovec
  2001-09-16  7:21       ` Steffen Persvold
  2001-09-16 11:02       ` Vojtech Pavlik
@ 2001-09-18 11:27       ` jury gerold
  2 siblings, 0 replies; 38+ messages in thread
From: jury gerold @ 2001-09-18 11:27 UTC (permalink / raw)
  To: linux-kernel; +Cc: alan



Petr Vandrovec wrote:

>>+static void __init pci_fixup_athlon_bug(struct pci_dev *d)
>>+{ 
>>+       u8 v; 
>>+       pci_read_config_byte(d, 0x55, &v);
>>+       if(v & 0x80) {
>>+               printk(KERN_NOTICE "Stomping on Athlon bug.\n");
>>+               v &= 0x7f; /* clear bit 55.7 */
>>+               pci_write_config_byte(d, 0x55, v);
>>+       }
>>+}
>>
>>Well, these are cosmetic changes anyway...
>>What is more important now:
>>1) Do we have people who still see Athlon bug with the patch?
>>
>
>Just by any chance - does anybody have KT133 (not KT133A)
>datasheet? I just noticed at home that my KT133 has reg 55 set
>to 0x89 and it happilly lives... So maybe some BIOS vendors
>used KT133 instead of KT133A BIOS image?
>
Same here ... with a board from gigabyte
I had to replace a 128MB PC100 RAM module (maybe related, maybe not)
but now it works.

Gerold Jury


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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-17  1:37               ` Ignacio Vazquez-Abrams
@ 2001-09-17 14:59                 ` Jonathan Morton
  0 siblings, 0 replies; 38+ messages in thread
From: Jonathan Morton @ 2001-09-17 14:59 UTC (permalink / raw)
  To: Ignacio Vazquez-Abrams, linux-kernel

>  > ... but there are listed both KT133 and KT133A based motherboards,
>>  so maybe it is intentional?
>
>The same south bridge is used for both the KT133 and the KT133A.

And also for other northbridges.  I've seen the 82c686a used on an 
i810 board, which is currently in my friend's games machine.

-- 
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
           V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-17  0:58             ` Petr Vandrovec
@ 2001-09-17  1:37               ` Ignacio Vazquez-Abrams
  2001-09-17 14:59                 ` Jonathan Morton
  0 siblings, 1 reply; 38+ messages in thread
From: Ignacio Vazquez-Abrams @ 2001-09-17  1:37 UTC (permalink / raw)
  To: linux-kernel

On Mon, 17 Sep 2001, Petr Vandrovec wrote:

> On Sun, Sep 16, 2001 at 01:52:36PM -0300, Roberto Jung Drebes wrote:
>
> > Handle 0x0002
> > 	DMI type 2, 8 bytes.
> > 	Board Information Block
> > 		Vendor:  <http://www.abit.com.tw>
> > 		Product: 8363-686A(KT7,KT7A,KT7A-RAID,KT7E)
> > 		Version:
> > 		Serial Number:
>
> ... but there are listed both KT133 and KT133A based motherboards,
> so maybe it is intentional?

The same south bridge is used for both the KT133 and the KT133A.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>


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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-16 16:52           ` Roberto Jung Drebes
@ 2001-09-17  0:58             ` Petr Vandrovec
  2001-09-17  1:37               ` Ignacio Vazquez-Abrams
  0 siblings, 1 reply; 38+ messages in thread
From: Petr Vandrovec @ 2001-09-17  0:58 UTC (permalink / raw)
  To: Roberto Jung Drebes; +Cc: linux-kernel, alan

On Sun, Sep 16, 2001 at 01:52:36PM -0300, Roberto Jung Drebes wrote:
> On Sun, 16 Sep 2001, Alan Cox wrote:
> > One way to test this hypthesis maybe to run dmidecode on the machines and
> > see if they report KT133 or KT133A. Its also possible some BIOS code does
> > blindly program bit 7 even tho its reserved and should have been kept
> > unchanged.
> 
> I'm not sure if this is the output you are talking about (I see no KT133
> strings on it) but here it goes (this motherboard uses KT133A and
> exhibits the bug):
> 
> Handle 0x0001
> 	DMI type 1, 25 bytes.
> 	System Information Block
> 		Vendor: VIA Technologies, Inc.
> 		Product: VT8363
> 		Version:  
> 		Serial Number:  

VT8363 is basic KT133. KT133A == VT8363A, at least according
to VT8363A datasheet...

> Handle 0x0002
> 	DMI type 2, 8 bytes.
> 	Board Information Block
> 		Vendor:  <http://www.abit.com.tw>
> 		Product: 8363-686A(KT7,KT7A,KT7A-RAID,KT7E)
> 		Version:  
> 		Serial Number:  

... but there are listed both KT133 and KT133A based motherboards, 
so maybe it is intentional?
				Best regards,
					Petr Vandrovec
					vandrove@vc.cvut.cz


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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-16 14:47             ` Alan Cox
@ 2001-09-16 17:01               ` Vojtech Pavlik
  0 siblings, 0 replies; 38+ messages in thread
From: Vojtech Pavlik @ 2001-09-16 17:01 UTC (permalink / raw)
  To: Alan Cox; +Cc: Petr Vandrovec, linux-kernel, VDA

On Sun, Sep 16, 2001 at 03:47:55PM +0100, Alan Cox wrote:
> > > One way to test this hypthesis maybe to run dmidecode on the machines and
> > > see if they report KT133 or KT133A. Its also possible some BIOS code does
> > > blindly program bit 7 even tho its reserved and should have been kept
> > > unchanged.
> > 
> > I think it's possible to decide whether a chipset is KT133 or KT133A
> > based on the hostbridge revision. Mine is KT133 and is rev 03.
> 
> That tells you the chipset of the bridge. dmidecode dumps bios strings which
> may tell you the chipset the bios was actually for..

Ahh, yes.

-- 
Vojtech Pavlik
SuSE Labs

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-16 13:53         ` Alan Cox
  2001-09-16 13:50           ` Vojtech Pavlik
@ 2001-09-16 16:52           ` Roberto Jung Drebes
  2001-09-17  0:58             ` Petr Vandrovec
  1 sibling, 1 reply; 38+ messages in thread
From: Roberto Jung Drebes @ 2001-09-16 16:52 UTC (permalink / raw)
  To: linux-kernel

On Sun, 16 Sep 2001, Alan Cox wrote:

> > > to 0x89 and it happilly lives... So maybe some BIOS vendors
> > > used KT133 instead of KT133A BIOS image?
> > 
> > Same here ...
> 
> One way to test this hypthesis maybe to run dmidecode on the machines and
> see if they report KT133 or KT133A. Its also possible some BIOS code does
> blindly program bit 7 even tho its reserved and should have been kept
> unchanged.

I'm not sure if this is the output you are talking about (I see no KT133
strings on it) but here it goes (this motherboard uses KT133A and
exhibits the bug):

SMBIOS 2.3 present.
DMI 2.3 present.
40 structures occupying 1181 bytes.
DMI table at 0x000F0800.
Handle 0x0000
	DMI type 0, 20 bytes.
	BIOS Information Block
		Vendor: Award Software International, Inc.
		Version: 6.00 PG
		Release: 07/05/2001
		BIOS base: 0xE0000
		ROM size: 192K
		Capabilities:
			Flags: 0x000000007FCBDE90
Handle 0x0001
	DMI type 1, 25 bytes.
	System Information Block
		Vendor: VIA Technologies, Inc.
		Product: VT8363
		Version:  
		Serial Number:  
Handle 0x0002
	DMI type 2, 8 bytes.
	Board Information Block
		Vendor:  <http://www.abit.com.tw>
		Product: 8363-686A(KT7,KT7A,KT7A-RAID,KT7E)
		Version:  
		Serial Number:  
Handle 0x0003
	DMI type 3, 17 bytes.
	Chassis Information Block
		Vendor:  
		Chassis Type: Desktop
		Version:  
		Serial Number:  
		Asset Tag:  
Handle 0x0004
	DMI type 4, 35 bytes.
	Processor
		Socket Designation: Socket A
		Processor Type: Central Processor
		Processor Family: M1
		Processor Manufacturer: AMD
		Processor Version: AMD Duron(tm)
		Serial Number:  
		Asset Tag:  
		Vendor Part Number:  
Handle 0x0006
	DMI type 6, 12 bytes.
	Memory Bank
		Socket: BANK_0
		Banks: 0 1
		Speed: 60nS
		Type: 
		Installed Size: 64Mbyte
		Enabled Size: 64Mbyte
Handle 0x0007
	DMI type 6, 12 bytes.
	Memory Bank
		Socket: BANK_1
		Banks: 2 3
		Speed: 60nS
		Type: 
		Installed Size: 64Mbyte
		Enabled Size: 64Mbyte
Handle 0x0008
	DMI type 6, 12 bytes.
	Memory Bank
		Socket: BANK_2
		Banks: 4 5
		Speed: 60nS
		Type: UNKNOWN 
		Installed Size: Not Installed
		Enabled Size: Not Installed
Handle 0x000A
	DMI type 7, 19 bytes.
	Cache
		Socket: Internal Cache
		L1 Internal Cache: write-back
		L1 Cache Size: 128K
		L1 Cache Maximum: 128K
		L1 Cache Type: Synchronous 
Handle 0x000B
	DMI type 7, 19 bytes.
	Cache
		Socket: External Cache
		L2 External Cache: write-back
		L2 Cache Size: 64K
		L2 Cache Maximum: 64K
		L2 Cache Type: Synchronous 
Handle 0x000C
	DMI type 8, 9 bytes.
	Port Connector
		Internal Designator: PRIMARY IDE
		Internal Connector Type: On Board IDE
		External Designator:  
		External Connector Type: None
		Port Type: Other
Handle 0x000D
	DMI type 8, 9 bytes.
	Port Connector
		Internal Designator: SECONDARY IDE
		Internal Connector Type: On Board IDE
		External Designator:  
		External Connector Type: None
		Port Type: Other
Handle 0x000E
	DMI type 8, 9 bytes.
	Port Connector
		Internal Designator: FDD
		Internal Connector Type: On Board Floppy
		External Designator:  
		External Connector Type: None
		Port Type: „(­û
Handle 0x000F
	DMI type 8, 9 bytes.
	Port Connector
		Internal Designator: COM1
		Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
		External Designator:  
		External Connector Type: DB-9 pin male
		Port Type: Serial Port 16450 Compatible
Handle 0x0010
	DMI type 8, 9 bytes.
	Port Connector
		Internal Designator: COM2
		Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
		External Designator:  
		External Connector Type: DB-9 pin male
		Port Type: Serial Port 16450 Compatible
Handle 0x0011
	DMI type 8, 9 bytes.
	Port Connector
		Internal Designator: LPT1
		Internal Connector Type: DB-25 pin female
		External Designator:  
		External Connector Type: DB-25 pin female
		Port Type: Parallel Port ECP/EPP
Handle 0x0012
	DMI type 8, 9 bytes.
	Port Connector
		Internal Designator: Keyboard
		Internal Connector Type: Other
		External Designator:  
		External Connector Type: PS/2
		Port Type: Keyboard Port
Handle 0x0013
	DMI type 8, 9 bytes.
	Port Connector
		Internal Designator: PS/2 Mouse
		Internal Connector Type: PS/2
		External Designator: No Detected
		External Connector Type: PS/2
		Port Type: Mouse Port
Handle 0x0014
	DMI type 9, 13 bytes.
	Card Slot
		Slot: ISA
		Type: 16bit ISA 
		Slot Features: 5v 
Handle 0x0015
	DMI type 9, 13 bytes.
	Card Slot
		Slot: PCI
		Type: 32bit PCI 
		Status: In use.
		Slot Features: 5v 
Handle 0x0016
	DMI type 9, 13 bytes.
	Card Slot
		Slot: PCI
		Type: 32bit PCI 
		Status: In use.
		Slot Features: 5v 
Handle 0x0017
	DMI type 9, 13 bytes.
	Card Slot
		Slot: PCI
		Type: 32bit PCI 
		Status: In use.
		Slot Features: 5v 
Handle 0x0018
	DMI type 9, 13 bytes.
	Card Slot
		Slot: PCI
		Type: 32bit PCI 
		Status: In use.
		Slot Features: 5v 
Handle 0x0019
	DMI type 9, 13 bytes.
	Card Slot
		Slot: PCI
		Type: 32bit PCI 
		Status: Available.
		Slot Features: 5v 
Handle 0x001A
	DMI type 9, 13 bytes.
	Card Slot
		Slot: PCI
		Type: 32bit PCI 
		Status: Available.
		Slot Features: 5v 
Handle 0x001B
	DMI type 10, 8 bytes.
	On Board Devices Information
		Description:   : Enabled
		Type: 
		Description:   : Enabled
		Type: 
Handle 0x001C
	DMI type 9, 13 bytes.
	Card Slot
		Slot: AGP
		Type: 32bit AGP 2x 
		Status: Available.
		Slot Features: 5v 
Handle 0x001D
	DMI type 8, 9 bytes.
	Port Connector
		Internal Designator: USB
		Internal Connector Type: None
		External Designator:  
		External Connector Type: Other
		Port Type: USB
Handle 0x001E
	DMI type 13, 22 bytes.
	BIOS Language Information
Handle 0x001F
	DMI type 16, 15 bytes.
	Physical Memory Array
Handle 0x0020
	DMI type 17, 27 bytes.
	Memory Device
Handle 0x0403
	DMI type 0, 0 bytes.
	BIOS Information Block
		Vendor: NoneNoneNoneNone
		Version: \x11^["
		Release: 
		BIOS base: 0x41420
		ROM size: 4800K
		Capabilities:
			Flags: 0x326B6E614200315F
Handle 0x0605
	DMI type 3, 4 bytes.
	Chassis Information Block
		Vendor: 
		Chassis Type: 
		Version: \x03\x06
		Serial Number: 
		Asset Tag: 
Handle 0x0201
	DMI type 9, 0 bytes.
	Card Slot
		Slot: \x01\x02\x02
		Type: 
		Slot Features: 3.3v 
Handle 0x0403
	DMI type 0, 0 bytes.
	BIOS Information Block
		Vendor: NoneNoneNoneNone
		Version: \x13\x0f$
		Release: 
		BIOS base: 0x41420
		ROM size: 4800K
		Capabilities:
			Flags: 0x346B6E614200325F
Handle 0x0605
	DMI type 3, 4 bytes.
	Chassis Information Block
		Vendor: \x03\x06
		Chassis Type: 
		Version: 
		Serial Number: 
		Asset Tag: 
Handle 0xFF00
	DMI type 0, 0 bytes.
	BIOS Information Block
		Vendor: 
		Version: 
		Release: 
		BIOS base: 0x1F000
		ROM size: 64K
		Capabilities:
			Flags: 0x0000251314000020
Handle 0x01FF
	DMI type 0, 255 bytes.
	BIOS Information Block
		Vendor: 
		Version: 
		Release: 
		BIOS base: 0x01000
		ROM size: 0K
		Capabilities:
			Flags: 0x0000000025131400
Handle 0x0000
	DMI type 0, 0 bytes.
	BIOS Information Block
		Vendor: 
		Version: 
		Release: 
		BIOS base: 0x00000
		ROM size: 0K
		Capabilities:
			Flags: 0x0000000000000000
Handle 0x0000
	DMI type 0, 0 bytes.
	BIOS Information Block
		Vendor: 
		Version: 
		Release: 
		BIOS base: 0x00000
		ROM size: 0K
		Capabilities:
			Flags: 0x0000000000000000

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/


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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-16 13:50           ` Vojtech Pavlik
@ 2001-09-16 14:47             ` Alan Cox
  2001-09-16 17:01               ` Vojtech Pavlik
  0 siblings, 1 reply; 38+ messages in thread
From: Alan Cox @ 2001-09-16 14:47 UTC (permalink / raw)
  To: Vojtech Pavlik; +Cc: Alan Cox, Petr Vandrovec, linux-kernel, VDA

> > One way to test this hypthesis maybe to run dmidecode on the machines and
> > see if they report KT133 or KT133A. Its also possible some BIOS code does
> > blindly program bit 7 even tho its reserved and should have been kept
> > unchanged.
> 
> I think it's possible to decide whether a chipset is KT133 or KT133A
> based on the hostbridge revision. Mine is KT133 and is rev 03.

That tells you the chipset of the bridge. dmidecode dumps bios strings which
may tell you the chipset the bios was actually for..

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-16 11:02       ` Vojtech Pavlik
@ 2001-09-16 13:53         ` Alan Cox
  2001-09-16 13:50           ` Vojtech Pavlik
  2001-09-16 16:52           ` Roberto Jung Drebes
  0 siblings, 2 replies; 38+ messages in thread
From: Alan Cox @ 2001-09-16 13:53 UTC (permalink / raw)
  To: Vojtech Pavlik; +Cc: Petr Vandrovec, linux-kernel, VDA, alan

> > to 0x89 and it happilly lives... So maybe some BIOS vendors
> > used KT133 instead of KT133A BIOS image?
> 
> Same here ...

One way to test this hypthesis maybe to run dmidecode on the machines and
see if they report KT133 or KT133A. Its also possible some BIOS code does
blindly program bit 7 even tho its reserved and should have been kept
unchanged.

Alan

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-16 13:53         ` Alan Cox
@ 2001-09-16 13:50           ` Vojtech Pavlik
  2001-09-16 14:47             ` Alan Cox
  2001-09-16 16:52           ` Roberto Jung Drebes
  1 sibling, 1 reply; 38+ messages in thread
From: Vojtech Pavlik @ 2001-09-16 13:50 UTC (permalink / raw)
  To: Alan Cox; +Cc: Petr Vandrovec, linux-kernel, VDA

On Sun, Sep 16, 2001 at 02:53:17PM +0100, Alan Cox wrote:
> > > to 0x89 and it happilly lives... So maybe some BIOS vendors
> > > used KT133 instead of KT133A BIOS image?
> > 
> > Same here ...
> 
> One way to test this hypthesis maybe to run dmidecode on the machines and
> see if they report KT133 or KT133A. Its also possible some BIOS code does
> blindly program bit 7 even tho its reserved and should have been kept
> unchanged.

I think it's possible to decide whether a chipset is KT133 or KT133A
based on the hostbridge revision. Mine is KT133 and is rev 03.

-- 
Vojtech Pavlik
SuSE Labs

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-16  1:52     ` Petr Vandrovec
  2001-09-16  7:21       ` Steffen Persvold
@ 2001-09-16 11:02       ` Vojtech Pavlik
  2001-09-16 13:53         ` Alan Cox
  2001-09-18 11:27       ` jury gerold
  2 siblings, 1 reply; 38+ messages in thread
From: Vojtech Pavlik @ 2001-09-16 11:02 UTC (permalink / raw)
  To: Petr Vandrovec; +Cc: linux-kernel, VDA, alan

On Sun, Sep 16, 2001 at 03:52:07AM +0200, Petr Vandrovec wrote:
> > +static void __init pci_fixup_athlon_bug(struct pci_dev *d)
> > +{ 
> > +       u8 v; 
> > +       pci_read_config_byte(d, 0x55, &v);
> > +       if(v & 0x80) {
> > +               printk(KERN_NOTICE "Stomping on Athlon bug.\n");
> > +               v &= 0x7f; /* clear bit 55.7 */
> > +               pci_write_config_byte(d, 0x55, v);
> > +       }
> > +}
> > 
> > Well, these are cosmetic changes anyway...
> > What is more important now:
> > 1) Do we have people who still see Athlon bug with the patch?
> 
> Just by any chance - does anybody have KT133 (not KT133A)
> datasheet? I just noticed at home that my KT133 has reg 55 set
> to 0x89 and it happilly lives... So maybe some BIOS vendors
> used KT133 instead of KT133A BIOS image?

Same here ...

-- 
Vojtech Pavlik
SuSE Labs

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-16  7:21       ` Steffen Persvold
@ 2001-09-16  8:08         ` Jan Niehusmann
  2001-09-19  3:47           ` Albert D. Cahalan
  0 siblings, 1 reply; 38+ messages in thread
From: Jan Niehusmann @ 2001-09-16  8:08 UTC (permalink / raw)
  To: Steffen Persvold; +Cc: Petr Vandrovec, linux-kernel, VDA, alan

On Sun, Sep 16, 2001 at 09:21:49AM +0200, Steffen Persvold wrote:
> I also have a question; if "movntq; sfence" type of memory copy can cause data
> corruption in kernel space, it can in theory also do so in user space right ?
> So, if I'm right this bug could also be on machines running a 2.2 kernel with
> userspace programs using 3DNow (or SSE even) instructions.

Sure. I did crash a computer running an old kernel (not 2.2 but 
2.4.0-testX without the optimised fast_copy_page) from a non-privileged
user space program containing the same code as the optimised fast_copy_page.

Jan


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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-16  1:52     ` Petr Vandrovec
@ 2001-09-16  7:21       ` Steffen Persvold
  2001-09-16  8:08         ` Jan Niehusmann
  2001-09-16 11:02       ` Vojtech Pavlik
  2001-09-18 11:27       ` jury gerold
  2 siblings, 1 reply; 38+ messages in thread
From: Steffen Persvold @ 2001-09-16  7:21 UTC (permalink / raw)
  To: Petr Vandrovec; +Cc: linux-kernel, VDA, alan

Petr Vandrovec wrote:
> 
> > +static void __init pci_fixup_athlon_bug(struct pci_dev *d)
> > +{
> > +       u8 v;
> > +       pci_read_config_byte(d, 0x55, &v);
> > +       if(v & 0x80) {
> > +               printk(KERN_NOTICE "Stomping on Athlon bug.\n");
> > +               v &= 0x7f; /* clear bit 55.7 */
> > +               pci_write_config_byte(d, 0x55, v);
> > +       }
> > +}
> >
> > Well, these are cosmetic changes anyway...
> > What is more important now:
> > 1) Do we have people who still see Athlon bug with the patch?
> 
> Just by any chance - does anybody have KT133 (not KT133A)
> datasheet? I just noticed at home that my KT133 has reg 55 set
> to 0x89 and it happilly lives... So maybe some BIOS vendors
> used KT133 instead of KT133A BIOS image?

Hmm, I have a "KT133 Athlon Norbridge, Preliminary Revision 1.0 May 12, 2000"
PDF. Register 55 is described like this :

Device 0 Offset 55  Debug .............................................. RW
	7-5	Reserved (do not program)...................... default = 0
	4	Write Policy for CPU Write to DRAM
		0	Issue DRAM write when FIFO holds more
			than two requests of DRAM controller idle . def
		1	Disable Write Policy
	3-0	Reserved (do not program)...................... default = 0

Which doesn't explain things much more since the bits in question (7, 3, 0) is
marked as "Reserved".

I also have a question; if "movntq; sfence" type of memory copy can cause data
corruption in kernel space, it can in theory also do so in user space right ?
So, if I'm right this bug could also be on machines running a 2.2 kernel with
userspace programs using 3DNow (or SSE even) instructions.

Regards,
-- 
  Steffen Persvold   | Scalable Linux Systems |   Try out the world's best   
 mailto:sp@scali.no  |  http://www.scali.com  | performing MPI implementation:
Tel: (+47) 2262 8950 |   Olaf Helsets vei 6   |      - ScaMPI 1.12.2 -         
Fax: (+47) 2262 8951 |   N0621 Oslo, NORWAY   | >300MBytes/s and <4uS latency

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-14 23:16   ` Alan Cox
  2001-09-15 17:44     ` Nicholas Knight
  2001-09-15 18:02     ` Jonathan Morton
@ 2001-09-16  1:52     ` Petr Vandrovec
  2001-09-16  7:21       ` Steffen Persvold
                         ` (2 more replies)
  2 siblings, 3 replies; 38+ messages in thread
From: Petr Vandrovec @ 2001-09-16  1:52 UTC (permalink / raw)
  To: linux-kernel; +Cc: VDA, alan

> +static void __init pci_fixup_athlon_bug(struct pci_dev *d)
> +{ 
> +       u8 v; 
> +       pci_read_config_byte(d, 0x55, &v);
> +       if(v & 0x80) {
> +               printk(KERN_NOTICE "Stomping on Athlon bug.\n");
> +               v &= 0x7f; /* clear bit 55.7 */
> +               pci_write_config_byte(d, 0x55, v);
> +       }
> +}
> 
> Well, these are cosmetic changes anyway...
> What is more important now:
> 1) Do we have people who still see Athlon bug with the patch?

Just by any chance - does anybody have KT133 (not KT133A)
datasheet? I just noticed at home that my KT133 has reg 55 set
to 0x89 and it happilly lives... So maybe some BIOS vendors
used KT133 instead of KT133A BIOS image?
					Thanks,
						Petr Vandrovec
						vandrove@vc.cvut.cz
						


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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-15 17:44     ` Nicholas Knight
@ 2001-09-15 23:23       ` Alan Cox
  0 siblings, 0 replies; 38+ messages in thread
From: Alan Cox @ 2001-09-15 23:23 UTC (permalink / raw)
  To: tegeran; +Cc: Alan Cox, VDA, Petr Vandrovec, linux-kernel

> Not being a developer or guru on the internal software workings of the 
> hardware here, I have to ask, does this clear up some bug, or does it 
> disable the optimizations causing the problem? Is this a *fix* or a 
> band-aid?

Without documentation - who knows


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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-14 23:16   ` Alan Cox
  2001-09-15 17:44     ` Nicholas Knight
@ 2001-09-15 18:02     ` Jonathan Morton
  2001-09-16  1:52     ` Petr Vandrovec
  2 siblings, 0 replies; 38+ messages in thread
From: Jonathan Morton @ 2001-09-15 18:02 UTC (permalink / raw)
  To: tegeran; +Cc: linux-kernel

>  > > +static void __init pci_fixup_athlon_bug(struct pci_dev *d)
>>  > +{
>>  > +       u8 v;
>>  > +       pci_read_config_byte(d, 0x55, &v);
>>  > +       if(v & 0x80) {
>>  > +               printk(KERN_NOTICE "Stomping on Athlon bug.\n");
>>  > +               v &= 0x7f; /* clear bit 55.7 */
>>  > +               pci_write_config_byte(d, 0x55, v);
>>  > +       }
>>  > +}
>>  >
>>  > Well, these are cosmetic changes anyway...
>>  > What is more important now:
>>  > 1) Do we have people who still see Athlon bug with the patch?
>>  > 2) Do Alan read these messages? ;-)
>>
>>  Im watching the discussion with interest. If it proves to be the magic
>>  bullet I will ask VIA for guidance on the issue
>
>Not being a developer or guru on the internal software workings of the
>hardware here, I have to ask, does this clear up some bug, or does it
>disable the optimizations causing the problem? Is this a *fix* or a
>band-aid?

AFAICT, it's a *fix*.  The register in question is "for debug use 
only, never write anything other than zero in it" but generally shows 
non-zero when a faulty BIOS is installed.  We're zeroing the bit that 
appears to cause the problem.  It's highly unlikely to be an extra 
optimisation - if it is, it's an unsafe one.

-- 
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
           V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-14 23:16   ` Alan Cox
@ 2001-09-15 17:44     ` Nicholas Knight
  2001-09-15 23:23       ` Alan Cox
  2001-09-15 18:02     ` Jonathan Morton
  2001-09-16  1:52     ` Petr Vandrovec
  2 siblings, 1 reply; 38+ messages in thread
From: Nicholas Knight @ 2001-09-15 17:44 UTC (permalink / raw)
  To: Alan Cox, VDA; +Cc: Petr Vandrovec, linux-kernel

On Friday 14 September 2001 04:16 pm, Alan Cox wrote:
> > +static void __init pci_fixup_athlon_bug(struct pci_dev *d)
> > +{
> > +       u8 v;
> > +       pci_read_config_byte(d, 0x55, &v);
> > +       if(v & 0x80) {
> > +               printk(KERN_NOTICE "Stomping on Athlon bug.\n");
> > +               v &= 0x7f; /* clear bit 55.7 */
> > +               pci_write_config_byte(d, 0x55, v);
> > +       }
> > +}
> >
> > Well, these are cosmetic changes anyway...
> > What is more important now:
> > 1) Do we have people who still see Athlon bug with the patch?
> > 2) Do Alan read these messages? ;-)
>
> Im watching the discussion with interest. If it proves to be the magic
> bullet I will ask VIA for guidance on the issue

Not being a developer or guru on the internal software workings of the 
hardware here, I have to ask, does this clear up some bug, or does it 
disable the optimizations causing the problem? Is this a *fix* or a 
band-aid?

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
  2001-09-14 18:43 ` VDA
@ 2001-09-14 23:16   ` Alan Cox
  2001-09-15 17:44     ` Nicholas Knight
                       ` (2 more replies)
  2001-09-20 23:38   ` bill davidsen
  1 sibling, 3 replies; 38+ messages in thread
From: Alan Cox @ 2001-09-14 23:16 UTC (permalink / raw)
  To: VDA; +Cc: Petr Vandrovec, linux-kernel

> +static void __init pci_fixup_athlon_bug(struct pci_dev *d)
> +{ 
> +       u8 v; 
> +       pci_read_config_byte(d, 0x55, &v);
> +       if(v & 0x80) {
> +               printk(KERN_NOTICE "Stomping on Athlon bug.\n");
> +               v &= 0x7f; /* clear bit 55.7 */
> +               pci_write_config_byte(d, 0x55, v);
> +       }
> +}
> 
> Well, these are cosmetic changes anyway...
> What is more important now:
> 1) Do we have people who still see Athlon bug with the patch?
> 2) Do Alan read these messages? ;-)

Im watching the discussion with interest. If it proves to be the magic 
bullet I will ask VIA for guidance on the issue

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

* Re: Athlon: Try this (was: Re: Athlon bug stomping #2)
       [not found] <372BFCD7961@vcnet.vc.cvut.cz>
@ 2001-09-14 18:43 ` VDA
  2001-09-14 23:16   ` Alan Cox
  2001-09-20 23:38   ` bill davidsen
  0 siblings, 2 replies; 38+ messages in thread
From: VDA @ 2001-09-14 18:43 UTC (permalink / raw)
  To: Petr Vandrovec; +Cc: linux-kernel

Hello Petr,
Saturday, September 15, 2001, 10:16:59 AM, you wrote:
PV> Hi,
PV>   I'll sleep much better with ...

>> +static void __init pci_fixup_athlon_bug(struct pci_dev *d)
>> +{ 
>> +       u8 v; 
>> +       printk("Trying to stomp on Athlon bug...\n");
>> +       pci_read_config_byte(d, 0x55, &v);
PV>+       if (v & 0x80) {
>> +           v &= 0x7f; /* clear bit 55.7 */
>> +           pci_write_config_byte(d, 0x55, v);
PV>+       }

How about this:

+static void __init pci_fixup_athlon_bug(struct pci_dev *d)
+{ 
+       u8 v; 
+       pci_read_config_byte(d, 0x55, &v);
+       if(v & 0x80) {
+               printk(KERN_NOTICE "Stomping on Athlon bug.\n");
+               v &= 0x7f; /* clear bit 55.7 */
+               pci_write_config_byte(d, 0x55, v);
+       }
+}

Well, these are cosmetic changes anyway...
What is more important now:
1) Do we have people who still see Athlon bug with the patch?
2) Do Alan read these messages? ;-)
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/



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

end of thread, other threads:[~2001-09-20 23:38 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-09-13 12:31 Athlon bug stomping #2 VDA
2001-09-14  2:56 ` Roberto Jung Drebes
2001-09-14  4:02   ` Chris Vandomelen
2001-09-14  5:51     ` Eric W. Biederman
2001-09-14  7:34       ` Roberto Jung Drebes
2001-09-14  8:27         ` Athlon: Try this (was: Re: Athlon bug stomping #2) Roberto Jung Drebes
2001-09-14 18:19           ` Byron Stanoszek
2001-09-15 18:00             ` Liakakis Kostas
2001-09-15 20:28               ` VDA
2001-09-15  7:15           ` brian
2001-09-19  1:30             ` brian
2001-09-19 13:10             ` Re[2]: " VDA
2001-09-19 23:56               ` Nicholas Knight
2001-09-20  3:17                 ` Nicholas Knight
2001-09-20 12:34                   ` Alan Cox
2001-09-16 21:53           ` Carsten Leonhardt
2001-09-19  3:55             ` Dan Hollis
2001-09-14  9:26         ` Jeff Lightfoot
     [not found] <372BFCD7961@vcnet.vc.cvut.cz>
2001-09-14 18:43 ` VDA
2001-09-14 23:16   ` Alan Cox
2001-09-15 17:44     ` Nicholas Knight
2001-09-15 23:23       ` Alan Cox
2001-09-15 18:02     ` Jonathan Morton
2001-09-16  1:52     ` Petr Vandrovec
2001-09-16  7:21       ` Steffen Persvold
2001-09-16  8:08         ` Jan Niehusmann
2001-09-19  3:47           ` Albert D. Cahalan
2001-09-16 11:02       ` Vojtech Pavlik
2001-09-16 13:53         ` Alan Cox
2001-09-16 13:50           ` Vojtech Pavlik
2001-09-16 14:47             ` Alan Cox
2001-09-16 17:01               ` Vojtech Pavlik
2001-09-16 16:52           ` Roberto Jung Drebes
2001-09-17  0:58             ` Petr Vandrovec
2001-09-17  1:37               ` Ignacio Vazquez-Abrams
2001-09-17 14:59                 ` Jonathan Morton
2001-09-18 11:27       ` jury gerold
2001-09-20 23:38   ` bill davidsen

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).