Re: I/O tracing

2001-06-04 Thread richardj_moore
You can use either dprobes to set up a tracepoint dynamically anywhere you please see: http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes Or, you can use gkhi to define a hook anywhere in the kernel you please. You can write a hook exit as a kmod to do whatever you fan

Re: Linux kernel programming for beginners

2001-05-15 Thread richardj_moore
Yes, try the O'Reilly books, especilly Linux Device Drivers by Rubini, ISBN 1-56592-292-1 Richard Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM U

Re: Dynamically altering code segments

2001-02-27 Thread richardj_moore
Dprobes is one mechanism for doing what you want. It works the same way OS/2 dynamic trace did. Another mecnahism, also available from the dprobes web page is the GKHI (generalised kernel hooks interface). If you know you want tracepoints in permanently assigned locations then you could code a g

Re: monitoring I/O

2001-01-24 Thread richardj_moore
I can offer the GKHI we put together to make kernel hooks easy to add an manage. If you know which code paths you need to peek then you can write you monitor as a kernel mod - user mod pair. The kernel mod will accumulate the stats, the user mod will extract and report the stats. See the web pag

Re: Anybody got 2.4.0 running on a 386 ?

2001-01-10 Thread richardj_moore
Does linux cater of all the old 386 chip bugs - especially the memory management oddities? Richard Moore - RAS Project Lead - Linux Technology Centre (PISC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP

Re: Question about RTC interrupts on i386

2000-12-15 Thread richardj_moore
You can get some interesting side effects if you incease the clock speed. I'm not saying that Linux will suffer, but I have seen problems on other Intel based systems - it all depends on what you do with the clock interrupt. Increasing the seed will give a finer grained pre-emption capability.

Re: cpu stepping

2000-12-12 Thread richardj_moore
Stepping is Intel teminology for chip revisions - possibly other manufacturers have used the same terminology. Intel documents the fixes, or rather the bugs and work-arounds, for each stepping level in the addendum to the particular processor's reference manual. Probably, I haven't checked, thi

Re: Why is double_fault serviced by a trap gate?

2000-12-09 Thread richardj_moore
I agree, I've changed my mind about the use of a task gate for NMI - Intel recommend an interrupt gate for a very good reason - NMI's are queued until the IRET so using an interrup gate for NMI (and keeping interrupts disabled) will guarantee that NMIs are handled serially. I think our use of a

Re: Why is double_fault serviced by a trap gate?

2000-12-08 Thread richardj_moore
Exactly, and you wouldn't set DPL=3 for interrupt 8 since a double-fault can only occur from ring 0.. Richard Moore - RAS Project Lead - Linux Technology Centre (PISC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM

Re: Why is double_fault serviced by a trap gate?

2000-12-08 Thread richardj_moore
Actually what you are pointing out here is the differing needs for differing uses. Real-time, embedded systems etc have different requirements or at lest different priorities to enterprise usage. I'm coming from the enterprise server angle - the Linux/390 type of use and high end IA32 Server. I

Re: Why is double_fault serviced by a trap gate?

2000-12-08 Thread richardj_moore
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK -- Forwarde

Re: Why is double_fault serviced by a trap gate?

2000-12-08 Thread richardj_moore
No no. That's that the whole point of a gate. You make a controlled transition to ring 0 including stack switching. There are complex protection checking rules, however as long as the DPL of the gate descriptor is 3 then ring 3 is allowed to make the transition to ring 0. A stack fault in user

Re: who is writing to disk

2000-12-08 Thread richardj_moore
One option, if there's no bespoke mechanism is to use DPorbes and or Linux Trace Toolkit to set up a trace of file system apis. You could also start with strace. Richard Moore - RAS Project Lead - Linux Technology Centre (PISC). http://oss.software.ibm.com/developerworks/opensource/linux Off

Re: Why is double_fault serviced by a trap gate?

2000-12-07 Thread richardj_moore
Yes, indeed this is the point - we should at least be able to report the problem even if we can't recover - and we should do that in the standard kernel. It doesn't seem right to convert a bad problem into an unfathomable disaster, which is what a trap gate for double-fault does. If you're going

Re: Why is double_fault serviced by a trap gate?

2000-12-07 Thread richardj_moore
You seem to be misunderstanding the point of the argument: R3 stack fault - no problem - handled by trap gate for idt vector 12 - recovery is possible if one wants to handle it. R0 stack fault - big problem, exception 12 is converted to a double-fault, which is converted to a triple-fault becaus

Re: Why is double_fault serviced by a trap gate?

2000-12-07 Thread richardj_moore
Which surely we can on today's x86 systems. Even back in the days of OS/2 2.0 running on a 386 with 4Mb RAM we used a taskgate for both NMI and Double Fault. You need only a minimal stack - 1K, sufficient to save state and restore ESP to a known point before switching back to the main TSS to all

Why is double_fault serviced by a trap gate?

2000-12-07 Thread richardj_moore
Why is double_fault serviced by a trap gate? The problem with this is that any double-fault caused by a stack-fault, which is the usual reason, becomes a triple-fault. And a triple-fault results in a processor reset or shutdown making the fault damn near impossible to get any information on. Ou

anounce: Universal dynamic trace for Linux

2000-11-25 Thread richardj_moore
You can now use IBM's DProbes with Opersys' Linux Trace Toolkit to provide a universal (dynamic) tracing capability for Linux. It is universal because it provides a common tracing mechanism for all executables whether in user or kernel space. It is dynamic because tracepoints are defined and ap

Re: Newbie

2000-11-15 Thread richardj_moore
Not even Intel can spell kernal [sic] - see 486 Programmer's reference - description of protection mechanism. BTW one of the enhancements to the Pentium was an improvement in the spelling of kernel. :-) Richard Moore - RAS Project Lead - Linux Technology Centre (PISC). http://oss.software.i

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-15 Thread richardj_moore
Please respond to Andrea Arcangeli <[EMAIL PROTECTED]> To: Richard J Moore/UK/IBM@IBMGB cc: Subject: Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI) On Wed, Nov 15, 2000 at 05:14:57AM +, [EMAIL PROTECTED] wrote: > > > Andrea, > > I am very greatful for your detailed analysi

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-15 Thread richardj_moore
Andrea, I am very greatful for your detailed analysis. I have yet to digest everything you commented but will get back to you on all points you raise very soon. Here are my thoughts so far: > I think gkhi should be renamed to something like "Fast Unregistered Kernel > Hook Interface" to avoid

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-13 Thread richardj_moore
Andi Kleen wrote: >I think using dprobes for collecting information is ok, but when you want >to do actual actions with it (not only using it as a debugger) IMHO it >is better to patch and recompile the kernel. I absolutely agree. The only time I ever used this capability was to modify a propri

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-12 Thread richardj_moore
Alexander Viro wrote: > It's not a good idea, it's an obvious fact. Oh, you mean forking the tree? Again I find your terminology at odds with mine; what do you mean by forking the tree? I get the impression that it's a very restrictive notion where any functional ehancement applied as a patch o

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-12 Thread richardj_moore
Andi Kleen wrote: > It will just help some people who have a unrational aversion against kernel >recompiles and believe in vendor blessed binaries. An interesting remark Andi, especially in the light of your note to me regarding your use of DProbes - i.e. you'd rather use DProbes to dump out

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-10 Thread richardj_moore
No, misunderstood. GKHI is not implemented using dynamic probes. GKHI places in the kernel calls to APIs in the DProbes code. Since we'ed rather have Dprobes out of the kernel then essentially it acts as a loader after the fact, i.e. it fixes up the DProbes API calls when the DProbe module loa

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-10 Thread richardj_moore
Matti, >Please educate me, what does "our RAS offerings" mean here ? >(I didn't find "RAS" at your signature-URL site, but I didn't > poke around very much..) RAS = Reliabilty, Availability & Serviceability = those things that are are not mainline to an OS but add the qualities na

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-10 Thread richardj_moore
> Right. So what you're saying is that GKHI is adding complexity to the > kernel to make it easier for peopel to put in non-standard patches which > exposes non-standard interfaces which will lead to kernels not supported > by the Linux Kernel Development Community. Right? I don't think I me

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-10 Thread richardj_moore
> The problem with the hooks et.al. is very simple - they promote every > bloody implementation detail to exposed API. Surely not, having the kernel source does that. The alternative to the hook is embed a patch in the kernel source. What proveds greater exposure to internals: hooks of s

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-10 Thread richardj_moore
> That being said, the real problem with the GKHI is that as Al said, it > does expose internal kernel interfaces --- and the Linux kernel > development community as a whole refuses to be bound by such interfaces, > sometimes even during a stable kernel series. I'm not sure that GKHI exposes a

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-10 Thread richardj_moore
>> Why? I think the IBM GKHI code would be of tremendous value. It would > > And we already refuse to support those kernels - your point being? > > Making this "commonplace" is a nightmare. Go away with that. How is so? Richard Moore - RAS Project Lead - Linux Technology Centre (PIS

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-10 Thread richardj_moore
>> extensions using the GKHI would not be breaking the license agreement, I >> don't think. There's lots of binary modules right now -- VMWare, Aureal > sound card drivers, etc. > >All of which just cause large numbers of bugs to go in the bitbucket because >nobody can tell whose the problem i

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-10 Thread richardj_moore
> Yes, and that's why I am opposing here: Technically you are right, but > proposing that enterprise Linux should go this way is inviting binary > only modules due to the lax handling of modules. Not so sure it does. If a kernel module wants to make use of GKHI then it will have to 1) include

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-09 Thread richardj_moore
Let be clear about one thing: the GKHI make no statement about enabling proprietary extensions and that's a common misconception. GKHI is intended to make optional facilities easier to co-install and change. We designed it for DProbes, and when modularised will remain a GPL opensource offering.

[ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-08 Thread richardj_moore
We've just release version 0.6 of Generalised Kernel Hooks Interface (GKHI) see the IBM Linux Technology Centre's web page DProbes link: http://oss.software.ibm.com/developerworks/opensource/linux Some folks expressed an interest in this type of facility recently in discussions concerning makin

Re: Calling module symbols from inside the kernel !

2000-11-07 Thread richardj_moore
We have a generic way of doing this which we are about to release - called GKHI (Generalised Kernel Hooks Interface) would you like a copy to test? Richard Moore - RAS Project Lead - Linux Technology Centre (PISC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)

Re: [ANNOUNCE] DProbes 1.1

2000-10-20 Thread richardj_moore
Andi, Thanks for your feedback. We are looking at this now. Hopefully we will be able to give you a response on Monday. If we don't then it's because most of us are on holiday next week. I'm interested in getting information on who is using DProbes and how its being used? Yes, an also that w

Re: Clear interrupts on a SMP machine?

2000-10-18 Thread richardj_moore
I think you need to use the smp_call_funtion service and define the function to be a spin_until_notified function. Each other processor will call spin_until_notified when it receives the IPI for smp_call_function. You can do what you need, then change some global that's keeping all the other pr

[ANNOUNCE] DProbes 1.1

2000-10-18 Thread richardj_moore
We've release v1.1 of DProbes - deatils and code is on the DProbes web page. the enhancements include: - DProbes for kernel version 2.4.0-test7 is now available. - Provision to invoke other debug facilities (SGI KDB, Crash Dump and coredumps) from a probe program. - Probe points can now be a

Re: DProbes with LTT

2000-10-10 Thread richardj_moore
Karim, I've been back through an initial evaluation we did for LTT, back in May. One of the feature we highlighted we'd like to see was an ability to specify custom formatting templates. Our original OS/2 trace facility allowed the user to generate formatting templates which would specify pri

Re: The case for a standard kernel debugger

2000-10-09 Thread richardj_moore
>Hence, yes I can provide an interface from the kernel to log a trace event >with a variable length buffer, but I don't think that taking away the statically >defined trace points is the right thing to do. (I might have gotten this >completely wrong, though ... My presumption about your suggest

Re: The case for a standard kernel debugger

2000-10-06 Thread richardj_moore
Completely agree - co-operation+integration is the order of the day. They other thing I didn't mention was that the GKHI was substantially coded before we discovered your hook capability. Part of the GKHI is also to allow hooks to be dynamicaly defined i.e. to allow kernel modules to declare hoo

Re: The case for a standard kernel debugger

2000-10-06 Thread richardj_moore
Yes, we looked at that and it didn't seem to provide the generality we needed - multipe exits registered per hook, ability to arm a set of hooks atomically, ability to prioritise dispatching order of a hook exit, MP complient. I may be wrong but the Linux Trace Toolkit hooks like like they were

Re: Phase tree algorithm defined

2000-10-05 Thread richardj_moore
Good! I hope to meet you next week at ALS as I'm giving a pitch on DProbes next Thursday. When is your session? The P-tree by the way is described by Knuth but was modiifed slightly when deployed in HPFS. There are some details of it around - see If I still have any unclassified info - actuall

Re: Phase tree algorithm defined

2000-10-05 Thread richardj_moore
Daniel, This is very valuable - thanks for makeing the effort. You could enhance you document greatly if you provided a few diagrams to illustrate the structure, especially the example file system. I'd suggest converting the document to HTML or XML. Also, I'd like to understand how the Pha

Re: 2.4 kernel problems on 386

2000-10-04 Thread richardj_moore
What you're seeing is a tripple fault. I don't know why this is happening, but usually it has something to do with the double-fault mechanism being damaged (or not set-up) when a double-fault occurs. You mentiuon 386 - I rememeber in OS/2 we have many work-arounds for Intel processor errata - it

Re: Anyone working on multi-threaded core files for 2.4 ?

2000-09-29 Thread richardj_moore
Yes we (IBM Linux Technology Center RAS Team) are. If you have ideas/concerns/requirements please make them known. We are at the point of deciding what to attack. We have other dumping technologies on other OSs we could model a Linux enhancement on. There are many things we'd like to see incorp

Re: cpu reset on laptops and microcode update.

2000-09-21 Thread richardj_moore
I wouldn't have expected a reset to be done on shutdown -r since that doesn't force POST to run. My guess is that we go directly to the BIOS to read the bootstrap (INT 19 is it??) Richard Moore - RAS Project Lead - Linux Technology Centre. http://oss.software.ibm.com/developerworks/opensourc

Re: Linux RAS

2000-09-15 Thread richardj_moore
The comparison is was making was with OS/2, not MVS, because: 1) all too often MVS is cited as being the paradigm for RAS when infact there are special architectural features, as you've pointed out, that might detract from a generalised comparison. 2) OS/2 is an x86 based OS so has the problems

Re: The case for a standard kernel debugger

2000-09-15 Thread richardj_moore
I think the case for the kernel debugger is better stated as the case for RAS (Reliability, Serviceability and Availability) in the kernel, in other words, there is a case for having the right diagnostic, reporting and recovery tools in the right place at the right time. A kdb does not fulfil