[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

"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

> > 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.


Reply to: