BUG at scsi_lib.c:1108 [Was: mmotm 2009-11-24-16-47 uploaded]

BUG at scsi_lib.c:1108 [Was: mmotm 2009-11-24-16-47 uploaded]

[Jiri Slaby]

On 11/25/2009 01:47 AM, akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2009-11-24-16-47 has been uploaded to

Hi, I'm hitting the BUG below in the past two -mmotm's
(2009-11-24-16-47, 2009-11-17-14-03):

kernel BUG at /home/l/latest/xxx/drivers/scsi/scsi_lib.c:1108!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/kernel/uevent_seqnum
CPU 1
Modules linked in: ath5k ath
Pid: 10, comm: events/1 Not tainted 2.6.32-rc8-mm1_64 #905 To Be Filled
By O.E.M.
RIP: 0010:[<ffffffff81291cda>]  [<ffffffff81291cda>]
scsi_setup_fs_cmnd+0x8a/0xa0
RSP: 0018:ffff8801cb88db20  EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801c472b800 RCX: ffff8801c403a000
RDX: 0000000001082421 RSI: ffff8801c3d01000 RDI: ffff8801c472b800
RBP: ffff8801cb88db30 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8801c53e68a0 R11: 0000000000000000 R12: ffff8801c3d01000
R13: ffff8801c472b800 R14: 0000000000000000 R15: ffff8801c472b848
FS:  0000000000000000(0000) GS:ffff880028280000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00007f401b0065c0 CR3: 00000001c3e03000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process events/1 (pid: 10, threadinfo ffff8801cb88c000, task
ffff8801cb864140)
Stack:
 ffff8801c3d01000 ffff8801c53e68a0 ffff8801cb88dba0 ffffffff81299550
<0> ffff8801cb88db90 ffffffff81193a2a ffff8801cb88dba0 ffff8801c403a000
<0> 0000000000000000 ffff8801c4038b60 ffff8801c3d01000 ffff8801c3d01000
Call Trace:
 [<ffffffff81299550>] sd_prep_fn+0x80/0x800
 [<ffffffff81193a2a>] ? cfq_remove_request+0x14a/0x1d0
 [<ffffffff81189b7a>] blk_peek_request+0xca/0x1a0
 [<ffffffff81291206>] scsi_request_fn+0x56/0x3e0
 [<ffffffff8118934b>] __blk_run_queue+0x6b/0x140
 [<ffffffff81186fb4>] elv_insert+0x144/0x1a0
 [<ffffffff81187072>] __elv_add_request+0x62/0xc0
 [<ffffffff8118a479>] __make_request+0x129/0x3f0
 [<ffffffff81188fcf>] generic_make_request+0x19f/0x360
 [<ffffffff81188fcf>] ? generic_make_request+0x19f/0x360
 [<ffffffff811891f8>] submit_bio+0x68/0xe0
 [<ffffffff81328fe4>] md_submit_barrier+0xe4/0x170
 [<ffffffff81328f00>] ? md_submit_barrier+0x0/0x170
 [<ffffffff8104c81c>] worker_thread+0x12c/0x200
 [<ffffffff81050f60>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff8104c6f0>] ? worker_thread+0x0/0x200
 [<ffffffff81050c8e>] kthread+0x8e/0xa0
 [<ffffffff81003cfa>] child_rip+0xa/0x20
 [<ffffffff81050c00>] ? kthread+0x0/0xa0
 [<ffffffff81003cf0>] ? child_rip+0x0/0x20
Code: 41 5c c9 c3 48 8b 00 48 85 c0 74 b7 48 8b 40 48 48 85 c0 74 ae 4c
89 e6 48 89 df ff d0 85 c0 74 a2 eb dc b0 02 0f 1f 40 00 eb d4 <0f> 0b
0f 1f 40 00 eb fa 66 66 66 66 66 2e 0f 1f 84 00 00 00 00
RIP  [<ffffffff81291cda>] scsi_setup_fs_cmnd+0x8a/0xa0
 RSP <ffff8801cb88db20>
---[ end trace 64ebbf58ad5b90ce ]---





I have raids 0 and 1, ext3 on the former, LVM+ext3 on the latter. It is
100% reproducible, each time while booting. But even after some services
start (opensuse 11.2). Plain singlemode doesn't trigger it. I didn't
investigate that further though.

regards,
-- 
js
Faculty of Informatics, Masaryk University
Suse Labs, Novell

Re: BUG at scsi_lib.c:1108 [Was: mmotm 2009-11-24-16-47 uploaded]

[James Bottomley]

On Wed, 2009-11-25 at 16:12 +0100, Jiri Slaby wrote:
> On 11/25/2009 01:47 AM, akpm@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2009-11-24-16-47 has been uploaded to
> 
> Hi, I'm hitting the BUG below in the past two -mmotm's
> (2009-11-24-16-47, 2009-11-17-14-03):

So this looks like some type of bug in the barrier code. What the BUG_ON
is saying is that something sent us a REQ_TYPE_FS (which should be a
filesystem read or write) with no attached data, so we can't process it.

I've cc'd Jens to see what he thinks.

Could you bisect this to find the offending commit?

Thanks,

James


> kernel BUG at /home/l/latest/xxx/drivers/scsi/scsi_lib.c:1108!
> invalid opcode: 0000 [#1] SMP
> last sysfs file: /sys/kernel/uevent_seqnum
> CPU 1
> Modules linked in: ath5k ath
> Pid: 10, comm: events/1 Not tainted 2.6.32-rc8-mm1_64 #905 To Be Filled
> By O.E.M.
> RIP: 0010:[<ffffffff81291cda>]  [<ffffffff81291cda>]
> scsi_setup_fs_cmnd+0x8a/0xa0
> RSP: 0018:ffff8801cb88db20  EFLAGS: 00010046
> RAX: 0000000000000000 RBX: ffff8801c472b800 RCX: ffff8801c403a000
> RDX: 0000000001082421 RSI: ffff8801c3d01000 RDI: ffff8801c472b800
> RBP: ffff8801cb88db30 R08: 0000000000000000 R09: 0000000000000000
> R10: ffff8801c53e68a0 R11: 0000000000000000 R12: ffff8801c3d01000
> R13: ffff8801c472b800 R14: 0000000000000000 R15: ffff8801c472b848
> FS:  0000000000000000(0000) GS:ffff880028280000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 00007f401b0065c0 CR3: 00000001c3e03000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process events/1 (pid: 10, threadinfo ffff8801cb88c000, task
> ffff8801cb864140)
> Stack:
>  ffff8801c3d01000 ffff8801c53e68a0 ffff8801cb88dba0 ffffffff81299550
> <0> ffff8801cb88db90 ffffffff81193a2a ffff8801cb88dba0 ffff8801c403a000
> <0> 0000000000000000 ffff8801c4038b60 ffff8801c3d01000 ffff8801c3d01000
> Call Trace:
>  [<ffffffff81299550>] sd_prep_fn+0x80/0x800
>  [<ffffffff81193a2a>] ? cfq_remove_request+0x14a/0x1d0
>  [<ffffffff81189b7a>] blk_peek_request+0xca/0x1a0
>  [<ffffffff81291206>] scsi_request_fn+0x56/0x3e0
>  [<ffffffff8118934b>] __blk_run_queue+0x6b/0x140
>  [<ffffffff81186fb4>] elv_insert+0x144/0x1a0
>  [<ffffffff81187072>] __elv_add_request+0x62/0xc0
>  [<ffffffff8118a479>] __make_request+0x129/0x3f0
>  [<ffffffff81188fcf>] generic_make_request+0x19f/0x360
>  [<ffffffff81188fcf>] ? generic_make_request+0x19f/0x360
>  [<ffffffff811891f8>] submit_bio+0x68/0xe0
>  [<ffffffff81328fe4>] md_submit_barrier+0xe4/0x170
>  [<ffffffff81328f00>] ? md_submit_barrier+0x0/0x170
>  [<ffffffff8104c81c>] worker_thread+0x12c/0x200
>  [<ffffffff81050f60>] ? autoremove_wake_function+0x0/0x40
>  [<ffffffff8104c6f0>] ? worker_thread+0x0/0x200
>  [<ffffffff81050c8e>] kthread+0x8e/0xa0
>  [<ffffffff81003cfa>] child_rip+0xa/0x20
>  [<ffffffff81050c00>] ? kthread+0x0/0xa0
>  [<ffffffff81003cf0>] ? child_rip+0x0/0x20
> Code: 41 5c c9 c3 48 8b 00 48 85 c0 74 b7 48 8b 40 48 48 85 c0 74 ae 4c
> 89 e6 48 89 df ff d0 85 c0 74 a2 eb dc b0 02 0f 1f 40 00 eb d4 <0f> 0b
> 0f 1f 40 00 eb fa 66 66 66 66 66 2e 0f 1f 84 00 00 00 00
> RIP  [<ffffffff81291cda>] scsi_setup_fs_cmnd+0x8a/0xa0
>  RSP <ffff8801cb88db20>
> ---[ end trace 64ebbf58ad5b90ce ]---
> 
> 
> 
> 
> 
> I have raids 0 and 1, ext3 on the former, LVM+ext3 on the latter. It is
> 100% reproducible, each time while booting. But even after some services
> start (opensuse 11.2). Plain singlemode doesn't trigger it. I didn't
> investigate that further though.
> 
> regards,

Re: BUG at scsi_lib.c:1108 [Was: mmotm 2009-11-24-16-47 uploaded]

[Jiri Slaby]

On 11/25/2009 04:19 PM, James Bottomley wrote:
> On Wed, 2009-11-25 at 16:12 +0100, Jiri Slaby wrote:
>> On 11/25/2009 01:47 AM, akpm@linux-foundation.org wrote:
>>> The mm-of-the-moment snapshot 2009-11-24-16-47 has been uploaded to
>>
>> Hi, I'm hitting the BUG below in the past two -mmotm's
>> (2009-11-24-16-47, 2009-11-17-14-03):
> 
> So this looks like some type of bug in the barrier code. What the BUG_ON
> is saying is that something sent us a REQ_TYPE_FS (which should be a
> filesystem read or write) with no attached data, so we can't process it.
> 
> I've cc'd Jens to see what he thinks.
> 
> Could you bisect this to find the offending commit?

Hmm. I bisected it twice to
commit 1bebedd653e1bb0440ebf40724c55791c21ad7cc
Merge: a8d5ddf 62fa36a
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Wed Nov 25 17:42:47 2009 +1100

    Merge remote branch 'md/for-next'


It doesn't make sense at all. How can empty merge cause a regression?
And md/for-next doesn't produce the BUG.

After the 1st bisection I did
 git checkout 1bebedd653e1bb0440ebf40724c55791c21ad7cc
and built it. It crashed. Then I did
 git bisect start 1bebedd origin/stable
where origin is next. And got back to the 1bebedd by bisection.

-- 
js
Faculty of Informatics, Masaryk University
Suse Labs, Novell

Re: BUG at scsi_lib.c:1108 [Was: mmotm 2009-11-24-16-47 uploaded]

[Neil Brown]

On Wed, 25 Nov 2009 21:22:57 +0100
Jiri Slaby <jirislaby@gmail.com> wrote:

> It doesn't make sense at all. How can empty merge cause a regression?
> And md/for-next doesn't produce the BUG.

I've hit that situation before.  Two separate changes in separate
branches conspire to cause a problem.

md/for-next contains code to handle barriers properly for all levels,
not just RAID1.
It is possible I got this wrong in some way, and some new sanity check
in a separate branch is firing, or it is possible some other bug in
barrier handling has been added and now that MD sends barriers, it is
being triggered.

What I did to find the actual offending patches is to got to one of the
heads just before the merge, and cherry-pick all the patches from the
other branch, and then bisect that.

NeilBrown

Re: BUG at scsi_lib.c:1108 [Was: mmotm 2009-11-24-16-47 uploaded]

[Boaz Harrosh]

On 11/25/2009 11:13 PM, Neil Brown wrote:
> On Wed, 25 Nov 2009 21:22:57 +0100
> Jiri Slaby <jirislaby@gmail.com> wrote:
> 
>> It doesn't make sense at all. How can empty merge cause a regression?
>> And md/for-next doesn't produce the BUG.
> 
> I've hit that situation before.  Two separate changes in separate
> branches conspire to cause a problem.
> 
> md/for-next contains code to handle barriers properly for all levels,
> not just RAID1.
> It is possible I got this wrong in some way, and some new sanity check
> in a separate branch is firing, or it is possible some other bug in
> barrier handling has been added and now that MD sends barriers, it is
> being triggered.
> 
> What I did to find the actual offending patches is to got to one of the
> heads just before the merge, and cherry-pick all the patches from the
> other branch, and then bisect that.
> 

cherry-pick is hard work.
Stand on the merge point and do:
git rebase -i HEAD^

That will cherry-pick all these for you in one easy command ;-)

Boaz
> NeilBrown
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BUG at scsi_lib.c:1108 [Was: mmotm 2009-11-24-16-47 uploaded]

[Neil Brown]

On Thu, 26 Nov 2009 08:13:59 +1100
Neil Brown <neilb@suse.de> wrote:

> On Wed, 25 Nov 2009 21:22:57 +0100
> Jiri Slaby <jirislaby@gmail.com> wrote:
> 
> > It doesn't make sense at all. How can empty merge cause a regression?
> > And md/for-next doesn't produce the BUG.
> 
> I've hit that situation before.  Two separate changes in separate
> branches conspire to cause a problem.
> 
> md/for-next contains code to handle barriers properly for all levels,
> not just RAID1.
> It is possible I got this wrong in some way, and some new sanity check
> in a separate branch is firing, or it is possible some other bug in
> barrier handling has been added and now that MD sends barriers, it is
> being triggered.

And it looks like I did get it wrong in some way.
I handled a barrier by:
   - send an empty barrier to each component
   - schedule to write with the barrier flag cleared
   - send another empty barrier

If an empty barrier is received, step 2 sends an empty non-barrier,
which caused the BUG.
I have revised the code to special case empty barriers and only perform
the first step.
This should appear in the next -next.

Thanks,
NeilBrown

Re: BUG at scsi_lib.c:1108 [Was: mmotm 2009-11-24-16-47 uploaded]

[Jiri Slaby]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

On 11/27/2009 05:17 AM, Neil Brown wrote:
> If an empty barrier is received, step 2 sends an empty non-barrier,
> which caused the BUG.
> I have revised the code to special case empty barriers and only perform
> the first step.
> This should appear in the next -next.

Yup, it works (with the patch attached). Thanks.

-- 
js

[-- Attachment #2: 0001-raid-fixup.patch --]
[-- Type: text/x-patch, Size: 6471 bytes --]

>From d2ab5e2d06602b79b4c06208fd1ee492a32c983f Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@novell.com>
Date: Fri, 27 Nov 2009 11:08:28 +0100
Subject: [PATCH] raid fixup

---
 drivers/md/md.c    |   56 ++++++++++++++++++++++++++++++++++++++++-----------
 drivers/md/raid5.c |    3 ++
 fs/compat_ioctl.c  |   22 --------------------
 3 files changed, 47 insertions(+), 34 deletions(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 89a1350..d6f7f6c 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -44,6 +44,7 @@
 #include <linux/random.h>
 #include <linux/reboot.h>
 #include <linux/file.h>
+#include <linux/compat.h>
 #include <linux/delay.h>
 #include <linux/raid/md_p.h>
 #include <linux/raid/md_u.h>
@@ -287,9 +288,11 @@ static void md_end_barrier(struct bio *bio, int err)
 
 	if (atomic_dec_and_test(&mddev->flush_pending)) {
 		if (mddev->barrier == (void*)1) {
+			/* This was a post-request barrier */
 			mddev->barrier = NULL;
 			wake_up(&mddev->sb_wait);
 		} else
+			/* The pre-request barrier has finished */
 			schedule_work(&mddev->barrier_work);
 	}
 	bio_put(bio);
@@ -302,10 +305,16 @@ static void md_submit_barrier(struct work_struct *ws)
 
 	atomic_set(&mddev->flush_pending, 1);
 
-	if (!test_bit(BIO_EOPNOTSUPP, &bio->bi_flags)) {
+	if (test_bit(BIO_EOPNOTSUPP, &bio->bi_flags))
+		bio_endio(bio, -EOPNOTSUPP);
+	else if (bio->bi_size == 0)
+		/* an empty barrier - all done */
+		bio_endio(bio, 0);
+	else {
 		mdk_rdev_t *rdev;
 
 		bio->bi_rw &= ~(1<<BIO_RW_BARRIER);
+		bio->bi_rw |= (1<<BIO_RW_SYNCIO);
 		if (mddev->pers->make_request(mddev->queue, bio))
 			generic_make_request(bio);
 		mddev->barrier = (void*)1;
@@ -331,8 +340,7 @@ static void md_submit_barrier(struct work_struct *ws)
 				rdev_dec_pending(rdev, mddev);
 			}
 		rcu_read_unlock();
-	} else
-		bio_endio(bio, -EOPNOTSUPP);
+	}
 	if (atomic_dec_and_test(&mddev->flush_pending)) {
 		mddev->barrier = NULL;
 		wake_up(&mddev->sb_wait);
@@ -1512,12 +1520,10 @@ static void super_1_sync(mddev_t *mddev, mdk_rdev_t *rdev)
 
 	if (rdev->raid_disk >= 0 &&
 	    !test_bit(In_sync, &rdev->flags)) {
-		if (rdev->recovery_offset > 0) {
-			sb->feature_map |=
-				cpu_to_le32(MD_FEATURE_RECOVERY_OFFSET);
-			sb->recovery_offset =
-				cpu_to_le64(rdev->recovery_offset);
-		}
+		sb->feature_map |=
+			cpu_to_le32(MD_FEATURE_RECOVERY_OFFSET);
+		sb->recovery_offset =
+			cpu_to_le64(rdev->recovery_offset);
 	}
 
 	if (mddev->reshape_position != MaxSector) {
@@ -1551,7 +1557,7 @@ static void super_1_sync(mddev_t *mddev, mdk_rdev_t *rdev)
 			sb->dev_roles[i] = cpu_to_le16(0xfffe);
 		else if (test_bit(In_sync, &rdev2->flags))
 			sb->dev_roles[i] = cpu_to_le16(rdev2->raid_disk);
-		else if (rdev2->raid_disk >= 0 && rdev2->recovery_offset > 0)
+		else if (rdev2->raid_disk >= 0)
 			sb->dev_roles[i] = cpu_to_le16(rdev2->raid_disk);
 		else
 			sb->dev_roles[i] = cpu_to_le16(0xffff);
@@ -5663,6 +5669,25 @@ done:
 abort:
 	return err;
 }
+#ifdef CONFIG_COMPAT
+static int md_compat_ioctl(struct block_device *bdev, fmode_t mode,
+		    unsigned int cmd, unsigned long arg)
+{
+	switch (cmd) {
+	case HOT_REMOVE_DISK:
+	case HOT_ADD_DISK:
+	case SET_DISK_FAULTY:
+	case SET_BITMAP_FILE:
+		/* These take in integer arg, do not convert */
+		break;
+	default:
+		arg = (unsigned long)compat_ptr(arg);
+		break;
+	}
+
+	return md_ioctl(bdev, mode, cmd, arg);
+}
+#endif /* CONFIG_COMPAT */
 
 static int md_open(struct block_device *bdev, fmode_t mode)
 {
@@ -5728,6 +5753,9 @@ static const struct block_device_operations md_fops =
 	.open		= md_open,
 	.release	= md_release,
 	.ioctl		= md_ioctl,
+#ifdef CONFIG_COMPAT
+	.compat_ioctl	= md_compat_ioctl,
+#endif
 	.getgeo		= md_getgeo,
 	.media_changed	= md_media_changed,
 	.revalidate_disk= md_revalidate,
@@ -6518,7 +6546,9 @@ void md_do_sync(mddev_t *mddev)
 		       "md: resuming %s of %s from checkpoint.\n",
 		       desc, mdname(mddev));
 		mddev->curr_resync = j;
-	}
+		mddev->curr_resync_completed = j;
+	} else
+		mddev->curr_resync_completed = 0;
 
 	while (j < max_sectors) {
 		sector_t sectors;
@@ -6670,7 +6700,8 @@ void md_do_sync(mddev_t *mddev)
 	} else if (test_bit(MD_RECOVERY_REQUESTED, &mddev->recovery))
 		mddev->resync_min = mddev->curr_resync_completed;
 	mddev->curr_resync = 0;
-	mddev->curr_resync_completed = 0;
+	if (!test_bit(MD_RECOVERY_INTR, &mddev->recovery))
+		mddev->curr_resync_completed = 0;
 	sysfs_notify(&mddev->kobj, NULL, "sync_completed");
 	wake_up(&resync_wait);
 	set_bit(MD_RECOVERY_DONE, &mddev->recovery);
@@ -6733,6 +6764,7 @@ static int remove_and_add_spares(mddev_t *mddev)
 						       nm, mdname(mddev));
 					spares++;
 					md_new_event(mddev);
+					set_bit(MD_CHANGE_DEVS, &mddev->flags);
 				} else
 					break;
 			}
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index a8cab1d..f6c93a5 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3996,6 +3996,9 @@ static int make_request(struct request_queue *q, struct bio * bi)
 			finish_wait(&conf->wait_for_overlap, &w);
 			set_bit(STRIPE_HANDLE, &sh->state);
 			clear_bit(STRIPE_DELAYED, &sh->state);
+			if ((bi->bi_rw & (1<<BIO_RW_SYNCIO)) &&
+			    !test_and_set_bit(STRIPE_PREREAD_ACTIVE, &sh->state))
+				atomic_inc(&conf->preread_active_stripes);
 			release_stripe(sh);
 		} else {
 			/* cannot get stripe for read-ahead, just give-up */
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 8bd37d8..05c9211 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -1089,28 +1089,6 @@ COMPATIBLE_IOCTL(FIGETBSZ)
 /* 'X' - originally XFS but some now in the VFS */
 COMPATIBLE_IOCTL(FIFREEZE)
 COMPATIBLE_IOCTL(FITHAW)
-/* RAID */
-COMPATIBLE_IOCTL(RAID_VERSION)
-COMPATIBLE_IOCTL(GET_ARRAY_INFO)
-COMPATIBLE_IOCTL(GET_DISK_INFO)
-COMPATIBLE_IOCTL(PRINT_RAID_DEBUG)
-COMPATIBLE_IOCTL(RAID_AUTORUN)
-COMPATIBLE_IOCTL(CLEAR_ARRAY)
-COMPATIBLE_IOCTL(ADD_NEW_DISK)
-ULONG_IOCTL(HOT_REMOVE_DISK)
-COMPATIBLE_IOCTL(SET_ARRAY_INFO)
-COMPATIBLE_IOCTL(SET_DISK_INFO)
-COMPATIBLE_IOCTL(WRITE_RAID_INFO)
-COMPATIBLE_IOCTL(UNPROTECT_ARRAY)
-COMPATIBLE_IOCTL(PROTECT_ARRAY)
-ULONG_IOCTL(HOT_ADD_DISK)
-ULONG_IOCTL(SET_DISK_FAULTY)
-COMPATIBLE_IOCTL(RUN_ARRAY)
-COMPATIBLE_IOCTL(STOP_ARRAY)
-COMPATIBLE_IOCTL(STOP_ARRAY_RO)
-COMPATIBLE_IOCTL(RESTART_ARRAY_RW)
-COMPATIBLE_IOCTL(GET_BITMAP_FILE)
-ULONG_IOCTL(SET_BITMAP_FILE)
 /* Keyboard -- can be removed once tty3270 uses ops->compat_ioctl */
 ULONG_IOCTL(KDSIGACCEPT)
 COMPATIBLE_IOCTL(KDGETKEYCODE)
-- 
1.6.5.3