LinuxLists.cc - 2.6.13-mm1: hangs during boot ...

2005-09-02 12:54:41

Subject: 2.6.13-mm1: hangs during boot ...

... at the the point indicated by the following output:

[ 8.197224] Freeing unused kernel memory: 288k freed
[ 8.428217] SCSI subsystem initialized
[ 8.510376] sym0: <810a> rev 0x23 at pci 0000:00:08.0 irq 11
[ 8.587731] sym0: No NVRAM, ID 7, Fast-10, SE, parity checking
[ 8.671531] sym0: SCSI BUS has been reset.
[ 8.725530] scsi0 : sym-2.2.1
[ 17.256480] 0:0:0:0: ABORT operation started.
[ 22.323534] 0:0:0:0: ABORT operation timed-out.
[ 22.384348] 0:0:0:0: DEVICE RESET operation started.
[ 27.458702] 0:0:0:0: DEVICE RESET operation timed-out.
[ 27.527544] 0:0:0:0: BUS RESET operation started.
[ 32.533775] 0:0:0:0: BUS RESET operation timed-out.
[ 32.599173] 0:0:0:0: HOST RESET operation started.
[ 32.669659] sym0: SCSI BUS has been reset.

Peter
--
Peter Williams [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce

2005-09-02 20:13:06

by Andrew Morton

[permalink] [raw]

Subject: Re: 2.6.13-mm1: hangs during boot ...

Peter Williams <[email protected]> wrote:
>
> ... at the the point indicated by the following output:
>
> [ 8.197224] Freeing unused kernel memory: 288k freed
> [ 8.428217] SCSI subsystem initialized
> [ 8.510376] sym0: <810a> rev 0x23 at pci 0000:00:08.0 irq 11
> [ 8.587731] sym0: No NVRAM, ID 7, Fast-10, SE, parity checking
> [ 8.671531] sym0: SCSI BUS has been reset.
> [ 8.725530] scsi0 : sym-2.2.1
> [ 17.256480] 0:0:0:0: ABORT operation started.
> [ 22.323534] 0:0:0:0: ABORT operation timed-out.
> [ 22.384348] 0:0:0:0: DEVICE RESET operation started.
> [ 27.458702] 0:0:0:0: DEVICE RESET operation timed-out.
> [ 27.527544] 0:0:0:0: BUS RESET operation started.
> [ 32.533775] 0:0:0:0: BUS RESET operation timed-out.
> [ 32.599173] 0:0:0:0: HOST RESET operation started.
> [ 32.669659] sym0: SCSI BUS has been reset.
>

Is there no response from sysrq-T?

Maybe adding initcall_debug to the boot command line will show extra info?

The .config would be useful, thanks.

2005-09-03 03:51:39

On Sun, 2005-09-04 at 01:24 +1200, Reuben Farrelly wrote:
> I am seeing it fill up my messages log as it is logging 1 or so messages each
> minute. I've emailed the SCSI maintainer James Bottomley twice about it but
> had no response either time.

OK, can you try this ... it should confirm the theory if the messages go
away.

Thanks,

James

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -315,7 +315,7 @@ int scsi_execute(struct scsi_device *sde
req->sense = sense;
req->sense_len = 0;
req->timeout = timeout;
- req->flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL;
+ req->flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL | REQ_QUIET;

/*
* head injection *required* here otherwise quiesce won't work
@@ -927,17 +927,20 @@ void scsi_io_completion(struct scsi_cmnd
scsi_requeue_command(q, cmd);
return;
}
- printk(KERN_INFO "Device %s not ready.\n",
- req->rq_disk ? req->rq_disk->disk_name : "");
+ if (!(req->flags & REQ_QUIET))
+ dev_printk(KERN_INFO,
+ &cmd->device->sdev_gendev,
+ "Device not ready.\n");
cmd = scsi_end_request(cmd, 0, this_count, 1);
return;
case VOLUME_OVERFLOW:
- printk(KERN_INFO "Volume overflow <%d %d %d %d> CDB: ",
- cmd->device->host->host_no,
- (int)cmd->device->channel,
- (int)cmd->device->id, (int)cmd->device->lun);
- __scsi_print_command(cmd->data_cmnd);
- scsi_print_sense("", cmd);
+ if (!(req->flags & REQ_QUIET)) {
+ dev_printk(KERN_INFO,
+ &cmd->device->sdev_gendev,
+ "Volume overflow, CDB: ");
+ __scsi_print_command(cmd->data_cmnd);
+ scsi_print_sense("", cmd);
+ }
cmd = scsi_end_request(cmd, 0, block_bytes, 1);
return;
default:
@@ -954,15 +957,13 @@ void scsi_io_completion(struct scsi_cmnd
return;
}
if (result) {
- if (!(req->flags & REQ_SPECIAL))
- printk(KERN_INFO "SCSI error : <%d %d %d %d> return code "
- "= 0x%x\n", cmd->device->host->host_no,
- cmd->device->channel,
- cmd->device->id,
- cmd->device->lun, result);
+ if (!(req->flags & REQ_QUIET)) {
+ dev_printk(KERN_INFO, &cmd->device->sdev_gendev,
+ "SCSI error: return code = 0x%x\n", result);

- if (driver_byte(result) & DRIVER_SENSE)
- scsi_print_sense("", cmd);
+ if (driver_byte(result) & DRIVER_SENSE)
+ scsi_print_sense("", cmd);
+ }
/*
* Mark a single buffer as not uptodate. Queue the remainder.
* We sometimes get this cruft in the event that a medium error

2005-09-05 08:37:56

by Reuben Farrelly

[permalink] [raw]

Subject: Re: 2.6.13-mm1: hangs during boot ...

Hi,

On 5/09/2005 4:32 a.m., James Bottomley wrote:
> On Sun, 2005-09-04 at 01:24 +1200, Reuben Farrelly wrote:
>> I am seeing it fill up my messages log as it is logging 1 or so messages each
>> minute. I've emailed the SCSI maintainer James Bottomley twice about it but
>> had no response either time.
>
> OK, can you try this ... it should confirm the theory if the messages go
> away.
>
> Thanks,
>
> James
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -315,7 +315,7 @@ int scsi_execute(struct scsi_device *sde
> req->sense = sense;
> req->sense_len = 0;
> req->timeout = timeout;
> - req->flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL;
> + req->flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL | REQ_QUIET;
>
> /*
> * head injection *required* here otherwise quiesce won't work
> @@ -927,17 +927,20 @@ void scsi_io_completion(struct scsi_cmnd
> scsi_requeue_command(q, cmd);
> return;
> }
> - printk(KERN_INFO "Device %s not ready.\n",
> - req->rq_disk ? req->rq_disk->disk_name : "");
> + if (!(req->flags & REQ_QUIET))
> + dev_printk(KERN_INFO,
> + &cmd->device->sdev_gendev,
> + "Device not ready.\n");
> cmd = scsi_end_request(cmd, 0, this_count, 1);
> return;
> case VOLUME_OVERFLOW:
> - printk(KERN_INFO "Volume overflow <%d %d %d %d> CDB: ",
> - cmd->device->host->host_no,
> - (int)cmd->device->channel,
> - (int)cmd->device->id, (int)cmd->device->lun);
> - __scsi_print_command(cmd->data_cmnd);
> - scsi_print_sense("", cmd);
> + if (!(req->flags & REQ_QUIET)) {
> + dev_printk(KERN_INFO,
> + &cmd->device->sdev_gendev,
> + "Volume overflow, CDB: ");
> + __scsi_print_command(cmd->data_cmnd);
> + scsi_print_sense("", cmd);
> + }
> cmd = scsi_end_request(cmd, 0, block_bytes, 1);
> return;
> default:
> @@ -954,15 +957,13 @@ void scsi_io_completion(struct scsi_cmnd
> return;
> }
> if (result) {
> - if (!(req->flags & REQ_SPECIAL))
> - printk(KERN_INFO "SCSI error : <%d %d %d %d> return code "
> - "= 0x%x\n", cmd->device->host->host_no,
> - cmd->device->channel,
> - cmd->device->id,
> - cmd->device->lun, result);
> + if (!(req->flags & REQ_QUIET)) {
> + dev_printk(KERN_INFO, &cmd->device->sdev_gendev,
> + "SCSI error: return code = 0x%x\n", result);
>
> - if (driver_byte(result) & DRIVER_SENSE)
> - scsi_print_sense("", cmd);
> + if (driver_byte(result) & DRIVER_SENSE)
> + scsi_print_sense("", cmd);
> + }
> /*
> * Mark a single buffer as not uptodate. Queue the remainder.
> * We sometimes get this cruft in the event that a medium error

This patch fixes it, and there was no message during boot about not being
ready, nor after the machine had fully booted. Great ;-)

However, I did get an oops when warm booting the kernel, I suspect this may be
the oops that I get every now and then when warm rebooting, with no real
pattern, and possibly isn't related to the patch. As my serial console wasn't
set up at the time, I took a photo instead, at
http://www.reub.net/kernel/scsi-oops.jpg

Thanks
reuben