Example 1: sync only rmvb files between two dirs:
# rsync.exe -zarv --include="*/" --include="*.rmvb" --exclude="*" * /cygdrive/g/
From http://omappedia.org/wiki/Device_Tree
The "Open Firmware Device Tree", or simply Device Tree (DT), is a data structure and language for describing hardware. More specifically, it is a description of hardware that is readable by an operating system so that the operating system doesn't need to hard code details of the machine.
Structurally, the DT is a tree, or acyclic graph with named nodes, and nodes may have an arbitrary number of named properties encapsulating arbitrary data. A mechanism also exists to create arbitrary links from one node to another outside of the natural tree structure.
Conceptually, a common set of usage conventions, called 'bindings', is defined for how data should appear in the tree to describe typical hardware characteristics including data busses, interrupt lines, GPIO connections, and peripheral devices.
As much as possible, hardware is described using existing bindings to maximize use of existing support code, but since property and node names are simply text strings, it is easy to extend existing bindings or create new ones by defining new nodes and properties.
First and foremost, the kernel will use data in the DT to identify the specific machine. In a perfect world, the specific platform shouldn't matter to the kernel because all platform details would be described perfectly by the device tree in a consistent and reliable manner. Hardware is not perfect though, and so the kernel must identify the machine during early boot so that it has the opportunity to run machine-specific fixups. In the majority of cases, the machine identity is irrelevant, and the kernel will instead select setup code based on the machine's core CPU or SoC. On ARM for example, setup_arch() in arch/arm/kernel/setup.c will call setup_machine_fdt() in arch/arm/kernel/devicetree.c which searches through the machine_desc table and selects the machine_desc which best matches the device tree data. It determines the best match by looking at the 'compatible' property in the root device tree node, and comparing it with the dt_compat list in struct machine_desc.
The 'compatible' property contains a sorted list of strings starting with the exact name of the machine, followed by an optional list of boards it is compatible with sorted from most compatible to least. For example, the root compatible properties for the TI BeagleBoard and its successor, the BeagleBoard xM board might look like:
compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
Where "ti,omap3-beagleboard-xm" specifies the exact model, it also claims that it compatible with the OMAP 3450 SoC, and the omap3 family of SoCs in general. You'll notice that the list is sorted from most specific (exact board) to least specific (SoC family).
Astute readers might point out that the Beagle xM could also claim compatibility with the original Beagle board. However, one should be cautioned about doing so at the board level since there is typically a high level of change from one board to another, even within the same product line, and it is hard to nail down exactly what is meant when one board claims to be compatible with another. For the top level, it is better to err on the side of caution and not claim one board is compatible with another. The notable exception would be when one board is a carrier for another, such as a CPU module attached to a carrier board.
One more note on compatible values. Any string used in a compatible property must be documented as to what it indicates. Add documentation for compatible strings in Documentation/devicetree/bindings.
Again on ARM, for each machine_desc, the kernel looks to see if any of the dt_compat list entries appear in the compatible property. If one does, then that machine_desc is a candidate for driving the machine. After searching the entire table of machine_descs, setup_machine_fdt() returns the 'most compatible' machine_desc based on which entry in the compatible property each machine_desc matches against. If no matching machine_desc is found, then it returns NULL.
The reasoning behind this scheme is the observation that in the majority of cases, a single machine_desc can support a large number of boards if they all use the same SoC, or same family of SoCs. However, invariably there will be some exceptions where a specific board will require special setup code that is not useful in the generic case. Special cases could be handled by explicitly checking for the troublesome board(s) in generic setup code, but doing so very quickly becomes ugly and/or unmaintainable if it is more than just a couple of cases.
Instead, the compatible list allows a generic machine_desc to provide support for a wide common set of boards by specifying "less compatible" value in the dt_compat list. In the example above, generic board support can claim compatibility with "ti,omap3" or "ti,omap3450". If a bug was discovered on the original beagleboard that required special workaround code during early boot, then a new machine_desc could be added which implements the workarounds and only matches on "ti,omap3-beagleboard".
PowerPC uses a slightly different scheme where it calls the .probe() hook from each machine_desc, and the first one returning TRUE is used. However, this approach does not take into account the priority of the compatible list, and probably should be avoided for new architecture support.
From http://devicetree.org/Device_Tree_Usage
find -not -empty -type f -printf "%s\n" | sort -rn | uniq -d | xargs -I{} -n1 find -type f -size {}c -print0 | xargs -0 md5sum | sort | uniq -w32 --all-repeated=separate
Find Duplicate Files, excluding .svn-directories (based on size first, then MD5 hash)
find -type d -name ".svn" -prune -o -not -empty -type f -printf "%s\n" | sort -rn | uniq -d | xargs -I{} -n1 find -type d -name ".svn" -prune -o -type f -size {}c -print0 | xargs -0 md5sum | sort | uniq -w32 --all-repeated=separate
PWM=$( find /sys -name pwm1 )
for pwm in $PWM; do
echo "1" > ${pwm}_enable # manual
#echo "0" > ${pwm} # max speed
#echo "30" > ${pwm} # max speed
echo "180" > ${pwm} # max speed
#echo "220" > ${pwm} # max speed
#echo "255" > ${pwm} # max speed
done
/bin/su -l -c /usr/bin/startx swallow
/sbin/hdparm -S 60 /dev/sdb
/sbin/hdparm -S 60 /dev/sdc
# cat /root/check_diskstats.sh #!/bin/bash DISKS=$(/usr/sbin/smartctl --scan |/usr/bin/awk '{ print $1 }' |sed 's|/dev/||g') SLEEP_LIMIT=30 TMPSTAT=/tmp/diskstats for d in $DISKS; do
s=$( grep -i "$d " /proc/diskstats | sed "s/ \s*/ /g" ) if grep -i "$s" $TMPSTAT.$d; then echo "$( date +%FT%R )$s" >> $TMPSTAT.$d else echo "$( date +%FT%R )$s" > $TMPSTAT.$d fi if test "$( cat $TMPSTAT.$d | wc -l )" -gt "$SLEEP_LIMIT"; then if /sbin/hdparm -C /dev/$d | grep -i active; then /sbin/hdparm -y /dev/$d fi fi done # crontab -l # Edit this file to introduce tasks to be run by cron. # # Each task to run has to be defined through a single line # indicating with different fields when the task will be run # and what command to run for the task # # To define the time you can provide concrete values for # minute (m), hour (h), day of month (dom), month (mon), # and day of week (dow) or use '*' in these fields (for 'any').# # Notice that tasks will be started based on the cron's system # daemon's notion of time and timezones. # # Output of the crontab jobs (including errors) is sent through # email to the user the crontab file belongs to (unless redirected). # # For example, you can run a backup of all your user accounts # at 5 a.m every week with: # 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/ # # For more information see the manual pages of crontab(5) and cron(8) # # m h dom mon dow command * * * * * /bin/bash /root/check_diskstats.sh
I got following error on my AMD file server (SX-2310):
[528299.816034] [Hardware Error]: CPU:0 MC4_STATUS[-|CE|MiscV|-|AddrV|CECC]: 0x9c044cb0001c017b
[528299.816048] [Hardware Error]: MC4_ADDR: 0x000000021fcce508
[528299.816055] [Hardware Error]: Northbridge Error (node 0): L3 ECC data cache error.
[528299.816065] [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: EV
[530699.816052] [Hardware Error]: CPU:0 MC4_STATUS[-|CE|MiscV|-|AddrV|CECC]: 0x9c484cb1011c011b
[530699.816067] [Hardware Error]: MC4_ADDR: 0x00000001b4d0fa48
[530699.816075] [Hardware Error]: Northbridge Error (node 0): L3 ECC data cache error.
[530699.816084] [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD
2014-03-26
[1353899.816047] [Hardware Error]: CPU:0 MC4_STATUS[-|CE|MiscV|-|AddrV|CECC]: 0x9c03c8f0001c017b
[1353899.816063] [Hardware Error]: MC4_ADDR: 0x00000000c812610c
[1353899.816070] [Hardware Error]: Northbridge Error (node 0): L3 ECC data cache error.
[1353899.816080] [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: EV
[3256.362200] sd 5:0:0:0: [sdb] Asking for cache data failed
[3256.362200] sd 5:0:0:0: [sdb] Assuming drive cache : write through
What do the Asking for cache data failed and Assuming Drive Cache: write-through messages mean?
Hard disks have a small amount of RAM cache to speed up write operations. The system can write a chunk of data to the disk cache without actually waiting for it to be written to the disk. This is sometimes called "write-back" mode.
If there is no cache on the disk, data is directly written to it in "write-through" mode.
The Asking for cache data failed warning usually occurs with devices such as USB flash drives, USB card readers, etc. which present themselves as SCSI devices to the system (sdX), but have no cache.
The system asks the device: "Do you have a cache?" and gets no response. So it assumes there is no cache and puts it in "write-through" mode.
echo "# eliminate 'Asking for cache data failed' msg" >>/etc/modprobe.d/ums-realtek.conf
echo "options ums_realtek ss_en=0" >> /etc/modprobe.d/ums-realtek.conf
Reference: http://askubuntu.com/questions/167343/what-is-a-asking-for-cache-data-failed-warning