lkml.org 
[lkml]   [2006]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: swsusp regression [Was: 2.6.18-rc3-mm2]
    On Tue, Aug 08 2006, Jens Axboe wrote:
    > On Tue, Aug 08 2006, Rafael J. Wysocki wrote:
    > > On Tuesday 08 August 2006 12:43, Jens Axboe wrote:
    > > > On Tue, Aug 08 2006, Jiri Slaby wrote:
    > > > > Rafael J. Wysocki wrote:
    > > > > >On Monday 07 August 2006 18:23, Jason Lunz wrote:
    > > > > >>In gmane.linux.kernel, you wrote:
    > > > > >>>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/
    > > > > >>>I tried it and guess what :)... swsusp doesn't work :@.
    > > > > >>>
    > > > > >>>This time I was able to dump process states with sysrq-t:
    > > > > >>>http://www.fi.muni.cz/~xslaby/sklad/ide2.gif
    > > > > >>>
    > > > > >>>My guess is ide2/2.0 dies (hpt370 driver), since last thing kernel
    > > > > >>>prints is suspending device 2.0
    > > > > >>Does it go away if you revert this?
    > > > > >>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/broken-out/ide-reprogram-disk-pio-timings-on-resume.patch
    > > > > >>
    > > > > >>That should only affect resume, not suspend, but it does mess around
    > > > > >>with ide power management. Is this maybe happening on the *second*
    > > > > >>suspend?
    > > > > >>
    > > > > >>>-hdc: ATAPI 63X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
    > > > > >>>+hdc: ATAPI CD-ROM drive, 0kB Cache, UDMA(33)
    > > > > >>This looks suspicious. -mm does have several ide-fix-hpt3xx patches.
    > > > > >
    > > > > >I found that git-block.patch broke the suspend for me. Still have no idea
    > > > > >what's up with it.
    > > > >
    > > > > I suspect elevator changes. The wait_for_completion is not woken in
    > > > > ide-io by ll_rw_blk. But I don't understand block layer too much.
    > > >
    > > > The ide changes are far more likely, it's probably missing a completion.
    > >
    > > Actually I think the commit f74bf2e6b415588e562fdcfdd454d587eb33cd46
    > > (Remove ->waiting member from struct request) is wrong, because
    > > generic_ide_suspend() uses the end_of_io member of rq to pass the PM data
    > > to ide_do_drive_cmd() where the pointer gets overwritten by &wait (must_wait
    > > is "true", because action == ide_wait). Previously &wait was stored in
    > > rq->waiting and it didn't overwrite the PM data.
    >
    > Indeed, that looks broken now. That must be what is screwing it up. With
    > the former patch applied, did cdrom detection still look funny to you?
    >
    > I'll concoct a fix for that breakage.

    Something like this.

    diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
    index db647a9..38479a2 100644
    --- a/drivers/ide/ide-io.c
    +++ b/drivers/ide/ide-io.c
    @@ -141,7 +141,7 @@ enum {

    static void ide_complete_power_step(ide_drive_t *drive, struct request *rq, u8 stat, u8 error)
    {
    - struct request_pm_state *pm = rq->end_io_data;
    + struct request_pm_state *pm = rq->data;

    if (drive->media != ide_disk)
    return;
    @@ -164,7 +164,7 @@ static void ide_complete_power_step(ide_

    static ide_startstop_t ide_start_power_step(ide_drive_t *drive, struct request *rq)
    {
    - struct request_pm_state *pm = rq->end_io_data;
    + struct request_pm_state *pm = rq->data;
    ide_task_t *args = rq->special;

    memset(args, 0, sizeof(*args));
    @@ -421,7 +421,7 @@ void ide_end_drive_cmd (ide_drive_t *dri
    }
    }
    } else if (blk_pm_request(rq)) {
    - struct request_pm_state *pm = rq->end_io_data;
    + struct request_pm_state *pm = rq->data;
    #ifdef DEBUG_PM
    printk("%s: complete_power_step(step: %d, stat: %x, err: %x)\n",
    drive->name, rq->pm->pm_step, stat, err);
    @@ -933,7 +933,7 @@ #endif

    static void ide_check_pm_state(ide_drive_t *drive, struct request *rq)
    {
    - struct request_pm_state *pm = rq->end_io_data;
    + struct request_pm_state *pm = rq->data;

    if (blk_pm_suspend_request(rq) &&
    pm->pm_step == ide_pm_state_start_suspend)
    @@ -1018,7 +1018,7 @@ #endif
    rq->cmd_type == REQ_TYPE_ATA_TASKFILE)
    return execute_drive_cmd(drive, rq);
    else if (blk_pm_request(rq)) {
    - struct request_pm_state *pm = rq->end_io_data;
    + struct request_pm_state *pm = rq->data;
    #ifdef DEBUG_PM
    printk("%s: start_power_step(step: %d)\n",
    drive->name, rq->pm->pm_step);
    diff --git a/drivers/ide/ide.c b/drivers/ide/ide.c
    index d7b4499..0fd1e1c 100644
    --- a/drivers/ide/ide.c
    +++ b/drivers/ide/ide.c
    @@ -1219,7 +1219,7 @@ static int generic_ide_suspend(struct de
    memset(&args, 0, sizeof(args));
    rq.cmd_type = REQ_TYPE_PM_SUSPEND;
    rq.special = &args;
    - rq.end_io_data = &rqpm;
    + rq.data = &rqpm;
    rqpm.pm_step = ide_pm_state_start_suspend;
    rqpm.pm_state = state.event;

    @@ -1238,7 +1238,7 @@ static int generic_ide_resume(struct dev
    memset(&args, 0, sizeof(args));
    rq.cmd_type = REQ_TYPE_PM_RESUME;
    rq.special = &args;
    - rq.end_io_data = &rqpm;
    + rq.data = &rqpm;
    rqpm.pm_step = ide_pm_state_start_resume;
    rqpm.pm_state = PM_EVENT_ON;

    --
    Jens Axboe

    -
    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/

    \
     
     \ /
      Last update: 2006-08-08 13:09    [W:0.030 / U:0.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site