Hi Marc,
that's funny. We both wrote almost the same mail at the same time.
On 13.12.2007 02:14, Marc Jones wrote:
ron minnich wrote:
On Dec 12, 2007 4:50 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I don't like this. disable_car() should just be able to return without problems. If it can't do that, fix it.
I agree.
Why exactly do we invalidate the stack? If the stack is clobbered, the contents of variables should be in a clobbered state as well. In that case, I suspect parts of our v3 code would misbehave as well.
no, because what happens here is you are essentially dropping all local variables etc. -- this is a jump to a new context, and all the variables in that context are re-initialized.
Anyway, maybe Marc can tell us what is wrong. I just don't know. I never solved it on the LX either. I'm happy to see it solved but, at the same time, I don't want to burn my next month of limited cycles on something i have a workaround for.
I assume you are asking about the wbind. The important part being the wb, writeback. This pushes anything that was in the cache to memory. In LX we maintain the same stack location (same pointers) so we don't need to copy the cache to memory. We can just write it back. This works on the Norwich platform. Any non-working LX systems should be debugged.
Yes, I saw that wbinvd and wondered how it could fail.
The K8 is a bit different. The CAR is specified to be in the C0000 region and the CAR configuration works a little bit differently than the LX and Intel way. The result of those requirements is that at the end of CAR the stack and other contents of CAR have to be copied. Once copied the pointers are adjusted and then the function returns.
You mean, the stack is "moved"? Or why do we need to adjust the pointers? Won't that leave pointers to variables on stack dangling?
Regards, Carl-Daniel