Am 23.01.2013 um 10:12 schrieb David Armstrong:

>>>> On 21-1-2013 22:20, Michael Haberler wrote:
>>>>>> 
>>>>> I assume Bas will give the postmortem shortly - he nailed the issue; the 
>>>>> RTC boot timewarp makes for a lost DHCP lease midflight and NFS freezing, 
>>>>> making it look like a kernel hang.
>>>>> 

> ok i dont mind being shot down in flames , but would adding a RTC module 
> be a answer
> for example :-)
> 
> http://www.ebay.co.uk/itm/New-Arduino-I2C-RTC-DS1307-AT24C32-Real-Time-Clock-Module-For-AVR-ARM-PIC-/170794819927?pt=UK_BOI_Electrical_Comp
> 
> although i must admit it ends up having all sorts of a rats nest for now 
> , and if theirs no other answer
> and we end up making an interface for the Beagle the it could be more 
> permamant
> 
> i mention the above rtc only for the fact that i have one laying around


I'd think that'd be way overkill, it looks like one of this PC-architecture 
based assumptions violated which can be relied upon to have a battery-backed RTC

now that we know what is at the core of the problem, all we need is a robust 
way of handling it, i.e. to assure that a lease doesnt expire underneath 
midflight

there are several ways to 'fix' it for now, with varying degrees of sturdyness 
and elegance

- the most robust way for now is use a static IP address assignment in 
/etc/network/interfaces (that's the 'given a big enough hammer...' method, 
although your hammer would be much bigger ;)
- I installed ntp and this seems to time-warp the RTC right away, but it 
assumes connectivity to an NTP server and making a successful boot conditional 
on NTP is less than bright and an excellent source of support problems
- renewing the dhcp lease during boot after setting the time might be an option
- I'm working on an updated BB xenomai kernel which seems the 'fixrtc' option 
wired in as the bootlog says:
  [    1.598631] omap_rtc am33xx-rtc: setting system clock to 2013-01-23 
10:07:21 UTC (1358935641)
  without me adding 'fixrtc' to the boot command line - I think this is a 
dubious method though since all it needs to fail miserably is to power off the 
BB long enough

btw Xenomai per se doesnt need RTC support, so it's a plain Linux issue.

summary: make it work now; make it work elegantly later. Dont bother squashing 
rather trivial bugs with extra hardware.

- Michael

ps: on the new kernel - working with 'TI official sources' doesnt necessarily 
translate into 'that's been through some really painstaking quality control' - 
there are all sorts of issues, like code which has syntax errors derived from a 
copy & paste and obviously nobody even tried to compile the result; or options 
introduced which make the build break if the option isnt selected and the like.

Suddenly our buildbot looks like a stunning quality assurance tool on the 
forefront of software engineering ;)









------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to