Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!usc!hacgate!gryphon!cadovax!tzung From: tzung@cadovax.UUCP (Tzung Liu) Newsgroups: comp.unix.i386 Subject: RDUBLK bug in INTERACTIVE 386/ix (AT&T V.32) on 386 PC/AT. Message-ID: <2455@cadovax.UUCP> Date: 24 Oct 89 21:00:38 GMT Reply-To: tzung@cadovax.UUCP () Organization: VERSYSS Corporation, Torrance, CA Lines: 47 We have found a generic bug in INTERACTIVE 386/ix(AT&T V.32) for 386 PC/AT. The RDUBLK sysi86() system call, i.e. ReaD User BLocK, will fail if the user block requested is not in core but in swap device. This affect the "ps" and "crash" commands such that: 1. the "ps -aef" command will NOT show a process if it's swapped out at the time the "ps" command is running. 2. the "crash" command will show misleading information, especially in the "COMMAND" field if a process is swapped out. This bug doesn't exist in V.31 because the V.31 "ps" and "crash" commands do not use sysi86(RDUBLK, ...) to read a user blocks if a process is not in core. (Note: RDUBLK is a new member of sysi86() system call). The problem is that the RDUBLK routine in kernel calls the SWAP device read entry point(the raw i/o entry point) directly, if the requested user block is not in core, while passing the original byte count requested from user to the device driver. Both the "ps" and "crash" request sizeof(u) bytes, where u is the user block structure, which is NOT a multiple of the sector size. The SWAP raw i/o routines will reject any request if the byte count is not multiple of the sector size, 512 for 386 AT. Thus the sysi86(RDUBLK, ...) system call will fail and return -1. To recreate the problem: run a couple of big programs, or run multiple copies of the following program until your see the LED on your SWAP disk is ON most of the time. #define MAX 1024*2048 /* 2 MB */ char buffer[MAX] main() { int i; for (;;) for (i=0; i