Manual time set bug

At the moment I haven’t a net connection for my Beagleboard -xm so am setting the time at each switch on. I find that after doing so the clock is one hour slow. Repeating the setting a second time (correcting it by one hour) then sets the correct time. It’s the same whether set from Configure or Alarm.

Other settings are UTC+00:00 UK ‘GMT’ & Switch DST automatically – yes. ROS 5.19 – 3 Feb.

[Later] Don’t know if it’s a clue but this means the first time I’m setting date & time, the second just the time.

I’ve now connected my BB -xm to my modem through a homeplug. Discovered that the time wouldn’t set from any ntp server, the configuration box always displayed ‘busy’. Found also that Hermes & NewsHound couldn’t resolve their connections & timed out. FTPc the same. The only network related thing that worked was Netsurf.

Thought about what had changed since last network connection in November. I’d updated the ROM to 3 Feb & disc image to 27 Nov. Reverted the ROM from 3 Feb 2013 to my last backup, 29 Oct 2012. Presto – everything working back to normal including correct time setting.

Has anything changed between November & now that I might not have accounted for?

Found also that Hermes & NewsHound couldn’t resolve their connections & timed out. FTPc the same. The only network related thing that worked was Netsurf.

This sounds like a resolver problem. NetSurf uses its own inbuilt resolver code, whereas all the others mentioned will be using the OS resolver. One assumes all your IP settings are correct in configuration-Network. I regularly update the BB ROM, Use homeplug for networking. I haven’t noticed any problems, but use mainly NetSurf on the BB, all mail/news etc still on the Iyonix. I will have a play later to check some of these other apps on the BB.

One assumes all your IP settings are correct in configuration-Network.

Reverting to an earlier ROM fixes the problem so I assume so. It does look like a resolver issue, I agree.

I have just tried FTPc on the BB. It seemed fine. I am currently using RISC OS ROM dated 28 Jan, and FTPc 1.48 (7 Dec 2011). I could try Pluto/Newshound later if you think that would add anything.

Don’t think there will have been any changes to resolver itself – mine is 0.69 (11 Jul 2004).

Do you get sensible output from eg *inetstat -r or *arp -a ?

Reverting to an earlier ROM fixes the problem so I assume so. It does look like a resolver issue, I agree.

Whenever this happens a ‘rmreinit resolver’ should get the resolver working again.
I’m not sure what causes it. It seems to happen every now and then with certain ROM builds. Maybe try a later ROM build and the problem will be gone again.

Whenever this happens a ‘rmreinit resolver’ should get the resolver working again.

Ah, that gives me something to look at when I get home. Wonder if modules have moved around since November.

Whenever this happens a ‘rmreinit resolver’ should get the resolver working again.

That works but doesn’t survive a hard reset. Checked to see if anything was unplugged first but nothing was. Strange.

Same issue with 10 Feb ROM.

Do you get sensible output from eg *inetstat -r or *arp -a ?

After RMReinit, yes. Beforehand only quad dot values are displayed, unresolved to names.

The fundamental question is what is screwing with the resolver module in the first place?

It is a bit like (although not the same, obviously) the problem (one of many) with the A9 which I don’t think ROL/Advantage6 ever sorted, which used to lose the resolver module after a few minutesand one needed an obey file on the pinboard to reinit it as required.

A work around might be to have an obey file, run late in boot to rmreinit the resolver, but the cure would be to trace where the problem arises. It doesn’t seem to be a generic fault in the OS, otherwise others would see it. Maybe moving the rmreinit earlier and earlier in the boot sequence until it is run before the problem arises. I am assuming from your earlier comments that it is going wrong during Boot, rather than after a particular app is run.

I made an obey file to rmreinit the resolver. I tried it in predesk & in tasks & in both cases it failed. It does work if typed from the command line after boot.

I am assuming from your earlier comments that it is going wrong during Boot, rather than after a particular app is run.

Setting the time immediately after boot fails. As previously mentioned there’s no problem using an earlier ROM with the same HDD image.

If one called the obey file something like ~~~initres then it would be the last thing to be run in tasks during boot. If it fails there, but the rmreinit works when it is the very first thing done after boot has completed, then it looks like one of the apps run during boot may be the culprit.

then it looks like one of the apps run during boot may be the culprit.

http://www.heyrick.co.uk/software/harinezumi/ ?

If one called the obey file something like ~~~initres then it would be the last thing to be run in tasks during boot. If it fails there, but the rmreinit works when it is the very first thing done after boot has completed, then it looks like one of the apps run during boot may be the culprit.

Making the obey file the last item in Tasks works.

I tried reverting to a previously backed up !Boot in case there was anything in the last update (27 Nov) to cause problems. No difference in result. Oct 29 ROM works, January ones don’t.

I just don’t get why one ROM works whilst a later one doesn’t if it’s not related to a ROM change when all else is unchanged. I could understand it if !Boot wasn’t kept synchronised but that doesn’t apply here.

Making the obey file the last item in Tasks works.

Odd. There must be something in tasks that is behaving differently with the new ROM. The only thing in Tasks on my ARMini that is network related is an obey file ‘TimeSetup’.

Presumably, by changing the obeyfile name it should be possible to run it at different times in tasks, eg using leading plings should force it to be first, and naming it say pinsetup2 should run it after pinsetup etc. You could try running it before and after TimeSetup, assuming you have that file.

The only thing in Tasks on my ARMini that is network related is an obey file ‘TimeSetup’.

Same here. I’ll fiddle with the sequence.

TimeSetup is normally the last file in my Tasks dir. Putting the obey file to reinit Resolver after it allows normal running. Putting the obey file immediately before TimeSetup re-introduces the problem.

My version of NetTime is 0.40

Very curious. I have just checked my ARMini – it is running NetTime ver. 0.40 (10 Apr 2012), which appears to be in 360.Modules.Network. There is also ver. 0.36 in 310.Modules.Network. I never noticed the resolver problem on the ARMini when I was running mail/news on it, or when using FTPc to my web sites, although in general use I only regularly use NetSurf which has its own resolver.

I think the ARMini is due a reboot, having been up for about 3 weeks, so I will try running FTP immediately after a reboot and see whether it is go/no go.

Now done a reboot – no apps are run during boot, so the machine was as clean as it was going to be.

Ran FTPc and uploaded the latest changes to my web site without problem.

Looks like there is something odd about your setup. What time server are you using? I am using uk.pool.ntp.org.

If you do not do the rmreinit, what status does the resolver module show in *rommodules (active, dormant)?

What time server are you using?

I’ve used the time servers at Demon, O2 & Pool. Usually Demon.

If you do not do the rmreinit, what status does the resolver module show in *rommodules (active, dormant)?

Resolver is active.

Just to throw another spanner, once Resolver is reinitialised after power up everything continues to work even through a shutdown & restart. Resolver doesn’t need Reinit a second time. It’s only if the BB is powered off again that the problem arises.

@ Chris Johnson – Are you still using the RISC OS ROM dated 28 Jan? If so,would it be possible to have a copy?

@Fred – I still have a copy of that ROM, where do I send it?

Great, thanks. To fredATypicalDOTdemonDOTcoDOTuk please

The 28th Jan ROM demonstrates the same Resolver problem as the later ones on my BB -xm so something’s different ’tween that and my 29th October ROM.

Does the Beagleboard in the ARMini have a battery fitted?

The 28th Jan ROM demonstrates the same Resolver problem as the later ones on my BB -xm so something’s different ’tween that and my 29th October ROM.

There are 21 different images I know¹ of between those two dates.
Having said that, as I recall there were peculiarities with time setting as well as display settings that seemed to go away when I fitted the widget. Do you also have loss of DPMS settings?

¹ Squirrel genetics…