Pitted Knowledge of the Almighty Olive: hardware

Showing posts with label hardware. Show all posts

Nov 3, 2013

Debian and XFCE Dual Monitors

Open up a terminal and type in xrandr. This will output the configuration of the currently connected monitors. Identify the names of your monitors (such as HDMI2, LCD1, VGA1, CRT2 or whatever). In this example we have two monitors, HDMI1 and HDMI2.

Now type in the desired layout:

xrandr --output HDMI2 --left-of HDMI1

The monitors should now be showing your desired screen laytout. If not, play around until you have it.

To make this layout permanent, click on the Start menu > Settings > Session and Startup and then click on the Application Autostart tab. Add a new autostart item and then insert the xrandr command into the Command text field. Now if you restart your settings will be automatically loaded!

References

http://www.linuxquestions.org/questions/showthread.php?p=4658799

Nov 1, 2013

Debian: Sound issue

I had a bit of an issue with ALSA and Debian in regards to my sound device not being detected properly. This meant I had to dig around a bit to get it up and running.

Note that with this method may not work nicely with multiple sound cards. Your mileage may vary....

Problem:

Running the command alsamixer in a terminal returned this error message:

cannot load mixer controls: Invalid argument

Trying to restart the ALSA server got me this:

root@localhost:~# /etc/init.d/alsa-utils stop
[....] Shutting down ALSA...warning: 'alsactl store' failed with error message 'alsactl: get_control:250: Cannot read control info '2,0,0,Front Playback Volume,0': In[FAIL argument'...failed.

So there was something wrong with the system configuration or the control.

For reference, this is what my system has configured:

root@localhost:~# head -n 1 /proc/asound/card0/codec*
==> /proc/asound/card0/codec#2 <==
Codec: Realtek ALC887-VD

==> /proc/asound/card0/codec#3 <==
Codec: Intel PantherPoint HDMI

root@caesar:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC887-VD Analog [ALC887-VD Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 1: ALC887-VD Digital [ALC887-VD Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0

Explanation of these commands (skip if you want to get to the solution)

The first command reads out the first line (head -n1) of each of the files that match the search pattern (/proc/asound/card0/codec*). This matches two files (codec#2 and codec#3). The /proc/ filesystem is where Linux stores all the files necessary for running the operating system, including detected hardware devices. The first file tells us that the system recognizes the motherboard sound card, and the second files recognizes the HDMI output.

The second command confirms our suspicions, and also let's us know that ALSA detects these devices too (the Realtek and the HDMI devices are found and configured).

Now we know that the problem lies in the ALSA configuration, because everything is detected at this stage.

Solution:

Run the following command and look for your audio device:

lspci -v
The above step is important because you need to find the line 'Kernel driver in use' associated with your Audio controller (which is outputted by the above line). In my case the kernel was using snd_hda_intel.
Now we need to check to ensure the driver is installed. A simple way is to start off writing (DO NOT PRESS ENTER YET!) modprobe snd and then tab complete it (press the <TAB> key twice). This should bring up a list of sound drivers your system knows about. If your driver is not listed you should try to find and install it.
Edit /etc/modprobe.d/alsa_base.conf and add the following line (you may need to adjust this to suit your system):
options snd-hda-intel model=generic
Now we need to force ALSA to load the new configuration:
alsa force-reload
If you can hear sound after running the following command, congratulations!
aplay /usr/share/sounds/alsa/Front_Center.wav

References:

Aug 25, 2013

Linux Mint Multiseat with keyboards & mice(Xephyr)

I must state this important fact first:

Xephyr on Ubuntu/Linux Mint does not come compiled with evdev support.

This is important because Linux uses evdev to configure most input devices like keyboards and mice. You will see lots of documentation on configuring inputs with evdev, but none of those methods will work unless you compile Xephyr from scratch and enable evdev yourself.

I downloaded and installed the following executable to make my life easier. I repeat, this method will not work unless you have a modified version of Xephyr with evdev support!

Correct drivers - make sure they are installed!

I used an older Nvidia card so the following commands got me up and running:

sudo apt-get -y xserver-xorg-video-nouveau
#
# Upgrade our system
sudo apt-get -y install ubuntu-drivers-common
sudo apt-get -y install nvidia-current nvidia-settings

If you are unsure what graphics card you have then run the following (the second line is my output; yours will probably be different):

$ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)

Input devices

Determine which devices are which by running the following command (unplug devices to help to narrow down your options). The paths you see are going to help in writing up our configuration file.

$ ls -l /dev/input/by-path/
total 0
lrwxrwxrwx 1 root root 9 May 27 18:39 pci-0000:00:1d.0-usb-0:1:1.0-event-kbd -> ../event3
lrwxrwxrwx 1 root root 9 May 27 18:39 pci-0000:00:1d.0-usb-0:2:1.0-event-mouse -> ../event4
lrwxrwxrwx 1 root root 9 May 27 18:39 pci-0000:00:1d.0-usb-0:2:1.0-mouse -> ../mouse0
lrwxrwxrwx 1 root root 9 May 27 18:39 platform-i8042-serio-0-event-kbd -> ../event2
lrwxrwxrwx 1 root root 9 May 27 18:39 platform-i8042-serio-1-event-mouse -> ../event5
lrwxrwxrwx 1 root root 9 May 27 18:39 platform-i8042-serio-1-mouse -> ../mouse1

Custom Xephyr script

The custom script (save it to /usr/sbin/Xephyr.sh) will act like the glue in our multi-seat environment. It will attach input devices to our monitors and some other stuff.

#!/bin/bash
# 20060905 - josean - added get_event() function to obtain eventNN from a physical address
# Original version:
# http://en.wikibooks.org/wiki/Multiterminal_with_Xephyr
# http://www.c3sl.ufpr.br/multiterminal/howtos/Xephyr.sh
trap "" usr1
XEPHYR=/usr/local/sbin/Xephyr
get_event()
{
evento=`grep -A5 $1 /proc/bus/input/devices | grep 'H: Handlers=' | grep --only-matching -e 'event[0-9]*'`
}
args=()
while [ ! -z "$1" ]; do
if [[ "$1" == "-xauthority" ]]; then
shift
if [ ! -z "$1" ]; then
export XAUTHORITY="$1"
fi
elif [[ "$1" == "-display" ]]; then
shift
if [ ! -z "$1" ]; then
export DISPLAY="$1"
fi
elif [[ "$1" == "-kbdphys" ]]; then
shift
if [ ! -z "$1" ]; then
get_event $1
args=("${args[@]}" "-keybd")
args=("${args[@]}" "evdev,,device=/dev/input/$evento,xkbrules=evdev,xkbmodel=evdev,xkblayout=us")
fi
elif [[ "$1" == "-mousephys" ]]; then
shift
if [ ! -z "$1" ]; then
get_event $1
args=("${args[@]}" "-mouse")
args=("${args[@]}" "evdev,5,device=/dev/input/$evento")
fi
else
if ! expr match $1 'vt[0-9][0-9]*' >/dev/null; then
args=("${args[@]}" "$1")
fi
fi
shift
done
echo $XEPHYR "${args[@]}"
exec $XEPHYR "${args[@]}"

Xorg.conf settings

Edit /etc/X11/xorg.conf with something similar to the following. Please change the values to your whatever matches your system!!

############## SETTINGS#############
Section "ServerFlags" Option "DontZap" "true" Option "DontVTSwitch" "true" Option "DontZoom" "true" Option "AllowMouseOpenFail" "true" Option "AllowEmptyInput" "true" Option "AutoAddDevices" "false" Option "AutoEnableDevices" "false" Option "Xinerama" "false" Option "NoPM" "true" Option "DPM" "false" Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0"EndSection
############## INPUTS#############
Section "InputDevice" Identifier "Keyboard1" Driver    "evdev" Option    "Device" "/dev/input/event2" Option    "Floating" "true" Option    "XkbRules" "evdev" Option    "XkbModel" "evdev" Option    "XkbLayout" "us"EndSection
Section "InputDevice" Identifier "Mouse1" Driver    "evdev" Option    "Device" "/dev/input/event5" Option    "Floating" "true" Option    "GrabDevice" "on" Option    "Protocol" "auto" Option    "Emulate3Buttons" "no" Option    "ZAxisMapping" "4 5"EndSection
Section "InputDevice" Identifier "Keyboard0" Driver    "evdev" Option    "Device" "/dev/input/event3" Option    "Floating" "true" Option    "XkbRules" "evdev" Option    "XkbModel" "evdev" Option    "XkbLayout" "us"EndSection
Section "InputDevice" Identifier "Mouse0" Driver    "evdev" Option    "Device" "/dev/input/event4" Option    "Floating" "true" Option    "GrabDevice" "on" Option    "Protocol" "auto" Option    "Emulate3Buttons" "no" Option    "ZAxisMapping" "4 5"EndSection
########### SEAT 1##########
Section "Device" Identifier "Device1" Driver    "nvidia" Vendorname "NVIDIA Corporation" BoardName "GeForce 210" Option    "DPMS" "false" Option    "UseDisplayDevice" "CRT" Option    "ProbeAllGpus" "false" Option    "NoLogo" "true" Option    "RenderAccel" "true" Screen    1EndSection
Section "Monitor" Identifier "Monitor1" VendorName "Toshiba" ModelName "Toshiba Matsushita Display Technology Co., Ltd LCD-MONITOR" Option    "DPMS" "false"EndSection
Section "Screen" Identifier "Screen1" Device    "Device1" Monitor    "Monitor1" DefaultDepth 24 Subsection "Display"    Depth 24    Modes "nvidia-auto-select" EndSubsection Option    "DPMS" "false" Option    "UseDisplayDevice" "CRT" Option    "ProbeAllGpus" "false"EndSection
############# SEAT 0############
Section "Device" Identifier "Device0" Driver    "nvidia" VendorName "NVIDIA Corporation" BoardName "GeForce 210" Option    "DPMS" "false" Option    "UseDisplayDevice" "DFP" Option    "ProbeAllGpus" "false" Option    "NoLogo" "true" Option    "RenderAccel" "true" Screen    0EndSection
Section "Monitor" Identifier "Monitor0" VendorName "Toshiba" ModelName "Toshiba Matsushita Display Technology Co., Ltd LCD-MONITOR" Option    "DPMS" "false"EndSection
Section "Screen" Identifier "Screen0" Device    "Device0" Monitor    "Monitor0" DefaultDepth 24 SubSection "Display"    Depth 24    Modes "nvidia-auto-select" EndSubsection Option    "DPMS" "false" Option    "UseDisplayDevice" "DFP" Option    "ProbeAllGpus" "false"EndSection
############## SERVERS#############
Section "ServerLayout" Identifier "multix" Screen 0 "Screen0" 0 0 Screen 1 "Screen1" 0 0EndSection

MDM configuration

The MDM is what executes everything (if it has been configured properly). Edit /etc/mdm/mdm.conf and change the Server Section to the following:

## Also note, that if you redefine a [server-foo] section, then MDM will# use the definition in this file, not the MDM System Defaults configuration# file. It is currently not possible to disable a [server-foo] section# defined in the MDM System Defaults configuration file.#
[server-Xephyr0]name=Xephyr0command=/usr/bin/X -ac -br -layout multix -audit 4 -dpmshandled=falseflexible=false
[server-Xephyr1]name=Xephyr1command=/usr/sbin/Xephyr.sh -display :0.0 -xauthority /var/lib/mdm/:0.Xauth -fullscreen -kbdphys usb-0000:00:1d.0-1/input0 -mousephys usb-0000:00:1d.0-2/input0 -verbosity 100 -audit 4 -screen 0 -dpms -retrohandled=trueflexible=false
[server-Xephyr2]name=Xephyr2command=/usr/sbin/Xephyr.sh -display :0.1 -xauthority /var/lib/mdm/:0.Xauth -fullscreen -kbdphys isa0060/serio0/input0 -mousephys isa0060/serio1/input0 -verbosity 100 -audit 4 -screen 1 -dpms -retrohandled=trueflexible=false

Resources

Nov 14, 2012

Installing CentOS 6.3 from a USB mass storage device

I've done A LOT of research on this issue and I have finally been able to create a bootable USB to use for installing CentOS.

Download the Centos DVD for your system.

(Optional: You can run the md5sum command on your download and compare the hash against that stored on the server)
Clear the USB (NOTE: This is assuming your device is sdb!!! Double check, otherwise you may wipe your hard-drive!!!):

sudo dd if=/dev/zero of=/dev/sdb bs=512 count=1
Make it bootable (you can type in 'm' to show a help menu):

sudo fdisk /dev/sdb
>n
>p
>1
>(default)
>(default)
>a
>1
>t
>c
>w
Format the partition:

sudo mkfs.vfat /dev/sdb1
Download the livecd bash script and make it executable:

wget http://git.fedorahosted.org/cgit/livecd/plain/tools/livecd-iso-to-disk.sh
chmod +x livecd-iso-to-disk.sh
Install the software required by the script:

sudo apt-get install isomd5sum syslinux extlinux
Run the script:

sudo ./livecd-iso-to-disk.sh [your-dvd-iso] /dev/sdb1
Insert your USB device and run!

Jul 7, 2012

Make your own TRS (headphone) to RCA audio cable

I like to re-use old equipment whenever possible. Mostly because it gives me the opportunity to hack away at it until it suits my needs. This is one such case....

Most portable media players come with a 3.5mm TRS audio jack socket that is intended to play stereo sound on a sound system or headphones. Which is great, except I had an old surround sound system that only used RCA connections...

The TSR socket is the image on the left. The RSA sockets are on the right.

Let's get into the technical differences between each of these connection types:

The TSR cable can carry both channels of a stereo signal (the left and right channels). It can also be 'balanced', which is just a fancy way of saying that it is protected from external noise. All of these properties are possible because of the unique configuration of the plug, which is segmented into a Tip, Ring and a Sleeve (if you have been paying attention, that's where the TRS acronym originated).

Cut away view of a TSR jack plug showing the Tip, Ring and Sleeve.

For portable media players the TSR connection is unbalanced, with the Left channel transmitted through the Tip and the Right channel transmitted through the Ring. The Sleeve is used as a common ground for both channels.
RCA connections can only carry one signal and are always unbalanced.

Now we know the rough anatomy of the connectors we can now hack our own cable! For this guide, we will need one (1) TSR plug and two (2) RCA plugs. This is because the TSR will carry two channels, which we will distribute over the two RCA connectors (each RCA plug can only carry one channel).

Chop off one end of the TSR cable. You can discard the other end (or keep it for later...). Strip and and solder the end.

I just opened up my extra plug so I could see inside it (as well as know which channel is which)
Chop off two RCA plugs, leaving just enough wire so that we can strip it for our connection. Strip and and solder the end.
You should now have the following:

From Left-to-Right: The stripped end of the TSR plug (you should see three wires); The TSR plug; The stripped end of the RCA plug; The RCA plug
Connect the signal wire of each RCA plug to a TSR signal channel. For instance, one RCA signal wire will be connected to the TSR Tip wire for the left channel. The other RCA signal wire will be connected to the TSR Ring wire for the right channel.

Both RCA ground wires are to be connected to the TSR sleeve wire. YOU SHOULD TEST BEFORE SOLDERING!

Testing the set-up...
Once you have tested it all out, solder the connections and viola! You now have a TSR-to-RCA cable!

Hope this helps someone out there!!!

References:

Jun 13, 2012

Real Time Operating Systems: Subject Notes

RTOS (Real Time Operating Systems) is a subject that was offered by the University of Technology, Sydney (UTS). These are some of my notes from that subject.

Pre-emption (or context switch)

Pre-emption is the ability of the Operating System to stop a currently scheduled task in favour of a higher priority task. Enables pre-emptive multi-tasking.
An interrupt generally denotes something that needs to be handled straight away. Normal scheduling is avoided until the interrupt is handled; in other words, interrupts generally cannot be pre-empted.
By making the scheduler pre-emptive, we make it more responsive to events. The downside is that it is more susceptible to race conditions, where the executing program modifies/uses data the pre-empted process has not finished using.
Pre-emptive multi-tasking can be compared to co-operative multi-tasking, where the process must give their time to other processes. This requires the process to be co-operative and not hog all the resources.
A scheduler that can pre-empt a process during a system call is a pre-emptive kernel.

A simple flow of how pre-emption works. The Red box is a low priority thread that is pre-empted, the Yellow and Blue are interrupts and the Green is a higher priority thread.

Process

A process is an instance of a program in execution. The execution happens in a sequential fashion.
A process has at a minimum a copy of the program code, a Process Control Block (discussed later), a Stack (to keep track of active subroutines and events) and a Data Section or Heap. The data section includes the program code, process-specific data (such as inputs and outputs) and storage of intermediate data.
A process will start in the New state, then go to Ready (waiting to be assigned). It can then be put into either the Running (executing) or Waiting (waiting on I/O operations) states until it reaches the Terminated state.

A visualisation of the process state
The Process Control Block (PCB) contains the information associated with a particular process and its context. This includes the Process state (see above diagram), a Program Counter (hold the memory address of the next program instruction to execute), CPU Registers (for storage of process specific data), CPU Scheduling Information (so the CPU can make scheduling decisions), Memory-management information, Accounting information (how long the last run was, how much time accumulated, etc), and I/O status information.
When we wish to switch the executing process, the CPU will store the current state of the running process into a PCB and load up the state of the next process from their PCB. When the process has completed executing, the CPU will then store that process' PCB and reload the previous PCB. This is called Context Switching.
Context switching is considered overhead. It is time in which the CPU does nothing.
The queues used to store the details of processes are the Job Queue (all processes in the system), the Ready Queue (processes in main memory waiting to execute), and the Device Queue (processes waiting for an I/O device to respond).
A Scheduler can be either Long-term (selects processes to be brought into the ready queue, and does not need to be fast because it matches the speed of I/O devices) or Short-term (selects process from ready-queue to be executed, and needs to match the CPU speed)
Since Long-term schedulers take the most time, it determines the degree of multi-programming a computer can handle.
A process can either be considered an I/O bound process (does more I/O tasks) or a CPU bound process (does more computations)
Processes are generally created from a parent process, which in turn creates it's own child processes. This creates a tree-hierarchy of processes.
Aspects of the relationship between a child process to its parent are:

Resource sharing: The parent and child can share all resources, a sub-set of resources, or no resources at all
Execution: The parent and child run concurrently, or the parent waits until the child terminates
Address space: The child is an exact duplicate of the parent, or the child has another program image loaded into it
Termination: The process can make a call to exit() which makes the system deallocate process resources, or the parent can abort the child. Some operating systems do no allow the child to continue if the parent is terminated

Processes can communicate by either Message passing (which passes through the kernel) or through Shared Memory (much quicker but can lead to race conditions). Message passing requires that a communication link is established that is either physical or logical.
Message passing can be Blocking/Synchronous (The sender must wait until the message is received or the receiver must wait until a message is sent) or Non-blocking/Asynchronous (both entities do not have to wait)
The Client-Server communication model uses Sockets (end-point for communication), Remote Procedure Call or RPC (abstract procedure calls across networked systems. Uses a Stub to locate and marshal/pack the parameters into a message) and Remote Method Invocation or RMI (similar to RPC but for Object-Orientated applications).
A Light Weight Process (LWP) is different to normal processes in that it shares some or all of its logical address space and system resources with other processes. It differs from threads (discussed later) in that it has its own Process Identifier and is fully controlled by the kernel (threads are controlled by the application). This set-up means that a LWP has less processing overhead.

Threads

Threads are by-products of processes in that they share everything the parent process has. It has its own stack and registers to store information, but it shares code and files with other threads and the parent process. This lessens the strain on resources.
Threads can be implemented through the User-level (via libraries) or the Kernel-level (direct kernel support)
There are three mapping schemes used to map user (process) threads to kernel threads.

One-to-One scheme has one user thread to every kernel thread
Many-to-One scheme has many user threads to every kernel thread
Many-to-many scheme has many user threads running off many kernel threads

Java threads are handled by the Java Virtual Machine (JVM). To use Java threads you must use the Runnable class or interface.
Terminating a thread involves two methods: Asynchronous (terminate immediately) or Deferred (allows the thread to periodically check if it should be terminated)

CPU Scheduling

The Scheduler will select a process from the ready queue and allocate the CPU to that process.
The Dispatcher gives control of the CPU to the process selected by the short-term scheduler. It handles context switching and jumping to the correct location in the program code.
Dispatcher Latency is the term used to describe the time it takes for the dispatcher to stop one program and start another
The criteria that the scheduler uses to determine which process to select include:

CPU Utilization: process keeps the CPU busy
Throughput: number of processes that complete execution per time unit
Turnaround time: total time to execute a particular process
Waiting time: amount of time a process has been waiting in the queue
Response time: time when the request was made till the first response

Scheduling schemes include:

First Come First Served (FCFS): Tasks are executed in the order that they arrive. This means that a high-priority process will have to wait until other tasks are executed first. In addition, a long process will significantly slow down all other processes.
Shortest Job First (SJF): Each process will be associated with the estimated time of its next CPU burst. The shortest job at the time will be executed over other processes. This significantly reduces the waiting time.
Round Robin (RR): The CPU has a time quantum of q time units. Each process will be executed for that amount of time before being pre-empted. If there are n processes, each process will get 1/n of the CPU time in time chunks of q. No process waits more than (n1-)q time units. Note that q has to be large enough otherwise there is too much overhead.

Priority Scheduling means associating a number with a process to aid in scheduling decisions. A problem with such solutions is starvation (where a low priority process never gets the chance to run). The solution is aging (increase the priority of a process over time).
Multi-level queues means splittling the Ready Queue into two:

Foreground are the interactive user applications. They generally require some form of user input. They typically use Round Robin scheduling.
Background are the batch jobs and system services. They do not require any sort of user input. They typically use FIFO or FCFS scheduling.

CPU scheduling becomes more complex when multiple CPUs are added. It needs to share the load.
Hard Real Time Scheduling means that critical processes are assured that they get completed within a set period of time. Soft Real Time Scheduling require that just critical processes receive priority over other processes
Thread scheduling can occur locally through libraries or globally through the kernel.

Process Synchronization

Concurrent access to data is not desirable as this will result in race conditions and data inconsistency. Therefore we must implement mechanisms to ensure data remains consistent.
Terms used in process synchronization are:

Mutual Exclusion: When one process is operating in its critical section no other process can enter their critical section
Race condition: Where there is concurrent access to data and the result is dependent on the order of execution
Critical section: Section of code where the process accesses shared data
Entry section: Section of code where the process asks if it can move into the critical section
Exit section: Section of code where the process releases the shared data
Bounded waiting: A bound must exist on the number of times other processes are allowed to enter their critical sections after a process has made a request to enter its critical section.
Locks: Flags used to determine whether the data is in use. The entry section will acquire the lock, while the exit section will release it
Semaphore: A synchronization tool that can simply be an integer value with two methods: acquire and release. It can be a Counting semaphore (no bounds) or a Binary Semaphore (also known as a mutex lock)
Monitors are a high-level abstraction that provide a convenient mechanism for process synchronization. Only one process may be active in a monitor at a time.

For semaphores to work, we must guarantee that no two processes can execute the acquire or release functions on the same semaphore at the same time. A semaphore wait list does this by creating a linked list that stores the current value and a pointer to the next value.

Main Memory

A program must be bought into memory and placed within a process to be run. Main Memory (generally RAM), Registers and Cache are the only storage elements that a CPU can directly access.
Memory address types are:

Logical Address: generated by the CPU and is an abstraction for user-level programs so that we do not have to specify the physical address at compile time
Physical Address: what is seen by the memory management unit. This is the address the RAM unit uses to refer to a physical element.

The Memory Management Unit (MMU) maps Logical to Physical addresses. It will add a relocation register to the logical address sent by a user program to determine a real physical address.
Dynamic Loading involves loading a routine only if it is needed. This saves system resources and can be implemented by the program, so no special support from the OS is required.
Dynamic Linking (or shared libraries) is a method where linking does not occur until execution. A small piece of code (known as a stub) is inserted into the program which attempts to locate the required routine in memory. The code will then replace itself with the address of the loaded routine
Swapping involves moving a process out of main memory and into secondary storage. It can later be moved back for continued execution. However, the system must maintain a ready queue of processes ready to run but are currently swapped out.
Physical memory is divided into fixed-size blocks called frames, while Logical memory is divided into blocks called pages. The OS will keep track of all free frames so that when a process requires n pages it will find n free frames and load the program. Note that while logical memory may seem contiguous to the process, it may actually be non-contiguous in physical memory. To facilitate this we need a page table to transfer Logical addresses to physical addresses.
Segmentation: a memory management scheme that acknowledges a process is a collection of segments. Segments are distinct from other segments, but are bounded within the process. In physical memory they can occupy the same frame.

Real Time Systems

A Real Time system requires that processes be finished before a certain deadline. Real-time does not mean Real-fast; it means that the system can respond to external environmental events almost instantly, seemingly running in "real-time".
An Embedded system is part of a larger system
A Safety critical system has catastrophic results in the case of failure
Hard real-time systems guarantee that processes will be completed before the deadline. Soft real-time systems only prioritize real-time tasks over other processes
A real-time system are generally developed for a single purpose and have specific timing requirements. To achieve this, real-time systems are developed using the System-on-Chip (SoC) strategy. This involves putting all the required hardware onto a s single integrated circuit. This is in contrast to a Bus orientated system which separate these components.

Mar 1, 2012

Troubleshooting USB mobile internet in Ubuntu

Most mobile broadband USB sticks come with two partitions; one with the installer and the other with the actual connection device. When you plug in the USB, the operating system will first mount the installer partition (which usually contains the installers for Windows and Mac). The installer will insert code that will automatically switch the USB to skip the installer and mount the connection device directly. Unfortunately most manufacturers don't support Linux, so new USB devices won't work straight away.

This guide will provide some tips to get your troublesome USB broadband stick working. This guide will focus on Ubuntu (11.04 in particular), however most of this guide should be applicable to other distro's as well (as long as it has usb_modeswitch installed). The particular device I will be configuring is the Huawei Technologies K3771 USB device given by Vodafone Australia.

First we will go through some troubleshooting tips for those new to the game, and by step 3 we will begin applying our fix.

Plug-in your device, open up a terminal (or command prompt) and type in the following command:

nm-tool

This will open up a list of internet devices; eth stands for ethernet and is usually your wired/wireless connections. We are looking for entries with wwan, GSM, 3G or Mobile Broadband in this list. If your device is detected here but does not work then it is a software issue that is outside the scope of this guide.
Now we need to see if your device is even detected by the system. Unplug your device, wait a second and in the terminal type in:

lsusb > ~/usb1.txt

When the command finishes plug the device back in, wait ALOT of seconds (wait until LEDs start flashing) and type in:

lsusb > ~/usb2.txt

Now to see if anything changed. Type in the command:

diff ~/usb1.txt ~/usb2.txt

You should now see something like:

6a7> Bus 002 Device 008: ID 12d1:14c4 Huawei Technologies Co., Ltd

If nothing pops up on the terminal, then either you jumped the gun too early with the second lsusb OR your device simply isn't playing nice. This is outside the scope of this guide and I suggest you hit up the guys at libusb or kernel developers to track this problem down. But before you do just cross your fingers and try:

sudo /usr/sbin/update-usbids

This will update the id list of USB devices your system will support; hopefully it will be in there!!
So now the hard part starts. The line we got from lsusb gives us some useful information about the device. The ID of a device can be split into two parts; the first part (12d1) is the vendor code, and the second part (14c4) is the product code. Unfortunately, in this case the product code points to the installer partition of the device. We need to manually tell the system to switch over to the mobile broadband part (this is what the installer does automatically for Windows and Mac). To do this we run the following command:

sudo gedit /lib/udev/rules.d/40-usb_modeswitch.rules

This will bring up a text editor with a list of all the USB devices that the system will automatically switch. We now need to add our device to this list. Either add to the end of the file or do a search to find similar devices and add:

# This is just a comment. Replace this text with information of your device
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="14c4", RUN+="usb_modeswitch '%b/%k'"

Replace the vendor and product id's with whatever lsusb produced. It should look like:

# Vodafone (Huawei) K3771
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="14c4", RUN+="usb_modeswitch '%b/%k'"

Ok, so now we are telling the system to switch our device.... switch to what? Remember, no matter how fancy they get computers are always very, very stupid machines. The mobile broadband device has it's own product id that we must link to the installer id. This is where it gets tricky; you need to figure out what this id is and at this stage I have no other advice other than to Google and pray. Luckily for me I know that my device id is 12d1:14ca. Now we need to create a custom usb_modeswitch rule.....
Navigate to the directory /usr/share/usb_modeswitch/ by running the following command in a terminal:

cd /usr/share/usb_modeswitch/

If you perform an ls you will see that this directory contains a file called configPack.tar.gz. This file contains all the switching rules; we need to edit it to add our device. First back up the file through:

sudo cp configPack.tar.gz configPack-ORIGINAL.tar.gz

Now we will extract the scripts through running:

sudo mkdir configPack/; sudo tar xzf configPack.tar.gz -C configPack/

Run the command to open a text file for our new rule (replace the 12d1:14c4 part with the id of your device):

sudo gedit configPack/12d1\:14c4

This will open a completely blank document. Add the following text (remember to customise for your particular device!):

##########################################
# Vodafone (Huawei) K3771 (again, this is just a comment)
#
# Our settings discovered by lsusb (the '0x' part just
# tells the system how to interpret the number
DefaultVendor= 0x12d1
DefaultProduct=0x14c4
#
# Our target product that we will switch to
TargetVendor= 0x12d1
TargetProduct= 0x14ca
#
# Some misc values that I don't really understand and am
# not game enough to change...
CheckSuccess=20
MessageContent="55534243123456780000000000000011062000000100000000000000000000"

Now we need to repack the rules and clean up our mess:

cd configPack/; sudo tar -czf ../configPack.tar.gz *; cd ../; sudo rm -rf configPack/

You can check the contents of the file by running the following command:

sudo file-roller configPack.tar.gz
Now restart your machine and, fingers crossed, the system will now correctly detect your device!

References

Some useful links for those who want to trace something more specific:

Nov 3, 2013

References

Nov 1, 2013

References:

Aug 25, 2013

Correct drivers - make sure they are installed!

Input devices

Custom Xephyr script

Xorg.conf settings

MDM configuration

Resources

Nov 14, 2012

Further reading

Jul 7, 2012

References:

Jun 13, 2012

Pre-emption (or context switch)

Real Time Systems

Mar 1, 2012