On Tue, Sep 06, 2005 at 12:05:07AM +0200, Marc Giger wrote:
> Hi Andrea
>
> Two little details:
>
> The following line does not print what you expect on
> alpha's:
>
> MHZ = int(re.search(r' (\d+)\.?\d?',
> os.popen("grep -i mhz /proc/cpuinfo | head -n
>
Hi Andrea
Two little details:
The following line does not print what you expect on
alpha's:
MHZ = int(re.search(r' (\d+)\.?\d?',
os.popen("grep -i mhz /proc/cpuinfo | head -n
1").read()).group(1))
My /proc/cpuinfo:
cpu : Alpha
cpu model :
On Wed, Aug 31, 2005 at 09:47:01PM +0200, Andrea Arcangeli wrote:
> I'm thinking to add optional aggregations for (\d+)\.(\d+)\.(\d+)\D and
> for different archs. So you can watch ia64 only or 2.6.13 only etc...
>
> The "-tiger-smp/-generic-up" makes life harder indeed ;).
I now implemented some
On Wed, Aug 31, 2005 at 09:47:01PM +0200, Andrea Arcangeli wrote:
I'm thinking to add optional aggregations for (\d+)\.(\d+)\.(\d+)\D and
for different archs. So you can watch ia64 only or 2.6.13 only etc...
The -tiger-smp/-generic-up makes life harder indeed ;).
I now implemented some basic
Hi Andrea
Two little details:
The following line does not print what you expect on
alpha's:
MHZ = int(re.search(r' (\d+)\.?\d?',
os.popen(grep -i mhz /proc/cpuinfo | head -n
1).read()).group(1))
My /proc/cpuinfo:
cpu : Alpha
cpu model :
On Tue, Sep 06, 2005 at 12:05:07AM +0200, Marc Giger wrote:
Hi Andrea
Two little details:
The following line does not print what you expect on
alpha's:
MHZ = int(re.search(r' (\d+)\.?\d?',
os.popen(grep -i mhz /proc/cpuinfo | head -n
1).read()).group(1))
Thanks
On Wed, Aug 31, 2005 at 08:32:00PM +0200, Pavel Machek wrote:
> I'd say "ignore suspend". Machines using it are probably not connected
> to network, anyway, and it stresses system quite a lot.
Currently even if you're not connected to the network it's fine. As long
as you connect sometime. If a
On Wed, Aug 31, 2005 at 08:20:51PM +0200, Pavel Machek wrote:
> Well, you could remove everything that is not valid kernel text from
> backtrace.
What if the corruption wrote the ssh key inside a the kernel text?
As suggested before, I suspect the only way would be to make it
optional.
> Oh
Hi!
> > [..] combined
> > with an automatic oops/panic/bug-report this would be _very_ useful I think.
>
> That would be nice addition IMHO. It'll be more complex since it'll
> involve netconsole dumping and passing the klive session to the kernel
> somehow (userland would be too unreliable to
Hi!
> > tiny C program or a shell script using netcat.
> >
> > echo "Reporting boot: "
> > (echo "BOOT:"_(cat /etc/lum-serial)":"_(uname -a)"::") | nc -u -w 10
> > testhost.example.com 7658
>
> Client completely stateless couldn't get right suspend to disk as far as
> I can tell.
I'd say
On Tue, 30 Aug 2005, Andrea Arcangeli wrote:
That would be nice addition IMHO. It'll be more complex since it'll
involve netconsole dumping and passing the klive session to the kernel
somehow (userland would be too unreliable to push the oops to the
server). The worst part is that oops dumping
On Tue, 30 Aug 2005, Andrea Arcangeli wrote:
That would be nice addition IMHO. It'll be more complex since it'll
involve netconsole dumping and passing the klive session to the kernel
somehow (userland would be too unreliable to push the oops to the
server). The worst part is that oops dumping
Hi!
tiny C program or a shell script using netcat.
echo Reporting boot:
(echo BOOT:_(cat /etc/lum-serial):_(uname -a)::) | nc -u -w 10
testhost.example.com 7658
Client completely stateless couldn't get right suspend to disk as far as
I can tell.
I'd say ignore suspend. Machines
Hi!
[..] combined
with an automatic oops/panic/bug-report this would be _very_ useful I think.
That would be nice addition IMHO. It'll be more complex since it'll
involve netconsole dumping and passing the klive session to the kernel
somehow (userland would be too unreliable to push the
On Wed, Aug 31, 2005 at 08:20:51PM +0200, Pavel Machek wrote:
Well, you could remove everything that is not valid kernel text from
backtrace.
What if the corruption wrote the ssh key inside a the kernel text?
As suggested before, I suspect the only way would be to make it
optional.
Oh and
On Wed, Aug 31, 2005 at 08:32:00PM +0200, Pavel Machek wrote:
I'd say ignore suspend. Machines using it are probably not connected
to network, anyway, and it stresses system quite a lot.
Currently even if you're not connected to the network it's fine. As long
as you connect sometime. If a
On Wed, Aug 31, 2005 at 04:28:59PM +0200, Sven Ladegast wrote:
> Why not generating a unique system ID at compilation stage of the kernel
> if the apopriate kernel option is enabled? This needn't have something to
> do with klive...just a unique kernel-ID or something like that.
I could also
On Wed, Aug 31, 2005 at 12:14:23PM -0700, [EMAIL PROTECTED] wrote:
> Do you want to try to handle version skew ? All kernels built
> from GIT trees look like 2.6.13 until Linus releases 2.6.14-rc1.
> Possible approaches (requiring changes to the kernel Makefile).
> 1) Use the SHA1 of HEAD to
Do you want to try to handle version skew ? All kernels built
from GIT trees look like 2.6.13 until Linus releases 2.6.14-rc1.
Possible approaches (requiring changes to the kernel Makefile).
1) Use the SHA1 of HEAD to provide a precise identification.
2) Use $(git-rev-tree linus
On Wed, 31 Aug 2005, Alan Cox wrote:
Registering means to create an ID for the system? Something out of
timestamp plus your PCI IDs and CPU info and so on?
Or have the other end issue you some kind of secure cookie, which was my
thought. Generating it locally as you suggest would be even
On Mer, 2005-08-31 at 01:19 +0200, Sven Ladegast wrote:
> On Wed, 31 Aug 2005, Alan Cox wrote:
>
> > "Register a box + optional PCI id list/CPU info"
> > Reply with a secured serial number
>
> Registering means to create an ID for the system? Something out of
> timestamp plus your PCI IDs and
On Mer, 2005-08-31 at 01:19 +0200, Sven Ladegast wrote:
On Wed, 31 Aug 2005, Alan Cox wrote:
Register a box + optional PCI id list/CPU info
Reply with a secured serial number
Registering means to create an ID for the system? Something out of
timestamp plus your PCI IDs and CPU info and
On Wed, 31 Aug 2005, Alan Cox wrote:
Registering means to create an ID for the system? Something out of
timestamp plus your PCI IDs and CPU info and so on?
Or have the other end issue you some kind of secure cookie, which was my
thought. Generating it locally as you suggest would be even
Do you want to try to handle version skew ? All kernels built
from GIT trees look like 2.6.13 until Linus releases 2.6.14-rc1.
Possible approaches (requiring changes to the kernel Makefile).
1) Use the SHA1 of HEAD to provide a precise identification.
2) Use $(git-rev-tree linus
On Wed, Aug 31, 2005 at 12:14:23PM -0700, [EMAIL PROTECTED] wrote:
Do you want to try to handle version skew ? All kernels built
from GIT trees look like 2.6.13 until Linus releases 2.6.14-rc1.
Possible approaches (requiring changes to the kernel Makefile).
1) Use the SHA1 of HEAD to provide
On Wed, Aug 31, 2005 at 04:28:59PM +0200, Sven Ladegast wrote:
Why not generating a unique system ID at compilation stage of the kernel
if the apopriate kernel option is enabled? This needn't have something to
do with klive...just a unique kernel-ID or something like that.
I could also store
On Tue, Aug 30, 2005 at 06:11:26PM -0400, Bill Davidsen wrote:
> the system, like load. A week running while I was on vacation doesn't
> test much, a week running on a loaded server tests other things.
btw, I thought about adding the load average too but it wasn't really
interesting, since
On Wed, 31 Aug 2005, Alan Cox wrote:
"Register a box + optional PCI id list/CPU info"
Reply with a secured serial number
Registering means to create an ID for the system? Something out of
timestamp plus your PCI IDs and CPU info and so on?
Sven
-
To unsubscribe from this list: send the
On Mer, 2005-08-31 at 00:43 +0200, Sven Ladegast wrote:
> collection has. What data does klive send? Is the data just a hash of
> different system variables or is it also possible to identify one single
> computer (or person)? Data protection...laws etc. are things that must be
> considered too
On Tue, 30 Aug 2005, Alan Cox wrote:
but it would have to be opt in. That might lower coverage but should
increase quality, especially id the id in the cookie can be put into
bugzilla reports, and the hardware reporting is done so it can be
machine processed (ie so you can ask stuff like
Rogier Wolff wrote:
On Tue, Aug 30, 2005 at 10:53:13AM +0200, Sven Ladegast wrote:
A trick to use would be to send an UDP packet at boot (after 1 minute
or so), and then randomly say "once a month" (i.e. about 1/30 chance of
sending a packet on the first day) The number of these random packets
On Tue, Aug 30, 2005 at 10:08:38AM -0700, Wilkerson, Bryan P wrote:
> they're work, I'm not sure I'd trust or use the data unless it was
> somehow authenticated.
I doubt many testers would be willing to register on yet another website
just for this. So I doubt adding authentication is a good
On Tue, 30 Aug 2005, Wilkerson, Bryan P wrote:
>
>
> On Tue, Aug 30, 2005 at 10:01:21AM +0200, Sven Ladegast wrote:
>> The idea isn't bad but lots of people could think that this is some
> kind
>> of home-phoning or spy software. I guess lots of people would turn
> this
>> feature off...and of
On Tue, Aug 30, 2005 at 10:01:21AM +0200, Sven Ladegast wrote:
> The idea isn't bad but lots of people could think that this is some
kind
> of home-phoning or spy software. I guess lots of people would turn
this
> feature off...and of course you can't enable it by default. But
combined
> with
On Tue, Aug 30, 2005 at 05:56:33PM +0100, Alan Cox wrote:
> I doubt there is anything needed that can't be done in sh and nc here.
> Catching boots can be done by adding one to a boot number and sending
> that as well. How does suspend to disk handle uptime - if the uptime
> stops then sending the
On 8/30/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Maw, 2005-08-30 at 17:10 +0200, Andrea Arcangeli wrote:
> > It's certainly much easier to tweak the kernel config before compiling
> > the kernel than to edit the mess in /etc/init.d/* with all the
> > gratuitous differences of the userland
On Maw, 2005-08-30 at 18:16 +0200, Andrea Arcangeli wrote:
> Tiny C program will be less tiny than the current tac file and the
> package would immediately become arch dependent.
I doubt there is anything needed that can't be done in sh and nc here.
Catching boots can be done by adding one to a
On Tue, Aug 30, 2005 at 05:33:38PM +0100, Alan Cox wrote:
> Just follow the LSB specification and about the only thing thats totally
> out of field is Slackware.
Fair enough, though one line like '(sleep 60; twistd ...) & in
/etc/init.d/boot.local would have been a bit simpler for a quick and
On Maw, 2005-08-30 at 17:10 +0200, Andrea Arcangeli wrote:
> It's certainly much easier to tweak the kernel config before compiling
> the kernel than to edit the mess in /etc/init.d/* with all the
> gratuitous differences of the userland flavours.
Just follow the LSB specification and about the
On Tue, Aug 30, 2005 at 11:40:58AM +0200, Rogier Wolff wrote:
> packets also wouldn't. So if it is so unimportant as here, why bother
> with the more overhead of the TCP connection?
I agree TCP isn't needed, I also don't see SSL very useful here, I use
it extensively for other projects and it
On Tue, Aug 30, 2005 at 10:01:21AM +0200, Sven Ladegast wrote:
> [..] combined
> with an automatic oops/panic/bug-report this would be _very_ useful I think.
That would be nice addition IMHO. It'll be more complex since it'll
involve netconsole dumping and passing the klive session to the kernel
On Tue, Aug 30, 2005 at 10:29:01AM +0200, Rogier Wolff wrote:
> sending a packet on the first day) The number of these random packets
> recieved is a measure of the number of CPU-months that the kernel
> runs.
This is more or less what klive currently does, except it's a bit more
sophisticated
On Maw, 2005-08-30 at 10:01 +0200, Sven Ladegast wrote:
> The idea isn't bad but lots of people could think that this is some kind
> of home-phoning or spy software. I guess lots of people would turn this
> feature off...and of course you can't enable it by default. But combined
> with an
On Tue, Aug 30, 2005 at 10:53:13AM +0200, Sven Ladegast wrote:
> >A trick to use would be to send an UDP packet at boot (after 1 minute
> >or so), and then randomly say "once a month" (i.e. about 1/30 chance of
> >sending a packet on the first day) The number of these random packets
> >recieved is
On Tue, 2005-08-30 at 11:40 +0200, Rogier Wolff wrote:
[...]
> would IMHO work better. (A userspace program is technically a better
> solution, the social aspect of getting a bigger user-base is the main
> reason for me to suggest the in-kernel approach).
So *if* a user wants to participate,
On Tue, 30 Aug 2005, Rogier Wolff wrote:
It IS some "home phoning" and "spy software". However, when the
goal is to sign you up for more direct marketing, people tend to
object. When the goal is to keep track of running kernels, I'm
hopeful that people will recognise that this is different.
On Tue, Aug 30, 2005 at 10:01:21AM +0200, Sven Ladegast wrote:
> The idea isn't bad but lots of people could think that this is some kind
> of home-phoning or spy software. I guess lots of people would turn this
> feature off...and of course you can't enable it by default. But combined
> with
On Tue, 30 Aug 2005, Andrea Arcangeli wrote:
During the Kernel Summit somebody raised the point that it's not clear
how much testing each rc/pre/git kernel gets before the final release.
Generally this is a good idea to track the usage/testing time of different
versions.
In theory we
On Tue, 30 Aug 2005, Andrea Arcangeli wrote:
During the Kernel Summit somebody raised the point that it's not clear
how much testing each rc/pre/git kernel gets before the final release.
Generally this is a good idea to track the usage/testing time of different
versions.
In theory we
On Tue, Aug 30, 2005 at 10:01:21AM +0200, Sven Ladegast wrote:
The idea isn't bad but lots of people could think that this is some kind
of home-phoning or spy software. I guess lots of people would turn this
feature off...and of course you can't enable it by default. But combined
with an
On Tue, 30 Aug 2005, Rogier Wolff wrote:
It IS some home phoning and spy software. However, when the
goal is to sign you up for more direct marketing, people tend to
object. When the goal is to keep track of running kernels, I'm
hopeful that people will recognise that this is different.
The
On Tue, Aug 30, 2005 at 10:53:13AM +0200, Sven Ladegast wrote:
A trick to use would be to send an UDP packet at boot (after 1 minute
or so), and then randomly say once a month (i.e. about 1/30 chance of
sending a packet on the first day) The number of these random packets
recieved is a measure
On Tue, 2005-08-30 at 11:40 +0200, Rogier Wolff wrote:
[...]
would IMHO work better. (A userspace program is technically a better
solution, the social aspect of getting a bigger user-base is the main
reason for me to suggest the in-kernel approach).
So *if* a user wants to participate, he/she
On Maw, 2005-08-30 at 10:01 +0200, Sven Ladegast wrote:
The idea isn't bad but lots of people could think that this is some kind
of home-phoning or spy software. I guess lots of people would turn this
feature off...and of course you can't enable it by default. But combined
with an automatic
On Tue, Aug 30, 2005 at 10:29:01AM +0200, Rogier Wolff wrote:
sending a packet on the first day) The number of these random packets
recieved is a measure of the number of CPU-months that the kernel
runs.
This is more or less what klive currently does, except it's a bit more
sophisticated than
On Tue, Aug 30, 2005 at 10:01:21AM +0200, Sven Ladegast wrote:
[..] combined
with an automatic oops/panic/bug-report this would be _very_ useful I think.
That would be nice addition IMHO. It'll be more complex since it'll
involve netconsole dumping and passing the klive session to the kernel
On Tue, Aug 30, 2005 at 11:40:58AM +0200, Rogier Wolff wrote:
packets also wouldn't. So if it is so unimportant as here, why bother
with the more overhead of the TCP connection?
I agree TCP isn't needed, I also don't see SSL very useful here, I use
it extensively for other projects and it would
On Maw, 2005-08-30 at 17:10 +0200, Andrea Arcangeli wrote:
It's certainly much easier to tweak the kernel config before compiling
the kernel than to edit the mess in /etc/init.d/* with all the
gratuitous differences of the userland flavours.
Just follow the LSB specification and about the only
On Tue, Aug 30, 2005 at 05:33:38PM +0100, Alan Cox wrote:
Just follow the LSB specification and about the only thing thats totally
out of field is Slackware.
Fair enough, though one line like '(sleep 60; twistd ...) in
/etc/init.d/boot.local would have been a bit simpler for a quick and
dirty
On Maw, 2005-08-30 at 18:16 +0200, Andrea Arcangeli wrote:
Tiny C program will be less tiny than the current tac file and the
package would immediately become arch dependent.
I doubt there is anything needed that can't be done in sh and nc here.
Catching boots can be done by adding one to a
On 8/30/05, Alan Cox [EMAIL PROTECTED] wrote:
On Maw, 2005-08-30 at 17:10 +0200, Andrea Arcangeli wrote:
It's certainly much easier to tweak the kernel config before compiling
the kernel than to edit the mess in /etc/init.d/* with all the
gratuitous differences of the userland flavours.
On Tue, Aug 30, 2005 at 05:56:33PM +0100, Alan Cox wrote:
I doubt there is anything needed that can't be done in sh and nc here.
Catching boots can be done by adding one to a boot number and sending
that as well. How does suspend to disk handle uptime - if the uptime
stops then sending the
On Tue, Aug 30, 2005 at 10:01:21AM +0200, Sven Ladegast wrote:
The idea isn't bad but lots of people could think that this is some
kind
of home-phoning or spy software. I guess lots of people would turn
this
feature off...and of course you can't enable it by default. But
combined
with an
On Tue, 30 Aug 2005, Wilkerson, Bryan P wrote:
On Tue, Aug 30, 2005 at 10:01:21AM +0200, Sven Ladegast wrote:
The idea isn't bad but lots of people could think that this is some
kind
of home-phoning or spy software. I guess lots of people would turn
this
feature off...and of course you
On Tue, Aug 30, 2005 at 10:08:38AM -0700, Wilkerson, Bryan P wrote:
they're work, I'm not sure I'd trust or use the data unless it was
somehow authenticated.
I doubt many testers would be willing to register on yet another website
just for this. So I doubt adding authentication is a good
Rogier Wolff wrote:
On Tue, Aug 30, 2005 at 10:53:13AM +0200, Sven Ladegast wrote:
A trick to use would be to send an UDP packet at boot (after 1 minute
or so), and then randomly say once a month (i.e. about 1/30 chance of
sending a packet on the first day) The number of these random packets
On Tue, 30 Aug 2005, Alan Cox wrote:
but it would have to be opt in. That might lower coverage but should
increase quality, especially id the id in the cookie can be put into
bugzilla reports, and the hardware reporting is done so it can be
machine processed (ie so you can ask stuff like
On Mer, 2005-08-31 at 00:43 +0200, Sven Ladegast wrote:
collection has. What data does klive send? Is the data just a hash of
different system variables or is it also possible to identify one single
computer (or person)? Data protection...laws etc. are things that must be
considered too
On Wed, 31 Aug 2005, Alan Cox wrote:
Register a box + optional PCI id list/CPU info
Reply with a secured serial number
Registering means to create an ID for the system? Something out of
timestamp plus your PCI IDs and CPU info and so on?
Sven
-
To unsubscribe from this list: send the line
On Tue, Aug 30, 2005 at 06:11:26PM -0400, Bill Davidsen wrote:
the system, like load. A week running while I was on vacation doesn't
test much, a week running on a loaded server tests other things.
btw, I thought about adding the load average too but it wasn't really
interesting, since
Hello,
During the Kernel Summit somebody raised the point that it's not clear
how much testing each rc/pre/git kernel gets before the final release.
So I setup a server to track automatically the amount of testing that
each kernel gets. Clearly this will be a very rough approximation and it
Hello,
During the Kernel Summit somebody raised the point that it's not clear
how much testing each rc/pre/git kernel gets before the final release.
So I setup a server to track automatically the amount of testing that
each kernel gets. Clearly this will be a very rough approximation and it
72 matches
Mail list logo
