On Jun-18-2014 9:22 PM, Daniel Vetter wrote:
> On Wed, Jun 18, 2014 at 07:47:24PM +0530, Vandana Kannan wrote:
>> For Gen < 8, set M2_N2 registers on every mode set. This is required to make
>> sure M2_N2 registers are set during boot, resume from sleep for cross-
>> checking the state. The registe
Hi Thierry/Daniel,
Please help review this patch series on aspect ratio and let me know
your inputs..
1. http://lists.freedesktop.org/archives/dri-devel/2014-June/061576.html
- All review comments (from Thierry) addressed.
2. http://lists.freedesktop.org/archives/dri-devel/2014-June/061217.html
-
On Thu, Jun 19, 2014 at 08:28:11PM +0100, Chris Wilson wrote:
> On Thu, Jun 19, 2014 at 12:06:13PM -0700, Ben Widawsky wrote:
> > This is one part in a few fixes needed to make FBC work with limited
> > stolen memory and large resolution displays. It is not the full
> > solution, but one (easy) ste
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Monday, June 30, 2014 6:45 PM
> To: Wang, Quanxian
> Cc: intel-gfx@lists.freedesktop.org; Daniel Vetter
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable
> for valleyview pla
On 2014/6/30 19:18, Michael S. Tsirkin wrote:
On Thu, Jun 19, 2014 at 05:53:51PM +0800, Tiejun Chen wrote:
Originally the reason to probe ISA bridge instead of Dev31:Fun0
is to make graphics device passthrough work easy for VMM, that
only need to expose ISA bridge to let driver know the real
har
On Mon, 2014-06-30 at 10:51 -0600, Rodrigo Vivi wrote:
> On Broadwell GT3 we have 2 Video Command Streamers (VCS),
> but userspace has no control when using VCS1 or VCS2. So we cannot test,
> validate or debug specific changes or workaround that might affect only
> one or another ring. So this patc
On Mon, 2014-06-30 at 09:51 -0700, Rodrigo Vivi wrote:
> On Broadwell GT3 we have 2 Video Command Streamers (VCS),
> but userspace has no control when using VCS1 or VCS2. So we cannot test,
> validate or debug specific changes or workaround that might affect only
> one or another ring. So this patc
On Mon, Jun 30, 2014 at 09:51:10AM -0700, Rodrigo Vivi wrote:
> On Broadwell GT3 we have 2 Video Command Streamers (VCS),
> but userspace has no control when using VCS1 or VCS2. So we cannot test,
> validate or debug specific changes or workaround that might affect only
> one or another ring. So th
>>From: Ben Widawsky [mailto:b...@bwidawsk.net]
>>Sent: Friday, June 20, 2014 9:43 AM
>>On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote:
>>> Higher RC6 residency is observed using timeout mode instead of EI
>>> mode. This applies to Broadwell only.
>>> The difference is particularly n
On Mon, Jun 30, 2014 at 09:51:11AM -0700, Rodrigo Vivi wrote:
> ring index calculation table was out of date after other rings were added,
> although the formula is flexible and scale when adding new rings.
>
> So this patch just update the comments and add a brief explanation
> why to use sync_se
On Mon, Jun 30, 2014 at 09:51:09AM -0700, Rodrigo Vivi wrote:
> It just fix a typo.
>
> Signed-off-by: Rodrigo Vivi
Reviewed-by: Ben Widawsky
[snip]
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.free
From: Ben Widawsky
The GEN FBC unit provides the ability to set a low pass on frames it
attempts to compress. If a frame is less than a certain amount
compressibility (2:1, 4:1) it will not bother. This allows the driver to
reduce the size it requests out of stolen memory.
Unluckily, a few month
Reviewed-by: Rodrigo Vivi
On Thu, Jun 19, 2014 at 12:06 PM, Ben Widawsky
wrote:
> Right now, there is no threshold (0 means fail, 1 means 1:1 compression
> limit). This is to split the function/non-functional change of the next
> patch.
>
> The next patch will start to attempt to reduce the am
Reviewed-by: Rodrigo Vivi
On Thu, Jun 19, 2014 at 12:06 PM, Ben Widawsky
wrote:
> We are already using the size to determine whether or not to free the
> object, so there is no functional change there. Almost everything else
> has changed to static allocations of the drm_mm_node too.
>
> Aside
On Mon, Jun 30, 2014 at 09:53:44AM -0700, Rodrigo Vivi wrote:
> Signed-off-by: Rodrigo Vivi
Reviewed-by: Ben Widawsky
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedes
On Mon, Jun 30, 2014 at 09:53:39AM -0700, Rodrigo Vivi wrote:
> Ipehr just carries Dword 0 and on Gen 8, offsets are located
> on Dword 2 and 3 of MI_SEMAPHORE_WAIT.
>
> This implementation was based on Ben's work and on Ville's suggestion for Ben
>
> Cc: Ville Syrjälä
> Cc: Ben Widawsky
> Sign
Ipehr just carries Dword 0 and on Gen 8, offsets are located
on Dword 2 and 3 of MI_SEMAPHORE_WAIT.
This implementation was based on Ben's work and on Ville's suggestion for Ben
Cc: Ville Syrjälä
Cc: Ben Widawsky
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_irq.c | 42 +++
From: Ben Widawsky
As Ville points out, it's possible/probable we don't actually need this.
Potentially, this validates the letter of the spec, and not the spirit.
Ville:
> I discussed this on irc w/ Ben, and I was suggesting we don't need to
> poll. Polling apparently can be used as a workaroun
From: Ben Widawsky
v2: s/ring_buffer/engine_cs (Rodrigo)
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ben Widawsky
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gpu_error.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gp
From: Ben Widawsky
Semaphore signalling works similarly to previous GENs with the exception
that the per ring mailboxes no longer exist. Instead you must define
your own space, somewhere in the GTT.
The comments in the code define the layout I've opted for, which should
be fairly future proof. I
From: Ben Widawsky
Simple debugfs file to display the current state of semaphores. This is
useful if you want to see the state without hanging the GPU.
NOTE: This patch is optional to the series.
NOTE2: Like the GPU error state collection, the reads are currently
incoherent.
v2 (Rodrigo): * It
From: Ben Widawsky
Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to
wait on is all well defined by the table in the previous patch. There is
nothing else different from previous GEN's semaphore synchronization
code.
v2: Update macros to not require the other ring's ring->id
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6eb45ac..1f84f88 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -47
From: Ben Widawsky
Since the semaphore information is in an object, just dump it, and let
the user parse it later.
NOTE: The page being used for the semaphores are incoherent with the
CPU. No matter what I do, I cannot figure out a way to read anything but
0s. Note that the semaphore waits are i
From: Ben Widawsky
With the ring mask we now have an easy way to know the number of rings
in the system, and therefore can accurately predict the number of dwords
to emit for semaphore signalling. This was not possible (easily)
previously.
There should be no functional impact, simply fewer instr
From: Ben Widawsky
Gen8 has already had some differentiation with how it handles rings.
Semaphores bring yet more differences, and now is as good a time as any
to do the split.
Also, since gen8 doesn't actually use semaphores up until this point,
put the proper "NULL" values in for the mbox info
On Broadwell GT3 we have 2 Video Command Streamers (VCS),
but userspace has no control when using VCS1 or VCS2. So we cannot test,
validate or debug specific changes or workaround that might affect only
one or another ring. So this patch introduces a mechanism to avoid the
ping-pong selection and u
ring index calculation table was out of date after other rings were added,
although the formula is flexible and scale when adding new rings.
So this patch just update the comments and add a brief explanation
why to use sync_seqno[ring index].
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915
It just fix a typo.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2faef26..c3f96a1 100644
--- a/drivers/gpu/drm/i
If a subtest fails, cleanup_crtc() never gets called and then the
test_data_t structure for the test is lost, including the CRC file
descriptor that we never got a chance to release; this causes all
subsequent tests to fail with -EBUSY at igt_pipe_crc_new().
The split between permanent data_t and
We're calling drmModeSetCursor() to change the cursor image and never
actually doing a display commit (aside from when we display the cursor),
so call the move ioctl directly rather than igt_plane_set_position() to
ensure the changes actually take effect.
Signed-off-by: Matt Roper
---
tests/kms_
Add a simple test to exercise universal plane support.
v6:
- Update to new universal plane interface (commit parameter rather than
state-changing function). It should now be a lot more explicit which
steps are being taken with legacy API's vs universal API's now.
v5:
- Check that we don't
Add a new public API that will attempt a display commit, but will return
an error code upon failure rather than failing the IGT test. This is
intended to allow igt tests to verify that the expected error codes are
returned to userspace when invalid requests are issued.
Note that with non-atomic p
None of our hardware can support this today, but we'd like to be able to
write tests that check that the kernel returns the proper error code
when userspace tries it anyway.
Signed-off-by: Matt Roper
---
lib/igt_kms.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/lib/igt_kms.c b/lib/i
Add a new commit interface, igt_display_commit2(), that allows tests to
specify which programming API should be used to perform hardware
updates. COMMIT_LEGACY is the only option for now, but universal
and atomic interfaces will be added as additional options in the future.
igt_display_commit() r
Add support for universal planes. This involves revamping the existing
plane handling a bit to allow primary & cursor planes to come from the
DRM plane list, rather than always being manually added.
v2: Don't drop fixed ordering of internal plane list. Primary will
always be index 0, cursor
This patch set refactors the igt_kms library a bit to allow display state
changes to be commited via different API's (with different "commit styles") and
adds a new "universal" commit style that makes use of the universal plane API.
Some of the patches here were previously posted here:
htt
The need to wait for a vblank after programming is due to the way we
actually program the hardware. Move need_wait_for_vblank out of the
pipe and into a local variable in preparation for future programming
styles (e.g., atomic pageflip) that will need different logic.
Signed-off-by: Matt Roper
-
The "need" flags on igt_pipe simply mirror the fb_changed field of the
primary/cursor planes. Drop them and just use fb_changed instead.
Signed-off-by: Matt Roper
---
lib/igt_kms.c | 18 ++
lib/igt_kms.h | 2 --
2 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/li
On Sat, 28 Jun 2014 02:04:28 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When switching from one pipe to another, the power sequencer of the new
> pipe seems to need a bit of kicking to lock into the port. Even the vdd
> force bit doesn't work before the power sequencer
On Thu, 26 Jun 2014 18:23:55 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The i915_gem_record_rings() code was unconditionally querying and saving state
> for the batch_obj of a request structure. This is not necessarily set. Thus a
> null pointer dereference can occur.
> ---
On Thu, 26 Jun 2014 18:23:54 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The scheduler needs to track batch buffers by seqno without extra, non-batch
> buffer work being attached to the same seqno. This means that anywhere which
> adds work to the ring should explicitly call
On Thu, 26 Jun 2014 18:23:52 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The 'i915_driver_preclose()' function has a parameter called 'file_priv'.
> However, this is misleading as the structure it points to is a 'drm_file' not
> a
> 'drm_i915_file_private'. It should be nam
On Thu, 26 Jun 2014 14:24:19 +0100
oscar.ma...@intel.com wrote:
> 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).
"w
2014-06-25 16:01 GMT-03:00 Imre Deak :
> From: Daniel Vetter
>
> All the other checks also check hw state, so checking our software
> refcounts for the plls looks a bit odd. Also this will simplify the
> conversion over to the shared dpll framework, which itself has massive
> amounts of checks to
On Thu, 26 Jun 2014 14:24:18 +0100
oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Again, it's low-level enough to simply take a ringbuf and nothing
> else.
>
> Trivial change.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_gem.c | 4 ++--
> drivers/gpu/drm/i91
On Thu, 26 Jun 2014 14:24:17 +0100
oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> It's simple enough that it doesn't need to know anything about the
> engine.
>
> Trivial change.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 13 ++---
> 1 file
On Thu, 26 Jun 2014 14:24:16 +0100
oscar.ma...@intel.com wrote:
> 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 allo
On Thu, 26 Jun 2014 14:24:15 +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 the BSp
On Thu, 26 Jun 2014 14:24:14 +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 obvious.
On Thu, 26 Jun 2014 14:24:13 +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. For no
On Thu, 26 Jun 2014 14:24:12 +0100
oscar.ma...@intel.com wrote:
> 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.
On Mon, Jun 30, 2014 at 07:24:13PM +0100, Damien Lespiau wrote:
> I assume the intention was to provide a different structure for each of
> the gen 2 devices.
>
> This doesn't change anything really.
>
> Signed-off-by: Damien Lespiau
Thanks, pushed.
-Chris
--
Chris Wilson, Intel Open Source T
On Mon, Jun 30, 2014 at 12:22 PM, Paulo Zanoni wrote:
> 2014-06-27 19:30 GMT-03:00 Rodrigo Vivi :
> > I have the feeling the safest side would be disable rc6 on resume
> instead of
> > force its enabling... or am I missing something?
>
> It will be enabled, then disabled.
>
oh that's true!
>
>
From: Paulo Zanoni
It is possible that, by the time we run i915_drm_freeze(),
delayed_resume_work was already queued but did not run yet. If it
still didn't run after intel_runtime_pm_disable_interrupts(), by the
time it runs it will try to change the interrupt registers with the
interrupts alrea
2014-06-27 19:30 GMT-03:00 Rodrigo Vivi :
> I have the feeling the safest side would be disable rc6 on resume instead of
> force its enabling... or am I missing something?
It will be enabled, then disabled.
> why don't you just cancel the work? and put another after resume?
>
> but if the patch r
2014-06-30 8:45 GMT-03:00 Rodrigo Vivi :
> As pointed out before we don't have a reliable way to read back ips
> status on BDW without the risk to disable it when reading.
> However now we are pretending that IPS on BDW is always on and getting
> people confused about it.
>
> So this patch allows p
As pointed out before we don't have a reliable way to read back ips
status on BDW without the risk to disable it when reading.
However now we are pretending that IPS on BDW is always on and getting
people confused about it.
So this patch allows people to know if ips was ever attempted to be enable
I assume the intention was to provide a different structure for each of
the gen 2 devices.
This doesn't change anything really.
Signed-off-by: Damien Lespiau
---
src/intel_module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel_module.c b/src/intel_module.c
index
Hello Jani,
On 30.06.2014 10:57, Jani Nikula wrote:
> On Sat, 28 Jun 2014, Oliver Hartkopp wrote:
>> The latest git pull from Linus' tree fixed my issue.
>>
>> vmlinuz-3.16.0-rc2-00211-gd7933ab (26.6. 21:19) was bad
>> vmlinuz-3.16.0-rc2-00319-g3e7b256 (28.6. 09:23) works again
>>
>> There are t
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
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
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 dur
Jani, here are the changes you suggested plus:
1) Against newer drm-intel-nightly
2) Added Acer C720P (touchscreen), tested by Michael
3) Removed HP 14 and Dell 11 Chromebooks since no testers yet
4) Clarified these are for the Haswell (Celeron 2955U) boards since upcoming
Chromebooks may be sam
Kernels v3.16-rc2 and v3.16-rc3 trigger a new (for me) warning. (I never
booted v3.16-rc1). Machine is a, rather outdated, ThinkPad X41 (ie,
single core i686).
WARNING: CPU: 0 PID: 221 at drivers/gpu/drm/i915/intel_display.c:1274
assert_planes_disabled+0xf9/0x100 [i915]()
plane B assertion failur
On Sat, 28 Jun 2014 16:45:03 +0300
Jani Nikula wrote:
> >> +/* Scale user_level in range [0..user_max] to [0..hw_max], clamping the
> >> result
> >> + * to [hw_min..hw_max]. */
> >> +static inline u32 clamp_user_to_hw(struct intel_connector *connector,
> >> + u32 user_
Chris Wilson wrote:
> This is similar to remap_pfn_range(), and uses the recently refactor
> code to do the page table walking. The key difference is that is back
> propagates its error as this is required for use from within a pagefault
> handler. The other difference, is that it combine the page
Chris Wilson wrote:
> In preparation for exporting very similar functionality through another
> interface, gut the current remap_pfn_range(). The motivating factor here
> is to reuse the PGB/PUD/PMD/PTE walker, but allow back progation of
> errors rather than BUG_ON.
>
> Signed-off-by: Chris Wilso
Hi Dave -
Here's some drm core stuff for 3.17 put together by Daniel.
BR,
Jani.
The following changes since commit bc1dfff04a5d4064ba0db1fab13f84ab4f333d2b:
Merge branch 'drm-nouveau-next' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2014-06-11
16:28:10 +1000)
ar
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org]
On Thu, Jun 19, 2014 at 05:53:51PM +0800, Tiejun Chen wrote:
> Originally the reason to probe ISA bridge instead of Dev31:Fun0
> is to make graphics device passthrough work easy for VMM, that
> only need to expose ISA bridge to let driver know the real
> hardware underneath. This is a requirement f
Il 30/06/2014 05:13, Chen, Tiejun ha scritto:
After I discuss internal, we think even we just set the real
vendor/device ids to this ISA bridge at 00:1f.0, guest firmware should
still work well with these pair of real vendor/device ids.
So if you think something would conflict or be broken, coul
On Wed, 25 Jun 2014, Alan Stern wrote:
> On Wed, 25 Jun 2014, Ville [iso-8859-1] Syrjl wrote:
>
>> On Wed, Jun 25, 2014 at 02:06:55PM -0400, Alan Stern wrote:
>> > Daniel:
>> >
>> > I encountered a new problem in the i915 driver the first time I booted
>> > a 3.16-rc kernel on this computer. Wh
On Thu, 26 Jun 2014, "Wang, Quanxian" wrote:
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Sent: Tuesday, June 24, 2014 11:58 PM
>> To: Wang, Quanxian
>> Cc: intel-gfx@lists.freedesktop.org; Daniel Vetter
>> Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv
On Thu, 05 Jun 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On most gen2-4 platforms the GTT can be (or maybe always is?)
> inside the stolen memory region. If that's the case, reduce the
> size of the stolen memory appropriately to make make sure we
> don't clobber the GTT
On Fri, 27 Jun 2014, Jani Nikula wrote:
> On Sat, 28 Jun 2014, deepa...@linux.intel.com wrote:
>> From: Deepak S
>>
>> Workaround fixed in Latest VLV revision. Forcing Gfx clk up not needed, and
>> Requesting the
>> min freq should bring bring the voltage Vnn.
>>
>> v2: Drop WA for Latest VLV re
On Thu, 26 Jun 2014, Rodrigo Vivi wrote:
> I'm sure this might affect Wayne, so, cc'ing him here.
>
> from my point of view this is right so:
> Reviewed-by: Rodrigo Vivi
Pushed to -fixes, thanks for the patch and review.
BR,
Jani.
>
>
> On Tue, Jun 24, 2014 at 3:59 AM, wrote:
>
>> From: Vill
On Wed, 25 Jun 2014, Ville Syrjälä wrote:
> On Wed, Jun 25, 2014 at 08:24:29AM -0700, Jesse Barnes wrote:
>> Apparently we can't trust this field on other platforms and need to find
>> some other way.
>>
>> Signed-off-by: Jesse Barnes
>
> Reviewed-by: Ville Syrjälä
>
> Since it's a regression i
On Mon, Jun 30, 2014 at 12:02:20PM +0200, Pavel Machek wrote:
> On Tue 2014-06-24 13:27:37, Chris Wilson wrote:
> > On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote:
> > > Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson:
> > > > On Tue, Jun 24, 2014 at 02:06:24PM +0300, Ja
On Tue 2014-06-24 13:27:37, Chris Wilson wrote:
> On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote:
> > Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson:
> > > On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote:
> > > > On Tue, 24 Jun 2014, Thomas Meyer wrote:
> >
On Sat, 28 Jun 2014, Oliver Hartkopp wrote:
> Hello Daniel,
>
> just to close my request:
>
> The latest git pull from Linus' tree fixed my issue.
>
> vmlinuz-3.16.0-rc2-00211-gd7933ab (26.6. 21:19) was bad
> vmlinuz-3.16.0-rc2-00319-g3e7b256 (28.6. 09:23) works again
>
> There are two pulls with
Hi
On Mon, Jun 30, 2014 at 8:59 AM, Chris Wilson wrote:
> On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
>> On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
>>
>> Resend without html krud which causes list to bounce the message.
>>
>> > Hi
>> >
>> > This commit ( a4de05268e674
On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
> On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
>
> Resend without html krud which causes list to bounce the message.
>
> > Hi
> >
> > This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot with
> > 3.16-git.
83 matches
Mail list logo
