With updates to the spec, we can actually see the context layout, and
how many dwords are allocated. That table suggests we need 70720 bytes
per HW context. Rounded up, this is 18 pages. Looking at what lives
after the current 4 pages we use, I can't see too much important (mostly
it's d3d related)
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commits 2d05eae1c92f
("drm/i915: Propagate errors back from fb set-base") and d62cf62ad07d
("drm/i915: Quirk the pipe A quirk in the modeset state checker") from
Linus' tree and co
Just remembered that Ken reviewed those 3 patches on IRC. So pushed
them.
--
Damien
On Wed, Feb 20, 2013 at 12:11:48PM +, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> intel/intel_aub.h | 76
> +
> 1 files changed, 53 i
If the crtc is active, we can simply flip a new fb onto it, provided the
other mode setting reqs are met. Otherwise, we'll need to do a full
mode set to re-enable the crtc.
v2: check for crtc active and set mode_changed accordingly
v3: add module parameter, i915.fastboot, to control no fb -> fb f
Need better pfit tracking to do this right.
v2: use fastboot param around this hack
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_displ
We already fetch and track other state into the main CRTC and encoder
structs, and for fastboot we need to do the same with the mode and clock
data we read out.
v2: fix debug print
v3: use fastboot param around state copy
v4: set clock and flags for crtc here instead of in setup_hw_state
Signed-o
We need this for comparing modes between configuration changes.
v2: try harder to calulate non-simple pixel clocks (Daniel)
call get_clock after getting the encoder config, needed for pixel multiply
(Jesse)
v3: drop get_clock now that the pixel_multiply has been moved into
get_pipe_con
Down to 5 patches, rebased on top of today's dinq and with changes
requested by Daniel.
This series is activated through the i915.fastboot=1 boot argument, and
works here on my SNB laptop. We still have some prettying of userspace
to do, but at least we avoid the panel power sequence so things ar
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c |5 +
drivers/gpu/drm/i915/i915_drv.h |1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4a4ec86..226d4d7 100644
--- a/drivers/gpu/drm/i915/i915_dr
On Mon, 24 Jun 2013 15:17:09 -0700
Ben Widawsky wrote:
> With updates to the spec, we can actually see the context layout, and
> how many dwords are allocated. That table suggests we need 70720 bytes
> per HW context. Rounded up, this is 18 pages. Looking at what lives
> after the current 4 pages
On Tue, Jun 25, 2013 at 11:46:01PM +0200, Yves-Alexis Perez wrote:
> But if that introduce regressions, shouldn't workarounds be found then?
> Sorry if I keep repeating that but brightness keys handling in-kernel is
> quite a useful feature and losing it (because of the “behave exactly
> like Windo
On mar., 2013-06-25 at 22:33 +0100, Matthew Garrett wrote:
> > I was referring to “standardize the behaviour by leaving up to
> > userspace”. A lot of thinkpads (for example) (all the pre-windows 8
> > ones) have a perfectly working ACPI backlight interface.
>
> And this patchset won't alter their
On Tue, Jun 25, 2013 at 11:30:37PM +0200, Yves-Alexis Perez wrote:
> On mar., 2013-06-25 at 22:14 +0100, Matthew Garrett wrote:
> > Which, as we've already established, you don't - Lenovo broke it. Your
> > Thinkpad claims to have 100 available levels, and most of them don't
> > work. The kernel
On mar., 2013-06-25 at 22:14 +0100, Matthew Garrett wrote:
> On Tue, Jun 25, 2013 at 11:10:11PM +0200, Yves-Alexis Perez wrote:
> > On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
> > > I agree, we should standardise the behaviour. And the only way we can
> > > standardise the behaviour
On Tue, Jun 25, 2013 at 11:10:11PM +0200, Yves-Alexis Perez wrote:
> On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
> > I agree, we should standardise the behaviour. And the only way we can
> > standardise the behaviour is to leave it up to userspace.
> >
> It's pretty clear we disagr
On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
> On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote:
> > On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
> > > Right, the kernel has special-casing to hook the backlight keys up to
> > > the ACPI backlight contro
On Tue, 25 Jun 2013 20:51:27 +
Shuah Khan wrote:
> On 06/25/2013 02:06 PM, Jesse Barnes wrote:
> > On Tue, 25 Jun 2013 19:59:28 +
> > Shuah Khan wrote:
> >
> >> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> >>> On Tue, 25 Jun 2013 21:37:37 +0200
> >>> Daniel Vetter wrote:
> >>>
> >>
> >
On Tue, Jun 25, 2013 at 11:51 PM, Shuah Khan wrote:
>
> On 06/25/2013 02:06 PM, Jesse Barnes wrote:
> > On Tue, 25 Jun 2013 19:59:28 +
> > Shuah Khan wrote:
> >
> >> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> >>> On Tue, 25 Jun 2013 21:37:37 +0200
> >>> Daniel Vetter wrote:
> >>>
> >>
> >
On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote:
> On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
> > Right, the kernel has special-casing to hook the backlight keys up to
> > the ACPI backlight control. This is an awful thing, because there's no
> > way to detect th
On Tue, Jun 25, 2013 at 11:51 PM, Shuah Khan wrote:
> On 06/25/2013 02:06 PM, Jesse Barnes wrote:
> > On Tue, 25 Jun 2013 19:59:28 +
> > Shuah Khan wrote:
> >
> >> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> >>> On Tue, 25 Jun 2013 21:37:37 +0200
> >>> Daniel Vetter wrote:
> >>>
> >>
> >>
On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
> On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
>
> > Before Linux support for acpi_osi("Windows 2012") (and when booting with
> > acpi_osi="!Windows 2012"), brightness keys were handled by the kernel
> > just fine, wh
On Tue, 25 Jun 2013 19:59:28 +
Shuah Khan wrote:
> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> > On Tue, 25 Jun 2013 21:37:37 +0200
> > Daniel Vetter wrote:
> >
>
> >>
> >> Adding more lists to cc + Jesse since he's the guilty one for the
> >> vt-switchless state restore stuff.
> >
> > Ye
On Tue, 25 Jun 2013 21:37:37 +0200
Daniel Vetter wrote:
> On Tue, Jun 25, 2013 at 9:05 PM, Linus Torvalds
> wrote:
> > Adding the appropriate cc'd.. I'm not seeing why this would start
> > happening now, but there's been a number of commits that touch the
> > intel crtc 'active' state and hotplu
On Tue, Jun 25, 2013 at 9:05 PM, Linus Torvalds
wrote:
> Adding the appropriate cc'd.. I'm not seeing why this would start
> happening now, but there's been a number of commits that touch the
> intel crtc 'active' state and hotplug logic, so I'm assuming one of
> them is to blame.. Lots of small c
On Tue, 25 Jun 2013 19:21:06 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> I can't find GEN6_RP_INTERRUPT_LIMITS (0xA014) anywhere in VLV docs.
> Reading it always returns zero from what I can tell, and eliminating
> it doesn't seem to make any difference to the behaviour
On Tue, 25 Jun 2013 19:21:05 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Eliminate the weird inverted logic from the rps new_delay comparison.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 delet
On Tue, 25 Jun 2013 19:21:04 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The timeout is 10 ms so it would end up as one jiffy when HZ=100, and
> one jiffy is quite susceptible to spurious timeouts as we've seen
> recently.
>
> Signed-off-by: Ville Syrjälä
> ---
> driv
On Tue, 25 Jun 2013 19:21:03 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Don't do needless udelay() calls if the Punit already completed
> the frequency change.
>
> Also double check things after the timeout to make sure the timeout
> wasn't just caused by some scheduli
On Tue, 25 Jun 2013 19:21:02 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> It seems that even though Punit reports the frequency change to have
> been completed, it still reports the old frequency in the status
> register for some time.
>
> So rather than polling for Puni
On Tue, 25 Jun 2013 21:38:10 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> There's little point in increasing the GPU frequency from the delayed
> rps work on VLV. Now when the GPU is idle, the GPU frequency actually
> keeps dropping gradually until it hits the minimum, wh
On Tue, 25 Jun 2013 19:21:01 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Always print both the MHz value and raw register value for rps stuff.
>
> Also kill a somewhat pointless local 'rpe' variable and just use
> dev_priv->rps.rpe_delay.
>
> While at it clean up the c
On Tue, Jun 25, 2013 at 8:38 PM, wrote:
> Just a few more rps patches for VLV.
>
> I noticed a silly GPU frequency ping-pong effect on an idle GPU due to the
> VLV rps timer. So I figured I'd do something about it, and the second patch
> tries to make sure that the first patch doesn't cause poor
On Tue, 25 Jun 2013 21:38:11 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> If the current GPU frquency is below RPe, and we're asked to increase
> it, just go directly to RPe. This should provide better performance
> faster than letting the frequency trickle up in response
Just a few more rps patches for VLV.
I noticed a silly GPU frequency ping-pong effect on an idle GPU due to the
VLV rps timer. So I figured I'd do something about it, and the second patch
tries to make sure that the first patch doesn't cause poor performance when
the GPU becomes busy again.
__
From: Ville Syrjälä
There's little point in increasing the GPU frequency from the delayed
rps work on VLV. Now when the GPU is idle, the GPU frequency actually
keeps dropping gradually until it hits the minimum, whereas previously
it just ping-ponged constantly between RPe and RPe-1.
Signed-off-
From: Ville Syrjälä
If the current GPU frquency is below RPe, and we're asked to increase
it, just go directly to RPe. This should provide better performance
faster than letting the frequency trickle up in response to the up
threshold interrupts.
For now just do it for VLV, since that matches qu
On Tue, Jun 25, 2013 at 05:26:45PM +0100, Chris Wilson wrote:
> Report back the user error of attempting to setup a CRTC with an invalid
> framebuffer pitch. This is trickier than it should be as on gen4, there
> is a restriction that tiled surfaces must have a stride less than 16k -
> which is les
Report back the user error of attempting to setup a CRTC with an invalid
framebuffer pitch. This is trickier than it should be as on gen4, there
is a restriction that tiled surfaces must have a stride less than 16k -
which is less than the largest supported CRTC size.
v2: Fix the limits for gen3
v
From: Ville Syrjälä
It seems that even though Punit reports the frequency change to have
been completed, it still reports the old frequency in the status
register for some time.
So rather than polling for Punit to complete the frequency change after
each request, poll before. This gets rid of th
Here's a bunch of stuff for VLV rps code.
My initial goal was to just get rid of the spurious Punit freq override
messages, but I ended up improving performance by accident as well.
IIRC Jesse was a bit scared of eliminating GEN6_RP_INTERRUPT_LIMITS, but
so far I haven't seen any ill effects from
From: Ville Syrjälä
The timeout is 10 ms so it would end up as one jiffy when HZ=100, and
one jiffy is quite susceptible to spurious timeouts as we've seen
recently.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
From: Ville Syrjälä
Don't do needless udelay() calls if the Punit already completed
the frequency change.
Also double check things after the timeout to make sure the timeout
wasn't just caused by some scheduling delays.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 14 +++
From: Ville Syrjälä
I can't find GEN6_RP_INTERRUPT_LIMITS (0xA014) anywhere in VLV docs.
Reading it always returns zero from what I can tell, and eliminating
it doesn't seem to make any difference to the behaviour of the system.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c
From: Ville Syrjälä
Eliminate the weird inverted logic from the rps new_delay comparison.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
i
From: Ville Syrjälä
Always print both the MHz value and raw register value for rps stuff.
Also kill a somewhat pointless local 'rpe' variable and just use
dev_priv->rps.rpe_delay.
While at it clean up the caps in "GPU" and "Punit" debug messages.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/
On Tue, Jun 25, 2013 at 03:24:17PM +0100, Damien Lespiau wrote:
> On Tue, Jun 25, 2013 at 04:38:21PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > No need to apply WaForceL3Serialization:vlv twice.
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Damien Lespi
On Tue, Jun 25, 2013 at 06:10:35PM +0200, Daniel Vetter wrote:
> Do we have any chances to amend this mistake by (gradually) phasing
> out support for the direct keypress forwarding in ACPI? Or at least
> some plans?
We could make the default value of brightness_switch_enabled a config
variable
On Tue, Jun 25, 2013 at 06:47:02PM +0300, Mika Kuoppala wrote:
> From: Chris Wilson
>
> As our contexts are more general than the logical contexts supported by
> the hardware, for instance they allow per context hangcheck tracking, it
> is beneficial to group tasks across rings belonging to the s
On Tue, Jun 25, 2013 at 6:08 PM, Matthew Garrett wrote:
> On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
>
>> Before Linux support for acpi_osi("Windows 2012") (and when booting with
>> acpi_osi="!Windows 2012"), brightness keys were handled by the kernel
>> just fine, whether
On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
> Before Linux support for acpi_osi("Windows 2012") (and when booting with
> acpi_osi="!Windows 2012"), brightness keys were handled by the kernel
> just fine, whether in console, in the display manager or in my desktop
> environme
From: Chris Wilson
The intent of the check is made more clear if we use the proper name for
0 here.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/dr
From: Chris Wilson
The default context is always supported (as it contains the global
hangcheck stats) and the contexts for hangcheck are not limited
to any ring.
References: https://bugs.freedesktop.org/show_bug.cgi?id=65845
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/
From: Chris Wilson
As our contexts are more general than the logical contexts supported by
the hardware, for instance they allow per context hangcheck tracking, it
is beneficial to group tasks across rings belonging to the same context.
Context switching is already a no-op for unsupported rings,
From: Ville Syrjälä
Add the names of all VLV DPIO registers.
Implement a quick and hacky solution to make the tool "detect"
DPIO registers by checking if the file name contains the string
"dpio".
Signed-off-by: Ville Syrjälä
---
tools/quick_dump/Makefile.am | 2 +-
tools/quick_dump/quick_d
Upon resetting the GPU, we begin processing batches once more, so
reset the hangcheck timer.
v2: kicking inside reset instead of hangcheck_elapsed and
sane commit message by Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c |2 ++
1 file changed, 2 insertions
To run hangcheck in near future.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c |6 ++
drivers/gpu/drm/i915/i915_irq.c | 21 -
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/dr
The timer for hangchecking can run again before the previous
reset it has triggered has been handled. This can corrupt
the hangcheck state as reset handling will access and write to
the hangcheck data. To prevent this, avoid running the hangcheck
logic while reset is in progress.
Signed-off-by: Mi
On Tue, Jun 25, 2013 at 04:38:21PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> No need to apply WaForceL3Serialization:vlv twice.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4
> 1 file changed, 4 dele
From: Ville Syrjälä
No need to apply WaForceL3Serialization:vlv twice.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index cc9440b..3705203 100644
--- a/d
On Tue, Jun 25, 2013 at 08:15:22AM +0100, Chris Wilson wrote:
> With Haswell the transcoders are a separate bank of registers from the
> pipes (4 transcoders, 3 pipes). In event of an error, we want to be sure
> we have a complete and accurate picture of the machine state, so record
> all the trans
On Mon, Jun 24, 2013 at 02:54:50PM +0100, Damien Lespiau wrote:
> Once we've found the the context object programmed in CCID, there's no
> need to look the other objects in the list.
>
> Signed-off-by: Damien Lespiau
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engin
On Tue, Jun 25, 2013 at 01:32:52PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 24, 2013 at 10:59:48PM +0100, Damien Lespiau wrote:
> > Caught with checkpatch.pl.
> >
> > Suggested-by: Daniel Vetter
> > Signed-off-by: Damien Lespiau
>
> For the series:
> Reviewed-by: Ville Syrjälä
Entire series
The if (pm_iir & ~GEN6_PM_RPS_EVENTS) check was redunandant. Otoh
adding a check for rps events allows us to avoid the spinlock grabbing
for VECS interrupts.
v2: Drop misplaced hunk which now moved to the right patch.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 20 +++
Since we only have one interrupt handler and interrupt handlers are
non-reentrant.
To drive the point really home give them all an _irq_handler suffix.
This is a tiny micro-optimization but even more important it makes it
clearer what locking we actually need. And in case someone screws this
up:
This way all changes to SDEIMR all go through the same function, with
the exception of the (single-threaded) setup/teardown code.
For paranoia again add an assert_spin_locked.
v2: For even more paranoia also sprinkle a spinlock assert over
cpt_can_enable_serr_int since we need to have that one th
The haswell unclaimed register handling code forgot to take the
spinlock. Since this is in the context of the non-rentrant interupt
handler and we only have one interrupt handler it is sufficient to
just grab the spinlock - we do not need to exclude any other
interrupts from running on the same cpu
From: Ville Syrjälä
We forgot to add VLV_DISPLAY_BASE to the VLV sprite registers, which
caused the sprites to not work at all.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 50 -
1 file changed, 25 insertions(+), 25 deletions(-)
di
From: Ville Syrjälä
The PIPECONF color range bit doesn't appear to be effective, on HDMI
outputs at least. The color range bit in the port register works though,
so let's use it.
I have not yet verified whether the PIPECONF bit works on DP outputs.
This reverts commit 83a2af88f80ebf8104c9e083b7
On Mon, Jun 24, 2013 at 10:59:48PM +0100, Damien Lespiau wrote:
> Caught with checkpatch.pl.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Damien Lespiau
For the series:
Reviewed-by: Ville Syrjälä
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing
On Tue, Jun 25, 2013 at 10:10:49AM +0100, Chris Wilson wrote:
> On Tue, Jun 25, 2013 at 11:06:52AM +0200, Daniel Vetter wrote:
> > There are legit cases, e.g. when userspace asks for something
> > impossible. So tune it down to debug output like we do with all other
> > userspace-triggerable warnin
On Tue, Jun 25, 2013 at 08:43:09AM +0100, Chris Wilson wrote:
> On Mon, Jun 24, 2013 at 09:04:40PM +0200, Daniel Vetter wrote:
> > Bspec seems to be full of lies, at least it disagress with reality:
> > Two systems corrobated that SDVO hpd bits are the same as on gen3.
> >
> > Cc: Arthur Ranyan
>
On Tue, Jun 25, 2013 at 11:06:52AM +0200, Daniel Vetter wrote:
> There are legit cases, e.g. when userspace asks for something
> impossible. So tune it down to debug output like we do with all other
> userspace-triggerable warnings.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66111#
There are legit cases, e.g. when userspace asks for something
impossible. So tune it down to debug output like we do with all other
userspace-triggerable warnings.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66111#c5
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.
On Mon, Jun 24, 2013 at 09:04:40PM +0200, Daniel Vetter wrote:
> Bspec seems to be full of lies, at least it disagress with reality:
> Two systems corrobated that SDVO hpd bits are the same as on gen3.
>
> Cc: Arthur Ranyan
> Cc: Chris Wilson
> Tested-by: Chris Wilson
> Reported-and-tested-by:
With Haswell the transcoders are a separate bank of registers from the
pipes (4 transcoders, 3 pipes). In event of an error, we want to be sure
we have a complete and accurate picture of the machine state, so record
all the transcoders in addition to all the active pipes.
Signed-off-by: Chris Wils
On Mon, Jun 24, 2013 at 09:59:33AM +0200, Daniel Vetter wrote:
> On Fri, Jun 21, 2013 at 03:40:04PM +0100, Chris Wilson wrote:
> > Do not trust our bookkeeping when reporting errors, and instead dump the
> > register contents. In particular, this solves one particular issue when
> > an error is rep
76 matches
Mail list logo
