On Thu, May 25, 2017 at 11:58:25AM -0700, Michel Thierry wrote:
> On 25/05/17 08:31, Daniele Ceraolo Spurio wrote:
> >
> >
> >On 22/05/17 12:56, Michal Wajdeczko wrote:
> >>On Mon, May 22, 2017 at 10:50:28AM -0700, Daniele Ceraolo Spurio wrote:
> >>>We're currently deleting the GuC logs if the FW
On 25/05/17 08:31, Daniele Ceraolo Spurio wrote:
On 22/05/17 12:56, Michal Wajdeczko wrote:
On Mon, May 22, 2017 at 10:50:28AM -0700, Daniele Ceraolo Spurio wrote:
We're currently deleting the GuC logs if the FW fails to load, but those
are still useful to understand why the loading failed.
On 22/05/17 12:56, Michal Wajdeczko wrote:
On Mon, May 22, 2017 at 10:50:28AM -0700, Daniele Ceraolo Spurio wrote:
We're currently deleting the GuC logs if the FW fails to load, but those
are still useful to understand why the loading failed. Keeping the
object around allows us to access them
On Mon, May 22, 2017 at 10:50:28AM -0700, Daniele Ceraolo Spurio wrote:
> We're currently deleting the GuC logs if the FW fails to load, but those
> are still useful to understand why the loading failed. Keeping the
> object around allows us to access them after driver load is completed.
>
> v2:
We're currently deleting the GuC logs if the FW fails to load, but those
are still useful to understand why the loading failed. Keeping the
object around allows us to access them after driver load is completed.
v2: keep the object around instead of using kernel memory (chris)
don't store the