Skip to contentSkip to conversation

2.6.13-mm1: hangs during boot ...

DISCUSSION Reuben Farrelly 3 participants 5 messages Sep 3, 2005 – Sep 5, 2005 2 messages not in the archive SCSI

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

Reuben Farrelly

author
#2 lore raw

Hi Peter,

Quoted 7 lines · Peter Williams
Quoted 6 lines · Len
Quoted 1 line
Quoted 1 line
[  279.662960]  [<c02d5c74>] wait_for_completion+0xa4/0x110

possibly a missing interrupt?

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

CONFIG_ACPI=y

any difference if booted with "acpi=off" or "acpi=noirq"?

Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a "device not ready" message

Are you seeing this "Device not ready" message appear over and over, or just the once?

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.

The SCSI device I have is:

Sep  3 22:14:40 tornado kernel: Vendor: SONY  Model: CD-RW  CRX145S  Rev: 1.0b

As for the inability to log in, this bug may be relevant, given I also had that problem:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166422

There are fixes in the pipeline for util-linux audit interaction in Fedora as well. I know because I reported those too ;)

Quoted 1 line

after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh.

The workaround by enabling audit support, but obviously a better fix is in the pipeline..

I'm surprised more people aren't discovering these 'interactions' due to having audit not turned on. Does everyone build audit into their kernels?

reuben

#3 lore raw
Quoted 17 lines · Reuben Farrelly

Hi Peter,

Quoted 13 lines · Peter Williams
Quoted 11 lines · Len
Quoted 1 line
Quoted 1 line
[  279.662960]  [<c02d5c74>] wait_for_completion+0xa4/0x110

possibly a missing interrupt?

Quoted 1 line

CONFIG_ACPI=y

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

any difference if booted with "acpi=off" or "acpi=noirq"?

Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a "device not ready" message

Are you seeing this "Device not ready" message appear over and over, or just the once?

Just the once.

Quoted 21 lines

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.

The SCSI device I have is:

Sep  3 22:14:40 tornado kernel: Vendor: SONY  Model: CD-RW  CRX145S  Rev: 1.0b

As for the inability to log in, this bug may be relevant, given I also had that problem:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166422

There are fixes in the pipeline for util-linux audit interaction in Fedora as well. I know because I reported those too ;)

Quoted 1 line

after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh.

The workaround by enabling audit support, but obviously a better fix is in the pipeline..

I'm surprised more people aren't discovering these 'interactions' due to having audit not turned on. Does everyone build audit into their kernels?

reuben

Signature · 4 lines
Peter Williams                                   [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
#4 lore raw
Quoted 4 lines · Peter Williams
Quoted 2 lines

Are you seeing this "Device not ready" message appear over and over, or just the once?

Just the once.

OK, I finally have a theory about this. It's the everything goes via bios code. Previously there were several levels at which commands could exit the SCSI stack; now we make everything go via bios, so they all come out at the top.

get_capabilities() in sr.c is sending a TEST_UNIT_READY which will get NOT_READY back. Previously this was completing before it got to scsi_io_completion(); now it doesn't. There must be quite a few cases like this. The best fix is probably to use and respect REQ_QUIET for internally generated commands.

James

#5 lore raw
In reply to Reuben Farrelly
Quoted 3 lines · Reuben Farrelly

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

drivers/scsi/scsi_lib.c +18 -17
@@ -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
author
#6 lore raw

Hi,

Quoted 63 lines · James Bottomley
Quoted 1 line · Reuben Farrelly

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

drivers/scsi/scsi_lib.c +14 -15
@@ -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,

drivers/scsi/scsi_lib.c void scsi_io_completion(struct scsi_cmnd · line 969

Quoted 10 lines
drivers/scsi/scsi_lib.c +4 -2
+				   "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