From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: "Prakash K. Cheemplavam" <prakashkc@gmx.de>
Cc: Martin Drab <drab@kepler.fjfi.cvut.cz>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: APIC/LAPIC hanging problems on nForce2 system.
Date: Thu, 6 Jan 2005 14:52:20 +0100 [thread overview]
Message-ID: <58cb370e05010605527f87297e@mail.gmail.com> (raw)
In-Reply-To: <41DCFEF0.5050105@gmx.de>
Hi,
On Thu, 06 Jan 2005 10:03:44 +0100, Prakash K. Cheemplavam
<prakashkc@gmx.de> wrote:
> Martin Drab schrieb:
> > On Wed, 5 Jan 2005, Prakash K. Cheemplavam wrote:
> >
> > ...
> > DEBUG: pci_fixup_nforce2() called.
> > DEBUG: nForce2 revision byte = 0xC1.
> > DEBUG: fixed value = 0x9F01FF01.
> > DEBUG: current value = 0x8F0FFF01. <---------------
> > ...
> >
> > So that means, that the device doesn't have the "C1 Halt Disconnect"
> > enabled at that point, and, though, no fixup is done. However, if you take
> > a closer look at the result of "lspci -xxx" (attached as "lspci-xxx.log"),
> >
> > 00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev c1)
> > ...
> > 60: 08 00 01 20 20 00 88 80 10 00 00 00 01 ff 0f 9f <-------
> > ...
> >
> > you'll notice, that all of a sudden that bit 28 of PCI.0x6c *is set!! That
> > means, that sometimes later, after the pci_fixup_nforce2() is called,
> > something, smewhere, somehow has to set the bit to 1. But this part in the
> > arch/i386/pci/fixup.c prevents it.
>
> You are not by chance using athcool or something to enable disconnect?
>
> >
> > /*
> > * Apply fixup only if C1 Halt Disconnect is enabled
> > * (bit28) because it is not supported on some boards.
> > */
> > vvvvvvvvvvvvvvvvv
> > if ((val & (1 << 28)) && val != fixed_val) {
> > printk(KERN_WARNING "PCI: nForce2 C1 Halt Disconnect fixup\n");
> > pci_write_config_dword(dev, 0x6c, fixed_val);
> > }
> >
> > So my question is: Is the condition necessary? If there really are boards,
> > that don't support this, then is would probably have to be a more
> > sophisticated test, or the fixup would have to be called again later, when
> > the flag is set. BTW.: Any clue on what could possibly set the flag?
>
> Well, I also think it is quite stupid to only apply the fix if
> disconnect is enabled at boot time and don't apply it if it is not. The
> kernel dev responsible for it is rather pedantic: Fix only when needed,
Hey, I only coded it because I was getting a lot of false IDE bugreports... ;-)
> ie don't apply anything in a foreseeing way (prevent what could break),
> if change something in userspace, do it correctly. (not exact words of
> course, but the conclusion of it.) Ie if you enable disconnect outside
> of bios and kernel, you should also set the fix by hand...
>
> Easy workaround: Enable disconnect in bios, if possible, then the kernel
> will fix it for you...
>
> I admit there is logic behind the dev's point of view, nevertheless it
> is not a very near-to-life-and-make-it-simpler-for-the-user logic. There
> is often a difference in point of view of kernel dev and average user...
Changing _only_ "fixup" bits seems like a reasonable compromise IMO.
Could you (or Martin) make a patch and submit it to -mm for testing?
Bartlomiej
next prev parent reply other threads:[~2005-01-06 13:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-05 15:28 Martin Drab
2005-01-05 16:05 ` Zwane Mwaikambo
2005-01-05 16:56 ` Martin Drab
2005-01-05 16:50 ` Prakash K. Cheemplavam
2005-01-05 17:06 ` Martin Drab
2005-01-05 17:17 ` Prakash K. Cheemplavam
2005-01-05 17:22 ` Martin Drab
2005-01-05 17:26 ` Prakash K. Cheemplavam
2005-01-05 17:30 ` Martin Drab
2005-01-06 0:14 ` Martin Drab
2005-01-06 9:03 ` Prakash K. Cheemplavam
2005-01-06 13:52 ` Bartlomiej Zolnierkiewicz [this message]
2005-01-06 15:04 ` [PATCH] " Prakash K. Cheemplavam
2005-01-06 23:46 ` Andrew Morton
2005-01-07 0:28 ` Prakash K. Cheemplavam
2005-01-07 0:49 ` Andrew Morton
2005-01-07 11:47 ` Martin Drab
2005-01-07 13:53 ` Prakash K. Cheemplavam
2005-01-07 15:34 ` Bartlomiej Zolnierkiewicz
2005-01-06 14:18 ` Martin Drab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58cb370e05010605527f87297e@mail.gmail.com \
--to=bzolnier@gmail.com \
--cc=drab@kepler.fjfi.cvut.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=prakashkc@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome