https://bugzilla.novell.com/show_bug.cgi?id=406636
User teheo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=406636#c9
--- Comment #9 from Tejun Heo 2008-08-13 20:50:21 MDT ---
This is super strange. Here's the offending function upto the crashing point.
int ata_std_softreset(struct ata_link *link, unsigned int *classes,
unsigned long deadline)
{
struct ata_port *ap = link->ap;
unsigned int slave_possible = ap->flags & ATA_FLAG_SLAVE_POSS;
unsigned int devmask = 0;
int rc;
u8 err;
DPRINTK("ENTER\n");
if (ata_link_offline(link)) {
classes[0] = ATA_DEV_NONE;
goto out;
}
/* determine if device 0/1 are present */
if (ata_devchk(ap, 0))
devmask |= (1 << 0);
if (slave_possible && ata_devchk(ap, 1))
devmask |= (1 << 1);
/* select device 0 again */
ap->ops->dev_select(ap, 0);
^^^^^^^
Kernel dies while trying to dereference ops from ap.
48 8b 43 08 mov 0x8(%rbx),%rax
%rbx contains the address of ap and the offset of ->ops is 8. According to the
register dump, %rbx is seemingly legit 0xffff81012e67800 far away from the
faulted address 0xd9814f5a. %ebx is also dereferenced earlier in the function
to determine slave_possible (offset 24), so it's highly doubtful the above code
is the actual offender.
The interesting thing is that none of the GPRs contains anything near the fault
address and even if the reported EIP is incorrect for some mysterious reason, I
can't find any instruction which can cause dereference of the faulted address
nearby.
Combined with the reported random behavior on SL103 and other weirdness
including the fact that the OOPS goes away in safe setting, I don't think it's
much lower level problem. Maybe things like dirty SMM trick gone wrong?
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.