Re: [Bug #11989] Suspend failure on NForce4-based boards due to chanes in stop_machine

Heiko Carstens
2008-11-11T12:42:01Z

On Tue, Nov 11, 2008 at 12:31:34PM +0100, Heiko Carstens wrote:
> On Tue, Nov 11, 2008 at 11:52:14AM +0100, Ingo Molnar wrote:
> >
> > * Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> >
> > > However, it is reproducible by doing
> > >
> > > # echo core > /sys/power/pm_test
> > >
> > > and repeating
> > >
> > > # echo disk > /sys/power/state
> > >
> > > for a couple of times, in which case the last two lines printed to the console
> > > before a (solid) hang are:
> > >
> > > SMP alternatives: switching to SMP code
> > > Booting processor 1 APIC 0x1 ip 0x6000
> > >
> > > So, it evidently fails while re-enabling the non-boot CPU and not
> > > during disabling it as I thought before.
> > >
> > > With commit c9583e55fa2b08a230c549bd1e3c0bde6c50d9cc reverted the
> > > issue is not reproducible any more.
> >
> > [ Cc:-ed workqueue/locking/suspend-race-condition experts. ]
> >
> > Seems like the new kernel/stop_machine.c logic has a race for the test
> > sequence above. (Below is the bisected commit again, maybe the race is
> > visible via email review as well.)
>
> FWIW, I tried to reproduce this on s390 and got the following:
>
> A process that would do nothing but onlining/offlining cpus would get
> stuck after a while:
>
> 0 schedule+842 [0x342522]
> 1 schedule_timeout+200 [0x342ec4]
> 2 wait_for_common+362 [0x341fd6]
> 3 wait_for_completion+54 [0x342146]
> 4 __synchronize_sched+80 [0x81670]
> 5 cpu_down+172 [0x33c030]
> 6 store_online+96 [0x33c488]
> 7 sysdev_store+52 [0x1bda84]
> 8 sysfs_write_file+242 [0x1350ba]
> 9 vfs_write+176 [0xd2028]
> 10 sys_write+82 [0xd21ea]
> 11 sysc_noemu+16 [0x269d8]
>
> All cpus are in cpu_idle and no other task in state TASK_INTERRUPTIBLE
> or TASK_UNINTERRUPTIBLE. However it would continue to work as soon as
> I login into the system or generate a console interrupt.
> I'm going to look into the dump and see if I can figure out what is
> broken here.
> Dunno if it is the same bug or something else.

[Cc:-ed Steven and Paul, since this backtrace seems to be RCU specific]

Steven, Paul, any idea what could cause the hang? I think I would
get lost in the RCU code...