Re: 2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error
On Thu, Nov 29 2007 at 1:36 +0200, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Nov 2007 16:14:21 -0700
> Matthew Wilcox <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Nov 28, 2007 at 01:40:36PM -0800, Andrew Morton wrote:
>>> On Wed, 28 Nov 2007 23:01:31 +0300
>>> Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
>>>
Reliably spams dmesg with end_request() horrors. This happens when git
starts checking out linux tree to fresh ext2 partition. Disk is several
month old and there were no prolems with, say, 2.6.24-rc3:
>> Could you try reverting 6f5391c283d7fdcf24bf40786ea79061919d1e1d and see
>> if the problem still exists?
>>
>
> That's not completely trivial..
>
> I did a hand-made revert against 2.6.24-rc3-mm2 (below) but some other patch
> in there causes:
>
> drivers/scsi/scsi_lib.c: In function 'scsi_blk_pc_done':
> drivers/scsi/scsi_lib.c:1251: error: 'struct scsi_cmnd' has no member named
> 'request_bufflen'
>
That would be the bidi patches. You need to use scsi_bufflen(cmd) instead of
cmd->request_bufflen. (See below)
Do you need that I send a patch?
>
> --- a/drivers/scsi/scsi.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
> +++ a/drivers/scsi/scsi.c
> @@ -59,7 +59,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -379,8 +378,9 @@ void scsi_log_send(struct scsi_cmnd *cmd
> scsi_print_command(cmd);
> if (level > 3) {
> printk(KERN_INFO "buffer = 0x%p, bufflen = %d,"
> -" queuecommand 0x%p\n",
> +" done = 0x%p, queuecommand 0x%p\n",
> scsi_sglist(cmd), scsi_bufflen(cmd),
> + cmd->done,
> cmd->device->host->hostt->queuecommand);
>
> }
> @@ -667,12 +667,6 @@ void __scsi_done(struct scsi_cmnd *cmd)
> blk_complete_request(rq);
> }
>
> -/* Move this to a header if it becomes more generally useful */
> -static struct scsi_driver *scsi_cmd_to_driver(struct scsi_cmnd *cmd)
> -{
> - return *(struct scsi_driver **)cmd->request->rq_disk->private_data;
> -}
> -
> /**
> * scsi_finish_command - cleanup and pass command back to upper layer
> * @cmd: the command
> @@ -685,8 +679,6 @@ void scsi_finish_command(struct scsi_cmn
> {
> struct scsi_device *sdev = cmd->device;
> struct Scsi_Host *shost = sdev->host;
> - struct scsi_driver *drv;
> - unsigned int good_bytes;
>
> scsi_device_unbusy(sdev);
>
> @@ -712,13 +704,7 @@ void scsi_finish_command(struct scsi_cmn
> "Notifying upper driver of completion "
> "(result %x)\n", cmd->result));
>
> - good_bytes = scsi_bufflen(cmd);
> -if (cmd->request->cmd_type != REQ_TYPE_BLOCK_PC) {
> - drv = scsi_cmd_to_driver(cmd);
> - if (drv->done)
> - good_bytes = drv->done(cmd);
> - }
> - scsi_io_completion(cmd, good_bytes);
> + cmd->done(cmd);
> }
> EXPORT_SYMBOL(scsi_finish_command);
>
> diff -puN
> drivers/scsi/scsi_error.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
> drivers/scsi/scsi_error.c
> ---
> a/drivers/scsi/scsi_error.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
> +++ a/drivers/scsi/scsi_error.c
> @@ -1697,6 +1697,7 @@ scsi_reset_provider(struct scsi_device *
>
> scmd->scsi_done = scsi_reset_provider_done_command;
> memset(&scmd->sdb, 0, sizeof(scmd->sdb));
> + scmd->done = NULL;
>
> scmd->cmd_len = 0;
>
> diff -puN
> drivers/scsi/scsi_lib.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
> drivers/scsi/scsi_lib.c
> --- a/drivers/scsi/scsi_lib.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
> +++ a/drivers/scsi/scsi_lib.c
> @@ -944,6 +944,7 @@ void scsi_end_bidi_request(struct scsi_c
>
> scsi_finalize_request(cmd, 1);
> }
> +EXPORT_SYMBOL(scsi_io_completion);
>
> /*
> * Function:scsi_io_completion()
> @@ -1238,6 +1239,18 @@ static struct scsi_cmnd *scsi_get_cmd_fr
> return cmd;
> }
>
> +static void scsi_blk_pc_done(struct scsi_cmnd *cmd)
> +{
> + BUG_ON(!blk_pc_request(cmd->request));
> + /*
> + * This will complete the whole command with uptodate=1 so
> + * as far as the block layer is concerned the command completed
> + * successfully. Since this is a REQ_BLOCK_PC command the
> + * caller should check the request's errors value
> + */
> + scsi_io_completion(cmd, cmd->request_bufflen);
+ scsi_io_completion(cmd, scsi_bufflen(cmd));
> +}
> +
> int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req)
> {
> struct scsi_cmnd *cmd;
> @@ -1285,6 +1298,7 @@ int scsi_setup_blk_pc_cmnd(struct scsi_d
> cmd->transfersize = req->data_len;
> cmd->allowed = req
Re: 2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error
On Wed, 28 Nov 2007 16:14:21 -0700
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 28, 2007 at 01:40:36PM -0800, Andrew Morton wrote:
> > On Wed, 28 Nov 2007 23:01:31 +0300
> > Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> >
> > > Reliably spams dmesg with end_request() horrors. This happens when git
> > > starts checking out linux tree to fresh ext2 partition. Disk is several
> > > month old and there were no prolems with, say, 2.6.24-rc3:
>
> Could you try reverting 6f5391c283d7fdcf24bf40786ea79061919d1e1d and see
> if the problem still exists?
>
That's not completely trivial..
I did a hand-made revert against 2.6.24-rc3-mm2 (below) but some other patch
in there causes:
drivers/scsi/scsi_lib.c: In function 'scsi_blk_pc_done':
drivers/scsi/scsi_lib.c:1251: error: 'struct scsi_cmnd' has no member named
'request_bufflen'
--- a/drivers/scsi/scsi.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
+++ a/drivers/scsi/scsi.c
@@ -59,7 +59,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -379,8 +378,9 @@ void scsi_log_send(struct scsi_cmnd *cmd
scsi_print_command(cmd);
if (level > 3) {
printk(KERN_INFO "buffer = 0x%p, bufflen = %d,"
- " queuecommand 0x%p\n",
+ " done = 0x%p, queuecommand 0x%p\n",
scsi_sglist(cmd), scsi_bufflen(cmd),
+ cmd->done,
cmd->device->host->hostt->queuecommand);
}
@@ -667,12 +667,6 @@ void __scsi_done(struct scsi_cmnd *cmd)
blk_complete_request(rq);
}
-/* Move this to a header if it becomes more generally useful */
-static struct scsi_driver *scsi_cmd_to_driver(struct scsi_cmnd *cmd)
-{
- return *(struct scsi_driver **)cmd->request->rq_disk->private_data;
-}
-
/**
* scsi_finish_command - cleanup and pass command back to upper layer
* @cmd: the command
@@ -685,8 +679,6 @@ void scsi_finish_command(struct scsi_cmn
{
struct scsi_device *sdev = cmd->device;
struct Scsi_Host *shost = sdev->host;
- struct scsi_driver *drv;
- unsigned int good_bytes;
scsi_device_unbusy(sdev);
@@ -712,13 +704,7 @@ void scsi_finish_command(struct scsi_cmn
"Notifying upper driver of completion "
"(result %x)\n", cmd->result));
- good_bytes = scsi_bufflen(cmd);
-if (cmd->request->cmd_type != REQ_TYPE_BLOCK_PC) {
- drv = scsi_cmd_to_driver(cmd);
- if (drv->done)
- good_bytes = drv->done(cmd);
- }
- scsi_io_completion(cmd, good_bytes);
+ cmd->done(cmd);
}
EXPORT_SYMBOL(scsi_finish_command);
diff -puN
drivers/scsi/scsi_error.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
drivers/scsi/scsi_error.c
--- a/drivers/scsi/scsi_error.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
+++ a/drivers/scsi/scsi_error.c
@@ -1697,6 +1697,7 @@ scsi_reset_provider(struct scsi_device *
scmd->scsi_done = scsi_reset_provider_done_command;
memset(&scmd->sdb, 0, sizeof(scmd->sdb));
+ scmd->done = NULL;
scmd->cmd_len = 0;
diff -puN
drivers/scsi/scsi_lib.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
+++ a/drivers/scsi/scsi_lib.c
@@ -944,6 +944,7 @@ void scsi_end_bidi_request(struct scsi_c
scsi_finalize_request(cmd, 1);
}
+EXPORT_SYMBOL(scsi_io_completion);
/*
* Function:scsi_io_completion()
@@ -1238,6 +1239,18 @@ static struct scsi_cmnd *scsi_get_cmd_fr
return cmd;
}
+static void scsi_blk_pc_done(struct scsi_cmnd *cmd)
+{
+ BUG_ON(!blk_pc_request(cmd->request));
+ /*
+* This will complete the whole command with uptodate=1 so
+* as far as the block layer is concerned the command completed
+* successfully. Since this is a REQ_BLOCK_PC command the
+* caller should check the request's errors value
+*/
+ scsi_io_completion(cmd, cmd->request_bufflen);
+}
+
int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req)
{
struct scsi_cmnd *cmd;
@@ -1285,6 +1298,7 @@ int scsi_setup_blk_pc_cmnd(struct scsi_d
cmd->transfersize = req->data_len;
cmd->allowed = req->retries;
cmd->timeout_per_command = req->timeout;
+ cmd->done = scsi_blk_pc_done;
return BLKPREP_OK;
}
EXPORT_SYMBOL(scsi_setup_blk_pc_cmnd);
diff -puN
drivers/scsi/scsi_priv.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
drivers/scsi/scsi_priv.h
--- a/drivers/scsi/scsi_priv.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
+++ a/drivers/scsi/scsi_priv.h
@@ -68,7 +68,6 @@ extern int scsi_maybe_u
Re: 2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error
On Wed, Nov 28, 2007 at 01:40:36PM -0800, Andrew Morton wrote: > On Wed, 28 Nov 2007 23:01:31 +0300 > Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > > > Reliably spams dmesg with end_request() horrors. This happens when git > > starts checking out linux tree to fresh ext2 partition. Disk is several > > month old and there were no prolems with, say, 2.6.24-rc3: Could you try reverting 6f5391c283d7fdcf24bf40786ea79061919d1e1d and see if the problem still exists? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error
> > [ 225.378426] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > > [ 225.378659] end_request: I/O error, dev sdb, sector 141295703 > > [ 225.390133] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > > [ 225.391988] end_request: I/O error, dev sdb, sector 141295703 > > [ 225.392463] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > > [ 225.392625] end_request: I/O error, dev sdb, sector 141295703 > > [ 225.392999] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > > [ 225.393161] end_request: I/O error, dev sdb, sector 141295703 > > [ 225.393571] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > > [ 225.393731] end_request: I/O error, dev sdb, sector 141295703 > > [ 225.394382] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > > [ 225.394544] end_request: I/O error, dev sdb, sector 141295703 > > [ 225.395247] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > > [ 225.395412] end_request: I/O error, dev sdb, sector 141295703 > > I don't know whether this failure was a scsi thing or an ata thing? The ATA layer would print diagnostics if it failed the command so I'm a bit baffled by the report. It looks like the SCSI mid layer rejected it before we even got it ? - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error
On Wed, 28 Nov 2007 23:01:31 +0300 Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > Reliably spams dmesg with end_request() horrors. This happens when git > starts checking out linux tree to fresh ext2 partition. Disk is several > month old and there were no prolems with, say, 2.6.24-rc3: > > [ 225.378426] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.378659] end_request: I/O error, dev sdb, sector 141295703 > [ 225.390133] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.391988] end_request: I/O error, dev sdb, sector 141295703 > [ 225.392463] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.392625] end_request: I/O error, dev sdb, sector 141295703 > [ 225.392999] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.393161] end_request: I/O error, dev sdb, sector 141295703 > [ 225.393571] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.393731] end_request: I/O error, dev sdb, sector 141295703 > [ 225.394382] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.394544] end_request: I/O error, dev sdb, sector 141295703 > [ 225.395247] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.395412] end_request: I/O error, dev sdb, sector 141295703 > > CONFIG_ATA=y > # CONFIG_ATA_NONSTANDARD is not set > CONFIG_ATA_ACPI=y > CONFIG_SATA_AHCI=y > CONFIG_ATA_PIIX=y > CONFIG_PATA_JMICRON=y and > [ 35.229713] sd 2:0:1:0: [sdb] 976773168 512-byte hardware sectors (500108 > MB) So that's an OK sector number. > [0.00] Linux version 2.6.24-rc3-mm2 ([EMAIL PROTECTED]) (gcc version > 4.1.2 (Gentoo 4.1.2 p1.0.2)) #3 SMP PREEMPT Wed Nov 28 22:23:45 MSK 2007 > [0.00] Command line: root=/dev/sda2 [EMAIL PROTECTED]/eth0,[EMAIL > PROTECTED]/00:80:48:45:EC:73 ignore_loglevel > [0.00] BIOS-provided physical RAM map: > [0.00] BIOS-e820: - 0009fc00 (usable) > [0.00] BIOS-e820: 0009fc00 - 000a (reserved) > [0.00] BIOS-e820: 000e4000 - 0010 (reserved) > [0.00] BIOS-e820: 0010 - 7ff9 (usable) > [0.00] BIOS-e820: 7ff9 - 7ff9e000 (ACPI data) > [0.00] BIOS-e820: 7ff9e000 - 7ffe (ACPI NVS) > [0.00] BIOS-e820: 7ffe - 8000 (reserved) > [0.00] BIOS-e820: fee0 - fee01000 (reserved) > [0.00] BIOS-e820: ffb0 - 0001 (reserved) > [0.00] BIOS-e820: 0001 - 00018000 (usable) > [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used > [0.00] Entering add_active_range(0, 256, 524176) 1 entries of 256 used > [0.00] Entering add_active_range(0, 1048576, 1572864) 2 entries of > 256 used > [0.00] end_pfn_map = 1572864 > [0.00] DMI 2.4 present. > [0.00] ACPI: RSDP 000FA980, 0024 (r2 ACPIAM) > [0.00] ACPI: XSDT 7FF90100, 0054 (r1 KOZIRO FRONTIER 2000707 MSFT >97) > [0.00] ACPI: FACP 7FF90290, 00F4 (r3 MSTEST OEMFACP 2000707 MSFT >97) > [0.00] ACPI: DSDT 7FF905C0, 8FA9 (r1 A0637 A06370000 INTL > 20060113) > [0.00] ACPI: FACS 7FF9E000, 0040 > [0.00] ACPI: APIC 7FF90390, 006C (r1 MSTEST OEMAPIC 2000707 MSFT >97) > [0.00] ACPI: MCFG 7FF90400, 003C (r1 MSTEST OEMMCFG 2000707 MSFT >97) > [0.00] ACPI: SLIC 7FF90440, 0176 (r1 KOZIRO FRONTIER 2000707 MSFT >97) > [0.00] ACPI: OEMB 7FF9E040, 007B (r1 MSTEST AMI_OEM 2000707 MSFT >97) > [0.00] ACPI: HPET 7FF99570, 0038 (r1 MSTEST OEMHPET 2000707 MSFT >97) > [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used > [0.00] Entering add_active_range(0, 256, 524176) 1 entries of 256 used > [0.00] Entering add_active_range(0, 1048576, 1572864) 2 entries of > 256 used > [0.00] [e200-e21f] PMD ->81000120 on > node 0 > [0.00] [e220-e23f] PMD ->81000160 on > node 0 > [0.00] [e240-e25f] PMD ->810001A0 on > node 0 > [0.00] [e260-e27f] PMD ->810001E0 on > node 0 > [0.00] [e280-e29f] PMD ->81000220 on > node 0 > [0.00] [e2a0-e2bf] PMD ->81000260 on > node 0 > [0.00] [e2c0-e2df] PMD ->810002A0 on > node 0 > [0.00] [e2e0-e2ff] PMD ->810002E0 on > node 0 > [0.00] [e2000100-e200011f] PMD ->81000320 on > node 0 > [0.00] [e2000120-e200013f] PMD ->81000360 on > node 0 > [0.00] [e2000140-e200015f] PMD ->810003A0 on > node 0 > [
