On Oct 7,  9:21pm, Mark Brinicombe wrote:
> Subject: Re: Kernel bug (when switching v-consoles)?
> >_data_abort_handler ( +0x10)
> >_unsleep ( +0x10)
> >_psignal
> >_physcon_switch
> >_console_switch
>
> This is the killer sequence...
>
> I believe the bug is in the console code but I have not confirmed that.
> I suspect that something (the proc pointer involved) may be trashed. Thus
> an non existant processes is being woken...
>
> Q. did you have X running at the time ?
>
> [Rob, nut: Thoughts ... ? looking briefly at the switching code I am not
> particularly happy with the way the switching is working ... for example the
> signal is only delivered to the process owning the console being switched in
> and not to the one being switched out. Also signals should only be used if
> explicitly requested via an ioctl in my view.
> Also I think that the locking is still broken in the switching code]

I'm not very happy with it either but I have to do what the console code
requires and X does need some way to tell when it is being switched in. I don't
think it really matters whether the signal is requested by an ioctl or not so
long as the driver interface is well defined and bug-free. A switch-out signal
isn't particularly useful because it won't get delivered until some
indeterminate time after the switch-out completes. A better way to do things
would be to intercept the entire switch-out/switch-in inside the kernel and
handle the mapping of the real VRAM transparently (possibly with a redraw
hint).

Cheers

Rob

--