Hi,

[ ..... ]
> OK,  here are my first results :
> 
> First boot of 'BOOTX.poll' kernel, delivers 
> 
>  - on boot sequence the same behavior on my ZIP, this is
>    wainting about 20 seconds then showing the error-messages
> sd1 at scsibus0 targ 6 lun 0: <IOMEGA, ZIP 100, R.41> SCSI2 0/direct removable
> sd1: sd1(ncrscsi0:6:0): illegal request, 
> 	data = ff fe 01 05 c9 00 00 00 00 00 00 00 00 00 00 00 00
> sd1: could not mode sense (4); using fictitious geometry
> This messages were also shown when I 'disklabel' or 'newfs' the ZIP
This is a 'solved' bug. What I mean is that the bug will be gone right *after*
the 1.2 release. The problem stems from the fact that the drive is asked for
geometry info that it doesn't support. The messages are annoying but do no
harm.
> 
>  - fsck /home (= /dev/sd0f on SCSI disk) brought many 'st_pool_size' mesages
>    on screen takes a long time and then kernel crashed with 'MMU fault'.
> But I think the reason could be an incorrect /home-filesystem.
I have the feeling that the huge amount of messages is somehow the cause of
this panic. If you still get this panic after binpatching the poolsize, let
me know.
> 
> This crash was reproductable with the other kernel BOOTX.intr
> 
> But then reboot with both kernel works ok, also fsck in boot phase of all
> partitions ( / /usr and also /home) works fine.
This sounds promising....

> 
> After this, reading a tar-file from a ZIP-disk in MSDOS format brought ONE
> kernel hung, but after the next reboot I got NO hung or crash either :)
> 
> With kernel BOOTX.poll I then did :
> 	- binpatch'ing _st_pool_size with several values (see my mail before)
> 	- making a new filesystem on ZIP
> 	- writing tar-files of / and /usr on this new ZIP partition 
> 	  and reading that files.
> NO ONE error message appeared and no more kernel crash or hung - up to now
> 
> Tomorrow I continue testing e.g. together with my second harddisk
> and the other kernel (BOOTX.intr). When it will did also fine you recieve
> my congratulations ;-)  but now I must go to bed.
It looks like the problems on the removables are finally under control! I
hope you are also able to run the '.intr' kernel without problems. This
would mean that the Falcon scsi-driver is finally getting an aceptable
quality.
> 
> good night
Same to you! And thanks for testing,

Leo.