https://bugzilla.kernel.org/show_bug.cgi?id=81861
--- Comment #12 from Alan <a...@lxorguk.ukuu.org.uk> ---
0xffffffffa01c481e <+1838>: mov 0x254(%rbx),%ecx
is loading an offset from something. It can't be line 471.
It could be line 472, or could be 468. but the offset looks way too big to be
either unless its been optimised somewhat. It's not always entirely accurate.
At this point what might be useful is to add lines between then and rebuild ...
ie
printk("[");
467 slot = &mvi->slot_info[tag];
printk("%d ", tag);
468 slot->tx = mvi->tx_prod;
printk("%p ", slot);
469 del_q = TXQ_MODE_I | tag |
470 (TXQ_CMD_STP << TXQ_CMD_SHIFT) |
471 (MVS_PHY_ID << TXQ_PHY_SHIFT) |
472 (mvi_dev->taskfileset << TXQ_SRS_SHIFT);
printk("%d", mvi->tx_prod]);
473 mvi->tx[mvi->tx_prod] = cpu_to_le32(del_q);
printk("]\n");
and try again. When it dies just before the oops you should have lines of the
form
[num num num]
the final one of which is incomplete. Where it ends tells us where it died and
the values may even give
us a guess at why. If the final [ .. ] sequence is complete then it crashed
somewhere else in the routine and gdb is confused.
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
