Re: Potential timer bug
Err. I'm stupid. This isn't a bug. On Fri, 11 Feb 2005 02:09:10 -0700, Tipp Moseley <[EMAIL PROTECTED]> wrote: > Hello, > > I am running on a uniprocessor x86 with CONFIG_SMP disabled and > CONFIG_PREEMPT enabled. > > The problem I have encountered is when using a timer in a module. The > timer is set to execute every 3 ticks, and does nothing but increment > a counter, and that works fine. However, when the module is unloaded > sometimes the system hangs on module exit and barfs something like: > > Unable to handle kernel paging request at virtual address e18861bc > printing eip: > c0122a88 > *pde = 015e5067 > *pte = > Oops: 0002 [#1] > PREEMPT > Modules linked in: yenta socket, rsrc_nonstatic sonypi > CPU: 0 > ... > Call Trace: > __do_softirq+0x76/0x90 > do_softirq+0x41/0x50 > ... > <0>Kernel panic - not syncing: Fatal exception in interrupt > > I am using del_timer_sync to delete the timer in the module_exit > routine, and sometimes it works correctly. My theory is that since > with CONFIG_SMP disabled, del_timer_sync is the same as del_timer. > This allows the timer to potentially execute after the module has > unloaded, causing the invalid paging request. > > My solution to the problem (which works, but is probably not optimal) > is to change '#ifdef CONFIG_SMP' to '#if defined(CONFIG_SMP) || > defined(CONFIG_PREEMPT)' around the code defining timer_del_sync. A > patch is attached. Let me know if there's any more information that I > can provide. > > Thanks, > > Tipp Moseley > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Potential timer bug
Hello, I am running on a uniprocessor x86 with CONFIG_SMP disabled and CONFIG_PREEMPT enabled. The problem I have encountered is when using a timer in a module. The timer is set to execute every 3 ticks, and does nothing but increment a counter, and that works fine. However, when the module is unloaded sometimes the system hangs on module exit and barfs something like: Unable to handle kernel paging request at virtual address e18861bc printing eip: c0122a88 *pde = 015e5067 *pte = Oops: 0002 [#1] PREEMPT Modules linked in: yenta socket, rsrc_nonstatic sonypi CPU: 0 ... Call Trace: __do_softirq+0x76/0x90 do_softirq+0x41/0x50 ... <0>Kernel panic - not syncing: Fatal exception in interrupt I am using del_timer_sync to delete the timer in the module_exit routine, and sometimes it works correctly. My theory is that since with CONFIG_SMP disabled, del_timer_sync is the same as del_timer. This allows the timer to potentially execute after the module has unloaded, causing the invalid paging request. My solution to the problem (which works, but is probably not optimal) is to change '#ifdef CONFIG_SMP' to '#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)' around the code defining timer_del_sync. A patch is attached. Let me know if there's any more information that I can provide. Thanks, Tipp Moseley linux-2.6.11-rc3-bk7-timer Description: Binary data
Potential timer bug
Hello, I am running on a uniprocessor x86 with CONFIG_SMP disabled and CONFIG_PREEMPT enabled. The problem I have encountered is when using a timer in a module. The timer is set to execute every 3 ticks, and does nothing but increment a counter, and that works fine. However, when the module is unloaded sometimes the system hangs on module exit and barfs something like: Unable to handle kernel paging request at virtual address e18861bc printing eip: c0122a88 *pde = 015e5067 *pte = Oops: 0002 [#1] PREEMPT Modules linked in: yenta socket, rsrc_nonstatic sonypi CPU: 0 ... Call Trace: __do_softirq+0x76/0x90 do_softirq+0x41/0x50 ... 0Kernel panic - not syncing: Fatal exception in interrupt I am using del_timer_sync to delete the timer in the module_exit routine, and sometimes it works correctly. My theory is that since with CONFIG_SMP disabled, del_timer_sync is the same as del_timer. This allows the timer to potentially execute after the module has unloaded, causing the invalid paging request. My solution to the problem (which works, but is probably not optimal) is to change '#ifdef CONFIG_SMP' to '#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)' around the code defining timer_del_sync. A patch is attached. Let me know if there's any more information that I can provide. Thanks, Tipp Moseley linux-2.6.11-rc3-bk7-timer Description: Binary data
Re: Potential timer bug
Err. I'm stupid. This isn't a bug. On Fri, 11 Feb 2005 02:09:10 -0700, Tipp Moseley [EMAIL PROTECTED] wrote: Hello, I am running on a uniprocessor x86 with CONFIG_SMP disabled and CONFIG_PREEMPT enabled. The problem I have encountered is when using a timer in a module. The timer is set to execute every 3 ticks, and does nothing but increment a counter, and that works fine. However, when the module is unloaded sometimes the system hangs on module exit and barfs something like: Unable to handle kernel paging request at virtual address e18861bc printing eip: c0122a88 *pde = 015e5067 *pte = Oops: 0002 [#1] PREEMPT Modules linked in: yenta socket, rsrc_nonstatic sonypi CPU: 0 ... Call Trace: __do_softirq+0x76/0x90 do_softirq+0x41/0x50 ... 0Kernel panic - not syncing: Fatal exception in interrupt I am using del_timer_sync to delete the timer in the module_exit routine, and sometimes it works correctly. My theory is that since with CONFIG_SMP disabled, del_timer_sync is the same as del_timer. This allows the timer to potentially execute after the module has unloaded, causing the invalid paging request. My solution to the problem (which works, but is probably not optimal) is to change '#ifdef CONFIG_SMP' to '#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)' around the code defining timer_del_sync. A patch is attached. Let me know if there's any more information that I can provide. Thanks, Tipp Moseley - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
