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

RE: Working ram disk image for IIsi



Hi,

>>Use the latest kernel (2.0)  from the Mac FTP site in the kernels/testing
>>directory.
>
>OK, let's see if I am missing anything.  In all the rebooting, I am now
>disabling extensions (with shift) as I reboot to save time.
>
>I am getting mixed results.  I am taking the kernel images I downloaded and
>copying them to the boot floppy with Penguin and renaming the file I copy
>to "linux".  First I thought I was having the lights go off while using the
>testing/2.0.33pl-980708 and 2.1.101-980620 kernels while booting from
>floppy.I tried the other two as well.  None of them have allowed me to type
>anything so far.  I then zapped my PRAM just in case.  I reset the 32 bit
>mode in Memory control panel.  I even tried a Power Computing keyboard to
>see if it made a difference, it didn't.

Sorry for causing the confusion here - I've said in a later e-mail that
the 2.0 kernel probably still has the adb_poll race condition ... Just checked
it, and the source here at home still had the race. Forgive me for not fixing
the 2.0 source immediately, but it's only been a week that we finally nailed
this bug, and I've spend most of the time backporting the 53C9x driver to
2.0, testing it ti make sure it works etc. and posting it. Plus fighting
kernel versions 2.0.33pl1 or 2.1.105 on my Falcon (horrible disk timeout rate,
system hangs in disk wait, went back to 2.0.29 to build these packages), and 
a real world job. It's fixed now, and I'll post another kernel as soon as I get
into the lab. 

>The floppy annoyed me, and I didn't see any difference in results when
>compared to copying the whole disk to the internal hard disk as a folder
>and then using it instead of the floppy.  This was necessary for one of the
>images because it was too large for the floppy disk.  I went back and tried
>to boot each of the following kernels and wrote down the results to
>double-check myself.  They each booted in 24 line large font (980507 booted
>in smaller font, which is nice) and they all had identical results on my
>LEDs (all LEDs were on):

They all failed, yes. Well, all of the 2.0.33 kernels worked on a ClassicII 
for me, so I didn't see the immediate need to fix the 2.0 source. The problem
with 980507 (as well as all other 2.0.33pl1 kernels) booting in the smaller font
is fixed as well, you would notice that the smaller font looks nice but has its
drawbacks as soon as you start vi, or do some command line editing. It should be
removed or better fixed, but see my remarks about the Mac project.

The Mac port is to be considered alpha, and as always with Linux: if something
breaks for you, getting the source and fixing it migth be the fastest way to
success.

	Michael


--  
To UNSUBSCRIBE, email to debian-68k-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org




Reply to: