src/sys/dev/vinum, branch releng/4.3

open_drive: Recognize drives located on Mylex RAID controllers.

2001-04-16T05:29:54+00:00

Reported by:	Matt Groener 
Approved by:	jkh

struct drive:

2001-04-08T02:18:14+00:00

  Workaround size mismatch in struct drive on alpha platform only.
  This struct is shared between kernel and userland and contains a
  dev_t, which now refers to a completely different structure in
  userland and kernel: int the kernel, userland dev_t is called
  udev_t, and dev_t is struct specinfo *.  In practical terms, kernel
  dev_t is a pointer and userland dev_t is an int, which on the alpha
  are different sizes.

  As stated, this is a workaround.  The correct fix would be in two
  parts:

  1.  Don't define structures in the kernel with the same name and a
      different content as a userland structure.  This is a
      kernel-wide issue: kernel dev_t needs another name.

  2.  Don't export unnecessary kernel structures to userland.  This
      can be done within Vinum.  It is currently on the tuit queue.

Sleuth work by:      Normand Leclerc 
Tested by:	     Normand Leclerc 
Blanket approved by: jkh

vinumlock: Catch a potential race condition where one process is

2001-04-04T06:27:11+00:00

	   waiting for a lock, and between the time it is woken and
	   it retries the lock, another process gets it and places it
	   in the first entry in the table.

	   This problem has not been observed, but it's possible, and
	   it's easy enough to fix.

Submitted by:	tegge

vinumunlock: Catch a real bug capable of hanging a system.  When
             releasing a lock, vinumunlock() called wakeup_one.  This
             caused wakeups to sometimes get lost.  After due
             consideration, we think that this is due to the fact that
             you can't guarantee that some other process is also
             waiting on the same address.  This makes wakeup_one a
             very dangerous function to use.

These changes have not yet been committed to -CURRENT.  In view of the
seriousness of the second one and the imminent 4.3-RELEASE, it seems
excusable to commit to -STABLE first.

36 hour test by:  grog
Suggested by:     alfred
Suffered by:      Andrew Gordon 
Approved by:      jkh

MFC: Allocate lock table for striped plexes as well as parity plexes.

2001-03-30T05:41:39+00:00

This was forgotten in the last slew of MFCs, and caused an immediate
panic when starting a striped plex.

Suffered by:	"John J. Rushford Jr" 
Approved by:	jkh

Catch up with -CURRENT. I've left it very late to MFC a number of

2001-03-13T03:04:06+00:00

problems which are fixed in -CURRENT.  Now's still not a good time to
do it, so I'd be grateful if people would hammer on this stuff.

Approved by:   jkh
Pointy hat to: grog

MFC: don't cross stripe boundaries when reviving.

2000-11-19T19:46:40+00:00

Approved by: jkh

MFC: Bring in sync with -CURRENT. Significant changes include:

2000-06-08T02:00:23+00:00

- Add dumpconfig command.
- Fix data corruption problems in RAID-4 and RAID-5 revive.

MFC. This appears to have been omitted by accident in an earlier

2000-06-02T04:26:11+00:00

commitfest.

expand_table: Avoid a race condition which may have been contributing
to the random corruption, panics and hangs we've been seeing in RAID-5
plexes, particularly with ata drives.

MFC: parityrebuild: write the parity block back to the correct

2000-06-02T04:20:35+00:00

subdisk.

HEADS UP: This fixes a serious data corruption bug when using the
userland command 'rebuildparity'.

MFC: Don't forget 'stripe' and 'mirror' commands when we turn off

2000-05-20T03:23:49+00:00

debugging.

Submitted-by: mdodd