Cameron Harris <[EMAIL PROTECTED]> :
[r8169 crash]
> Linux laptop 2.6.11-rc1-mm1 #2 SMP Sun Jan 16 22:36:26 GMT 2005 i686
^^
[...]
> I would try a newer kernel, but the command line options for
> specifying the framebuffer settings seems to have changed
: 00010206(2.6.11-rc1-mm1)
EIP is at rtl8169_start_xmit+0x55/0x2b0 [r8169]
eax: 003f ebx: cf236140 ecx: cc9c6000 edx:
esi: cf236240 edi: cfd9b280 ebp: cfd9b280 esp: c0685e00
ds: 007bes: 007bss: 0068
Process swapper (pid: 0, threadinfo=c0684000 task
Roman Zippel wrote:
> Ok, great.
> BTW I don't really expect the first version to be fully optimized (unless
> you want to :) ), but once the basics are right, that can still be added
> later.
Agreed. Tom will post updated patches sometime this week. I'll follow up
with the LTT stuff separately
Hi all,
since I've replaced my Athlon XP 1800 with a Athlon XP 3000
(Barton/FSB333), my logs are flooded with these warnings:
MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Bank 1: d4004152
MCE: The hardware reports a non fatal, correctable incident occurre
Hi,
On Sun, 23 Jan 2005, Karim Yaghmour wrote:
> But how does relayfs organize the namespace then? What if I have
> multiple channels per CPU, each for a different type of data, will
> all channels for the same CPU be under the same directory or will
> each type of data have its own directory wit
Karim Yaghmour wrote:
> This is not good for any client that doesn't know beforehand the exact
> size of their data units, as in the case of LTT. If LTT has to use this
> code that means we are going to loose performance because we will need to
> fill an intermediate data structure which will only
Karim Yaghmour wrote:
> This is not good for any client that doesn't know beforehand the exact
> size of their data units, as in the case of LTT. If LTT has to use this
> code that means we are going to loose performance because we will need to
> fill an intermediate data structure which will only
Hello Roman,
Roman Zippel wrote:
> Well, let's concentrate for a moment on the last thing and check later
> if and how they fit into relayfs. Since ltt will be first main user, let's
> optimize it for this.
> Also since relayfs is intended for large, fast data transfers, per cpu
> buffers are
Hi,
On Fri, 21 Jan 2005, Karim Yaghmour wrote:
> I should have avoided earlier confusing the use of a certain type of
> relayfs channel for a given purpose (i.e. LTT should not necessarily
> depend on the managed mode.) I believe that there is a need for
> more than one mode in relayfs independen
OK, I finally come around to answering this ...
Roman Zippel wrote:
> Sorry, you missunderstood me. At the moment I'm only secondarily
> interested in the API details, primarily I want to work out the details of
> what exactly relayfs/ltt are supposed to do. One main question here I
> can't an
Werner Almesberger wrote:
> - if the probe target is an instruction long enough, replace it with
>a jump or call (that's what I think the kprobes folks are working
>on. I remember for sure that they were thinking about it.)
I heard about this years ago, but I don't know that anything cam
[ 3rd try. Apologies to Karim, Thomas, and Roman, who apparently also
received my previous attempts. For some reason, one of my upstream
DNS servers decided to send me highly bogus MX records. ]
Karim Yaghmour wrote:
> Might I add that this is part of the problem ... No personal
> offence inte
On Wed, Jan 19, 2005 at 11:06:10PM +, Marcos D. Marado Torres wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, 14 Jan 2005, Barry K. Nathan wrote:
>
> >This isn't new to 2.6.11-rc1-mm1, but it has the infamous (to Fedora
> >users) "
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 14 Jan 2005, Barry K. Nathan wrote:
This isn't new to 2.6.11-rc1-mm1, but it has the infamous (to Fedora
users) "ACPI shutdown bug" -- poweroff hangs instead of actually turning
the computer off, on some computers. Here's th
Alle 13:42, mercoledì 19 gennaio 2005, bert hubert ha scritto:
> On Tue, Jan 18, 2005 at 10:39:35PM +0100, Fabio Coatti wrote:
> > vmstat under load is the following, and config.gz attached. Of course I
> > can provide any other needed detail; many thanks for any hint.
>
> Looks mightily like DMA i
Werner Almesberger wrote:
>>From all I've heard and seen of LTT (and I have to admit that most
> of it comes from reading this thread, not from reading the code),
Might I add that this is part of the problem ... No personal
offence intended, but there's been _A LOT_ of things said about
LTT that
Christoph Hellwig wrote:
On Sun, Jan 16, 2005 at 01:05:19PM -0600, Tom Zanussi wrote:
One of the things that uses these functions to read from a channel
from within the kernel is the relayfs code that implements read(2), so
taking them away means you wouldn't be able to use read() on a relayfs
file
On Tue, Jan 18, 2005 at 10:39:35PM +0100, Fabio Coatti wrote:
> vmstat under load is the following, and config.gz attached. Of course I can
> provide any other needed detail; many thanks for any hint.
Looks mightily like DMA is not on, even though you compiled the PIIX driver
in, which lists
> 0
On Sun, Jan 16, 2005 at 01:05:19PM -0600, Tom Zanussi wrote:
> One of the things that uses these functions to read from a channel
> from within the kernel is the relayfs code that implements read(2), so
> taking them away means you wouldn't be able to use read() on a relayfs
> file.
Removing them
On Sun, Jan 16, 2005 at 02:30:33PM -0600, Tom Zanussi wrote:
> This would allow an application to write trace events of its own to a
> trace stream for instance.
I don't think this is a good idea. Userspace could aswell easily write
its trace into shared memory segments.
> Also, I added a user-r
>From all I've heard and seen of LTT (and I have to admit that most
of it comes from reading this thread, not from reading the code),
I have the impression that it may try to be a bit too specialized,
and thus might miss opportunities for synergy.
You must be getting tired of people trying to red
Under heavy disk I/O, the system becomes very unresponsive (i.e. even a drop
down menu takes several seconds to open).
I've noticed this under 2.6.11-rc1-mm1 and 2.6.10-mm2, but I can try whatever
version is suggested. The way to reproduce this is quite simple: I'm using
gentoo, w
Karim Yaghmour writes:
>
> Tom Zanussi wrote:
> > I have to disagree. Awhile back, if you remember, I posted a patch to
> > the LTT daemon that would monitor the trace stream in real time, and
> > process it using an embedded Perl interpreter, no less:
> >
> > http://marc.theaimsgroup.com
Tom Zanussi wrote:
> I have to disagree. Awhile back, if you remember, I posted a patch to
> the LTT daemon that would monitor the trace stream in real time, and
> process it using an embedded Perl interpreter, no less:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109405724500237&w=2
>
>
Thomas,
Thomas Gleixner wrote:
> Yes, I did already start cleaning
>
> cat ../broken-out/ltt* | patch -p1 -R
:D
If it gives you a warm and fuzzy feeling to have the last
cheap-shot, then I'm all for it, it is of no consequence anyway.
And _please_ don't forget to answer this very email with
so
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> With that said, I hope we've agreed that we'll have a callback for
> letting relayfs clients know that they need to write the begining of
> the buffer event. There won't be any associated reserve. Conversly,
> I hope it is not too much to ask to ha
Hi,
Andi Kleen wrote:
On Tue, Jan 18, 2005 at 08:19:18PM +0900, Masami Hiramatsu wrote:
Hello,
I?m a developer of yet another kernel tracer, LKST. I and co-developers
are very glad to hear that LTT was merged into -mm tree and to talk
about the kernel tracer on this ML. Because we think that the
On Tue, Jan 18, 2005 at 08:19:18PM +0900, Masami Hiramatsu wrote:
> Hello,
>
> I?m a developer of yet another kernel tracer, LKST. I and co-developers
> are very glad to hear that LTT was merged into -mm tree and to talk
> about the kernel tracer on this ML. Because we think that the kernel
> e
Hello,
I’m a developer of yet another kernel tracer, LKST. I and co-developers
are very glad to hear that LTT was merged into -mm tree and to talk
about the kernel tracer on this ML. Because we think that the kernel
event tracer is useful to debug Linux systems, and to improve the kernel
reliab
On Mon, 2005-01-17 at 18:57 -0500, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
> > If we add another hardwired implementation then we do not have said
> > benefits.
>
> Please stop handwaving. Folks like Andrew, Christoph, Zwane, Roman,
> and others actually made specific requests for changes
Karim Yaghmour writes:
>
> Aaron Cohen wrote:
> > I've got a quick question and I just want to be clear that it
> > doesn't have a political agenda behind it.
>
> :)
>
> > Here goes, why can't LTT and/or relayfs, work similar to the way
> > syslog does and just fill a buffer (aka ring
Aaron Cohen wrote:
> I've got a quick question and I just want to be clear that it
> doesn't have a political agenda behind it.
:)
> Here goes, why can't LTT and/or relayfs, work similar to the way
> syslog does and just fill a buffer (aka ring-buffer or whatever is
> appropriate), while a use
nt, **wrote-pos);
>
> char* relay_reserve(*rchan, len, *ts, *td, *err, *interrupting);
> void relay_commit(*rchan, *from, len, reserve_code, interrupting);
> void relay_buffers_consumed(*rchan, u32);
>
> #define relay_write_direct(DEST, SRC, SIZE) \
> #define relay_lock_chann
nnel(RCHAN, FLAGS) \
#define relay_unlock_channel(RCHAN, FLAGS) \
This is a far-cry from what we had before, have a look at the
relayfs.txt file in 2.6.11-rc1-mm1's Documentation/filesystems if
you want to compare. Please at least acknowledge as much.
I'm more than willing to compromise,
Thomas Gleixner wrote:
> Provide a hook, export it and load your filters as a module, but keep
> the filters out of the mainline kernel code.
Great idea! I will do exactly that.
Thanks,
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Lim
Hello Roman,
Roman Zippel wrote:
> An additional comment about the order of events. What you're doing in
> lockless_reserve is bogus anyway. There is no single correct time to
> write into the event. By artificially synchronizing event order and event
> time you only cheat yourself. You either
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> a) create indexes, b) reorder events, and likely c) have to rewrite
An additional comment about the order of events. What you're doing in
lockless_reserve is bogus anyway. There is no single correct time to
write into the event. By artificially
J.A. Magallon wrote:
This does not patch against -mm1. -mm1 looks like a mix of plain 2.6.10
and your code.
Could you revamp it against -mm1, please ? I looked at it but seems out
of my understanding...
My patch replaces the one in -mm1.
Just revert the waiting-10s-... patch that is in 2.6.11-rc1
On Mon, 2005-01-17 at 18:41 -0500, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
> > I know, what I have said. I said reduce the filtering to the absolute
> > minimum and do the rest in userspace.
>
> You keep adopting the interpretation which best suits you, taking
> quotes out of context, and k
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> > Periodically can also mean a buffer start call back from relayfs
> > (although that would mean the first entry is not guaranteed) or a
> > (per cpu) eventcnt from the subsystem. The amount of needed search would
> > be limited. The main point
Thomas Gleixner wrote:
> If we add another hardwired implementation then we do not have said
> benefits.
Please stop handwaving. Folks like Andrew, Christoph, Zwane, Roman,
and others actually made specific requests for changes in the code.
What makes you think you're so special that you think yo
On Mon, 2005-01-17 at 17:42 -0500, Robert Wisniewski wrote:
> I believe (and Karim can correct me if I'm wrong) the idea is to have
> groups of events that can be disabled and enabled via a one word mask. No
> checking multiple variables, no #ifdefing, something very streamlined. By
> userspace
Thomas Gleixner wrote:
> I know, what I have said. I said reduce the filtering to the absolute
> minimum and do the rest in userspace.
You keep adopting the interpretation which best suits you, taking
quotes out of context, and keep repeating things that have already
been answered. There are limi
On 2005.01.16, Daniel Drake wrote:
> Hi,
>
> Joseph Fannin wrote:
> > On Fri, Jan 14, 2005 at 12:23:52AM -0800, Andrew Morton wrote:
> >
> >>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> >
> >
> >&g
On Mon, 2005-01-17 at 15:34 -0500, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
> > Thats the point. Adding another hardwired implementation does not give
> > us a possibility to solve the hardwired problem of the already available
> > stuff.
>
> Well then, like I said before, you know what you
n <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PRO
On Mon, 2005-01-17 at 15:32 -0500, Karim Yaghmour wrote:
> You're either on crack or I don't know how to read english. Here's what
> you said:
Maybe you should read your own comment about ad-hominem attacks earlier
in this thread and consider if it might apply to you.
I know, what I have said. I
:13 2005 from meromorphy
Linux analyticity 2.6.11-rc1-mm1 #5 SMP Sat Jan 15 01:25:23 PST 2005 sparc64
GNU/Linux
$ uptime
14:10:55 up 10 min, 7 users, load average: 0.10, 0.40, 0.31
Now I just have to remember to set up ip route add 192.168.1.0/24 dev
eth3 via 192.168.1.1 instead of just ip route add 19
Hello Chistoph,
Christoph Hellwig wrote:
> The thing I'm unhappy with is what the code does currently. I haven't
> looked at the code enough nor through about the problem enough to tell
> you what's the right thing to do. Knowing that will involve review of
> the architecture and serious benchm
Hello Roman,
Roman Zippel wrote:
> Periodically can also mean a buffer start call back from relayfs
> (although that would mean the first entry is not guaranteed) or a
> (per cpu) eventcnt from the subsystem. The amount of needed search would
> be limited. The main point is from the relayfs PO
Thomas Gleixner wrote:
> Thats the point. Adding another hardwired implementation does not give
> us a possibility to solve the hardwired problem of the already available
> stuff.
Well then, like I said before, you know what you need to do:
http://www-124.ibm.com/developerworks/oss/linux/projects
Thomas Gleixner wrote:
> Sorting out disabled events is the filtering you have to do in kernel
> and you should do it in the hot path or remove the unneccecary
> tracepoints at compiletime.
Do you actually read my replies or do you just grep for something
you can object to? If you care to read m
Hi, Andrew Morton schrub am Fri, 14 Jan 2005 10:35:34 -0800:
> What filesystem(s) do you use, and why?
sshfs (best idea for file access through firewalls).
gmailfs (best free off-site backup facility).
Will use encfs as soon as FUSE is in mainline
(I'm using cryptoloop now, but that's not san
Karim Yaghmour writes:
>
> Hello Roman,
>
>
> What we are dropping for later review: read/write semantics from
> user-space. It has to be understood that we believe that this is
> a major drawback. For one thing, you won't be able to do something
> like:
> $ cat /relayfs/xchg/my-file >
On Mon, Jan 17, 2005 at 10:48:52AM -0500, Robert Wisniewski wrote:
> Wow - disabling interrupts is handfuls to tens of cycles, so that means
> some architectures take thousands of cycles to do atomic operations. Then
> I would definitely agree we should not be using atomic operations on those,
> f
Arjan van de Ven writes:
> On Sun, 2005-01-16 at 16:06 -0500, Robert Wisniewski wrote:
>
> > :-) - as above. Furthermore, it seems that reducing the places where
> > interrupts are disabled would be a good thing?
>
> depends at the price. On several cpus, disabling interupts is hundreds
Hi,
On Sun, 16 Jan 2005, Karim Yaghmour wrote:
> > You can make it even simpler by dropping this completely. Every buffer is
> > simply a list of events and you can let ltt write periodically a timer
> > event. In userspace you can randomly seek at buffer boundaries and search
> > for the time
On Sun, 2005-01-16 at 21:24 -0500, Karim Yaghmour wrote:
> > Sorting out disabled events in the hot path and moving the if
> > (pid/gid/grp) whatever stuff into userspace postprocessing is not an
> > alien request.
>
> It is. Have you even read what I suggested to change in my other mail:
> if ((
On Sun, 2005-01-16 at 20:54 -0500, Karim Yaghmour wrote:
> If you really want to define layers, then there are actually four
> layers:
> 1- hooking mechanism
> 2- event definition / registration
> 3- event management infrastructure
> 4- transport mechanism
>
> LTT currently does 1, 2 & 3. Clearly
Hi Karim,
> Thomas Gleixner wrote:
>> It's not only me, who needs constant time. Everybody interested in
>> tracing will need that. In my opinion its a principle of tracing.
>
> relayfs is a generalized buffering mechanism. Tracing is one application
> it serves. Check out the web site: "high-spe
Thomas Gleixner wrote:
> Which is every 1.42 seconds on a 3GHz machine. I guess we don't have
> GB's of data when the 1.42 seconds elapse without an event.
My argument was about being able to browse the amount of data I was
refering to. The hearbeat thing was an asside to Roman as to the
fact tha
Thomas Gleixner wrote:
> This implies to seperate
>
> - infrastructure
> - event registration
> - transport mechanism
Like I said in my first response: we can't be everything for everbody,
the requirements are just too broad. ISO tried it with OSI. Have a
look at net/* for the result.
Current
On Sun, 2005-01-16 at 16:18 -0500, Karim Yaghmour wrote:
> We already do write a heartbeat event periodically to have readable
> traces in the case where the lower 32 bits of the TSC wrap-around.
Which is every 1.42 seconds on a 3GHz machine. I guess we don't have
GB's of data when the 1.42 secon
On Sat, 2005-01-15 at 23:23 -0500, Karim Yaghmour wrote:
> > Well, that's really a core problem. We don't want to duplicate
> > infrastructure, which practically does the same. So if relayfs isn't
> > usable in this kind of situation, it really raises the question whether
> > relayfs is usable a
On Sun, 2005-01-16 at 16:06 -0500, Robert Wisniewski wrote:
> :-) - as above. Furthermore, it seems that reducing the places where
> interrupts are disabled would be a good thing?
depends at the price. On several cpus, disabling interupts is hundreds
of times cheaper than doing an atomic op.
Christoph Hellwig writes:
> On Sun, Jan 16, 2005 at 03:11:00PM -0500, Robert Wisniewski wrote:
> > int global_val;
> >
> > modify_val_spin()
> > {
> >acquire_spin_lock()
> >// calculate some_value based on global_val
> >// for example c=global_val; if (c%0) some_value=10; else
Hello Roman,
Roman Zippel wrote:
> It seems we first need to specify, what relayfs actually is supposed to
> be. Is it a relaying mechanism for large amount of data from kernel to
> user space or is it a general communication channel between kernel and
> user space? You have to choose one, if
Andrew Morton writes:
> Robert Wisniewski <[EMAIL PROTECTED]> wrote:
> >
> > modify_val_spin()
> > {
> >acquire_spin_lock()
> >// calculate some_value based on global_val
> >// for example c=global_val; if (c%0) some_value=10; else some_value=20;
> >global_val = global_val
On Sun, Jan 16, 2005 at 03:11:00PM -0500, Robert Wisniewski wrote:
> int global_val;
>
> modify_val_spin()
> {
> acquire_spin_lock()
> // calculate some_value based on global_val
> // for example c=global_val; if (c%0) some_value=10; else some_value=20;
> global_val = globa
Robert Wisniewski <[EMAIL PROTECTED]> wrote:
>
> modify_val_spin()
> {
> acquire_spin_lock()
> // calculate some_value based on global_val
> // for example c=global_val; if (c%0) some_value=10; else some_value=20;
> global_val = global_val + some_value
> release_spin_
Karim Yaghmour writes:
>
> Christoph Hellwig wrote:
> > the lockless mode is really just loops around cmpxchg. It's spinlocks
> > reinvented poorly.
Christoph,
Sadly they're not the same, atomic operations provide a set of
functionality that simple spin locks do not give you. Consider
Christoph Hellwig writes:
> On Fri, Jan 14, 2005 at 04:11:38PM -0500, Karim Yaghmour wrote:
> >Where does this appear in relayfs and what rights do
> >user-space apps have over it (rwx).
>
> Why would you want anything but read access?
This would allow an application to write trace e
Christoph Hellwig wrote:
> the lockless mode is really just loops around cmpxchg. It's spinlocks
> reinvented poorly.
I beg to differ. You have to use different spinlocks depending on
where you are:
- serving user-space
- bh-derivatives
- irq
lockless is the same primitive regardless of your cu
Hello Christoph,
Christoph Hellwig wrote:
> Why would you want anything but read access?
Fine, we can put it read-only, we'll drop the "mode" field.
> I think random access is overkill. Keeping the code simple is more
> important and user-space can post-process it.
it's overkill if you're thi
Joseph Fannin wrote:
>>With this patch, initrds seem to get 'skipped'. I think this is
>> probably the cause for the reports of problems with RAID too.
On Sun, Jan 16, 2005 at 07:09:31PM +, Daniel Drake wrote:
> This seems likely and is probably also the cause of wli's problems
> mention
Hi,
Joseph Fannin wrote:
On Fri, Jan 14, 2005 at 12:23:52AM -0800, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
waiting-10s-before-mounting-root-filesystem.patch
retry mounting the root filesystem at boot time
With this patch
Karim Yaghmour writes:
>
> What I'm dropping for now is all the functions that allow a
> subsystem to read from a channel from within the kernel. So,
> for example, if you want to obtain large amounts of data from
> user-space via a relayfs channel you won't be able to. Here
> are the functi
Hi,
On Sun, 16 Jan 2005, Karim Yaghmour wrote:
> The per-cpu buffering issue is really specific to the client. It just
> so happens that LTT creates one channel for each CPU. Not everyone
> who needs to ship lots of data to user-space needs/wants one channel
> per cpu. You could, for example, use
Joseph Fannin wrote:
On Fri, Jan 14, 2005 at 12:23:52AM -0800, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
waiting-10s-before-mounting-root-filesystem.patch
retry mounting the root filesystem at boot time
With this patch
On Fri, Jan 14, 2005 at 06:09:23PM -0500, Karim Yaghmour wrote:
> relayfs implements two schemes: lockless and locking. The later uses
> standard linear locking mechanisms. If you need stringent constant
> time, you know what to do.
the lockless mode is really just loops around cmpxchg. It's spin
On Sat, Jan 15, 2005 at 01:24:16AM +0100, Thomas Gleixner wrote:
> Putting a 200k patch into the kernel for limited usage and maybe
> restricting a generic simple non intrusive and more generic
> implementation by its mere presence is making it inapplicable enough.
>
> Merge the instrumentation po
On Fri, Jan 14, 2005 at 04:11:38PM -0500, Karim Yaghmour wrote:
> Where does this appear in relayfs and what rights do
> user-space apps have over it (rwx).
Why would you want anything but read access?
> bufsize, nbufs:
> Usually things have to be subdivided in sub-buffers to ma
Karim Yaghmour writes:
>
> Hello Thomas,
>
> In the interest of avoiding expanding the thread too thin, I'm replying to
> both emails in the same time.
>
> Thomas Gleixner wrote:
> >>relayfs is a generalized buffering mechanism. Tracing is one application
> >>it serves. Check out the we
Daniel Kirsten <[EMAIL PROTECTED]> writes:
>> Are you using an initrd?
> yes.
Then read Documentation/initrd.txt ...
Your initrd must be deprecated, i guess you have to use
root=/dev/whatever/your_final_root_fs with it while it should be
root=/dev/ram0. (pretty sure it doesn't use pivot_root
Hi,
Reuben Farrelly wrote:
At 12:58 a.m. 15/01/2005, Andrew Morton wrote:
Reuben Farrelly <[EMAIL PROTECTED]> wrote:
>
> Something seems to have broken with 2.6.11-rc1-mm1, which worked ok
with
> 2.6.10-mm3.
>
> NET: Registered protocol family 17
> Starting balanced_irq
&
Hello Roman,
Roman Zippel wrote:
> It's interesting to read more about ltt's requirements, but I still think
> it's possible to leave this work to the relayfs layer.
Ok, I'm willing to play ball, but can you be a little bit more specific.
> Why not just move the ltt buffer management into rela
Hello Roman,
Roman Zippel wrote:
> On Sat, 15 Jan 2005, Karim Yaghmour wrote:
>>In addition, and this is a very important issue, quite a few
>>kernel developers mistook LTT for a kernel debugging tool, which
>>it was never meant to be. When, in fact, if you ask those who have
>>looked at using it
Hello Thomas,
In the interest of avoiding expanding the thread too thin, I'm replying to
both emails in the same time.
Thomas Gleixner wrote:
>>relayfs is a generalized buffering mechanism. Tracing is one application
>>it serves. Check out the web site: "high-speed data-relay filesystem."
>>Fanc
Hi,
On Sat, 15 Jan 2005, Karim Yaghmour wrote:
> In addition, and this is a very important issue, quite a few
> kernel developers mistook LTT for a kernel debugging tool, which
> it was never meant to be. When, in fact, if you ask those who have
> looked at using it for that purpose (try Marcelo
Andrew,
This patch removes from relayfs the 'klog debugging channel', which is
a relayfs 'application' that doesn't belong in the main code. Please
apply.
Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.11-rc1-mm1-vanilla/fs/Kconf
Hi,
On Fri, 14 Jan 2005, Karim Yaghmour wrote:
> > Why should a subsystem care about the details of the buffer management?
>
> Because it wants to enforce a data format on buffer boundaries.
It's interesting to read more about ltt's requirements, but I still think
it's possible to leave this w
Hello Thomas,
I don't mind having a general discussion about instrumentation, but
it has to be understood that the topic is so general and means so
many different things to different people that we are unlikely to
reach any useful consensus. Believe me, it's not for the lack of
trying. More below
On Fri, Jan 14, 2005 at 12:23:52AM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> waiting-10s-before-mounting-root-filesystem.patch
> retry mounting the root filesystem at boot time
With this patch,
> Are you using an initrd?
yes.
-
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://www.tux.org/lkml/
On Fri, 2005-01-14 at 15:22 -0800, Tim Bird wrote:
> but not 1) supporting infrastructure for timestamping, managing event
> data, etc., and 2) a static list of generally useful tracepoints.
Both points are well taken. Thats the essential minimum what
instrumentation needs.
I'd like to see th
Randy.Dunlap wrote (ao):
> Reuben Farrelly wrote:
> >At 12:58 a.m. 15/01/2005, Andrew Morton wrote:
> >
> >>Reuben Farrelly <[EMAIL PROTECTED]> wrote:
> >>>
> >>> Something seems to have broken with 2.6.11-rc1-mm1, which worked ok
> >
On Fri, 2005-01-14 at 20:25 -0500, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
>
> You have previously demonstrated that you do not understand the
> implementation you are criticizing. You keep repeating the size
> of the patch like a mantra, yet when pressed for actual bits of
> code that need
Hi Karim,
On Fri, 2005-01-14 at 20:14 -0500, Karim Yaghmour wrote:
> Gee Thomas, I guess you really want to take this one until the last
> man is standing. Feel free to use the ad-hominem tone if it suits
> you. Don't hold it against me though if I don't bite :)
No personal offence was intended.
Sorry about the missing quotes. It should read:
You wrote:
> Some things I'd like to see (as I am currently using the KIO
> equivalent) implemented as FUSE fs:
> - "fish", virtual file access over ssh
This is already available here:
http://sourceforge.net/projects/fuse
You need to dowload f
Some things I'd like to see (as I am currently using the KIO
equivalent) implemented as FUSE fs:
- "fish", virtual file access over ssh
This is already available here:
http://sourceforge.net/projects/fuse
You need to dowload fuse-2.2-pre3 and sshfs-1.0. It should work on
any kernel including
100 matches
Mail list logo
