“Live core” is the crash dump of the live running Solaris system, without actually rebooting or altering the system in any way. This requires understanding of dumpadm and savecore commands. Man pages of these commands can be found online at Sun Documentation site. Find primary memory size:

-bash-3.00# prtconf | grep Memory
Memory size: 8192 Megabytes

Generate the core dump device (good to have its size same as primary memory size)

-bash-3.00# mkfile -n 8G /var/crash/myhost/livecore
-bash-3.00# ls -l /var/crash/myhost/
total 50
-rw-r--r--   1 root     root           3 Jan  2 04:33 bounds
-rw------T   1 root     root     8589934592 Jan  2 04:23 livecore

Using dumpadm (Dump administration command), set dump device as the above generated file

-bash-3.00# dumpadm -d /var/crash/myhost/livecore
Dump content: kernel pages
Dump device: /var/crash/myhost/livecore (dedicated)
Savecore directory: /var/crash/myhost
Savecore enabled: yes

Generate live core using savecore:

-bash-3.00# savecore -L
dumping to /var/crash/myhost/livecore, offset 65536, content: kernel
100% done: 564893 pages dumped, compression ratio 2.91, dump succeeded
System dump time: Fri Jan  2 04:26:41 2009
Constructing namelist /var/crash/myhost/unix.29
Constructing corefile /var/crash/myhost/vmcore.29
100% done: 564893 of 564893 pages saved

Core dump generated two files: vmcore.29 and unix.29.

-bash-3.00# ls -l /var/crash/myhost/
total 12284738
-rw-r--r--   1 root     root           3 Jan  2 04:33 bounds
-rw------T   1 root     root     8589934592 Jan  2 04:33 livecore
-rw-r--r--   1 root     root     1913028 Jan  2 04:30 unix.29
-rw-r--r--   1 root     root     4675993600 Jan  2 04:33 vmcore.29

-bash-3.00# file  /var/crash/myhost/vmcore.29
/var/crash/myhost/vmcore.29:     SunOS 5.10 Generic_127127-11 64-bit SPARC crash dump from ''

-bash-3.00# file  /var/crash/myhost/unix.29
/var/crash/myhost/unix.29:       ELF 64-bit MSB executable SPARCV9 Version 1, UltraSPARC1 Extensions Required, statically linked, not stripped, no debugging information available

Man pages online:

dumpadm (1M) :
http://docs.sun.com/app/docs/doc/819-2240/dumpadm-1m?a=view

savecore (1M) :
http://docs.sun.com/app/docs/doc/816-5166/savecore-1m?a=view

[Read more..]

Direct Memory Access (DMA) is a way by which hardwares directly access host memory for reading or writing independent of CPU. The alternative approach is called the Programmed I/O where all read/write transactions will be through CPU and hence the CPU will be unavailable to other tasks during I/O. Due to the unavailability of CPU during I/O, programmed I/O approach is not preferred where there is a need for higher data transfers between hardwares and memory.

For example, a network device uses DMA approach to read/write buffers in host memory. In this way, CPU can be utilized in an efficient manner to process received frames than processing I/O.

For a DMA transfer, CPU initiates it by issuing a command. The DMA transfer command is executed by a DMA controller on the board. In case of PCI and other technologies, bus mastering technique is mostly used for DMA transfer. In bus mastering technique, the device takes control of the bus and performs DMA transfers on its own

Types of DMA

Devices perform one of the three ways of DMA
1. Bus-Master DMA
2. First-Party DMA, and
3. Third-Party DMA

Bus-Master DMA
The device takes control of the bus and performs DMA transfers on its own. In this type, device driver has to program the device's DMA interface (registers) according to its specification.

First-Party DMA
Under first-party DMA, the device uses a channel from the system's DMA engine to drive that device's DMA bus cycles. The device driver has to configure the channel in a cascade mode to avoid DMA engine from interfering with transfers.

Third-Party DMA
Third-party DMA uses a system DMA engine resident on the main system board, which has several DMA channels that are available for use by devices. The device relies on the system's DMA engine to perform the data transfers between the device and memory. The driver uses DMA engine routines to initialize and program the DMA engine. For each DMA data transfer, the driver programs the DMA engine and then gives the device a command to initiate the transfer in cooperation with that engine.

References:
1. Writing Device Drivers
2. Direct Memory Access

[Read more..]

Since TCP is a reliable and ordered delivery protocol, it makes sure that both ends are in sync with each other while terminating a session. Both end systems send a message with FIN bit set. FIN bit indicates connection finish request. Other end sends an ACK to the FIN message.

The connection is considered terminated once both hosts sends termination request through FIN messages and received corresponding ACK mesages.

Above figure shows how a TCP connection is terminated between two hosts.

1. TCP connection termination Initiator sends a message with FIN bit set.

2. On receiving connection termination request through FIN, other end initiates connection termination by indicating the upper layer (applications using this connection) that the connection is going to be ended. It sends an ACK.

3. The other end sends a message with FIN bit set indicating that its part of connection termination is also done (meaning that the application using this connection has terminated). It waits until it received a message with ACK and then closes its part of connection.

4. Now the initiator sends ACK to the FIN and waits for double the maximum segment life time to make sure that the ACK has been received by the other end. Then, it closes its part of connection.

[Read more..]

TCP is a transport layer protocol which is responsible for reliable and ordered delivery of stream of bytes from source to destination. One end acts as a server and the other acts as a client. Before starting any data transfer it has to establish a session between client and server.

To establish such a session (connection), TCP uses 3-way handshake method. During this period, both clients and servers exchange connection parameters and also do negotiate on the values to be used between them.

For example, some parameters like interface MTU, TCP window size etc. in one system can be more than that supported by other. In that case, they exchange their current settings and set to a mutually usable value for that connection.

Below figure shows how a TCP session is established between a client and a server. This involves three steps or handshakes. Each steps involves sending a frame from originator to destination.



1. Client sends its sequence number SEQ[A] to server. This sequence number is used by the server for synchronization which is very important for TCP's reliable and ordered delivery. Optionally, client and servers can synchronize their MSS (Maximum Segment Size). MSS is defined by the length field. If MSS is specified by client, through this it informs server that it can receive segments whose size can not exceed MSS. It sets acknowledgement field to 0 since this is the first frame to server in this session.

2. Server sends acknowledgement to the received frame (ACK) along with its sequence number SEQ[B]. Again, similar to server client uses this for synchronization between them. While sending ACK to client, it increments the sequence number (SEQ[A] + 1) which indiates to client that the server has received the frame with sequence SEQ[A] and expecting to receive new sequence frame (SEQ[A] + 1).

3. Now client acknowledges the frame from server by sending frame with (SEQ[B] + 1).

[Read more..]