I dropped the latest version of my Digiboard serial port driver into a
1.3.25 kernel over the weekend. I've had it working with 1.2.4 for some
time now. Anyway, trying to merge the Digi driver with the 1.3.25 kernel
caused it to hang the machine on initialization of the driver code (right
after the serial port initialization -- and the machine doesn't even bother
to panic()). Here's the relevant code:
pcxe_init( kmem_start )
{
.. local vars ..
.. struct inits..
save_flags(flags);
cli();
.. download BIOS/FEP to board ..
restore_flags(flags);
return(kmem_start);
}
I've traced the problem to the restore_flags() call at the end of the function.
Specifically, trying to set the interrupt flag again just before returning
kmem_start causes the machine to die. I've verified this:
1) flags, &flags are consistent between calls. That is, the init function
reportedly restores the same flags that it saves.
2) An assembly check reveals that the same flags _are_ supposed to be
restored after they are saved (typical flags value is 0x202).
3) The code does die right when the flags are restored (or, equivalently,
if a sti() instruction is put in the place of restore_flags()). It
dies on the popfl or the sti instruction, not afterwards.
4) A disassembly of pcxe_init reveals that the assembly code is ok -- that
is, the stack isn't corrupted, kmem_start is being returned untouched
(the driver doesn't need any kmem ;).
The developer at Digi & I agree that it's due to another kernel change.
Has anything changed in the way driver initialization occurs to cause
this kind of behavior?
-- Bob Glamm | Email: glamm@mountains.ee.umn.edu 209 5th St. SE #207 | URL: http://www.cs.umn.edu/users/glamm/ Minneapolis, MN 55414 | EE grad, U of Minnesota - Twin Cities (612)623-9437/(612)625-7876