https://bugzilla.kernel.org/show_bug.cgi?id=81861 --- Comment #12 from Alan <alan@xxxxxxxxxxxxxxxxxxx> --- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
