Tôi đã nhận được một số lỗi btrfs và ext4. Sau khi quyết định kiểm tra RAM, tôi đã nhận được các lỗi lặp lại sau đây memtester. Tôi luôn gặp lỗi tương tự sau khi chạy một chút memtester. Thông thường trong một giờ, nhưng phải mất 4-5 giờ trong một lần.

RAM máy tính của tôi được hàn. Tôi có thêm khe trống. Không có cài đặt nào trong BIOS để tắt RAM trên bo mạch.

Tôi đã chạy:

• Memtest86 + trong 8 lần vượt qua (~ 8 giờ)
• MemTest86 trong 18 lần vượt qua (~ 9 giờ)
• memtestervà stressapptesttrên mặc định Fedora 27, được cài đặt trên thanh USB (~ 10 giờ)
• memtestervà stressapptesttrên Ubuntu 17.10 Live mặc định (~ 2 giờ)
• memtestervà stressapptesttrên Ubuntu 17.10 trên thanh USB (~ 8 giờ)
• # debsums --changed tập tin thay đổi duy nhất là một hình ảnh của một chủ đề.

Họ đã không in bất kỳ lỗi nào.

Tôi đang sử dụng Ubuntu 17.10 (được nâng cấp từ 17.04) với kernel mặc định. Hạt nhân không bị nhiễm độc. Đó là một máy tính xách tay ASUS với Intel Haswell i3.

• Cũng đã thử nghiệm với Linux 4.14.13 và 4.15.0-rc3, RC4, tuyến chính.
• Cũng được thử nghiệm với gói intel-microcode.

Lỗi có thể tái tạo hoặc Nouveau bị vô hiệu hóa hoặc bị kích hoạt, không có trình điều khiển nhị phân nvidia nào được tải.

Danh sách đen các mô-đun sau: mtd intel_spi_platform intel_spivì chúng không tải trên cài đặt Fedora 27 mặc định và chúng dường như gạch một số máy tính xách tay Lenova. Lỗi chưa dừng lại.

uname -ađầu ra của

Linux hostname 4.13.0-19-generic #22-Ubuntu SMP Mon Dec 4 11:58:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

# lsmodđầu ra của

https://paste.ubfox.com/26222245/

Fedora 27 của # lsmodđầu ra 's

https://paste.ubfox.com/26226473/

Tình hình hiện tại

Tôi đã đặt ổ cứng vào máy tính xách tay (máy tính xách tay dự phòng) mà tôi biết là tốt và đã chạy thử nghiệm ở đó. Tôi đã nhận được các lỗi. Bây giờ tôi khá chắc chắn đây là một vấn đề phần mềm. Tôi chưa bao giờ có thể kích hoạt các lỗi trên máy tính xách tay của mình bằng Ubuntu mới cũng như với Fedora đã thử nhiều giờ.

Tôi nên làm gì?

Một mẫu các lỗi:

Loop 6:
  Stuck Address       : ok         
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok         
  Block Sequential    : ok         
  Checkerboard        : ok         
  Bit Spread          : ok         
  Bit Flip            : testing 262
FAILURE: 0x00000000 != 0xfffffffeffffffff at offset 0x0ef94000.
FAILURE: 0x00000000 != 0x100000000 at offset 0x0ef94008.
FAILURE: 0x00000000 != 0xfffffffeffffffff at offset 0x0ef94010.
FAILURE: 0x00000000 != 0x100000000 at offset 0x0ef94018.
FAILURE: 0x00000000 != 0xfffffffeffffffff at offset 0x0ef94020.
FAILURE: 0x00000000 != 0x100000000 at offset 0x0ef94028.
FAILURE: 0x00000000 != 0xfffffffeffffffff at offset 0x0ef94030.
FAILURE: 0x00000000 != 0x100000000 at offset 0x0ef94038.
  Walking Ones        : ok         
  Walking Zeroes      : ok         
  8-bit Writes        : ok
  16-bit Writes       : ok

Một lỗi tương tự với cả hai khe RAM đều đầy:

Loop 1:
  Stuck Address       : ok         
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok         
  Block Sequential    : ok         
  Checkerboard        : ok         
  Bit Spread          : testing   4
FAILURE: 0x00000000 != 0x00000050 at offset 0x7da80000.
FAILURE: 0x00000000 != 0xffffffffffffffaf at offset 0x7da80008.
FAILURE: 0x00000000 != 0x00000050 at offset 0x7da80010.
FAILURE: 0x00000000 != 0xffffffffffffffaf at offset 0x7da80018.
FAILURE: 0x00000000 != 0x00000050 at offset 0x7da80020.
FAILURE: 0x00000000 != 0xffffffffffffffaf at offset 0x7da80028.
FAILURE: 0x00000000 != 0x00000050 at offset 0x7da80030.
FAILURE: 0x00000000 != 0xffffffffffffffaf at offset 0x7da80038.
  Bit Flip            : setting 141

Một lỗi của stressapptest:

Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e000(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e008(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e010(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e018(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e020(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e028(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e030(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a
Report Error: miscompare : DIMM Unknown : 1 : 157s
Hardware Error: miscompare on CPU 2(0x2) at 0x7fcc0726e038(0xb0d18:DIMM Unknown): read:0x0000000000000000, reread:0x0000000000000000 expected:0x4a4a4a4a4a4a4a4a

Tôi nghi ngờ bằng cách nào đó cấu hình của Ubuntu kết hợp với phần cứng máy tính xách tay của tôi là để đổ lỗi cho những lỗi này. Hầu như mọi lúc trong gói tám.

Không quan trọng, thông tin liên quan lỏng lẻo dưới đây

Về các lỗi btrfs; Tôi đã sử dụng 17.04. Tôi đã hỏi xung quanh trong irc của btrfs. Tôi đã được thông báo rằng đó có thể là lỗi phần cứng hoặc lỗi nào đó là lỗi quản lý bộ nhớ. Một phần của trang siêu dữ liệu của các btrfs chứa đầy số không, giống như tôi đã trải nghiệm bây giờ. Tôi đã chạy memtester chỉ một vài lần, chuyển sang ext4 và đổ lỗi cho trình điều khiển nhị phân nvidia.

Các lệnh và tham số của chúng mà tôi sử dụng:

# stressapptest -M 10000 -s 1800

10000 là bộ nhớ khả dụng mà tôi có thể kiểm tra. Tôi hiểu nó qua free -m-s` là giây.

# memtester 4096

CPU của máy tính xách tay có 2 lõi nên tôi thường bắt đầu hai trường hợp. 4096 là một nửa bộ nhớ hiện có thông quafree -m

Đã xóa câu trả lời gần

Một câu trả lời đã bị xóa trong phần hỏi đáp này:

Bạn đã thử cài đặt lại Ubuntu bởi vì nó có vẻ như lỗi quản lý bộ nhớ cấp hệ điều hành

Câu trả lời của tôi là tương tự vì nó liên quan đến quản lý bộ nhớ ở mức rất thấp; KASLR ở cấp hạt nhân.

KASLR làm gì

KASLR là viết tắt của K ernel Một ddress S tốc độ L ayout R andomization. Tôi chưa bao giờ nghe thấy nó nói to nhưng trong tâm trí tôi phát âm nó là "Casler". Nghĩ ma thân thiện trong máy. KASLR là một biện pháp bảo mật để ngẫu nhiên hóa vị trí các mô-đun hạt nhân nằm trong bộ nhớ. Lý thuyết là hạt nhân khó bị hack hơn khi bạn không thể dựa vào cùng một đoạn mã luôn ở cùng một vị trí bộ nhớ.

Hoạt động KASLR có thể được coi là đối nghịch với các trình kiểm tra bộ nhớ, đọc và ghi lặp lại vào cùng một vị trí bộ nhớ không mong đợi THAY ĐỔI. Chúng đối lập với nhau, nó thu hút tôi (thành ngữ nhận thấy), để thực hiện tìm kiếm google trên KASLR và lỗi bộ nhớ. Một người đặc biệt dường như không liên quan có thể xứng đáng nhận được một tin nhắn trên github liên kết đến Q & A này. Lý do là họ nghĩ rằng họ là những người duy nhất bị ảnh hưởng bởi việc dịch chuyển địa chỉ bộ nhớ (nếu tôi đọc chính xác chủ đề của họ). Ba lượt truy cập đầu tiên là từ RedHat , người mà tôi không muốn liên kết đến vì trang web của họ là một phần bài đăng để có được trên robot tìm kiếm google và sau đó họ bắt bạn phải trả tiền để đọc.

Có những vấn đề đã biết khi KASLR tải "nội dung" hạt nhân vào giữa bản đồ bộ nhớ mà nó không phải làm. Thật không may, tôi không thể nhớ lại liên kết tôi tìm thấy tuần trước để đưa vào câu trả lời tối nay. Liên kết có một bản vá / cách giải quyết để chỉ đạo KASLR không sử dụng các vị trí bộ nhớ cụ thể.

Sau khi xác nhận các vấn đề đã biết với KASLR và các vị trí bộ nhớ, tôi đã nhận xét dưới câu hỏi để vô hiệu hóa KASLR và kiểm tra lại bộ nhớ. Một câu trả lời cho biết nó có vẻ thành công vì vậy tôi đang đăng câu trả lời này.

Cách vô hiệu hóa KASLR

Mặc dù tôi đã sử dụng tùy chọn dòng lệnh grub kernel "kaslr" trong một vài năm nay, nó đã trở thành mặc định kernel kể từ ít nhất là phiên bản 4.12 . Để loại bỏ KASLR khỏi tải, sử dụng chỉnh sửa /etc/default/grubvà thay đổi dòng này:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nokaslr"

Bạn có thể có các tùy chọn khác ngoài "yên tĩnh" và "giật gân". Bước quan trọng là thêm "nokaslr" và để các tùy chọn khác thay thế.

Sau đó lưu tệp và chạy:

sudo update-grub

Tất nhiên, một cách khác để vô hiệu hóa KASLR là chỉ cần sử dụng Kernel cũ hơn như 4.4.0 trong Ubuntu 16.04.1 khi KASLR không được tự động đưa vào.

Vấn đề rất giống với sự cố bit ngẫu nhiên của RAM. Theo kinh nghiệm của tôi, MemTest86 là bài kiểm tra "quá dễ" cho phần cứng. Nó sẽ tìm thấy bộ nhớ thực sự xấu nhưng các vấn đề nhỏ thường sẽ không được chú ý.

Nếu bạn muốn biết bộ nhớ của mình có tốt không, hãy thử chạy Prime95 ở chế độ tự kiểm tra / tra tấn được cấu hình để sử dụng càng nhiều RAM càng tốt.

Một thử nghiệm tốt khác là chạy thử nghiệm rowhammer hai mặt trong vài giờ.

Tôi tin rằng nếu Prime95 và rowhammer hai mặt không thể tìm thấy bất kỳ vấn đề nào với bộ nhớ của bạn, thì nó có thể hoạt động chính xác. Tuy nhiên, chỉ cần chạy MemTest86, biên dịch chương trình, cài đặt HĐH, chơi trò chơi có thể hoạt động ngay cả khi bộ nhớ của bạn hơi kém (ở đó, đã làm điều đó - và bị hỏng dữ liệu trong thời gian dài).