Don't know the 7550 and whether you are running an SD card
or not, but
On both the 7370 and 7260 I've experienced "pauses" while typing.
Generally few seconds, not the 30 seconds you describe.
Never got to the bottom of it on 7260 as switched projects before
I could chase it down.
On 7370 project, it's believed to be caused by a bug in kernel SD
driver: tss<whatever>.
Technologic System had us switch to user level SD drivers (nbd) and the
problem went away.
Not sure it's related, but one more data point...
tc
Ryan wrote:
>
> That doesn't seem to be what we are seeing. In both of my test cases
> there was a good 40mb of memory free, no extraneous processes or
> memory hogs to speak of. Additionally, linux will freeze up an
> interactive "application program" eating up processor on an malloc
> when it is memory starved, but only until the OOM kicks in and kills
> and cleans up the hogs... The symptoms would be much different than
> what myself and Martin are describing. No interactivity with the
> shell/process would exist, whereas we have interactivity, just no
> console output.
>
> On 09/28/11 13:58, Walter Marvin wrote:
>
>> I have observed such "glitches" in several application programs. My
>> recollection is that removing unneeded servers solved the problem.
>> The theory is that the kernel gets "memory starved" The entire system
>> can only use real memory. This is just a hypothesis and not confirmed
>>
>> thanks
>>
>> Walter
>>
>> ------------------------------------------------------------------------
>> *From:* Ryan <>
>> *To:*
>> *Sent:* Wednesday, September 28, 2011 12:25 PM
>> *Subject:* Re: [ts-7000] TS7550 - network glitches?
>>
>> I have experienced the same thing (only using mostly SSH) on the
>> TS-7553. The commands are being processed as you say, it is merely
>> the output being echoed back. I have never seen such a thing before
>> this either, and had reported it to technologic. I have also noticed
>> that it's not just after a period of time, it is dependent on how
>> many chars are waiting as well. Too many, and you get a connection
>> reset by peer, not enough and it hangs up on the other side and when
>> you type something you get a write failed: broken pipe instead. It
>> appears TCP is fighting very hard to keep it going but there is
>> errors, yet, if you look at the interface statistics it says no such
>> thing. So It appears to be an issue at the kernel level (or perhaps
>> also hardware error that is just not being detected by the kernel
>> driver)...
>> I have also noticed, interestingly, the problem happens much less
>> often, but still happens, when I boot from an SD card using the
>> Jun082011 image. I have not tried the sep06 image yet (and would be
>> difficult to do so since I've installed many custom packages).
>>
>> Another observation I've made, which makes it even more confusing, is
>> that if I have multiple SSH sessions open, it is only ONE of them
>> that is affected this way, I can still access the other sessions
>> normally. It's AS IF scroll-lock was in effect on that one terminal,
>> even though it's not, and randomly restarts with no intervention.
>>
>> Have you tried the latest image?
>>
>> On 09/28/11 06:16, naturalwatt wrote:
>>> Hi.
>>>
>>> Has anyone else experienced what feels like lockups when connecting
>>> to the TS7500/TS7550 boards using telnet?
>>>
>>> This is running Debian on the boards and does not affect TS7250.
>>>
>>> While typing away, every few minutes (but not predictably or
>>> consistently) it suddenly seems to go dead, only to carry on where
>>> you left off after around 30 seconds or so. It is not related to
>>> filesystem access as far as I can tell. I wrote a program to usleep
>>> and produce a histogram of delays, and this shows it is not a system
>>> wide lockup - in addition the watchdog does not go off.
>>>
>>> If you have another telnet session to the same board, that will
>>> experience lockups at different times to the first one.
>>>
>>> All the systems (TS7250 and TS7550) are on the local subnet.
>>>
>>> It feels like a network problem, and I have some evidence that
>>> characters I type are being received but not echoed. If I type a
>>> command that has an effect on the LEDs, that is actioned even though
>>> I cannot see the keystrokes I enter.
>>>
>>> I've never seen a problem exactly like this and would welcome any
>>> suggestions for solution or investigation.
>>>
>>> Martin
>>>
>>
>>
>> --
>> Ryan
>>
>>
>>
>
>
> --
> Ryan
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|