> -----Original Message----- > From: Hannes Reinecke [mailto:hare@xxxxxxx] > Sent: Wednesday, 01 October, 2014 1:23 AM > To: James Bottomley > Cc: Christoph Hellwig; linux-scsi@xxxxxxxxxxxxxxx; Elliott, Robert (Server > Storage); Hannes Reinecke > Subject: [PATCHv5 00/24] scsi logging update (the boring part) > > This is the next iteration of my scsi logging patchset. > The patchset just contains some logging updates, code > reshuffling and sanity fixes. Nothing major. > > The second part of this patchset (the printk bit) > has been vetoed for the moment, so I'll have to > work on that. But in any case this patchset is > pretty much independent. > > Difference to v4: > - Add 'Reviewed-by' tags from hch where applicable > - Split off the fas216 patch into two different patches > - Added a patch to document scsi_try_to_abort_cmd > > Hannes Reinecke (24): > Remove scsi_cmd_print_sense_hdr() > sd: Remove scsi_print_sense() in sd_done() > aha152x: Debug output update and whitespace cleanup > scsi: introduce sdev_prefix_printk() > scsi: Use sdev as argument for sense code printing > acornscsi: use scsi_print_command() > fas216: Return DID_ERROR for incomplete data transfer > fas216: Update logging messages > 53c700: remove scsi_print_sense() usage > scsi: stop decoding if scsi_normalize_sense() fails > scsi: do not decode sense extras > scsi: use 'bool' as return value for scsi_normalize_sense() > scsi: remove scsi_print_status() > Implement scsi_opcode_sa_name > scsi: merge print_opcode_name() > scsi: consolidate opcode lookup in scsi_opcode_sa_name() > scsi: remove last argument from print_opcode_name() > scsi: Remove scsi_print_command when calling abort > scsi: separate out scsi_(host|driver)byte_string() > sd: Cleanup logging > scsi: simplify scsi_log_(send|completion) > scsi: fixup logging messages in scsi_error.c > scsi: use shost argument in scsi_eh_prt_fail_stats > scsi_error: document scsi_try_to_abort_cmd With this 24-part series applied to 3.17rc7, with the kernel set to print timestamps (e.g., printk.time=y on the kernel command line), the prints still end up trickling out a byte at a time, interleaved from different threads, when the system is overloaded. Maybe that's addressed by the part that is deferred? Example serial log excerpt: [74465.705193] sd 2:0:0:0: [sdr] CDB: [74465.705194] : [74465.705196] 0 [74465.705196] sd 2:0:0:0: [sdr] (null)FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [74465.705197] 00 [74465.705198] : [74465.705198] : [74465.705199] 00 [74465.705200] Read(10) [74465.705201] 28 [74465.705202] f4 [74465.705202] sd 2:0:0:0: [sdr] Sense Key : Hardware Error [current] [74465.705204] b2 [74465.705204] 28 [74465.705205] 28 [74465.705206] 01 [74465.705207] : [74465.705207] 00 [74465.705208] 70 [74465.705209] f8 [74465.705210] sd 2:0:0:0: [sdr] Add. Sense: Logical unit failure [74465.705211] 00 [74465.705211] 00 [74465.705212] 2f [74465.705213] 28 [74465.705214] 00 [74465.705215] 00 [74465.705215] 00 [74465.705217] 00 [74465.705217] sd 2:0:0:0: [sdr] CDB: [74465.705218] 00 [74465.705219] 70 [74465.705219] 00 [74465.705220] 00 [74465.705221] 00 [74465.705221] 00 [74465.705222] 01 [74465.705223] Read(10) [74465.705223] 01 [74465.705224] 00 [74465.705225] 00 [74465.705226] 9c [74465.705227] 08 [74465.705227] 08 [74465.705228] 81 [74465.705229] : [74465.705229] 9d [74465.705230] 00 [74465.705231] 01 [74465.705232] 70 [74465.705232] 00 [74465.705233] 00 [74465.705234] 50 [74465.705234] 28 [74465.705235] e8 [74465.705236] 08 [74465.705237] 9f [74465.705237] 00 [74465.705238] [74465.705238] [74465.705239] 00 [74465.705240] 00 [74465.705240] 00 [74465.705241] 00 [74465.705242] 68 [74465.705243] 00 [74465.705243] 00 [74465.705244] 00 [74465.705245] 00 [74465.705245] [74465.705246] 00 [74465.705247] 08 [74465.705247] 08 [74465.705248] 01 [74465.705249] 08 [74465.705250] 00 [74465.705250] 00 [74465.705251] 00 [74465.705253] 33 [74465.705253] sd 2:0:0:0: [sdr] Done: SUCCESS Result: hostbyte=DID_TARGET_FAILURE driverbyte=DRIVER_OK -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
