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
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
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
b
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
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
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
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
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
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
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
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
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 ]
[ 3
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
fix 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_
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
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?
R
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() in
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 change
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
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 me
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 in
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 02:52:4
_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
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 returning
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
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, K
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 14:20-0800,
er ones as they were 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
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>
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,
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 0x0
system needs several
minutes to reboot instead of some 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
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
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
---
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
+++ b/drivers
> 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
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
the
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 mac
nful before, so 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 ht
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
--
Se
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-
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 w
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
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 compil
44 matches
Mail list logo
