On Thu, Jan 22, 2009 at 08:05:19AM -0600, Martin Hicks wrote: > > On Mon, Jan 19, 2009 at 03:16:54PM -0600, Martin Hicks wrote: > > > > Hi, > > > > I've been trying to get patches for 2.6.29-rc out, but I've been unable > > to get it working correctly for x86_64. The patches are here > > > > ... > > > This happens right in the "nasty" interrupt stack fix-up at the > > end of kdba_get_stack_info_alternate() > > > > Any ideas why this be happening? Did I mis-merge somewhere? > > d99015b1abbad743aa049b439c1e1dede6d0fa49 is first bad commit > commit d99015b1abbad743aa049b439c1e1dede6d0fa49 > Author: Alexander van Heukelum <[email protected]> > Date: Wed Nov 19 01:18:11 2008 +0100 > > That's the commit that breaks kdb. I still haven't figured out how this > changes the stack contents when the fixup happens.
In 2.6.28 the top few bytes (highest addresses) of the interrupt stack look like this (top == highest addr, bottom == lowest addr): <next stack pointer> <- top of irqstack and pointer to the previous stack <ret_from_intr > <- return address < 5 stack addrs > <- local stackspace <do_IRQ > <- the next function down the stack 2.6.29 has the ret_from_intr address right at the top address of the stack, so ar.next is incorrect and tries to modify kernel code in ret_from_intr. What pushes this stack pointer that we use to find the pre-interrupt stack? Is that done by hardwware? mh _______________________________________________ kdb mailing list [email protected] http://oss.sgi.com/mailman/listinfo/kdb
