I hate replying to my own mail, but seeing as nobody else is... :)
Peter Rival wrote:
<snip>
> General thought so far:
>
> It appears that somehow the scsi command pointed to by Cmnd (as set in
> qlogicisp.c:1031) is NULL at some point in the loop, and we don't ever check
> for that occurrence. My question is, is that a valid state for the command
> slot, and if so, shouldn't we just continue on to the next one? Essentially,
>
> what we have is this:
>
> while (out_ptr != in_ptr) {
> u_int cmd_slot;
>
> sts = (struct Status_Entry *) &hostdata->res_cpu[out_ptr];
> out_ptr = (out_ptr + 1) & RES_QUEUE_LEN);
>
> cmd_slot = sts_handle;
> Cmnd = hostdata->cmd_slots[cmd_slot];
> <should we check that Cmnd is not null here, and if it is just
> continue?>
>
If I add just a simple
if (!Cmnd)
continue;
there are no more oopses. However, instead of oopses we now get SCSI command
timeouts.
>From a little more debugging, it appears that somewhere between writing out the
commands (in isp1020_queuecommand()) and taking them off of the cmd_slots array
(in isp1020_intr_handler()) we're moving a pointer to somewhere it doesn't
belong (my current guess is one beyond the end of the queue) and therefore
getting NULL Scsi_Cmnd pointers. I'll keep digging...maybe this knocks some
dust of someone's recollection...
- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:20 EST