mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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