aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/serial/usb_debug.c
diff options
context:
space:
mode:
authorBjoern B. Brandenburg <bbb@cs.unc.edu>2010-02-26 19:33:42 -0500
committerBjoern B. Brandenburg <bbb@cs.unc.edu>2010-02-26 19:33:42 -0500
commitda2cb92c9df507fe61053045caa0c9a08de4c73b (patch)
tree49301e7e13ac0f4dad5453838d82853a3096cce1 /drivers/usb/serial/usb_debug.c
parent049d1809fcb0b246a9f49e4edc1f2277bcd9d0da (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