software suspend in 2.5.70-mm3.

software suspend in 2.5.70-mm3.

Post by hugan » Wed, 04 Jun 2003 15:20:17



Hi Pavel Machek:

I try the 2.5.70-mm3 with software suspend function. When suspend it will oops at ide-disk.c 1526 line
   BUG_ON (HWGROUP(drive)->handler);

I'm disable this check, The software suspend can work, and also can resumed. But this fix is not best way. I found in ide-io.c 1196
   hwgroup->handler = NULL;
is the problem.

thanks.

--
Hu Gang / Steve

GPG FinePrint: 4099 3F1D AE01 1817 68F7  D499 A6C2 C418 86C8 610E
http://soulinfo.com/~hugang/HuGang.asc
ICQ#         : 205800361
Registered Linux User : 204016
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

software suspend in 2.5.70-mm3.

Post by Alan Co » Wed, 04 Jun 2003 16:30:14



Quote:> Hi Pavel Machek:

> I try the 2.5.70-mm3 with software suspend function. When suspend it will oops at ide-disk.c 1526 line
>    BUG_ON (HWGROUP(drive)->handler);

> I'm disable this check, The software suspend can work, and also can resumed. But this fix is not best way. I found in ide-io.c 1196
>    hwgroup->handler = NULL;
> is the problem.

The only way to make the suspend work properly is to queue the suspend
sequence wit the other requests. Ben was doing some playing with this
but I'm not sure what happened to it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

software suspend in 2.5.70-mm3.

Post by hugan » Wed, 04 Jun 2003 16:40:13


On 03 Jun 2003 14:22:48 +0100



> > Hi Pavel Machek:

> > I try the 2.5.70-mm3 with software suspend function. When suspend it will oops at ide-disk.c 1526 line
> >    BUG_ON (HWGROUP(drive)->handler);

> > I'm disable this check, The software suspend can work, and also can resumed. But this fix is not best way. I found in ide-io.c 1196
> >    hwgroup->handler = NULL;
> > is the problem.

> The only way to make the suspend work properly is to queue the suspend
> sequence wit the other requests. Ben was doing some playing with this
> but I'm not sure what happened to it.

Yes the above patch is not safe, When i'm run updatedb and suspsned, After resume will oops at kjournal.

Here is another test on it, it can works with updatedb.
-
I found a best way to fix it. here is it. With the patch, I'm run updatedb and suspend for 5 counts, every things is ok.

 --- ide-disk.c.old     Tue Jun  3 22:22:13 2003
 +++ ide-disk.c Tue Jun  3 22:16:22 2003

        do_idedisk_standby(drive);
        drive->blocked = 1;

 -      BUG_ON (HWGROUP(drive)->handler);
 +      /*BUG_ON (HWGROUP(drive)->handler);*/
 +      while(HWGROUP(drive)->handler) {
 +              schedule();
 +      }
        return 0;
  }

--
Hu Gang / Steve

GPG FinePrint: 4099 3F1D AE01 1817 68F7  D499 A6C2 C418 86C8 610E
http://soulinfo.com/~hugang/HuGang.asc
ICQ#         : 205800361
Registered Linux User : 204016
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

software suspend in 2.5.70-mm3.

Post by Alan Co » Wed, 04 Jun 2003 17:10:10



Quote:> > The only way to make the suspend work properly is to queue the suspend
> > sequence wit the other requests. Ben was doing some playing with this
> > but I'm not sure what happened to it.

> Yes the above patch is not safe, When i'm run updatedb and suspsned, After resume will oops at kjournal.

> Here is another test on it, it can works with updatedb.

Still races. Ben's stuff is needed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

software suspend in 2.5.70-mm3.

Post by Benjamin Herrenschmid » Wed, 04 Jun 2003 19:10:13




> > > The only way to make the suspend work properly is to queue the suspend
> > > sequence wit the other requests. Ben was doing some playing with this
> > > but I'm not sure what happened to it.

> > Yes the above patch is not safe, When i'm run updatedb and suspsned, After resume will oops at kjournal.

> > Here is another test on it, it can works with updatedb.

> Still races. Ben's stuff is needed

I have it working with some fixes from what I sent earlier, I'll
repost that tonight or tomorrow, I need to extract that from
a half-broken tree ;)

Ben.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

software suspend in 2.5.70-mm3.

Post by Pavel Mache » Wed, 04 Jun 2003 21:10:08


Hi!

Quote:> > > Hi Pavel Machek:

> > > I try the 2.5.70-mm3 with software suspend function. When suspend it will oops at ide-disk.c 1526 line
> > >    BUG_ON (HWGROUP(drive)->handler);

> > > I'm disable this check, The software suspend can work, and also can resumed. But this fix is not best way. I found in ide-io.c 1196
> > >    hwgroup->handler = NULL;
> > > is the problem.

> > The only way to make the suspend work properly is to queue the suspend
> > sequence wit the other requests. Ben was doing some playing with this
> > but I'm not sure what happened to it.

> Yes the above patch is not safe, When i'm run updatedb and suspsned, After resume will oops at kjournal.

> Here is another test on it, it can works with updatedb.
> -
> I found a best way to fix it. here is it. With the patch, I'm run updatedb and suspend for 5 counts, every things is ok.

Locating Ben's patch and forward-porting
it would be way better...
--
                                Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

software suspend in 2.5.70-mm3.

Post by Benjamin Herrenschmid » Thu, 05 Jun 2003 15:18:18


On Tue, 2003-06-03 at 19:04, Benjamin Herrenschmidt wrote:
> On Tue, 2003-06-03 at 16:08, Alan Cox wrote:
> > Still races. Ben's stuff is needed

> I have it working with some fixes from what I sent earlier, I'll
> repost that tonight or tomorrow, I need to extract that from
> a half-broken tree ;)

Ok, here is it. It still need a bit of cleanup (removal of magic
number for "steps" -> enum, etc...) and we may want to do more
things on wakeup especially for ide-cd, Also I don't deal with
ide-tape or ide-floppy in there and haven't fully studied the
impact with ide-scsi....

So it's not meant to be merged as-is, though I'd appreciate to
know if it helps for you.

Bartolomiej: Any comments appreciated, I won't do the ide-tape/floppy
part as I don't know/own these, I think i'll let you decide if
anything more is needed on the wakeup path for ide-cd... Once I
have enough feedback, I'll send you a cleanified version as
candidate for upstream merge.

===== drivers/ide/ide-cd.c 1.49 vs edited =====
--- 1.49/drivers/ide/ide-cd.c   Sun Jun  1 21:55:45 2003
+++ edited/drivers/ide/ide-cd.c Wed Jun  4 14:53:38 2003
@@ -3253,6 +3253,46 @@

 static int ide_cdrom_attach (ide_drive_t *drive);

+static void ide_cdrom_complete_power_step (ide_drive_t *drive, ide_power_state_t *state, u8 stat, u8 error)
+{
+}
+
+/* Power Management state machine.
+ *
+ * We don't do much for CDs right now
+ */
+static ide_startstop_t ide_cdrom_start_power_step (ide_drive_t *drive, ide_power_state_t *state)
+{
+       ide_task_t args;
+
+       memset(&args, 0, sizeof(ide_task_t));
+
+       if (state->step == 0) {
+               state->step = state->suspend ? 1 : 101;
+               return ide_stopped;
+       }
+       switch(state->step) {
+       case 1:
+               break;
+
+       case 101: /* Resume step 1 (restore DMA) */
+               /* Right now, all we do is call ide_dma_check for the HWIF,
+                * we could be smarter and check for current xfer_speed
+                * in struct drive etc...
+                * Also, this step could be implemented as a generic helper
+                * as most subdrivers will use it
+                */
+               if (!drive->id || !(drive->id->capability & 1))
+                       break;
+               if (HWIF(drive)->ide_dma_check == NULL)
+                       break;
+               HWIF(drive)->ide_dma_check(drive);
+               break;
+       }
+       state->step = ide_power_state_completed;
+       return ide_stopped;
+}
+
 static ide_driver_t ide_cdrom_driver = {
        .owner                  = THIS_MODULE,
        .name                   = "ide-cdrom",
@@ -3269,6 +3309,12 @@
        .capacity               = ide_cdrom_capacity,
        .attach                 = ide_cdrom_attach,
        .drives                 = LIST_HEAD_INIT(ide_cdrom_driver.drives),
+       .start_power_step       = ide_cdrom_start_power_step,
+       .complete_power_step    = ide_cdrom_complete_power_step,
+       .gen_driver             = {
+               .suspend        = generic_ide_suspend,
+               .resume         = generic_ide_resume,
+       }
 };

 static int idecd_open(struct inode * inode, struct file * file)
===== drivers/ide/ide-disk.c 1.45 vs edited =====
--- 1.45/drivers/ide/ide-disk.c Sun Jun  1 21:55:48 2003
+++ edited/drivers/ide/ide-disk.c       Wed Jun  4 14:54:24 2003
@@ -138,8 +138,6 @@

 #ifndef CONFIG_IDE_TASKFILE_IO

-static int driver_blocked;
-
 /*
  * read_intr() is the handler for disk read/multread interrupts
  */
@@ -364,9 +362,6 @@

        nsectors.all            = (u16) rq->nr_sectors;

-       if (driver_blocked)
-               panic("Request while ide driver is blocked?");
-
        if (drive->using_tcq && idedisk_start_tag(drive, rq)) {
                if (!ata_pending_commands(drive))
                        BUG();
@@ -1392,21 +1387,6 @@
        return 0;
 }

-static int call_idedisk_standby (ide_drive_t *drive, int arg)
-{
-       ide_task_t args;
-       u8 standby = (arg) ? WIN_STANDBYNOW2 : WIN_STANDBYNOW1;
-       memset(&args, 0, sizeof(ide_task_t));
-       args.tfRegister[IDE_COMMAND_OFFSET]     = standby;
-       args.command_type                       = ide_cmd_type_parser(&args);
-       return ide_raw_taskfile(drive, &args, NULL);
-}
-
-static int do_idedisk_standby (ide_drive_t *drive)
-{
-       return call_idedisk_standby(drive, 0);
-}
-
 static int do_idedisk_flushcache (ide_drive_t *drive)
 {
        ide_task_t args;
@@ -1505,37 +1485,66 @@
 #endif
 }

-static int idedisk_suspend(struct device *dev, u32 state, u32 level)
-{
-       ide_drive_t *drive = dev->driver_data;
-
-       printk("Suspending device %p\n", dev->driver_data);
-
-       /* I hope that every freeze operation from the upper levels have
-        * already been done...
-        */
-
-       if (level != SUSPEND_SAVE_STATE)
-               return 0;
-
-       /* set the drive to standby */
-       printk(KERN_INFO "suspending: %s ", drive->name);
-       do_idedisk_standby(drive);
-       drive->blocked = 1;

-       BUG_ON (HWGROUP(drive)->handler);
-       return 0;
+static void idedisk_complete_power_step (ide_drive_t *drive, ide_power_state_t *state, u8 stat, u8 error)
+{
+       switch(state->step) {
+       case 1: /* Suspend step 1 (flush cache) complete */
+               state->step = 2;
+               break;
+       case 2: /* Suspend step 2 (standby) complete */
+               state->step = ide_power_state_completed;
+               break;
+       }
 }

-static int idedisk_resume(struct device *dev, u32 level)
+/* Power Management state machine. This one is rather trivial for now,
+ * we should probably add more, like switching back to PIO on suspend
+ * to help some BIOSes, re-do the door locking on resume, etc...
+ */
+static ide_startstop_t idedisk_start_power_step (ide_drive_t *drive, ide_power_state_t *state)
 {
-       ide_drive_t *drive = dev->driver_data;
+       ide_task_t args;

-       if (level != RESUME_RESTORE_STATE)
-               return 0;
-       BUG_ON(!drive->blocked);
-       drive->blocked = 0;
-       return 0;
+       memset(&args, 0, sizeof(ide_task_t));
+
+       if (state->step == 0) {
+               state->step = state->suspend ? 1 : 101;
+               return ide_stopped;
+       }
+       switch(state->step) {
+       case 1: /* Suspend step 1 (flush cache) */
+               if (!drive->wcache) {
+                       idedisk_complete_power_step(drive, state, 0, 0);
+                       return ide_stopped;
+               }
+               if (drive->id->cfs_enable_2 & 0x2400)
+                       args.tfRegister[IDE_COMMAND_OFFSET]     = WIN_FLUSH_CACHE_EXT;
+               else
+                       args.tfRegister[IDE_COMMAND_OFFSET]     = WIN_FLUSH_CACHE;
+               args.command_type                               = ide_cmd_type_parser(&args);
+               return do_rw_taskfile(drive, &args);
+       case 2: /* Suspend step 2 (standby) */
+               args.tfRegister[IDE_COMMAND_OFFSET]     = WIN_STANDBYNOW1;
+               args.command_type                       = ide_cmd_type_parser(&args);
+               return do_rw_taskfile(drive, &args);
+
+       case 101: /* Resume step 1 (restore DMA) */
+               /* Right now, all we do is call ide_dma_check for the HWIF,
+                * we could be smarter and check for current xfer_speed
+                * in struct drive etc...
+                * Also, this step could be implemented as a generic helper
+                * as most subdrivers will use it
+                */
+               if (!drive->id || !(drive->id->capability & 1))
+                       break;
+               if (HWIF(drive)->ide_dma_check == NULL)
+                       break;
+               HWIF(drive)->ide_dma_check(drive);
+               break;
+       }
+       state->step = ide_power_state_completed;
+       return ide_stopped;
 }

 static void idedisk_setup (ide_drive_t *drive)
@@ -1681,9 +1690,11 @@
        .proc                   = idedisk_proc,
        .attach                 = idedisk_attach,
        .drives                 = LIST_HEAD_INIT(idedisk_driver.drives),
+       .start_power_step       = idedisk_start_power_step,
+       .complete_power_step    = idedisk_complete_power_step,
        .gen_driver             = {
-               .suspend        = idedisk_suspend,
-               .resume         = idedisk_resume,
+               .suspend        = generic_ide_suspend,
+               .resume         = generic_ide_resume,
        }
 };

===== drivers/ide/ide-io.c 1.11 vs edited =====
--- 1.11/drivers/ide/ide-io.c   Mon May 12 02:09:46 2003
+++ edited/drivers/ide/ide-io.c Wed Jun  4 14:55:06 2003
@@ -139,6 +139,39 @@
 EXPORT_SYMBOL(ide_end_request);

 /**
+ *     ide_complete_pm_request -       end the current Power Management request
+ *     @drive: target drive
+ *     @rq: request
+ *
+ *     This function cleans up the current PM request and stops the queue
+ *     if necessary.
+ */
+
+static void ide_complete_pm_request (ide_drive_t *drive, struct request *rq)
+{
+       ide_power_state_t *state = (ide_power_state_t *)rq->special;
+       unsigned long flags;
+       int suspend = state->suspend;
+
+#ifdef DEBUG_PM
+       printk("%s: completing PM request, suspend: %d\n", drive->name, state->suspend);
+#endif
+       spin_lock_irqsave(&ide_lock, flags);
+       if (suspend)
+               __blk_stop_queue(&drive->queue);
+       else
+               drive->blocked = 0;
+       blkdev_dequeue_request(rq);
+       HWGROUP(drive)->rq = NULL;
+       end_that_request_last(rq);
+       spin_unlock_irqrestore(&ide_lock, flags);
+       /* Hrm... there is no __blk_start_queue... */
+       if (!suspend)
+               blk_start_queue(&drive->queue);
+}
+
+
+/**
  *     ide_end_drive_cmd       -       end an explicit drive command
  *     @drive: command
  *     @stat: status bits
@@ -214,6 +247,17 @@
                                args->hobRegister[IDE_HCYL_OFFSET_HOB]    = hwif->INB(IDE_HCYL_REG);
                        }
                }
+       } else if (rq->flags & REQ_POWER_MANAGEMENT) {
+               ide_power_state_t *state = (ide_power_state_t *)rq->special;
+
+#ifdef DEBUG_PM
+               printk("%s: complete_power_step(susp: %d, step: %d, stat: %x, err: %x)\n",
+                       drive->name, state->suspend, state->step, stat, err);
+#endif
+               DRIVER(drive)->complete_power_step(drive, state, stat, err);
+               if (state->step == ide_power_state_completed)
+                       ide_complete_pm_request(drive, rq);
+               return;
        }

        spin_lock_irqsave(&ide_lock, flags);
@@ -615,7 +659,37 @@
        while ((read_timer() - HWIF(drive)->last_time) < DISK_RECOVERY_TIME);
 #endif

-       SELECT_DRIVE(drive);
+       if (rq->flags & REQ_POWER_MANAGEMENT) {
+               ide_power_state_t *state = (ide_power_state_t *)rq->special;
+               int rc;
+
+               /* Mark drive blocked when starting the suspend sequence */
+               if (state->suspend && state->step == 0)
+                       drive->blocked = 1;
+               /* If this is a power management wakeup request, the first thing
+                * we do is to wait for BSY bit to go away (with a looong timeout)
+                * as a drive on this hwif may just be POSTing itself. We do that
+                * before even selecting as the "other" device on the bus may be
+                * broken enough to walk on our toes at this point.
+                */
+               if (state->suspend != 0 || state->step != 0)
+                       goto dont_wait;
+#ifdef DEBUG_PM
+               printk("%s: Wakeup request inited, waiting for !BSY...\n", drive->name);
+#endif        
+               rc = ide_wait_not_busy(HWIF(drive), 35000);
+               if (rc)
+                       printk(KERN_WARNING "%s: bus not ready on wakeup\n", drive->name);
+               SELECT_DRIVE(drive);
+               HWIF(drive)->OUTB(8, HWIF(drive)->io_ports[IDE_CONTROL_OFFSET]);
+               rc = ide_wait_not_busy(HWIF(drive),
...

read more »

 
 
 

software suspend in 2.5.70-mm3.

Post by Michael Fran » Thu, 05 Jun 2003 16:00:16


Patch 2.5.70-mm3 and  compile with gcc295 OK

Bare multisuer with serial console,
no modules, network, usb, acpi .....

During suspend, after a while (some dots on the console)  
got the output below in an endless loop

Is there any debug or progress output in this version
and how to use?

Regards
Michael

Call Trace:
 [<c011d958>] schedule+0x40/0x388
 [<c011eb02>] io_schedule+0xe/0x18
 [<c01384d5>] wait_on_page_bit_wq+0xc9/0xe4
 [<c011f320>] autoremove_wake_function+0x0/0x3c
 [<c011f320>] autoremove_wake_function+0x0/0x3c
 [<c01384fa>] wait_on_page_bit+0xa/0x10
 [<c014cc34>] rw_swap_page_sync+0x98/0xc6
 [<c0136afd>] write_suspend_image+0xf1/0x324
 [<c0246bdf>] device_resume+0x7f/0x88
 [<c01370e1>] drivers_unsuspend+0x11/0x18
 [<c013735e>] suspend_save_image+0x12/0x1c
 [<c013753f>] do_magic_suspend_2+0x17/0xa8
 [<c011ba9d>] do_magic+0x4d/0x130
 [<c013763b>] do_software_suspend+0x6b/0x90
 [<c0137695>] software_suspend+0x35/0x3c
 [<c012ba97>] sys_reboot+0x2df/0x36c
 [<c0143830>] unmap_page_range+0x38/0x5c
 [<c0143959>] unmap_vmas+0x105/0x208
 [<c01656e4>] dput+0x1c/0x204
 [<c01656e4>] dput+0x1c/0x204
 [<c015d367>] path_release+0xf/0x30
 [<c014fe69>] sys_chdir+0x5d/0x68
 [<c010af17>] syscall_call+0x7/0xb

--
Powered by linux-2.5.70-mm3
My current linux related activities in rough order of priority:
- Testing of 2.4/2.5 kernel interactivity
- Testing of Swsusp for 2.4
- Testing of Opera 7.11 emphasizing interactivity
- Research of NFS i/o errors during transfer 2.4>2.5
- Learning 2.5 series kernel debugging with kgdb
- Studying 2.5 series serial and ide drivers, ACPI, S3
* Input and feedback is always welcome *

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

software suspend in 2.5.70-mm3.

Post by Benjamin Herrenschmid » Thu, 05 Jun 2003 16:10:05



> Patch 2.5.70-mm3 and  compile with gcc295 OK

> Bare multisuer with serial console,
> no modules, network, usb, acpi .....

> During suspend, after a while (some dots on the console)  
> got the output below in an endless loop

> Is there any debug or progress output in this version
> and how to use?

I'm not sure how to interpret that call trace, was there any
other message just before ? There is some debug output in the
patch though it may have been lost at that point.

Ben.

Quote:> Regards
> Michael

> Call Trace:
>  [<c011d958>] schedule+0x40/0x388
>  [<c011eb02>] io_schedule+0xe/0x18
>  [<c01384d5>] wait_on_page_bit_wq+0xc9/0xe4
>  [<c011f320>] autoremove_wake_function+0x0/0x3c
>  [<c011f320>] autoremove_wake_function+0x0/0x3c
>  [<c01384fa>] wait_on_page_bit+0xa/0x10
>  [<c014cc34>] rw_swap_page_sync+0x98/0xc6
>  [<c0136afd>] write_suspend_image+0xf1/0x324
>  [<c0246bdf>] device_resume+0x7f/0x88
>  [<c01370e1>] drivers_unsuspend+0x11/0x18
>  [<c013735e>] suspend_save_image+0x12/0x1c
>  [<c013753f>] do_magic_suspend_2+0x17/0xa8
>  [<c011ba9d>] do_magic+0x4d/0x130
>  [<c013763b>] do_software_suspend+0x6b/0x90
>  [<c0137695>] software_suspend+0x35/0x3c
>  [<c012ba97>] sys_reboot+0x2df/0x36c
>  [<c0143830>] unmap_page_range+0x38/0x5c
>  [<c0143959>] unmap_vmas+0x105/0x208
>  [<c01656e4>] dput+0x1c/0x204
>  [<c01656e4>] dput+0x1c/0x204
>  [<c015d367>] path_release+0xf/0x30
>  [<c014fe69>] sys_chdir+0x5d/0x68
>  [<c010af17>] syscall_call+0x7/0xb

--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

software suspend in 2.5.70-mm3.

Post by Michael Fran » Thu, 05 Jun 2003 16:20:12



Patch 2.5.70-mm3 and  compile with gcc295 OK

Bare multisuer with serial console,
no modules, network, usb, acpi .....

Is there any debug or progress output in this version
and how to use?

Regards
Michael

OK, made the history longer

Last login: Wed Jun  4 21:59:38 on tty2

=init entered refrigerator
=pdflush entered refrigerator
=pdflush entered refrigerator
=kswapd0 entered refrigerator
=kseriod entered refrigerator
=kjournald entered refrigerator
=syslogd entered refrigerator
=open entered refrigerator
=open entered refrigerator
=open entered refrigerator
=open entered refrigerator
=open entered refrigerator
=login entered refrigerator
=login entered refrigerator
=login entered refrigerator
=login entered refrigerator
=login entered refrigerator
=login entered refrigerator
=bash entered refrigerator
=bash entered refrigerator
=bash entered refrigerator
=bash entered refrigerator
=bash entered refrigerator
=bash entered refrigerator
=open entered refrigerator
=comr entered refrigerator
=sleep entered refrigerator
=tst entered refrigerator
=tstr entered refrigerator
=|
Freeing memory: ..................|
Syncing disks before copy
Suspending devices
Suspending devices
hda: start_power_step(susp: 1, step: 0)
hda: start_power_step(susp: 1, step: 1)
hda: start_power_step(susp: 1, step: 2)
hda: complete_power_step(susp: 1, step: 2, stat: 50, err: 0)
hda: completing PM request, suspend: 1
Suspending devices
/critical section: Counting pages to copy[nosave c03f7000] (pages needed: 2273+512=2785 free: 14110)
Alloc pagedir
............
[nosave c03f7000]critical section/: done (2273 pages copied)
hda: Wakeup request inited, waiting for !BSY...
hda: start_power_step(susp: 0, step: 0)
hda: start_power_step(susp: 0, step: 101)
hda: completing PM request, suspend: 0
Devices Resumed
Devices Resumed
Writing data to swap (2273 pages): .<3>bad: scheduling while atomic!
Call Trace:
 [<c011d958>] schedule+0x40/0x388
 [<c011eb02>] io_schedule+0xe/0x18
 [<c01384d5>] wait_on_page_bit_wq+0xc9/0xe4
 [<c011f320>] autoremove_wake_function+0x0/0x3c
 [<c011f320>] autoremove_wake_function+0x0/0x3c
 [<c01384fa>] wait_on_page_bit+0xa/0x10
 [<c014cc34>] rw_swap_page_sync+0x98/0xc6
 [<c0136afd>] write_suspend_image+0xf1/0x324
 [<c0246bdf>] device_resume+0x7f/0x88
 [<c01370e1>] drivers_unsuspend+0x11/0x18
 [<c013735e>] suspend_save_image+0x12/0x1c
 [<c013753f>] do_magic_suspend_2+0x17/0xa8
 [<c011ba9d>] do_magic+0x4d/0x130
 [<c013763b>] do_software_suspend+0x6b/0x90
 [<c0137695>] software_suspend+0x35/0x3c
 [<c012ba97>] sys_reboot+0x2df/0x36c
 [<c0143830>] unmap_page_range+0x38/0x5c
 [<c0143959>] unmap_vmas+0x105/0x208
 [<c01656e4>] dput+0x1c/0x204
 [<c01656e4>] dput+0x1c/0x204
 [<c015d367>] path_release+0xf/0x30
 [<c014fe69>] sys_chdir+0x5d/0x68
 [<c010af17>] syscall_call+0x7/0xb

bad: scheduling while atomic!
Call Trace:
 [<c011d958>] schedule+0x40/0x388
 [<c011eb02>] io_schedule+0xe/0x18
 [<c01384d5>] wait_on_page_bit_wq+0xc9/0xe4
 [<c011f320>] autoremove_wake_function+0x0/0x3c
 [<c011f320>] autoremove_wake_function+0x0/0x3c
 [<c01384fa>] wait_on_page_bit+0xa/0x10
 [<c014cc34>] rw_swap_page_sync+0x98/0xc6
 [<c0136afd>] write_suspend_image+0xf1/0x324
 [<c0246bdf>] device_resume+0x7f/0x88
 [<c01370e1>] drivers_unsuspend+0x11/0x18
 [<c013735e>] suspend_save_image+0x12/0x1c
 [<c013753f>] do_magic_suspend_2+0x17/0xa8
 [<c011ba9d>] do_magic+0x4d/0x130
 [<c013763b>] do_software_suspend+0x6b/0x90
 [<c0137695>] software_suspend+0x35/0x3c
 [<c012ba97>] sys_reboot+0x2df/0x36c
 [<c0143830>] unmap_page_range+0x38/0x5c
 [<c0143959>] unmap_vmas+0x105/0x208
 [<c01656e4>] dput+0x1c/0x204
 [<c01656e4>] dput+0x1c/0x204
 [<c015d367>] path_release+0xf/0x30
 [<c014fe69>] sys_chdir+0x5d/0x68
 [<c010af17>] syscall_call+0x7/0xb

--
Powered by linux-2.5.70-mm3
My current linux related activities in rough order of priority:
- Testing of 2.4/2.5 kernel interactivity
- Testing of Swsusp for 2.4
- Testing of Opera 7.11 emphasizing interactivity
- Research of NFS i/o errors during transfer 2.4>2.5
- Learning 2.5 series kernel debugging with kgdb
- Studying 2.5 series serial and ide drivers, ACPI, S3
* Input and feedback is always welcome *

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

software suspend in 2.5.70-mm3.

Post by Benjamin Herrenschmid » Thu, 05 Jun 2003 16:40:09


Quote:> hda: start_power_step(susp: 1, step: 0)
> hda: start_power_step(susp: 1, step: 1)
> hda: start_power_step(susp: 1, step: 2)
> hda: complete_power_step(susp: 1, step: 2, stat: 50, err: 0)
> hda: completing PM request, suspend: 1
> Suspending devices
> /critical section: Counting pages to copy[nosave c03f7000] (pages needed: 2273+512=2785 free: 14110)
> Alloc pagedir
> ............
> [nosave c03f7000]critical section/: done (2273 pages copied)
> hda: Wakeup request inited, waiting for !BSY...
> hda: start_power_step(susp: 0, step: 0)
> hda: start_power_step(susp: 0, step: 101)
> hda: completing PM request, suspend: 0
> Devices Resumed
> Devices Resumed

Hrm... the joy if swsusp putting your disk to sleep just to wake it up
right away... I need to check if I can differenciate suspend-to-disk
from suspend-to-ram here to just not put the drive in STANDBY mode
on suspend-to-disk (just freeze the queues)

Quote:> Writing data to swap (2273 pages): .<3>bad: scheduling while atomic!

Here's the real one. However, it doesn't look related to my sleep code,
though I cannot guarantee this for sure right now, it _seems_ it's
a swsusp bug you are hitting.

- Show quoted text -

Quote:> Call Trace:
>  [<c011d958>] schedule+0x40/0x388
>  [<c011eb02>] io_schedule+0xe/0x18
>  [<c01384d5>] wait_on_page_bit_wq+0xc9/0xe4
>  [<c011f320>] autoremove_wake_function+0x0/0x3c
>  [<c011f320>] autoremove_wake_function+0x0/0x3c
>  [<c01384fa>] wait_on_page_bit+0xa/0x10
>  [<c014cc34>] rw_swap_page_sync+0x98/0xc6
>  [<c0136afd>] write_suspend_image+0xf1/0x324
>  [<c0246bdf>] device_resume+0x7f/0x88
>  [<c01370e1>] drivers_unsuspend+0x11/0x18
>  [<c013735e>] suspend_save_image+0x12/0x1c
>  [<c013753f>] do_magic_suspend_2+0x17/0xa8
>  [<c011ba9d>] do_magic+0x4d/0x130
>  [<c013763b>] do_software_suspend+0x6b/0x90
>  [<c0137695>] software_suspend+0x35/0x3c
>  [<c012ba97>] sys_reboot+0x2df/0x36c
>  [<c0143830>] unmap_page_range+0x38/0x5c
>  [<c0143959>] unmap_vmas+0x105/0x208
>  [<c01656e4>] dput+0x1c/0x204
>  [<c01656e4>] dput+0x1c/0x204
>  [<c015d367>] path_release+0xf/0x30
>  [<c014fe69>] sys_chdir+0x5d/0x68
>  [<c010af17>] syscall_call+0x7/0xb

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

software suspend in 2.5.70-mm3.

Post by Michael Fran » Thu, 05 Jun 2003 16:40:15



Quote:> > hda: start_power_step(susp: 1, step: 0)
> > hda: start_power_step(susp: 1, step: 1)
> > hda: start_power_step(susp: 1, step: 2)
> > hda: complete_power_step(susp: 1, step: 2, stat: 50, err: 0)
> > hda: completing PM request, suspend: 1
> > Suspending devices
> > /critical section: Counting pages to copy[nosave c03f7000] (pages needed:
> > 2273+512=2785 free: 14110) Alloc pagedir
> > ............
> > [nosave c03f7000]critical section/: done (2273 pages copied)
> > hda: Wakeup request inited, waiting for !BSY...
> > hda: start_power_step(susp: 0, step: 0)
> > hda: start_power_step(susp: 0, step: 101)
> > hda: completing PM request, suspend: 0
> > Devices Resumed
> > Devices Resumed

> Hrm... the joy if swsusp putting your disk to sleep just to wake it up
> right away... I need to check if I can differenciate suspend-to-disk
> from suspend-to-ram here to just not put the drive in STANDBY mode
> on suspend-to-disk (just freeze the queues)

It did this also in 2.4 until Nigel Cunningham fixed it.

Quote:

> > Writing data to swap (2273 pages): .<3>bad: scheduling while atomic!

> Here's the real one. However, it doesn't look related to my sleep code,
> though I cannot guarantee this for sure right now, it _seems_ it's
> a swsusp bug you are hitting.

Well, awaiting the next patch...

Regards
Michael

--
Powered by linux-2.5.70-mm3
My current linux related activities in rough order of priority:
- Testing of 2.4/2.5 kernel interactivity
- Testing of Swsusp for 2.4
- Testing of Opera 7.11 emphasizing interactivity
- Research of NFS i/o errors during transfer 2.4>2.5
- Learning 2.5 series kernel debugging with kgdb - it's in the -mm tree
- Studying 2.5 series serial and ide drivers, ACPI, S3
* Input and feedback is always welcome *
Joke of the day: http://lwn.net/Articles/34848/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

software suspend in 2.5.70-mm3.

Post by Pavel Mache » Thu, 05 Jun 2003 21:50:16


Hi!

Quote:> > ............
> > [nosave c03f7000]critical section/: done (2273 pages copied)
> > hda: Wakeup request inited, waiting for !BSY...
> > hda: start_power_step(susp: 0, step: 0)
> > hda: start_power_step(susp: 0, step: 101)
> > hda: completing PM request, suspend: 0
> > Devices Resumed
> > Devices Resumed

> Hrm... the joy if swsusp putting your disk to sleep just to wake it up
> right away... I need to check if I can differenciate suspend-to-disk
> from suspend-to-ram here to just not put the drive in STANDBY mode
> on suspend-to-disk (just freeze the queues)

Why? Suspending then resuming it may take long but seems correct to
me.

Quote:> > Writing data to swap (2273 pages): .<3>bad: scheduling while atomic!

> Here's the real one. However, it doesn't look related to my sleep code,
> though I cannot guarantee this for sure right now, it _seems_ it's
> a swsusp bug you are hitting.

Yes, it looks so.
                                                                Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

software suspend in 2.5.70-mm3.

Post by Pavel Mache » Thu, 05 Jun 2003 22:20:16


Hi!

Quote:> > > Still races. Ben's stuff is needed

> > I have it working with some fixes from what I sent earlier, I'll
> > repost that tonight or tomorrow, I need to extract that from
> > a half-broken tree ;)

> Ok, here is it. It still need a bit of cleanup (removal of magic
> number for "steps" -> enum, etc...) and we may want to do more
> things on wakeup especially for ide-cd, Also I don't deal with
> ide-tape or ide-floppy in there and haven't fully studied the
> impact with ide-scsi....

> So it's not meant to be merged as-is, though I'd appreciate to
> know if it helps for you.

> Bartolomiej: Any comments appreciated, I won't do the ide-tape/floppy
> part as I don't know/own these, I think i'll let you decide if
> anything more is needed on the wakeup path for ide-cd... Once I
> have enough feedback, I'll send you a cleanified version as
> candidate for upstream merge.

Please send cleaned up version ASAP... Waiting will do no good. If it
handles only ide-disks, that's okay, its still way better than whats
in the tree.

                                                                Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. 2.5.70 and 2.5.70-mm3 hang on bootup

Both 2.5.70 and 2.5.70-mm3 hang right after "Ok, booting the kernel..." on
one of my test boxes (at the point, nothing works, not even turning on/off
the NumLock LED).

Hardware: ASUS A7S333, Athlon 2600+, 1 GB RAM
Compiler: gcc 3.3

Haven't had the time to debug this yet (and probably won't have the time
for a couple more days, busy with work ATM); any ideas?

LLaP
bero
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Database Du Jour?

3. [2.5.70][ANNOUNCE] kexec for 2.5.70 available

4. ispell

5. 2.5.70-mm3 with contest

6. Strange PPP problem!

7. About 2.5.70-mm3

8. net/Config.in

9. 2.5.70-mm3 - Oops and hang

10. 2.5.70-mm3

11. capacity in 2.5.70-mm3

12. 2.5.70-mm3: ioctl32-cleanup-ppc64

13. Some oddities from 2.5.67 to 2.5.70-mm3