[Bug 81861] Oops by mvsas v0.8.16: sas: ataX: end_device-Y:0:Z: dev error handler -> general protection fault, RIP: mvs_task_prep_ata+0x80/0x3a0

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=81861

--- Comment #12 from Alan <alan@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.