Re: e1000e regression - 5.4rc1

Hi, On 08.10.19 09:46, Kai-Heng Feng wrote: Hi Tobias, On Oct 5, 2019, at 03:52, Tobias Klausmann wrote: Hello, On 04.10.19 19:36, Kai-Heng Feng wrote: Hi Tobias On Oct 4, 2019, at 18:34, Tobias Klausmann wrote: Hello all, While testing the 5.4rc1 release, i noticed my Ethernet

Re: e1000e regression - 5.4rc1

Hello, On 04.10.19 19:36, Kai-Heng Feng wrote: Hi Tobias On Oct 4, 2019, at 18:34, Tobias Klausmann wrote: Hello all, While testing the 5.4rc1 release, i noticed my Ethernet never coming fully up, seemingly having a timeout problem. While bisecting this i landed at the commit

e1000e regression - 5.4rc1

Hello all, While testing the 5.4rc1 release, i noticed my Ethernet never coming fully up, seemingly having a timeout problem. While bisecting this i landed at the commit dee23594d587386e9fda76732aa5f5a487709510 ("e1000e: Make speed detection on hotplugging cable more reliable") as the first

Re: [PATCH v2] drivers/media/dvb-frontends: Implement probe/remove for stv6110x

On 29.05.19 20:45, Joe Perches wrote: On Wed, 2019-05-29 at 18:56 +0200, Tobias Klausmann wrote: Refactor out the common parts of stv6110x_probe() and stv6110x_attach() into separate functions. This provides the needed functionality to use dvb_module_probe() instead of dvb_attach()! v2

[PATCH] drivers/media/dvb-frontends: Implement probe/remove for stv090x

Move common code into a new function. This provides the needed functionality to use dvb_module_probe() instead of dvb_attach()! Signed-off-by: Tobias Klausmann --- drivers/media/dvb-frontends/stv090x.c | 198 +++-- drivers/media/dvb-frontends/stv090x.h | 3

[PATCH v2] drivers/media/dvb-frontends: Implement probe/remove for stv6110x

Refactor out the common parts of stv6110x_probe() and stv6110x_attach() into separate functions. This provides the needed functionality to use dvb_module_probe() instead of dvb_attach()! v2: - Impovments based on comments by Sean Young - Fix checkpatch.pl --strict errors Signed-off-by: Tobias

Re: [PATCH] drivers/media/dvb-frontends: Implement probe/remove for stv6110x

Hello, answers, if appropriate, inline! On 26.05.19 11:33, Sean Young wrote: Hi Tobias, On Sun, May 12, 2019 at 04:53:06PM +0200, Tobias Klausmann wrote: Ping, comments for this patch are appreciated! Sorry for not back to you earlier. No problem, thanks for reviewing! Please run

Re: [PATCH] drivers/media/dvb-frontends: Implement probe/remove for stv6110x

Ping, comments for this patch are appreciated! Thanks, Tobias On 09.05.19 21:51, Tobias Klausmann wrote: Refactor out the common parts of stv6110x_probe() and stv6110x_attach() into separate functions. This provides the needed functionality to use dvb_module_probe() instead of dvb_attach

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On 12/18/17 7:06 PM, Mike Galbraith wrote: Greetings, Kernel bound workloads seem to trigger the below for whatever reason.  I only see this when beating up NFS.  There was a kworker wakeup latency issue, but with a bandaid applied to fix that up, I can still trigger this. Hi, i have seen

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On 12/18/17 7:06 PM, Mike Galbraith wrote: Greetings, Kernel bound workloads seem to trigger the below for whatever reason.  I only see this when beating up NFS.  There was a kworker wakeup latency issue, but with a bandaid applied to fix that up, I can still trigger this. Hi, i have seen

Re: Regression in TTM driver w/Linus' master

On 11/24/17 4:35 PM, Christian König wrote: Am 24.11.2017 um 16:17 schrieb Tobias Klausmann: On 11/24/17 3:54 PM, Daniel Vetter wrote: On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote: On 11/23/17 2:58 AM, Dave Airlie wrote: On 23 November 2017 at 11:17, Laura Abbott <l

Re: Regression in TTM driver w/Linus' master

On 11/24/17 4:35 PM, Christian König wrote: Am 24.11.2017 um 16:17 schrieb Tobias Klausmann: On 11/24/17 3:54 PM, Daniel Vetter wrote: On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote: On 11/23/17 2:58 AM, Dave Airlie wrote: On 23 November 2017 at 11:17, Laura Abbott wrote

Re: Regression in TTM driver w/Linus' master

On 11/24/17 3:54 PM, Daniel Vetter wrote: On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote: On 11/23/17 2:58 AM, Dave Airlie wrote: On 23 November 2017 at 11:17, Laura Abbott <labb...@redhat.com> wrote: Hi, Fedora QA testing reported a panic when booting up VMs usin

Re: Regression in TTM driver w/Linus' master

On 11/24/17 3:54 PM, Daniel Vetter wrote: On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote: On 11/23/17 2:58 AM, Dave Airlie wrote: On 23 November 2017 at 11:17, Laura Abbott wrote: Hi, Fedora QA testing reported a panic when booting up VMs using qmeu vga drivers (https

Re: Regression in TTM driver w/Linus' master

On 11/23/17 2:58 AM, Dave Airlie wrote: On 23 November 2017 at 11:17, Laura Abbott wrote: Hi, Fedora QA testing reported a panic when booting up VMs using qmeu vga drivers (https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ) [ 30.108507] [ cut

Re: Regression in TTM driver w/Linus' master

On 11/23/17 2:58 AM, Dave Airlie wrote: On 23 November 2017 at 11:17, Laura Abbott wrote: Hi, Fedora QA testing reported a panic when booting up VMs using qmeu vga drivers (https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ) [ 30.108507] [ cut here ] [

Re: [PATCH 17/29] drm/nouveau: switch to drm_*{get,put} helpers

Looks good to me! Reviewed-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> On 8/3/17 1:58 PM, Cihangir Akturk wrote: > drm_*_reference() and drm_*_unreference() functions are just > compatibility alias for drm_*_get() and drm_*_put() adn should not be > used by new c

Re: [PATCH 17/29] drm/nouveau: switch to drm_*{get,put} helpers

Looks good to me! Reviewed-by: Tobias Klausmann On 8/3/17 1:58 PM, Cihangir Akturk wrote: > drm_*_reference() and drm_*_unreference() functions are just > compatibility alias for drm_*_get() and drm_*_put() adn should not be > used by new code. So convert all users of compatibility

Re: [Nouveau] [PATCH] drm: disable vblank only if it got previously enabled

it up. > Otherwise we're back to the old style vblank horror show. > > Thanks, Daniel > >> On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann >> <tobias.johannes.klausm...@mni.thm.de> wrote: >>> mimic the behavior of vblank_disable_fn(), another caller of >&g

Re: [Nouveau] [PATCH] drm: disable vblank only if it got previously enabled

it up. > Otherwise we're back to the old style vblank horror show. > > Thanks, Daniel > >> On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann >> wrote: >>> mimic the behavior of vblank_disable_fn(), another caller of >>> drm_vblank_disable_and_s

[PATCH] drm: disable vblank only if it got previously enabled

b0 e8 38 fa ed c6 44 0f b6 [ 12.768508] ---[ end trace d9bb853af3659bd5 ]--- Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> --- drivers/gpu/drm/drm_vblank.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_vblank.c b/dri

[PATCH] drm: disable vblank only if it got previously enabled

b0 e8 38 fa ed c6 44 0f b6 [ 12.768508] ---[ end trace d9bb853af3659bd5 ]--- Signed-off-by: Tobias Klausmann --- drivers/gpu/drm/drm_vblank.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index a233a6

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

The conversion is a nice catch, but i'd like to have a bit more context, see below! With a better description: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> On 7/14/17 5:10 PM, Karol Herbst wrote: Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE usage we

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

The conversion is a nice catch, but i'd like to have a bit more context, see below! With a better description: Tobias Klausmann On 7/14/17 5:10 PM, Karol Herbst wrote: Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE usage we could convert to WARN_ONCE? Reviewed

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On 7/14/17 3:41 PM, Mike Galbraith wrote: On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:  All DRM did was to slip a WARN_ON_ONCE() that nouveau triggers into a kernel module where such things no longer warn, they blow the box out of the water. BTW, turn that irksome WARN_ON_ONCE()

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On 7/14/17 3:41 PM, Mike Galbraith wrote: On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:  All DRM did was to slip a WARN_ON_ONCE() that nouveau triggers into a kernel module where such things no longer warn, they blow the box out of the water. BTW, turn that irksome WARN_ON_ONCE()

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On 7/12/17 7:19 PM, Mike Galbraith wrote: On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith wrote: On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: Some display

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On 7/12/17 7:19 PM, Mike Galbraith wrote: On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith wrote: On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: Some display stuff did

Re: [PULL REQUEST] i2c for 4.12

If you find the time, please push it out to master for testing purpose! (my touchpad is broken as well: 9d6408433019bfae15e2d0d5f4498c4ff70b86c0 - i2c: designware: don't infer timings described by ACPI from clock rate) Thanks, Tobias Klausmann On 5/22/17 11:04 PM, Wolfram Sang wrote

Re: [PULL REQUEST] i2c for 4.12

If you find the time, please push it out to master for testing purpose! (my touchpad is broken as well: 9d6408433019bfae15e2d0d5f4498c4ff70b86c0 - i2c: designware: don't infer timings described by ACPI from clock rate) Thanks, Tobias Klausmann On 5/22/17 11:04 PM, Wolfram Sang wrote

Re: Question about DEC Alpha memory ordering

Hi! On Mon, 13 Feb 2017, Paul E. McKenney wrote: > On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote: > > On 2/13/17 1:39 PM, Paul E. McKenney wrote: > > > can real DEC Alpha hardware end up with both instances of "r1" > > > having the value 1? > > > > I thought this question reminded

Re: Question about DEC Alpha memory ordering

Hi! On Mon, 13 Feb 2017, Paul E. McKenney wrote: > On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote: > > On 2/13/17 1:39 PM, Paul E. McKenney wrote: > > > can real DEC Alpha hardware end up with both instances of "r1" > > > having the value 1? > > > > I thought this question reminded

Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section

On 18.12.2016 20:57, Valo, Kalle wrote: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> writes: A patch for this is already floating on the ML for a while now latest: (ath9k: do not return early to fix rcu unlocking) It's here: https://patchwork.kernel.org/patch/9472709/

Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section

On 18.12.2016 20:57, Valo, Kalle wrote: Tobias Klausmann writes: A patch for this is already floating on the ML for a while now latest: (ath9k: do not return early to fix rcu unlocking) It's here: https://patchwork.kernel.org/patch/9472709/ Good to know! Hopefully Kalle will include

Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section

Hi, A patch for this is already floating on the ML for a while now latest: (ath9k: do not return early to fix rcu unlocking) Hopefully Kalle will include it in one of his upcoming pull requests. Greetings, Tobias On 18.12.2016 16:59, Paul E. McKenney wrote: On Sun, Dec 18, 2016 at

Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section

Hi, A patch for this is already floating on the ML for a while now latest: (ath9k: do not return early to fix rcu unlocking) Hopefully Kalle will include it in one of his upcoming pull requests. Greetings, Tobias On 18.12.2016 16:59, Paul E. McKenney wrote: On Sun, Dec 18, 2016 at

[PATCH v2] ath9k: do not return early to fix rcu unlocking

_entry+0x146/0x220 [] start_secondary+0x148/0x170 Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> Fixes: d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible") Cc: <sta...@vger.kernel.org> # v4.9 --- v2: break instead of unlock (rename patch) [Felix Fiet

[PATCH v2] ath9k: do not return early to fix rcu unlocking

_entry+0x146/0x220 [] start_secondary+0x148/0x170 Signed-off-by: Tobias Klausmann Fixes: d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible") Cc: # v4.9 --- v2: break instead of unlock (rename patch) [Felix Fietkau], fix reference to commit [Kalle Valo] --- drivers/net/wireless/ath

Re: [PATCH] ath9k: unlock rcu read when returning early

On 13.12.2016 11:41, Felix Fietkau wrote: On 2016-12-12 19:50, Tobias Klausmann wrote: Starting with ath9k: use ieee80211_tx_status_noskb where possible [d94a461d7a7df68991fb9663531173f60ef89c68] the driver uses rcu_read_lock() && rcu_read_unlock() yet on returni

Re: [PATCH] ath9k: unlock rcu read when returning early

On 13.12.2016 11:41, Felix Fietkau wrote: On 2016-12-12 19:50, Tobias Klausmann wrote: Starting with ath9k: use ieee80211_tx_status_noskb where possible [d94a461d7a7df68991fb9663531173f60ef89c68] the driver uses rcu_read_lock() && rcu_read_unlock() yet on returni

[PATCH] ath9k: unlock rcu read when returning early

46/0x220 [] start_secondary+0x148/0x170 Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> --- drivers/net/wireless/ath/ath9k/xmit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c inde

[PATCH] ath9k: unlock rcu read when returning early

46/0x220 [] start_secondary+0x148/0x170 Signed-off-by: Tobias Klausmann --- drivers/net/wireless/ath/ath9k/xmit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c index 52bfbb988611..857d5ae09a1d 100644 --- a/dri

Re: ATH9 driver issues on ARM64

Hello there, as this is a thread about ath9k and ARM64, i'm not sure if i should answer here or not, but i have similar "stalls" with ath9k on x86_64 (starting with 4.9rc), stack trace is posted down below where the original ARM64 stall traces are. Greetings, Tobias On 08.12.2016 18:36,

Re: ATH9 driver issues on ARM64

Hello there, as this is a thread about ath9k and ARM64, i'm not sure if i should answer here or not, but i have similar "stalls" with ath9k on x86_64 (starting with 4.9rc), stack trace is posted down below where the original ARM64 stall traces are. Greetings, Tobias On 08.12.2016 18:36,

Re: 4.9.0-rc6+ boot problem

Hello, I can confirm certain wireless networks cause hangs (stalls - mostly swapper/n). This only happens with one network here, others are fine. I tried to bisect it but never came to an presentable result. Greetings, Tobias On 01.12.2016 17:10, Radim Krčmář wrote: 2016-11-30

Re: 4.9.0-rc6+ boot problem

Hello, I can confirm certain wireless networks cause hangs (stalls - mostly swapper/n). This only happens with one network here, others are fine. I tried to bisect it but never came to an presentable result. Greetings, Tobias On 01.12.2016 17:10, Radim Krčmář wrote: 2016-11-30

Re: Linux 4.9-rcX: rcu_preempt detected stalls on CPUs/tasks messages

recent). Best Regards, Tobias Klausmann [1]: https://homepages.thm.de/~tjkl80/dmesg4.txt [2]: https://homepages.thm.de/~tjkl80/dmesg3.txt [3]: https://homepages.thm.de/~tjkl80/dmesg2.txt [4]: https://homepages.thm.de/~tjkl80/dmesg.txt

Re: Linux 4.9-rcX: rcu_preempt detected stalls on CPUs/tasks messages

recent). Best Regards, Tobias Klausmann [1]: https://homepages.thm.de/~tjkl80/dmesg4.txt [2]: https://homepages.thm.de/~tjkl80/dmesg3.txt [3]: https://homepages.thm.de/~tjkl80/dmesg2.txt [4]: https://homepages.thm.de/~tjkl80/dmesg.txt

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

On 26.11.2014 21:29, Michael Marineau wrote: On Mon, Nov 24, 2014 at 11:43 PM, Maarten Lankhorst wrote: Hey, Op 22-11-14 om 21:16 schreef Michael Marineau: On Nov 22, 2014 11:45 AM, "Michael Marineau" wrote: On Nov 22, 2014 8:56 AM, "Maarten Lankhorst" < maarten.lankho...@canonical.com>

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

On 26.11.2014 21:29, Michael Marineau wrote: On Mon, Nov 24, 2014 at 11:43 PM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Hey, Op 22-11-14 om 21:16 schreef Michael Marineau: On Nov 22, 2014 11:45 AM, Michael Marineau m...@marineau.org wrote: On Nov 22, 2014 8:56 AM, Maarten

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

On 19.11.2014 09:10, Maarten Lankhorst wrote: ... On the EDITED patch from fixed-fences-for-bisect, can you do the following: In nouveau/nv84_fence.c function nv84_fence_context_new, remove fctx->base.sequence = nv84_fence_read(chan); and add back nouveau_bo_wr32(priv->bo, chan->chid * 16/4,

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

On 19.11.2014 09:10, Maarten Lankhorst wrote: Hey, On 19-11-14 07:43, Michael Marineau wrote: On 3.18-rc kernel's I have been intermittently experiencing GPU lockups shortly after startup, accompanied with one or both of the following errors: nouveau E[ PFIFO][:01:00.0] read fault at

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

On 19.11.2014 09:10, Maarten Lankhorst wrote: Hey, On 19-11-14 07:43, Michael Marineau wrote: On 3.18-rc kernel's I have been intermittently experiencing GPU lockups shortly after startup, accompanied with one or both of the following errors: nouveau E[ PFIFO][:01:00.0] read fault at

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

On 19.11.2014 09:10, Maarten Lankhorst wrote: ... On the EDITED patch from fixed-fences-for-bisect, can you do the following: In nouveau/nv84_fence.c function nv84_fence_context_new, remove fctx-base.sequence = nv84_fence_read(chan); and add back nouveau_bo_wr32(priv-bo, chan-chid * 16/4,

Re: [BUG] x86: reboot doesn't reboot

be related. If I can help in any way, let me konw! Thanks, Tobias Klausmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FA

Re: [BUG] x86: reboot doesn't reboot

seconds, so this may be related. If I can help in any way, let me konw! Thanks, Tobias Klausmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

Re: [Nouveau] 3.12rc1-pre Nouveau? oops

On 09.09.2013 00:29, Dave Airlie wrote: On Mon, Sep 9, 2013 at 8:01 AM, Tobias Klausmann wrote: On 08.09.2013 23:33, Dave Airlie wrote: Looks like you have Optimus (intel + nvidia), and the backtrace has runtime pm in it, which is something new Dave added for 3.12, adding him in explicitly

Re: [Nouveau] 3.12rc1-pre Nouveau? oops

On 08.09.2013 23:33, Dave Airlie wrote: Looks like you have Optimus (intel + nvidia), and the backtrace has runtime pm in it, which is something new Dave added for 3.12, adding him in explicitly. The simplest explanation is that disp->init is NULL. And it seems like there are no outputs from

[PATCH] Bail in nouveau_display_resume() if there are no output available!

--- drivers/gpu/drm/nouveau/nouveau_display.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index d2712e6..a4ba734 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++

Re: 3.12rc1-pre Nouveau? oops

> Looks like you have Optimus (intel + nvidia), and the backtrace has > runtime pm in it, which is something new Dave added for 3.12, adding > him in explicitly. The simplest explanation is that disp->init is > NULL. And it seems like there are no outputs from the earlier nouveau > init prints. I

Re: 3.12rc1-pre Nouveau? oops

Looks like you have Optimus (intel + nvidia), and the backtrace has runtime pm in it, which is something new Dave added for 3.12, adding him in explicitly. The simplest explanation is that disp-init is NULL. And it seems like there are no outputs from the earlier nouveau init prints. I guess

[PATCH] Bail in nouveau_display_resume() if there are no output available!

--- drivers/gpu/drm/nouveau/nouveau_display.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index d2712e6..a4ba734 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++

Re: [Nouveau] 3.12rc1-pre Nouveau? oops

On 08.09.2013 23:33, Dave Airlie wrote: Looks like you have Optimus (intel + nvidia), and the backtrace has runtime pm in it, which is something new Dave added for 3.12, adding him in explicitly. The simplest explanation is that disp-init is NULL. And it seems like there are no outputs from the

Re: [Nouveau] 3.12rc1-pre Nouveau? oops

On 09.09.2013 00:29, Dave Airlie wrote: On Mon, Sep 9, 2013 at 8:01 AM, Tobias Klausmann tobias.johannes.klausm...@mni.thm.de wrote: On 08.09.2013 23:33, Dave Airlie wrote: Looks like you have Optimus (intel + nvidia), and the backtrace has runtime pm in it, which is something new Dave added

I915 DRI_PRIME Bug Resend

0x90 [i915] [] ? dma_buf_release+0x23/0x80 [] ? __fput+0xcd/0x230 [] ? task_work_run+0x97/0xd0 [] ? do_notify_resume+0x79/0xa0 [] ? int_signal+0x12/0x17 ---[ end trace 99a0c147e69ddcd1 ]--- Thanks, Tobias Klausmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in t

I915 DRI_PRIME Bug Resend

99a0c147e69ddcd1 ]--- Thanks, Tobias Klausmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 3.11-rc2

On 22.07.2013 15:08, Rafael J. Wysocki wrote: On Sunday, July 21, 2013 11:07:03 PM Tobias Klausmann wrote: On 21.07.2013 21:53, Linus Torvalds wrote: So it's been another week, and -rc2 is out there. ... (b) we had a late change to how ACPI backlight handling is done on certain machines

Re: Linux 3.11-rc2

On 22.07.2013 15:08, Rafael J. Wysocki wrote: On Sunday, July 21, 2013 11:07:03 PM Tobias Klausmann wrote: On 21.07.2013 21:53, Linus Torvalds wrote: So it's been another week, and -rc2 is out there. ... (b) we had a late change to how ACPI backlight handling is done on certain machines

Re: Linux 3.11-rc2

I'm mentioning this explicitly. This pach finally fixes my backlight control! Thanks! Tobias Klausmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

Re: Linux 3.11-rc2

I'm mentioning this explicitly. This pach finally fixes my backlight control! Thanks! Tobias Klausmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds

Hi! On a whim, I tried fiddling with ALPHA_LEGACY_START_ADDRESS. While this necessitates switching the system type to GENERIC_ALPHA, it makes the whole thing work. I suspect the change in segment size shifted stuff around enough to make the DP264 layout a "legacy" one. Regards, Tobias --

Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds

Hi! On a whim, I tried fiddling with ALPHA_LEGACY_START_ADDRESS. While this necessitates switching the system type to GENERIC_ALPHA, it makes the whole thing work. I suspect the change in segment size shifted stuff around enough to make the DP264 layout a legacy one. Regards, Tobias --

Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds

Hi! On Tue, 26 Mar 2013, Michael Cree wrote: > On 26/03/2013, at 4:09 AM, Tobias Klausmann wrote: > > On Mon, 25 Mar 2013, Will Deacon wrote: > >> Any news on these? I've included an updated version of the first > >> patch, with > >> the Tested-by-ta

Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds

Hi! On Tue, 26 Mar 2013, Michael Cree wrote: On 26/03/2013, at 4:09 AM, Tobias Klausmann wrote: On Mon, 25 Mar 2013, Will Deacon wrote: Any news on these? I've included an updated version of the first patch, with the Tested-by-tag and a tweaked commit message below. As a data

Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds

Hi! On Mon, 25 Mar 2013, Will Deacon wrote: > Any news on these? I've included an updated version of the first patch, with > the Tested-by-tag and a tweaked commit message below. As a data point, I tried vanilla 3.8.4 on the weekend. With my usual config on a UP1500, it will fail at build time

Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds

Hi! On Mon, 25 Mar 2013, Will Deacon wrote: Any news on these? I've included an updated version of the first patch, with the Tested-by-tag and a tweaked commit message below. As a data point, I tried vanilla 3.8.4 on the weekend. With my usual config on a UP1500, it will fail at build time

Re: [PATCH 00/11] rcu: Add missing RCU idle APIs on idle loop v2

Hi! On Mon, 10 Sep 2012, Frederic Weisbecker wrote: > > AFAICT, schedule_preempt_disabled() was only introduced in 3.4 > > and thus needs to be backported for 3.3. > > Please try with this instead: > > preempt_enable_no_resched(); > schedule(); > preempt_disable(); > >

Re: [PATCH 00/11] rcu: Add missing RCU idle APIs on idle loop v2

Hi! On Mon, 10 Sep 2012, Frederic Weisbecker wrote: AFAICT, schedule_preempt_disabled() was only introduced in 3.4 and thus needs to be backported for 3.3. Please try with this instead: preempt_enable_no_resched(); schedule(); preempt_disable(); Thanks. While it

Re: [PATCH 00/11] rcu: Add missing RCU idle APIs on idle loop v2

Hi! On Sat, 25 Aug 2012, Paul E. McKenney wrote: > Both Alpha patches should apply as-is back to 3.3, and should also fix > the problem. Could you please check this on the versions of interest? I just now tried them on top of 3.3.8 from linux-stable.git. While they apply cleanly, I get a

Re: [PATCH 00/11] rcu: Add missing RCU idle APIs on idle loop v2

Hi! On Sat, 25 Aug 2012, Paul E. McKenney wrote: Both Alpha patches should apply as-is back to 3.3, and should also fix the problem. Could you please check this on the versions of interest? I just now tried them on top of 3.3.8 from linux-stable.git. While they apply cleanly, I get a compile