In response to my message about the "modprobe floppy" lock-up, you said:
> On Sat, 27 Jul 1996, Bob McCracken wrote:
>>
>>
>> As of kernel 2.0.9 and 2.0.10, "modprobe floppy" never returns, and my system
>> locks solid. The modprobe used is from the modules-2.0.0 package, and it has
>> NO problems with my other modules, which are: 8390, binfmt_aout, dummy, ftape,
>> isofs, loop, lp, minix, ne, nfs, xiafs.
>>
>> I tried the command "insmod -vs floppy.o", but since the disk becomes and
>> remains busy till I hit the reset, I got only this in /var/log/syslog:
>>
>> Jul 27 13:51:44 kerouac insmod: Section 1: (.text) at 0x8053650
>>
>> Because neither .9 nor .10 make any changes to floppy.c, I have to assume
>> that the problem originates elsewhere in the kernel, some change having
>> been made after 2.0.8 that floppy.o doesn't know about.
>>
>> This is pretty mysterious, and I'd mail the current floppy maintainer
>> directly, if I knew who that was.
>>
>> So ... any ideas, anyone?
>>
>> - Bob McCracken kerouac@ssnet.com
>
> Do you have a cmd640 chip? (One of the cmd640's bugs involved the improper
> wiring of the floppy "disk changed" signal to the cmd640.)
> (Just an idea -- the cmd640 code did change a bit .9 and .10 --
As a matter of fact I do have one, and, as always, I compiled .9 and .10
with cmd640.c included.
I was aware that 2.0.9 had interrupt unmasking disabled for cmd640, and that
this is been corrected in 2.0.10 to allow it again, but I didn't know there
was any such signal connection as you describe between the cmd640 chip and
the diskette controller. (I did, however, *somewhat* suspect the hard disk
support, since there'd been no change at all to floppy.c, but I had no idea
of what to look for in that regard.)
While that particular signal may have nothing to do with this problem, your
comment suggests there may be more to the cmd640/floppy interaction than
meets the eye (my eye, anyway); so, I'm going to recompile .10 without
cmd640 support and try again.
Thanks.
- Bob McCracken kerouac@ssnet.com