[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <47C5FF3B.2000000@shaw.ca>
Date: Wed, 27 Feb 2008 18:24:27 -0600
From: Robert Hancock <hancockr@...w.ca>
To: Kuan Luo <kluo@...dia.com>
Cc: Jeff Garzik <jeff@...zik.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Tejun Heo <htejun@...il.com>, Peer Chen <pchen@...dia.com>,
Allen Martin <AMartin@...dia.com>
Subject: Re: [PATCH] sata_nv: fix nmi intr or system hanging in rhel4u6 adma.
Kuan Luo wrote:
> Jeff wrote:
>> robert worte:
>>> This is basically avoiding switching into register mode,
>> right? I don't
>>> think this is a very good solution as the point of the
>> tf_read function
>>> is that it's supposed to read the taskfile provided by the drive to
>>> diagnose the error, so not doing this isn't a good thing.
>> Agree with this analysis -- if ->tf_read() is being called, then
>> obviously the core wants a current copy of the device's ATA registers.
>>
>> It is not a good solution to simply avoiding returning
>> meaningful data,
>> because -- as Robert notes -- we need tf_read for analysis.
>>
>> Jeff
>>
>
> The driver got one error : "nv_adma_check_cpb: CPB 0, flags=0x11". The
> code entered ata_port_abort -> ata_qc_complete
> -> fill_result_tf->nv_adma_tf_read.
>
> Firstly, nv_adma_register_mode failed, showing the below messages:
> timeout waiting for ADMA IDLE, stat=0x440
> timeout waiting for ADMA LEGACY, stat=0x440
>
> Then enter ata_tf_read function.
> I found the system hung at tf->hob_nsect = ioread8(ioaddr->nsect_addr);
> Sometimes the screen showed "
> CPU0: Machin check Exception 0000000000000004
> Bank 4:b200000000070f0f
> kernel panic -not syncing: CPU Context corrupt.
> "
> If nv_adma_register_mode failed, the reg result should be not
> meaningful.
> I don't know why the systm hung.
By the way, this MCE indicates that the CPU integrated northbridge got a
watchdog error indicating that a bus transaction timed out (presumably
on the HyperTransport link). This likely indicates that the chipset
failed to respond to a CPU read of that register. Obviously this is
something we want to avoid causing..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists