This was how the APIC_TIMER_BASE_DIV was originally added there.
http://www.ussg.iu.edu/hypermail/linux/kernel/9907.1/0608.html
Thanks,
Venkatesh
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Mikael Pettersson
> Sent: Thursday, January 22, 2004 9:49 AM
> To: Linus Torvalds
> Cc: Karol Kozimor; Georg C. F. Greve; Nakajima, Jun; Martin
> Loschwitz; [email protected]; Brown, Len;
> [email protected]
> Subject: Re: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot
>
>
> Linus Torvalds writes:
> >
> >
> > On Thu, 22 Jan 2004, Mikael Pettersson wrote:
> >
> > > Karol Kozimor writes:
> > > >
> > > > diff -Bru linux-2.6.0-test8/arch/i386/kernel/apic.c
> patched/arch/i386/kernel/apic.c
> > > > --- linux-2.6.0-test8/arch/i386/kernel/apic.c
> 2003-10-18 05:43:36.000000000 +0800
> > > > +++ patched/arch/i386/kernel/apic.c 2003-10-30
> 23:17:50.000000000 +0800
> > > > @@ -836,8 +836,8 @@
> > > > {
> > > > unsigned int lvtt1_value, tmp_value;
> > > >
> > > > - lvtt1_value = SET_APIC_TIMER_BASE(APIC_TIMER_BASE_DIV) |
> > > > - APIC_LVT_TIMER_PERIODIC |
> LOCAL_TIMER_VECTOR;
> > > > + lvtt1_value = APIC_LVT_TIMER_PERIODIC |
> LOCAL_TIMER_VECTOR;
> > > > +
> > > > apic_write_around(APIC_LVTT, lvtt1_value);
> > >
> > > What is the purpose of this change?
> > > I don't remember seeing this before on LKML. (I don't
> have time to read bugzilla.)
> >
> > Hmm.. It does seem to fix things for a couple of people,
> so it looks
> > interesting.
> >
> > As far as I can tell, the _only_ thing it does is to
> change the timer base
> > from "DIV" to "CLKIN". I seem to have misplaced my ia-32
> "volume 3" thing,
> > but I have an old one for a pentium, and that one doesn't actually
> > haev the timer-base thing at all - and marks those bits as
> "reserved".
> >
> > So it is entirely possible that the only safe value to
> write there is 0.
>
> Confirmed. Those bits (18 and 19 in LVTT) are marked reserved in the
> latest IA32 Volume 3. I have no idea where this APIC_TIMER_BASE came
> from (maybe some ancient discrete LAPIC thing?), but we
> almost certainly
> shouldn't write anything but zero to them.
>
> > So I'm inclined to apply the patch, but it would be better
> if somebody who
>
> I agree. The patch should be applied.
>
> /Mikael
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Thu, 22 Jan 2004, Mikael Pettersson wrote:
>
> To handle both cases the code should do one of those "is intergrated"
> tests we alreay have several of in apic.c. I can fix that, but not
> until tomorrow.
Even then I'd like to hear _why_ it would be a problem to bypass the
divider on an external LAPIC. The original patch comes with a message
explicitly saying that it was never even tested on such an external LAPIC,
and doing a google newsgroup search doesn't find any replies to that
post.
So it's entirely possible that the code was bogus to begin with, and just
never mattered..
I actually have some really old Intel manuals, including one for the
i82489DX (actually, it's just one part of a "Pentium Processors and
Related Products" manual). And while I see the register definition (and
yes, it documents the CLKIN/TMBASE/DIVIDER usage), I don't see anything
that actually says that you shouldn't just use CLKIN.
Do we have any real reason to care? We calculate the counter value
dynamically anyway, so the only "bug" might be that on one of those old
i82489DX machines we might report a frequency value that is off by a
factor of 16. Which should just make the user really happy ("cool, my APIC
is running at 256 MHz!").
Hmm?
Linus
Pallipadi, Venkatesh writes:
>
> This was how the APIC_TIMER_BASE_DIV was originally added there.
> http://www.ussg.iu.edu/hypermail/linux/kernel/9907.1/0608.html
That message confirms my suspicion. The bits were apparently needed
in the ancient discrete LAPICs, but they clearly must not be set
in some current integrated LAPICs.
To handle both cases the code should do one of those "is intergrated"
tests we alreay have several of in apic.c. I can fix that, but not
until tomorrow.
/Mikael
On Thu, 22 Jan 2004, Linus Torvalds wrote:
> > To handle both cases the code should do one of those "is intergrated"
> > tests we alreay have several of in apic.c. I can fix that, but not
> > until tomorrow.
>
> Even then I'd like to hear _why_ it would be a problem to bypass the
> divider on an external LAPIC. The original patch comes with a message
> explicitly saying that it was never even tested on such an external LAPIC,
> and doing a google newsgroup search doesn't find any replies to that
> post.
It wasn't tested back then in July 1999, but later it actually was and
proved correct -- see the note in arch/i386/kernel/apic.c (I can dig
through my archive for patches and mails involved). A few other problems
were resolved as a result as well, e.g. the logical destination mode
turned out not to work with the i82489DX unless the DFR is set to
0xffffffff explicitly as stated in the manuals (we used to set it to 0xf
earlier, based on documentation on the integrated APICs, and yes, the
i82489DX does support a flat 32-bit logical destination selection), a race
when using INIT IPIs to wake up APs, etc.
> I actually have some really old Intel manuals, including one for the
> i82489DX (actually, it's just one part of a "Pentium Processors and
> Related Products" manual). And while I see the register definition (and
> yes, it documents the CLKIN/TMBASE/DIVIDER usage), I don't see anything
> that actually says that you shouldn't just use CLKIN.
There were actually two documents, sort of complementing each other, also
available as discrete hardcopies. ;-) If there's interest in the
documents I can think on how to make them available.
> Do we have any real reason to care? We calculate the counter value
> dynamically anyway, so the only "bug" might be that on one of those old
> i82489DX machines we might report a frequency value that is off by a
> factor of 16. Which should just make the user really happy ("cool, my APIC
> is running at 256 MHz!").
Well, I think the systems are rare enough we'd better keep their
configuration as much similar to the more common ones as possible. This
way chances are any bug that would hit the formers, will trigger for the
latters as well. And in this case it's just a few bytes of code as Mikael
has already proposed.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +