Re: 2.6.25 pci=noacpi

[Thomas Renninger <trenn@suse.de>]

On Thu, 2008-05-08 at 12:38 +0100, Richard wrote:
> Thomas Renninger wrote:
> > On Thu, 2008-05-08 at 08:23 +0100, Richard wrote:
> >   
> >> Thomas Renninger wrote:
> >>     
> > ...
> >
> >   
> >>>>>> thanks - the idle=poll works to fix the problem.
> >>>>>>         
> >>>>>>             
> >>>>> Well, that's hardly a "fix".  The power consumption will be very high.
> >>>>>
> >>>>>           
> >>>> Hehehe, its a start. A booting kernel is definitely a good start (even 
> >>>> one what drinks battery). I have some avenues in the source to 
> >>>> investigate, but being a ACPI n00bie its trying to get my head around 
> >>>> the mass of code thats a daunting task.
> >>>>     
> >>>>         
> >>> Richard, could you try processor.max_cstate=2 (or even 1), pls (without
> >>> noapictimer).
> >>> Or you can double check whether you have cstates at all first(when
> >>> booting with noapictimer):
> >>> cat /proc/acpi/processor/*/power
> >>>
> >>> Vendors often invalidate deeper sleep states with an invalid latency.
> >>> Maybe this has been forgotten here, Windows does not use deeper C-state
> >>> or it works there for some reason.
> >>> If this works for you, please send dmidecode output.
> >>> IMO we should then blacklist this machine in
> >>> drivers/acpi/processor_idle.c to not use the offending sleep state.
> >>> There already is a blacklist.
> >>>
> >>> Thanks,
> >>>
> >>>    Thomas
> >>>
> >>>
> >>>   
> >>>       
> >> Hi Thomas (and all)
> >>
> >> I tried the processor.max_cstate=2 to no avail.   on a 23, 24 and a .25 
> >> kernel :-P   The machine shuts  down just after INIT  starts.
> >>     
> > Could you also try processor.max_cstate=1 (one kernel is enough, just a
> > quick test... )
> > The culprit is in the idle routine and there just the C-states are
> > triggered..., it should be related to C-states.
> >
> >   
> >> ------------- This is reported when booted with noapictimer ----------------
> >> cat /proc/acpi/processor/*/power
> >> active state:            C0
> >> max_cstate:              C8
> >> bus master activity:     00000000
> >> maximum allowed latency: 6666 usec
> >> states:
> >>     C1:                  type[C1] promotion[--] demotion[--] 
> >> latency[000] usage[00082490] duration[00000000000000000000]
> >>     C2:                  type[C2] promotion[--] demotion[--] 
> >> latency[018] usage[00000000] duration[00000000000000000000]
> >>     
> > I wonder why even C2 is not entered with noapictimer...
> >   
> >>     C3:                  type[C3] promotion[--] demotion[--] 
> >> latency[083] usage[00000000] duration[00000000000000000000]
> >> ----------------------------------------------------------------------------------
> >>     
> >
> >
> >   Thomas
> >
> >
> >   
> Hi there Thomas,
> 
> processor.max_cstate=1 didnt make any difference.   I can video the 
> bootup sequence so you can see exactly what I am looking at?

You mean when exactly it hangs, yes that would be useful.
Really strange is that idle=poll works and processor.max_cstate=1 does
not.
Maybe you can double check that you or I didn't do a mistake with the
boot parameter. Everything would perfectly fit: You have C3, those
machines are known that apictimer does not work in deeper sleep
states...

Interesting could be at what time it hangs and whether the processor
module could have been and was loaded already at that time.
This one provides its own idle routine which will get used when it's
loaded.

Maybe moving away the processor module (eventually it also must be
reverted from initrd) helps?

   Thomas