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

Re: Atari TT


> >If the other kernel (nonet) shows a proper boot screen, that's a kernel size
> >issue. 
> They have very few difference, though.

Just saying. The floppy blink is the only way to tell the kernel is still
running in the absence of screen output (and I've even had cases where the
kernel stopped progressing with floppy blinking i.e. interrupts enabled). 
> >That does not include my more recent patches to the interrupt code. I
> >suspect you may be using the atari_ethernec driver instead of the generic ne
> >one as well. I'll check your kernel image to see what it does use. 
> I’m using Geert’s m68k-queue branch plus Alan’s patch.
> Is that not correct?

I don't know - I've never checked out that branch. Time to check what's
actually in there. 
> And yes, of course I selected the EtherNAT and EtherNEC drivers.

Some of my commits last year changed the semantics of the config options to
select the new, generic drivers instead of my old hacked copies. Depending
on the state of Geert's tree, it may be either of the options. 

Looking at the git web interface for m68k-queue, the current state still is
to use the old atari_ethernec (hacked copy of ancient ne.c driver). So the 
error you will be getting is precisely what I've been seeing while using that
version - kernel locks up on the first timer-faked interrupt in. 

The new driver may or may not fare better in that regard; I'll test that
ASAP. If it does the same thing, fixing this will be _much_ harder because I
cannot touch any code in ne.c. 

The whole point may be sort of moot anyway - has anyone managed to boot a TT
sucessfully all the way, with console screen output,  to the point where it 
fails to mount a root filesystem with your nonet kernel? That may require
use of the -s bootstrap flag, as I've said before. If that works out, we'll
also have console output at the time the network driver is loaded. That
would allow some kind of debugging (at one or two removed). Without any kind
of debug output from the kernel (aside from colorful pixels), that's a bit



Reply to: