All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
To: Len Brown <lenb@kernel.org>
Cc: "Justin P. Mattock" <justinmattock@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux acpi <linux-acpi@vger.kernel.org>
Subject: Re: [ 11.333737] is this a ghost?
Date: Tue, 18 Nov 2008 18:49:16 +0000	[thread overview]
Message-ID: <49230E2C.60101@tuffmail.co.uk> (raw)
In-Reply-To: <1227030114.3161.18.camel@LiNuX>

Justin P. Mattock wrote:
> On Tue, 2008-11-18 at 16:58 +0000, Alan Jenkins wrote:
>   
>> Justin P. Mattock wrote:
>>     
>>> On Tue, 2008-11-18 at 11:15 +0000, Alan Jenkins wrote:
>>>   
>>>       
>>>> On 11/18/08, Justin P. Mattock <justinmattock@gmail.com> wrote:
>>>>     
>>>>         
>>>>> in dmesg I see:
>>>>> [   11.333737]
>>>>> but nothing else.
>>>>>           ---------------(cut)-----------------
>>>>> [   11.247147] Monitor-Mwait will be used to enter C-1 state
>>>>> [   11.247151] Monitor-Mwait will be used to enter C-2 state
>>>>> [   11.247154] Monitor-Mwait will be used to enter C-3 state
>>>>> [   11.247671] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
>>>>> [   11.247996] processor ACPI_CPU:00: registered as cooling_device0
>>>>> [   11.248008] ACPI: Processor [CPU0] (supports 8 throttling states)
>>>>> [   11.306465] ACPI: SSDT 3FEB8F10, 0087 (r1 APPLE   Cpu1Ist     3000
>>>>> INTL 20050309)<7>power_supply ADP1: No power supply yet
>>>>>       
>>>>>           
>>>> Look at this last line.  The "<7>" is a priority marker.  Normally it
>>>> marks the start of a line, and should be hidden.  So you seem to be
>>>> missing a line break just after "20050309)"...
>>>>
>>>>     
>>>>         
>>>>> [   11.306831] power_supply ADP1: power_supply_changed
>>>>> [   11.306839] ACPI: AC Adapter [ADP1] (on-line)
>>>>> [   11.333737]                         <------------what's with this!!!
>>>>>       
>>>>>           
>>>> ...which seems to be delayed and reappears here?
>>>>
>>>>     
>>>>         
>>>>> [   11.342937] power_supply ADP1: power_supply_changed_work
>>>>> [   11.351901] power_supply ADP1: power_supply_update_gen_leds 1
>>>>> [   11.351916] ACPI: SSDT 3FEB7F10, 0085 (r1 APPLE   Cpu1Cst     3000
>>>>> INTL 20050309)
>>>>>       
>>>>> if you need to see the full dmesg I can attach..
>>>>> I've seen this happen on a random.
>>>>>       
>>>>>           
>>>> I guess you have a multicore processor (or some other sort of SMP), right?
>>>>
>>>> I think kernel messages are not completely synchronized by design, for
>>>> reliability reasons.  (e.g. to make sure critical error messages /
>>>> backtraces can get through on a dying system).
>>>>     
>>>>         
>>> Cool.
>>> makes good sense to me, 
>>> As long as it's not something that shouldn't be there,
>>> or something that's broken. As for this happening again
>>> looking at dmesg nothing, all synchronized.
>>> Seems to randomly show itself.
>>>   
>>>       
>> It's the ACPICA OS abstraction layer - it splits every message into
>> multiple printk() calls.  Other subsystems don't do this... it probably
>> could and should be fixed.
>>
>> drivers/acpi/utmisc.c:
>>
>>     void ACPI_INTERNAL_VAR_XFACE
>>     acpi_ut_info(const char *module_name, u32 line_number, const char
>>     *format, ...)
>>     {
>>         va_list args;
>>
>>         /*
>>          * Removed module_name, line_number, and acpica version, not needed
>>          * for info output
>>          */
>>         acpi_os_printf("ACPI: ");
>>
>>         va_start(args, format);
>>         acpi_os_vprintf(format, args);
>>         acpi_os_printf("\n");
>>         va_end(args);
>>     }
>>
>> The alternative is to use the preprocessor, i.e. macros and string
>> concatenation to generate a single printk().
>>
>> Alan
>>     
>
> Maybe I'm missing a library or something.
> The issue with this is the consistency.
> one reboot I'll see it up higher in dmesg,
> and then on another reboot nothing, then
> maybe a few more reboots I'll see it down lower
> in dmesg(like what I posted). As for fixing this
> I'm not educated enough to go in and exactly know what
> to change(one day hopefully, so I can contribute),
> But I am willing to try a patch out to see if it resolves
> the issue.
>   

Right.  It's simple enough, I can write a patch.  Not sure what would be
most acceptable though.

Len, this sounds like a genuine bug.  Would you accept a patch changing
ACPI_INFO(()) etc. to use GNU-style variadic macros?

Thanks
Alan

      reply	other threads:[~2008-11-18 18:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-18  9:37 [ 11.333737] is this a ghost? Justin P. Mattock
2008-11-18 11:15 ` Alan Jenkins
2008-11-18 16:29   ` Justin P. Mattock
2008-11-18 16:58     ` Alan Jenkins
2008-11-18 17:41       ` Justin P. Mattock
2008-11-18 18:49         ` Alan Jenkins [this message]

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=49230E2C.60101@tuffmail.co.uk \
    --to=alan-jenkins@tuffmail.co.uk \
    --cc=justinmattock@gmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.