All of lore.kernel.org
 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 APIC/LAPIC hanging problems on nForce2 system 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.