RDUBLK bug in INTERACTIVE 386/ix (AT&T V.32) on 386 PC/AT.

[Tzung Liu]

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<MAX; buffer[i++] = 0xff)
			;
	}

Then use the "ps" and "crash" command to see the processes in the system.
You will notice that "ps" will report less processes than it should be.

There is no easy way to get around the problem unless your can modify
the kernel source or the source codes of "ps" and "crash".

May be INTERACTIVE will come up with a bug fix later.

Tzung Liu.