I am writing a polled mode Xen AHCI driver to collect some minimal information after a system crash. As dom0 would have initialized and used the HBA before we enter the crashing code path, I am not doing any kind of device initialization within the Xen AHCI driver. I am also not setting up interrupts etc. as the driver is used in polled mode. I simply map the abar and other memory regions associated with the device that dom0 has already setup and write to it/read from it as needed. After a crash, within the Xen AHCI driver I am able to get to the pci space for the device, get valid HBA registers, mapping etc. works but the HBA does not respond back after I issue a command for execution. In specific, after I set the port x command issue register (pxci) for the free slot, that slot is not getting cleared as it should after a command execution. As an experiment to see if anything at all works with respect to setting/resetting port registers, I simply decided to stop/start the HBA command engine by setting the ST bit in the command register (PxCMD) to 0 and then checking if CR, FR bit etc. in PxCMD are reset by HBA after a ST reset but they remain set. I am hoping someone with AHCI experience might be able to shed some light as to why the HBA is not responding as it should. Thanks. Kamala _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Nov 22, 2010 at 09:51:26AM -0500, Kamala Narasimhan wrote:> I am writing a polled mode Xen AHCI driver to collect some minimalWhat is a ''Xen AHCI'' driver?> information after a system crash. As dom0 would have initialized and > used the HBA before we enter the crashing code path, I am not doing > any kind of device initialization within the Xen AHCI driver. I am > also not setting up interrupts etc. as the driver is used in polled > mode. I simply map the abar and other memory regions associated with > the device that dom0 has already setup and write to it/read from it as > needed. > > After a crash, within the Xen AHCI driver I am able to get to the pci > space for the device, get valid HBA registers, mapping etc. works but > the HBA does not respond back after I issue a command for execution. > In specific, after I set the port x command issue register (pxci) for > the free slot, that slot is not getting cleared as it should after a > command execution. > > As an experiment to see if anything at all works with respect to > setting/resetting port registers, I simply decided to stop/start the > HBA command engine by setting the ST bit in the command register > (PxCMD) to 0 and then checking if CR, FR bit etc. in PxCMD are reset > by HBA after a ST reset but they remain set. > > I am hoping someone with AHCI experience might be able to shed some > light as to why the HBA is not responding as it should. Thanks. > > Kamala > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
It is a bare minimal driver in Xen (under development) which is invoked upon a system crash to persist crash dump data to disk by issuing commands through the pre-programmed HBA registers. Unlike a full fledged AHCI driver, we do not initialize the very many memory regions used to communicate between the device and the system software as in our case the dom0 would have already done all that. We simply map those memory regions that dom0 has already setup and issue commands to copy data to disk. And that issuing of command part is not succeeding as I would expect. Kamala On Mon, Nov 22, 2010 at 11:42 AM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> On Mon, Nov 22, 2010 at 09:51:26AM -0500, Kamala Narasimhan wrote: >> I am writing a polled mode Xen AHCI driver to collect some minimal > > What is a ''Xen AHCI'' driver? > >> information after a system crash. As dom0 would have initialized and >> used the HBA before we enter the crashing code path, I am not doing >> any kind of device initialization within the Xen AHCI driver. I am >> also not setting up interrupts etc. as the driver is used in polled >> mode. I simply map the abar and other memory regions associated with >> the device that dom0 has already setup and write to it/read from it as >> needed. >> >> After a crash, within the Xen AHCI driver I am able to get to the pci >> space for the device, get valid HBA registers, mapping etc. works but >> the HBA does not respond back after I issue a command for execution. >> In specific, after I set the port x command issue register (pxci) for >> the free slot, that slot is not getting cleared as it should after a >> command execution. >> >> As an experiment to see if anything at all works with respect to >> setting/resetting port registers, I simply decided to stop/start the >> HBA command engine by setting the ST bit in the command register >> (PxCMD) to 0 and then checking if CR, FR bit etc. in PxCMD are reset >> by HBA after a ST reset but they remain set. >> >> I am hoping someone with AHCI experience might be able to shed some >> light as to why the HBA is not responding as it should. Thanks. >> >> Kamala >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Nov 22, 2010 at 12:07:58PM -0500, Kamala Narasimhan wrote:> It is a bare minimal driver in Xen (under development) which is > invoked upon a system crash to persist crash dump data to disk by > issuing commands through the pre-programmed HBA registers. Unlike a > full fledged AHCI driver, we do not initialize the very many memory > regions used to communicate between the device and the system software > as in our case the dom0 would have already done all that. We simply > map those memory regions that dom0 has already setup and issue > commands to copy data to disk. And that issuing of command part is > not succeeding as I would expect.I think you are better of asking on the ahci-devel, and as well folks on the kdump mailing list as they had to wrestle with these kinds of issues already. Thought .. why not use the kdump kernel?> > Kamala > > On Mon, Nov 22, 2010 at 11:42 AM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > > On Mon, Nov 22, 2010 at 09:51:26AM -0500, Kamala Narasimhan wrote: > >> I am writing a polled mode Xen AHCI driver to collect some minimal > > > > What is a ''Xen AHCI'' driver? > > > >> information after a system crash. As dom0 would have initialized and > >> used the HBA before we enter the crashing code path, I am not doing > >> any kind of device initialization within the Xen AHCI driver. I am > >> also not setting up interrupts etc. as the driver is used in polled > >> mode. I simply map the abar and other memory regions associated with > >> the device that dom0 has already setup and write to it/read from it as > >> needed. > >> > >> After a crash, within the Xen AHCI driver I am able to get to the pci > >> space for the device, get valid HBA registers, mapping etc. works but > >> the HBA does not respond back after I issue a command for execution. > >> In specific, after I set the port x command issue register (pxci) for > >> the free slot, that slot is not getting cleared as it should after a > >> command execution. > >> > >> As an experiment to see if anything at all works with respect to > >> setting/resetting port registers, I simply decided to stop/start the > >> HBA command engine by setting the ST bit in the command register > >> (PxCMD) to 0 and then checking if CR, FR bit etc. in PxCMD are reset > >> by HBA after a ST reset but they remain set. > >> > >> I am hoping someone with AHCI experience might be able to shed some > >> light as to why the HBA is not responding as it should. Thanks. > >> > >> Kamala > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xensource.com > >> http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I think you are better of asking on the ahci-devel, and as well folks > on the kdump mailing list as they had to wrestle with these kinds of > issues already.Is there a ahci-devel list I am unaware of? In the mean time, I managed to pepper some of the Linux storage list with the same question. No dice yet.> > Thought .. why not use the kdump kernel?Per folks more knowledgeable in kdump/kexec etc., here are some advantages - 1) This approach doesn''t have the same resource constraint as that of kdump approach like setting aside memory. 2) This would be more reliable on systems that uses AHCI. Also, in the long run this component could be turned into one of the many lowest level pluggable storage interface for crash dump persistence and other components could be built on top to collect lot more useful information. Kamala _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel