On Wed, Jul 23, 2014 at 08:11:33AM -0700, Randy Dunlap wrote: > On 07/23/2014 07:41 AM, scame...@beardog.cce.hp.com wrote: > > On Wed, Jul 23, 2014 at 02:15:29PM +0000, Benesh, Scott wrote: > >> From: Nick Krause [mailto:xerofo...@gmail.com] > >> Sent: Saturday, July 19, 2014 11:51 PM > >> To: mike.mil...@hp.com > >> Cc: ISS StorageDev; linux-kernel@vger.kernel.org > >> Subject: cciss_scsi.c: Fix me > >> > >> Hey Mike, > >> I seem to be hitting a fix me message in this file in > >> function,cciss_scsi_queue_command_lck. > >> I am wondering what you want to do when C is Null? > >> Cheers Nick > > > > Hi Nick, > > > > Mike's moved on from HP to Canonical now. > > > > It looks like you're running out of commands for tape drives, > > which shouldn't ever happen, since we set > > > > sh->can_queue = cciss_tape_cmds; > > > > and we allocate that many commands + 2.... > > > > scsi_cmd_stack_setup(ctlr_info_t *h, struct cciss_scsi_adapter_data_t *sa) > > { > > int i; > > struct cciss_scsi_cmd_stack_t *stk; > > size_t size; > > > > stk = &sa->cmd_stack; > > stk->nelems = cciss_tape_cmds + 2; > > > > You're apparently hitting this: > > > > spin_lock_irqsave(&h->lock, flags); > > c = scsi_cmd_alloc(h); > > spin_unlock_irqrestore(&h->lock, flags); > > if (c == NULL) { /* trouble... */ > > dev_warn(&h->pdev->dev, "scsi_cmd_alloc returned NULL!\n"); > > /* FIXME: next 3 lines are -> BAD! <- */ > > cmd->result = DID_NO_CONNECT << 16; > > done(cmd); > > return 0; > > } > > > > which means that scsi_cmd_alloc returned NULL, which only happens > > if the thing has run out of commands. > > > > It's not obvious to me how it can be that it runs out of commands. > > Maybe we're losing them somehow, but this has not previously been > > a problem that I'm aware of. > > > > Are you able to reproduce the problem? > > > > What's going on on the system when it happens? > > > > putting in a dump_stack(); near that FIXME might give a clue. > > > > Which kernel are you running? > > > > -- steve > > Hi Steve, > > You apparently have not been following the Nick saga. > > Nick is using cscope to search for FIXMEs in the kernel source tree and > then trying to generate patches to remove or 'fix' them. > > He is not hitting a kernel oops or panic or bug.
Ah, ok, thanks. That explains it, because I was pretty sure that code is a "this will never happen" case. -- steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
