Terry Lambert said:
> The problem is that ktrace/kdump rendesvous at a file;
> truss does
> not, so it has some capabilities that ktrace does not.
> In some
> circumstances (e.g. a system crash, where kdump doesn't
> get a
> chance to get at the file, because it's "cleaned up"
> and not
> even ful
John Baldwin wrote:
> Since ktrace logs all syscall entries and exits, it should seem that
> a kdump after the process had exited would show which syscall returned
> EAGAIN quite easily.
This works if the process exits after the EAGAIN; that would only
work for the specific error that people are s
On 18-Jul-2003 Terry Lambert wrote:
> Pawel Jakub Dawidek wrote:
>> +> trussRelies on the event model of procfs; there have been some
>> +> initial patches and discussion of migrating truss to ptrace() but
>> +> I don't think we have anything very usable y
In the last episode (Jul 18), Pawel Jakub Dawidek said:
> On Fri, Jul 18, 2003 at 01:45:34AM -0700, Terry Lambert wrote:
> +> > +> truss Relies on the event model of procfs; there have been
> +> > +>some initial patches and discussion of migrating truss
> +> > +>to ptrace() but I d
On Fri, Jul 18, 2003 at 01:45:34AM -0700, Terry Lambert wrote:
+> > +> trussRelies on the event model of procfs; there have been some
+> > +> initial patches and discussion of migrating truss to ptrace() but
+> > +> I don't think we have anything very usabl
Pawel Jakub Dawidek wrote:
> +> trussRelies on the event model of procfs; there have been some
> +> initial patches and discussion of migrating truss to ptrace() but
> +> I don't think we have anything very usable yet. I'd be happy to
> +> be
On Thu, Jul 17, 2003 at 01:01:11PM -0400, Robert Watson wrote:
+> Most system functionality that relied on procfs has been rewritten to rely
+> on other mechanisms. In general, I advise against running procfs--it's
+> interesting, but conceptually it's very risky. If you look at the history
+> of
On Tue, 15 Jul 2003, Josh Brooks wrote:
> I have loaded two 5.1-RELEASE systems, both of them have PROCFS and
> PSEUDOFS in the kernel, and yet neither of them have a procfs mounted.
>
> There is no procfs line in /etc/fstab by default, and no procfs is
> mounted on the system in any way.
>
>
On Tue, Jul 15, 2003 at 10:43:19PM -0700, Josh Brooks wrote:
[...]
> One of the systems, the one I am doing all the work on, is an SMP system,
> and it keeps locking up on me - the lockups are always the same - things
> are going fine, and suddenly a process fails to complete - maybe it is
> "pwd"
On Wed, 16 Jul 2003, Bruce M Simpson wrote:
> On Tue, Jul 15, 2003 at 10:43:19PM -0700, Josh Brooks wrote:
> > I have loaded two 5.1-RELEASE systems, both of them have PROCFS and
> > PSEUDOFS in the kernel, and yet neither of them have a procfs mounted.
>
> I think one of the first things people
On Tue, Jul 15, 2003 at 10:43:19PM -0700, Josh Brooks wrote:
> I have loaded two 5.1-RELEASE systems, both of them have PROCFS and
> PSEUDOFS in the kernel, and yet neither of them have a procfs mounted.
I think one of the first things people are going to ask is:
which scheduler are you using, SCH
Hello,
I have loaded two 5.1-RELEASE systems, both of them have PROCFS and
PSEUDOFS in the kernel, and yet neither of them have a procfs mounted.
There is no procfs line in /etc/fstab by default, and no procfs is mounted
on the system in any way.
Question 1: Is this intentional ? Is it no lo
12 matches
Mail list logo
