Hi all,
The preload kmp is failing again in Kernel:stable. I can't seem to figure out where the "canonical" version of this code is at in order to fix it.
Anyone know which repo is the "real" one? Is it the one in Kernel:HEAD? If so, it's failing there as well :)
Actually, why do we require this kmp in the first place? I'm getting tired of having it keep the Tumbleweed kernel updates from pushing out to users properly.
If it's so necessary, shouldn't we merge the thing upstream?
thanks,
greg k-h
On Sat, Jan 22, 2011 at 10:45:39AM -0800, Greg KH wrote:
Hi all,
The preload kmp is failing again in Kernel:stable. I can't seem to figure out where the "canonical" version of this code is at in order to fix it.
Anyone know which repo is the "real" one? Is it the one in Kernel:HEAD? If so, it's failing there as well :)
And please don't tell me that the only "tree" for the preload.tar.gz file is in the build system packages, surely it's kept in a tree somewhere else so we can track modifications for it and the like, right?
thanks,
greg k-h
lø., 22.01.2011 kl. 10.57 -0800, skrev Greg KH:
On Sat, Jan 22, 2011 at 10:45:39AM -0800, Greg KH wrote:
Hi all,
The preload kmp is failing again in Kernel:stable. I can't seem to figure out where the "canonical" version of this code is at in order to fix it.
Anyone know which repo is the "real" one? Is it the one in Kernel:HEAD? If so, it's failing there as well :)
And please don't tell me that the only "tree" for the preload.tar.gz file is in the build system packages, surely it's kept in a tree somewhere else so we can track modifications for it and the like, right?
thanks,
greg k-h
Does this help?
bjolie@embla:~/Skrivebord> osc meta pkg openSUSE:Factory/preload <package project="openSUSE:Factory" name="preload"> <title>Preloads Files into System Cache for Faster Booting</title> <description>Preload lists files to load into the system cache. This shortens system boot time if used correctly.</description> <devel project="Base:System" package="preload"/> <build> <disable arch="ppc64"/> </build> </package>
//Bjørn
On Sat, Jan 22, 2011 at 08:15:55PM +0100, Bjørn Lie wrote:
lø., 22.01.2011 kl. 10.57 -0800, skrev Greg KH:
On Sat, Jan 22, 2011 at 10:45:39AM -0800, Greg KH wrote:
Hi all,
The preload kmp is failing again in Kernel:stable. I can't seem to figure out where the "canonical" version of this code is at in order to fix it.
Anyone know which repo is the "real" one? Is it the one in Kernel:HEAD? If so, it's failing there as well :)
And please don't tell me that the only "tree" for the preload.tar.gz file is in the build system packages, surely it's kept in a tree somewhere else so we can track modifications for it and the like, right?
thanks,
greg k-h
Does this help?
bjolie@embla:~/Skrivebord> osc meta pkg openSUSE:Factory/preload
<package project="openSUSE:Factory" name="preload"> <title>Preloads Files into System Cache for Faster Booting</title> <description>Preload lists files to load into the system cache. This shortens system boot time if used correctly.</description> <devel project="Base:System" package="preload"/>
Yeah, I saw that but based on all of the other versions floating around, I didn't know to believe it or not...
thanks,
greg k-h
Hi,
On Sat, 22 Jan 2011, Greg KH wrote:
The preload kmp is failing again in Kernel:stable. I can't seem to figure out where the "canonical" version of this code is at in order to fix it.
Anyone know which repo is the "real" one? Is it the one in Kernel:HEAD? If so, it's failing there as well :)
And please don't tell me that the only "tree" for the preload.tar.gz file is in the build system packages, surely it's kept in a tree somewhere else so we can track modifications for it and the like, right?
Right. Now, look at preload.spec and you'll see. Hint: https://svn.suse.de/svn/desktop/trunk/preload
Ciao, Michael.
On Sat, Jan 22, 2011 at 08:16:47PM +0100, Michael Matz wrote:
Hi,
On Sat, 22 Jan 2011, Greg KH wrote:
The preload kmp is failing again in Kernel:stable. I can't seem to figure out where the "canonical" version of this code is at in order to fix it.
Anyone know which repo is the "real" one? Is it the one in Kernel:HEAD? If so, it's failing there as well :)
And please don't tell me that the only "tree" for the preload.tar.gz file is in the build system packages, surely it's kept in a tree somewhere else so we can track modifications for it and the like, right?
Right. Now, look at preload.spec and you'll see. Hint: https://svn.suse.de/svn/desktop/trunk/preload
Ah, thanks, sorry, missed that.
{sigh}
Subversion, it's as if someone wants to keep me from making any changes to this code...
greg k-h
On Sat, Jan 22, 2011 at 11:31:29AM -0800, Greg KH wrote:
On Sat, Jan 22, 2011 at 08:16:47PM +0100, Michael Matz wrote:
Hi,
On Sat, 22 Jan 2011, Greg KH wrote:
The preload kmp is failing again in Kernel:stable. I can't seem to figure out where the "canonical" version of this code is at in order to fix it.
Anyone know which repo is the "real" one? Is it the one in Kernel:HEAD? If so, it's failing there as well :)
And please don't tell me that the only "tree" for the preload.tar.gz file is in the build system packages, surely it's kept in a tree somewhere else so we can track modifications for it and the like, right?
Right. Now, look at preload.spec and you'll see. Hint: https://svn.suse.de/svn/desktop/trunk/preload
Ah, thanks, sorry, missed that.
{sigh}
Subversion, it's as if someone wants to keep me from making any changes to this code...
And I can't seem to find the kernel portion of the code in that repo, but I might be missing something...
confused,
greg k-h
On Sat, Jan 22, 2011 at 11:40:21AM -0800, Greg KH wrote:
On Sat, Jan 22, 2011 at 11:31:29AM -0800, Greg KH wrote:
On Sat, Jan 22, 2011 at 08:16:47PM +0100, Michael Matz wrote:
Hi,
On Sat, 22 Jan 2011, Greg KH wrote:
The preload kmp is failing again in Kernel:stable. I can't seem to figure out where the "canonical" version of this code is at in order to fix it.
Anyone know which repo is the "real" one? Is it the one in Kernel:HEAD? If so, it's failing there as well :)
And please don't tell me that the only "tree" for the preload.tar.gz file is in the build system packages, surely it's kept in a tree somewhere else so we can track modifications for it and the like, right?
Right. Now, look at preload.spec and you'll see. Hint: https://svn.suse.de/svn/desktop/trunk/preload
Ah, thanks, sorry, missed that.
{sigh}
Subversion, it's as if someone wants to keep me from making any changes to this code...
And I can't seem to find the kernel portion of the code in that repo, but I might be missing something...
confused,
The build does: mkdir source cp stap/preloadtrace.stp stap/Kbuild source touch source/preloadtrace.c kernels=`cd /usr/lib/debug/lib/modules && ls -1d *-$flavor ` cp -r source obj/$flavor make -C /usr/src/linux-obj/%_target_cpu/$flavor modules M=$PWD/obj/$flavor stap -p 4 -DMAXSTRINGSIZE=300 -DMAXSKIPPED=2000 -r $kernels -m preloadtrace obj/$flavor/preloadtrace.stp mv preloadtrace.ko obj/$flavor
So I guess it is basically building on an empty .c file but with stap script in.
Ciao, Marcus
On Sun, Jan 23, 2011 at 09:28:33AM +0100, Marcus Meissner wrote:
The build does: mkdir source cp stap/preloadtrace.stp stap/Kbuild source touch source/preloadtrace.c kernels=`cd /usr/lib/debug/lib/modules && ls -1d *-$flavor ` cp -r source obj/$flavor make -C /usr/src/linux-obj/%_target_cpu/$flavor modules M=$PWD/obj/$flavor stap -p 4 -DMAXSTRINGSIZE=300 -DMAXSKIPPED=2000 -r $kernels -m preloadtrace obj/$flavor/preloadtrace.stp mv preloadtrace.ko obj/$flavor
So I guess it is basically building on an empty .c file but with stap script in.
Thanks for the help.
As I'm stuck in Tokyo due to plane problems, I tried to take some time to look into fixing it. Building the preload module from the svn tree seems to work fine, but from the spec file, it dies with the following errors: /tmp/stapr2YkJ8/preloadtrace.c: In function 'function_gettimeofday_ns': /tmp/stapr2YkJ8/preloadtrace.c:2291:3: error: implicit declaration of function '_stp_gettimeofday_ns' /tmp/stapr2YkJ8/preloadtrace.c: In function 'systemtap_module_init': /tmp/stapr2YkJ8/preloadtrace.c:5448:3: error: implicit declaration of function '_stp_init_time' /tmp/stapr2YkJ8/preloadtrace.c:5703:4: error: implicit declaration of function '_stp_kill_time' make[3]: *** [/tmp/stapr2YkJ8/preloadtrace.o] Error 1
Which kind of implies that it's a system tap issue somewhere. Do we need to update the system tap version in Kernel:HEAD somehow?
Anyone have any ideas?
thanks,
greg k-h
Hello,
As on 2011-01-23 20:20, Greg KH did write:
On Sun, Jan 23, 2011 at 09:28:33AM +0100, Marcus Meissner wrote:
The build does: mkdir source cp stap/preloadtrace.stp stap/Kbuild source touch source/preloadtrace.c kernels=`cd /usr/lib/debug/lib/modules && ls -1d *-$flavor ` cp -r source obj/$flavor make -C /usr/src/linux-obj/%_target_cpu/$flavor modules M=$PWD/obj/$flavor stap -p 4 -DMAXSTRINGSIZE=300 -DMAXSKIPPED=2000 -r $kernels -m preloadtrace obj/$flavor/preloadtrace.stp mv preloadtrace.ko obj/$flavor
So I guess it is basically building on an empty .c file but with stap script in.
Thanks for the help.
As I'm stuck in Tokyo due to plane problems, I tried to take some time to look into fixing it. Building the preload module from the svn tree seems to work fine, but from the spec file, it dies with the following errors: /tmp/stapr2YkJ8/preloadtrace.c: In function 'function_gettimeofday_ns': /tmp/stapr2YkJ8/preloadtrace.c:2291:3: error: implicit declaration of function '_stp_gettimeofday_ns' /tmp/stapr2YkJ8/preloadtrace.c: In function 'systemtap_module_init': /tmp/stapr2YkJ8/preloadtrace.c:5448:3: error: implicit declaration of function '_stp_init_time' /tmp/stapr2YkJ8/preloadtrace.c:5703:4: error: implicit declaration of function '_stp_kill_time' make[3]: *** [/tmp/stapr2YkJ8/preloadtrace.o] Error 1
Which kind of implies that it's a system tap issue somewhere. Do we need to update the system tap version in Kernel:HEAD somehow?
Anyone have any ideas?
The module is able to build with the following change in the spec file. Please see the build log in home:polyconvex:kernel
Index: preload.spec =================================================================== --- preload.spec (revision d148ee1baaccce6c604dcfb4bca7a627) +++ preload.spec (working copy) @@ -71,7 +71,7 @@ kernels=`cd /usr/lib/debug/lib/modules && ls -1d *-$flavor ` cp -r source obj/$flavor make -C /usr/src/linux-obj/%_target_cpu/$flavor modules M=$PWD/obj/$flavor - stap -p 4 -DMAXSTRINGSIZE=300 -DMAXSKIPPED=2000 -r $kernels -m preloadtrace obj/$flavor/preloadtrace.stp + stap -p 4 -DMAXSTRINGSIZE=300 -DMAXSKIPPED=2000 -DSTAP_NEED_GETTIMEOFDAY=1 -r $kernels -m preloadtrace obj/$flavor/preloadtrace.stp mv preloadtrace.ko obj/$flavor done
On Mon, Jan 24, 2011 at 01:05:11PM +0100, Kshitij Kulshreshtha wrote:
Hello,
As on 2011-01-23 20:20, Greg KH did write:
On Sun, Jan 23, 2011 at 09:28:33AM +0100, Marcus Meissner wrote:
The build does: mkdir source cp stap/preloadtrace.stp stap/Kbuild source touch source/preloadtrace.c kernels=`cd /usr/lib/debug/lib/modules && ls -1d *-$flavor ` cp -r source obj/$flavor make -C /usr/src/linux-obj/%_target_cpu/$flavor modules M=$PWD/obj/$flavor stap -p 4 -DMAXSTRINGSIZE=300 -DMAXSKIPPED=2000 -r $kernels -m preloadtrace obj/$flavor/preloadtrace.stp mv preloadtrace.ko obj/$flavor
So I guess it is basically building on an empty .c file but with stap script in.
Thanks for the help.
As I'm stuck in Tokyo due to plane problems, I tried to take some time to look into fixing it. Building the preload module from the svn tree seems to work fine, but from the spec file, it dies with the following errors: /tmp/stapr2YkJ8/preloadtrace.c: In function 'function_gettimeofday_ns': /tmp/stapr2YkJ8/preloadtrace.c:2291:3: error: implicit declaration of function '_stp_gettimeofday_ns' /tmp/stapr2YkJ8/preloadtrace.c: In function 'systemtap_module_init': /tmp/stapr2YkJ8/preloadtrace.c:5448:3: error: implicit declaration of function '_stp_init_time' /tmp/stapr2YkJ8/preloadtrace.c:5703:4: error: implicit declaration of function '_stp_kill_time' make[3]: *** [/tmp/stapr2YkJ8/preloadtrace.o] Error 1
Which kind of implies that it's a system tap issue somewhere. Do we need to update the system tap version in Kernel:HEAD somehow?
Anyone have any ideas?
The module is able to build with the following change in the spec file. Please see the build log in home:polyconvex:kernel
Index: preload.spec
--- preload.spec (revision d148ee1baaccce6c604dcfb4bca7a627) +++ preload.spec (working copy) @@ -71,7 +71,7 @@ kernels=`cd /usr/lib/debug/lib/modules && ls -1d *-$flavor ` cp -r source obj/$flavor make -C /usr/src/linux-obj/%_target_cpu/$flavor modules M=$PWD/obj/$flavor
- stap -p 4 -DMAXSTRINGSIZE=300 -DMAXSKIPPED=2000 -r $kernels -m
preloadtrace obj/$flavor/preloadtrace.stp
- stap -p 4 -DMAXSTRINGSIZE=300 -DMAXSKIPPED=2000
-DSTAP_NEED_GETTIMEOFDAY=1 -r $kernels -m preloadtrace obj/$flavor/preloadtrace.stp mv preloadtrace.ko obj/$flavor done
Yeah that fixed it!
Thanks so much for this, it would have taken me a long time to figure it out. Checking this fix into the different repos now...
thanks,
greg k-h
Hi,
On Sat, 22 Jan 2011, Greg KH wrote:
Right. Now, look at preload.spec and you'll see. Hint: https://svn.suse.de/svn/desktop/trunk/preload
Ah, thanks, sorry, missed that.
{sigh}
Subversion, it's as if someone wants to keep me from making any changes to this code...
And I can't seem to find the kernel portion of the code in that repo, but I might be missing something...
Well, preload doesn't contain any kernel code, modules or otherwise. It contains a systemtap script. And the latter happens to be implemented via kernel modules. Not my fault.
Ciao, Michael.
On Sun, Jan 23, 2011 at 08:42:35PM +0100, Michael Matz wrote:
Hi,
On Sat, 22 Jan 2011, Greg KH wrote:
Right. Now, look at preload.spec and you'll see. Hint: https://svn.suse.de/svn/desktop/trunk/preload
Ah, thanks, sorry, missed that.
{sigh}
Subversion, it's as if someone wants to keep me from making any changes to this code...
And I can't seem to find the kernel portion of the code in that repo, but I might be missing something...
Well, preload doesn't contain any kernel code, modules or otherwise. It contains a systemtap script. And the latter happens to be implemented via kernel modules. Not my fault.
Yeah, in looking at this further, I think I agree, but unwinding the systemtap stuff is a mess...
thanks,
greg k-h
On Sat, 22 Jan 2011 20:16:47 +0100 (CET) Michael Matz matz@suse.de wrote:
Right. Now, look at preload.spec and you'll see. Hint: https://svn.suse.de/svn/desktop/trunk/preload
Connection timed out.
On Sun, Jan 23, 2011 at 07:09:34PM +0100, Stefan Seyfried wrote:
On Sat, 22 Jan 2011 20:16:47 +0100 (CET) Michael Matz matz@suse.de wrote:
Right. Now, look at preload.spec and you'll see. Hint: https://svn.suse.de/svn/desktop/trunk/preload
Connection timed out.
It's behind the suse firewall :(
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/23/2011 02:20 PM, Greg KH wrote:
On Sun, Jan 23, 2011 at 07:09:34PM +0100, Stefan Seyfried wrote:
On Sat, 22 Jan 2011 20:16:47 +0100 (CET) Michael Matz matz@suse.de wrote:
Right. Now, look at preload.spec and you'll see. Hint: https://svn.suse.de/svn/desktop/trunk/preload
Connection timed out.
It's behind the suse firewall :(
Perhaps this should be moved to gitorious then?
- -Jeff
- -- Jeff Mahoney SUSE Labs
On Sun, 23 Jan 2011 17:02:11 -0500 Jeff Mahoney jeffm@suse.com wrote:
On 01/23/2011 02:20 PM, Greg KH wrote:
It's behind the suse firewall :(
Perhaps this should be moved to gitorious then?
Well, it's not like I would *want* to touch this code ;-)
-
Bjørn Lie -
Greg KH -
Jeff Mahoney -
Kshitij Kulshreshtha -
Marcus Meissner -
Michael Matz -
Stefan Seyfried