|
Hans-Peter Reichert
|
reported event time (re)starts with zero on every new tracebuffer in a kev file
|
|
Hans-Peter Reichert
02/06/2008 2:55 AM
post4821
|
reported event time (re)starts with zero on every new tracebuffer in a kev file
already posted this weeks ago, but nobody replied.
so after installing the latest build 200802041024 - I tried adain, but sill ...
The shown time of an event in the "Trace Log" view starts with zero on every new tracebuffer.
see here:
Event, Time, Owner, Type, Data
293815, 999ms 995us, MMI3GApplication (77854) Thread 7 (7), SyncSemPost Enter, sync_ptr 0x803aa2c count 0 owner
0xfffffffc
293816, , MMI3GApplication (77854) Thread 14 (14), Ready, pid 77854 tid 14 priority 15 policy 2
293817, 2us, MMI3GApplication (77854) Thread 7 (7), SyncSemPost Exit, ret_val 0x0
this is not very handy, 'cause you can't use this information anymore
and using "Real Time" instead is not really an option.
|
|
|
|
|
|
Colin Burgess(deleted)
|
Re: reported event time (re)starts with zero on every new tracebuffer
in a kev file
|
|
Colin Burgess(deleted)
02/06/2008 3:48 AM
post4822
|
Re: reported event time (re)starts with zero on every new tracebuffer
in a kev file
HP I don't see this with the same build - could you send me the logfile?
Hans-Peter Reicher wrote:
> already posted this weeks ago, but nobody replied.
> so after installing the latest build 200802041024 - I tried adain, but
> sill ...
>
> The shown time of an event in the "Trace Log" view starts with zero on
> every new tracebuffer.
> see here:
> Event, Time, Owner, Type, Data
> 293815, 999ms 995us, MMI3GApplication (77854) Thread 7 (7), SyncSemPost
> Enter, sync_ptr 0x803aa2c count 0 owner 0xfffffffc
>
> 293816, , MMI3GApplication (77854) Thread 14 (14), Ready, pid 77854 tid
> 14 priority 15 policy 2
> 293817, 2us, MMI3GApplication (77854) Thread 7 (7), SyncSemPost Exit,
> ret_val 0x0
>
> this is not very handy, 'cause you can't use this information anymore
> and using "Real Time" instead is not really an option.
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post4821
>
--
cburgess@qnx.com
|
|
|
|
|
|
Colin Burgess(deleted)
|
Re: reported event time (re)starts with zero on every new tracebuffer
in a kev file
|
|
Colin Burgess(deleted)
02/06/2008 5:15 AM
post4823
|
Re: reported event time (re)starts with zero on every new tracebuffer
in a kev file
Ok, I do see it in this log!
I don't think it's every buffer - rather, it's every 1 seconds, the time shown
flips from 999ms to 0!
However the cycle counts logged in the trace looks just fine, so I'm stumped
right now.
Hans-Peter Reicher wrote:
> already posted this weeks ago, but nobody replied.
> so after installing the latest build 200802041024 - I tried adain, but
> sill ...
>
> The shown time of an event in the "Trace Log" view starts with zero on
> every new tracebuffer.
> see here:
> Event, Time, Owner, Type, Data
> 293815, 999ms 995us, MMI3GApplication (77854) Thread 7 (7), SyncSemPost
> Enter, sync_ptr 0x803aa2c count 0 owner 0xfffffffc
>
> 293816, , MMI3GApplication (77854) Thread 14 (14), Ready, pid 77854 tid
> 14 priority 15 policy 2
> 293817, 2us, MMI3GApplication (77854) Thread 7 (7), SyncSemPost Exit,
> ret_val 0x0
>
> this is not very handy, 'cause you can't use this information anymore
> and using "Real Time" instead is not really an option.
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post4821
>
--
cburgess@qnx.com
|
|
|
|
|
|
Hans-Peter Reichert
|
Re: reported event time (re)starts with zero on every new tracebuffer
|
|
Hans-Peter Reichert
03/02/2008 8:56 AM
post5447
|
Re: reported event time (re)starts with zero on every new tracebuffer
No change on this issue with
Build id: I20080227
just tested this.
Is there PR filed for this?
/hp
|
|
|
|
|
|
Elena Laskavaia
|
Re: reported event time (re)starts with zero on every new tracebuffer
|
|
Elena Laskavaia
03/03/2008 10:22 AM
post5458
|
Re: reported event time (re)starts with zero on every new tracebuffer
Please report a problem through your customer support channel.
|
|
|
|
|
|
Hans-Peter Reichert
|
Re: reported event time (re)starts with zero on every new tracebuffer
|
|
Hans-Peter Reichert
03/04/2008 2:48 AM
post5483
|
Re: reported event time (re)starts with zero on every new tracebuffer
just imagine that I am doing this testing as a private person, not in my function as an employee.
So why should I have to file a PR (I can't do this as a private one) for something very obvious and something that
aleady is proved by Colin.
Colin also reported to me that after alerting him, he now sees this problem in other logs too - so it's a problem in
general, not a special problem to me
thanks
hp
|
|
|
|
|
|
Thomas Fletcher
|
Re: reported event time (re)starts with zero on every new tracebuffer
|
|
Thomas Fletcher
03/04/2008 10:45 AM
post5487
|
Re: reported event time (re)starts with zero on every new tracebuffer
On Tue, Mar 4, 2008 at 2:48 AM, Hans-Peter Reicher <
hpreichert@harmanbecker.com> wrote:
> just imagine that I am doing this testing as a private person, not in my
> function as an employee.
... but you aren't =;-)
As a general comment. The forums are not a replacement for the QNX support
services. They
enhance the services and provide a direct connection to QNX developers, both
those employed
by QNX and those working with QNX for their own purposes.
If you want to ensure that something is fixed and addressed for your
organization, then using
your support contract is the way to go.
> So why should I have to file a PR (I can't do this as a private one) for
> something very obvious and something that aleady is proved by Colin.
> Colin also reported to me that after alerting him, he now sees this
> problem in other logs too - so it's a problem in general, not a special
> problem to me
>
... but it is important to you and your organization, so you should ensure
that the report gets
filed by your organization. Otherwise it may be seen as an internal report
and not get the visibility
it would normally get as a customer reported PR during problem report
triages. We are attempting
to ensure that customer reported issues get first use of developers time ...
and in the future you
will also be able to more closely track the progress of PR's that you have
filed.
That is why it is important for you to ensure that a PR is filed with your
name/organization attached
to it (whether this is done by Colin or not is a different matter all
together).
Thomas
|
|
|
|
|
|
Elena Laskavaia
|
RE: reported event time (re)starts with zero on every new tracebu
ffer
|
|
Elena Laskavaia
03/04/2008 11:13 AM
post5488
|
RE: reported event time (re)starts with zero on every new tracebu
ffer
Thomas, do you know why it works in 4.0.1? Did you make this special
re-ordering events hack in IDE? Why it stopped working now?
|
|
|
|
|
|
Thomas Fletcher
|
Re: reported event time (re)starts with zero on every new tracebu ffer
|
|
Thomas Fletcher
03/05/2008 11:15 AM
post5529
|
Re: reported event time (re)starts with zero on every new tracebu ffer
On Tue, Mar 4, 2008 at 11:13 AM, Elena Laskavaia <elaskavaia@qnx.com> wrote:
> Thomas, do you know why it works in 4.0.1? Did you make this special
> re-ordering events hack in IDE? Why it stopped working now?
I _believe_ it has to do with the fact that 6.3.2 logs put the buffer event
out before
the time event.
The IDE fix would likely be in the normalizing code, I'm looking at it now
pending Colin giving me some more information.
Thanks,
Thomas
|
|
|
|
|
|
Wjatscheslaw Talanow
|
Re: reported event time (re)starts with zero on every new tracebuffer
|
|
Wjatscheslaw Talanow
03/28/2008 4:56 AM
post6232
|
Re: reported event time (re)starts with zero on every new tracebuffer
I'm working on a plug-in for the SystemProfiler right now and I have the same problem as posted by HP Reichert.
The following code snippet behaves exactly the same way HP Reichert described:
...
final long totalNano = TraceUtil.cycle2ns(cycle, eProv, true);
return TimeFmt.toString(totalNano, TimeFmt.DISPLAY_MILLI |
TimeFmt.DISPLAY_MICRO);
}
I don't know whether the data used for conversion has changed or the conversion algorithm itself. However, I think that
the TraceUtil.cycle2ns(...) method returns the wrong value.
I hope that helps a bit.
Greetings
Slawa
|
|
|
|
|
|
