On Sat, Jun 16, 2007 at 08:10:53PM -0700, Linus Torvalds wrote:
> This is where we started. The same way you seem to think that "freedom"
> has only the meaning *you* and the FSF give it, and that somehow the
> spirit of the GPL includes the "four freedoms" that aren't even
> _mentioned_ in it.
On Sat, Jun 16, 2007 at 08:10:53PM -0700, Linus Torvalds wrote:
This is where we started. The same way you seem to think that freedom
has only the meaning *you* and the FSF give it, and that somehow the
spirit of the GPL includes the four freedoms that aren't even
_mentioned_ in it.
THAT
On Sun, May 27, 2007 at 06:10:41PM +0200, Jesper Juhl wrote:
> >bool "USB device class-devices (DEPRECATED)"
> >depends on USB
> >- default n
> >+ default y
>
> It puzzles me why a deprecated option should be default 'Y'...
Because if it defaults to 'n', a 'make
On Sun, May 27, 2007 at 04:34:37PM +0200, Kay Sievers wrote:
> older kernels. That's all, and correctly configured kernels don't break
> anything.
>
> > So instead of papering this breakage over with cleverly worded help texts
> > that suggest a solution, how about we set USB_DEVICE_CLASS to 'y'
> the separate class device. How does that help text sound?
>
> This option provides backward compatibility for systems where
> usbfs is not mounted, and no udev rule like this exists:
> SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", \
>
On Sun, May 27, 2007 at 04:42:35AM +0200, Kay Sievers wrote:
> > Any clues? Please let me know how I can help solve this problem!
>
> It works fine for me here. Do you have CONFIG_USB_DEVICE_CLASS=y set?
Ah, I have not. However, this setting was not present in 2.6.21-rc3, from
which
On Sun, May 27, 2007 at 04:42:35AM +0200, Kay Sievers wrote:
Any clues? Please let me know how I can help solve this problem!
It works fine for me here. Do you have CONFIG_USB_DEVICE_CLASS=y set?
Ah, I have not. However, this setting was not present in 2.6.21-rc3, from
which configuration I
the separate class device. How does that help text sound?
This option provides backward compatibility for systems where
usbfs is not mounted, and no udev rule like this exists:
SUBSYSTEM==usb, ACTION==add, ENV{DEVTYPE}==usb_device, \
NAME=bus/usb/$env{BUSNUM}/$env{DEVNUM},
On Sun, May 27, 2007 at 04:34:37PM +0200, Kay Sievers wrote:
older kernels. That's all, and correctly configured kernels don't break
anything.
So instead of papering this breakage over with cleverly worded help texts
that suggest a solution, how about we set USB_DEVICE_CLASS to 'y' by
On Sun, May 27, 2007 at 06:10:41PM +0200, Jesper Juhl wrote:
bool USB device class-devices (DEPRECATED)
depends on USB
- default n
+ default y
It puzzles me why a deprecated option should be default 'Y'...
Because if it defaults to 'n', a 'make oldconfig' will
Greg, Kay, kernel people,
Today I booted 2.6.22-rc2 on Ubunty Edgy Eft, and lsusb died on me:
[EMAIL PROTECTED]:~$ lsusb
[EMAIL PROTECTED]:~$ sudo lsusb
[EMAIL PROTECTED]:~$
This behaviour persists in rc4. This might be udev related. I'm running:
ii udev
Greg, Kay, kernel people,
Today I booted 2.6.22-rc2 on Ubunty Edgy Eft, and lsusb died on me:
[EMAIL PROTECTED]:~$ lsusb
[EMAIL PROTECTED]:~$ sudo lsusb
[EMAIL PROTECTED]:~$
This behaviour persists in rc4. This might be udev related. I'm running:
ii udev
Con,
Recent kernel versions have real problems for me on the interactivity front,
with even a simple 'make' of my C++ program (PowerDNS) causing Firefox to
slow down to a crawl.
RSDL fixed all that, the system is noticeably snappier.
As a case in point, I used to notice when a compile was done
Con,
Recent kernel versions have real problems for me on the interactivity front,
with even a simple 'make' of my C++ program (PowerDNS) causing Firefox to
slow down to a crawl.
RSDL fixed all that, the system is noticeably snappier.
As a case in point, I used to notice when a compile was done
On Sat, Mar 03, 2007 at 02:26:09PM -0800, Andrew Morton wrote:
> > > It is *not* a global instruction. It uses setenv, so the user's policy
> > > affects only the target process and its forked children.
> >
> > ... and all other processes accessing the same file(s)!
> >
> > Your library and the
On Sat, Mar 03, 2007 at 11:30:49PM +0100, Arnd Bergmann wrote:
> It might be nicer to make this
>
> for (;;)
> asm volatile ("idle");
This looks remarkably like relax_cpu()
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl
On Sat, Mar 03, 2007 at 04:30:56PM -0500, Rik van Riel wrote:
> The user has been accessing the kernel tree over and over
> again, for hours on end (compile testing a patch). Along
> comes a backup program, that tells you to evict the whole
> thing from the cache.
This is arguably due to a
On Sat, Mar 03, 2007 at 04:30:56PM -0500, Rik van Riel wrote:
The user has been accessing the kernel tree over and over
again, for hours on end (compile testing a patch). Along
comes a backup program, that tells you to evict the whole
thing from the cache.
This is arguably due to a linux
On Sat, Mar 03, 2007 at 11:30:49PM +0100, Arnd Bergmann wrote:
It might be nicer to make this
for (;;)
asm volatile (idle);
This looks remarkably like relax_cpu()
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl
On Sat, Mar 03, 2007 at 02:26:09PM -0800, Andrew Morton wrote:
It is *not* a global instruction. It uses setenv, so the user's policy
affects only the target process and its forked children.
... and all other processes accessing the same file(s)!
Your library and the system calls
On Tue, Feb 20, 2007 at 02:02:00PM -0800, Rick Jones wrote:
> The slope appears to be flattening-out the farther out to the right it
> goes. Perhaps that is the length of time it takes to take all the
> requisite cache misses.
The rate of flattening out appears to correlate with the number of
On Tue, Feb 20, 2007 at 02:40:40PM -0500, Benjamin LaHaise wrote:
> Make sure your system is idle. Userspace bloat means that *lots* of idle
> activity occurs in between timer ticks on recent distributions -- all those
You hit the nail on the head. I had previously measured with X shut down,
On Tue, Feb 20, 2007 at 09:48:59PM +0300, Evgeniy Polyakov wrote:
> Likely first overhead related to cache population or gamma-ray radiation.
> If it happens only one (it does in my test), then everything is ok I
> think. Bert, how frequently you get that long recvfrom()?
I have plotted the
On Tue, Feb 20, 2007 at 07:41:25PM +0300, Evgeniy Polyakov wrote:
> It can be recvfrom only problem - syscall overhead on my p4 (core duo,
> debian testing) is bout 300 usec - to test I ran read('dev/zero', ,
> 0) in a loop.
nsec I assume?
The usec numbers for read(fd, , 0) where fd is
On Tue, Feb 20, 2007 at 11:50:13AM +0100, Andi Kleen wrote:
> P4s are pretty slow at taking locks (or rather doing atomical operations)
> and there are several of them in this path. You could try it with a UP
> kernel. Actually hotunplugging the other virtual CPU should be sufficient
> with
On Tue, Feb 20, 2007 at 11:50:13AM +0100, Andi Kleen wrote:
P4s are pretty slow at taking locks (or rather doing atomical operations)
and there are several of them in this path. You could try it with a UP
kernel. Actually hotunplugging the other virtual CPU should be sufficient
with recent
On Tue, Feb 20, 2007 at 07:41:25PM +0300, Evgeniy Polyakov wrote:
It can be recvfrom only problem - syscall overhead on my p4 (core duo,
debian testing) is bout 300 usec - to test I ran read('dev/zero', data,
0) in a loop.
nsec I assume?
The usec numbers for read(fd, c, 0) where fd is
On Tue, Feb 20, 2007 at 09:48:59PM +0300, Evgeniy Polyakov wrote:
Likely first overhead related to cache population or gamma-ray radiation.
If it happens only one (it does in my test), then everything is ok I
think. Bert, how frequently you get that long recvfrom()?
I have plotted the average
On Tue, Feb 20, 2007 at 02:40:40PM -0500, Benjamin LaHaise wrote:
Make sure your system is idle. Userspace bloat means that *lots* of idle
activity occurs in between timer ticks on recent distributions -- all those
You hit the nail on the head. I had previously measured with X shut down,
On Tue, Feb 20, 2007 at 02:02:00PM -0800, Rick Jones wrote:
The slope appears to be flattening-out the farther out to the right it
goes. Perhaps that is the length of time it takes to take all the
requisite cache misses.
The rate of flattening out appears to correlate with the number of
On Thu, Feb 15, 2007 at 09:42:32AM -0800, Linus Torvalds wrote:
> We know one interface: the current aio_read() one. Nobody really _likes_
[...]
> Others? We don't know yet. And exposing complex interfaces that may not be
> the right ones is much *worse* than exposing simple interfaces (that
On Thu, Feb 15, 2007 at 09:42:32AM -0800, Linus Torvalds wrote:
We know one interface: the current aio_read() one. Nobody really _likes_
[...]
Others? We don't know yet. And exposing complex interfaces that may not be
the right ones is much *worse* than exposing simple interfaces (that
On Tue, Feb 13, 2007 at 09:58:48AM -0500, Benjamin LaHaise wrote:
> not present is mandatory). I have looked into exactly this approach, and
> it's only cheaper if the code is incomplete. Linux's native threads are
> pretty damned good.
Cheaper in time or in memory? Iow, would you be able to
On Tue, Feb 13, 2007 at 09:58:48AM -0500, Benjamin LaHaise wrote:
not present is mandatory). I have looked into exactly this approach, and
it's only cheaper if the code is incomplete. Linux's native threads are
pretty damned good.
Cheaper in time or in memory? Iow, would you be able to
On Fri, Feb 09, 2007 at 02:33:01PM -0800, Linus Torvalds wrote:
> - IF the system call blocks, we call the architecture-specific
>"schedule_async()" function before we even get any scheduler locks, and
>it can just do a fork() at that time, and let the *child* return to the
>
On Fri, Feb 09, 2007 at 02:33:01PM -0800, Linus Torvalds wrote:
- IF the system call blocks, we call the architecture-specific
schedule_async() function before we even get any scheduler locks, and
it can just do a fork() at that time, and let the *child* return to the
original
On Mon, Feb 05, 2007 at 01:57:15PM -0800, Linus Torvalds wrote:
> I doubt very many people want to do that. It would tend to simply be nicer
> to do
>
> async(poll);
Yeah - I saw that technique being mentioned later on in the thread, and it
would work, I think.
To make up for the waste
On Fri, Feb 02, 2007 at 03:37:09PM -0800, Davide Libenzi wrote:
> Since I still think that the many-thousands potential async operations
> coming from network sockets are better handled with a classical event
> machanism [1], and since smooth integration of new async syscall into the
>
O_NONBLOCK supposedly hits the entire 'ofile' and not just the fd:
http://cr.yp.to/unix/nonblock.html
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
-
To unsubscribe from this list: send the line
O_NONBLOCK supposedly hits the entire 'ofile' and not just the fd:
http://cr.yp.to/unix/nonblock.html
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
-
To unsubscribe from this list: send the line
On Fri, Feb 02, 2007 at 03:37:09PM -0800, Davide Libenzi wrote:
Since I still think that the many-thousands potential async operations
coming from network sockets are better handled with a classical event
machanism [1], and since smooth integration of new async syscall into the
standard
On Mon, Feb 05, 2007 at 01:57:15PM -0800, Linus Torvalds wrote:
I doubt very many people want to do that. It would tend to simply be nicer
to do
async(poll);
Yeah - I saw that technique being mentioned later on in the thread, and it
would work, I think.
To make up for the waste of
>From two comments posted to my "blog"
http://blog.netherlabs.nl/articles/2007/02/04/a-synchronous-programming
Excerpted from the diary of Dragonfly BSD,
http://www.dragonflybsd.org/status/diary.shtml
Remove the asynchronous syscall interface. It was an idea before its time.
However, keep the
From two comments posted to my blog
http://blog.netherlabs.nl/articles/2007/02/04/a-synchronous-programming
Excerpted from the diary of Dragonfly BSD,
http://www.dragonflybsd.org/status/diary.shtml
Remove the asynchronous syscall interface. It was an idea before its time.
However, keep the
On Fri, Feb 02, 2007 at 03:17:57PM -0800, Linus Torvalds wrote:
> threads. But you need to look at what it is we parallelize here, and ask
> yourself why we're doing what we're doing, and why people aren't *already*
> just using a separate thread for it.
Partially this is for the bad reason
On Fri, Feb 02, 2007 at 03:17:57PM -0800, Linus Torvalds wrote:
threads. But you need to look at what it is we parallelize here, and ask
yourself why we're doing what we're doing, and why people aren't *already*
just using a separate thread for it.
Partially this is for the bad reason that
On Thu, Feb 01, 2007 at 01:29:41PM -0800, Zach Brown wrote:
> >I want to try it on from a userspace perspective.
>
> Frankly, I'm not sure its ready for that yet. You're welcome to give
> it a try, but it's early enough that you're sure to hit problems
> almost immediately.
I'm counting on
On Tue, Jan 30, 2007 at 01:39:45PM -0700, Zach Brown wrote:
> sys_asys_submit() is added to let userspace submit asynchronous system calls.
> It specifies the system call number and arguments. A fibril is constructed
> for
> each call. Each starts with a stack which executes the given system
On Thu, Feb 01, 2007 at 03:11:03PM +0100, Martin Klejch wrote:
>I am a linux user (distro Ubuntu 6.10) with a 2.6.17.10-generic
> kernel running on my Acer TravelMate 4672LMi.
> I found a line "Please report the result to linux-kernel to fix this
> permanently" in my /var/log/kern.log but
On Thu, Feb 01, 2007 at 03:11:03PM +0100, Martin Klejch wrote:
I am a linux user (distro Ubuntu 6.10) with a 2.6.17.10-generic
kernel running on my Acer TravelMate 4672LMi.
I found a line Please report the result to linux-kernel to fix this
permanently in my /var/log/kern.log but have no
On Tue, Jan 30, 2007 at 01:39:45PM -0700, Zach Brown wrote:
sys_asys_submit() is added to let userspace submit asynchronous system calls.
It specifies the system call number and arguments. A fibril is constructed
for
each call. Each starts with a stack which executes the given system call
On Thu, Feb 01, 2007 at 01:29:41PM -0800, Zach Brown wrote:
I want to try it on from a userspace perspective.
Frankly, I'm not sure its ready for that yet. You're welcome to give
it a try, but it's early enough that you're sure to hit problems
almost immediately.
I'm counting on it -
On Mon, Jan 22, 2007 at 11:24:06AM -0500, Neil Horman wrote:
> The error was reported to me second hand. I'm expecting a reproducer
> (although
> to date, I'm still waiting for it, so I may have jumped the gun here). In
> fact,
I've asked for a repoducer weeks ago and nothing happened,
On Mon, Jan 22, 2007 at 11:24:06AM -0500, Neil Horman wrote:
The error was reported to me second hand. I'm expecting a reproducer
(although
to date, I'm still waiting for it, so I may have jumped the gun here). In
fact,
I've asked for a repoducer weeks ago and nothing happened, nobody
On Tue, Jan 16, 2007 at 10:42:53PM +0100, Aurelien Jarno wrote:
> I have just tried a 2.6.20-rc5 kernel (I previously used a 2.6.19 one),
> and I have noticed that the IPv6 router advertisement functionality is
Can you check if rc1, rc2, rc3 etc do work?
Thanks.
--
http://www.PowerDNS.com
On Tue, Jan 16, 2007 at 10:42:53PM +0100, Aurelien Jarno wrote:
I have just tried a 2.6.20-rc5 kernel (I previously used a 2.6.19 one),
and I have noticed that the IPv6 router advertisement functionality is
Can you check if rc1, rc2, rc3 etc do work?
Thanks.
--
http://www.PowerDNS.com
On Thu, Jan 11, 2007 at 01:25:16AM -0700, Sean Reifschneider wrote:
> Nope, I haven't looked in strace at all. It's definitely making it to
> user-space. The code in question is (abbreviated):
>
>if (select(0, (fd_set *)0, (fd_set *)0, (fd_set *)0, ) != 0) {
>
On Thu, Jan 11, 2007 at 07:50:26AM -0800, Linus Torvalds wrote:
> Yes. O_DIRECT is really fundamentally broken. There's just no way to fix
> it sanely. Except by teaching people not to use it, and making the normal
Does this mean that it will eat data today? Or that it is broken because it
On Thu, Jan 11, 2007 at 07:50:26AM -0800, Linus Torvalds wrote:
Yes. O_DIRECT is really fundamentally broken. There's just no way to fix
it sanely. Except by teaching people not to use it, and making the normal
Does this mean that it will eat data today? Or that it is broken because it
On Thu, Jan 11, 2007 at 01:25:16AM -0700, Sean Reifschneider wrote:
Nope, I haven't looked in strace at all. It's definitely making it to
user-space. The code in question is (abbreviated):
if (select(0, (fd_set *)0, (fd_set *)0, (fd_set *)0, t) != 0) {
On Sun, Dec 31, 2006 at 12:13:52PM -0500, Jon Smirl wrote:
> What is the simplest way to get open/close/read/write working under
> 2.6.20-rc2? I know this is horrible and shouldn't be done, I just want
> to get the driver working long enough to see if it is worth saving.
I'm no expert, but try
On Sun, Dec 31, 2006 at 12:13:52PM -0500, Jon Smirl wrote:
What is the simplest way to get open/close/read/write working under
2.6.20-rc2? I know this is horrible and shouldn't be done, I just want
to get the driver working long enough to see if it is worth saving.
I'm no expert, but try
On Fri, Dec 29, 2006 at 07:28:55PM +0100, Dr.-Ing. Ingo D. Rullhusen wrote:
> i hope that's the right address for this little problem, which arises
> with linux kernel 2.4.34.
>
> If i compile the Advanced Power Management as module it do not work. If
> i try a depmod i get an unresolved
On Fri, Dec 29, 2006 at 07:28:55PM +0100, Dr.-Ing. Ingo D. Rullhusen wrote:
i hope that's the right address for this little problem, which arises
with linux kernel 2.4.34.
If i compile the Advanced Power Management as module it do not work. If
i try a depmod i get an unresolved symbols
On Sun, Dec 24, 2006 at 09:51:50AM -0600, Larry Finger wrote:
> This is a heads-up for anyone wishing to use bcm43xx-softmac on Linus's git
> tree, which is now at
> v2.6.20-rc2. There are two serious bugs in that code. Fixes are found below.
For some reason your patch does not apply to stock
On Sun, Dec 24, 2006 at 09:51:50AM -0600, Larry Finger wrote:
This is a heads-up for anyone wishing to use bcm43xx-softmac on Linus's git
tree, which is now at
v2.6.20-rc2. There are two serious bugs in that code. Fixes are found below.
For some reason your patch does not apply to stock
On Mon, Dec 04, 2006 at 07:30:33AM -0500, Josef 'Jeff' Sipek wrote:
> The following patches are in a git repo at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/unionfs.git
Jeff,
Do you have a pointer to a quick blurb on this work?
Thanks.
--
http://www.PowerDNS.com Open
On Sun, Dec 03, 2006 at 05:53:23PM -0800, Bill Huey wrote:
> [8264, 996648, 0] {inode_init_once, fs/inode.c, 196}
> [8552, 996648, 0] {inode_init_once, fs/inode.c, 193}
Impressive, Bill!
How tightly is your work bound to -rt? Iow, any chance of separating the
two? Or
On Sun, Dec 03, 2006 at 05:53:23PM -0800, Bill Huey wrote:
[8264, 996648, 0] {inode_init_once, fs/inode.c, 196}
[8552, 996648, 0] {inode_init_once, fs/inode.c, 193}
Impressive, Bill!
How tightly is your work bound to -rt? Iow, any chance of separating the
two? Or
On Mon, Dec 04, 2006 at 07:30:33AM -0500, Josef 'Jeff' Sipek wrote:
The following patches are in a git repo at:
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/unionfs.git
Jeff,
Do you have a pointer to a quick blurb on this work?
Thanks.
--
http://www.PowerDNS.com Open source,
On Mon, Nov 27, 2006 at 06:26:34PM +, Eric Van Hensbergen wrote:
> This is the first cut of a device-mapper target which provides a write-back
> or write-through block cache. It is intended to be used in conjunction with
> remote block devices such as iSCSI or ATA-over-Ethernet, particularly
On Mon, Nov 27, 2006 at 06:26:34PM +, Eric Van Hensbergen wrote:
This is the first cut of a device-mapper target which provides a write-back
or write-through block cache. It is intended to be used in conjunction with
remote block devices such as iSCSI or ATA-over-Ethernet, particularly in
On Sat, Sep 03, 2005 at 06:58:00PM -0400, Chuck Ebbert wrote:
> I just bought a new notebook. Here is the output from lspci using the latest
> pci.ids file from sourceforge:
I'd suggest researching before buying.
--
http://www.PowerDNS.com Open source, database driven DNS Software
On Sat, Sep 03, 2005 at 06:58:00PM -0400, Chuck Ebbert wrote:
I just bought a new notebook. Here is the output from lspci using the latest
pci.ids file from sourceforge:
I'd suggest researching before buying.
--
http://www.PowerDNS.com Open source, database driven DNS Software
On Tue, Aug 23, 2005 at 04:49:14AM -0500, Davy Durham wrote:
> However, I'm getting segfaults because some pointers in places are
> getting set to low integer values (which didn't used to have those values).
epoll is pretty heavily benchmarked and hence tested. I don't entirely
understand the
On Tue, Aug 23, 2005 at 04:49:14AM -0500, Davy Durham wrote:
However, I'm getting segfaults because some pointers in places are
getting set to low integer values (which didn't used to have those values).
epoll is pretty heavily benchmarked and hence tested. I don't entirely
understand the
On Wed, Aug 03, 2005 at 02:14:03PM +0200, Jules Colding wrote:
> I am experiencing segfaults in mkdir, and mkdir alone, under high load.
I've seen errors like these happen, and they were kernel bugs.
> [0.00] Bootdata ok (command line is root=/dev/sda4 vga=0x31B
>
On Wed, Aug 03, 2005 at 02:14:03PM +0200, Jules Colding wrote:
I am experiencing segfaults in mkdir, and mkdir alone, under high load.
I've seen errors like these happen, and they were kernel bugs.
[0.00] Bootdata ok (command line is root=/dev/sda4 vga=0x31B
video=vesafb:mtrr,ywrap)
On Fri, Jul 29, 2005 at 08:10:32PM -0400, Xin Zhao wrote:
> Thanks. I will try. The only problem I have right now is I am using
> Xenolinux instead of standard Linux kernel, I cannot see the option to
> enable the frame pointer. But I will figure out how to enable that.
If you ever report
On Fri, Jul 29, 2005 at 08:10:32PM -0400, Xin Zhao wrote:
Thanks. I will try. The only problem I have right now is I am using
Xenolinux instead of standard Linux kernel, I cannot see the option to
enable the frame pointer. But I will figure out how to enable that.
If you ever report something
On Fri, Jul 29, 2005 at 05:00:20PM -0400, Xin Zhao wrote:
> Thanks for your reply.
>
> Below is the code that print the kernel calling trace:
Can I suggest just turning on frame pointers like I suggested?
If you say Y here the resulting kernel image will be slightly larger
and slower, but it
On Fri, Jul 29, 2005 at 04:27:16PM -0400, Xin Zhao wrote:
> I supprisely noticed that the dump_stack results are quite different!
> Why did I get the calling traces below our_ssy_open() and above
> syscall_call()? Any thought on this? Many thanks!
This might depend on compiling with frame
On Fri, Jul 29, 2005 at 04:27:16PM -0400, Xin Zhao wrote:
I supprisely noticed that the dump_stack results are quite different!
Why did I get the calling traces below our_ssy_open() and above
syscall_call()? Any thought on this? Many thanks!
This might depend on compiling with frame pointers,
On Fri, Jul 29, 2005 at 05:00:20PM -0400, Xin Zhao wrote:
Thanks for your reply.
Below is the code that print the kernel calling trace:
Can I suggest just turning on frame pointers like I suggested?
If you say Y here the resulting kernel image will be slightly larger
and slower, but it
On Mon, Jul 25, 2005 at 07:47:45PM -0400, Karim Yaghmour wrote:
> Now if only I could remember what I talked about after I left the Black
> Thorn at 2h45am and the guy in the elevator at Les Suites pressed on a
> button and said "'M' for more beer" ...
I bet in involved 'M' for more markers,
On Mon, Jul 25, 2005 at 11:12:25AM -0400, Christopher Friesen wrote:
> >Is do_gettimeofday supposed to be monotonous?
>
> Nope.
>
> > I'm seeing time go backward by tiny amounts, and then progressing.
>
> Are you running NTP? Corrections could cause this.
No. I am running a machine which
On Mon, Jul 25, 2005 at 03:56:48AM -0400, Sonny Rao wrote:
> Hi, I had some trouble compiling it, I figured out that one needs
> libboost, but then I've also discovered that g++-3.4.4 and g++-4.0.1
> don't want to compile it while g++-3.3.5 works. (FYI, all of these were
> Ubuntu versions)
Yes,
On Mon, Jul 25, 2005 at 03:56:48AM -0400, Sonny Rao wrote:
Hi, I had some trouble compiling it, I figured out that one needs
libboost, but then I've also discovered that g++-3.4.4 and g++-4.0.1
don't want to compile it while g++-3.3.5 works. (FYI, all of these were
Ubuntu versions)
Yes, you
On Mon, Jul 25, 2005 at 11:12:25AM -0400, Christopher Friesen wrote:
Is do_gettimeofday supposed to be monotonous?
Nope.
I'm seeing time go backward by tiny amounts, and then progressing.
Are you running NTP? Corrections could cause this.
No. I am running a machine which often changes
On Mon, Jul 25, 2005 at 07:47:45PM -0400, Karim Yaghmour wrote:
Now if only I could remember what I talked about after I left the Black
Thorn at 2h45am and the guy in the elevator at Les Suites pressed on a
button and said 'M' for more beer ...
I bet in involved 'M' for more markers, Karim
Is do_gettimeofday supposed to be monotonous? I'm seeing time go backward by
tiny amounts, and then progressing.
I'm using do_gettimeofday on a single processor, CONFIG_PREEMPT_NONE=y, and
saving stuff from generic_make_request - see http://ds9a.nl/diskstat for the
source. 2.6.13-rc3-mm1, HZ=250.
Is do_gettimeofday supposed to be monotonous? I'm seeing time go backward by
tiny amounts, and then progressing.
I'm using do_gettimeofday on a single processor, CONFIG_PREEMPT_NONE=y, and
saving stuff from generic_make_request - see http://ds9a.nl/diskstat for the
source. 2.6.13-rc3-mm1, HZ=250.
It is with distinct lack of pride that I release version 0.1 of diskstat
'Geeks in Black Thorn', a tool that allows you to generate the kinds of
graphs as presented in my OLS talk 'On faster application startup times:
Cache stuffing, seek profiling, adaptive preloading'. The lack of pride is
It is with distinct lack of pride that I release version 0.1 of diskstat
'Geeks in Black Thorn', a tool that allows you to generate the kinds of
graphs as presented in my OLS talk 'On faster application startup times:
Cache stuffing, seek profiling, adaptive preloading'. The lack of pride is
On Fri, Jul 22, 2005 at 04:18:46PM -0500, Davy Durham wrote:
> Please forgive and redirect me if this is not the right place to ask
> this question:
>
> I'm looking to write a sort of messaging system that would take input
> from any number of entities that "register" with it.. it would then
>
On Fri, Jul 22, 2005 at 01:01:32PM -0700, Paul Jackson wrote:
> Another vote in favor of relayfs here ...
At OLS the 'SystemTAP' idea was presented, which has been partially
implemented already, and it builds on relayfs as well. It dovetails nicely
with kprobes.
So it appears there is a sizeable
On Fri, Jul 22, 2005 at 01:01:32PM -0700, Paul Jackson wrote:
Another vote in favor of relayfs here ...
At OLS the 'SystemTAP' idea was presented, which has been partially
implemented already, and it builds on relayfs as well. It dovetails nicely
with kprobes.
So it appears there is a sizeable
On Fri, Jul 22, 2005 at 04:18:46PM -0500, Davy Durham wrote:
Please forgive and redirect me if this is not the right place to ask
this question:
I'm looking to write a sort of messaging system that would take input
from any number of entities that register with it.. it would then
route
Hi Andrew,
I'm currently at OLS and presented http://ds9a.nl/diskstat yesterday, which
also references your ancient 'fboot' program.
I've also done experiments along those lines, and will be doing more of them
soon.
You mention it was a waste of time, do you recall if that meant:
1) that the
Hi Andrew,
I'm currently at OLS and presented http://ds9a.nl/diskstat yesterday, which
also references your ancient 'fboot' program.
I've also done experiments along those lines, and will be doing more of them
soon.
You mention it was a waste of time, do you recall if that meant:
1) that the
1 - 100 of 250 matches
Mail list logo
