* 2.6.14: Oops on suspend after on-the-fly switch to anticipatory i/o scheduler - PowerBook5,4
@ 2005-10-29 17:26 Paul Collins
2005-10-30 2:59 ` Tejun Heo
0 siblings, 1 reply; 4+ messages in thread
From: Paul Collins @ 2005-10-29 17:26 UTC (permalink / raw)
To: linux-kernel
I boot with elevator=cfq (wanted to try the ionice stuff, never got
around to it). Having decided to go back to the anticipatory
scheduler, I did the following:
# echo anticipatory > /sys/block/hda/queue/scheduler
# echo anticipatory > /sys/block/hdc/queue/scheduler
A while later I did 'sudo snooze', which produced the Oops below.
Booting with elevator=as and then changing to cfq, sleep works fine.
But if I resume and change back to anticipatory I get a similar Oops
on the next 'sudo snooze'.
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C01E1948 LR: C01D6A60 SP: EFBC5C20 REGS: efbc5b70 TRAP: 0300 Not tainted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000020, DSISR: 40000000
TASK = efb012c0[1213] 'pmud' THREAD: efbc4000
Last syscall: 54
GPR00: 00080000 EFBC5C20 EFB012C0 EFE9E044 EFBC5CE8 00000002 00000000 C03B0000
GPR08: C046E5D8 00000000 C03B47C8 E6A58360 22042422 1001E4DC 10010000 10000000
GPR16: 10000000 10000000 10000000 7FE4EB40 10000000 10000000 10010000 C0400000
GPR24: C0380000 00000002 00000002 C046E0C0 00000000 00000002 00000000 EFBC5CE8
NIP [c01e1948] as_insert_request+0xa8/0x6b0
LR [c01d6a60] __elv_add_request+0xa0/0x100
Call trace:
[c01d6a60] __elv_add_request+0xa0/0x100
[c01ffb84] ide_do_drive_cmd+0xb4/0x190
[c01fc1c0] generic_ide_suspend+0x80/0xa0
[c01d4574] suspend_device+0x104/0x160
[c01d47c0] device_suspend+0x120/0x330
[c03f3b50] pmac_suspend_devices+0x50/0x1b0
[c03f4294] pmu_ioctl+0x344/0x9b0
[c0082aa4] do_ioctl+0x84/0x90
[c0082b3c] vfs_ioctl+0x8c/0x460
[c0082f50] sys_ioctl+0x40/0x80
[c0004850] ret_from_syscall+0x0/0x4c
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.6.14: Oops on suspend after on-the-fly switch to anticipatory i/o scheduler - PowerBook5,4
2005-10-29 17:26 2.6.14: Oops on suspend after on-the-fly switch to anticipatory i/o scheduler - PowerBook5,4 Paul Collins
@ 2005-10-30 2:59 ` Tejun Heo
2005-10-30 13:43 ` Tejun Heo
0 siblings, 1 reply; 4+ messages in thread
From: Tejun Heo @ 2005-10-30 2:59 UTC (permalink / raw)
To: Paul Collins; +Cc: linux-kernel, Jens Axboe
Hello, Paul.
Paul Collins wrote:
> I boot with elevator=cfq (wanted to try the ionice stuff, never got
> around to it). Having decided to go back to the anticipatory
> scheduler, I did the following:
>
> # echo anticipatory > /sys/block/hda/queue/scheduler
> # echo anticipatory > /sys/block/hdc/queue/scheduler
>
> A while later I did 'sudo snooze', which produced the Oops below.
>
> Booting with elevator=as and then changing to cfq, sleep works fine.
> But if I resume and change back to anticipatory I get a similar Oops
> on the next 'sudo snooze'.
>
>
> Oops: kernel access of bad area, sig: 11 [#1]
> NIP: C01E1948 LR: C01D6A60 SP: EFBC5C20 REGS: efbc5b70 TRAP: 0300 Not tainted
> MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
> DAR: 00000020, DSISR: 40000000
> TASK = efb012c0[1213] 'pmud' THREAD: efbc4000
> Last syscall: 54
> GPR00: 00080000 EFBC5C20 EFB012C0 EFE9E044 EFBC5CE8 00000002 00000000 C03B0000
> GPR08: C046E5D8 00000000 C03B47C8 E6A58360 22042422 1001E4DC 10010000 10000000
> GPR16: 10000000 10000000 10000000 7FE4EB40 10000000 10000000 10010000 C0400000
> GPR24: C0380000 00000002 00000002 C046E0C0 00000000 00000002 00000000 EFBC5CE8
> NIP [c01e1948] as_insert_request+0xa8/0x6b0
> LR [c01d6a60] __elv_add_request+0xa0/0x100
> Call trace:
> [c01d6a60] __elv_add_request+0xa0/0x100
> [c01ffb84] ide_do_drive_cmd+0xb4/0x190
> [c01fc1c0] generic_ide_suspend+0x80/0xa0
> [c01d4574] suspend_device+0x104/0x160
> [c01d47c0] device_suspend+0x120/0x330
> [c03f3b50] pmac_suspend_devices+0x50/0x1b0
> [c03f4294] pmu_ioctl+0x344/0x9b0
> [c0082aa4] do_ioctl+0x84/0x90
> [c0082b3c] vfs_ioctl+0x8c/0x460
> [c0082f50] sys_ioctl+0x40/0x80
> [c0004850] ret_from_syscall+0x0/0x4c
>
Can you please post assembly of as_insert_request? You can get this by
doing 'objdump -d drivers/block/as-iosched.o | less' and copy & pasting
as_insert_request part.
I'm also trying to reproduce the oops but haven't succeeded yet. Does
the oops occur only if the disk is loaded while switching scheduler /
snoozing or does it happen regardless of disk load?
And one more thing. Can you please try the following program and see if
it causes the oops? The program simply writes 3, sleeps one second and
then writes 0. When redirected to the disk's power/state sysfs node, it
will make the disk sleep for 1 second and then wake it up.
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
int level = 3;
if (argc > 1)
level = atoi(argv[1]);
setvbuf(stdout, NULL, _IONBF, 0);
printf("%d", level);
sleep(1);
printf("0");
return 0;
}
After compiling, do the following.
./a.out > /sys/block/hd?/device/power/state
Thanks. :-)
--
tejun
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.6.14: Oops on suspend after on-the-fly switch to anticipatory i/o scheduler - PowerBook5,4
2005-10-30 2:59 ` Tejun Heo
@ 2005-10-30 13:43 ` Tejun Heo
2005-10-31 12:51 ` Jens Axboe
0 siblings, 1 reply; 4+ messages in thread
From: Tejun Heo @ 2005-10-30 13:43 UTC (permalink / raw)
To: Tejun Heo; +Cc: Paul Collins, linux-kernel, Jens Axboe
Tejun Heo wrote:
> Hello, Paul.
>
> Paul Collins wrote:
>
>> I boot with elevator=cfq (wanted to try the ionice stuff, never got
>> around to it). Having decided to go back to the anticipatory
>> scheduler, I did the following:
>>
>> # echo anticipatory > /sys/block/hda/queue/scheduler
>> # echo anticipatory > /sys/block/hdc/queue/scheduler
>>
>> A while later I did 'sudo snooze', which produced the Oops below.
>>
>> Booting with elevator=as and then changing to cfq, sleep works fine.
>> But if I resume and change back to anticipatory I get a similar Oops
>> on the next 'sudo snooze'.
>>
>>
>> Oops: kernel access of bad area, sig: 11 [#1]
>> NIP: C01E1948 LR: C01D6A60 SP: EFBC5C20 REGS: efbc5b70 TRAP: 0300
>> Not tainted
>> MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
>> DAR: 00000020, DSISR: 40000000
>> TASK = efb012c0[1213] 'pmud' THREAD: efbc4000
>> Last syscall: 54 GPR00: 00080000 EFBC5C20 EFB012C0 EFE9E044
>> EFBC5CE8 00000002 00000000 C03B0000 GPR08: C046E5D8 00000000
>> C03B47C8 E6A58360 22042422 1001E4DC 10010000 10000000 GPR16:
>> 10000000 10000000 10000000 7FE4EB40 10000000 10000000 10010000
>> C0400000 GPR24: C0380000 00000002 00000002 C046E0C0 00000000
>> 00000002 00000000 EFBC5CE8 NIP [c01e1948] as_insert_request+0xa8/0x6b0
>> LR [c01d6a60] __elv_add_request+0xa0/0x100
>> Call trace:
>> [c01d6a60] __elv_add_request+0xa0/0x100
>> [c01ffb84] ide_do_drive_cmd+0xb4/0x190
>> [c01fc1c0] generic_ide_suspend+0x80/0xa0
>> [c01d4574] suspend_device+0x104/0x160
>> [c01d47c0] device_suspend+0x120/0x330
>> [c03f3b50] pmac_suspend_devices+0x50/0x1b0
>> [c03f4294] pmu_ioctl+0x344/0x9b0
>> [c0082aa4] do_ioctl+0x84/0x90
>> [c0082b3c] vfs_ioctl+0x8c/0x460
>> [c0082f50] sys_ioctl+0x40/0x80
>> [c0004850] ret_from_syscall+0x0/0x4c
>>
>
> Can you please post assembly of as_insert_request? You can get this by
> doing 'objdump -d drivers/block/as-iosched.o | less' and copy & pasting
> as_insert_request part.
>
> I'm also trying to reproduce the oops but haven't succeeded yet. Does
> the oops occur only if the disk is loaded while switching scheduler /
> snoozing or does it happen regardless of disk load?
>
> And one more thing. Can you please try the following program and see if
> it causes the oops? The program simply writes 3, sleeps one second and
> then writes 0. When redirected to the disk's power/state sysfs node, it
> will make the disk sleep for 1 second and then wake it up.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int argc, char **argv)
> {
> int level = 3;
> if (argc > 1)
> level = atoi(argv[1]);
> setvbuf(stdout, NULL, _IONBF, 0);
> printf("%d", level);
> sleep(1);
> printf("0");
> return 0;
> }
>
> After compiling, do the following.
>
> ./a.out > /sys/block/hd?/device/power/state
>
> Thanks. :-)
>
Oh.. Never mind. Jens seems to know how to fix it. :-)
--
tejun
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.6.14: Oops on suspend after on-the-fly switch to anticipatory i/o scheduler - PowerBook5,4
2005-10-30 13:43 ` Tejun Heo
@ 2005-10-31 12:51 ` Jens Axboe
0 siblings, 0 replies; 4+ messages in thread
From: Jens Axboe @ 2005-10-31 12:51 UTC (permalink / raw)
To: Tejun Heo; +Cc: Paul Collins, linux-kernel
On Sun, Oct 30 2005, Tejun Heo wrote:
> Tejun Heo wrote:
> >Hello, Paul.
> >
> >Paul Collins wrote:
> >
> >>I boot with elevator=cfq (wanted to try the ionice stuff, never got
> >>around to it). Having decided to go back to the anticipatory
> >>scheduler, I did the following:
> >>
> >># echo anticipatory > /sys/block/hda/queue/scheduler
> >># echo anticipatory > /sys/block/hdc/queue/scheduler
> >>
> >>A while later I did 'sudo snooze', which produced the Oops below.
> >>
> >>Booting with elevator=as and then changing to cfq, sleep works fine.
> >>But if I resume and change back to anticipatory I get a similar Oops
> >>on the next 'sudo snooze'.
> >>
> >>
> >> Oops: kernel access of bad area, sig: 11 [#1]
> >> NIP: C01E1948 LR: C01D6A60 SP: EFBC5C20 REGS: efbc5b70 TRAP: 0300
> >>Not tainted
> >> MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
> >> DAR: 00000020, DSISR: 40000000
> >> TASK = efb012c0[1213] 'pmud' THREAD: efbc4000
> >> Last syscall: 54 GPR00: 00080000 EFBC5C20 EFB012C0 EFE9E044
> >>EFBC5CE8 00000002 00000000 C03B0000 GPR08: C046E5D8 00000000
> >>C03B47C8 E6A58360 22042422 1001E4DC 10010000 10000000 GPR16:
> >>10000000 10000000 10000000 7FE4EB40 10000000 10000000 10010000
> >>C0400000 GPR24: C0380000 00000002 00000002 C046E0C0 00000000
> >>00000002 00000000 EFBC5CE8 NIP [c01e1948] as_insert_request+0xa8/0x6b0
> >> LR [c01d6a60] __elv_add_request+0xa0/0x100
> >> Call trace:
> >> [c01d6a60] __elv_add_request+0xa0/0x100
> >> [c01ffb84] ide_do_drive_cmd+0xb4/0x190
> >> [c01fc1c0] generic_ide_suspend+0x80/0xa0
> >> [c01d4574] suspend_device+0x104/0x160
> >> [c01d47c0] device_suspend+0x120/0x330
> >> [c03f3b50] pmac_suspend_devices+0x50/0x1b0
> >> [c03f4294] pmu_ioctl+0x344/0x9b0
> >> [c0082aa4] do_ioctl+0x84/0x90
> >> [c0082b3c] vfs_ioctl+0x8c/0x460
> >> [c0082f50] sys_ioctl+0x40/0x80
> >> [c0004850] ret_from_syscall+0x0/0x4c
> >>
> >
> >Can you please post assembly of as_insert_request? You can get this by
> >doing 'objdump -d drivers/block/as-iosched.o | less' and copy & pasting
> >as_insert_request part.
> >
> >I'm also trying to reproduce the oops but haven't succeeded yet. Does
> >the oops occur only if the disk is loaded while switching scheduler /
> >snoozing or does it happen regardless of disk load?
> >
> >And one more thing. Can you please try the following program and see if
> >it causes the oops? The program simply writes 3, sleeps one second and
> >then writes 0. When redirected to the disk's power/state sysfs node, it
> >will make the disk sleep for 1 second and then wake it up.
> >
> >#include <stdio.h>
> >#include <stdlib.h>
> >
> >int main(int argc, char **argv)
> >{
> > int level = 3;
> > if (argc > 1)
> > level = atoi(argv[1]);
> > setvbuf(stdout, NULL, _IONBF, 0);
> > printf("%d", level);
> > sleep(1);
> > printf("0");
> > return 0;
> >}
> >
> >After compiling, do the following.
> >
> >./a.out > /sys/block/hd?/device/power/state
> >
> >Thanks. :-)
> >
>
> Oh.. Never mind. Jens seems to know how to fix it. :-)
This should fix it.
-------
Don't clear ->elevator_data on exit, if we are switching queues we are
overwriting the data of the new io scheduler.
Signed-off-by: Jens Axboe <axboe@suse.de>
diff --git a/drivers/block/cfq-iosched.c b/drivers/block/cfq-iosched.c
index cd056e7..23df2d2 100644
--- a/drivers/block/cfq-iosched.c
+++ b/drivers/block/cfq-iosched.c
@@ -2260,10 +2260,8 @@ static void cfq_put_cfqd(struct cfq_data
if (!atomic_dec_and_test(&cfqd->ref))
return;
- blk_put_queue(q);
-
cfq_shutdown_timer_wq(cfqd);
- q->elevator->elevator_data = NULL;
+ blk_put_queue(q);
mempool_destroy(cfqd->crq_pool);
kfree(cfqd->crq_hash);
--
Jens Axboe
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-10-31 12:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-10-29 17:26 2.6.14: Oops on suspend after on-the-fly switch to anticipatory i/o scheduler - PowerBook5,4 Paul Collins
2005-10-30 2:59 ` Tejun Heo
2005-10-30 13:43 ` Tejun Heo
2005-10-31 12:51 ` Jens Axboe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox