Notes/Questions for Fraser

Emergency network service if DHCP fails [Is this something that we would be able to put under Common Errors and Troubleshooting?]

  • use the command in redboot on the TS-7200 to manually set the IP address, mask, gateway
Emergency network service if TFTP fails [Is this something that we would be able to put under Common Errors and Troubleshooting?]
  • put a spare PC in the lab (probably on the same net as the TS-7200s)
  • install ubuntu
  • apt-get install tftpd sshfs (see ST#83234)
  • configure tftpd (see ST#83234)
  • use sshfs to mount ~cs452/tftp/ARM/ onto /tftpboot/ARM (see ST#83234)
  • for some detailed examples, see ST#83234 [move Solaris services02.student.cs and services10.student.cs tftp service to linux (especially for CS452 Realtime)] comments at Jan 23 2013 19:10, Feb 20 2013 15:30 and Feb 22 2013 16:28
  • tell the students the IP of the emergency TFTP server PC
  • if no staff are available to do this, tell the students to do it. They invented the procedure in a previous term.









Real-Time Lab Administrator Documentation(DRAFT)

The Real-Time Lab is a lab used by students taking courses in real-time programming (CS 452 / CS 652). It features programmable locomotives (A.K.A trains) where the goal is to... I actually don't know what the goal is]

The normal development cycle is:

  • Recompile the student's kernel and application to a single .elf file
  • Copy the .elf file to under ~cs452/tftp/ARM/ (which has write permission for group cs452_sf). All students in cs452/cs652 should be in group cs452_sf. This is handled automatically by our student account software if they are registered in the course.
  • Reboot a TS-7200 (one second)
  • Wait for it to obtain an address via DHCP (a few seconds, but sometimes 20 seconds when DHCP is not working well)
  • TFTP download a file containing the student's kernel and application (a few seconds)
  • Test, often for only a few minutes until something goes wrong
  • Repeat
During the busy part of the term, students are working in the lab 24 hours a day. This creates a need for very high reliability of network services, especially: [Are you able to think of a better place for this list?]
  • DHCP
  • TFTP
  • nfs or sshfs access from the TFTP servers to ~cs452/tftp/ARM/
  • nfs access from the CS undergrad CPU servers (linux.student.cs) to ~cs452/tftp/ARM/
  • ssh access from

Table of Contents

System Specifications

Trains

  • it would be more correct to call them locomotives or engines, but in this course they are known as trains
  • See trains status at the train status page

The lab

  • Located in MC 3018. There is also a smaller room within MC 3018, which is referred to as MC 3018a.
  • There is a mini-TR [will people acting on your behalf know what this is?] in the room containing two Ethernet switches that serve all jacks in the lab.
  • MC 3018 (The outer room)
    • Every desk in the outer room has an Ethernet jack mounted on the desktop for student use.
    • Most desks have a nettop, save some that are intended for laptop use. These laptop desks have no nettop, but they do have a power bar and Ethernet jack.
    • They should have: a monitor. [I'm not sure if this applies to laptop desks or nettop desks. Could you please clarify?]
    • They may have: a keyboard and mouse. [I'm not sure if this applies to laptop desks or nettop desks. Could you please clarify?]
  • MC 3018s (The inner room)
    • Has 4 work areas, each with:
      • A PC which is used as a console for the TS-7200
      • A small grey box containing a TS-7200 embedded ARM single-board computer
      • A 4 x 8 foot table for a Marklin digitally-controlled train set
    • Tracks A and B are in full operation Do you think it would be appropriate to have a hardware section specifically for the tracks?
    • Track C is under construction Do you think it would be appropriate to have a hardware section specifically for the tracks?
    • Track D does not (yet) exist Do you think it would be appropriate to have a hardware section specifically for the tracks?

Nettops

  • Ask Clayton, Anthony, or Dave
  • More information would be welcome here

TS-7200

PCs

  • Hardware
    • Do not need much performance or capacity from CPU, RAM or disk due to low software requirements
    • Have an rs232 serial port card
      • The primary serial port is used as a console for the TS-7200
      • The second serial port is sometimes needed for debugging (by connecting it to (COM1?)) [We should probably figure this out for sure] on the TS-7200 (the port that normally goes from the TS-7200 to the train set).
  • Software
    • Primary applications being used are gtkterm, with some use of Firefox and PDF viewer
    • They run Ubuntu 10.04 desktop, which will be upgraded to Ubuntu 12.04 for Spring 2013 term
    • Have gtkterm and openssh-server installed
  • Configuration
    • Have automatic login to account "realfolk" at boot time
    • Realfolk has a password, but the students don't know it
    • Do not use our Active Directory
    • Do not have any user accounts, except the realfolk shared account
    • Do not mount the CS undergrad home directories or any other remote files
    • The hostname is the barcode
    • Are on a CS private network, which can't reach off campus or even non-CS networks on campus
    • There is nothing to prevent someone from booting a live CD (or thumbdrive) and taking control of the PC. The students can be trusted to not do this (or very seldom, they have used it to improve the machine, e.g. install useful software, which is allowed, but not encouraged)
TFTP servers:
  • Warning: a TS-7200 can only TFTP using the server's IP address, not its hostname
  • services02.student.cs -- retired
  • services10.student.cs -- in production, but should be retired as soon as possible
    • Solaris 8
    • xhier tftp
      • will only serve requests from 129.97.0.0 networks
  • db2a.student.cs -- proof of concept, not currently known to users * ubuntu 12.04 LXC server
  • tftp1.student.cs -- does not exist yet
  • tftp2.student.cs -- does not exist yet

Authentication and Authorization Information

Many systems demand authentication before they can be accessed. List the information required to gain access to the system. Please do not put passwords on this page. This page will be public and accessible by Google.

People

  • Administrator: Yan Martel
  • Point of contact (expert): Fraser Gunn (fhgunn)
  • Backup Point of Contact: ...
  • Stakeholders:

Terminology

For example:

  • Definitum
    • In a definition the word being defined is the definitum
    • Is a fancy word that nobody ever really uses
  • MarkUs
    • A marking system in which students can submit their code and faculty can provide feedback and assign grades
    • Originates from the University of Toronto
CAUTION: There is a feature for terminology in the Wiki Markup Language. Do not use it. It has been known to break pages.

Guides to the Completion of Scheduled Tasks

Some tasks must be completed on a regular basis. List the scheduled tasks from least frequently recurring to most frequently recurring. Each one must have a detailed guide on how to go about completing the task and how often/when the task must be completed. Try to be as detailed as possible. Use the following the formatting:

Level-3 heading with the frequency of occurrence. (More than one task can be under this heading)

Level-4 heading with a very general description of the task

A paragraph outlining the purpose of doing the task

  1. Description of step
    • Details and notes about how to complete the step
    • Details and notes about how to complete the step
  2. ...

Check for Success

How to see if the scheduled task was completed successfully

For example:

Between Every Term

Empty the database

Keeps things clean and organized

  1. Log in to the database.
    • This is a secure connection
  2. Run the purge command
  3. log out
    • The logout button is at the top-right of the page

Check for Success

Try to return an entry from the database. If it cannot find the entry, the database was emptied successfully.

Another Example, also completed between every term

This example will help you understand

  1. Do this
  2. Do that
  3. Now do something fancy

Check for Success

How to know if it worked

On the First Day of Every Month

Task Name

A really good purpose

  1. Do this
  2. Do that
  3. Now do something fancy

Check for Success

How to know if it worked

Guides to the Completion of Common Requests

Prepare a factory-fresh train for use in CS452

  1. Remove couplers, which snap into the NEM coupler pocket. They should be removed because:
    • They are not used in the course (although an ambitious project may request them)
    • They are soon broken because of the train collisions that are a normal part of debugging
    • They cause unwanted coupling when the trains collide
    • They are tricky to uncouple after unwanted coupling
  2. Remove pantographs, wires, insulators, antennae, horns and any other cosmetic pieces on the roof that can be easily damaged
  3. Set the address to something unique
    • The old trains use dip switches on the circuit board [This confuses me. Why would we be using an old train if we are setting up trains that are factory-fresh?]
    • New trains must be programmed
      • Use the Marklin 60215 Central Station and a test track
      • Remove all other trains from the test track
      • Place the new train on the test track
      • If the train has an MFX decoder, it will be recognized by the Central Station. Otherwise, create the train in the Central Station.
      • Enter maintenance mode
      • Change the address to an unused address
      • Download parameters to train
      • Add the address to the name, e.g. change "Re 1429" to "Re 1429#49"
      • Exit maintenance mode
      • Check that train responds to commands, e.g. headlights, reverse, speed
      • Make and place address labels on roof at front of train (front has pick-up and is labelled "1" or "A" on body) and inside body and frame

Prepare a factory-fresh TS-7200 for use in CS452

  1. Attach a terminal emulator to the TS-7200, e.g. gtkterm, to COM1 @ 115200 baud, 8n1, no flow control
  2. Interrupt (control-C?) [Why is there a question mark? Are we not sure that control-c is the right keystroke?] stock boot within one second, to pull up a RedBoot prompt
  3. Run fconfig to , [I feel like there is a word that is missing in this line. I might be wrong about this...]
    For example:
    RedBoot> fconfig
       Run script at boot: false
       Use BOOTP for network configuration: true
       dns_ip: 172.19.47.5
       Network hardware address [MAC]: 0x00:0xD0:0x69:0x41:0xDA:0xCC
       GDB connection port: 9000
       Force console for special debug messages: false
       Network debug at boot time: false
       Update RedBoot non-volatile configuration - continue (y/n)? y
       ... Erase from 0x607c0000-0x607c1000: .
       ... Program from 0x01fdf000-0x01fe0000 at 0x607c0000: .
       
  4. Open the box and set the jumpers:
    1. Remove JP1 (boot to serial port COM1)
    2. Install JP2 (enable serial console)
    3. Remove JP3 (write enable flash) because we have twice had student programs accidentally trash the flash
    4. Install JP4 (console swapped to COM2) because COM1 has modem control, needed by the train set
    5. Remove JP5 (factory test)
    6. Ignore JP6 (user jumper)
  5. With the box still open, remove DIO cable (ribbon cable from digital I/O header to COM3) because COM3 is a misleading label and we want to protect DIO from people connecting an RS232 serial cable to COM3
  6. Ask Phil [Phil who?] to add a reset button. This requires drilling case, installing button and soldering its wires in parallel with the reset button on the PCB.
    • Though we have yet to try this, it might work to instead wire the button to pins B2 (RESET) and B1 (GND) on the PC/104 bus 64-pin connector. The TS-7200 Hardware Manual says, "The electrical specification for the PC/104 expansion bus is identical to the PC/AT ISA bus." Ask Mike [Mike who?] for an opinion. [We should probably settle on one method. The multiple options here might get confusing. If we want to include this bit of information somewhere in the template, the Current Discussions section would definitely be a good place for it]
    • In a pinch you can skip this step and let the students power cycle to reboot. However:
      • The frequent power cycling should reduce the TS-7200 life expectancy. (This is theoretical; we haven't seen any signs of it.)
      • The wires will break at the power connector in about 2 months. (It's easy to fix.)
      • Students need to reboot frequently and a button is much easier to use.
This section outlines the guides to completing tasks that are commonly requested by clients

Formatting should be similar to the guides to the completion of scheduled tasks section

Level-3 heading with a very high-level description of the request

  1. Description of step
    • Details and notes about how to complete the step
    • Details and notes about how to complete the step
  2. ...

Check for Success

How to see if the requested task was completed successfully

For example:

Set Up an Exam

  1. Log into the system for setting up exams
  2. ...

Check for Success

A list of students and where they will be seated for their exam is outputted

Common Failures/Bugs & Troubleshooting

Weak wireless internet access in the Real-Time Lab

Wireless reception has been poor in the past, because the room was half-way between to APs on the same channel. Wireless users would see frequent ~20 second dropout while their laptop re-associates from one AP to the other.

What do you say when people complain about this? Is there anything that has been done to fix the issue, or is the issue going to be solved in the future?

The wires broke at the power connector

Optional paragraph text that describes the potential causes of the issue

Optional paragraph text to direct which how-to steps should be followed (only applicable if there is more than one possible cause of the issue such that more than one how-to is needed)

A level-4 heading that describes the issue that this section will address. If there is only one how-to that will be included for this current issue, this heading may be omitted.

Optional paragraph text to provide any information that might be needed before beginning the how-to

A level-5 heading that says, "Test for Applicability of Fix"
  1. A test to determine if the issue addressed by the current section is what is causing the described problem (to prevent maintainers from addressing the wrong issue)
    • Formatted as an ordered list of steps
    • If the test is really simple, describing it in a small paragraph will suffice (instead of using the list format).
A level-5 heading that says, "Steps to Fix the Issue"
  1. A series of steps to fix the issue
    • Formatted as an ordered list of steps
    • If the fix is really simple, describing it in a small paragraph will suffice instead of using the list format.
A level-5 heading that says, "Test for Successful Fix"
  1. A test that will pass if and only if the issue is resolved.
    • Formatted as an ordered list of steps
    • If the test is really simple, describing it in a small paragraph will suffice (instead of using the list format).

Current Discussions Related to the System

Some systems have important long-term changes that are being discussed. If needed, a summary of each discussion may be included here.

See Also

Related Twiki Pages

Related EDocs

Formatted in a list.

For example:

  • EDoc 1
  • EDoc 2
  • ...

Related External Links

For example:
Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r17 - 2013-07-17 - DrewPilcher
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback