dglo / dor-driver Goto Github PK

dor driver does not seem to unload after
long (>6 hr) mjb tests. this causes
unnecessary domhub reboots to reload
the driver...

No associated GitHub commit

No associated GitHub commit

see if this can be optimized further

No associated GitHub commit

Some DOMs are dropping out of the run (timeouts in the 'transitionToDomApp' call). This appears to be a softboot issue.

No associated GitHub commit

No associated GitHub commit

The discussion with Azriel and the previous driver bug fix of last month led me to think about what happens with Kalle cuts the power due to current/voltage over/under limits (firmware fuse).

Since I keep a copy of the control bits (CTRL 0..3), there is a problem if Kalle turns off the power and the user does anything else afterwards involving the CTRL register (which is just about everything!). I.e. the driver will just turn the power right back on again, because I don't "know" that the firmware has turned the power off. This is obviously not good. The power-on sequence in the driver checks for this, but really I should check it at all other times (at interrupt time) -- i.e. to safeguard against a changing electrical situation.

I think the necessary fix is to create a small interrupt handler to handle the power-off bits correctly (detect power-off condition and set CTRL 0..3 appropriately). Kalle already has the necessary interrupt enabled, I just have to use it.

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

Hex dump and ascii summary

No associated GitHub commit

No associated GitHub commit

Needs firmware from Kalle first

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

off by one error - for fix, see queue is full function in simglue.h in hubsim project

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

No associated GitHub commit

.

No associated GitHub commit

dor driver full load echo-test performance
is still sub par (afaik). to reproduce,
run echo-test on 64 doms and check the
system and user load, it should be <20%
on the 1.1GHz CPU card. at last check
it was around 80%...

Additional Information: According to David Hays, a fully loaded Hub running the 1.1GHz card shows adequate performance (DHapp + Driver < 80% loaded), with full bandwidth on all DOMs.

a restart of the dor-driver is currently required, which means that you end up power cycling ALL DOMs in order to get around this problem, which is a disaster!

No associated GitHub commit

No associated GitHub commit

This shows up with the JRockit JVM. 'signal occurred during softboot' causes interruption of softboot, and an EAGAIN.

Steps to Reproduce: Run pDAQ w/ JRockit JVM

No associated GitHub commit

waveform recording and output has been
supported by dor fw since nov of last
year. afaik, it is still not implemented
in dor-driver. this is an important
feature for tracking down comm problems...

No associated GitHub commit

No associated GitHub commit