[GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Jonathan Morton]

>Today I updated the BIOS of my motherboard, a ABIT KT7A (VIA Apollo KT133A
>chipset). The kernel I had (2.4.9) started crashing on boot with an
>invalid page fault, usually right after starting init. I tryed a i686
>kernel and noticed it works OK, so I recompiled my crashy kernel only
>switching the processor type and it also worked. changed it back to
>Athlon/K7/Duron and it starts crashing.
>
>Anyone else experiencing this?

BINGO!

This problem is known about, but this is the first report we've had 
of it on a Duron (as opposed to Athlon), and you've successfully 
tracked it down to the updated BIOS.

We need the versions of your old and new BIOSes, as accurately as you 
can make it.

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

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Gergely Tamas]

Hi!

Some time ago I had the same problem, but because I had no ability to grep
output I ``solved'' this with a BIOS downgrade. :)

 > We need the versions of your old and new BIOSes, as accurately as you
 > can make it.

The correct working version is kt73c and the latest kt73r has this
problem.

Gergely

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Gergely Tamas]

Hi!

 > The correct working version is kt73c and the latest kt73r has this
 > problem.

And of course - sorry, I forgot it to write in previous mail - same mobo,
ABIT KT7A and BIOSes are available at e.g.
ftp://ftp.leo.org/pub/comp/general/devices/abit/bios/kt7/

Gergely

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Jonathan Morton]

>  > The correct working version is kt73c and the latest kt73r has this
>  > problem.
>
>And of course - sorry, I forgot it to write in previous mail - same mobo,
>ABIT KT7A and BIOSes are available at e.g.
>ftp://ftp.leo.org/pub/comp/general/devices/abit/bios/kt7/

I have a KT7 mb with the (fairly old) UL BIOS, works fine with my 
1G/100 Athlon.  I also just got the system working again after a HD 
failure.  Perhaps I should try different BIOSes (including the 3C and 
3R) and see if I get it to fail...

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

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Nicholas Knight]

On Tuesday 11 September 2001 04:21 am, Jonathan Morton wrote:
> >Today I updated the BIOS of my motherboard, a ABIT KT7A (VIA Apollo
> > KT133A chipset). The kernel I had (2.4.9) started crashing on boot
> > with an invalid page fault, usually right after starting init. I
> > tryed a i686 kernel and noticed it works OK, so I recompiled my
> > crashy kernel only switching the processor type and it also worked.
> > changed it back to Athlon/K7/Duron and it starts crashing.
> >
> >Anyone else experiencing this?
>
> BINGO!
>
> This problem is known about, but this is the first report we've had
> of it on a Duron (as opposed to Athlon), and you've successfully
> tracked it down to the updated BIOS.
>

Actually we've had a couple reports on Durons on KT133A chipsets failing.
We've only had a couple reports of BIOS versions making a difference 
though, and it was never really clear which version did what.

> We need the versions of your old and new BIOSes, as accurately as you
> can make it.

Can someone compare the INTERNAL BIOS versions (as opposed to the 
external reported by the motherboard manufacturer)?

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[J.Brown (Ender/Amigo)]

I don't have any problems with the kernel, but if I'm compiling (say) the
kernel or any large program, user-mode apps like gcc, make, etc all
randomly segfault on me.

I'm running a Duron 800 on a Asus A7V133 mobo - and no bios version I've
tried has made a bit of difference yet :p

 - Ender


Regards,	| If I must have computer systems with publically
	 Ender  | available terminals, the maps they display of my complex
  (James Brown)	| will have a room clearly marked as the Main Control Room.
		| That room will be the Execution Chamber. The actual main
		| control room will be marked as Sewage Overflow Containment.

On Tue, 11 Sep 2001, Nicholas Knight wrote:

> Date: Tue, 11 Sep 2001 05:59:41 -0700
> From: Nicholas Knight <tegeran@home.com>
> To: Jonathan Morton <chromi@cyberspace.org>,
>      Roberto Jung Drebes <drebes@inf.ufrgs.br>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel
>     crash)
>
> On Tuesday 11 September 2001 04:21 am, Jonathan Morton wrote:
> > >Today I updated the BIOS of my motherboard, a ABIT KT7A (VIA Apollo
> > > KT133A chipset). The kernel I had (2.4.9) started crashing on boot
> > > with an invalid page fault, usually right after starting init. I
> > > tryed a i686 kernel and noticed it works OK, so I recompiled my
> > > crashy kernel only switching the processor type and it also worked.
> > > changed it back to Athlon/K7/Duron and it starts crashing.
> > >
> > >Anyone else experiencing this?
> >
> > BINGO!
> >
> > This problem is known about, but this is the first report we've had
> > of it on a Duron (as opposed to Athlon), and you've successfully
> > tracked it down to the updated BIOS.
> >
>
> Actually we've had a couple reports on Durons on KT133A chipsets failing.
> We've only had a couple reports of BIOS versions making a difference
> though, and it was never really clear which version did what.
>
> > We need the versions of your old and new BIOSes, as accurately as you
> > can make it.
>
> Can someone compare the INTERNAL BIOS versions (as opposed to the
> external reported by the motherboard manufacturer)?
> -
> 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/
>

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Roberto Jung Drebes]

On Tue, 11 Sep 2001, Jonathan Morton wrote:

> >  > The correct working version is kt73c and the latest kt73r has this
> >  > problem.
> >
> >And of course - sorry, I forgot it to write in previous mail - same mobo,
> >ABIT KT7A and BIOSes are available at e.g.
> >ftp://ftp.leo.org/pub/comp/general/devices/abit/bios/kt7/
> 
> I have a KT7 mb with the (fairly old) UL BIOS, works fine with my 
> 1G/100 Athlon.  I also just got the system working again after a HD 
> failure.  Perhaps I should try different BIOSes (including the 3C and 
> 3R) and see if I get it to fail...

Here, old BIOS == YH new BIOS == 3R.

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

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Luigi Genoni]

OK, on a trial athlon 1GhZ FSB 133 MHZ i did an upgrade from a well
working KT73c to KT73r and BOOM!

here i read from their changelog!!

1.Update BIOS code.

7.Enhance the high speed 133FSB Athlon
                    stability for KT7A/KT7A-RAID.

I think I should make a try with a 1300 Mhz 100MhzFSB!

effectivelly all my Athlon now wroks well using
KT73c bios, i never upgraded to a following one, but i made a further
check, and noticed that the first oops reports are older than this bios
release. So there is no way that first report could be related to
KT73r bios version. maybe also KT73n has problems.... (1.First release for
KT7A/KT7A-RAID V
                    1.3 or newer.)

Luigi

On Tue, 11 Sep 2001, Nicholas Knight wrote:

> On Tuesday 11 September 2001 04:21 am, Jonathan Morton wrote:
> > >Today I updated the BIOS of my motherboard, a ABIT KT7A (VIA Apollo
> > > KT133A chipset). The kernel I had (2.4.9) started crashing on boot
> > > with an invalid page fault, usually right after starting init. I
> > > tryed a i686 kernel and noticed it works OK, so I recompiled my
> > > crashy kernel only switching the processor type and it also worked.
> > > changed it back to Athlon/K7/Duron and it starts crashing.
> > >
> > >Anyone else experiencing this?
> >
> > BINGO!
> >
> > This problem is known about, but this is the first report we've had
> > of it on a Duron (as opposed to Athlon), and you've successfully
> > tracked it down to the updated BIOS.
> >
>
> Actually we've had a couple reports on Durons on KT133A chipsets failing.
> We've only had a couple reports of BIOS versions making a difference
> though, and it was never really clear which version did what.
>
> > We need the versions of your old and new BIOSes, as accurately as you
> > can make it.
>
> Can someone compare the INTERNAL BIOS versions (as opposed to the
> external reported by the motherboard manufacturer)?
> -
> 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/
>

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[VDA]

Ok, guys, since we know that Athlon bug is BIOS version dependent,
please do this:
* Flash 'bad' BIOS (one that makes Atlon-optimized kernel to oops)
* Reboot
* Save complete output of lspci -vvvxxx
* Flash 'good' BIOS
* Reboot
* Save complete output of lspci -vvvxxx
* Send me those captured outputs. Include BIOS versions pls.

Note: you don't need to boot with Athlon-optimized kernel.
I just want to compare what's the difference in chipset
programming with 'bad' and 'good' BIOS.
If you feel so inclined, do the comparison yourself
and report.

Does anybody have KT133A data sheet handy to look up
those PCI config register dumps?
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Janne Pänkälä]

> Does anybody have KT133A data sheet handy to look up
> those PCI config register dumps?

well VIA powered up their public site (www.viaarena.com) or whatever and
on the instant I put query of where all the datasheets have vanished.
(I managed at one point to download quite thoughout documentation about
VT82C598MVP but it has since vanished from their site)

They even replied to my post
"http://forums.viaarena.com/messageview.cfm?catid=6&threadid=103"

-----
                      Tuesday, September 11, 2001 1:50 AM 

                    Hi Epa, 

                    The list of datasheets currently available is here.
Some are not full versions, some are. If you want/need a datasheet, please
complete the request form on that page. 
-----

So I completed the request form and never heard from them again.
Too familiar? I thought so.

-- 
Janne
echo peufiuhu@tt.lac.nk | tr acefhiklnptu utpnlkihfeca

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Jonathan Morton]

>effectivelly all my Athlon now wroks well using
>KT73c bios, i never upgraded to a following one, but i made a further
>check, and noticed that the first oops reports are older than this bios
>release. So there is no way that first report could be related to
>KT73r bios version. maybe also KT73n has problems.... (1.First release for
>KT7A/KT7A-RAID V
>                     1.3 or newer.)

Or, more likely, the earlier reports came from m/board vendors who 
upgraded their *base* BIOS version earlier than ABIT, or who simply 
have flakier designs which fail even under the older versions. 
Notice that the first change listed for 3R is "update BIOS code" 
which probably means the AWARD 'base' code which supports the actual 
chipset rather than Abit-specific features.

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

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Dwayne C. Litzenberger]

[-- Attachment #1: Type: text/plain, Size: 9052 bytes --]

On Tue, Sep 11, 2001 at 12:21:22PM +0100, Jonathan Morton wrote:
> >Today I updated the BIOS of my motherboard, a ABIT KT7A (VIA Apollo KT133A
> >chipset). The kernel I had (2.4.9) started crashing on boot with an
> >invalid page fault, usually right after starting init. I tryed a i686
> >kernel and noticed it works OK, so I recompiled my crashy kernel only
> >switching the processor type and it also worked. changed it back to
> >Athlon/K7/Duron and it starts crashing.
> >
> >Anyone else experiencing this?
> 
> BINGO!
> 
> This problem is known about, but this is the first report we've had 
> of it on a Duron (as opposed to Athlon), and you've successfully 
> tracked it down to the updated BIOS.
> 
> We need the versions of your old and new BIOSes, as accurately as you 
> can make it.

I don't have time to do a full oops trace right now (I've never done one
before, so it would take some time, and I am somewhat busy with school work
right now), but I will confirm that I have an AMD Thunderbird 1200MHz with
a KT133A board, and it works fine with CONFIG_MK6 set, but CONFIG_MK7 craps
out with an oops soon after init starts.  I'm running kernel 2.4.8
(including the stock emu10k1 drivers) patched with the Debian FreeS/WAN
patch (though those are modules, and are not actually being loaded).

My BIOS code is the newest available from my motherboard manufacturer (the
board is a Future Power FP-KT133A, whose specs are at:
http://www.futurepowerusa.com/products/FP-kt133.htm )

I suppose if anyone's really interested, I can allocate some time to report
more on this problem.  Ask away!

Anyway, here's my current /proc/cpuinfo:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 4
model name      : AMD Athlon(tm) Processor
stepping        : 2
cpu MHz         : 1200.017
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips        : 2392.06

And lspci -vv:

00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
	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
	Region 0: Memory at d0000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [a0] AGP version 2.0
		Status: RQ=15 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode])
	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
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	Memory behind bridge: d6000000-d7ffffff
	Prefetchable memory behind bridge: d4000000-d5ffffff
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
	Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
	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
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
	Subsystem: VIA Technologies, Inc. Bus Master IDE
	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: 64
	Region 4: I/O ports at d000 [size=16]
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI])
	Subsystem: Unknown device 0925:1234
	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: 32, cache line size 08
	Interrupt: pin D routed to IRQ 11
	Region 4: I/O ports at d400 [size=32]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI])
	Subsystem: Unknown device 0925:1234
	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: 32, cache line size 08
	Interrupt: pin D routed to IRQ 11
	Region 4: I/O ports at d800 [size=32]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
	Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
	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-
	Capabilities: [68] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0a.0 Multimedia audio controller: Creative Labs SB Live! EMU10000 (rev 07)
	Subsystem: Creative Labs: Unknown device 8061
	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: 32 (500ns min, 5000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at dc00 [size=32]
	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:0a.1 Input device controller: Creative Labs SB Live! (rev 07)
	Subsystem: Creative Labs Gameport Joystick
	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: 32
	Region 0: I/O ports at e000 [size=8]
	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:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
	Subsystem: Realtek Semiconductor Co., Ltd. RT8139
	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: 32 (8000ns min, 16000ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at e400 [size=256]
	Region 1: Memory at d9000000 (32-bit, non-prefetchable) [size=256]
	Expansion ROM at <unassigned> [disabled] [size=64K]

01:00.0 VGA compatible controller: nVidia Corporation Vanta [NV6] (rev 15) (prog-if 00 [VGA])
	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: 248 (1250ns min, 250ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at d6000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at d4000000 (32-bit, prefetchable) [size=32M]
	Expansion ROM at <unassigned> [disabled] [size=64K]
	Capabilities: [60] 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-
	Capabilities: [44] AGP version 2.0
		Status: RQ=31 SBA- 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>


-- 
Dwayne C. Litzenberger - dlitz@dlitz.net

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

RE: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Alistair Phipps]

> >Today I updated the BIOS of my motherboard, a ABIT KT7A (VIA Apollo
KT133A
> >chipset). The kernel I had (2.4.9) started crashing on boot with an
> >invalid page fault, usually right after starting init. I tryed a i686
> >kernel and noticed it works OK, so I recompiled my crashy kernel only
> >switching the processor type and it also worked. changed it back to
> >Athlon/K7/Duron and it starts crashing.
> >
> >Anyone else experiencing this?
>
> BINGO!
>
> This problem is known about, but this is the first report we've had
> of it on a Duron (as opposed to Athlon), and you've successfully
> tracked it down to the updated BIOS.
>
> We need the versions of your old and new BIOSes, as accurately as you
> can make it.

I don't know if this is relevant, but on the Abit KT7 w/Duron 700 I'm using
right now, I upgraded from the -ZT BIOS to the -3R BIOS, and immediately had
problems booting.  I ran memtest86 (www.memtest86.com) and found that on
test 5 I was getting many errors at a particular address range (there had
been no errors with the previous BIOS).  I tried turning down the RAM speed
settings in the BIOS, but none helped - then I tried setting the "MD driving
strength" to "Lo" instead of "Hi" (Hi had been the default) and suddenly got
complete stability and no memory errors with memtest86, even at the high
performance RAM settings.

I can't test if this is related to the i686 vs Athlon "kernel" bug as I'm
not running Linux right now (long story - this isn't my own machine) but it
might be something worth checking.  The crashing occuring may actually be
caused by memory problems - I suggest everyone experiencing this test their
system with memtest86 - particularly tests 5 and 6.  It takes a long time
but may be worth it to rule out problematic RAM / BIOS settings for RAM.

- Alistair Phipps

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Alan Cox]

> 2.4.10pre[47]. My motherbord is Chaintech CT-7AIA2 (kt133A/686A), Duron 600.
> I did'nt see such things with kernels 2.4.[78]. The problem persists even 
> after recompiling kernel with K6-III optimisation. Note, this motherboard

Thats unrelated. Thats 2.4.10pre being exactly what it sounds - a buggy
pre-release snapshot

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[J.Brown (Ender/Amigo)]

Intresting. I'll try that, because it sounds exactly what I had (constant
segfaults in 2.2.18, occasional and more random in 2.4.x).


 - Ender

> A colleague purchased a number of A7V133s all of which exhibited seg faults
> in make and gcc. make reproducibly seg faulted in vfork(). This was
> with 2.2.18 kernels compiled for i586. We next tried a 2.4.8 kernel
> built for i686 and the problem persisted, though less reproducibly. The
> kernel reports 'Applying VIA southbridge workaround', but it looks
> like we need another fix.
>
> Most of the BIOS options had no effect, but changing the 'PCI latency'
> setting from 32 to 64 seems to have fixed it, fingers crossed.
>
> P.
>
> --
> +--------------------------------------------------+
> | Peter Horton      | pdh@colonel-panic.org        |
> | Software Engineer | http://www.colonel-panic.org |
> +--------------------------------------------------+
> -
> 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/
>

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Peter Horton]

On Wed, Sep 12, 2001 at 08:29:35AM +0400, Dmitry Volkoff wrote:
> >I don't have any problems with the kernel, but if I'm compiling (say) the
> >kernel or any large program, user-mode apps like gcc, make, etc all
> >randomly segfault on me.
> >
> >I'm running a Duron 800 on a Asus A7V133 mobo - and no bios version I've
> >tried has made a bit of difference yet :p
> 
> Same things here. I'm also experiencing random segfaults with kernels 
> 2.4.10pre[47]. My motherbord is Chaintech CT-7AIA2 (kt133A/686A), Duron 600.
> I did'nt see such things with kernels 2.4.[78]. The problem persists even 
> after recompiling kernel with K6-III optimisation. Note, this motherboard
> was rock solid and I never had any problems with athlon-optimised kernels
> prior to 2.4.9.
> 

A colleague purchased a number of A7V133s all of which exhibited seg faults
in make and gcc. make reproducibly seg faulted in vfork(). This was
with 2.2.18 kernels compiled for i586. We next tried a 2.4.8 kernel
built for i686 and the problem persisted, though less reproducibly. The
kernel reports 'Applying VIA southbridge workaround', but it looks
like we need another fix.

Most of the BIOS options had no effect, but changing the 'PCI latency'
setting from 32 to 64 seems to have fixed it, fingers crossed.

P.

-- 
+--------------------------------------------------+
| Peter Horton      | pdh@colonel-panic.org        |
| Software Engineer | http://www.colonel-panic.org |
+--------------------------------------------------+

Re: [GOLDMINE!!!] Athlon optimisation bug (was Re: Duron kernel crash)

[Dmitry Volkoff]

>I don't have any problems with the kernel, but if I'm compiling (say) the
>kernel or any large program, user-mode apps like gcc, make, etc all
>randomly segfault on me.
>
>I'm running a Duron 800 on a Asus A7V133 mobo - and no bios version I've
>tried has made a bit of difference yet :p

Same things here. I'm also experiencing random segfaults with kernels 
2.4.10pre[47]. My motherbord is Chaintech CT-7AIA2 (kt133A/686A), Duron 600.
I did'nt see such things with kernels 2.4.[78]. The problem persists even 
after recompiling kernel with K6-III optimisation. Note, this motherboard
was rock solid and I never had any problems with athlon-optimised kernels
prior to 2.4.9.

-- 

    DV