Hi,
This is a known problem I know, the screen problem
with some athlon computer due to some PCI optimization
code etc..; but how can I work around this. For
2.4.19-pre2 I remember to go somewhere to find pci.c
and comment out the code related, but in
2.4.19-pre6aa1 I got stuck..
Is there an official way to overcome/fix this problem
? (kernel build option?) Or just anyone interested in
doing such job?
Please help and copy your reply to my email address.
Thanks a lot
=====
Steve Kieu
http://messenger.yahoo.com.au - Yahoo! Messenger
- A great way to communicate long-distance for FREE!
Hi,
On Sat, Apr 13, 2002 at 06:58:40PM +1000, Steve Kieu wrote:
> This is a known problem I know, the screen problem
> with some athlon computer due to some PCI optimization
> code etc..; but how can I work around this. For
> 2.4.19-pre2 I remember to go somewhere to find pci.c
> and comment out the code related, but in
> 2.4.19-pre6aa1 I got stuck..
>
> Is there an official way to overcome/fix this problem
> ? (kernel build option?) Or just anyone interested in
> doing such job?
I don't know of an "official way".
There were a number of postings refering to
arch/i386/kernel/pci-pc.c: pci_fixup_via_northbridge_bug()
and claiming that not clearing bit 5 did make the problem go away.
(IOW: Replace v &= 0x1f; /* clear bits 5, 6, 7 */
by v &= 0x3f; /* clear bits 6, 7 */
and see whether this helps.)
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
>
> I don't know of an "official way".
I think this is a known problem but it is strange that
no one bother to implement something to make it easier
for the end user to compile their own kernel rather
than seraching the file and edit it . Of course I
believe my box is not the only one suffering such
problem.
> There were a number of postings refering to
> arch/i386/kernel/pci-pc.c:
> pci_fixup_via_northbridge_bug()
Just after posting my first email, I found the file,
yes it is in arch/i386/kernel/pci-pc.c and I just
comment out all lines in struct pci_fixup
pcibios_fixups[] related to VIA; that is
PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA etc...
I have no idea if this affects the system, but it
seemed that the problem is solved and no thing wierd
happened yet :-). May be if I got some trouble I will
set the bit as you said.
> and claiming that not clearing bit 5 did make the
> problem go away.
> (IOW: Replace v &= 0x1f; /* clear bits 5, 6, 7 */
> by v &= 0x3f; /* clear bits 6, 7 */
> and see whether this helps.)
>
> Regards,
Thanks for your reply
=====
Steve Kieu
http://messenger.yahoo.com.au - Yahoo! Messenger
- A great way to communicate long-distance for FREE!
Hi Steven,
On Tue, Apr 16, 2002 at 04:43:06PM +1000, Steve Kieu wrote:
> I think this is a known problem but it is strange that
> no one bother to implement something to make it easier
> for the end user to compile their own kernel rather
> than seraching the file and edit it.
The reason for the code there was that people had problems without it.
Somebody found some docu from VIA and came up with the patch that is now
in the kernel. And it helped those people.
So, it's not that nobody bothers, it's just that we don't want to break
those people's computers.
> Of course I believe my box is not the only one suffering such
> problem.
No, there have been a few reports on LKML.
> > arch/i386/kernel/pci-pc.c:
>
> Just after posting my first email, I found the file,
> yes it is in arch/i386/kernel/pci-pc.c and I just
> comment out all lines in struct pci_fixup
> pcibios_fixups[] related to VIA; that is
> PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA etc...
>
> I have no idea if this affects the system, but it
> seemed that the problem is solved and no thing wierd
> happened yet :-). May be if I got some trouble I will
> set the bit as you said.
You complain that no one bothers. The opposite is true:
Hacking solutions that work for some and not for others is just not
acceptable. But that's what you did now.
(Nothing wrong with it, if it helps you. But you don't help finding a
solution that works for everybody.)
> > and claiming that not clearing bit 5 did make the
> > problem go away.
> > (IOW: Replace v &= 0x1f; /* clear bits 5, 6, 7 */
> > by v &= 0x3f; /* clear bits 6, 7 */
> > and see whether this helps.)
It would be intersting to know. Maybe just clearing bits 6 and 7
would make everybody happy?
But the docu seems to indicate otherwise and there have not yet been
enough reports to be sure.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
OoO En cette matin?e ensoleill?e du mardi 16 avril 2002, vers 09:57,
Kurt Garloff <[email protected]> disait:
>> > and claiming that not clearing bit 5 did make the
>> > problem go away.
>> > (IOW: Replace v &= 0x1f; /* clear bits 5, 6, 7 */
>> > by v &= 0x3f; /* clear bits 6, 7 */
>> > and see whether this helps.)
> It would be intersting to know. Maybe just clearing bits 6 and 7
> would make everybody happy?
Another related hack is to modify latency of this northbridge to 0 and
to increase latency of "bandwidth eating" components. On
french-speaking newsgroup fr.comp.os.linux.moderated, we have several
reports that complete freeze of the system with TV cards can be
postponed (at least ; in my case, they disappeared) by this
tweak. Since, this is TV card related, I have already submitted this
to bttv maintainer (I haven't checked if latest revisions of bttv
include an option for this) but maybe decreasing to 0 the northbridge
latency could help some people too (with or without TV card).
--
BOFH excuse #5:
static from plastic slide rules