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

Re: Blackhawk problems

On Tue, Nov 02, 1999 at 11:52:17PM -0800, Aaron Burt wrote:
> Well, I got DebPPC on my Blackhawk recently.  However, both the PReP
> kernel supplied with the latest unstable and the one I built from the
> 2.2.13 source deb have a couple problems: 
> Regular "Bogus Interrupt" messages that seem to be triggered by the
> keyboard.

This is a known problem with interrupt handling on PReP.  I'm trying
to get it all sorted out.  I'm actually looking at the interrupt ack cycle
rather than a specific interrupt like keyboard right now.  I've been thinking
that the interrupt is acked and before it is serviced and cleared on the
device, and the device is asserting another interrupt on the 8259 when the
device is already serviced.

It's harmless except that it is wasting a lot of cycles in irq servicing
for nothing (and syslog space).

> Also, have the clfbgen patches for Blackhawk been merged yet?  Should I
> try to deb Xbh?

I'd be happy to see someone deb Xbh...I've thought of doing it.  I did a
little work on the clgenfb driver (Jeff's latest version) so it worked with
the 5446 on PReP boxes (that's what's being shipped on MCG's current 
products).  Unfortunately, I don't have any work time to spend on video
issues since they are low priority, but I'd love to see Jeff/someone get
working clgenfb support into the kernel.  A few months ago it could only
do 8bit depth on PReP whereas Xbh can do 16bit.  I've heard that 2.2.13 
introduced a new clgenfb driver that is updated from a Zorro perspective
such that it breaks Jeff's patches pretty horribly...it's probably time
to get the driver in the kernel so it can be properly maintained.

There is a _small_ problem with FB support in that currently things work
nicely with VGAcon and Sercon built together in the boot image.  If a VGA
console is not detected then the kernel will fall back to serial console
mode.  This is real handy for all the VME/CPCI PReP boards out there still
being made that are mostly going to be installed over serial console.
FB inits things differently such that the when FB support is in the kernel
it doesn't go through the same console initialization routine and have an
opportunity to fall back to serial console.  Ideally this needs to fixed
such that if a fb device is not detected, it will look for standard vga
console, and then fall back to serial automagically.

> Otherwise, I'm mighty impressed.


Matt Porter
This is Linux Country. On a quiet night, you can hear Windows reboot.

Reply to: