om looking at the code, I think I've found at least one bug in opendir:
...
dnew = realloc(dirstruct->dp,
dirstruct->max * sizeof(struct dir_s));
...
Shouldn't this be: "...*sizeof(struct dirent_s));"?
--
Paulo Marques - www.grupopie.com
"Nostalgia isn't what it
at the code, I think I've found at least one bug in opendir:
...
dnew = realloc(dirstruct-dp,
dirstruct-max * sizeof(struct dir_s));
...
Shouldn't this be: ...*sizeof(struct dirent_s));?
--
Paulo Marques - www.grupopie.com
Nostalgia isn't what it used to be.
--
To unsubscribe from
and
dirty_expire_centisecs)
You can read all about those tunables in Documentation/filesystems/proc.txt.
Just my 2 cents,
--
Paulo Marques - www.grupopie.com
"Very funny Scotty. Now beam up my clothes."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
and
dirty_expire_centisecs)
You can read all about those tunables in Documentation/filesystems/proc.txt.
Just my 2 cents,
--
Paulo Marques - www.grupopie.com
Very funny Scotty. Now beam up my clothes.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
n could be simply
implemented by having a default value for the flag that is the "current
state" for that flag...
--
Paulo Marques - www.grupopie.com
"There cannot be a crisis today; my schedule is already full."
--
To unsubscribe from this list: send the line "unsubscribe lin
a default value for the flag that is the current
state for that flag...
--
Paulo Marques - www.grupopie.com
There cannot be a crisis today; my schedule is already full.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Bryan Wu wrote:
From: Robin Getz <[EMAIL PROTECTED]>
[...]
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -12,6 +12,8 @@
* (25/Aug/2004) Paulo Marques <[EMAIL PROTECTED]>
* Changed the compression method from stem compression to "table lookup"
* compre
Bryan Wu wrote:
From: Robin Getz [EMAIL PROTECTED]
[...]
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -12,6 +12,8 @@
* (25/Aug/2004) Paulo Marques [EMAIL PROTECTED]
* Changed the compression method from stem compression to table lookup
* compression
+ * (10/Jul/2006
Cyrill Gorcunov wrote:
[Paulo Marques - Wed, Jan 23, 2008 at 06:26:28PM +]
Cyrill Gorcunov wrote:
[...]
case 's':
- getstring(tmp, 64);
+ getstring(tmp, sizeof(tmp));
if (setjmp(bus_error_jmp) == 0
l a nice cleanup,
though. So, if the powerpc people feel they can spare an extra 64 bytes
of stack here, I guess it's ok.
--
Paulo Marques - www.grupopie.com
"As far as we know, our computer has never had an undetected error."
Weisert
--
To unsubscribe from this list: send the line
spare an extra 64 bytes
of stack here, I guess it's ok.
--
Paulo Marques - www.grupopie.com
As far as we know, our computer has never had an undetected error.
Weisert
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Cyrill Gorcunov wrote:
[Paulo Marques - Wed, Jan 23, 2008 at 06:26:28PM +]
Cyrill Gorcunov wrote:
[...]
case 's':
- getstring(tmp, 64);
+ getstring(tmp, sizeof(tmp));
if (setjmp(bus_error_jmp) == 0
thing,
- most faster method is read + write + fadvice.
- worst method is mmap + memcpy.
One thing you could also try is to pass MAP_POPULATE to mmap so that the
page tables are filled in at the time of the mmap, avoiding a lot of
page faults later.
Just my 2 cents,
--
Paulo Marques
thing,
- most faster method is read + write + fadvice.
- worst method is mmap + memcpy.
One thing you could also try is to pass MAP_POPULATE to mmap so that the
page tables are filled in at the time of the mmap, avoiding a lot of
page faults later.
Just my 2 cents,
--
Paulo Marques
later isn't pretty anyway.
I can do a patch for this, but this will touch a few subsystems that use
these interfaces (there are not a lot of them, though). The major change
would probably be the allocation of a small buffer (56~60 bytes) in some
of the callers to hold the module name.
for this, but this will touch a few subsystems that use
these interfaces (there are not a lot of them, though). The major change
would probably be the allocation of a small buffer (56~60 bytes) in some
of the callers to hold the module name.
--
Paulo Marques - www.grupopie.com
There cannot
write their drivers.
--
Paulo Marques - www.grupopie.com
"Very funny Scotty. Now beam up my clothes."
--
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-inf
their drivers.
--
Paulo Marques - www.grupopie.com
Very funny Scotty. Now beam up my clothes.
--
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 at http
Mathieu Desnoyers wrote:
* Paulo Marques ([EMAIL PROTECTED]) wrote:
When resolving symbol names from addresses with aliased symbol names,
kallsyms_lookup always returns the first symbol, even if it is a weak
symbol.
[...]
From: Paulo Marques <[EMAIL PROTECTED]>
Signed-off-by: M
Mathieu Desnoyers wrote:
* Paulo Marques ([EMAIL PROTECTED]) wrote:
When resolving symbol names from addresses with aliased symbol names,
kallsyms_lookup always returns the first symbol, even if it is a weak
symbol.
[...]
From: Paulo Marques [EMAIL PROTECTED]
Signed-off-by: Mathieu Desnoyers
rom: Paulo Marques <[EMAIL PROTECTED]>
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
--
Paulo Marques - www.grupopie.com
"There cannot be a crisis today; my schedule is already full."
--- ./scripts/kallsyms.c.orig 2007-10-30 18:51:28.0 +
+++ ./scripts/ka
Marques [EMAIL PROTECTED]
Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
--
Paulo Marques - www.grupopie.com
There cannot be a crisis today; my schedule is already full.
--- ./scripts/kallsyms.c.orig 2007-10-30 18:51:28.0 +
+++ ./scripts/kallsyms.c2007-10-30 19:07
st hadn't found the time to do it, and then our mail server just went
berserk and I lost 5 days of LKML :P
I think the patch is ok as it is, but a nice message explaining what it
does and why would be nice for the changelog. So, I'll post a new
message with a nice description for inclusion in -mm today.
mail server just went
berserk and I lost 5 days of LKML :P
I think the patch is ok as it is, but a nice message explaining what it
does and why would be nice for the changelog. So, I'll post a new
message with a nice description for inclusion in -mm today.
Sorry for the delay,
--
Paulo
So, if someone wants to use this, it should go through -mm for a while,
first.
--
Paulo Marques - www.grupopie.com
"All I ask is a chance to prove that money can't make me happy."
--- ./scripts/kallsyms.c.orig 2007-10-30 18:51:28.0 +
+++ ./scripts/kallsyms.c2007
this, it should go through -mm for a while,
first.
--
Paulo Marques - www.grupopie.com
All I ask is a chance to prove that money can't make me happy.
--- ./scripts/kallsyms.c.orig 2007-10-30 18:51:28.0 +
+++ ./scripts/kallsyms.c2007-10-30 19:07:58.0 +
@@ -34,7 +34,7
to reduce the size used by the symbol table in the running kernel.
Just take a look at "get_symbol_pos" in kernel/kallsyms.c and
"get_ksymbol" in kernel/module.c to see exactly how this is done
--
Paulo Marques - www.grupopie.com
"There cannot be a crisis today; my
to reduce the size used by the symbol table in the running kernel.
Just take a look at get_symbol_pos in kernel/kallsyms.c and
get_ksymbol in kernel/module.c to see exactly how this is done
--
Paulo Marques - www.grupopie.com
There cannot be a crisis today; my schedule is already full
ock.
On the other hand, if you take the other approach of reducing the stack
usage by creating a printk_symbol interface, the stack usage would drop
from 350 bytes to 128 bytes and your problem would go away entirely.
--
Paulo Marques - www.grupopie.com
"All I ask is a chance to prove that mon
Steven Rostedt wrote:
On Wed, Sep 19, 2007 at 03:25:15PM +0100, Paulo Marques wrote:
if we change the interface from "print_symbol(fmt, addr)" to
"print_symbol(prefix, addr, int newline)" we can simply do:
printk(prefix);
printk_symbol(addr);
if (newline)
printk(&
ore callers of the old interface. At
that point we can just drop it entirely.
--
Paulo Marques - www.grupopie.com
"God is love. Love is blind. Ray Charles is blind. Ray Charles is God."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
it entirely.
--
Paulo Marques - www.grupopie.com
God is love. Love is blind. Ray Charles is blind. Ray Charles is God.
-
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
Steven Rostedt wrote:
On Wed, Sep 19, 2007 at 03:25:15PM +0100, Paulo Marques wrote:
if we change the interface from print_symbol(fmt, addr) to
print_symbol(prefix, addr, int newline) we can simply do:
printk(prefix);
printk_symbol(addr);
if (newline)
printk(\n);
NACK
I just wrote
.
On the other hand, if you take the other approach of reducing the stack
usage by creating a printk_symbol interface, the stack usage would drop
from 350 bytes to 128 bytes and your problem would go away entirely.
--
Paulo Marques - www.grupopie.com
All I ask is a chance to prove that money can't make
nction that does the same as
sprint_symbol, but does "printk" instead of "sprintf".
This should reduce immensely the stack usage of print_symbol without the
need for locking.
Of course this requires changing _all_ callers of print_symbol to use
the new interface, but these a
.
This should reduce immensely the stack usage of print_symbol without the
need for locking.
Of course this requires changing _all_ callers of print_symbol to use
the new interface, but these are less than 100 ;)
Comments?
--
Paulo Marques - www.grupopie.com
You're just jealous because
Paul Mundt wrote:
On Tue, Sep 11, 2007 at 12:41:49PM +0100, Paulo Marques wrote:
[...]
Why do you say that it's x86 specific? Am I missing something?
The emulator it uses only runs on x86 and x86_64. Thus, it's x86
specific. The v86d and uvesafb pages seem to be in disagremeent, unless
it should work on any PCI system where we can access the video
card ROM and can emulate the hardware used by the ROM code.
Why do you say that it's x86 specific? Am I missing something?
--
Paulo Marques - www.grupopie.com
"You're just jealous because the voices only talk to me."
[1] h
work on any PCI system where we can access the video
card ROM and can emulate the hardware used by the ROM code.
Why do you say that it's x86 specific? Am I missing something?
--
Paulo Marques - www.grupopie.com
You're just jealous because the voices only talk to me.
[1] http://dev.gentoo.org
Paul Mundt wrote:
On Tue, Sep 11, 2007 at 12:41:49PM +0100, Paulo Marques wrote:
[...]
Why do you say that it's x86 specific? Am I missing something?
The emulator it uses only runs on x86 and x86_64. Thus, it's x86
specific. The v86d and uvesafb pages seem to be in disagremeent, unless
Tilman Schmidt wrote:
Paulo Marques schrieb:
I just tried booting a brand new 2.6.23-rc5 and after a few minutes it
just panicked: machine totally frozen, blinking keyboard leds.
[...]
Maybe someone out there has a good suggestion that I could try before
bisecting...
A probable candidate
Tilman Schmidt wrote:
Paulo Marques schrieb:
I just tried booting a brand new 2.6.23-rc5 and after a few minutes it
just panicked: machine totally frozen, blinking keyboard leds.
[...]
Maybe someone out there has a good suggestion that I could try before
bisecting...
A probable candidate
kobj);
#endif
pr_debug("kobjects must be dynamically allocated, not static\n");
/* dump_stack(); */
pr_debug(" end silly warning \n");
+out:
+ kfree(namebuf);
}
#else
[...]
--
Paulo Marques - www.grupopie.com
"You're just jealous
(); */
pr_debug( end silly warning \n);
+out:
+ kfree(namebuf);
}
#else
[...]
--
Paulo Marques - www.grupopie.com
You're just jealous because the voices only talk to me.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
the stack because the last position of the buffer is always
cleared to zero.
This patch increments KSYM_NAME_LEN by one and updates code
accordingly.
Nice work.
I've been wanting to do that cleanup myself for a long time ;)
Acked-by: Paulo Marques <[EMAIL PROTECTED]>
--
Paulo M
the stack because the last position of the buffer is always
cleared to zero.
This patch increments KSYM_NAME_LEN by one and updates code
accordingly.
Nice work.
I've been wanting to do that cleanup myself for a long time ;)
Acked-by: Paulo Marques [EMAIL PROTECTED]
--
Paulo Marques
h
- just leave it for now and wait until I work on kallsyms again to
silently remove that line together with other changes
Andrew, what would you prefer?
--
Paulo Marques - www.grupopie.com
"All I ask is a chance to prove that money can't make me happy."
-
To unsubscribe from this
.
yes, i believe this is true
I only tried in on x86 with my toolchain and it works, but I don't know
if it is worth the risk of breaking someone's setup for virtually no gain...
--
Paulo Marques - www.grupopie.com
"God is real, unless declared integer."
-
To unsubscribe from this
Christoph Hellwig wrote:
On Tue, Jun 19, 2007 at 05:15:56PM +0100, Paulo Marques wrote:
The only in-kernel user of "memmem" is scripts/kallsyms.c and it only
uses it to find tokens that are 2 bytes in size. It is trivial to
replace it with a simple function that finds 2-b
Christoph Hellwig wrote:
On Tue, Jun 19, 2007 at 05:15:56PM +0100, Paulo Marques wrote:
The only in-kernel user of memmem is scripts/kallsyms.c and it only
uses it to find tokens that are 2 bytes in size. It is trivial to
replace it with a simple function that finds 2-byte tokens
this is true
I only tried in on x86 with my toolchain and it works, but I don't know
if it is worth the risk of breaking someone's setup for virtually no gain...
--
Paulo Marques - www.grupopie.com
God is real, unless declared integer.
-
To unsubscribe from this list: send the line unsubscribe
it for now and wait until I work on kallsyms again to
silently remove that line together with other changes
Andrew, what would you prefer?
--
Paulo Marques - www.grupopie.com
All I ask is a chance to prove that money can't make me happy.
-
To unsubscribe from this list: send the line
available.
Signed-off-by: Paulo Marques <[EMAIL PROTECTED]>
--
Paulo Marques - www.grupopie.com
"667: The neighbor of the beast."
--- ./scripts/kallsyms.c.orig 2007-06-08 12:55:49.0 +0100
+++ ./scripts/kallsyms.c2007-06-08 13:19:52.0 +0100
@@ -37
-off-by: Paulo Marques [EMAIL PROTECTED]
--
Paulo Marques - www.grupopie.com
667: The neighbor of the beast.
--- ./scripts/kallsyms.c.orig 2007-06-08 12:55:49.0 +0100
+++ ./scripts/kallsyms.c2007-06-08 13:19:52.0 +0100
@@ -378,6 +378,17 @@ static void
82
This is a somewhat crude measure but it shows that only about 30% of the
kernel is "v2 or later" and those pieces could be used on some other "v2
or later" project (including v3). But the kernel as a whole is v2 and my
point was that the claim that there are just a few
Bernd Paysan wrote:
On Friday 15 June 2007 13:49, Paulo Marques wrote:
I've contributed some code for the kernel (unlike yourself, AFAICT), and
believe me, I did so under GPL v2. The COPYING file is pretty much self
explanatory, so I didn't need to add any explicit license statement to
my code
Bernd Paysan wrote:
On Thursday 14 June 2007 19:20, Paulo Marques wrote:
Watching the output of the first grep without "wc -l" shows that,
although it is not 100% accurate, it is still ok just to get a rough
estimate.
So yes, ~6300 files are definitely more than a couple ;)
Bernd Paysan wrote:
On Thursday 14 June 2007 19:20, Paulo Marques wrote:
Watching the output of the first grep without wc -l shows that,
although it is not 100% accurate, it is still ok just to get a rough
estimate.
So yes, ~6300 files are definitely more than a couple ;)
I knew I shouldn't
Bernd Paysan wrote:
On Friday 15 June 2007 13:49, Paulo Marques wrote:
I've contributed some code for the kernel (unlike yourself, AFAICT), and
believe me, I did so under GPL v2. The COPYING file is pretty much self
explanatory, so I didn't need to add any explicit license statement to
my code
% of the
kernel is v2 or later and those pieces could be used on some other v2
or later project (including v3). But the kernel as a whole is v2 and my
point was that the claim that there are just a few v2 only files was
bogus.
--
Paulo Marques - www.grupopie.com
As far as we know, our computer
ot;wc -l" shows that,
although it is not 100% accurate, it is still ok just to get a rough
estimate.
So yes, ~6300 files are definitely more than a couple ;)
--
Paulo Marques - www.grupopie.com
"God is love. Love is blind. Ray Charles is blind. Ray Charles is God."
-
To unsubsc
, it is still ok just to get a rough
estimate.
So yes, ~6300 files are definitely more than a couple ;)
--
Paulo Marques - www.grupopie.com
God is love. Love is blind. Ray Charles is blind. Ray Charles is God.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
won't be able to kill the speaker with software...
--
Paulo Marques - www.grupopie.com
"Don't hit a man when he's down -- kick him; it's easier."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
won't be able to kill the speaker with software...
--
Paulo Marques - www.grupopie.com
Don't hit a man when he's down -- kick him; it's easier.
-
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
of
size 2, so we can use a simplified version instead (and probably get
better code in the process).
How about the attached patch instead?
If you approve it, I'll post it appropriately for inclusion in -mm.
--
Paulo Marques - www.grupopie.com
"God is real, unless declared integer."
---
of
size 2, so we can use a simplified version instead (and probably get
better code in the process).
How about the attached patch instead?
If you approve it, I'll post it appropriately for inclusion in -mm.
--
Paulo Marques - www.grupopie.com
God is real, unless declared integer.
--- ./scripts
, but I
always keep an eye out for kallsyms usage...
--
Paulo Marques - www.grupopie.com
"Very funny Scotty. Now beam up my clothes."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
/ knowledge to review the rest of the code, but I
always keep an eye out for kallsyms usage...
--
Paulo Marques - www.grupopie.com
Very funny Scotty. Now beam up my clothes.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
g standard kernel interfaces (error numbers, memory allocation,
printk, etc.) is not the right way to get code merged.
--
Paulo Marques - www.grupopie.com
"For every problem there is one solution which is simple, neat, and wrong."
H. L. Mencken
-
To unsubscribe from this list: send t
kernel interfaces (error numbers, memory allocation,
printk, etc.) is not the right way to get code merged.
--
Paulo Marques - www.grupopie.com
For every problem there is one solution which is simple, neat, and wrong.
H. L. Mencken
-
To unsubscribe from this list: send the line unsubscribe linux
modprobe/rmmod loop
cat /proc/kallsyms >/dev/null loop
Copy all needed info under module_mutex.
NOTE: this patch keeps module_mutex static.
Yes, this patch fixes the "cat /proc/kallsyms" race without changing any
"external" interfaces, so I think it should go into main
st reliable solution would be to not return
internal module information through pointers and keep all that logic
internal to module.c, then the "proto-patch" with some improvements
might be the way to go...
--
Paulo Marques - www.grupopie.com
"God is love. Love is blind. Ray Charles
information through pointers and keep all that logic
internal to module.c, then the proto-patch with some improvements
might be the way to go...
--
Paulo Marques - www.grupopie.com
God is love. Love is blind. Ray Charles is blind. Ray Charles is God.
-
To unsubscribe from this list: send the line
cat /proc/kallsyms /dev/null loop
Copy all needed info under module_mutex.
NOTE: this patch keeps module_mutex static.
Yes, this patch fixes the cat /proc/kallsyms race without changing any
external interfaces, so I think it should go into mainline in any case.
Acked-by: Paulo Marques [EMAIL
Andrew Morton wrote:
On Fri, 16 Mar 2007 17:16:39 + Paulo Marques <[EMAIL PROTECTED]> wrote:
Does freeze_processes() / unfreeze_processes() solve this by only
freezing processes that have voluntarily scheduled (opposed to just
being preempted)?
It goes much much furthe
Ingo Molnar wrote:
* Paulo Marques <[EMAIL PROTECTED]> wrote:
looking at the problem from another angle: wouldnt this be something
that would benefit from freeze_processes()/unfreeze_processes(), and
hence no locking would be required?
I also considered this, but it seemed a little too
so if you think it
would be better to use freeze_processes()/unfreeze_processes(), I can
cook up a patch for that too...
--
Paulo Marques - www.grupopie.com
"Very funny Scotty. Now beam up my clothes."
diffstat:
arch/parisc/kernel/unwind.c |3 --
arch/powerpc/xmon/xmon.c|
be better to use freeze_processes()/unfreeze_processes(), I can
cook up a patch for that too...
--
Paulo Marques - www.grupopie.com
Very funny Scotty. Now beam up my clothes.
diffstat:
arch/parisc/kernel/unwind.c |3 --
arch/powerpc/xmon/xmon.c| 11 -
arch/ppc/xmon/xmon.c
Ingo Molnar wrote:
* Paulo Marques [EMAIL PROTECTED] wrote:
looking at the problem from another angle: wouldnt this be something
that would benefit from freeze_processes()/unfreeze_processes(), and
hence no locking would be required?
I also considered this, but it seemed a little too blunt
Andrew Morton wrote:
On Fri, 16 Mar 2007 17:16:39 + Paulo Marques [EMAIL PROTECTED] wrote:
Does freeze_processes() / unfreeze_processes() solve this by only
freezing processes that have voluntarily scheduled (opposed to just
being preempted)?
It goes much much further than that. Those
th current git since module_mutex is not declared in module.h,
not to mention compile when CONFIG_MODULES not set)
IMHO we should not expose module_mutex outside of module.c. That is just
wrong from an encapsulation point of view.
--
Paulo Marques - www.grupopie.com
"667: The neighbor of the beast
is not declared in module.h,
not to mention compile when CONFIG_MODULES not set)
IMHO we should not expose module_mutex outside of module.c. That is just
wrong from an encapsulation point of view.
--
Paulo Marques - www.grupopie.com
667: The neighbor of the beast.
-
To unsubscribe from
operation like /proc/modules does.
I would still prefer the other solution to avoid exposing "module_mutex"
outside of module.c like this :(
I'll try to send in a patch today for review.
--
Paulo Marques - www.grupopie.com
"As far as we know, our computer has never had an undetect
Alexey Dobriyan wrote:
On Tue, Mar 13, 2007 at 06:49:50PM +, Paulo Marques wrote:
Alexey Dobriyan wrote:
[...]
What happens is that module_get_kallsym() drops module_mutex,
returns "struct module *", module unloaded, "struct module *"
used.
The only use fo
Alexey Dobriyan wrote:
On Tue, Mar 13, 2007 at 06:49:50PM +, Paulo Marques wrote:
Alexey Dobriyan wrote:
[...]
What happens is that module_get_kallsym() drops module_mutex,
returns struct module *, module unloaded, struct module *
used.
The only use for the struct module * is to display
/modules does.
I would still prefer the other solution to avoid exposing module_mutex
outside of module.c like this :(
I'll try to send in a patch today for review.
--
Paulo Marques - www.grupopie.com
As far as we know, our computer has never had an undetected error.
Weisert
-
To unsubscribe from
won't oops, though.
I'll try to cook up a patch, if no one objects to this approach,
--
Paulo Marques - www.grupopie.com
"There cannot be a crisis today; my schedule is already full."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
to this approach,
--
Paulo Marques - www.grupopie.com
There cannot be a crisis today; my schedule is already full.
-
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
is worth,
Acked-by: Paulo Marques <[EMAIL PROTECTED]>
--
Paulo Marques - www.grupopie.com
"Very funny Scotty. Now beam up my clothes."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mo
ting anything at all.
--
Paulo Marques - www.grupopie.com
"Very funny Scotty. Now beam up my clothes."
-
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/majordom
the the #ifdef CONFIG_KALLSYMS and just
let them be available even in a not CONFIG_KALLSYMS kernel.
Since kallsyms_lookup is already #ifdef'ed to something sane,
sprint_symbol will just print out the symbol address in that case, but
it is better than not printing anything at all.
--
Paulo
is worth,
Acked-by: Paulo Marques [EMAIL PROTECTED]
--
Paulo Marques - www.grupopie.com
Very funny Scotty. Now beam up my clothes.
-
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
inline void lookup_symbol(unsigned long addr, char *buffer)
+{
+ return NULL;
+}
Returning NULL in a function returning "void" doesn't seem right :P
Maybe it should be something like this instead:
{
*buffer = '\0';
}
[...]
Anyway, the change looks useful, so thanks for
*buffer)
+{
+ return NULL;
+}
Returning NULL in a function returning void doesn't seem right :P
Maybe it should be something like this instead:
{
*buffer = '\0';
}
[...]
Anyway, the change looks useful, so thanks for the patch :)
--
Paulo Marques - www.grupopie.com
Very funny
for priority
* reasons reschedule the idle task to see if it can now run.
*/
if (rq->nr_running) {
resched_task(rq->idle);
ret = 1;
}
If that is the case, turning off CONFIG_SCHED_SMT would solve the problem.
--
Paulo M
for priority
* reasons reschedule the idle task to see if it can now run.
*/
if (rq-nr_running) {
resched_task(rq-idle);
ret = 1;
}
If that is the case, turning off CONFIG_SCHED_SMT would solve the problem.
--
Paulo Marques
a
binutils version problem.
Can you send the output of scripts/ver_linux to see what binutils
version you are using?
Also you can try a "make debug_kallsyms" build that creates a .tmp_map1
and a .tmp_map2 files that might help diagnose the problem.
--
Paulo Marques - www.gr
a
binutils version problem.
Can you send the output of scripts/ver_linux to see what binutils
version you are using?
Also you can try a make debug_kallsyms build that creates a .tmp_map1
and a .tmp_map2 files that might help diagnose the problem.
--
Paulo Marques - www.grupopie.com
(or at least
I hope it is ;)
--
Paulo Marques - www.grupopie.com
It is a mistake to think you can solve any major problems
just with potatoes.
Douglas Adams
--- ./scripts/kallsyms.c.orig 2005-06-23 19:20:20.0 +0100
+++ ./scripts/kallsyms.c2005-06-23 19:20:34.0 +0100
(or at least
I hope it is ;)
--
Paulo Marques - www.grupopie.com
It is a mistake to think you can solve any major problems
just with potatoes.
Douglas Adams
--- ./scripts/kallsyms.c.orig 2005-06-23 19:20:20.0 +0100
+++ ./scripts/kallsyms.c2005-06-23 19:20:34.0 +0100
1 - 100 of 263 matches
Mail list logo
