advice on dz.c

advice on dz.c

[William Lee Irwin III]

startup() in the 2.4.14 dz.c appears to either not terminate or to
bring down the kernel on a DecStation 5000/200. The 2.4.5 dz.c when
put it in its place appears to work properly, modulo some strangeness
in terminal emulation at runtime.

Unfortunately, attempts to isolate what difference creates the problem
failed to reveal the true cause of this. The kernel appears to die
immediately after restore_flags(). This appears unusual to me as the
changes are largely cosmetic.

I also tried extending the extent of the code over which interrupts
are disabled, to no avail. After extending it to what apparently was
the entire extent of the driver's ->open code the kernel died somewhere
between enabling interrupts again and the printk immediately after
the return to tty_open(). It did not appear that the driver was
re-entered at this point, as printk's for the other entry points
failed to trigger.


I am interested in suggestions as to what code changes I should make
in order to bring this driver into a more robust state so that I myself
can repair the code for use on one of my own personal machines.


Thanks,
Bill

Re: advice on dz.c

[Dave Airlie]

This is unusual I've just taken a run down through a diff of 1.17 and 1.22
from the MIPS CVS tree and I can't see anything that could cause breakage
that has been changed... I'd try commentined out the DZ_DEBUG stuff.. this
isn't meant to be called... unless someone wants to specifically debug
their dz.c on a decstation.... otherwise it should be switched off..

Granted to code doesn't look like it would compile with it off..

Dave.

On Fri, 23 Nov 2001, William Lee Irwin III wrote:

> startup() in the 2.4.14 dz.c appears to either not terminate or to
> bring down the kernel on a DecStation 5000/200. The 2.4.5 dz.c when
> put it in its place appears to work properly, modulo some strangeness
> in terminal emulation at runtime.
>
> Unfortunately, attempts to isolate what difference creates the problem
> failed to reveal the true cause of this. The kernel appears to die
> immediately after restore_flags(). This appears unusual to me as the
> changes are largely cosmetic.
>
> I also tried extending the extent of the code over which interrupts
> are disabled, to no avail. After extending it to what apparently was
> the entire extent of the driver's ->open code the kernel died somewhere
> between enabling interrupts again and the printk immediately after
> the return to tty_open(). It did not appear that the driver was
> re-entered at this point, as printk's for the other entry points
> failed to trigger.
>
>
> I am interested in suggestions as to what code changes I should make
> in order to bring this driver into a more robust state so that I myself
> can repair the code for use on one of my own personal machines.
>
>
> Thanks,
> Bill
>

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied@skynet.ie
pam_smb / Linux DecStation / Linux VAX / ILUG person

Re: advice on dz.c

[Dave Airlie]

This is unusual I've just taken a run down through a diff of 1.17 and 1.22
from the MIPS CVS tree and I can't see anything that could cause breakage
that has been changed... I'd try commentined out the DZ_DEBUG stuff.. this
isn't meant to be called... unless someone wants to specifically debug
their dz.c on a decstation.... otherwise it should be switched off..

Granted to code doesn't look like it would compile with it off..

Dave.

On Fri, 23 Nov 2001, William Lee Irwin III wrote:

> startup() in the 2.4.14 dz.c appears to either not terminate or to
> bring down the kernel on a DecStation 5000/200. The 2.4.5 dz.c when
> put it in its place appears to work properly, modulo some strangeness
> in terminal emulation at runtime.
>
> Unfortunately, attempts to isolate what difference creates the problem
> failed to reveal the true cause of this. The kernel appears to die
> immediately after restore_flags(). This appears unusual to me as the
> changes are largely cosmetic.
>
> I also tried extending the extent of the code over which interrupts
> are disabled, to no avail. After extending it to what apparently was
> the entire extent of the driver's ->open code the kernel died somewhere
> between enabling interrupts again and the printk immediately after
> the return to tty_open(). It did not appear that the driver was
> re-entered at this point, as printk's for the other entry points
> failed to trigger.
>
>
> I am interested in suggestions as to what code changes I should make
> in order to bring this driver into a more robust state so that I myself
> can repair the code for use on one of my own personal machines.
>
>
> Thanks,
> Bill
>

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied@skynet.ie
pam_smb / Linux DecStation / Linux VAX / ILUG person

Re: advice on dz.c

[William Lee Irwin III]

On Sat, Nov 24, 2001 at 11:44:40AM +0000, Dave Airlie wrote:
> This is unusual I've just taken a run down through a diff of 1.17 and 1.22
> from the MIPS CVS tree and I can't see anything that could cause breakage
> that has been changed... I'd try commentined out the DZ_DEBUG stuff.. this
> isn't meant to be called... unless someone wants to specifically debug
> their dz.c on a decstation.... otherwise it should be switched off..
> 
> Granted to code doesn't look like it would compile with it off..
> 
> Dave.

I took a day out to look at it, I can spend more time on debugging it,
as hacking the kernel into shape on this box is somewhat of a hobby
project for me.

I think the one thing I didn't take a look at was the copy_to_user()
changes, so it could be useful to explore that, and I've got a couple
of other tricks up my sleeve.


Cheers,
Bill