I updated my motherboard from ASUS A7V to ABIT KT7A (VIA Apollo KT133A
chipset). The kernel I had (2.4.10) started crashing on boot 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.
I also search the mailing list. My mother board is KT7A series v1.3 with
bios revision 4T (I also try with 3N, same results). K7 at 1333MHz. BIOS
settings are default (except I have disabled all BIOS/video shadow).
After flash I also reset CMOS via hardware jumper.
Is there any solution to this (except compiling kernel for 6x86)?
TIA
Oh no.
Anybody still insist that 'Athlon bug' patch is not to be
included into mainstream kernel?
If someone doesn't like it, feel free to make it a config
option (enabled by default!) and submit an updated patch.
My original patch against 2.4.9 is at the end.
Tuesday, October 09, 2001, 11:32:24 AM,
"Marco Berizzi" <[email protected]> wrote:
MB> I updated my motherboard from ASUS A7V to ABIT KT7A (VIA Apollo KT133A
MB> chipset). The kernel I had (2.4.10) started crashing on boot usually
MB> right after starting init. I tryed a i686 kernel and noticed it works
MB> OK, so I recompiled my crashy kernel only switching the processor type
MB> and it also worked. Changed it back to Athlon/K7/Duron and it starts
MB> crashing.
MB> I also search the mailing list. My mother board is KT7A series v1.3 with
MB> bios revision 4T (I also try with 3N, same results). K7 at 1333MHz. BIOS
MB> settings are default (except I have disabled all BIOS/video shadow).
MB> After flash I also reset CMOS via hardware jumper.
MB> Is there any solution to this (except compiling kernel for 6x86)?
--
Best regards, VDA
mailto:[email protected]
--- pci-pc.c.orig Sun Aug 12 15:54:07 2001
+++ pci-pc.c Tue Sep 18 16:45:21 2001
@@ -948,6 +948,26 @@
d->irq = 9;
}
+/* Fixes some oopses on Athlon optimized
+ * 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)
+ * > Bits 7-0: Reserved (do not program). default = 0
+ * ABIT KT7A 3R BIOS: 0x89 (oopses)
+ * ABIT KT7A YH BIOS: 0x00 (works)
+ */
+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);
+ }
+}
+
struct pci_fixup pcibios_fixups[] = {
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82451NX, pci_fixup_i450nx },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82454GX, pci_fixup_i450gx },
@@ -961,6 +981,7 @@
/* Our bus code shouldnt need this fixup any more. Delete once
verified */
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_COMPAQ,
PCI_DEVICE_ID_COMPAQ_6010, pci_fixup_compaq },
#endif
+ { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_8363_0, pci_fixup_athlon_bug },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_UMC,
PCI_DEVICE_ID_UMC_UM8886BF, pci_fixup_umc_ide },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SI,
PCI_DEVICE_ID_SI_5513, pci_fixup_ide_trash },
{ PCI_FIXUP_HEADER, PCI_ANY_ID, PCI_ANY_ID,
pci_fixup_ide_bases },
ohhh thanks for the real time response. It's the first time I'm posting
to this mailing list.
Could I try to patch also 2.4.10 kernel? This patch will be included in
kernel 2.4.11?
----- Original Message -----
From: "VDA" <[email protected]>
To: "Marco Berizzi" <[email protected]>;
<[email protected]>
Sent: Tuesday, October 09, 2001 1:45 PM
Subject: [PATCH] again: Re: Athlon kernel crash (i686 works)
> Oh no.
>
> Anybody still insist that 'Athlon bug' patch is not to be
> included into mainstream kernel?
> If someone doesn't like it, feel free to make it a config
> option (enabled by default!) and submit an updated patch.
> My original patch against 2.4.9 is at the end.
>
> Tuesday, October 09, 2001, 11:32:24 AM,
> "Marco Berizzi" <[email protected]> wrote:
> MB> I updated my motherboard from ASUS A7V to ABIT KT7A (VIA Apollo
KT133A
> MB> chipset). The kernel I had (2.4.10) started crashing on boot
usually
> MB> right after starting init. I tryed a i686 kernel and noticed it
works
> MB> OK, so I recompiled my crashy kernel only switching the processor
type
> MB> and it also worked. Changed it back to Athlon/K7/Duron and it
starts
> MB> crashing.
>
> MB> I also search the mailing list. My mother board is KT7A series
v1.3 with
> MB> bios revision 4T (I also try with 3N, same results). K7 at
1333MHz. BIOS
> MB> settings are default (except I have disabled all BIOS/video
shadow).
> MB> After flash I also reset CMOS via hardware jumper.
>
> MB> Is there any solution to this (except compiling kernel for 6x86)?
> --
> Best regards, VDA
> mailto:[email protected]
>
> --- pci-pc.c.orig Sun Aug 12 15:54:07 2001
> +++ pci-pc.c Tue Sep 18 16:45:21 2001
> @@ -948,6 +948,26 @@
> d->irq = 9;
> }
>
> +/* Fixes some oopses on Athlon optimized
> + * 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)
> + * > Bits 7-0: Reserved (do not program). default = 0
> + * ABIT KT7A 3R BIOS: 0x89 (oopses)
> + * ABIT KT7A YH BIOS: 0x00 (works)
> + */
> +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);
> + }
> +}
> +
> struct pci_fixup pcibios_fixups[] = {
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_82451NX, pci_fixup_i450nx },
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_82454GX, pci_fixup_i450gx },
> @@ -961,6 +981,7 @@
> /* Our bus code shouldnt need this fixup any more. Delete once
> verified */
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_COMPAQ,
> PCI_DEVICE_ID_COMPAQ_6010, pci_fixup_compaq },
> #endif
> + { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_8363_0, pci_fixup_athlon_bug },
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_UMC,
> PCI_DEVICE_ID_UMC_UM8886BF, pci_fixup_umc_ide },
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SI,
> PCI_DEVICE_ID_SI_5513, pci_fixup_ide_trash },
> { PCI_FIXUP_HEADER, PCI_ANY_ID, PCI_ANY_ID,
> pci_fixup_ide_bases },
>
>
>
Hi!
> Could I try to patch also 2.4.10 kernel?
You can do this 'by hand'. 2.4.10 changed the structure a bit. But I sent
VDA a modified patch some time ago. Maybe just ask him.
> This patch will be included in kernel 2.4.11?
I don't think so. :(
Honestly I'm not happy about this, but there had beed a large discussion
about it. There were some people which mobo worked right 'out of the box',
and they found that others should patch their kernels by hand to be able
to use their linux boxes. :(((
Gergely
ps: I use this patch too on an ABIT KT7A mobo with Duron 750
I'm happy with this patch too, as it stops my machine from crashing when switching to user-space.
I've run several LMbench tests against both 686-optimized and Athlon-optimized kernels. The
results waver across multiple tests, one kernel winning some tests one time and losing the next,
but the values are all close. I can post the results of any benchmarks 686 vs Athlon anyone wants
me to run if we can get this patch in soon!
Here's the dump of my LMbench runs, if anyone wants to oggle the numbers:
L M B E N C H 2 . 0 S U M M A R Y
------------------------------------
Basic system parameters
----------------------------------------------------
Host OS Description Mhz
--------- ------------- ----------------------- ----
Athlon-1 Linux 2.4.10- i686-pc-linux-gnu 1333
Athlon-2 Linux 2.4.10- i686-pc-linux-gnu 1333
i686-1 Linux 2.4.10- i686-pc-linux-gnu 1333
i686-2 Linux 2.4.10- i686-pc-linux-gnu 1333
Processor, Processes - times in microseconds - smaller is better
----------------------------------------------------------------
Host OS Mhz null null open selct sig sig fork exec sh
call I/O stat clos TCP inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ----
Athlon-1 Linux 2.4.10- 1333 0.21 0.29 4.93 5.74 17.1 0.60 1.90 142. 770. 8593
Athlon-2 Linux 2.4.10- 1333 0.21 0.29 5.24 5.98 28.8 0.60 1.90 152. 823. 8771
i686-1 Linux 2.4.10- 1333 0.21 0.29 4.61 5.47 29.5 0.60 1.91 141. 776. 8670
i686-2 Linux 2.4.10- 1333 0.20 0.29 5.02 5.86 32.7 0.60 1.88 156. 870. 8871
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
Athlon-1 Linux 2.4.10- 1.030 1.2900 11.6 3.5800 125.5 20.2 126.7
Athlon-2 Linux 2.4.10- 0.820 1.3800 11.7 3.6200 125.8 27.4 126.2
i686-1 Linux 2.4.10- 0.820 1.3100 11.6 3.8400 125.8 24.6 125.9
i686-2 Linux 2.4.10- 0.590 1.2700 11.7 3.9100 125.5 20.7 126.1
*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP
ctxsw UNIX UDP TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
Athlon-1 Linux 2.4.10- 1.030 3.227 5.41 9.664 21.8 12.1 32.7 49.5
Athlon-2 Linux 2.4.10- 0.820 4.015 6.78 10.4 23.0 14.0 33.9 50.8
i686-1 Linux 2.4.10- 0.820 3.510 6.01 9.569 21.5 12.2 33.4 599K
i686-2 Linux 2.4.10- 0.590 4.153 6.75 10.1 23.0 13.2 34.1 18.M
File & VM system latencies in microseconds - smaller is better
--------------------------------------------------------------
Host OS 0K File 10K File Mmap Prot Page
Create Delete Create Delete Latency Fault Fault
--------- ------------- ------ ------ ------ ------ ------- ----- -----
Athlon-1 Linux 2.4.10- 29.1 41.5 190.1 66.0 523.0 0.448 2.00000
Athlon-2 Linux 2.4.10- 30.9 43.9 199.3 64.2 537.0 0.429 2.00000
i686-1 Linux 2.4.10- 29.0 41.9 209.4 65.2 532.0 0.634 2.00000
i686-2 Linux 2.4.10- 31.0 44.1 187.1 64.5 610.0 0.436 2.00000
*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------
Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem
UNIX reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
Athlon-1 Linux 2.4.10- 847. 685. 311. 332.4 501.3 176.2 206.2 471. 342.5
Athlon-2 Linux 2.4.10- 882. 586. 187. 331.6 510.2 177.6 207.1 484. 343.5
i686-1 Linux 2.4.10- 863. 586. 299. 320.0 510.2 176.3 206.6 472. 342.6
i686-2 Linux 2.4.10- 874. 318. 199. 319.6 520.2 177.7 206.8 486. 343.5
Memory latencies in nanoseconds - smaller is better
(WARNING - may not be correct, check graphs)
---------------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem Guesses
--------- ------------- ---- ----- ------ -------- -------
Athlon-1 Linux 2.4.10- 1333 2.259 15.1 155.3
Athlon-2 Linux 2.4.10- 1333 2.259 15.1 155.4
i686-1 Linux 2.4.10- 1333 2.259 15.1 155.3
i686-2 Linux 2.4.10- 1333 2.259 15.1 155.3
Hi.
Could somebody explain me this comment?:
/*
* Incoming packets are placed on per-cpu queues so
that
* no locking is needed.
*/
struct softnet_data
{
int throttle;
int cng_level;
int avg_blog;
struct sk_buff_head input_pkt_queue;
struct net_device *output_queue;
struct sk_buff *completion_queue;
} __attribute__((__aligned__(SMP_CACHE_BYTES)));
I didn't understand why packets are placed so and why
locking isn't needed?
__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
Kirill Ratkin wrote:
>Hi.
>
>Could somebody explain me this comment?:
>/*
> * Incoming packets are placed on per-cpu queues so
>that
> * no locking is needed.
> */
>
>struct softnet_data
>{
> int throttle;
> int cng_level;
> int avg_blog;
> struct sk_buff_head input_pkt_queue;
> struct net_device *output_queue;
> struct sk_buff *completion_queue;
>} __attribute__((__aligned__(SMP_CACHE_BYTES)));
>
>I didn't understand why packets are placed so and why
>locking isn't needed?
>
As I understand this, the only reason u lock is
1) In an SMP or multiprocessor system, you suspect somebody else is running
simultaneously with you, this can lead to two or more processors executing
the same code simultaneously, this may lead to races.(which u do not want).
2) In a Multiprocessor or uniprocesor, data is shared among user processes in the kernel
or
between a user process in the kernel and an interrupt context
(like an irq handler or a bottom half or a tasklet).
So if u have a situation where (2) does not hold and u have a multiprocessor system,
per CPU data need not be locked, since it is not visible/used by other processors.
Did I get it right?
Balbir
>
>__________________________________________________
>Do You Yahoo!?
>NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
>http://geocities.yahoo.com/ps/info1
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, 9 Oct 2001, Kirill Ratkin wrote:
> Could somebody explain me this comment?:
> /*
> * Incoming packets are placed on per-cpu queues so that
> * no locking is needed.
> */
> I didn't understand why packets are placed so and why
> locking isn't needed?
Each CPU has its own data structure here. This means no
other CPU will touch this queue (they have their own)
so there is nobody we could ever race against.
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed)
http://www.surriel.com/ http://distro.conectiva.com/
>
>
>
>Each CPU has its own data structure here. This means no
>other CPU will touch this queue (they have their own)
>so there is nobody we could ever race against.
>
We would still require locking or interrupt disabling if this data is used
from an interrupt context (due to re-enterency issues), wouldn't we Rik?
Regards,
Balbir
>
>
>regards,
>
>Rik
>
On Tue, 9 Oct 2001, BALBIR SINGH wrote:
> >Each CPU has its own data structure here. This means no
> >other CPU will touch this queue (they have their own)
> >so there is nobody we could ever race against.
>
> We would still require locking or interrupt disabling if this data is used
> from an interrupt context (due to re-enterency issues), wouldn't we Rik?
I think this code is only run from interrupt context anyway.
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed)
http://www.surriel.com/ http://distro.conectiva.com/
Could my random kernel oopses be caused by that bug?
I have a VIA (ASUS A7V) cipset an K7 1000Mhz, and sometimes the kernel crash.
I just updated to kernel 2.4.10, and the first problem is that I get a random
oops if I try to load analog.o with modprobe. I sent a report of this problem
two days ago.
Could that patch solve my problem?
Alejandro Conty wrote:
>
> Could my random kernel oopses be caused by that bug?
>
> I have a VIA (ASUS A7V) cipset an K7 1000Mhz, and sometimes the kernel crash.
> I just updated to kernel 2.4.10, and the first problem is that I get a random
> oops if I try to load analog.o with modprobe. I sent a report of this problem
> two days ago.
>
> Could that patch solve my problem?
The oops with the analog joystick driver is fixed in 2.4.11-preX.
--
Brian Gerst
On Tue, 9 Oct 2001, Bryan Mayland wrote:
> I'm happy with this patch too, as it stops my machine from crashing when switching to user-space.
> I've run several LMbench tests against both 686-optimized and Athlon-optimized kernels. The
> results waver across multiple tests, one kernel winning some tests one time and losing the next,
> but the values are all close. I can post the results of any benchmarks 686 vs Athlon anyone wants
> me to run if we can get this patch in soon!
That's what I see... the patch doesn't make things faster, it prevents the
system from failing due to user space code. If it was just a speed thing I
wouldn't feel strongly about getting it in production.
The other thing is that I don't buy "some people don't need it" when some
people can't run without it and no one yet has stated that it impaired the
function of their system.
Given that some systems are vulnerable to user code induced failuers
without the patch, and there are no reports that the patch causes problems
on any system, and it's optional in config anyway, why the resistance. The
"we know what you need" attitude belongs in that other o/s, not
Linux. Make it experimental, there are lots of other "use at your own
risk" options in config!
--
bill davidsen <[email protected]>
"If I were a diplomat, in the best case I'd go hungry. In the worst
case, people would die."
-- Robert Lipe
Il 13:45, marted? 9 ottobre 2001, VDA ha scritto:
> Anybody still insist that 'Athlon bug' patch is not to be
> included into mainstream kernel?
> If someone doesn't like it, feel free to make it a config
> option (enabled by default!) and submit an updated patch.
> My original patch against 2.4.9 is at the end.
>
> Tuesday, October 09, 2001, 11:32:24 AM,
> "Marco Berizzi" <[email protected]> wrote:
> MB> I updated my motherboard from ASUS A7V to ABIT KT7A (VIA Apollo KT133A
> MB> chipset). The kernel I had (2.4.10) started crashing on boot usually
> MB> right after starting init. I tryed a i686 kernel and noticed it works
> MB> OK, so I recompiled my crashy kernel only switching the processor type
> MB> and it also worked. Changed it back to Athlon/K7/Duron and it starts
> MB> crashing.
Same problem here (oops at boot, athlon 1.2GHz, kernels 2.4.9 ->10, athlon
optimization. All goes right if I set i686 processor) but the patch didn't
work. I have a GA-7VMM / VIA KLE 133 AGPset Motherboard. The kernel still
oopses , it only changes color:) (white on black without patch, green on
black with patch applied.)
I will be happy to test any new patch, if this can help.
--
Fabio Coatti
Ferrara Linux User Group
> Hi!
>
> > Could my random kernel oopses be caused by that bug?
>
> I'm not sure, but I think no. If you hit this bug, you're even not able to
> start Linux. In most - if not all - reported cases, the computers did not
> reach the shell. They oopsed e.g. at init or shortly after passing it.
Ok, so is not that bug, I get an oops only once in a week.
>
> > I have a VIA (ASUS A7V) cipset an K7 1000Mhz, and sometimes the
>
> VIA KT133A ?
Yes. I just updated to 2.4.10, so I will wait a few days and see what happens. By now I haven't had any crash (but the analog.o one, which is already fixed).
Hi!
> Ok, so is not that bug, I get an oops only once in a week.
>
> >
> > > I have a VIA (ASUS A7V) cipset an K7 1000Mhz, and sometimes the
> >
> > VIA KT133A ?
Another thing. Which BIOS do you use ? Everything seems to be ok until
BIOS rel. 3C . Patch is only required for computers with BIOS rel. 3R and
later (as shown today :)) ...
Gergely
thanks everybody for the response.
Last: my abit is KT7A series v1.3. Does anybody if it is safe to patch
bios with revision ZT?
----- Original Message -----
From: "Marek Mentel" <[email protected]>
To: "Marco Berizzi" <[email protected]>
Sent: Tuesday, October 09, 2001 7:38 PM
Subject: Re: Athlon kernel crash (i686 works)
> On Tue, 9 Oct 2001 11:32:24 +0200, Marco Berizzi wrote:
>
> >
> >I also search the mailing list. My mother board is KT7A series v1.3
with
> >bios revision 4T (I also try with 3N, same results). K7 at 1333MHz.
BIOS
> >settings are default (except I have disabled all BIOS/video shadow).
> >After flash I also reset CMOS via hardware jumper.
> >
> >Is there any solution to this (except compiling kernel for 6x86)?
> >
>
> Try ZT bios - it works ok with my ABIT KT7E - with Athlon
> optimised kernels.
> Using 686 optimised kernels is not full solution - user-space
> programs
> compiled with Atlhon optimisation can not only crash but kill
> sytem
> too ( as far as I remember from previous linux-kernel posts. )
>
> Not being kernel developer I must ask you to read archive messages
>
> on this topics - groups.google.com could be helpful .
>
>
> ----------------------------------------------------------------------
> --------------------------------
> Official BIOS release ZT for KT7/KT7-RAID/KT7A/KT7A-RAID/KT7E
>
>
> ftp://ftp.abit.com.tw/pub/bios/kt7
>
> Release information:
>
> 1. Adds three new options to enhance the system compatibility
>
> .Delay transaction
> .PCI master read caching
> .PCI master time-out
>
> Set above options to Disabled/Disabled/0 may help SB Live 5.1
> sound
> issue. If the system experiences low performance after these
> settings,
> enable the "PCI master read caching" please.
> 2. Fixes the issue Athlon 1.3G(100) wrongfully recognized as
> 104x12.5.
> 3. Adds an option "State after power failure".
> 4. Set all four IDE devices to "AUTO".
> 5. Set the default year to 2001.
> 6. BIOS compile date: 05/11/2001
>
>
>
> --------------------------------------------------------
> Marek Mentel [email protected] 2:484/3.8
> INSTITUTE FOR CHEMICAL PROCESSING OF COAL , Zabrze , POLAND
> NOTE: my opinions are strictly my own and not those of my employer
>
>
>
>
On Tue, 9 Oct 2001, Marco Berizzi wrote:
> I also search the mailing list. My mother board is KT7A series v1.3 with
> bios revision 4T (I also try with 3N, same results). K7 at 1333MHz. BIOS
> settings are default (except I have disabled all BIOS/video shadow).
> After flash I also reset CMOS via hardware jumper.
>
> Is there any solution to this (except compiling kernel for 6x86)?
There is a patch, that changes an unknown bit in the VIA chipset. You can
find it in the archives (search for "Athlon, Try this" or "athlon bug
stomping")
--
Roberto Jung Drebes <[email protected]>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/
On Tue, 9 Oct 2001, VDA wrote:
> Anybody still insist that 'Athlon bug' patch is not to be
> included into mainstream kernel?
> If someone doesn't like it, feel free to make it a config
> option (enabled by default!) and submit an updated patch.
> My original patch against 2.4.9 is at the end.
It should perhaps go in alan's pre-kernels, but it needs wide testing.
Want should make sure it doesn't break systems which are otherwise fine
without it.
And we still don't have any explanation from VIA what this mysterious bit
is supposed to do.
-Dan
--
[-] Omae no subete no kichi wa ore no mono da. [-]
On Tue, 9 Oct 2001, Gergely Tamas wrote:
> > Ok, so is not that bug, I get an oops only once in a week.
> > > > I have a VIA (ASUS A7V) cipset an K7 1000Mhz, and sometimes the
> > > VIA KT133A ?
> Another thing. Which BIOS do you use ? Everything seems to be ok until
> BIOS rel. 3C . Patch is only required for computers with BIOS rel. 3R and
> later (as shown today :)) ...
ASUS A7V is KT133, not KT133A...
-Dan
--
[-] Omae no subete no kichi wa ore no mono da. [-]
Yes, this patch shlud be included as configuration option,
(also because of the long nights spended discusing this topic and
seeing this thousands of lspci-vvvxxx output :) ), but not enabled
byu default and with a VERY VERY clear help.
Luigi
On Tue, 9 Oct 2001, VDA wrote:
> Oh no.
>
> Anybody still insist that 'Athlon bug' patch is not to be
> included into mainstream kernel?
> If someone doesn't like it, feel free to make it a config
> option (enabled by default!) and submit an updated patch.
> My original patch against 2.4.9 is at the end.
>
> Tuesday, October 09, 2001, 11:32:24 AM,
> "Marco Berizzi" <[email protected]> wrote:
> MB> I updated my motherboard from ASUS A7V to ABIT KT7A (VIA Apollo KT133A
> MB> chipset). The kernel I had (2.4.10) started crashing on boot usually
> MB> right after starting init. I tryed a i686 kernel and noticed it works
> MB> OK, so I recompiled my crashy kernel only switching the processor type
> MB> and it also worked. Changed it back to Athlon/K7/Duron and it starts
> MB> crashing.
>
> MB> I also search the mailing list. My mother board is KT7A series v1.3 with
> MB> bios revision 4T (I also try with 3N, same results). K7 at 1333MHz. BIOS
> MB> settings are default (except I have disabled all BIOS/video shadow).
> MB> After flash I also reset CMOS via hardware jumper.
>
> MB> Is there any solution to this (except compiling kernel for 6x86)?
> --
> Best regards, VDA
> mailto:[email protected]
>
> --- pci-pc.c.orig Sun Aug 12 15:54:07 2001
> +++ pci-pc.c Tue Sep 18 16:45:21 2001
> @@ -948,6 +948,26 @@
> d->irq = 9;
> }
>
> +/* Fixes some oopses on Athlon optimized
> + * 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)
> + * > Bits 7-0: Reserved (do not program). default = 0
> + * ABIT KT7A 3R BIOS: 0x89 (oopses)
> + * ABIT KT7A YH BIOS: 0x00 (works)
> + */
> +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);
> + }
> +}
> +
> struct pci_fixup pcibios_fixups[] = {
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_82451NX, pci_fixup_i450nx },
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_82454GX, pci_fixup_i450gx },
> @@ -961,6 +981,7 @@
> /* Our bus code shouldnt need this fixup any more. Delete once
> verified */
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_COMPAQ,
> PCI_DEVICE_ID_COMPAQ_6010, pci_fixup_compaq },
> #endif
> + { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_8363_0, pci_fixup_athlon_bug },
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_UMC,
> PCI_DEVICE_ID_UMC_UM8886BF, pci_fixup_umc_ide },
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SI,
> PCI_DEVICE_ID_SI_5513, pci_fixup_ide_trash },
> { PCI_FIXUP_HEADER, PCI_ANY_ID, PCI_ANY_ID,
> pci_fixup_ide_bases },
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
on 2.4.10
*** linux/arch/i386/kernel/pci-pc.c Mon Sep 24 00:21:37 2001
--- 2.4.10/arch/i386/kernel/pci-pc.c Sat Sep 29 12:03:13 2001
***************
*** 907,912 ****
--- 907,928 ----
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)
{
***************
*** 1172,1177 ****
--- 1188,1194 ----
{ 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 }
};
On Tue, 9 Oct 2001, Gergely Tamas wrote:
> Hi!
>
> > Could I try to patch also 2.4.10 kernel?
>
> You can do this 'by hand'. 2.4.10 changed the structure a bit. But I sent
> VDA a modified patch some time ago. Maybe just ask him.
>
> > This patch will be included in kernel 2.4.11?
>
> I don't think so. :(
>
> Honestly I'm not happy about this, but there had beed a large discussion
> about it. There were some people which mobo worked right 'out of the box',
> and they found that others should patch their kernels by hand to be able
> to use their linux boxes. :(((
>
> Gergely
>
> ps: I use this patch too on an ABIT KT7A mobo with Duron 750
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> I've run several LMbench tests against both 686-optimized
> and Athlon-optimized kernels. The results waver across multiple
> tests, one kernel winning some tests one time and losing the next,
> but the values are all close.
The benefits of the kernel Athlon optimizations are higher memory bandwidth
for bulk copies/clears and less cache pollution. But LMbench isn't going to
show any difference, because its tests use generic x86 mem*() functions, not
Athlon-optimized SSE memory routines like in the Athlon kernel.
*Local* Communication bandwidths in MB/s - bigger is better
Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem
UNIX reread reread (libc) (hand) read
write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- ----
-
Athlon-1 Linux 2.4.10- 847. 685. 311. 332.4 501.3 176.2 206.2 471.
342.5
Athlon-2 Linux 2.4.10- 882. 586. 187. 331.6 510.2 177.6 207.1 484.
343.5
i686-1 Linux 2.4.10- 863. 586. 299. 320.0 510.2 176.3 206.6 472.
342.6
i686-2 Linux 2.4.10- 874. 318. 199. 319.6 520.2 177.7 206.8 486.
343.5
It should be obvious that LMbench uses sub-optimal memory routines, since
the numbers for "Bcopy" and "Mem read/write" bandwidth are so much lower
than pipe and AF UNIX bandwidths! (the pipe/UNIX tests are basically
equivalent to Bcopy, plus extra user<->kernel transitions and context
switches).
The only cases where I'd expect the Athlon kernel to do better on LMbench
are essentially kernel memcpy() benchmarks - pipe and AF UNIX bandwidths.
I'm not sure if the kernel pipe and UNIX socket code actually uses
Athlon-optimized routines; in any case the small buffer sizes (eg 4KB for
pipes) could be hiding any performance gain.
Regards,
Dan
>> I've run several LMbench tests against both 686-optimized
>> and Athlon-optimized kernels. The results waver across multiple
>> tests, one kernel winning some tests one time and losing the next,
>> but the values are all close.
DM> The benefits of the kernel Athlon optimizations are higher memory bandwidth
DM> for bulk copies/clears and less cache pollution. But LMbench isn't going to
DM> show any difference, because its tests use generic x86 mem*() functions, not
DM> Athlon-optimized SSE memory routines like in the Athlon kernel.
There are no SSE optimizations (yet).
There are prefetch/movntq tricks.
Optimized fast_clear_page() is 3x faster than normal one,
optimized fast_copy_page() is 1.5x faster than normal one.
(roughly, it depends on your mem and CPU MHz)
I can mail a test program to you if you are curious.
--
Best regards, VDA
mailto:[email protected]