* 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; 29+ 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] 29+ messages in thread
* Re: Athlon: Try this (was: Re: Athlon bug stomping #2) 2001-09-14 18:43 ` Athlon: Try this (was: Re: Athlon bug stomping #2) 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ messages in thread
* Re: Athlon: Try this (was: Re: Athlon bug stomping #2) 2001-09-14 18:43 ` Athlon: Try this (was: Re: Athlon bug stomping #2) VDA 2001-09-14 23:16 ` Alan Cox @ 2001-09-20 23:38 ` bill davidsen 1 sibling, 0 replies; 29+ 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] 29+ messages in thread
* 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
0 siblings, 2 replies; 29+ 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] 29+ messages in thread
* Athlon: Try this (was: Re: Athlon bug stomping #2) 2001-09-14 7:34 Athlon bug stomping #2 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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-16 21:53 ` Carsten Leonhardt 2 siblings, 1 reply; 29+ 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] 29+ 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 0 siblings, 0 replies; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ messages in thread
* Re: Athlon: Try this (was: Re: Athlon bug stomping #2) 2001-09-14 7:34 Athlon bug stomping #2 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; 29+ 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] 29+ messages in thread
end of thread, other threads:[~2001-09-20 23:38 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <372BFCD7961@vcnet.vc.cvut.cz> 2001-09-14 18:43 ` Athlon: Try this (was: Re: Athlon bug stomping #2) 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 2001-09-14 7:34 Athlon bug stomping #2 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-16 21:53 ` Carsten Leonhardt 2001-09-19 3:55 ` Dan Hollis 2001-09-14 9:26 ` Jeff Lightfoot
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).