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 <heukelum@xxxxxxxxxxxxx>
> 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
|