Il 03/07/2014 21:09, Jesse Barnes ha scritto:
Practically speaking, we could probably assume specific CPU/PCH combos,
as I don't think they're generally mixed across generations, though SNB
and IVB did have compatible sockets, so there is the possibility of
mixing CPT and PPT PCHs, but those are
At Fri, 4 Jul 2014 10:00:37 +0800,
mengdong@intel.com wrote:
>
> From: Jani Nikula
>
> For Haswell and Broadwell, if the display power well has been disabled,
> the display audio controller divider values EM4 M VALUE and EM5 N VALUE
> will have been lost. The CDCLK frequency is required for
From: Jani Nikula
For Haswell and Broadwell, if the display power well has been disabled,
the display audio controller divider values EM4 M VALUE and EM5 N VALUE
will have been lost. The CDCLK frequency is required for reprogramming them
to generate 24MHz HD-A link BCLK. So provide a private inte
The Acer C720 and C720P Chromebooks (with Celeron 2955U CPU) have a
controllable backlight although their VBT reports otherwise. Apply quirk
to ignore the backlight presence check during backlight setup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813
Tested-by: James Duley
Tested-by
The Toshiba CB35 Chromebook (with Celeron 2955U CPU) has a controllable
backlight although its VBT reports otherwise. Apply quirk to ignore the
backlight presence check during backlight setup.
Patch tested by author on Toshiba CB35.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813
Sig
commit c675949ec58ca50d5a3ae3c757892f1560f6e896
drm/i915: do not setup backlight if not available according to VBT
caused a regression on machines with a misconfigured VBT. Add a quirk to
assert the presence of a controllable backlight. Use it to ignore the VBT
backlight presence check durin
Submitted with git to correct whitespace problems.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 07/02/2014 07:40 AM, Paulo Zanoni wrote:
2014-07-02 5:35 GMT-03:00 Jani Nikula :
From: Clint Taylor
The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces a delay
for warm reboots to the T12 panel timing as de
This is a spec requirement for all rings.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_context.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5b4a9a0..1ac648f 100644
--- a/drivers/
Originally the thought for the assertion was that if there are no real
VMAs (died during execbuf), or there is only 1 VMA, but the VMA is on
the active list, it's a bug. The former case is pretty obvious. The
later case simply meant to assert the context unref/object retire
interactions were workin
Damien,
We run intel-gpu-tool in VMware esx console. We didn't port display part of
intel gpu driver to esx, so we don't need any display tests at all.
If you could provide us a solution to run intel gpu tools without cairo, that
would be great.
Thanks
Ying
__
Thanks
Please just ignore this one for now. It will be removed on next round.
On Thu, Jul 3, 2014 at 5:38 PM, Ben Widawsky
wrote:
> On Thu, Jul 03, 2014 at 05:33:05PM -0400, Rodrigo Vivi wrote:
> > From: Ben Widawsky
> >
> > The PDPs seem to get screwed up otherwise, specifically PDP0. I am n
On Thu, Jul 03, 2014 at 05:33:05PM -0400, Rodrigo Vivi wrote:
> From: Ben Widawsky
>
> The PDPs seem to get screwed up otherwise, specifically PDP0. I am not
> really clear why this is required, it just works with full PPGTT.
>
> v2: Only do it for gen8, to limit regression potential
>
> v3: Fi
From: Deepak S
With RC6 enabled, BYT has an HW issue in determining the right
Gfx busyness.
WA for Turbo + RC6: Use SW based Gfx busy-ness detection to decide
on increasing/decreasing the freq. This logic will monitor C0
counters of render/media power-wells over EI period and takes
necessary acti
From: Chris Wilson
On g33, the documentation states
"HWS_PGA:
Format = Bits 28:12 of graphics memory address (bits 31:29 MBZ)."
which translates to that the address of the HWS must be below 256MiB,
which is conveniently the mappable aperture.
This also appears to be true (but not documented a
From: Ville Syrjälä
If the object is already UC leave it as UC instead of automagically
promoting it to WT in i915_gem_object_pin_to_display_plane() when
the hardware is WT capable.
Supposedly the user wanted UC for a reason, so let's respect that.
Signed-off-by: Ville Syrjälä
Signed-off-by: R
From: Clint Taylor
The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces a delay
for warm reboots to the T12 panel timing as defined in the VBT table for
the connected panel.
Ver2: removed redundant pr_crit(), com
From: Chris Wilson
In the move over to use BIOS connector configs, we lost the ability to
force a specific set of connectors on or off. Try to remedy that by
dropping back to the old behavior if we detect a hard coded connector
config that tries to enable a connector (disabling is easy!).
Based
From: Ben Widawsky
The PDPs seem to get screwed up otherwise, specifically PDP0. I am not
really clear why this is required, it just works with full PPGTT.
v2: Only do it for gen8, to limit regression potential
v3: Fix the bugzilla links
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=7
From: Vandana Kannan
Added a property to enable user space to set aspect ratio for HDMI displays.
If there is no user specified value, then PAR_NONE/Automatic option is set
by default. User can select aspect ratio 4:3 or 16:9. The aspect ratio
selected by user would come into effect with a mode s
From: Chris Wilson
If we try to execute on a known ring, but it has failed to be
initialised correctly, report that the GPU is hung rather than the
command invalid. This leaves us reporting EINVAL only if the user
requests execution on a ring that is not supported by the device.
This should prev
From: Deepak S
We need do forcewake before Disabling RC6, This is what the BIOS
expects while going into suspend.
v2: updated commit message. (Daniel)
Reviewer: Paulo Zanoni
Cc: Paulo Zanoni
Signed-off-by: Deepak S
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
From: Ben Widawsky
Cc: Kenneth Graunke
Signed-off-by: Ben Widawsky
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
It was 4 rounds out of date what made it hard to get old patches. However
Daniel and Jani didn't leave
many patches behind.
0 on Apr 4 - Apr 16
1 on Apr 16 - May 6
2 on M
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
It was 4 rounds out of date what made it hard to get old patches. However
Daniel and Jani didn't leave
many patches behind.
0 on Apr 4 - Apr 16
1 on Apr 16 - May 6
2 on M
On Thu, Jul 03, 2014 at 10:10:48AM -0700, Ben Widawsky wrote:
> On Thu, Jul 03, 2014 at 08:17:32AM +0100, Damien Lespiau wrote:
> > On Wed, Jul 02, 2014 at 02:19:42PM +0100, Rutkowski, Adam J wrote:
> > > Having said all this, how about restoring the pin_ioctl? At least for
> > > some time? We do h
On Thu, 03 Jul 2014, Clint Taylor wrote:
> On 07/02/2014 01:35 AM, Jani Nikula wrote:
>> From: Clint Taylor
>>
>> The panel power sequencer on vlv doesn't appear to accept changes to its
>> T12 power down duration during warm reboots. This change forces a delay
>> for warm reboots to the T12 pane
On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> On Thu, 3 Jul 2014 14:26:12 -0400
> Konrad Rzeszutek Wilk wrote:
>
> > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, J
On Thu, 3 Jul 2014 14:26:12 -0400
Konrad Rzeszutek Wilk wrote:
> On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > Il 02/07/201
On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > >With this long thread I
On 07/02/2014 01:35 AM, Jani Nikula wrote:
From: Clint Taylor
The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces a delay
for warm reboots to the T12 panel timing as defined in the VBT table for
the connected p
On Thu, Jul 03, 2014 at 08:17:32AM +0100, Damien Lespiau wrote:
> On Wed, Jul 02, 2014 at 02:19:42PM +0100, Rutkowski, Adam J wrote:
> > Having said all this, how about restoring the pin_ioctl? At least for
> > some time? We do have a use case and moving to other - better -
> > solution would take
On Thu, 3 Jul 2014 16:59:17 +0100
Chris Wilson wrote:
> On Thu, Jul 03, 2014 at 08:49:22AM -0700, Jesse Barnes wrote:
> > On Thu, 3 Jul 2014 15:29:26 +0100
> > Chris Wilson wrote:
> >
> > > Baytrail uses the RPS wait-boosting mechanism of Sandybridge+ but also has
> > > a very lax downclocking
On Thu, 3 Jul 2014 16:51:11 +0100
Chris Wilson wrote:
> On Thu, Jul 03, 2014 at 08:44:20AM -0700, Jesse Barnes wrote:
> > On Thu, 3 Jul 2014 08:09:01 +0100
> > Chris Wilson wrote:
> >
> > > Since we rely on hangcheck to wait up and kick us out of an indefinite
> > > wait should the GPU ever st
On Thu, Jul 03, 2014 at 08:49:22AM -0700, Jesse Barnes wrote:
> On Thu, 3 Jul 2014 15:29:26 +0100
> Chris Wilson wrote:
>
> > Baytrail uses the RPS wait-boosting mechanism of Sandybridge+ but also has
> > a very lax downclocking strategy (upclock if more than 90% busy over 76ms,
> > downclock if
On Thu, Jul 03, 2014 at 08:44:20AM -0700, Jesse Barnes wrote:
> On Thu, 3 Jul 2014 08:09:01 +0100
> Chris Wilson wrote:
>
> > Since we rely on hangcheck to wait up and kick us out of an indefinite
> > wait should the GPU ever stop functioning, it appears sensible that we
> > should check that ha
On Thu, 3 Jul 2014 15:29:26 +0100
Chris Wilson wrote:
> Baytrail uses the RPS wait-boosting mechanism of Sandybridge+ but also has
> a very lax downclocking strategy (upclock if more than 90% busy over 76ms,
> downclock if less than 70% busy over 450ms). This causes Baytrail to use
> maximum clo
On Thu, 3 Jul 2014 08:09:01 +0100
Chris Wilson wrote:
> Since we rely on hangcheck to wait up and kick us out of an indefinite
> wait should the GPU ever stop functioning, it appears sensible that we
> should check that hangcheck is indeed active before starting that wait.
> This just prevents a
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of oscar.ma...@intel.com
> Sent: Thursday, July 03, 2014 4:28 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 4/8] drm/i915: Add kerneldoc comments to the
> intel_conte
From: Oscar Mateo
A bit of background on the context elements.
Cc: Jesse Barnes
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1cebefc..
From: Oscar Mateo
This is preparatory work for Execlists: we plan to use it later to
allocate our own context objects (since Logical Ring Contexts do
not have the same kind of backing objects).
No functional changes.
Reviewed-by: Jesse Barnes
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i9
From: Oscar Mateo
This is an Execlists preparatory patch, since they make context ID become an
overloaded term:
- In the software, it was used to distinguish which context userspace was
trying to use.
- In the BSpec, the term is used to describe the 20-bits long field the
hardware uses to it
From: Oscar Mateo
So that we isolate the legacy ringbuffer submission mechanism, which becomes
a good candidate to be abstracted away. This is prep-work for Execlists (which
will its own workload submission mechanism).
No functional changes.
Reviewed-by: Jesse Barnes
Signed-off-by: Oscar Mateo
From: Oscar Mateo
More prep work: with Execlists, we are going to start creating a lot
of extra ringbuffers soon, so these functions are handy.
No functional changes.
v2: rename allocate/destroy_ring_buffer to alloc/destroy_ringbuffer_obj
because the name is more meaningful and to mirror a simi
From: Oscar Mateo
It's simple enough that it doesn't need to know anything about the
engine.
Trivial change.
Reviewed-by: Jesse Barnes
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/driv
From: Oscar Mateo
We have already advanced that Logical Ring Contexts have their own kind
of backing objects, but everything will be better explained in the Execlists
series. For now, suffice it to say that the current backing object is only
ever used with the render ring, so we're making this fa
From: Oscar Mateo
Again, it's low-level enough to simply take a ringbuf and nothing
else.
Trivial change.
Reviewed-by: Jesse Barnes
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++--
2 files changed, 4 insertions
> -Original Message-
> From: Lespiau, Damien
> Sent: Thursday, July 03, 2014 7:19 PM
> To: Nikula, Jani
> Cc: Lin, Mengdong; alsa-de...@alsa-project.org; ti...@suse.de;
> intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: provide interface for audio
> driver
Baytrail uses the RPS wait-boosting mechanism of Sandybridge+ but also has
a very lax downclocking strategy (upclock if more than 90% busy over 76ms,
downclock if less than 70% busy over 450ms). This causes Baytrail to use
maximum clocks, and for them to stay high, when doing simple tasks such as
s
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Thursday, July 03, 2014 1:28 PM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/8] drm/i915: Rename ctx->obj to ctx-
> >rcs_state
>
> On Thu, Jul 03, 2014
On Thu, Jul 03, 2014 at 04:35:41PM +0530, Shobhit Kumar wrote:
> We should keep DEVICE_READY bit set in the ULPS enter sequence. In
> exit sequence also we should set DEVICE_READY, but thats causing
> blankout for me. Also exit sequence is simplified as per hw team
> recommendation.
>
> This shoul
On Thu, Jul 03, 2014 at 12:08:42PM +, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Thursday, July 03, 2014 10:47 AM
> > To: Mateo Lozano, Oscar
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [P
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Thursday, July 03, 2014 10:49 AM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 3/8] drm/i915: Rename ctx->is_initialized to
> ctx->rcs_is_initialized
>
>
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Thursday, July 03, 2014 10:47 AM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/8] drm/i915: Rename ctx->obj to ctx-
> >rcs_state
>
> On Thu, Jun 26, 201
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Thursday, July 03, 2014 10:53 AM
> To: Mateo Lozano, Oscar; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 4/8] drm/i915: Rename ctx->id to ctx->handle
>
> On Thu, Jul 03, 2014 at 10:30:5
On Tue, 01 Jul 2014, Rodrigo Vivi wrote:
> Jani, please ignore the 4th patch on this series and merge the 3 I've
> reviewed and tested already.
Patches 1-3 pushed to dinq. Thanks for the patches and review.
BR,
Jani.
>
> They are essential to allow FBC work on BDW without changing bios
> config
On Thu, Jul 03, 2014 at 10:32:38AM +0300, Jani Nikula wrote:
> On Thu, 03 Jul 2014, mengdong@intel.com wrote:
> > From: Jani Nikula
>
> I wrote this as a quick hack patch to try as an alternative to [1] which
> ended up not working on Haswell. Please reassure me that this is going
> to be a t
While sending DPI SHUTDOWN command, we cannot wait for FIFO empty as
pipes are not disabled at that time. In case of MIPI we disable port
first and send SHUTDOWN command while pipe is still running and FIFOs
will not be empty, causing spurious error log
Signed-off-by: Shobhit Kumar
---
drivers/g
We should keep DEVICE_READY bit set in the ULPS enter sequence. In
exit sequence also we should set DEVICE_READY, but thats causing
blankout for me. Also exit sequence is simplified as per hw team
recommendation.
This should fix -
[drm:intel_dsi_clear_device_ready] *ERROR* DSI LP not going Low
Bu
On Thu, 03 Jul 2014, "Lin, Mengdong" wrote:
> Hi Jani,
>
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Thursday, July 03, 2014 3:33 PM
>
>> I wrote this as a quick hack patch to try as an alternative to [1] which
>> ended up not working on Haswell. Please reassure me that this is
On Thu, Jul 03, 2014 at 10:30:52AM +0100, Chris Wilson wrote:
> On Thu, Jun 26, 2014 at 02:24:15PM +0100, oscar.ma...@intel.com wrote:
> > From: Oscar Mateo
> >
> > This is an Execlists preparatory patch, since they make context ID become an
> > overloaded term:
> >
> > - In the software, it was
On Thu, Jun 26, 2014 at 02:24:14PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> We only use this flag to signify that the render state (a.k.a. golden
> context, a.k.a. null context) has been initialized. It doesn't mean
> anything for the other engines, so make that distinction obv
On Thu, Jun 26, 2014 at 02:24:13PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> This is Execlists preparatory work.
>
> We have already advanced that Logical Ring Contexts have their own kind
> ob backing objects, but everything will be better explained in the Execlists
> series.
Hi Jani,
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, July 03, 2014 3:33 PM
> I wrote this as a quick hack patch to try as an alternative to [1] which
> ended up not working on Haswell. Please reassure me that this is going to
> be a temporary solution until we get a more
On Thu, Jun 26, 2014 at 02:24:15PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> This is an Execlists preparatory patch, since they make context ID become an
> overloaded term:
>
> - In the software, it was used to distinguish which context userspace was
> trying to use.
> - In t
On Thu, Jul 03, 2014 at 09:07:41AM +, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Thursday, July 03, 2014 8:32 AM
> > To: Mateo Lozano, Oscar
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PA
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Thursday, July 03, 2014 8:32 AM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 8/8] drm/i915: Extract the actual workload
> submission mechanism from execbu
Hi Dave -
Fixes for 3.16-rc3; most importantly Jesse brings back VGA he took away
on a bunch of machines. Also a vblank fix for BDW and a power workaround
fix for VLV.
BR,
Jani.
The following changes since commit 8525a235c96a548873c6c5644f50df32b31f04c6:
drm/i915: vlv_prepare_pll is only nee
On Thu, Jul 03, 2014 at 08:12:35AM +0100, Damien Lespiau wrote:
> This reverts commit 02f6bcccf7c324115747aae2f0addd6af5d321cd.
>
> The OA buffer can contain global data (in particular, not linked to a
> context or a single batch execution) about GPU events (eg. hw context
> switches, rc6 transiti
On Thu, 03 Jul 2014, mengdong@intel.com wrote:
> From: Jani Nikula
I wrote this as a quick hack patch to try as an alternative to [1] which
ended up not working on Haswell. Please reassure me that this is going
to be a temporary solution until we get a more generic interface between
the audio
On Thu, Jun 26, 2014 at 02:24:19PM +0100, oscar.ma...@intel.com wrote:
> + i915_gem_execbuffer_move_to_active(vmas, ring);
> + i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj);
This is where I start freaking out over the mix of global vs logical
state and the implications of
On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > >With this long thread I lost a bit context about the challenges
> > >that exists. But let me try su
On Wed, Jul 02, 2014 at 02:19:42PM +0100, Rutkowski, Adam J wrote:
> Having said all this, how about restoring the pin_ioctl? At least for
> some time? We do have a use case and moving to other - better -
> solution would take time. I think backward compatibility is something
> that you take into c
This reverts commit 02f6bcccf7c324115747aae2f0addd6af5d321cd.
The OA buffer can contain global data (in particular, not linked to a
context or a single batch execution) about GPU events (eg. hw context
switches, rc6 transitions, frequency changes, ...) and needs to be
mapped to GGTT. The pin ioctl
Since we rely on hangcheck to wait up and kick us out of an indefinite
wait should the GPU ever stop functioning, it appears sensible that we
should check that hangcheck is indeed active before starting that wait.
This just prevents a driver error in the processing of hangcheck from
appearing to ha
75 matches
Mail list logo
