[ofw] Support boot device in IB stack?
Leonid Keller
leonid at mellanox.co.il
Thu Feb 12 00:23:29 PST 2009
> In order to support crashdump, the IB related code must be able to run
at IRQL 31.
Could you explain why do you think so ?
As far as I know, at IRQL 31 all interrupts/dpc/threads are blocked.
When a crash happens, the only task of OS is to create a dump, while
preserving the current state.
So it looks strange to me, that OS will allow to any driver to continue
working after a crash.
As to creating a crash dump at IRQL 31, it looks a bit strange to me.
OS have to write the dump to HD, which presumes the work with disk
driver at IRQL 2 at worst.
Am I missing something ?
> -----Original Message-----
> From: ofw-bounces at lists.openfabrics.org
> [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of James Yang
> Sent: Thursday, February 12, 2009 1:59 AM
> To: Tzachi Dar; ofw at lists.openfabrics.org
> Subject: RE: [ofw] Support boot device in IB stack?
>
> Hi Tzachi,
>
> The boot should be OK if #1 and #3 are resolved. In order to
> support crashdump, the IB related code must be able to run at
> IRQL 31. It will be good to know what functions are OK to run
> and what are not. By the way, according to DDK, "Callers of
> KeAcquireSpinLock must be running at IRQL <= DISPATCH_LEVEL."
>
> There is no formal document on crashdump. The most important
> thing is that it's running at IRQL 31, and multiple threading
> may not work at this time.
>
> iSCSI is one of the solutions, but we also have to support
> vhba directly. And in order to get MS WHQL for vhba, we must
> support crashdump. Do you get any request to support
> crashdump on iSCSI/ipoib?
>
> Thanks,
> James
>
> -----Original Message-----
> From: Tzachi Dar [mailto:tzachid at mellanox.co.il]
> Sent: Wednesday, February 11, 2009 12:55 AM
> To: James Yang; ofw at lists.openfabrics.org
> Subject: RE: [ofw] Support boot device in IB stack?
>
> Hi James,
>
> As for 1,3 this are technical changes that can easily be done.
>
> Issue #2 seems much more problematic to me.
> First I must say that I haven't studied the topic thoroughly,
> so I might be getting a wrong impression of the entire issue.
> One more thing to start with, is that I'm not sure that this
> request is a must. What I mean by that is that booting will
> take place just fine.
> The one thing that will not work is creating a crash dump file later.
>
> In any case, spinlocks don't really have a problem with
> higher IRQL (the way I understand it), but many other
> commands have. So if the code is only trying to send/receive
> data with qps that are open I guess that things should work.
> Trying to open new QPs will not work (we have to wait).
> Please also note that there are only about 5 commands that
> can be called from IRQL>DISPATCH_LEVEL.
>
> Can you please send a reference to the document that says
> what are the demands after the system has crashed?
>
> Another question is this, will booting using iSCSI be a
> better option for you? (not that it was done using ipoib).
>
> Thanks
> Tzachi
>
> > -----Original Message-----
> > From: ofw-bounces at lists.openfabrics.org
> > [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of James Yang
> > Sent: Tuesday, February 10, 2009 11:31 PM
> > To: ofw at lists.openfabrics.org
> > Subject: [ofw] Support boot device in IB stack?
> >
> > Hi,
> >
> > We would like to support boot device especially SAN boot
> over IB. So
> > far I can see the following issues in current code:
> > 1) Many functions are page-able. If these functions are running at
> > boot or shut down time, the disk may not be ready, the paging won't
> > work.
> > 2) Spinlock may not work for crashdump, whose
> > IRQL>DISPATCH_LEVEL. Any other functions need to be changed
> > when IRQL>DISPATCH_LEVEL?
> > 3) All related drivers should be boot start driver.
> >
> > Are there any other potential problem? Is there any plan to support
> > SAN boot?
> >
> > Please advice.
> >
> > Thanks,
> > James
> >
> >
> >
> >
> >
> > _______________________________________________
> > ofw mailing list
> > ofw at lists.openfabrics.org
> > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
> >
>
> _______________________________________________
> ofw mailing list
> ofw at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>
More information about the ofw
mailing list