Hi,
I just compiled 2.6.31-rc1-git9 to give it a try. The problem I
encountered with this release is that it cannot recognize empty DVD
(probably CD will be the same. But, I didn't try it.) media with K3b.
I'm having the below error messages in dmesg. Also, I tried with several
new empty DVD medias. So, I'm sure that it's not a faulty DVD media. The
same media burns fine with K3b under <= 2.6.31-rc1-git6.
[ 4526.724245] cdrom: This disc doesn't have any tracks I recognize!
[ 4526.748278] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 4526.748285] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current]
[ 4526.748292] sr 0:0:0:0: [sr0] Add. Sense: Illegal mode for this track
[ 4526.748300] end_request: I/O error, dev sr0, sector 0
[ 4526.748307] Buffer I/O error on device sr0, logical block 0
[ 4526.750295] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 4526.750302] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current]
[ 4526.750308] sr 0:0:0:0: [sr0] Add. Sense: Illegal mode for this track
[ 4526.750316] end_request: I/O error, dev sr0, sector 0
[ 4526.750321] Buffer I/O error on device sr0, logical block 0
[ 4586.738212] cdrom: This disc doesn't have any tracks I recognize!
[ 4586.753644] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 4586.753652] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current]
[ 4586.753659] sr 0:0:0:0: [sr0] Add. Sense: Illegal mode for this track
[ 4586.753668] end_request: I/O error, dev sr0, sector 0
[ 4586.753673] Buffer I/O error on device sr0, logical block 0
[ 4586.757373] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 4586.757379] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current]
[ 4586.757384] sr 0:0:0:0: [sr0] Add. Sense: Illegal mode for this track
[ 4586.757391] end_request: I/O error, dev sr0, sector 0
[ 4586.757395] Buffer I/O error on device sr0, logical block 0
Tarkan
(cc linux-scsi)
On Thu, 02 Jul 2009 16:23:00 +0300
Tarkan Erimer <[email protected]> wrote:
> Hi,
>
> I just compiled 2.6.31-rc1-git9 to give it a try. The problem I
> encountered with this release is that it cannot recognize empty DVD
> (probably CD will be the same. But, I didn't try it.) media with K3b.
> I'm having the below error messages in dmesg. Also, I tried with several
> new empty DVD medias. So, I'm sure that it's not a faulty DVD media. The
> same media burns fine with K3b under <= 2.6.31-rc1-git6.
>
>
> [ 4526.724245] cdrom: This disc doesn't have any tracks I recognize!
> [ 4526.748278] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [ 4526.748285] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current]
> [ 4526.748292] sr 0:0:0:0: [sr0] Add. Sense: Illegal mode for this track
> [ 4526.748300] end_request: I/O error, dev sr0, sector 0
> [ 4526.748307] Buffer I/O error on device sr0, logical block 0
> [ 4526.750295] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [ 4526.750302] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current]
> [ 4526.750308] sr 0:0:0:0: [sr0] Add. Sense: Illegal mode for this track
> [ 4526.750316] end_request: I/O error, dev sr0, sector 0
> [ 4526.750321] Buffer I/O error on device sr0, logical block 0
> [ 4586.738212] cdrom: This disc doesn't have any tracks I recognize!
> [ 4586.753644] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [ 4586.753652] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current]
> [ 4586.753659] sr 0:0:0:0: [sr0] Add. Sense: Illegal mode for this track
> [ 4586.753668] end_request: I/O error, dev sr0, sector 0
> [ 4586.753673] Buffer I/O error on device sr0, logical block 0
> [ 4586.757373] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [ 4586.757379] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current]
> [ 4586.757384] sr 0:0:0:0: [sr0] Add. Sense: Illegal mode for this track
> [ 4586.757391] end_request: I/O error, dev sr0, sector 0
> [ 4586.757395] Buffer I/O error on device sr0, logical block 0
There are no recent changes to cdrom.c. Maybe it's due to a scsi change?
Similar issue on 2 machines. 2.6.31-rc1-git3 works ok. 2.6.31-rc2
cannot recognize *any* DVD media with K3b. No messages in dmesg or
syslog.
Unfortunately I can't try bisection, because I don't have more time
(work). I try do it at the end of week.
--
Maciej Rutecki
http://www.maciek.unixy.pl
On Wed, 2009-07-08 at 15:09 +0200, Maciej Rutecki wrote:
> Similar issue on 2 machines. 2.6.31-rc1-git3 works ok. 2.6.31-rc2
> cannot recognize *any* DVD media with K3b. No messages in dmesg or
> syslog.
>
> Unfortunately I can't try bisection, because I don't have more time
> (work). I try do it at the end of week.
Also were there any tools upgrades around this? The messages:
> [ 4526.750295] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [ 4526.750302] sr 0:0:0:0: [sr0] Sense Key : Illegal Request [current]
> [ 4526.750308] sr 0:0:0:0: [sr0] Add. Sense: Illegal mode for this track
> [ 4526.750316] end_request: I/O error, dev sr0, sector 0
> [ 4526.750321] Buffer I/O error on device sr0, logical block 0
Clearly imply the errors are coming from the device: The sense code is
generated by it. So this means that either the DVD has been put into
some type of wrong mode or something in sr is sending the wrong command.
You might also try this patch from martin petersen: it will print out
the actual command that's causing the problems ... that might give a
clue.
James
---
Subject: [PATCH] SCSI: Print failed commands
From: "Martin K. Petersen" <[email protected]>
When a request fails we print the sense data but not the actual command
that failed. Add a printout of the operation + CDB for failed commands.
Signed-off-by: Martin K. Petersen <[email protected]>
---
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 30f3275..79ea5be 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -896,6 +896,7 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
scsi_print_result(cmd);
if (driver_byte(result) & DRIVER_SENSE)
scsi_print_sense("", cmd);
+ scsi_print_command(cmd);
}
blk_end_request_all(req, -EIO);
scsi_next_command(cmd);
On Wed, 2009-07-08 at 09:27 -0500, James Bottomley wrote:
>
> You might also try this patch from martin petersen: it will print out
> the actual command that's causing the problems ... that might give a
> clue.
>
> James
On the bugzilla entry ,
http://bugzilla.kernel.org/show_bug.cgi?id=13727
Thomas Meyer indicated it was (possibly) the following commit,
018e0446890661504783f92388ecce7138c1566d
I added Jens to the CC ..
Daniel
On Wed, 2009-07-08 at 09:06 -0700, Daniel Walker wrote:
> On Wed, 2009-07-08 at 09:27 -0500, James Bottomley wrote:
> >
> > You might also try this patch from martin petersen: it will print out
> > the actual command that's causing the problems ... that might give a
> > clue.
> >
> > James
>
> On the bugzilla entry ,
>
> http://bugzilla.kernel.org/show_bug.cgi?id=13727
>
> Thomas Meyer indicated it was (possibly) the following commit,
>
> 018e0446890661504783f92388ecce7138c1566d
>
> I added Jens to the CC ..
So thats:
commit 018e0446890661504783f92388ecce7138c1566d
Author: Jens Axboe <[email protected]>
Date: Fri Jun 26 16:27:10 2009 +0200
block: get rid of queue-private command filter
What this tends to suggest is that the command filter was blocking some
type of command sent from user space which is causing the problem, and
now we're letting it through. Restoring the command filter will work
around the problem, but the root cause should be finding and fixing
whatever is issuing the commands in the first place.
James
On Wed, Jul 08 2009, James Bottomley wrote:
> On Wed, 2009-07-08 at 09:06 -0700, Daniel Walker wrote:
> > On Wed, 2009-07-08 at 09:27 -0500, James Bottomley wrote:
> > >
> > > You might also try this patch from martin petersen: it will print out
> > > the actual command that's causing the problems ... that might give a
> > > clue.
> > >
> > > James
> >
> > On the bugzilla entry ,
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=13727
> >
> > Thomas Meyer indicated it was (possibly) the following commit,
> >
> > 018e0446890661504783f92388ecce7138c1566d
> >
> > I added Jens to the CC ..
>
> So thats:
>
> commit 018e0446890661504783f92388ecce7138c1566d
> Author: Jens Axboe <[email protected]>
> Date: Fri Jun 26 16:27:10 2009 +0200
>
> block: get rid of queue-private command filter
>
> What this tends to suggest is that the command filter was blocking some
> type of command sent from user space which is causing the problem, and
> now we're letting it through. Restoring the command filter will work
> around the problem, but the root cause should be finding and fixing
> whatever is issuing the commands in the first place.
There should be no functional change, since the filters were all the
same. Perhaps blk_scsi_ioctl_init() isn't being run, a good start would
be to stick a printk() in there and verify that it's actually being
executed. I've been tricked by __init before.
--
Jens Axboe
2009/7/8 James Bottomley <[email protected]>:
> On Wed, 2009-07-08 at 09:06 -0700, Daniel Walker wrote:
>> On Wed, 2009-07-08 at 09:27 -0500, James Bottomley wrote:
>> >
>> > You might also try this patch from martin petersen: it will print out
>> > the actual command that's causing the problems ... that might give a
>> > clue.
>> >
>> > James
>>
>> On the bugzilla entry ,
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=13727
>>
>> Thomas Meyer indicated it was (possibly) the following commit,
>>
>> 018e0446890661504783f92388ecce7138c1566d
>>
>> I added Jens to the CC ..
>
> So thats:
>
> commit 018e0446890661504783f92388ecce7138c1566d
> Author: Jens Axboe <[email protected]>
> Date: Fri Jun 26 16:27:10 2009 +0200
>
> block: get rid of queue-private command filter
>
> What this tends to suggest is that the command filter was blocking some
> type of command sent from user space which is causing the problem, and
> now we're letting it through. Restoring the command filter will work
> around the problem, but the root cause should be finding and fixing
> whatever is issuing the commands in the first place.
>
> James
>
>
>
Confirm. I find some time, and do bisection:
018e0446890661504783f92388ecce7138c1566d is first bad commit
commit 018e0446890661504783f92388ecce7138c1566d
Author: Jens Axboe <[email protected]>
Date: Fri Jun 26 16:27:10 2009 +0200
block: get rid of queue-private command filter
The initial patches to support this through sysfs export were broken
and have been if 0'ed out in any release. So lets just kill the code
and reclaim some space in struct request_queue, if anyone would later
like to fixup the sysfs bits, the git history can easily restore
the removed bits.
Signed-off-by: Jens Axboe <[email protected]>
:040000 040000 aaaec08cd15fe376286ef07b90eddb60f7dc98a1
5cc15daa4a596dcb97300baf7828e78ceeb40d5e M block
:040000 040000 f1fbb94e7136c18e0df7d967800073a98901d51d
0d0a6e6e360b75daf9dc673a5ef0b7d745d5718e M drivers
:040000 040000 e56a6498a1ca54adce4972cc2fe092a6e054165f
1c1e974e56532151cf0c98bfeb1ff05971e5b2c1 M include
I revert this commit and in -rc2 k3b can see dvd drive. (some
explanation: I have little different problem; k3b can't see/detect DVD
drive).
Regards
--
Maciej Rutecki
http://www.maciek.unixy.pl
>>>>> "James" == James Bottomley <[email protected]> writes:
James> You might also try this patch from martin petersen: it will print
James> out the actual command that's causing the problems ... that might
James> give a clue.
Any particular reason you didn't merge that patch, btw.? It's been
extremely useful on this end...
--
Martin K. Petersen Oracle Linux Engineering
On Wed, 8 Jul 2009 18:57:28 +0200
Jens Axboe <[email protected]> wrote:
> On Wed, Jul 08 2009, James Bottomley wrote:
> > On Wed, 2009-07-08 at 09:06 -0700, Daniel Walker wrote:
> > > On Wed, 2009-07-08 at 09:27 -0500, James Bottomley wrote:
> > > >
> > > > You might also try this patch from martin petersen: it will print out
> > > > the actual command that's causing the problems ... that might give a
> > > > clue.
> > > >
> > > > James
> > >
> > > On the bugzilla entry ,
> > >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=13727
> > >
> > > Thomas Meyer indicated it was (possibly) the following commit,
> > >
> > > 018e0446890661504783f92388ecce7138c1566d
> > >
> > > I added Jens to the CC ..
> >
> > So thats:
> >
> > commit 018e0446890661504783f92388ecce7138c1566d
> > Author: Jens Axboe <[email protected]>
> > Date: Fri Jun 26 16:27:10 2009 +0200
> >
> > block: get rid of queue-private command filter
> >
> > What this tends to suggest is that the command filter was blocking some
> > type of command sent from user space which is causing the problem, and
> > now we're letting it through. Restoring the command filter will work
> > around the problem, but the root cause should be finding and fixing
> > whatever is issuing the commands in the first place.
>
> There should be no functional change, since the filters were all the
> same. Perhaps blk_scsi_ioctl_init() isn't being run, a good start would
> be to stick a printk() in there and verify that it's actually being
> executed. I've been tricked by __init before.
I can't find where you call blk_scsi_ioctl_init(). I've attached a fix
(not tested).
Jens, I'm not sure that I saw the above patch on any mailing list. If
you merged the patch without sending any mailing list, please don't do
that.
=
From: FUJITA Tomonori <[email protected]>
Subject: [PATCH] block: call blk_scsi_ioctl_init()
Currently, blk_scsi_ioctl_init() is not called so
blk_default_cmd_filter isn't initalized. Some commands are not blocked
wrongly.
This fixes a regression introduced:
commit 018e0446890661504783f92388ecce7138c1566d
Author: Jens Axboe <[email protected]>
Date: Fri Jun 26 16:27:10 2009 +0200
block: get rid of queue-private command filter
Signed-off-by: FUJITA Tomonori <[email protected]>
---
block/scsi_ioctl.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index f0e0ce0..e5b1001 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -680,3 +680,4 @@ int __init blk_scsi_ioctl_init(void)
blk_set_cmd_filter_defaults(&blk_default_cmd_filter);
return 0;
}
+fs_initcall(blk_scsi_ioctl_init);
--
1.6.0.6
On Thu, 9 Jul 2009 08:49:34 +0900
FUJITA Tomonori <[email protected]> wrote:
> On Wed, 8 Jul 2009 18:57:28 +0200
> Jens Axboe <[email protected]> wrote:
>
> > On Wed, Jul 08 2009, James Bottomley wrote:
> > > On Wed, 2009-07-08 at 09:06 -0700, Daniel Walker wrote:
> > > > On Wed, 2009-07-08 at 09:27 -0500, James Bottomley wrote:
> > > > >
> > > > > You might also try this patch from martin petersen: it will print out
> > > > > the actual command that's causing the problems ... that might give a
> > > > > clue.
> > > > >
> > > > > James
> > > >
> > > > On the bugzilla entry ,
> > > >
> > > > http://bugzilla.kernel.org/show_bug.cgi?id=13727
> > > >
> > > > Thomas Meyer indicated it was (possibly) the following commit,
> > > >
> > > > 018e0446890661504783f92388ecce7138c1566d
> > > >
> > > > I added Jens to the CC ..
> > >
> > > So thats:
> > >
> > > commit 018e0446890661504783f92388ecce7138c1566d
> > > Author: Jens Axboe <[email protected]>
> > > Date: Fri Jun 26 16:27:10 2009 +0200
> > >
> > > block: get rid of queue-private command filter
> > >
> > > What this tends to suggest is that the command filter was blocking some
> > > type of command sent from user space which is causing the problem, and
> > > now we're letting it through. Restoring the command filter will work
> > > around the problem, but the root cause should be finding and fixing
> > > whatever is issuing the commands in the first place.
> >
> > There should be no functional change, since the filters were all the
> > same. Perhaps blk_scsi_ioctl_init() isn't being run, a good start would
> > be to stick a printk() in there and verify that it's actually being
> > executed. I've been tricked by __init before.
>
> I can't find where you call blk_scsi_ioctl_init(). I've attached a fix
> (not tested).
>
> Jens, I'm not sure that I saw the above patch on any mailing list. If
> you merged the patch without sending any mailing list, please don't do
> that.
>
>
> =
> From: FUJITA Tomonori <[email protected]>
> Subject: [PATCH] block: call blk_scsi_ioctl_init()
>
> Currently, blk_scsi_ioctl_init() is not called so
> blk_default_cmd_filter isn't initalized. Some commands are not blocked
> wrongly.
Oops, it should have been "some commands are blocked wrongly".
On Wed, 2009-07-08 at 18:52 -0400, Martin K. Petersen wrote:
> >>>>> "James" == James Bottomley <[email protected]> writes:
>
> James> You might also try this patch from martin petersen: it will print
> James> out the actual command that's causing the problems ... that might
> James> give a clue.
>
> Any particular reason you didn't merge that patch, btw.? It's been
> extremely useful on this end...
No-one reminded me ... until the potential debugging use triggered a
memory.
James
2009/7/9 FUJITA Tomonori <[email protected]>:
> From: FUJITA Tomonori <[email protected]>
> Subject: [PATCH] block: call blk_scsi_ioctl_init()
>
> Currently, blk_scsi_ioctl_init() is not called so
> blk_default_cmd_filter isn't initalized. Some commands are not blocked
> wrongly.
>
> This fixes a regression introduced:
>
> commit 018e0446890661504783f92388ecce7138c1566d
> Author: Jens Axboe <[email protected]>
> Date: Fri Jun 26 16:27:10 2009 +0200
>
> block: get rid of queue-private command filter
>
> Signed-off-by: FUJITA Tomonori <[email protected]>
Works with latest git. Thanks for patch
Tested-by Maciej Rutecki <maciej.rutecki@gmail>
--
Maciej Rutecki
http://www.maciek.unixy.pl
On Thu, Jul 09 2009, FUJITA Tomonori wrote:
> From: FUJITA Tomonori <[email protected]>
> Subject: [PATCH] block: call blk_scsi_ioctl_init()
>
> Currently, blk_scsi_ioctl_init() is not called so
> blk_default_cmd_filter isn't initalized. Some commands are not blocked
> wrongly.
>
> This fixes a regression introduced:
>
> commit 018e0446890661504783f92388ecce7138c1566d
> Author: Jens Axboe <[email protected]>
> Date: Fri Jun 26 16:27:10 2009 +0200
>
> block: get rid of queue-private command filter
>
> Signed-off-by: FUJITA Tomonori <[email protected]>
> ---
> block/scsi_ioctl.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
> index f0e0ce0..e5b1001 100644
> --- a/block/scsi_ioctl.c
> +++ b/block/scsi_ioctl.c
> @@ -680,3 +680,4 @@ int __init blk_scsi_ioctl_init(void)
> blk_set_cmd_filter_defaults(&blk_default_cmd_filter);
> return 0;
> }
> +fs_initcall(blk_scsi_ioctl_init);
> --
> 1.6.0.6
You beat me to it, it was the missing call as I suspected. This
works, I verified it myself. Applied to for-linus, going upstream
soon.
--
Jens Axboe
On Thu, 9 Jul 2009 09:50:04 +0200
Jens Axboe <[email protected]> wrote:
> On Thu, Jul 09 2009, FUJITA Tomonori wrote:
> > From: FUJITA Tomonori <[email protected]>
> > Subject: [PATCH] block: call blk_scsi_ioctl_init()
> >
> > Currently, blk_scsi_ioctl_init() is not called so
> > blk_default_cmd_filter isn't initalized. Some commands are not blocked
> > wrongly.
> >
> > This fixes a regression introduced:
> >
> > commit 018e0446890661504783f92388ecce7138c1566d
> > Author: Jens Axboe <[email protected]>
> > Date: Fri Jun 26 16:27:10 2009 +0200
> >
> > block: get rid of queue-private command filter
> >
> > Signed-off-by: FUJITA Tomonori <[email protected]>
> > ---
> > block/scsi_ioctl.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
> > index f0e0ce0..e5b1001 100644
> > --- a/block/scsi_ioctl.c
> > +++ b/block/scsi_ioctl.c
> > @@ -680,3 +680,4 @@ int __init blk_scsi_ioctl_init(void)
> > blk_set_cmd_filter_defaults(&blk_default_cmd_filter);
> > return 0;
> > }
> > +fs_initcall(blk_scsi_ioctl_init);
> > --
> > 1.6.0.6
>
> You beat me to it, it was the missing call as I suspected. This
> works, I verified it myself. Applied to for-linus, going upstream
> soon.
I really hope that you become more serious about not causing such
incident; breaking mainline kernel by merging your trivial patch after
-rc1 (even without sending the patch to any mailing list). You broke
mainline in the exact same way just months ago (the commit
1e42807918d17e8c93bf14fbb74be84b141334c1 in 2.6.29-rc7).
Thanks,
On Thu, Jul 09 2009, FUJITA Tomonori wrote:
> On Thu, 9 Jul 2009 09:50:04 +0200
> Jens Axboe <[email protected]> wrote:
>
> > On Thu, Jul 09 2009, FUJITA Tomonori wrote:
> > > From: FUJITA Tomonori <[email protected]>
> > > Subject: [PATCH] block: call blk_scsi_ioctl_init()
> > >
> > > Currently, blk_scsi_ioctl_init() is not called so
> > > blk_default_cmd_filter isn't initalized. Some commands are not blocked
> > > wrongly.
> > >
> > > This fixes a regression introduced:
> > >
> > > commit 018e0446890661504783f92388ecce7138c1566d
> > > Author: Jens Axboe <[email protected]>
> > > Date: Fri Jun 26 16:27:10 2009 +0200
> > >
> > > block: get rid of queue-private command filter
> > >
> > > Signed-off-by: FUJITA Tomonori <[email protected]>
> > > ---
> > > block/scsi_ioctl.c | 1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
> > > index f0e0ce0..e5b1001 100644
> > > --- a/block/scsi_ioctl.c
> > > +++ b/block/scsi_ioctl.c
> > > @@ -680,3 +680,4 @@ int __init blk_scsi_ioctl_init(void)
> > > blk_set_cmd_filter_defaults(&blk_default_cmd_filter);
> > > return 0;
> > > }
> > > +fs_initcall(blk_scsi_ioctl_init);
> > > --
> > > 1.6.0.6
> >
> > You beat me to it, it was the missing call as I suspected. This
> > works, I verified it myself. Applied to for-linus, going upstream
> > soon.
>
> I really hope that you become more serious about not causing such
> incident; breaking mainline kernel by merging your trivial patch after
> -rc1 (even without sending the patch to any mailing list). You broke
> mainline in the exact same way just months ago (the commit
> 1e42807918d17e8c93bf14fbb74be84b141334c1 in 2.6.29-rc7).
It should have waited for .32, I agree. I had it sitting around
for quite a while, not sure why the merged version didn't have
the initcall added. But yes, I should have posted and postponed
it.
--
Jens Axboe