Brad Boyer:
.
.
> That seems odd. Could you send me both kernels (in a private email) so I
> can take a look at them? It's possible one compiler or the other has a
> bug in the code generation. It's been known to happen before.

Done. Also, I compared a bunch of different kernel compiles and interrupt
configurations and made notes below...

> > Also another odd thing, from adb. I was holding down the up arrow key to go
> > through the history under bash and the computer though at some point that I
> > never released the key. I couldn't do anything to get it to stop by
repushing
> > the down key or any other key for that matter.
>
> Do any other ADB events register? If no other keys do anything at all, it's
> possible that the driver lost communication with the bus, and isn't seeing
> anything to end the key repeat. Most likely this would just be a bug in
> the driver.

It seems like the adb gets hung. When it gets stuck, last time was on the "n"
key, no other key makes it change, it keeps hammering out n's. When this
happens, I can still access the machine via the ethernet. When I try a reboot
(which appears to rely upon adb) the machine is unable to restart, it
hangs at the point at which it's supposedly going to do a HW reboot.

Now I tried a bunch of combinations of kernels and devices and made the
following observations:

With the b and c patches mentioned previously installed, if adb is
DISABLED esp and sonic work ok. sg_verify suceeds on the whole disc.

If adb is enabled, sonic works ok but esp gets the selection errors and
fails the sg_verify randomly. ADB itself works with the keyboard but is
very flakey.

With ADB enabled, If the kernel is compiled with gcc2.95 on OSX, there are
about 100 times as many esp select errors than there is if the same kernel
is compiled with gcc 3.3.5 on the performa itself.

If I enable the "alternate irq mapping" by adding the 575 to the
table of supported machines in arch/m68k/mac/via.c I get MUCH better
behavior out of ADB keyboard. It SEEMS like I can't make it fail. Sonic
still works but esp throws many selection errors and fails right
away on sg_verify. The modified alt irq mapping code:

#if 1
/* Some machines support an alternate IRQ mapping that spreads */
/* Ethernet and Sound out to their own autolevel IRQs and moves */
/* VIA1 to level 6. A/UX uses this mapping and we do too. Note */
/* that the IIfx emulates this alternate mapping using the OSS. */

switch(macintosh_config->ident) {
case MAC_MODEL_P575:
via_alt_mapping = 1;
via1[vDirB] |= 0x40;
via1[vBufB] &= ~0x40;
break;
break;
default:
via_alt_mapping = 0;
break;
}

Without the alt_irq_mapping I get this interrupt configuration:
auto 0: 0 spurious int
auto 1: 1460722 via1
auto 2: 56742 via2
auto 3: 0 int3 handler
auto 4: 0 scc
auto 5: 0 int5 handler
auto 6: 0 int6 handler
auto 7: 0 NMI
via1 9: 550450 framebuffer vbl
framebuffer vbl
via1 10: 287 ADB
via1 14: 914166 timer
via2 17: 2852 F nubus
via2 19: 53909 Mac ESP SCSI
nbus 56: 2852 F sonic

With the alt mapping I get:
auto 0: 0 spurious int
auto 1: 0 int1 handler
auto 2: 4872 via2
auto 3: 763 sonic
auto 4: 0 scc
auto 5: 0 int5 handler
auto 6: 16788 via1
auto 7: 0 NMI
via1 9: 6805 framebuffer vbl
framebuffer vbl
via1 10: 282 ADB
via1 14: 10703 timer
via2 17: 0 F nubus
via2 19: 4872 Mac ESP SCSI

With alt mapping and no ADB I get:
auto 0: 0 spurious int
auto 1: 0 int1 handler
auto 2: 8797 via2
auto 3: 1298 sonic
auto 4: 0 scc
auto 5: 0 int5 handler
auto 6: 147840 via1
auto 7: 0 NMI
via1 9: 56321 framebuffer vbl
framebuffer vbl
via1 14: 92894 timer
via2 17: 0 F nubus
via2 19: 8797 Mac ESP SCSI


Hope this gives some clues....

Bob
--
/~\ The ASCII | Robert E. Brose II N0QBJ
\ / Ribbon Campaign | http://www.qbjnet.com/
X Help cure | mailto:bob@...
/ \ HTML Email | public key at http://www.qbjnet.com/key.html
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k