Subject: kernel debugging advances
To: netbsd-macppc <port-macppc@NetBSD.ORG>
From: Riccardo Mottola <rollei@tiscalinet.it>
List: port-macppc
Date: 12/13/2004 11:11:05
Hello,

I like to see how many problems are tackled now on the kernel and
support for MP may indeed uncover and fix many interrupt related bugs.
It is too a pity that 2.0 was already released.
I want however to get the attention back on my own issues. Apart from
the porblems of my 4400 and the 8200... I would stick to blockers. I'd
also like to organize testing and debugging a bit more, just having a
dozen of different kernels on my HD from three different people and
using the mail inbox as "test queue" is not  productive. It worked when
I tested one or 2 kernels but it doesn't scale

- the kernel is quite seriously broken on my 9500.
It hangs at boot and continues only when keyboard is coninuously
stimulated.

current CVS code (well... 3 days ago) shows interrupt problems with the
kernel hanging at boot. Some small patch suggestions by Michael did not
help. Further more I somehow stupidly lost his older locore_subr.S
version in a maze of thousands of emails.

I propose the following (until things have staibilized more):

- I will track CVS with as little modifications as possible and so test
that everything is still fine
- I ask Michael to build a kernel for me in a condition that he thinks
it will work (od versions vefore Matt's modifications, new patches..
etc) and I will test that
- I can do the same thing for others

once the kernel is booting again.. the mc ethernet work needs still to
be verified here!

And are what do you gus thing int he SCSI number assignment order?
checking the internal bus first and assigning sd0 to it first instead of
the external one... If you have an external disk or zip-drive that is
not alwasy connected everything gets screwed up! I find that stupid. Are
there particular reasons for the current setup?

The other blocker is on the 9600 for which I prepared an external drive.
The same drive gets recognized on the external bus on my 9500 but then
screws up all scsi ID's and so prevents booting. The drives gets not
recognized on the 9600. So as soon the kernel starts booting again,
tackling the 9600 issue would be good also because it would open another
test platform: the 9600 had an unusable mc0 too for example, it has a
different videocard and a slightly newer motherboard (I have a Kansas
with a 604ev proc). I suppose also that I should get a backside cache
recognition on it, since it has 1MB backside cache instead of 512k on
board.

Have a nice day,

   Riccardo