Since TX hardware checksum and RX completion checksum have been
supported now, so add related information in hns3_dbg_bd_info().
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 50 +-
1 file changed, 40 insertions(+), 10 deletions(-)
diff
On 2020/11/28 4:53, Jakub Kicinski wrote:
On Fri, 27 Nov 2020 16:47:20 +0800 Huazhong Tan wrote:
Since TX hardware checksum and RX completion checksum have been
supported now, so add related information in hns3_dbg_bd_info().
Signed-off-by: Huazhong Tan
drivers/net/ethernet/hisilicon/hns3
On Fri, 27 Nov 2020 16:47:20 +0800 Huazhong Tan wrote:
> Since TX hardware checksum and RX completion checksum have been
> supported now, so add related information in hns3_dbg_bd_info().
>
> Signed-off-by: Huazhong Tan
drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:266:22: warning: incorrec
Since TX hardware checksum and RX completion checksum have been
supported now, so add related information in hns3_dbg_bd_info().
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 50 +-
1 file changed, 40 insertions(+), 10 deletions(-)
diff
Allow a security class to give more information on an rxrpc_s-type key when
it is viewed in /proc/keys. This will allow the upcoming RxGK security
class to show the enctype name here.
Signed-off-by: David Howells
---
net/rxrpc/ar-internal.h |3 +++
net/rxrpc/server_key.c |4
2 fi
From: Yonglong Liu
Adds debugfs to dump new shaping parameters: rate and flag.
Signed-off-by: Yonglong Liu
Signed-off-by: Huazhong Tan
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/net
Allow a security class to give more information on an rxrpc_s-type key when
it is viewed in /proc/keys. This will allow the upcoming RxGK security
class to show the enctype name here.
Signed-off-by: David Howells
---
net/rxrpc/ar-internal.h |3 +++
net/rxrpc/server_key.c |4
2 fi
Sometimes we want ftrace display more and longer information about
the trace.
$ sudo perf ftrace -G '*'
2) 0.979 us| mutex_unlock();
2) 1.540 us| __fsnotify_parent();
2) 0.433 us| fsnotify();
$ sudo perf ftrace -G '*' --graph-opts verbose
14160.770883 | 0) <...>-47814
Sometimes we want ftrace display more and longer information about
the trace.
$ sudo perf ftrace -G '*'
2) 0.979 us| mutex_unlock();
2) 1.540 us| __fsnotify_parent();
2) 0.433 us| fsnotify();
$ sudo perf ftrace -G '*' --graph-opts verbose
14160.770883 | 0) <...>-47814
Sometimes we want ftrace display more and longer information about
the trace.
$ sudo perf ftrace -G '*'
2) 0.979 us| mutex_unlock();
2) 1.540 us| __fsnotify_parent();
2) 0.433 us| fsnotify();
$ sudo perf ftrace -G '*' --graph-opts verbose
14160.770883 | 0) <...>-47814
On Mon, Jul 13, 2020 at 11:07:56AM +0900, Namhyung Kim wrote:
> On Sat, Jul 11, 2020 at 9:43 PM Changbin Du wrote:
> >
> > Sometimes we want ftrace display more and longer information about
> > the trace.
> >
> > $ sudo perf ftrace -G
> > 2) 0.979 us| mutex_unlock();
> > 2) 1.540 us
On Sat, Jul 11, 2020 at 9:43 PM Changbin Du wrote:
>
> Sometimes we want ftrace display more and longer information about
> the trace.
>
> $ sudo perf ftrace -G
> 2) 0.979 us| mutex_unlock();
> 2) 1.540 us| __fsnotify_parent();
> 2) 0.433 us| fsnotify();
>
> $ sudo perf ftr
Sometimes we want ftrace display more and longer information about
the trace.
$ sudo perf ftrace -G
2) 0.979 us| mutex_unlock();
2) 1.540 us| __fsnotify_parent();
2) 0.433 us| fsnotify();
$ sudo perf ftrace -G --graph-opts verbose
14160.770883 | 0) <...>-47814 |
Sometimes we want ftrace display more and longer information about
the trace.
$ sudo perf ftrace -G
2) 0.979 us| mutex_unlock();
2) 1.540 us| __fsnotify_parent();
2) 0.433 us| fsnotify();
$ sudo perf ftrace -G --graph-opts verbose
14160.770883 | 0) <...>-47814 |
Sometimes we want ftrace display more and longer information about the trace.
$ sudo perf ftrace -G
2) 0.979 us| mutex_unlock();
2) 1.540 us| __fsnotify_parent();
2) 0.433 us| fsnotify();
$ sudo perf ftrace -G --graph-verbose
14160.770883 | 0) <...>-47814 | |
On Wed, May 20, 2020 at 06:02:57PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Sun, May 10, 2020 at 11:06:17PM +0800, Changbin Du escreveu:
> > Sometimes we want ftrace display more and longer information about trace.
>
> Humm, -v? Or that would bring too much stuff from other parts of perf?
> I g
On Thu, May 21, 2020 at 6:03 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Sun, May 10, 2020 at 11:06:17PM +0800, Changbin Du escreveu:
> > Sometimes we want ftrace display more and longer information about trace.
>
> Humm, -v? Or that would bring too much stuff from other parts of perf?
> I guess so,
Em Sun, May 10, 2020 at 11:06:27PM +0800, Changbin Du escreveu:
> This is for the function graph tracer to display more info about latency.
> The execution context is shown in this case.
Ok, another --function-graph-opts entry, maybe you can just make -G
receive optional args.
- A
Em Sun, May 10, 2020 at 11:06:17PM +0800, Changbin Du escreveu:
> Sometimes we want ftrace display more and longer information about trace.
Humm, -v? Or that would bring too much stuff from other parts of perf?
I guess so, perhaps as an option to the function-graph tracer, one that
combines, as yo
This is for the function graph tracer to display more info about latency.
The execution context is shown in this case.
$ sudo perf ftrace -G --latency-format
\# tracer: function_graph
\#
1) | 0.992 us| mutex_unlock();
1) | 1.404 us| __fsnotify_parent();
1
Sometimes we want ftrace display more and longer information about trace.
$ sudo perf ftrace -G -l
6800.190937 | 4) <...>-7683 | 2.072 us| mutex_unlock();
6800.190941 | 4) <...>-7683 | 2.171 us| __fsnotify_parent();
6800.190943 | 4) <...>-7683 | 1.497 us|
From: Changbin Du
Add these info fields to funcgraph wakeup tracers:
o Show CPU info since the waker could be on a different CPU.
o Show function duration and overhead.
o Show IRQ markers.
Link: http://lkml.kernel.org/r/20190101154614.8887-3-changbin...@gmail.com
Signed-off-by: Changbin D
Add these info fields to funcgraph wakeup tracers:
o Show CPU info since the waker could be on a different CPU.
o Show function duration and overhead.
o Show IRQ markers.
Signed-off-by: Changbin Du
---
kernel/trace/trace_sched_wakeup.c | 5 -
1 file changed, 4 insertions(+), 1 deletion
I have a donation for you and for my charity work in your region. Please reply
me ASAp for more info
Good day,
I have an interesting business offer for you which will be of immense benefit
to you. Although this may be hard to believe and thought of as one of the
numerous online scam but
Please grant me the benefit of doubt and write me to know what this entails, am
sure you wont regret it. You
On Mon, 16 Oct 2017 16:32:51 -0700
Randy Dunlap wrote:
> There are some good comments about bitmap operations in lib/bitmap.c
> and include/linux/bitmap.h, so format them for document generation and
> pull them into core-api/kernel-api.rst.
>
> I converted the "tables" of functions from using ta
From: Randy Dunlap
There are some good comments about bitmap operations in lib/bitmap.c
and include/linux/bitmap.h, so format them for document generation and
pull them into core-api/kernel-api.rst.
I converted the "tables" of functions from using tabs to using spaces
so that they are more reada
From: Chao Yu
Signed-off-by: Chao Yu
---
fs/f2fs/segment.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index a29919330e27..d310b82caef1 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -740,7 +740,8 @@ static void __remove
No callers then need to report any further info, thus reducing both the
amount of code and the log noise.
Signed-off-by: Peter Rosin
---
drivers/i2c/i2c-mux.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 2178266b
On Wed, Feb 08, 2017 at 01:04:52AM +, Dilger, Andreas wrote:
>
> > On Feb 3, 2017, at 03:33, Greg Kroah-Hartman
> > wrote:
> >
> > On Sat, Jan 28, 2017 at 07:04:38PM -0500, James Simmons wrote:
> >> From: Andreas Dilger
> >>
> >> Update the sysfs "version" file to print "lustre: " with
>
> On Feb 3, 2017, at 03:33, Greg Kroah-Hartman
> wrote:
>
> On Sat, Jan 28, 2017 at 07:04:38PM -0500, James Simmons wrote:
>> From: Andreas Dilger
>>
>> Update the sysfs "version" file to print "lustre: " with
>> the version number.
>>
>> Signed-off-by: Andreas Dilger
>> Intel-bug-id: https
On Sat, Jan 28, 2017 at 07:04:38PM -0500, James Simmons wrote:
> From: Andreas Dilger
>
> Update the sysfs "version" file to print "lustre: " with
> the version number.
>
> Signed-off-by: Andreas Dilger
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5969
> Reviewed-on: http://review.wham
From: Andreas Dilger
Update the sysfs "version" file to print "lustre: " with
the version number.
Signed-off-by: Andreas Dilger
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5969
Reviewed-on: http://review.whamcloud.com/16721
Reviewed-by: James Simmons
Reviewed-by: Dmitry Eremin
Reviewe
From: Christoffer Dall
When translating an L2 IPA to an L1 IPA, we some times need to know at
which level this translation occurred and what the resulting permissions
was, so populate the translation result structure with these additional
fields.
Signed-off-by: Christoffer Dall
Signed-off-by: J
This patch changes to show more info in message log about the recovery
of the corrupted superblock during ->mount, e.g. the index of corrupted
superblock and the result of recovery.
Signed-off-by: Chao Yu
---
fs/f2fs/super.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
d
Update i2c_pxa_scream_blue_murder() fn to print more information
in case of error.
Also, use dev_err variants instead of printk.
Signed-off-by: Jett.Zhou
Signed-off-by: Vaibhav Hiremath
Cc: Wolfram Sang
---
drivers/i2c/busses/i2c-pxa.c | 22 +++---
1 file changed, 15 insertions
Update i2c_pxa_scream_blue_murder() fn to print more information
in case of error.
Also, use dev_err variants instead of printk.
Signed-off-by: Jett.Zhou
Signed-off-by: Vaibhav Hiremath
Cc: Wolfram Sang
---
drivers/i2c/busses/i2c-pxa.c | 22 +++---
1 file changed, 15 insertions
--
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/
--
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/
On Wed, May 20, 2015 at 7:30 PM, Grygorii Strashko
wrote:
> This series updates gpiolib debugfs code to show more information about
> GPIOs requested as IRQ.
>
> First patch ensures that information about GPIOs requested as IRQ only
> will be provided through GPIO debugfs.
>
> Other two patches ex
This series updates gpiolib debugfs code to show more information about
GPIOs requested as IRQ.
First patch ensures that information about GPIOs requested as IRQ only
will be provided through GPIO debugfs.
Other two patches extend information for GPIOs requested as IRQ
- show Linux irq number
- s
From: Oleg Nesterov
The comment above rcu_read_unlock() explains the potential deadlock
if the caller holds one of the locks taken by rt_mutex_unlock() paths,
but it is not clear from this documentation that any lock which can
be taken from interrupt can lead to deadlock as well and we need to
ta
The comment above rcu_read_unlock() explains the potential deadlock
if the caller holds one of the locks taken by rt_mutex_unlock() paths,
but it is not clear from this documentation that any lock which can
be taken from interrupt can lead to deadlock as well and we need to
take rt_mutex_lock() int
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]
This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
messages". There are some struct members which
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]
This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
messages". There are some struct members whi
3.2.51-rc1 review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]
This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
messages". There are some struct members which don't
3.8.13.7 -stable review patch. If anyone has any objections, please let me
know.
--
From: Dan Carpenter
[ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]
This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
messages". There are some struct members whic
3.5.7.19 -stable review patch. If anyone has any objections, please let me
know.
--
From: Dan Carpenter
commit ff862a4668dd6dba962b1d2d8bd344afa6375683 upstream.
This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
messages". There are some struct members which d
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]
This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
messages". There are some struct members which don'
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]
This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
messages". There are some struct members which don't
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]
This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
messages". There are some struct members which don't
more info when reporting the problem
printk(KERN_ERR) from check_hung_task() likely means we have a bug,
but unlike BUG_ON()/WARN_ON ()it doesn't show the kernel version,
this complicates the bug-reports investigation.
Add the additional pr_err() to print tainted/release/version
printk(KERN_ERR) from check_hung_task() likely means the bug,
but unlike BUG_ON/WARN_ON it doesn't show the kernel version,
this complicates the bug-reports investigation.
Add the additional pr_err() to print tainted/release/version
like dump_stack_print_info() does, the output becomes:
I
From: Wengmeiling
When we search a config symbol, if it has no prompt the position of this
symbol in the Kconfig file and it's dependencies are not printed. This can
be inconvenient, especially when it's set to n and we want to find out why.
the following is an example:
before:
Symbol: GENERIC
On 03/25/2013 05:32 PM, Pavel Emelyanov wrote:
> On 03/11/2013 01:11 PM, Pavel Emelyanov wrote:
>> Hi.
>>
>> This v3 series is ported on v3.9-rc2 and patches' changelogs are fixed
>> according to Thomas' feedback to contain info why the change is required.
>
> Gentlemen,
>
> I'm sorry for botheri
On 03/11/2013 01:11 PM, Pavel Emelyanov wrote:
> Hi.
>
> Currently kernel doesn't provide any API for getting information about
> what timers are currently created by process and in which state they
> are. Also, the way timer IDs are generated makes it impossible to create
> a timer with any desi
Hi.
Currently kernel doesn't provide any API for getting information about
what timers are currently created by process and in which state they
are. Also, the way timer IDs are generated makes it impossible to create
a timer with any desired ID. Both facilities are very very tempting by
the check
On Fri, 8 Mar 2013, Pavel Emelyanov wrote:
> On 02/21/2013 10:21 PM, Pavel Emelyanov wrote:
> > Hi.
> >
> > Here's another approach to address the problems with insufficient API
> > of posix timers.
>
> Gentlemen,
Sir,
that caught my attention. Will move it up on my todo list :)
--
To unsubs
On 02/21/2013 10:21 PM, Pavel Emelyanov wrote:
> Hi.
>
> Here's another approach to address the problems with insufficient API
> of posix timers.
Gentlemen,
If you don't mind, I'd like to remind you about this set :) If you could
find some time in your schedule and share your thoughts about one
Commit-ID: c0540606837af79b2ae101e5e7b2206e3844d150
Gitweb: http://git.kernel.org/tip/c0540606837af79b2ae101e5e7b2206e3844d150
Author: Ben Greear
AuthorDate: Wed, 6 Feb 2013 10:56:19 -0800
Committer: Ingo Molnar
CommitDate: Tue, 19 Feb 2013 08:42:44 +0100
lockdep: Print more info when
Hi.
Here's another approach to address the problems with insufficient API
of posix timers.
Currently kernel doesn't provide any API for getting information about
what timers are currently created by process and in which state they
are. Initially the proposal was to add a couple of system calls
On 02/21/2013 05:21 AM, Matthew Helsley wrote:
> On Thu, Feb 14, 2013 at 8:18 AM, Pavel Emelyanov wrote:
>> Hi.
>>
>> I'm working on the checkpoint-restore project (http://criu.org), briefly
>> it's aim is to collect information about process' state and saving it so
>> that later it is possible to
On Thu, Feb 14, 2013 at 8:18 AM, Pavel Emelyanov wrote:
> Hi.
>
> I'm working on the checkpoint-restore project (http://criu.org), briefly
> it's aim is to collect information about process' state and saving it so
> that later it is possible to recreate the processes in the very same state
> as th
Hi.
I'm working on the checkpoint-restore project (http://criu.org), briefly
it's aim is to collect information about process' state and saving it so
that later it is possible to recreate the processes in the very same state
as they were, using the collected information.
One part of the task's st
Commit-ID: 7a508076d4efdfd4fcb6fbd50a32d2c1a6e98791
Gitweb: http://git.kernel.org/tip/7a508076d4efdfd4fcb6fbd50a32d2c1a6e98791
Author: Ben Greear
AuthorDate: Wed, 6 Feb 2013 10:56:19 -0800
Committer: Ingo Molnar
CommitDate: Thu, 7 Feb 2013 12:17:43 +0100
lockdep: Print more info when
From: Ben Greear
This helps debug cases where a lock is acquired over and
over without being released.
Signed-off-by: Ben Greear
---
kernel/lockdep.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 7981e5b..7e76b69 100644
On Mon, Sep 24, 2012 at 1:04 PM, Geert Uytterhoeven
wrote:
> On Mon, Sep 24, 2012 at 9:00 PM, Jason Baron wrote:
>>> - pr_warn("expected <%d bytes into control\n", USER_BUF_PAGE);
>
> %u?
>
>>> + pr_warn("expected <%d bytes into control, you wrote %d\n",
>>> +
On Mon, Sep 24, 2012 at 9:00 PM, Jason Baron wrote:
>> - pr_warn("expected <%d bytes into control\n", USER_BUF_PAGE);
%u?
>> + pr_warn("expected <%d bytes into control, you wrote %d\n",
>> + USER_BUF_PAGE, (int) len);
>
> The style here, I think, is ge
On Tue, Sep 18, 2012 at 05:36:44PM -0600, Jim Cromie wrote:
> Tell user how big the attempted write was, in case its not obvious.
> This helped identify a missing flush in my stress-test script.
>
> Signed-off-by: Jim Cromie
> ---
> lib/dynamic_debug.c | 3 ++-
> 1 file changed, 2 insertions(+),
Tell user how big the attempted write was, in case its not obvious.
This helped identify a missing flush in my stress-test script.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
ind
ddebug_proc_write() warns if the written buffer is >4096 bytes.
Might as well tell user how much was attempted, in case its not obvious.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug
Hi and sorry for the late reply.
On Tue 24-07-12 13:33:03, Andrew Morton wrote:
>
> The patch titled
> Subject: memcg, oom: provide more info while memcg oom happening
> has been added to the -mm tree. Its filename is
> memcg-oom-provide-more-info-while-memcg-oom-
Allen Martin wrote:
Nothing inside the chipset should be decoding port 80 writes. It's
possible this board has a port 80 decoder wired onto the board that's
misbehaving. I've seen other laptop boards with port 80 decoders
wired onto the board, even if the 7 segment display is only populated
o
Allen Martin wrote:
Nothing inside the chipset should be decoding port 80 writes. It's
possible this board has a port 80 decoder wired onto the board that's
misbehaving. I've seen other laptop boards with port 80 decoders
wired onto the board, even if the 7 segment display is only populated
> Alan Cox wrote:
> > On Wed, 12 Dec 2007 21:58:25 +0100
> > Rene Herman <[EMAIL PROTECTED]> wrote:
> >
> >> On 12-12-07 21:26, Rene Herman wrote:
> >>
> >>> On 12-12-07 21:07, David P. Reed wrote:
> Someone might have an in to nVidia to clarify this,
> since I don't.
> In any case, t
On 14-12-07 23:05, Chuck Ebbert wrote:
On 12/12/2007 04:05 PM, H. Peter Anvin wrote:
Rene Herman wrote:
By the way, _does_ anyone have a contact at nVidia who could clarify?
Alan maybe? I'm quite curious what they did...
Summary:
Unless after booting with "acpi=off", outputs to port 0x80
On 12/12/2007 04:05 PM, H. Peter Anvin wrote:
> Rene Herman wrote:
>> On 12-12-07 21:26, Rene Herman wrote:
>>
>>> On 12-12-07 21:07, David P. Reed wrote:
>>
Someone might have an in to nVidia to clarify this, since I don't.
In any case, the udelay(2) approach seems to be a safe fix for
> One wonders if it does some SMM trick to capture port 0x80 writes and
> attempt to haul them off for debugging; it almost sounds like some kind
> of debugging code got let out into the field.
Not implausible. We've got a bug I've been dealing with where a vendor
left debug stuff enabled via th
Alan Cox wrote:
On Wed, 12 Dec 2007 21:58:25 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
On 12-12-07 21:26, Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Someone might have an in to nVidia to clarify this, since I don't. In
any case, the udelay(2) approach seems to be a safe f
Rene Herman wrote:
On 12-12-07 21:26, Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Someone might have an in to nVidia to clarify this, since I don't.
In any case, the udelay(2) approach seems to be a safe fix for this
machine.
By the way, _does_ anyone have a contact at nVi
On Wed, 12 Dec 2007 21:58:25 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 12-12-07 21:26, Rene Herman wrote:
>
> > On 12-12-07 21:07, David P. Reed wrote:
>
> >> Someone might have an in to nVidia to clarify this, since I don't. In
> >> any case, the udelay(2) approach seems to be a safe
On 12-12-07 21:26, Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Someone might have an in to nVidia to clarify this, since I don't. In
any case, the udelay(2) approach seems to be a safe fix for this machine.
By the way, _does_ anyone have a contact at nVidia who could clarify
Port 0xED, just FYI:
cycles: out 1430, in 1370
cycles: out 1429, in 1370
(800 Mhz)
Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Sadly, I've been busy with other crises in my day job for the last
few days. I did modify Rene's test program and ran it on my
"problem" machine,
On 12-12-07 21:07, David P. Reed wrote:
Sadly, I've been busy with other crises in my day job for the last few
days. I did modify Rene's test program and ran it on my "problem"
machine, with the results below.
The interesting part of this is that port 80 seems to respond to "in"
instructio
Sadly, I've been busy with other crises in my day job for the last few
days. I did modify Rene's test program and ran it on my "problem"
machine, with the results below.
The interesting part of this is that port 80 seems to respond to "in"
instructions faster than the presumably "unused" por
esent, and non-swapped.
The patch below adds two fields to /proc/$pid/smaps, that give this information.
Probably even more info will be interesting.
How about adding amount of locked memory, and most importantly map count?
This way I can estimate how 'shared' a process memory really
>From 145247b8e776b32c9930018ab65bb6c5401e28ef Mon Sep 17 00:00:00 2001
From: Maxim Levitsky <[EMAIL PROTECTED]>
Date: Fri, 5 Oct 2007 08:04:03 +0200
Subject: [PATCH] Add more statistics to /proc/$pid/smaps
Add amount of swapped memory and amount of anonymous memory
to /proc/$pid/smaps
Signed-off
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/kvm/mmu.c
===
--- linux-2.6.orig/drivers/kvm/mmu.c
+++ linux-2.6/drivers/kvm/mmu.c
@@ -305,12 +305,16 @@ static void rmap_write_protect(struct kv
static int is_
Greetings,
Some more info on removable media oddness. I use both vfat and ext2
format zip disk. Two mountpoints:
/dev/hdc4 /mnt/zipvfatnoauto,user 0 0
/dev/hdc1 /mnt/zip2 ext2noauto,user 0 0
Odd behaviour:
$ mount
On Thursday 04 August 2005 23:45, Tommy Christensen wrote:
> Denis Vlasenko wrote:
> > Hi,
> >
> > As reported earlier, sometimes my home box don't want
> > to send anything.
> >
> > # ip r
> > 1.1.5.5 dev tun0 proto kernel scope link src 1.1.5.6
> > 1.1.4.0/24 dev if proto kernel scope link
Denis Vlasenko wrote:
Hi,
As reported earlier, sometimes my home box don't want
to send anything.
# ip r
1.1.5.5 dev tun0 proto kernel scope link src 1.1.5.6
1.1.4.0/24 dev if proto kernel scope link src 1.1.4.6
default via 1.1.5.5 dev tun0
# ping 1.1.4.1 -i 0.01
2005-08-02_19:12:18.19
Hi,
As reported earlier, sometimes my home box don't want
to send anything.
# ip r
1.1.5.5 dev tun0 proto kernel scope link src 1.1.5.6
1.1.4.0/24 dev if proto kernel scope link src 1.1.4.6
default via 1.1.5.5 dev tun0
# ping 1.1.4.1 -i 0.01
kernel log:
2005-07-30_21:28:25.15338 kern.info:
Hi again,
Earlier today I wrote about my SMP and Ultra-DMA problem. Now have I
written
down the boot information. I hope that the attachment show the correct
information, it was written in W*rd so some lower case chars can have been
converted into upper case...
I also checked the IDE-patch and t
On Tue, 22 May 2001, null wrote:
> Here is some additional info about the 2.4 performance defect.
>
> Only one person offered a suggestion about the use of HIGHMEM.
> I tried with and without HIGHMEM enabled with the same results.
> However, it does appear to take a bit longer to reach
> performa
> post I quoted some conversation between Rick Van Riel and Alan Cox
Oops. The least I can do is spell his name right. Sorry Rik. 8)
Keep up the good work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
On Tue, 22 May 2001, Jeffrey W. Baker wrote:
> In short, I'm not seeing this problem.
I appreciate your attempt to duplicate the defect on your system. In my
original post I quoted some conversation between Rick Van Riel and Alan
Cox where they describe seeing the same symptoms under heavy load.
On Tue, 22 May 2001, null wrote:
> Here is some additional info about the 2.4 performance defect.
>
> Only one person offered a suggestion about the use of HIGHMEM. I tried
> with and without HIGHMEM enabled with the same results. However, it does
> appear to take a bit longer to reach perfor
Here is some additional info about the 2.4 performance defect.
Only one person offered a suggestion about the use of HIGHMEM. I tried
with and without HIGHMEM enabled with the same results. However, it does
appear to take a bit longer to reach performance drop-out condition when
HIGHMEM is disa
??
--
Mircea Damian
E-mails: [EMAIL PROTECTED], [EMAIL PROTECTED]
WebPage: http://taz.mania.k.ro/~dmircea/
-
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
P
1 - 100 of 117 matches
Mail list logo
