On 9/29/07, Luming Yu <luming.yu@xxxxxxxxx> wrote: >Hello list, >The PSR.lp bit of kernel thread kondemand sometimes would be set, then >causes set_pstate PAL call fails with invalid argument. I tracked down >to the place that the PSR.lp was set in do_notify_resume_user. I don't >understand why not use task->thread.on_ustack to >check if on user stack.in the first place. For optimization? The reason for not using on_ustack is because stack in fsys is a mixture of kernel states and user states. on_ustack is not a correct way to reflect fsys stack usage. It's cleared to 0 during fsys which can not be explained as it's not user stack. The current implementation of checking user_stack() is correct. Though it would be better to change user_stack()'s name to something like fsys_stack() to avoid future confusion. The patch actually always makes user_stack()=0 and fsys_mode()=0 during fsys execution. Thus there is no psr.lp=1 during fsys execution. And signal is always delivered during fsys execution.This masks the "Transition failure" issue instead of fixing it. The patch might cause issues in some stress tests. Could you please provide more debug info on the issue? Thanks. -Fenghua - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|