diff options
author | Bjoern B. Brandenburg <bbb@cs.unc.edu> | 2010-02-26 19:33:42 -0500 |
---|---|---|
committer | Bjoern B. Brandenburg <bbb@cs.unc.edu> | 2010-02-26 19:33:42 -0500 |
commit | da2cb92c9df507fe61053045caa0c9a08de4c73b (patch) | |
tree | 49301e7e13ac0f4dad5453838d82853a3096cce1 /drivers/usb/serial/usb_debug.c | |
parent | 049d1809fcb0b246a9f49e4edc1f2277bcd9d0da (diff) |
Revert "Fix BUG: enter gsnedf_schedule with entry->scheduled = NULL"
This reverts commit 0ee906925fbca18a3dc76a2e42e710d0f1fbd721.
Resetting scheduled_on too early can cause more than one CPU to
spin on a task's stack to become available, as witnessed by the
following trace:
4562253 P0: (find/1489) invoked gsnedf_schedule.
4562254 P0: (find/1489) blocks:1 out_of_time:0 np:0 sleep:0 preempt:1 state:1 sig:0
XXXX TOO EARLY RESET OF SCHEDULED_ON
4562256 P0: (find/1489) gsnedf_schedule: scheduled_on = NO_CPU
4562262 P1: (find/1489) wake_up at 76632733947
4562265 P1: rt: adding find/1489 (7000000, 13000000) rel=76631524234 to ready queue at 76632741843
XXXX BAD LINKING
4562268 P1: (find/1489) linked to 3.
4562273 P0: (find/1489) state changed while we dropped the lock: is_running=1, was_running=0
4562279 P0: (find/1489) gsnedf_task_block: scheduled_on = NO_CPU
4562280 P3: (find/1489) scheduled at 76632789894
4562281 P0: NULL linked to 3.
4562282 P3: (find/1489) migrate from 0
4562283 P3: (find/1489) stack_in_use=0
4562284 P0: (find/1489) wake_up at 76632797387
XXXX P3 WAITS FOR THE STACK
4562285 P3: (find/1489) waiting to deschedule
4562286 P0: rt: adding find/1489 (7000000, 13000000) rel=76631524234 to ready queue at 76632802553
4562287 P0: check_for_preemptions: attempting to link task 1489 to 2
XXXX BAD LINKING, AGAIN
4562288 P0: (find/1489) linked to 2.
4562294 P2: (swapper/0) invoked gsnedf_schedule.
4562296 P2: (swapper/0) will be preempted by find/1489
XXXX FINALLY STACK WILL BE RELEASED
4562295 P0: (find/1489) switched away from
XXXX GRABBED BY P2
4562298 P2: (find/1489) scheduled at 76632848683
4562300 P2: (find/1489) migrate from 0
4562301 P2: (find/1489) stack_in_use=0
XXXX P2 STARTS FOR THE STACK
4562302 P2: (find/1489) waiting to deschedule
Our migration code does not anticipate more than two CPUs contending for
the same stack. All it handles is a "handoff"; it is the responsibility of
the scheduler plugin to make sure that never two CPUs try to pull the the
same task at the same time. This has been violated here because the task
got linked around before it has been descheduled.
Diffstat (limited to 'drivers/usb/serial/usb_debug.c')
0 files changed, 0 insertions, 0 deletions