Date: Tue, 9 May 1995 21:40:01 -0700 From: uhclem%nemesis@fw.ast.com To: freebsd-bugs Subject: bin/393: Problem #FDIV025 Message-ID: <199505100440.VAA08468@freefall.cdrom.com> In-Reply-To: Your message of Tue, 9 May 95 23:23 CDT <m0s93J0-0004vwC@nemesis.lonestar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>Number: 393
>Category: bin
>Synopsis: Simultaneous cp and ls of files on dos f/s hangs procs [FDIV025]
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-bugs (FreeBSD bugs mailing list)
>State: open
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue May 9 21:40:00 1995
>Originator: Frank Durda IV
>Organization:
>Release: FreeBSD 2.0.950412-SNAP i386
>Environment:
[FDIV025]
FreeBSD 2.0.950412-SNAP i386
Stock kernel, "make world" kernel, or custom kernel.
>Description:
If you are copying files to a freshly-formatted MS-DOS floppy (6.2.2)
and on a second process you do a ls -R of the same floppy, sometimes
the ls process will hang, and then the cp process may also hang.
Other types of filesystem reads will substitute for ls and probably
other programs can be used to put files on the floppy.
>How-To-Repeat:
To easily repeat the problem:
Take a freshly formatted MS-DOS floppy and mount it as /mnt:
mount -t msdos /dev/fd0a /mnt
cd /
mkdir test2
cd test2
create 26 files named a thru z of non-zero length.
I used date > a
thru date > z
(the script to automate this is left to the observer)
mkdir z1
mkdir z2
mkdir z3
cp * z1/.
cp * z2/.
cp * z3/.
sync
You should have 104 files and three directories in the test2 tree..
At this point, I suggest making a tar image of test2 so you can restore
it if you lose it in the next steps.
Make sure you are logged-in on at least three virtual terminals
cd to /test2 on all virtual terminals
On screen 1, issue the command:
cp -R * /mnt/.
On screen 2, issue the command
ls -R /mnt
continue to repeat (!!) the ls command, waiting for the prompt each time.
Eventually the ls command will not terminate.
At this point you may hear floppy I/O continue for another 15
seconds or so, and then the drive light will go off. Switch to screen 1
and verify that the cp command is hung.
If the cp command finished normally and ls didn't hang up,
rm -rf /mnt/. and repeat the above commands. For me it always hung
during the first cp command.
On the third screen, you can do a ps -alxw and should see results like this
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
0 0 0 0 -18 0 0 0 sched DLs ?? 0:00.00 (swapper)
0 1 0 2 10 0 412 176 wait Is ?? 0:00.05 /sbin/init --
0 2 0 0 -18 0 0 12 psleep DL ?? 0:00.00 (pagedaemon)
0 3 0 0 28 0 0 12 psleep DL ?? 0:00.00 (vmdaemon)
0 4 0 0 -6 0 0 12 update DL ?? 0:00.12 (update)
0 19 1 23 18 0 212 88 pause Is ?? 0:00.02 adjkerntz -i
0 41 1 0 2 0 180 228 select Is ?? 0:00.03 routed -q
0 57 1 0 2 0 180 296 select Ss ?? 0:00.43 syslogd
1 63 1 75 2 0 176 220 select Is ?? 0:00.02 portmap
0 72 1 18 2 0 208 312 select Is ?? 0:00.84 inetd
0 79 1 0 18 0 264 332 pause Is ?? 0:00.09 cron
0 81 1 25 2 0 184 284 select Is ?? 0:00.13 lpd
0 84 1 22 2 0 404 328 netcon Is ?? 0:00.04
sendmail: accepting connections (sendmail)
0 124 1 0 3 0 476 276 ttyin Ss+ v0 0:01.08 -csh (csh)
0 192 124 0 -6 0 252 132 getblk D v0 0:00.30
cp -R a b c d e f g h i j k l m n o p q r s t u v w x y z z1 z2 z
0 125 1 0 18 0 472 336 pause Is v1 0:00.59 -csh (csh)
0 212 125 0 -14 0 352 196 msdhgt D+ v1 0:00.07
ls -g -k -R /mnt
0 126 1 0 18 0 472 332 pause Ss v2 0:00.40 -csh (csh)
0 216 126 6 29 0 440 180 - R+ v2 0:00.04 ps -alxw
(The wait channel of the ls and cp is always the same as above.)
At this point, you can't kill the above processes, but you might be able
to do selected operations on the same floppy file system. In one case I was
able to do a ls /mnt and got results and a prompt, but then I attempted a
ls -alR and that hung up. Another time I was able to rm -rf /mnt/*
all the files on the floppy without incident even though the other
processes were still hung.
>Fix:
No idea. However, the order of directories copied seems important.
When I used subdirectories named "one", "two" and "three" I could not
get a failure. Another interesting thing is the order in which
the repeated ls commands show files being copied, almost a reverse
alphabetic order.
*END*
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505100440.VAA08468>