lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e25071430909260512q3d23d3a0h901dc3416a4c2ddd@mail.gmail.com>
Date:	Sat, 26 Sep 2009 08:12:00 -0400
From:	Loren Rogers <loren.rogers@...il.com>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Kernel getting hosed?

Thanks Robert!  I'm pretty sure we have no process mucking with the
clock.  Is there any way I can diagnose "who" is the culprit?  Are
there any useful tools you suggest? We have attempted to use gdb, and
when we get into this "state" we cannot break into gdb.  We have
attempted to use a Lauterbach (j-tag) and when we "break" into this
state, all threads seem to be in the scheduled state like normal.  We
have also attempted to use oprofile, but notice that there are missing
files during the 5 minutes we are in this state.
Thanks,
/Loren


On Fri, Sep 25, 2009 at 10:47 PM, Robert Hancock <hancockrwd@...il.com> wrote:
> On 09/25/2009 07:02 PM, Loren Rogers wrote:
>>
>> Hello,
>> I am developing a multi-threaded media-based application written for
>> an iMX27-based processor running kernel 2.6.24.  But I'm seeing a
>> weird "phenomenon" where certain processes/threads are not being
>> serviced and my clock (according to gettimeofday()) get's set back as
>> well.  There are many symptoms to this behavior.  Here are some
>> symptoms:
>>
>> 1. It's usually the same application-based threads that are either
>> being serviced or not serviced
>> 2. The problem usually lasts for about 5 and a half minutes and then
>> appears to correct itself
>> 3. I'll see the cpu load for my application-process quickly jump up to
>> 99% right before the phenomenon (according to top)
>> 4. My IP-telnet and serial terminal sessions are both unusable.
>> 5. I have a logging utility with a timestamp feature (gettimeofday())
>> where, once this problem corrects itself, the clock has been set to
>> the exact time the problem started (i.e. let's say the problem starts
>> at 12:00:00, and I'll be logging msgs like 12:01:00, 12:04:22, etc...
>> Then after the problem "stops" the timestamp on my logger is once
>> again 12:00:00).  And when I do a command "date" the clock will say
>> 12:00:00!
>> 6. I think all of my IP-based network threads are being serviced.
>> 7. A colleague wrote a utility on one of the "alive" threads to start
>> collecting proc data once we know we are in this state; and he told me
>> that the proc counters have pretty much halted.
>>
>>
>> My colleagues and I have been chasing this for three weeks now.  I
>> have no clue on how to determine the culprit(s).  At first I thought
>> it was some bad code in the user-based application, but can someone
>> tell me with 100% certainty that this is either a user-space problem
>> or a kernel problem?  If it is a kernel problem, how can a user-space
>> application hose a kernel to this extent?
>>
>> If anybody can help me with some tool or tools to help diagnose the
>> cause of the problem or even where to start looking I would REALLY
>> appreciate it.  Thank you
>
> If the system clock is jumping backwards then unless some process is mucking
> with the clock, sounds like there's some kind of kernel timekeeping problem
> on that platform..
>



-- 
"Some men see things as they are and say why. I dream things that
never were and say why not?" - GBS
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ