Linux-2.6.31-rc1-git9 Cannot Recognize Empty DVD Media

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

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.

[ 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

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

Quoted 6 lines · James Bottomley

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 ..

Quoted 10 lines · Daniel Walker

Quoted 6 lines · James Bottomley

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 ,

Quoted 7 lines

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.

Quoted 25 lines · James Bottomley

Quoted 10 lines · Daniel Walker

Quoted 6 lines · James Bottomley

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 ,

Quoted 7 lines

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

Quoted 7 lines

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.

Quoted 34 lines · On Wed, 8 Jul 2009 18:57:28 +0200 Jens Axboe <[email protected]> wrote:

Quoted 25 lines · James Bottomley

Quoted 10 lines · Daniel Walker

Quoted 6 lines · James Bottomley

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 ,

Quoted 7 lines

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

Quoted 7 lines

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.

Quoted 4 lines

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.

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]>

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(-)

block/scsi_ioctl.c +1 -0

index f0e0ce0..e5b1001 100644
@@ -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);

Signature · 1 line

1.6.0.6

Quoted 20 lines · FUJITA Tomonori

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(-)

Quoted 11 lines

block/scsi_ioctl.c +1 -0

index f0e0ce0..e5b1001 100644
@@ -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);

Signature · 1 line

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.

Quoted 21 lines · On Thu, 9 Jul 2009 09:50:04 +0200 Jens Axboe <[email protected]> wrote:

Quoted 20 lines · FUJITA Tomonori

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(-)

Quoted 15 lines

Quoted 11 lines

block/scsi_ioctl.c +1 -0

index f0e0ce0..e5b1001 100644
@@ -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);

Signature · 1 line

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).

Quoted 10 lines · James Bottomley

Quoted 6 lines

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 ,

Quoted 7 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"James" == James Bottomley <[email protected]> writes:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"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...