Re: Re: Atari machines running Debian?
> > CVS 2.6.17 seems borked right now (lotsa nonexisting files messing up
> > make clean etc.). I'll keep poking around in 2.6.13.
>
> It would be far better to get 2.6.17 working, you'll will only have more
> problems later trying to forward port them, especially since the
> interrupt system drastically changed.
Well, duh. I was having trouble with my latest 2.6.13 giving no output in
the emulator at all, in what apparently was a bad interrupt storm. An
earlier snapshot still sort of worked, that's what I wanted to poke around
for.
"unexpected interrupt from 276" is what I get with 2.6.17 mainly. A few
"unexpected interrupt from 112" show up before that. With scheduling in
the TT hwclock code, the kernel dies quite early; replacing the timeout
there with a busy wait gets it to loop forever. With FastRAM > 0, the
kernel dies earlier while setting up memory (we definitely need discontig
memory).
> > I still don't understand the reason.
> >
> > "atari_slow_irq_" #n "_handler:\t" \
> > " addl %6,%5\n" /* preempt_count() += HARDIRQ_OFFSET */ \
> > SAVE_ALL_INT "\n" \
> > GET_CURRENT(%%d0) "\n" \
> >
> > (%5: "m" (preempt_count()), %6: "di" (HARDIRQ_OFFSET))
> >
> > is what fails to work,
>
> "m" is not really a good constraint to use here, it may generate extra
> code in front of the assembly construct and thus in front of the handler.
I notice all of this is disabled in 2.6.17. I don't seem to get any
autovector interrupts to come in, it all goes to bad_interrupt.
hardirq_count() (called from bad_interrupt) returns either 65536 or
131072, is that normal behavior?
> > With Geert's clarification I'll give it a fresh try. I'm still unsure how
> > to acquire a working screen buffer with ST-RAM swap disabled, but that'll
> > eventually work out.
>
> You could use something like arch/m68k/amiga/chipram.c to manage this
> memory area.
I had looked at that, but it didn't seem to fit for some reason. Anyway,
it's the interrupt code that needs fixing first of all.
Michael
Reply to: