map 後 PE 藍屏原因專題討論(e820cycles參數)

標籤：

map 後 PE 藍屏原因專題討論(e820cycles參數)

map 後 PE 藍屏原因專題討論(e820cycles參數)
http://bbs.znpc.net/thread-6182-1-5.html
不點發表於 2011-12-8 11:42:31

大家知道，藍屏的 workaround 解決方案是用 map --e820cycles=0 。但這並未根本解決問題。

本帖希望通過大量的使用者測試和使用經驗，探討藍屏的真正技術原因，以及可能的解決辦法。

有以下問題需要澄清：

1。何時開始藍屏的？就是說，什麼時候出廠的機器，開始藍屏？目的是確定舊電腦有無藍屏現象。

2。藍屏與硬體（主板、顯卡）有關還是與軟體（驅動程式）有關？猜測藍屏不過就是某個顯卡驅動的 bug 所導致的（這 bug 可能是人為製造的，也可能不是，這裡不討論這個話題）。顯卡驅動有可能在某種硬體條件之下才 “引爆” bug，而在別的硬體之下，bug 未被 “啟用”。如果確實如此，則更換顯卡驅動，應該可以解決藍屏問題。

我覺得WINPE藍屏可能與FIRADISK或WINVBLOCK驅動有關——現在的PE大都用FIRADISK驅動，而我的迷你筆記型電腦上用FIRADISK做WIN2003的RAMOS，也容易出現藍屏，而WINVBLOCK似乎好一些，不過好象沒幾個用WINVBLOCK做PE的驅動的。

貌似從Intel的5系列晶片開始出現的，集顯或可切換顯卡的筆記本較常出現，估計是跟Intel的HD顯卡有關，但至於是驅動還是硬體導致的，還得懂PE製作的人幫忙測試
什麼叫 BIOS？那可不是只有主板才有 BIOS。顯卡也有 BIOS。那些板卡，它們插在主板上，都可能有自己的 BIOS，也可能影響主板上原有的 BIOS。它們與主板一起，構成一個統一的、最終的 BIOS。這個最終的 BIOS，有時候為了簡單起見，就統稱為主板 BIOS。板卡插在主板上，影響的就是這個最終的 BIOS。因此，在上述討論中，說 BIOS 沒問題，是不對的。

你可以 “排除” 掉主板的問題，但你不能 “排除” 掉 BIOS 的問題。“主板” 與 “BIOS” 是兩個不同的概念，即，它們互相有 “交叉”，但不是完全相同的。

根據諸位的描述，我也覺得問題可能是由顯卡引起的。但嚴格來說，其實任何一個板卡（包括主板）都可能有問題。就是說，理論上存在這樣的可能性，即，問題根本上是主板造成的，但顯卡只是不幸地成為了 “受害者”（它被冤枉，它成為最大的 “嫌疑”）。

如果有人能夠證明，這個顯卡插在任何主板上都有同樣的問題，那麼這就基本上證明了確實是顯卡的問題。
越來越多的跡象表明，正是由於 intel 的顯卡造成的問題。大家繼續給出 “ 證明 ”。
如果可能，希望您提供grub4dos命令列下（直接進入命令列後）執行 displaymem 命令的顯示結果和執行 ‘ map --status ‘命令的顯示結果 。
我開這個文章，本來的目的僅僅是探討在預設的 --e820cycles=-1 的情況下藍屏問題的，結果，大家超出了這個範圍。

原來的目的只是是想搞清導致藍屏的具體技術細節的。就是想判斷出，究竟哪個驅動程式導致了死機，以及可否通過更換有問題的驅動程式而解決問題。這才是開這個文章的目的。

再次澄清：

當 --e820cycles 不是 -1 的時候，出現任何情況，都是正常的，就是說，死機、藍屏，都屬於正常現象，我想，這一點就不用多次重複解釋了吧？而且這也不是本帖關注的重點。
sony vaio vpcsa雙顯卡膝上型電腦：
map --e820cycles=-1後藍屏，改成map --e820cycles=3正常
仔細看“framebuf”，說明是顯示緩衝有關

藍屏的原因，以前就搞清楚了，是 Windows 保護模式的驅動程式導致的。zhaohj 的情況，在藍屏時已經把出錯的驅動程式名字列出來了，它叫 framebuf 。

如果能夠更換掉這個驅動程式，就可以避免藍屏。

別再懷疑 grub4dos 的 int15 了。完全與此無關。zw2312914 仔細看看，grub4dos 的 int15，基本上可以說，不可能出錯的，這已經經過了無數次反覆的錘鍊了。應該是你自己搞錯了。你從頭到尾，仔細看看，就可知道，不會犯這樣低級的錯誤。

為什麼說與 grub4dos 的 int15 無關呢？因為已經證明了，在 grub4dos 的 int15 接管控制之後，什麼也不做，立即用 jmp 指令轉到 ROM 中原來的入口，照樣死機。而只有完全把 int15 的中斷向量直接改成 ROM 入口，才不死機。這就是為什麼要添加 e820cycles 參數的緣由了。

就是說，只要中斷號被修改成指向低於 ROM 的常規記憶體（即使立即又轉向 ROM 入口），在有問題的機器上，必死無疑。否則，如果不被 grub4dos 接管，就不會藍屏。問題十分清楚明白，這與 grub4dos 的 int15 的處理過程，完全無關。

所以，別在這個問題上糾結了。根本無解，除了更換驅動程式以外。

有證據顯示，同一台機器，換用 win7 一切正常，這說明，問題不在 grub4dos 上，而正是 XP 的驅動程式的錯。

以上都是有證明的，沒有含糊不清的地方。

displaymem 命令不顯示是否被 map 佔據的空間。也就是說，displamem 命令永遠顯示原來的、系統 BIOS 所賦予的記憶體布局。

memcheck 才顯示經過 map --hook 修改後的記憶體布局。

目前感覺大於4G記憶體的機器，map --mem --top /iso.iso (0xff)這種形式，會破壞模擬盤；
曾經測試上面8G記憶體的sony筆記本，前後map --mem --top一個虛擬盤，也不成功。
e820在4G以上是否沒保護？
----------------------
再找了台8G記憶體的台式機，map --mem --top 成功。
看來還是雙顯卡主板的問題。
但雙顯卡主板的機器，不加--top是可以成功的。也許是4G以上的記憶體地區不是一個連續的空間，裡面有空洞，我們沒有檢測出來。
大家知道，藍屏的 workaround 解決方案是用 map --e820cycles=0 。但這並未根本解決問題。

 

map 後 PE 藍屏原因專題討論(e820cycles參數)