- 21 Aug, 2015 1 commit
-
-
Alessandro Rubini authored
While the manual pages say nothing, https://lwn.net/Articles/291793/ hints that we should use POLLERR instead of POLLIN. I hoped to get rid of some of the poll messages, but nothing changes in simple tests. I hope we get rid of the EAGAIN in the later recvmsg() (likely with POLLIN we got the socket as readable, but nothing was in the error queue -- we had a new incoming frame instead). Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
- 23 Jul, 2015 1 commit
-
-
Alessandro Rubini authored
commit 3b985b02 added the new vlan-aware issue function, but didn't remove the old call. Thus, wrs is sending out announce messages twice in a row (with two proper sequence numbers). Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
- 22 Jul, 2015 3 commits
-
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
The old code used to discard every other tuple, because when "wait for hardware was set", the code cleared the flag and did nothing. This was exposed by one of the clean-up passes, but I chose not to change the behaviour. Now I do the normal work when wait_for_hw gets cleared. However, as a side effect, wr_mon was always saying "wait for hardware", because any action would set the flag. Thus, the solution is not setting the flag in TRACK_PHASE, but only in the initial SYNC_SEC and SYNC_NSEC states. The code then checks if the hardware is busy, irrespective of any flag. The result in wr_mon is matching reality, and the code works twice as fast as it used to. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
The previous code to set system time from WR time is not really working. It is implemented in wrs_time_ops->set and it relies on ppsi being non-wr slave before being wr slave, but this should not happen. Such code, with its "weird" message, remains in place to be used when we run in non-wr mode (as slaves). This new code is the right thing to do: when we are done syncing the "big steps" in WR, and start dealing with sub-tick, we jump system time. There is no correction for TAI/UTC because the time operations for arch-unux (set/get) already do the conversion. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
- 21 Jul, 2015 5 commits
-
-
Alessandro Rubini authored
Since commit f3d427ee, we lost the concept of "next_state" (to make code simple), but this means that we should report to wr_mon the state string we acted on, not the next. Otherwise, we see SYNC_PHASE all the time, when we are actually waiting for SYNC_SEC or SYNC_NSEC to complete the adjustment. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Earlier we only called it in from slave state, but it's correct to do it in any state (thus also from st_com_master_handle_announce, used by listening and master mode. This makes WR syncing much faster. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
- 20 Jul, 2015 2 commits
-
-
Alessandro Rubini authored
Sometimes we get error in the recv(MSGQUEUE), with EAGAIN. Likely we got a real frame (so poll for reading is ok) but no stamp yet. This unsynced the transmitted frames and the error queue. This fix, i.e. retry if getting nothing, seems to fix the (rare) problem. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
If we were offset by a whole second, we'd remain in SYNC_SEC (SYNC_TAI) without moving to SYNC_PHASE. It happens when you change the second counter by hand, but it's very unlikely in the initial setup. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
- 10 Jul, 2015 1 commit
-
-
Adam Wujek authored
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>
-
- 09 Jul, 2015 3 commits
-
-
Alessandro Rubini authored
What happened, sometimes, is that the phase setpoint take a meaningless (and high) value. This is because we were into SYNC_NSEC and moved to SYNC_PHASE without checking. Maybe because of other problems too. That situation led to a lockup of the softpll, which tries to reach an unreachable setpoint. Now we force to stay in SYNC_NSEC if the offset is more than one cycle (and SYNC_SEC if more than one second). As a side effect, the phase setpoint is always 0..16ns (while earlier I got setpoints of 1.5 of 17.5 etc, up to 64.5 for the same setup and same temperature). The problem here is: what is going to happen if, by thermal effect, the phase setpoint crosses the 0..16n interval? Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Adam Wujek authored
-
- 08 Jul, 2015 3 commits
-
-
Adam Wujek authored
Tune SNMP_MAX_OFFSET_PS and SNMP_MAX_DELTA_RTT_PS Signed-off-by: Adam Wujek <adam.wujek@cern.ch>
-
Adam Wujek authored
Remove the n_err_rxtx_deltas from the struct wr_servo_state since it is not used anymore. Checking deltas was moved directly to SNMPD. Signed-off-by: Adam Wujek <adam.wujek@cern.ch>
-
Adam Wujek authored
Checking whether deltas are zero is moved to SNMP. Signed-off-by: Adam Wujek <adam.wujek@cern.ch>
-
- 06 Jul, 2015 21 commits
-
-
Benoit Rat authored
When changing the state of the WR servo we can call a hook (function pointer) to a function defined by a user in the upper layer (wrpc-sw). The purpose of the hook is to add new functionalities when we reach a specific state (Alarms, IRIGB, etc...) without needing to change the code of PPSI. [This is a rework of the original patch by Benoit. Mainly, I added the extra integer argument to the hook (so I call it twice: both entering and leaving the servo), and I removed the function to set the hook from wrpc: the main function can set the pointer directly] Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
-
Alessandro Rubini authored
The switch is padding short frames sent from the CPU in the nic core. When the frame is then being sent to an "access" port, the tag is removed, and thus the frame gets shorter. The net effect is that sync/f-up/delay-rep were sent short, and discarded by the recipient. Greg could move padding to the endpoint, but this extra work is not really needed, as nobody else is expected to get frames from the CPU over the SFP ports. So we chose to fix transmission in software and avoid to change the gateware. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
The way vlan frames are received is different on wrs than in normal Linux. Likely my own driver (for wrs hardware) is not doing the right thing. So, when we receive tagged frames, they reach us as-is (not as the payload only, with "aux" data on a side). This commit considers this case. The commit also fixes a pair of other details -- mostly, the amount of "short packet of 0 bytes, ignored", by returning -2 to mean "drop with no error". Signed-off-by: Alessandro Rubini <rubini@gnudd.com> SQUASH fix for ARCH_WRS Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
When we support multiple vlans, we must issue announce to all supported vlans. Same applies to sync/follow-up. This changes state-master.c to do the sending several times. Initially I changed msg.c (for the announce message only), this saved the repeated call to msg_pack_announce() but by doing it at state-master level I have simpler code and layer consistency (doing sync/fup at msg.c level would be a mess). Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
With UDP we have two channels but we talk with the same peers. Moreover, we reply with a general message to an event message, so having two peers was plain wrong. I'm well aware this commit should happen before vlans are introduced, but I don't want to deal with all the conflicts in moving it back. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
The changes to the two socket files are very similar, and rely on the linux way of doing things: on receive we must listen to every protocol and use the auxiliary information to tell vlans apart. On transmit we must build the hardware header with vlan information. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
While looking for an alignment bug I had bad frames: being able to look at the binary content of all ptp-ethtype frames (or ip/udp/ptp) is very useful in that situation. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
This requires some change to the include files, to be able to build for all architectures. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
The vlanhdr is not something I can find in standard include files, so here is a custom definition, called pp_vlanhdr. Adding peer_vid is needed so a master can reply to its own slave, while listening to several vlans. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
This step is in preparation for vlan support, where the tx and rx headers have a different length. This commit doesn't build for arch-wrpc, fixed in the next commit Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
This "netpath" is a pain, completely needless. The NP(ppi) is overhead in the code and must be removed. It is now turned to an identity function, so external patches won't conflict. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
This is partly undoing the previous commit, but there is really no common code between udp and raw in the init path. Besides, initializing for vlan means creating a raw socket, and we'd break the whole "switch" idea. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
We can't have VLAN support with UDP, since this VLAN is a hack (needed for GSI operational setup). The error check about udp+vlan is only in time-unix, because arch-wrs uses unix socket initialization, and other architectures can't run UDP. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-