RE: PROBLEM: ACPI freezes 2.6.1 on boot

RE: PROBLEM: ACPI freezes 2.6.1 on boot

[Nakajima, Jun]

Right now I forwarded this to linux-acpi@intel.com, but copying the ACPI
mailing list acpi-devel@lists.sourceforge.net would be helpful in
general. Len can provide more specific directions for reporting ACPI
bugs.

Thanks,
Jun
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Georg C. F. Greve
> Sent: Wednesday, January 21, 2004 8:12 AM
> To: Martin Loschwitz
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: PROBLEM: ACPI freezes 2.6.1 on boot
> 
>  || On Wed, 21 Jan 2004 16:35:51 +0100
>  || Martin Loschwitz <madkiss@madkiss.org> wrote:
> 
>  ml> By now means. I, however, didn't even try to get a solution since
>  ml> back then. Since the bug appeared with a patched 2.6.0 and
>  ml> 2.6.1-mm2, which was one of the first patches including the new
>  ml> ACPI, it was clear to me that it was ACPI related and that I
>  ml> would better wait for somebody to find the root of the evil and
>  ml> to kill it.
> 
> Damn. ACPI being somewhat a central issue, I hoped someone had picked
> it up already. Did you write to the ACPI list about it? My mail
> apparently didn't make it (couldn't see it in the archive).
> 
> 
>  ml> I see your "Notebook vs. Linux"-story continues to be
>  ml> unsuccessfull, though :(
> 
> Yup, it seems that way. It is an eternal struggle. *sigh*
> 
> Nice to see that someone read the issue, though. :)
> 
> Regards,
> Georg
> 
> --
> Georg C. F. Greve
<greve@gnu.org>
> Free Software Foundation Europe
> (http://fsfeurope.org)
> Brave GNU World
(http://brave-gnu-world.org)

Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Georg C. F. Greve]

 || On Wed, 21 Jan 2004 08:32:50 -0800
 || "Nakajima, Jun" <jun.nakajima@intel.com> wrote: 

 nj> Right now I forwarded this to linux-acpi@intel.com, but copying
 nj> the ACPI mailing list acpi-devel@lists.sourceforge.net would be
 nj> helpful in general. Len can provide more specific directions for
 nj> reporting ACPI bugs.

Thanks.

FYI, there is a bug on the Linux kernel bugzilla corresponding to this
problem: 

         http://bugzilla.kernel.org/show_bug.cgi?id=1774

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

Re: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Sérgio Monteiro Basto]

And disable apic (lopic and io-pic) options from kernel compilation ?


On Wed, 2004-01-21 at 21:15, Georg C. F. Greve wrote:
> || On 2004-01-21 18:56:59, Linus Torvalds wrote:
> 
>  > Does it go away if you just make "acpi_pic_set_level_irq()" do
>  > nothing (ie just remove the "outb()" call
>  > 
>  > 	arch/i386/kernel/acpi/boot.c line 273
>  > 
>  > or just make the if-statement be always false).
> 
>  > It's entirely possible that the SCI is just horribly broken, and
>  > can't be level-triggered.
> 
> Just tried removing the outb() call both from plain vanilla 2.6.1 and
> one with the latest ACPI patch. No change. The system freezes with the
> same message at the same point during bootup.
> 
> Any other ideas?
> 
> Regards,
> Georg

-- 
Sérgio M B

Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Georg C. F. Greve]

UPDATE:

Out of curiosity and because it seemed to be the interrupt handling
that was problematic, I disabled "Local APIC support on uniprocessors."

That convinced the machine to boot with ACPI.

Here is an excerpt from dmesg regarding ACPI only:

[...]
ACPI: RSDP (v000 ACPIAM                                    ) @ 0x000f4b60
ACPI: RSDT (v001 A M I  OEMRSDT  0x06000310 MSFT 0x00000097) @ 0x1f740000
ACPI: FADT (v002 A M I  OEMFACP  0x06000310 MSFT 0x00000097) @ 0x1f740200
ACPI: OEMB (v001 A M I  OEMBIOS  0x06000310 MSFT 0x00000097) @ 0x1f750040
ACPI: DSDT (v001  0ABBD 0ABBD001 0x00000001 MSFT 0x0100000d) @ 0x00000000
[...]
ACPI: Subsystem revision 20031002
ACPI: IRQ 9 was Edge Triggered, setting to Level Triggerd
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
[...]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: Embedded Controller [EC0] (gpe 28)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 12)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 12)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 12)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 12)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 12)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 *4 5 6 7 12)
ACPI: Power Resource [GFAN] (off)
[...]
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 5
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 4
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
[...]
speedstep-centrino: found "Intel(R) Pentium(R) M processor 1600MHz": max frequency: 1600000kHz
[...]
ACPI: AC Adapter [AC0] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Lid Switch [LID]
ACPI: Fan [FN00] (off)
ACPI: Processor [CPU1] (supports C1 C2 C3, 8 throttling states)
ACPI: Thermal Zone [THRM] (54 C)
Asus Laptop ACPI Extras version 0.26
  M2N model detected, supported
[...]
Resume Machine: resuming from /dev/hda8
Resuming from device hda8
Resume Machine: This is normal swap space
PM: Reading pmdisk image.
PM: Resume from disk failed.
ACPI: (supports S0 S1 S3 S4 S5)
[...]


This looks pretty good, I think. Already checked some
funcionality. Suspend to RAM seems to work, although the display
remains dark on restart (but normal shutdown works, so the machine is
definitely back up).

So the problem we've been seeing seems to be related to the
interaction between local APIC support and ACPI.

I hope this helps tracking it down...

Regards,
Georg


P.S. Martin? Can you reproduce this?

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

Re: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Georg C. F. Greve]

 || On 21 Jan 2004 21:51:27 +0000
 || Sérgio Monteiro Basto <sergiomb@netcabo.pt> wrote: 

 smb> And disable apic (lopic and io-pic) options from kernel compilation ?

Funny -- we seemed to have had the same idea. 

Yes, this makes it boot (see my other mail).

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

Re: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Sérgio Monteiro Basto]

So you are another APIC victim :)

The funny thing, is that I thought that because, 
Linus has write :
"It's entirely possible that the SCI is just horribly broken, and can't
be level-triggered" about "ACPI: IRQ 9 was Edge Triggered, setting to
Level Triggerd".

And thinking, can be true ? that, if SCI can't be level-triggered (like
my laptop and yours), kernel with APIC (loapic or smp) options will hang
on boot !

On Wed, 2004-01-21 at 22:33, Georg C. F. Greve wrote:
>  || On 21 Jan 2004 21:51:27 +0000
>  || Sérgio Monteiro Basto <sergiomb@netcabo.pt> wrote: 
> 
>  smb> And disable apic (lopic and io-pic) options from kernel compilation ?
> 
> Funny -- we seemed to have had the same idea. 
> 
> Yes, this makes it boot (see my other mail).
> 
> Regards,
> Georg
> 
> -- 
> Georg C. F. Greve                                       <greve@gnu.org>
> Free Software Foundation Europe	                 (http://fsfeurope.org)
> Brave GNU World	                           (http://brave-gnu-world.org)
-- 
Sérgio M B

Re: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Georg C. F. Greve]

 || On 21 Jan 2004 23:31:43 +0000
 || Sérgio Monteiro Basto <sergiomb@netcabo.pt> wrote: 

 smb> So you are another APIC victim :)

Seems that way. :)


 smb> [...]

 smb> And thinking, can be true ? that, if SCI can't be
 smb> level-triggered (like my laptop and yours), kernel with APIC
 smb> (loapic or smp) options will hang on boot !

But can it really not be level triggered? 

My dmesg output tells me explicitly that it switched to level
triggered successfully when APIC is disabled.

So is that message wrong or is there a problem between APIC/ACPI?

Should we not be able to resolve that problem anytime soon, I would
suggest to add some information about this to the Kernel help for both
ACPI and APIC, like:

"
 CAUTION: 
 On some laptops, enabling both local APIC and ACPI can cause
 problems.  Should your system hang during boot with a message like
  'ACPI: IRQ X was Edge Triggered, setting to Level Triggerd'
 you should disable either local APIC (recommended) or ACPI. 
 See http://bugzilla.kernel.org/show_bug.cgi?id=1774 for details.
"

that could save people a lot of time in the future hunting down that
bug again -- also it should limit the amount of mails sent around on
the topic. :)

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

Re: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Karol Kozimor]

Thus wrote Georg C. F. Greve:
> So the problem we've been seeing seems to be related to the
> interaction between local APIC support and ACPI.

We've definitely had those problems before (with ASUS L3800C), there's 
even a patch fixing this issue (attached below) you might try.
I guess that's another of those lost and forgotten bugzilla bugs :)

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl


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);
 
 	/*
diff -Bru linux-2.6.0-test8/drivers/acpi/bus.c patched/drivers/acpi/bus.c
--- linux-2.6.0-test8/drivers/acpi/bus.c	2003-10-18 05:43:19.000000000 +0800
+++ patched/drivers/acpi/bus.c	2003-10-30 23:20:32.000000000 +0800
@@ -589,6 +589,7 @@
 
 	ACPI_FUNCTION_TRACE("acpi_bus_init");
 
+	disable_APIC_timer();
 	status = acpi_initialize_subsystem();
 	if (ACPI_FAILURE(status)) {
 		printk(KERN_ERR PREFIX "Unable to initialize the ACPI Interpreter\n");
@@ -643,6 +644,7 @@
 		goto error1;
 	}
 
+	enable_APIC_timer();
 	printk(KERN_INFO PREFIX "Interpreter enabled\n");
 
 	/*
@@ -672,6 +674,7 @@
 error1:
 	acpi_terminate();
 error0:
+	enable_APIC_timer();
 	return_VALUE(-ENODEV);
 }
 

Re: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Mikael Pettersson]

Karol Kozimor writes:
 > Thus wrote Georg C. F. Greve:
 > > So the problem we've been seeing seems to be related to the
 > > interaction between local APIC support and ACPI.
 > 
 > We've definitely had those problems before (with ASUS L3800C), there's 
 > even a patch fixing this issue (attached below) you might try.
 > I guess that's another of those lost and forgotten bugzilla bugs :)
 > 
 > -- 
 > Karol 'sziwan' Kozimor
 > sziwan@hell.org.pl
 > 
 > 
 > 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.)

Re: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Karol Kozimor]

Thus wrote Mikael Pettersson:
>  > 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.)

I don't really know. I'm not the author of the patch, I just found it on my
disk and I remember it allowed me to boot with LAPIC compiled in, as the
system would otherwise hang during _STA and _INI execution. I don't even
know if the patch is still correct.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Georg C. F. Greve]

 || On Thu, 22 Jan 2004 13:08:54 +0100
 || Karol Kozimor <sziwan@hell.org.pl> wrote: 

 >> So the problem we've been seeing seems to be related to the
 >> interaction between local APIC support and ACPI.

 kk> We've definitely had those problems before (with ASUS L3800C),
 kk> there's even a patch fixing this issue (attached below) you might
 kk> try.  I guess that's another of those lost and forgotten bugzilla
 kk> bugs :)

Thanks a lot -- this patch fixed the problem for me.

The kernel now found the APIC and initialized ACPI (including
switching to level trigger) with no problems.

Could we please make sure this doesn't get lost again and makes it
into the kernel?

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

RE: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Yu, Luming]

> I guess that's another of those lost and forgotten bugzilla bugs :)
Hmm, it is http://bugzilla.kernel.org/show_bug.cgi?id=1269

Re: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Georg C. F. Greve]

 || On Thu, 22 Jan 2004 15:08:56 +0100
 || "Georg C. F. Greve" <greve@gnu.org> wrote: 

 gg> Could we please make sure this doesn't get lost again and makes
 gg> it into the kernel?

By the way, it seems that 

 http://bugzilla.kernel.org/show_bug.cgi?id=1774
 http://bugzilla.kernel.org/show_bug.cgi?id=1677
 http://bugzilla.kernel.org/show_bug.cgi?id=1530
 http://bugzilla.kernel.org/show_bug.cgi?id=1171

are probably related. So this could get rid of four bugzilla entries
at once. :)

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

Re: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Linus Torvalds]

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.

Also, why the heck do we call that "lvtt1"? It's just lvtt - no "1" there
anywhere.

So I'm inclined to apply the patch, but it would be better if somebody who 
had more recent docs could tell me what those newer docs say is the 
difference bewteen BASE_CLKIN (0) and BASE_DIV (2)...

		Linus

Re: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Mikael Pettersson]

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

RE: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Pallipadi, Venkatesh]

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: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] 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; linux-kernel@vger.kernel.org; Brown, Len; 
> acpi-devel@lists.sourceforge.net
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

RE: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Mikael Pettersson]

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

RE: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Linus Torvalds]

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

RE: [ACPI] Re: PROBLEM: ACPI freezes 2.6.1 on boot

[Maciej W. Rozycki]

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: macro@ds2.pg.gda.pl, PGP key available        +