#12043 NORM Not Tri: 12.1.0 build 19 wedges on my XO-1.5

Zarro Boogs per Child bugtracker at laptop.org
Fri Aug 10 18:27:22 EDT 2012


#12043: 12.1.0 build 19 wedges on my XO-1.5
--------------------------------+-------------------------------------------
           Reporter:  shep      |       Owner:               
               Type:  defect    |      Status:  new          
           Priority:  normal    |   Milestone:  Not Triaged  
          Component:  kernel    |     Version:  not specified
         Resolution:            |    Keywords:               
        Next_action:  diagnose  |    Verified:  0            
Deployment_affected:            |   Blockedby:               
           Blocking:            |  
--------------------------------+-------------------------------------------

Comment(by shep):

 I was able to collect a few more clues, which I'll record here for whoever
 gets around to fixing this.

 With these debugging printks:
 {{{
 $ git diff
 diff --git a/drivers/video/via/via-core.c b/drivers/video/via/via-core.c
 index dd58b53..b26865a 100644
 --- a/drivers/video/via/via-core.c
 +++ b/drivers/video/via/via-core.c
 @@ -640,7 +640,14 @@ static int via_suspend(struct pci_dev *pdev,
 pm_message_t state)
          */
         mutex_lock(&viafb_pm_hooks_lock);
         list_for_each_entry_reverse(hooks, &viafb_pm_hooks, list)
 +       {
 +               printk(KERN_WARNING "%s: calling hook 0x%p\n",
 +                      __FUNCTION__, hooks->suspend);
                 hooks->suspend(hooks->private);
 +               printk(KERN_WARNING "%s: back from 0x%p\n",
 +                      __FUNCTION__, hooks->suspend);
 +
 +       }
         mutex_unlock(&viafb_pm_hooks_lock);

         pci_save_state(pdev);
 diff --git a/drivers/video/via/via_suspend.c
 b/drivers/video/via/via_suspend.c
 index 06dd8c4..35b9def 100644
 --- a/drivers/video/via/via_suspend.c
 +++ b/drivers/video/via/via_suspend.c
 @@ -538,6 +538,8 @@ int viafb_suspend(void *unused)
         viafb_sync(viafbinfo);
         console_unlock();

 +       printk(KERN_WARNING "viafb_suspend is done!\n");
 +
         return 0;
  }



 }}}

 I see this (and nothing more) when the suspend wedges:

 {{{
 [   50.731983] Freezing user space processes ... (elapsed 0.01 seconds)
 done.
 [   50.752873] Freezing remaining freezable tasks ... (elapsed 0.01
 seconds) done.
 [   50.773433] dcon_source_switch to DCON
 [   50.797993] olpc-dcon: The DCON has control
 [   50.802840] i8042 kbd 00:04: wake-up capability enabled by ACPI
 [   50.808837] i8042 aux 00:03: wake-up capability disabled by ACPI
 [   50.816986] libertas_sdio mmc1:0001:1: mmc1:0001:1: suspend: PM flags =
 0x3
 [   50.824087] via_suspend: calling hook 0xb0588e2c
 [   50.828712] viafb_suspend!
 [   50.832152] viafb_suspend is done!
 [   50.835558] via_suspend: back from 0xb0588e2c
 [   50.839974] via_suspend: calling hook 0xb0587f78
 [   50.844672] via_suspend: back from 0xb0587f78
 }}}

 while an example where it did not wedge looks like this:

 {{{
 [  851.264998] Freezing user space processes ... (elapsed 0.02 seconds)
 done.
 [  851.292806] Freezing remaining freezable tasks ... (elapsed 0.01
 seconds) done.
 [  851.314113] i8042 kbd 00:04: wake-up capability enabled by ACPI
 [  851.320342] i8042 aux 00:03: wake-up capability disabled by ACPI
 [  851.328259] libertas_sdio mmc1:0001:1: mmc1:0001:1: suspend: PM flags =
 0x3
 [  851.335403] via_suspend: calling hook 0xb0588e2c
 [  851.340242] viafb_suspend!
 [  851.343546] viafb_suspend is done!
 [  851.346955] via_suspend: back from 0xb0588e2c
 [  851.351461] libertas_sdio mmc1:0001:1: Suspend without wake params --
 powering down card
 [  851.360472] via_suspend: calling hook 0xb0587f78
 [  851.365096] via_suspend: back from 0xb0587f78
 [  851.370767] mmc1: card 0001 removed
 [  851.390153] PM: suspend of devices complete after 76.887 msecs
 [  851.470388] PM: late suspend of devices complete after 74.387 msecs
 [  851.476797] ACPI: Preparing to enter system sleep state S3
 }}}

 Curiously, the above example of suspend not wedging I did not have
 NetworkManager running.  This was the first time I ever saw it not wedge
 with NetworkManager not running.  I wonder if the extra printks changed
 the timing and maybe the underlying bug is race condition.

-- 
Ticket URL: <http://dev.laptop.org/ticket/12043#comment:6>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system


More information about the Bugs mailing list