碰到開機問題, 請首先仔細看一遍 "NOT BOOTING?! Read THIS BOOT PROBLEM STICKY (also for PI2B)".
而我的問題比較偏向 SD Crad controller 搭配問題, 類似:
1) Pi 2 is much more picky than B+ when it comes to memory cards and throws mmcblk0 errors randomly when rebooting #372
2) SDCard corruption on RPI2 #397.
If you find your wifi 'drops out' from time to time, you can fix it by following procedures:
Create and edit a new file in /etc/modprobe.d/8192cu.conf
sudo vi /etc/modprobe.d/8192cu.conf
# Disable power saving (recommended)
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0
Then reboot with sudo reboot. 結果反應在 /sys/module/8192cu/parameters/…
For details, please check "A Brief Introduction to RTL8192C driver Power Saving"
# In associated idle
rtw_power_mgnt=0|1|2
0 == disable power saving
1 == power saving on, minPS
2 == power saving on, maxPS
rtw_enusbss=0|1
0 == disable auto suspend
1 == enable auto suspend
rtw_hwpwrp_detect=0|1
0 == disable HW power pin detection
1 == enable HW power pin detection
# Under unassociated idle state
rtw_ips_mode=0|1
0 == low power, IPS_NORMAL
1 == higher power, IPS_LEVEL2
The conventional wisdom, because we're running our RPis as server systems not clients, is to set rtw_power_mgnt=0 and rtw_enusbss=0 to prevent the dongle going into power saving and to ignore the other two parms because they don't make any difference. If the server goes into power saving we'd need a process to wake it up. That's different from a client system where interaction from a keyboard user will trigger a request to wake up and associate the dongle.
.7z
套件名稱：p7zip-full。
壓縮：$ 7z a FileName.7z FileName
使用密碼 (PASSWORD) 壓縮：$ 7z a FileName.7z FileName -pPASSWORD
解壓縮：$ 7z x FileName.7z
.bz
壓縮：unkown。
解壓縮1：$ bzip2 -d FileName.bz
解壓縮2：$ bunzip2 FileName.bz
.bz2
套件名稱：bzip2。
壓縮：$ bzip2 -z FileName
解壓縮1：$ bzip2 -d FileName.bz2
解壓縮2：$ bunzip2 FileName.bz2
.gz
套件名稱：gzip。
壓縮 : $ gzip FileName
解壓縮1：$ gunzip FileName.gz
解壓縮2：$ gzip -d FileName.gz
.lha
套件名稱：lha。
壓縮：$ lha -a FileName.lha FileName
解壓縮：$ lha -e FileName.lha
.rar
套件名稱：rar, unrar。
壓縮：$ rar a FileName.rar DirName
解壓縮1：$ rar e FileName.rar
解壓縮2：$ unrar e FileName.rar
.tar (僅打包，無壓縮)
套件名稱：tar。
打包：$ tar cvf FileName.tar DirName
解包：$ tar xvf FileName.tar
.tar.bz
壓縮：unkown。
解壓縮：$ tar jxvf FileName.tar.bz
.tar.bz2
套件名稱：bzip2。
壓縮：$ tar jcvf FileName.tar.bz2 DirName
解壓縮：$ tar jxvf FileName.tar.bz2
.tar.gz
套件名稱：gzip。
壓縮：$ tar zcvf FileName.tar.gz DirName
解壓縮：$ tar zxvf FileName.tar.gz
.tar.tgz
套件名稱：gzip。
壓縮：$ tar zcvf FileName.tar.tgz FileName
解壓縮：$ tar zxvf FileName.tar.tgz
.tar.xz
套件名稱：xz-utils。
壓縮：$ tar Jcvf FileName.tar.xz DirName
解壓縮：$ tar Jxvf FileName.tar.xz
.tar.Z
壓縮：$ tar Zcvf FileName.tar.Z DirName
解壓縮：$ tar Zxvf FileName.tar.Z
.tgz
套件名稱：gzip。
壓縮：$ tar zcvf FileName.tgz FileName
解壓縮：$ tar zxvf FileName.tgz
.xz
套件名稱：xz-utils。
壓縮：$ xz -z FileName
解壓縮：$ xz -d FileName.xz
.Z
壓縮：compress FileName
解壓縮：$ uncompress FileName.Z
.zip
套件名稱：zip。
壓縮：$ zip FileName.zip DirName
解壓縮：$ unzip FileName.zip
首先釐清幾個關鍵OpenCL是什麼？NV的CUDA還是AMD的APP又是？為何要用GPU加速？
在評估速度之前必須先瞭解以上這些東西是什麼。
OpenCL是一種讓不同運算架構的處理器之間能夠協同運算或是溝通的平台。
CUDA與APP則是NV與AMD各自的圖形處理核心運算架構，自家設計好硬體，然後釋出能夠呼叫這些硬體資源的函式庫，讓工程師開發程式時知道用哪個函式可以調用記憶體、或指定多少顆CUDA或Stream核心來做什麼事情。
GPU加速的起源：
電腦的運算指令大概可分為兩類，一種是浮點運算、另一種是普通整數運算，通常普通軟體僅需要整數運算就能解決大部分的問題，但關於影像、多媒體、三維虛擬實境這類的處理卻必須有非常高的浮點運算能力才行，所以將浮點運算交給另個IC來處理的2D、3D加速卡概念就出來了，之後演變成如今這種局面，利用浮點運算能力非常強大的GPU核心來處理影像、圖形資訊，而CPU則專心負責通用運算處理，專才專用、可喜可賀。
正因為上述原因CPU與GPU的結構差異非常大，CPU因為要能夠快速處理所有電腦內的資訊所以單一核心的硬體元件數非常多，所以在製程上不太可能有太多個核心在同一個封裝上，因為元件數量太高所以會使發熱量提昇，在散熱能力有限的情況下，能容納的核心數非常有限。而GPU則相反，由於圖形處理有自己的規範（OpenGL與Direct X）GPU僅需要處理限定的指令，可以說硬體是專門為了支援這些規範而做了最佳化，所以單一核心的元件數量並不像CPU這樣肥大，導致GPU單一個封裝能容納的核心數量就遠高於CPU了，用我的電腦作為實際案例好了，CPU是X3 435如其型號有三個核心，顯示卡為AMD的R 5770有800個核心，三比上八百，GPU內的核心數量比CPU多了兩百多倍。
於是有人在比對這個數量差異之後突發奇想：如果讓這麼大量的核心一起幫我做運算，那效率豈不是等於有一個八百核的處理器？那Xeon或i7的12核算什麼？所以在得知這個構思後，NV覺得有搞頭，在2007年2月15日最早搶了頭香做出了GPU加速的雛型「CUDA」，想取得以自家顯卡加速的先機，而蘋果公司也對GPU加速起了興趣，在做了初步研究之後發現自己一家公司做可能沒搞頭，必須要結合各家廠商建立一個通用架構，所以在2008年6月16日時與 AMD, IBM, Intel, Nvidia共同向 Khronos Group這個開放運算架構組織提出了「OpenCL」的架構，起初僅支援類似CPU與GPU這種本來就在PC很普及的零件上，後來隨著ARM公司(手機處理器架構的創始者)的加入，如今OpenCL也壯大到能夠支援手機的ARM架構處理器了，如果你有能力開發系統，理論上甚至能把一堆手機核心並列起來組成超級運算雲，這是題外話...。
轉檔有兩個階段，一、將影片檔案「解碼」變成「影像」，二、將影像轉存成檔案則稱為「編碼」。而轉檔最慢的部份在於「編碼」上。目前GPU的運算從07年到現在才發展沒多久，在這短短幾年內很難開發出一個能夠「有效」利用GPU的核心數的「編碼器」。雖然利用到所有GPU核心幫你工作理論上是可行的，但實際上這種程式的撰寫非常之不易，因為工程師要將原本在CPU處理時是一整長串影片數據的大量指令，分解成許多個指令給不同核心各自去處理，最後再將所有處理完的資料同步組合起來，這些都很傷腦力，且需要影像方面的應用數學家來配合才能達成。另外，硬體上也是處處碰壁，主要難處在於資源分配的部份，尤其是分配記憶體的部份，工程師很難決定要如何分配資料要存放在主記憶體或顯示記憶體上，因為PCI-E介面卡要經過晶片組作為溝通橋樑DDR(主記憶)體與GDDR(顯卡記憶體)面間溝通非常緩慢），另外指令能夠分解的數量有限，並非所有指令都能夠分解成許多小單位給大量的顯示核心並行運算，總之目前由於硬體的限制，導致軟體的開發處處都是困難，但為了達到以往都沒想過的速度...這些是開發必經的過程。
結論：
簡單來說，是目前正處在軟體、硬體都還正在發展的「磨合期」，目前軟硬體兩方面都在急劇進步當中，像是AMD公司就非常具有前瞻性地收購下ATI然後將CPU與GPU融合產生了APU這種東西，且一直在修改架構準備將GPU部份能夠有效為通用運算進行加速，而AMD在下一代APU當中也提出了HSA架構的概念，讓GPU與CPU共享主記憶體，如此一來便沒有像是與PCI-E介面卡間還要經過晶片組的頻寬瓶頸了，可謂GPU加速的一大進步，相信Intel與Nvidia也會馬上跟進，這樣良性競爭下最終將會使軟體與硬體都將同步提昇轉檔效率，所以我們消費者與廠商都是雙贏的，但需要時間等待就是了，目前還享受不到「真正解放」的GPU加速轉檔或者加速運算...。
就算你買了有很多核心的顯卡，目前也沒有軟體能夠「有效」發揮它的效能，所以核心數目絕不會是你考慮買卡來轉檔的主因，但如果說你有其他運算需求（如3D算圖、Adobe CS6全），或者你是程式開發者，那你可以買張2~3千元的卡，不論AMD或NVIDIA都可，反正都支援OpenCL來加速運算。
如果你注重畫質，x264軟體編碼器將是最佳選擇，它擁有CPU上的最高速度，以及對H.264各層級的架構支援度非常高，還能搭配Avisynth的各種濾鏡來處理影片，另外如果你要利用FFT(沒聽過就略過吧...)來去除雜訊，Avisynth也提供了使用GPU加速的濾鏡DLL我自己測試時GPU Loading幾乎都在100％。目前這套x264軟體編碼器亦有人正將它搬往OpenCL上不過目前還不穩定，各位可以關注x264之後的動態。
如果你注重速度，但又不想失去太多畫質，那你可以考慮支援OpenCL的編碼器，像是MainConcept H.264 Encoder、Xilisoft Video Converter Ultimate 6、Handbrake(Beta測試版)等軟體來進行轉檔編碼。
我個人是建議使用MainConcept H.264 Encoder，雖然加速幅度不大，不過它所提供的的畫質與軟體編碼相差彷彿，使用上比較困難，需要一定專業知識。
如果MainConcept操作介面上的單字看不懂...請直接使用Xilisoft Video Converter Ultimate 6，它沒有很多複雜艱深的詞彙、有中文版本，但產出的檔案較大（壓縮率較低）。
關於上面提到更有效率的CPU+GPU協同機制，AMD端將會推出hUMA共享主記憶體，Intel端則是早早就已經實作了。
Intel的作法是從Sandy Bridge開始，就已經讓內顯跟CPU核心都掛到內部超高速Ring Bus上，內顯可以跟CPU核心處於同等地位、從比記憶體快得多的L3快取直接存取CPU/內顯之間共享的資料，盡量不透過比快取慢很多的記憶體。先把穩固地基打好後，接下來就是持續在IVB、Haswell、Broadwell、Skylake....繼續堆電晶體加強內顯本身遊戲跟異質計算的能力，並持續改進高速Ring Bus的頻寬跟運作。
下圖是Sandy Bridge的示意圖，Ivy Bridge/Haswell基本上也都是基於類似的Ring Bus架構讓CPU跟GPU可共享L3快取，但有持續改善效能跟效率：
AMD Kaveri APU會採用hUMA，Llano/Trinity/Richland APU是透過更傳統的Snooping跟記憶體複製的方式，但不管是Kaveri/Trinity/Richland/Llano APU，都還只是在較慢的記憶體階層下功夫，還不敢大刀闊斧把GPU直接連到內部快取上。畢竟AMD礙於製程問題，在APU上連L3快取都取消了，也無從透過L3讓CPU跟GPU共享資料；而擁有L3快取的FX系列，則是無法再有空間納入內顯。
下圖是hUMA的概念：
hUMA是用來解決AMD自家CPU/內顯溝通效率未最佳化的問題，而Intel除了在Sandy Bridge時已經把CPU跟GPU之間的溝通方式打掉重練過、可以共享L3快取之外，在Intel處理器上執行OpenCL的程式，CPU跟GPU也是已經可以用類似於uHMA的方式共享/存取相同的實體記憶體區塊的，可參考Intel的OpenCL白皮書跟OpenCL程式設計指南：
http://software.intel.com/en-us/articles/opencl-the-advantages-of-heterogeneous-approach
http://software.intel.com/en-us/forums/topic/277703
換個角度看，Intel要繼續改進記憶體共享的機制，不會比當初在Sandy Bridge上加入Ring Bus架構/並把GPU也掛上L3快取來得更有挑戰，畢竟最難的架構打掉重建工作已經熬過去了。但是AMD要大幅度敲掉架構、把內顯也掛到L3快取上面去，首先得要有能把L3快取加回APU、或是能在FX上加入內顯的製程餘裕，因此不管從架構設計面、生產製程面來看，都將會是工程浩大。
原來Intel早已有了先見之明，將記憶體設計成「直通共享」，Intel支脈已經貫通了，正在鍛鍊內息；AMD則是相反、內息很充盈，但因為支脈尚未貫通，沒法發出大招。
既然GPU都有能力即時處理一堆影像資訊了，沒道理不能操滿所有核心來共同演算，只缺在分散式軟體演算架構尚未成熟。
PSU輸出總共分成3.3V、5V、12V三種，電腦零件個別使用哪種呢?
3.3V：PCI匯流排、南橋晶片、網路晶片
5V：12cm風扇(包含以下尺寸，部分14cm也可以5V供電啟動)、HDD硬碟跟光碟機PCB以及晶片元件、MB前後I\O輸出介面(EX : USB、P\S2)、MB 部分控制晶片(EX : PWM、音效晶片)、記憶體
12V：PCI-E匯流排、CPU、顯示卡、北橋晶片(未整合進CPU前)、HDD硬碟以及光碟馬達、MB MOSFET、14cm風扇(包含以上尺寸)
12cm風扇最低可以用3.3V電壓啟動，14cm以上最低則需要7V電壓才能啟動，PWM風扇實際上就是以電壓去控制風扇轉速高低，少部分高價風扇則是自己有PWM晶片做溫控動作。
在AGP跟更早之前的PCI時代，顯示卡吃的是3.3V，所以當時PSU重視的是3.3V、5V輸出，某些廠商因無力研發新架構就只能一直啃老本賣舊有商品，這類PSU跟目前時下主流重視12V相比會被認為『不足瓦』，實際上單純就以前跟現在的供電需求類型不同。
從顯示卡改吃12V供電之後，整平台吃最重的就是12V了，不計瑣碎的周邊、IO、匯流排、晶片那些，光算CPU跟顯示卡的耗電量就佔了總平台將近95%，所以挑PSU幾乎只要看12V就能夠判斷能否供給平台穩定使用。
12V以目前主流來看幾種迴路設計
(一) 單路12V輸出, 如下:
P.S. : 振華雖然都為單路設計，但保護僅有3項
優點：
硬體只要接上即可使用，不須計算12V迴路供電有無分別過載
缺點：
OPP、OCP觸發上限不明確的話，過載未斷路12V有極大機率直接帶走所有零件
(二) 雙路、三路、四路12V輸出, 如下:
優點：
多數設計為CPU、PCI-E1、PCI-E2甚至大瓦數產品有PCI-E3、PCI-E4為個別12V負責供應，遇到零件故障或者某路12V過載造成暴衝或者OCP、OPP、SCP未觸發，幾乎是只有該路12V所附掛的零件損壞
缺點：
如廠商未提供明確的12V分路供應設計，USER又無法得知該資訊，很容易因附掛零件擠在同一路12V造成過載
12V部分挑完之後就是看保護，基本上有六項
低電壓UVP：電壓的最小值超過限制時自動關閉電源供應器
過電流OCP：超過電流負荷時，自我防護動作啟動自動關閉電源供應器(視廠商設定觸發上限). 無OCP，有可能是"假雙路、真單路". OCP設太高=虛設
過電壓OVP：電壓的最大值超過限制時自動關閉電源供應器
過負載OPP：超過電源最大負載110%~130%時，自動關閉電源供應器(視廠商設定觸發上限)
過溫度OTP：感溫元件感應到溫度超過限制溫度時自動關閉電源供應器
短路保護SCP：當有輸出到任一零件端的電阻低於0.1歐姆時避免造成其他零件發生短路, 自動關閉電源供應器
以目前3.3V+5V總和100~120W左右來說，硬碟掛8顆是絕對沒問題的，不要有硬碟掛多吃不少3.3V、5V就認為12V輸出會減少，兩者的保護是分開做不互相干涉。
!!! 不管再貴、設計再好的產品良率也不會100%.
你學會看7樣東西，挑出來的psu的89不離10了。
[1]電壓上的波紋必須小, ripple of 100% loading (要看用示波器測的，軟體測的都是垃圾，無參考價值)
[2]電壓必須穩定，高負載不能掉壓，掉一點點可以, 不能太多。以顯示卡而言, 如供電不足螢幕會出現花屏之類的，表示螢幕顯示不正常，並不清晰，就是代表供電不足，但不至於會燒掉. 檢測電源供應器最好用線性阻抗當負載，如大功率電阻，加載之後再以示波器觀測各點波形，這樣比較能明確判斷電源供應器是否正常。輕載或空載的情況下, 單單量測電壓是不足以判斷的.電容老化, 輸出電流不足, 接上負載一定會掉電壓. 差勁的Power, 電壓起伏越大,相對的顯示卡.主機板.記憶體.硬碟 升天的機率就越高. 常見的狀況就是電壓供應器沒有爆炸. 硬碟掛了N顆. 主機板或顯示卡一直送修.
[3]該有的安全機制必須有,保護機制的種類和設定值。( 缺一不可, 多路款至少要知OCP的設定值)
[4]交叉負載時，哪些點的表現比較差
[5]知道自己到底要單路還是多路，多路又是幾路
[6]瓦數計算:單軌供電尤其是12V的瓦數必須足夠應付需求。取得CPU、顯示卡的約略滿載耗電量→挑選預算內12V足以供給CPU、顯卡總和耗電量之產品→從12V足夠、預算內的清單內先挑選出保護最足的部分→以用料、交叉負載表現最佳的產品購買。主要是看PSU的12V瓦數, 不是總瓦數。
[7]各式接頭在12v分路上的分配 (ex: 12V1 for MB+Accessory, 12V2 for CPU, …)、長度與數量
另外, 基於安全上的考慮, 歐美先進國家認為超過240VA的直流電,對人體電擊和設備火災..安全有危險. 所以其安規有要求持續功率不能超過240VA的認證. 例如,12V電源輸出不能超過20A, 5V不能超過48A,20V不能超過12A....
單路12V設計PSU,它的電流往往都超過20A,這種單路PSU在歐美是違反安規,不得進口販售的.且電流的限流保護線路會受溫度和材料誤差所影響,限流值常可能有10% 以上誤差. 廠商怕違反安規, 在標示PSU 12V最大額定電流時,有時只標示18A ,不敢標剛剛好20A.
各國安規略有不同要求,歐盟有CE,北美FCC,CSA,CB,UL標張,中國有CCC ,日本有PSE, ... 台灣經濟部標檢局BSMI認證則沒要求240VA規定,所以市售仍買得到單路12V大電流的PSU. 台灣市售號稱符合多國安規的PSU,大都是採多路設計,設計成本略高一點點.
顯卡設計者,也明白這240VA安規,且一根power pin腳,最大約可耐6~7A,所以,高階的顯卡的12V接頭,會分成8P +6P(3power pins + 3 GND pins),分別吃不同路的電流. 同理, SLI時,顯卡上的接頭也是分別各自吃不同路的電流.這樣就不會違反240VA的安規.
所以,很多大瓦數的PSU,若要賣歐美國家,它的12V輸出,就得把1路,分流成2路,3路(12V1,12V2,12V3),甚至5路,分別給CPU,高階顯卡,或SLI .每路最大電流都會小於20A,通常是18A.
一般來說，IGP (Integrated graphics processors) 主機板插上獨立顯卡後，內建的IGP預設都會自動關閉 (關閉後, 耗電量會少一點嗎?)。因此, 在條件相同的情況下，含IGP的主機板加裝獨立顯卡的效能表現，和一般的北橋並沒有明顯差別。
因此在 BIOS 中 Interal Graphics 的選項, 保留 default : AUTO 即可.
