From owner-freebsd-bugs Tue May 9 21:40:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA08476 for bugs-outgoing; Tue, 9 May 1995 21:40:02 -0700 Received: (from gnats@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA08468 ; Tue, 9 May 1995 21:40:01 -0700 Date: Tue, 9 May 1995 21:40:01 -0700 Message-Id: <199505100440.VAA08468@freefall.cdrom.com> From: uhclem%nemesis@fw.ast.com Reply-To: uhclem%nemesis@fw.ast.com To: freebsd-bugs Subject: bin/393: Problem #FDIV025 In-Reply-To: Your message of Tue, 9 May 95 23:23 CDT Sender: bugs-owner@FreeBSD.org Precedence: bulk >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: