Re: Mac Install Problems
Hi,
>> Can't believe that; HFS hasn't changed in ages (at least not in the last month
>> or so). What probably happened is that you selected one of the
>> <path to Debian archive>/.finderinfo/base2_0.tgz 'junk' files (HFS metadata)
>
>I tried and tried the debian install--trying the directory itself as well as
>the .finderinfo and .resource subdirectories--but I couldn't get past the
>"unexpected end of file" error that I mentioned. Finally, I went to the
>console window, mounted the HFS filesystem manually, and eventually realized
>that every file had size zero (and zcat bas2_0.tgz gave nothing). I
Ok, that looks more like a real HFS problem. I'm not sure when the last HFS
upgrade was (or if there's been any HFS upgrade at all, in 2.0.29) but
if ls shows zero file size of the real file (not .finderinfo or .resource
or such) you found a mysterious kernel bug.
>switched to the kernel on the rescue disk, and everything worked fine. I
>pulled the vmlinux-2.0.33pl1-980518.gz kernel off of maclinux.wwaves.com
>last night and everything works fine with that image as well.
That's the kernel to use, anyway. 2.0.29 has long been obsolete except on Mac.
>> Bad news for you. The driver couldn't find the Nubus ROM on the ethernet card
>> and gave up. You'll have to get the kernel source and start poking around in
>> the driver to fix this...
>
>In what file do I look and what am I looking for?
drivers/net/daynaport.c is the Nubus specific part of the driver. Try changing
the location the driver looks for ROM, or the size of ROM it scans. Maybe the
rewind of 32k wasn't enough?
Add more debug output to daynaport.c in the detection part, first thing is to
locate the ROM and parse the board resource (see drivers/nubus/nubus.c
for details). The board needs to be recognized as ethernet type, and it's got
a name and driver hardware and software IDs (DrHw, DrSw). The station address
is also hidden in the board resource.
There's a function to test for read or write access (nasty assembler) you can
use to scan the board address space for read-only space (ROM), read/write space
that holds the data (RAM) and read/write space that changes data (chip
registers). The RAM and chip detect has been figured out, the ROM detect seems
to be your problem. You might try to hardcode DrHw, DrSw and station address
and proceed to chip detect and RAM detect on not finding the ROM, just to see
if there's anything present on the board.
The driver makes a best guess based on DrHw and DrSw what register scaling to
use (word and longword access to Nubus might be spread over multiple bytes,
with empty space in between. But the ROM detection should have figured out the
proper byte lanes already).
That was a pretty boring description for the rest of debian-68k, we'd should
take followups to linux-mac68k I guess.
Michael
--
To UNSUBSCRIBE, email to debian-68k-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: