> block device that matters). I can't reproduce the problem with my
> 2.0.18 setup here and, indeed, tracing the vfsmntlist linked list
> shows everything OK (zero mnt_quotas[] entries and dq_op = 0 in the
> superblock). If you can get your system to a situation where you
> know that a "umount /proc" would cause the oops, could you make a
> copy of /proc/kcore at that point (without actually doing the umount),
> upload it and the relevant System.map (and maybe the non-compresses
> vmlinux image if possible) via anon ftp to /incoming on sable (or put
> it in /var/tmp somewhere if easier) and let me know? I'll take a look
> at it. One of the crashes was the
I have the problem 100% reproducible under 2.0.23. The sequence is a most
bizarre one.
1) umount /proc
I am told "/proc is busy" (!)
2) umount /mnt/dosd
This is a standard msdos FS, and the umount goes fine.
3) Try umount /proc again.
OOPS occurs. I'll try and dig it out of my sent-mail.
These 3 steps are 100% repeatable.
My setup is 2.0.23, possibly with pentium memcpy, kerneld to load many
modules, _quotas compiled in but not in use_ <---- seems to be common to
the OOPSES, and I think I have mandatory lock support. My oops used to
occur in locks_remove_locks I believe.
Unfortunately, when I get my system into a state when I _know_ it will
oops upon umount /proc, doing "cp /proc/kcore ." messes things up, and
the umount reports "/proc: device is busy" again. :-( And I even booted
with mem=4M to get the kcore.gz to fit on a single floppy... :)
Chris.