Booting kernel 3.15-rc2 on an AOpen i915GMm-hfs, I see the framebuffer broken.
Only about the upper left quarter of the monitor is used for displaying the
boot messages,
these (and the cursor) are replicated at the right of that area.
Approximately the lower half of the monitor stays black. The
Booting kernel 3.15-rc2 on an AOpen i915GMm-hfs, I see the framebuffer broken.
Only about the upper left quarter of the monitor is used for displaying the
boot messages,
these (and the cursor) are replicated at the right of that area.
Approximately the lower half of the monitor stays black. The
Rebooting after a power failure on an openSuSE 13.1 system
with kernel 3.13.0-rc6 triggered the attached lockdep warning.
cu,
Knut
[ 73.385211] REISERFS (device sdb4): checking transaction log (sdb4)
[ 73.465261] REISERFS (device sdb4): Using r5 hash to sort names
[ 73.533218] REISERFS
Rebooting after a power failure on an openSuSE 13.1 system
with kernel 3.13.0-rc6 triggered the attached lockdep warning.
cu,
Knut
[ 73.385211] REISERFS (device sdb4): checking transaction log (sdb4)
[ 73.465261] REISERFS (device sdb4): Using r5 hash to sort names
[ 73.533218] REISERFS
On 17.12.2013 19:59, Eric Dumazet wrote:
On Tue, 2013-12-17 at 19:13 +0100, Knut Petersen wrote:
Hi Linus / everybody!
Booting openSuSE 13.1 with kernel 3.13.0-rc4 triggers the attached
warning.
cu,
Knut
Following patch should solve the issue.
http://patchwork.ozlabs.org/patch/301382
Hi Linus / everybody!
Booting openSuSE 13.1 with kernel 3.13.0-rc4 triggers the attached
warning.
cu,
Knut
golem kernel: [ 25.324096]
golem kernel: [ 25.326525] =
golem kernel: [ 25.328009] [ INFO: inconsistent lock state ]
golem kernel: [ 25.328009]
Hi Linus / everybody!
Booting openSuSE 13.1 with kernel 3.13.0-rc4 triggers the attached
warning.
cu,
Knut
golem kernel: [ 25.324096]
golem kernel: [ 25.326525] =
golem kernel: [ 25.328009] [ INFO: inconsistent lock state ]
golem kernel: [ 25.328009]
On 17.12.2013 19:59, Eric Dumazet wrote:
On Tue, 2013-12-17 at 19:13 +0100, Knut Petersen wrote:
Hi Linus / everybody!
Booting openSuSE 13.1 with kernel 3.13.0-rc4 triggers the attached
warning.
cu,
Knut
Following patch should solve the issue.
http://patchwork.ozlabs.org/patch/301382
On 28.10.2013 16:16, Ingo Molnar wrote:
* Ingo Molnar wrote:
I tried that patch, together with all the kobj debug options
enabled. With that kernel configuration I was unable to
reproduce the problem during 500 typical workload / reboot
cycles. Without the debug options I was able to
On 25.10.2013 11:02, Linus Torvalds wrote:
Adding more people, so quoting the whole email for them.
We definitely have some module unload issues. Guys, try the following
a few times to unload modules:
lsmod | grep ' 0 '| cut -d' ' -f1 | xargs sudo rmmod
(a few times because unloading one
On 26.10.2013 13:43, Ingo Molnar wrote:
* Linus Torvalds wrote:
On Fri, Oct 25, 2013 at 11:23 AM, Thomas Gleixner wrote:
Enable DEBUG_OBJECTS, DEBUG_OBJECTS_FREE, DEBUG_OBJECTS_TIMERS
Yes, but nobody has actually been able to trigger it with those.
It's pretty rare, and the debug options
On 26.10.2013 13:43, Ingo Molnar wrote:
* Linus Torvalds torva...@linux-foundation.org wrote:
On Fri, Oct 25, 2013 at 11:23 AM, Thomas Gleixner t...@linutronix.de wrote:
Enable DEBUG_OBJECTS, DEBUG_OBJECTS_FREE, DEBUG_OBJECTS_TIMERS
Yes, but nobody has actually been able to trigger it with
On 25.10.2013 11:02, Linus Torvalds wrote:
Adding more people, so quoting the whole email for them.
We definitely have some module unload issues. Guys, try the following
a few times to unload modules:
lsmod | grep ' 0 '| cut -d' ' -f1 | xargs sudo rmmod
(a few times because unloading one
On 28.10.2013 16:16, Ingo Molnar wrote:
* Ingo Molnar mi...@kernel.org wrote:
I tried that patch, together with all the kobj debug options
enabled. With that kernel configuration I was unable to
reproduce the problem during 500 typical workload / reboot
cycles. Without the debug options I was
On 15.10.2013 02:59, Paul E. McKenney wrote:
On Mon, Oct 14, 2013 at 04:16:03PM -0700, Paul E. McKenney wrote:
On Mon, Oct 14, 2013 at 11:52:48PM +0200, Knut Petersen wrote:
On 14.10.2013 23:28, Paul E. McKenney wrote:
On Mon, Oct 14, 2013 at 10:53:03AM -0700, Linus Torvalds wrote:
I´ll run
On 15.10.2013 08:40, Ingo Molnar wrote:
* Frederic Weisbecker wrote:
I've been thinking that CONFIG_DEBUG_LIST could help. Unfortunately it's
good to spot list APIs misuse but, if Linus is right, the problem may be
that the list belongs to an object that has been freed, and I believe
that
On 15.10.2013 08:40, Ingo Molnar wrote:
* Frederic Weisbecker fweis...@gmail.com wrote:
I've been thinking that CONFIG_DEBUG_LIST could help. Unfortunately it's
good to spot list APIs misuse but, if Linus is right, the problem may be
that the list belongs to an object that has been freed, and
On 15.10.2013 02:59, Paul E. McKenney wrote:
On Mon, Oct 14, 2013 at 04:16:03PM -0700, Paul E. McKenney wrote:
On Mon, Oct 14, 2013 at 11:52:48PM +0200, Knut Petersen wrote:
On 14.10.2013 23:28, Paul E. McKenney wrote:
On Mon, Oct 14, 2013 at 10:53:03AM -0700, Linus Torvalds wrote:
I´ll run
On 14.10.2013 23:51, Frederic Weisbecker wrote:
On Mon, Oct 14, 2013 at 02:28:30PM -0700, Paul E. McKenney wrote:
On Mon, Oct 14, 2013 at 10:53:03AM -0700, Linus Torvalds wrote:
Hmm. No obvious ideas come to mind, but I'm adding more people to the cc.
Clearly the
On 14.10.2013 23:51, Frederic Weisbecker wrote:
On Mon, Oct 14, 2013 at 02:28:30PM -0700, Paul E. McKenney wrote:
On Mon, Oct 14, 2013 at 10:53:03AM -0700, Linus Torvalds wrote:
Hmm. No obvious ideas come to mind, but I'm adding more people to the cc.
Clearly the
Commit-ID: 723478c8a471403c53cf144999701f6e0c4bbd11
Gitweb: http://git.kernel.org/tip/723478c8a471403c53cf144999701f6e0c4bbd11
Author: Knut Petersen
AuthorDate: Wed, 25 Sep 2013 14:29:37 +0200
Committer: Ingo Molnar
CommitDate: Fri, 4 Oct 2013 10:06:07 +0200
perf: Enforce 1 as lower
Commit-ID: 723478c8a471403c53cf144999701f6e0c4bbd11
Gitweb: http://git.kernel.org/tip/723478c8a471403c53cf144999701f6e0c4bbd11
Author: Knut Petersen knut_peter...@t-online.de
AuthorDate: Wed, 25 Sep 2013 14:29:37 +0200
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 4 Oct 2013
rom 4ef9dabdd27a02e2ebd45c2d98afda7e43e82ab3 Mon Sep 17 00:00:00 2001
From: Knut Petersen
Date: Wed, 25 Sep 2013 14:29:37 +0200
Subject: [PATCH] Enforce 1 as lower limit for perf_event_max_sample_rate
/proc/sys/kernel/perf_event_max_sample_rate will accept
negative values as well as 0.
Negative values are unreasonable, and 0 cau
rom 7f468bd7bad2f2fec2e93c89a48008d1cba99001 Mon Sep 17 00:00:00 2001
From: Knut Petersen
Date: Wed, 25 Sep 2013 13:34:57 +0200
Subject: [PATCH] Enforce 1 as lower limit for perf_event_max_sample_rate
/proc/sys/kernel/perf_event_max_sample_rate will accept
negative values as well as 0.
Negat
7f468bd7bad2f2fec2e93c89a48008d1cba99001 Mon Sep 17 00:00:00 2001
From: Knut Petersen knut_peter...@t-online.de
Date: Wed, 25 Sep 2013 13:34:57 +0200
Subject: [PATCH] Enforce 1 as lower limit for perf_event_max_sample_rate
/proc/sys/kernel/perf_event_max_sample_rate will accept
negative values
4ef9dabdd27a02e2ebd45c2d98afda7e43e82ab3 Mon Sep 17 00:00:00 2001
From: Knut Petersen knut_peter...@t-online.de
Date: Wed, 25 Sep 2013 14:29:37 +0200
Subject: [PATCH] Enforce 1 as lower limit for perf_event_max_sample_rate
/proc/sys/kernel/perf_event_max_sample_rate will accept
negative values as well as 0.
Negative values
XME
comment for now.
Reported-by: Knut Petersen
Cc: Knut Petersen
Cc: Imre Deak
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_tv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index f2c6
for now.
Reported-by: Knut Petersen knut_peter...@t-online.de
Cc: Knut Petersen knut_peter...@t-online.de
Cc: Imre Deak imre.d...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_tv.c | 8
1 file
On 19.09.2013 08:57, Daniel Vetter wrote:
On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner wrote:
No, that's wrong. ->count_objects should never ass SHRINK_STOP.
Indeed, it should always return a count of objects in the cache,
regardless of the context.
SHRINK_STOP is for ->scan_objects to tell
On 19.09.2013 08:57, Daniel Vetter wrote:
On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner da...@fromorbit.com wrote:
No, that's wrong. -count_objects should never ass SHRINK_STOP.
Indeed, it should always return a count of objects in the cache,
regardless of the context.
SHRINK_STOP is for
Looking at the patch which introduced these error message for you, which
changed the ->count_objects return value from 0 to SHRINK_STOP your patch
below to treat 0 and SHRINK_STOP equally simply reverts the functional
change.
Yes, for i915* it de facto restores the old behaviour.
I don't
>From 75ae570ce7b0bb6b40c76beb18fc075e9af3127a Mon Sep 17 00:00:00 2001
From: Knut Petersen
Date: Wed, 18 Sep 2013 12:06:33 +0200
Subject: [PATCH] mm: respect SHRINK_STOP in shrink_slab_node()
Since commit 81e49f811404f428a9d9a63295a0c267e802fa12
i915_gem_inactive_count() might return SHRINK_STOP.
Unfortunately SHRINK_STOP is no
75ae570ce7b0bb6b40c76beb18fc075e9af3127a Mon Sep 17 00:00:00 2001
From: Knut Petersen knut_peter...@t-online.de
Date: Wed, 18 Sep 2013 12:06:33 +0200
Subject: [PATCH] mm: respect SHRINK_STOP in shrink_slab_node()
Since commit 81e49f811404f428a9d9a63295a0c267e802fa12
i915_gem_inactive_count() might return SHRINK_STOP.
Unfortunately
Looking at the patch which introduced these error message for you, which
changed the -count_objects return value from 0 to SHRINK_STOP your patch
below to treat 0 and SHRINK_STOP equally simply reverts the functional
change.
Yes, for i915* it de facto restores the old behaviour.
I don't
Hi everybody!
Since Sep 13 linux git master kernels started to complain about a new problem:
"shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative objects to delete nr="
Hardware: Aopen i915GMm-hfs, Pentium M, 2GB RAM
More information available on request.
cu,
Knut
--
To unsubscribe from
Hi everybody!
Since Sep 13 linux git master kernels started to complain about a new problem:
shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative objects to delete nr=negative
number
Hardware: Aopen i915GMm-hfs, Pentium M, 2GB RAM
More information available on request.
cu,
Knut
--
To
On 10.09.2013 11:44, Daniel Vetter wrote:
Thanks. Combined with your two patches and Jesse Barnes' patch
"add early quirk for reserving Intel graphics stolen memory v5",
current linux master branch works fine on i915GM hardware now.
cu,
Knut
--
To unsubscribe from this list: send the line
On 10.09.2013 11:44, Daniel Vetter wrote:
Thanks. Combined with your two patches and Jesse Barnes' patch
add early quirk for reserving Intel graphics stolen memory v5,
current linux master branch works fine on i915GM hardware now.
cu,
Knut
--
To unsubscribe from this list: send the line
On 07.09.2013 06:19, Hillf Danton wrote:
If it works after reverting commit,
3eaba51cd399f5362a9fd9ebd5fb8b625b454271
drm/i915: Don't call encoder's get_config unless encoder is active
Hmm, after reverting 3eaba51cd399f5362a9fd9ebd5fb8b625b454271 I still see:
[ 2.259897]
On 07.09.2013 06:19, Hillf Danton wrote:
If it works after reverting commit,
3eaba51cd399f5362a9fd9ebd5fb8b625b454271
drm/i915: Don't call encoder's get_config unless encoder is active
Hmm, after reverting 3eaba51cd399f5362a9fd9ebd5fb8b625b454271 I still see:
[ 2.259897]
Someone might be interested ... kernel 2e032852245b3dcfe5461d7353e34eb6da095ccf.
[0.00] Linux version 3.11.0-main+ (k...@linux-ktth.site) (gcc version
4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #34 PREEMPT Fri
Sep 6 09:46:35 CEST 2013
[2.258908] Linux agpgart
Someone might be interested ... kernel 2e032852245b3dcfe5461d7353e34eb6da095ccf.
[0.00] Linux version 3.11.0-main+ (k...@linux-ktth.site) (gcc version
4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #34 PREEMPT Fri
Sep 6 09:46:35 CEST 2013
[2.258908] Linux agpgart
Hi Linus!
It would be nice to have head cx88fix of git.linuxtv.org/hverkuil/media_tree.git
(git.linuxtv.org/hverkuil/media_tree.git/commit/5dce3635bf803cfe9dde84e00f5f9594439e6c02)
in 3.11 as it is a trivial and tested fix for a regression introduced between
3.10 and 3.11-rc1.
see
Hi Linus!
It would be nice to have head cx88fix of git.linuxtv.org/hverkuil/media_tree.git
(git.linuxtv.org/hverkuil/media_tree.git/commit/5dce3635bf803cfe9dde84e00f5f9594439e6c02)
in 3.11 as it is a trivial and tested fix for a regression introduced between
3.10 and 3.11-rc1.
see
On 27.08.2013 11:51, Hans Verkuil wrote:
On 08/27/2013 11:35 AM, Knut Petersen wrote:
On 27.08.2013 09:26, Hans Verkuil wrote:
On 08/25/2013 05:45 PM, Knut Petersen wrote:
Booting current git kernel dmesg shows a set of new warnings:
"wm8775 9-001b: I2C: cannot write ??? to regis
On 27.08.2013 09:26, Hans Verkuil wrote:
On 08/25/2013 05:45 PM, Knut Petersen wrote:
Booting current git kernel dmesg shows a set of new warnings:
"wm8775 9-001b: I2C: cannot write ??? to register R??"
Nevertheless, the hardware seems to work fine.
This is a new problem,
On 27.08.2013 09:26, Hans Verkuil wrote:
On 08/25/2013 05:45 PM, Knut Petersen wrote:
Booting current git kernel dmesg shows a set of new warnings:
wm8775 9-001b: I2C: cannot write ??? to register R??
Nevertheless, the hardware seems to work fine.
This is a new problem, introduced
On 27.08.2013 11:51, Hans Verkuil wrote:
On 08/27/2013 11:35 AM, Knut Petersen wrote:
On 27.08.2013 09:26, Hans Verkuil wrote:
On 08/25/2013 05:45 PM, Knut Petersen wrote:
Booting current git kernel dmesg shows a set of new warnings:
wm8775 9-001b: I2C: cannot write ??? to register R
As long as I use the "Hauppauge WinTV Nova-HD-S2", nobody seems to be
really interested in silencing deadlock warnings triggered by dvb_device_open().
dvb lockdep problems are old, but they still exist.
See:
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/27027
[
As long as I use the Hauppauge WinTV Nova-HD-S2, nobody seems to be
really interested in silencing deadlock warnings triggered by dvb_device_open().
dvb lockdep problems are old, but they still exist.
See:
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/27027
[
Booting current git kernel dmesg shows a set of new warnings:
"wm8775 9-001b: I2C: cannot write ??? to register R??"
Nevertheless, the hardware seems to work fine.
This is a new problem, introduced after kernel 3.10.
If necessary I can bisect.
dmesg snippet:
[ 11.841431] Linux video
Booting current git kernel dmesg shows a set of new warnings:
wm8775 9-001b: I2C: cannot write ??? to register R??
Nevertheless, the hardware seems to work fine.
This is a new problem, introduced after kernel 3.10.
If necessary I can bisect.
dmesg snippet:
[ 11.841431] Linux video
Executing "divertctrl wait interrogate HiSax cfu 99 0" occasionally
triggers a kernel bug in kernel 3.10. The same problem is present in
kernel 3.9.x and was already reported to lkml on May 9, 2013.
cu,
Knut
[ 284.593070] [ cut here ]
[ 284.593137] kernel BUG at
Executing divertctrl wait interrogate HiSax cfu 99 0 occasionally
triggers a kernel bug in kernel 3.10. The same problem is present in
kernel 3.9.x and was already reported to lkml on May 9, 2013.
cu,
Knut
[ 284.593070] [ cut here ]
[ 284.593137] kernel BUG at
During booting kernel 3.9.4 on an AOpen i915GMm-hfs, Pentium-M Dothan 2GHz, 2GB
RAM
system the "pipe_off wait timed out" warning was triggered. Reproducibility:
low, problem was
found only once.
cu,
Knut
[ 16.276006] =
[ 16.276006] [ INFO:
During booting kernel 3.9.4 on an AOpen i915GMm-hfs, Pentium-M Dothan 2GHz, 2GB
RAM
system the pipe_off wait timed out warning was triggered. Reproducibility:
low, problem was
found only once.
cu,
Knut
[ 16.276006] =
[ 16.276006] [ INFO:
After compiling kernel 3.9.1 I found that a script containing a
number of divertctrl commands triggered a kernel bug: (MSNs edited)
divertctrl wait interrogate HiSax cfu 123456 0
divertctrl wait interrogate HiSax cfu 1234567 0
[...]
I tried the script with kernel 3.9.0 and found the
After compiling kernel 3.9.1 I found that a script containing a
number of divertctrl commands triggered a kernel bug: (MSNs edited)
divertctrl wait interrogate HiSax cfu 123456 0
divertctrl wait interrogate HiSax cfu 1234567 0
[...]
I tried the script with kernel 3.9.0 and found the
Maybe somebody could have at that old locking warning:
[9.761427] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 loaded
[9.782848] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded
[9.794205] input: HDA Digital PCBeep as
/devices/pci:00/:00:1b.0/input/input5
[
Maybe somebody could have at that old locking warning:
[9.761427] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 loaded
[9.782848] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded
[9.794205] input: HDA Digital PCBeep as
/devices/pci:00/:00:1b.0/input/input5
[
Someone might be interested ...
A kernel build in parallel to a dvb-s recording resulted in the following log
entry:
[117284.040009] BUG: soft lockup - CPU#0 stuck for 23s! [cc1:2657]
[117284.040009] Modules linked in: ipt_MASQUERADE xt_pkttype xt_TCPMSS xt_tcpudp xt_LOG xt_limit iptable_nat
Someone might be interested ...
A kernel build in parallel to a dvb-s recording resulted in the following log
entry:
[117284.040009] BUG: soft lockup - CPU#0 stuck for 23s! [cc1:2657]
[117284.040009] Modules linked in: ipt_MASQUERADE xt_pkttype xt_TCPMSS xt_tcpudp xt_LOG xt_limit iptable_nat
. to be able to
access the opensuse bugzilla I will not report bugs there.
cu,
Knut
On 22.11.2012 16:37, Chris Wilson wrote:
On Thu, 22 Nov 2012 16:29:08 +0100, Knut Petersen
wrote:
Hi Chris!
Problem:
===
Slowdown of system, missing icons after 16 days kernel uptime and 12 days
Xserver
. to be able to
access the opensuse bugzilla I will not report bugs there.
cu,
Knut
On 22.11.2012 16:37, Chris Wilson wrote:
On Thu, 22 Nov 2012 16:29:08 +0100, Knut Petersen knut_peter...@t-online.de
wrote:
Hi Chris!
Problem:
===
Slowdown of system, missing icons after 16 days kernel uptime
On 22.11.2012 16:37, Chris Wilson wrote:
Well you kernel and drm has all the latest protections, which is good because it's usually a bo leak of some sort. First stop is to check xrestop, /sys/kernel/debug/dri/0/i915_gem_objects and intel-gpu-tools/scripts/who.sh That will undoubtably reveal a
On 22.11.2012 16:37, Chris Wilson wrote:
Well you kernel and drm has all the latest protections, which is good because it's usually a bo leak of some sort. First stop is to check xrestop, /sys/kernel/debug/dri/0/i915_gem_objects and intel-gpu-tools/scripts/who.sh That will undoubtably reveal a
Hi Chris!
Problem:
===
Slowdown of system, missing icons after 16 days kernel uptime and 12 days
Xserver uptime.
Xorg log: flooded with "(WW) intel(0): intel_uxa_prepare_access: bo map (use gtt? 1,
access 1) failed: No space left on device" lines
dmesg: flooded with
Hi Chris!
Problem:
===
Slowdown of system, missing icons after 16 days kernel uptime and 12 days
Xserver uptime.
Xorg log: flooded with (WW) intel(0): intel_uxa_prepare_access: bo map (use gtt? 1,
access 1) failed: No space left on device lines
dmesg: flooded with
Hi!
On an AOpen i915GMm-hfs a monitor connected to DVI-1 works well with both
kernel 3.4.7 and 3.5.
A monitor connected to VGA-1 boots to 1280x1024 with kernel 3.4.7 and 1024x768
with kernel 3.5.
kernel 3.5
<7>[3.132038] [drm:drm_helper_probe_single_connector_modes],
as the only relevant changes are
those from / to connector_status_connected.
cu,
Knut
>From f631128c46f916eb58bbdabf867248a04a0d2fc5 Mon Sep 17 00:00:00 2001
From: Knut Petersen
Date: Thu, 2 Aug 2012 08:52:04 +0200
Subject: [PATCH] drm: ignore disconnected <-> unknown status changes
Only
as the only relevant changes are
those from / to connector_status_connected.
cu,
Knut
From f631128c46f916eb58bbdabf867248a04a0d2fc5 Mon Sep 17 00:00:00 2001
From: Knut Petersen knut_peter...@t-online.de
Date: Thu, 2 Aug 2012 08:52:04 +0200
Subject: [PATCH] drm: ignore disconnected - unknown status
Hi!
On an AOpen i915GMm-hfs a monitor connected to DVI-1 works well with both
kernel 3.4.7 and 3.5.
A monitor connected to VGA-1 boots to 1280x1024 with kernel 3.4.7 and 1024x768
with kernel 3.5.
kernel 3.5
7[3.132038] [drm:drm_helper_probe_single_connector_modes],
I hit the following problem during a heavy compile job on kernel 3.4.5:
Jul 17 20:29:59 golem kernel: [27408.140718] [ cut here
]
Jul 17 20:29:59 golem kernel: [27408.140739] WARNING: at
kernel/mutex-debug.c:106 mutex_destroy+0x35/0x3f()
Jul 17 20:29:59 golem kernel:
I hit the following problem during a heavy compile job on kernel 3.4.5:
Jul 17 20:29:59 golem kernel: [27408.140718] [ cut here
]
Jul 17 20:29:59 golem kernel: [27408.140739] WARNING: at
kernel/mutex-debug.c:106 mutex_destroy+0x35/0x3f()
Jul 17 20:29:59 golem kernel:
Len Brown :
>
>
> Thanks for the sighting, Knut!
> This regression is dramatic when put in the terms of 50% performance hit!
> I guess the good news is that thermal throttling is doing the job
> we are asking it to:-)
>
>
>
Thermal management by cpufreq is working really fine ;-)
My problems
Len Brown :
Thanks for the sighting, Knut!
This regression is dramatic when put in the terms of 50% performance hit!
I guess the good news is that thermal throttling is doing the job
we are asking it to:-)
Thermal management by cpufreq is working really fine ;-)
My problems are
Thomas Renninger wrote:
>> mainboard: AOpen i915GMm-hfs, AWARD BIOS
>> cpu: Pentium-M 750 (0.8 to 1.86 MHz)
>> openSuSE 10.2 with kernel 2.6.22.1
> Is this a DELL laptop that gets throttled by 75% to throttling state 6
> if 60 degrees are exceeded?
No, it is a Pentium M desktop board.:
Chipset
e questionable commit without
changes,
would it be acceptable to make rw trip_points a kernel config option?
cu,
Knut Petersen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ker
,
would it be acceptable to make rw trip_points a kernel config option?
cu,
Knut Petersen
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
Thomas Renninger wrote:
mainboard: AOpen i915GMm-hfs, AWARD BIOS
cpu: Pentium-M 750 (0.8 to 1.86 MHz)
openSuSE 10.2 with kernel 2.6.22.1
Is this a DELL laptop that gets throttled by 75% to throttling state 6
if 60 degrees are exceeded?
No, it is a Pentium M desktop board.:
Chipset i915GM,
The special case for s_pitch == 2 saves about 270 ms system time (2120 ->
1850ms)
with a 16x30 font.
Compared to what? How much is the function call overhead?
Your version of the inline code inserted after an if (idx==2) in
bit_putcs against my version of the
inline code.
cu,
knut
Hi Roman!
+static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, +
u32 s_pitch, u32 height)
+{
+ int i, j;
+
+ if (likely(s_pitch==1))
+ for(i=0; i < height; i++)
+ dst[d_pitch*i] = src[i];
I added the multiply back
Something like below, which has the advantange that there is still only
one implementation of the function
True, that´s a great advantage.
and if it's still slower, we really need to check the compiler
Please have a look at the following patch. It takes your idea of
inlining but moves
Something like below, which has the advantange that there is still only
one implementation of the function
True, that´s a great advantage.
and if it's still slower, we really need to check the compiler
Please have a look at the following patch. It takes your idea of
inlining but moves
Hi Roman!
+static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, +
u32 s_pitch, u32 height)
+{
+ int i, j;
+
+ if (likely(s_pitch==1))
+ for(i=0; i height; i++)
+ dst[d_pitch*i] = src[i];
I added the multiply back
The special case for s_pitch == 2 saves about 270 ms system time (2120 -
1850ms)
with a 16x30 font.
Compared to what? How much is the function call overhead?
Your version of the inline code inserted after an if (idx==2) in
bit_putcs against my version of the
inline code.
cu,
knut
Hi Roman,
Could you try the patch below, for a few extra cycles you might want to
make it an inline function.
No, it does not help. If there is any difference, it is too small to be
measured on
my system ... and my system does run at 1000 Hz.
After 2.6.12 fb_pad_aligned_buffer() was
Probably you can make it even faster by avoiding the multiplication, like
unsigned int offset = 0;
for (i = 0; i < image.height; i++) {
dst[offset] = src[i];
offset += pitch;
}
More than two decades ago I learned to avoid mul and imul. Use shifts,
add and lea
be obvious.
Signed-off-by: Knut Petersen <[EMAIL PROTECTED]>
diff -uprN -X linux/Documentation/dontdiff -x '*.bak' -x '*.ctx'
linuxorig/drivers/video/console/bitblit.c linux/drivers/video/console/bitblit.c
--- linuxorig/drivers/video/console/bitblit.c 2005-08-29 01:41:01.0
be obvious.
Signed-off-by: Knut Petersen [EMAIL PROTECTED]
diff -uprN -X linux/Documentation/dontdiff -x '*.bak' -x '*.ctx'
linuxorig/drivers/video/console/bitblit.c linux/drivers/video/console/bitblit.c
--- linuxorig/drivers/video/console/bitblit.c 2005-08-29 01:41:01.0
+0200
+++ linux
Probably you can make it even faster by avoiding the multiplication, like
unsigned int offset = 0;
for (i = 0; i image.height; i++) {
dst[offset] = src[i];
offset += pitch;
}
More than two decades ago I learned to avoid mul and imul. Use shifts,
add and lea
Hi Roman,
Could you try the patch below, for a few extra cycles you might want to
make it an inline function.
No, it does not help. If there is any difference, it is too small to be
measured on
my system ... and my system does run at 1000 Hz.
After 2.6.12 fb_pad_aligned_buffer() was
92 matches
Mail list logo
