From mint-bounce@lists.fishpool.fi Wed Aug 18 15:27:58 2010 X-Virus-Scanned: amavisd-new at demon.co.uk Subject: Re: [MiNT] My problems with 1.17 (8/13 trunk) so far (untested in 1.16 beta) From: Alan Hourihane To: Keith Scroggins Cc: mint@lists.fishpool.fi In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Aug 2010 20:25:13 +0100 Message-ID: <1282159513.9133.7.camel@jetpack.demon.co.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: alanh@fairlite.co.uk Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: On Wed, 2010-08-18 at 15:16 -0400, Keith Scroggins wrote: > Problems I have been having: > > scp freezes, needing to be killed, or drops the connections, did not > happen previously. Have not figured out a pattern, even from debug > output. > > ssh into the system (sshd), connections seem to drop in 10 minutes or > less, but this needs more testing. Remote debug says the Atari dropped > it. > > telnet / ftp logins are failing sometimes based on timeouts, the machine > seems to stop listening after username is given. Works most of the time > though. Might only be an issue when, say, gcc is compiling and trying to > log in? Not sure yet. > > These could all be network issues with the ethernec driver, possibly. Not experienced any of the above here. > vi will hang, and needs to be killed. Never previously had this problem > and have made extensive use of vi. Seems to happen when I am inputing > commands too quickly for it to handle, like a buffer issue. Working on > compiling / cross compiling latest vim. As mentioned in a previous email I have similar problems with vim occasionally, but I think this is a vim problem with temporary files on our platform. > Have had configure script fail with sed (latest version). Basically it > freezes at the same test, and never comes back til killed. It takes about > 15 to 30 seconds for a CTRL-C to be read. This isn't a freeze but a side effect of the test it's doing. Essentially, leave it for about 30 minutes :-) I know the problem but it's a hard fix. Alan. > Here is the config.log snippet: > > configure:16371: checking for working mkstemp > configure:16415: gcc -o conftest -g -O2 conftest.c >&5 > configure:16418: $? = 0 > configure:16424: ./conftest > > And the source code is attached to this message. > > My system: > > Falcon - 72 Mhz CT60 (Rev 6) with 20 Mhz Bus, EtherNec, 14 Meg ST, 512 Meg > TT/FastRAM. 500 GB SATA / SATA DVDR. > > Latest released RPMs from SpareMiNT for everything, except GCC, which is > 4.5.1. > > ps -ef shows: > > root@falcon:/usr/local/src/sed-4.2>ps -ef > PID PPID PRI CURPRI STATUS SIZE TIME COMMAND > 000 000 0 0 Wait 98304 16:05.59 MiNT > 001 000 0 0 Wait 98304 00:00.13 init > 002 000 0 0 Sleep 98304 01:44.29 update > 015 000 0 0 TSR 163840 00:02.05 EXTENDOS > 031 000 0 0 Sleep 262144 00:01.79 syslogd > 049 000 0 0 Sleep 212992 00:00.04 inetd > 067 001 0 0 Sleep 73728 00:00.06 getty console > 068 049 0 0 Ready 188416 00:00.41 in > 069 068 0 0 Ready 770048 00:01.03 bash > 156 049 0 0 Sleep 188416 00:00.44 in > 157 156 0 0 Wait 770048 00:01.31 bash > 192 157 0 0 Sleep 2097152 00:00.68 lynx www.sparemint.org/sparemint/m > int/kernel/1.16.1/ > 221 069 0 21 Ready 49152 00:00.03 ps -ef > > I killed sshd as there was no purpose to having it run since it was not > currently usable. And, as can be seen, currently getting the previous > beta kernel to setup, hopefully tonight, but it might be a few days.