BSOD 0x09c trên 50 máy SuperMicro


8

Đối với một dự án, chúng tôi có 50 máy chủ được trang bị (nói chung) phần cứng giống nhau. Vấn đề chúng tôi có ở đây là rất nghiêm trọng và xảy ra trên tất cả các máy. Mặc dù có rất nhiều nỗ lực và liên hệ với các nhà sản xuất và các nhà phát triển phần mềm, mọi người đều chỉ vào nhau và thậm chí từ chối cung cấp cho tôi manh mối về những gì đang diễn ra.

Đầu tiên hãy để tôi mô tả các thiết lập. Đây là phần cứng 'máy chủ'. Đối với trải nghiệm đầu tiên của tôi, serverTHER là sự thất vọng lớn nhất trong cuộc đời tôi.

  • SuperMicro X10SDV-8C + -LN2F
  • Intel Xeon D-1540 (được nhúng trên bo mạch chủ)
  • Trường hợp 1U được thiết kế tùy chỉnh hoặc trường hợp ban đầu SuperMicro
  • PSU máy chủ 480 watt hoặc PSU gốc SuperMicro 200 watt
  • Ổ cứng SSD Samsung Evo 850 500 GB
  • 32 GB DDR4-2133 ECC hoặc NON-ECC (nhưng không được trộn trong cùng một máy chủ)
  • GPU GT330 4GB DDR3
  • GPU được gắn với thẻ riser PCIe (không phải ruy băng), không tên từ Trung Quốc hoặc SuperMicro gốc

Chạy trên hệ thống - Windows Server 2012 R2 Enterprise - VMWare Workstation 12 - Các nhiệm vụ chuyên sâu về GPU chạy của VM - Hệ thống này là chứng khoán, hoàn toàn không có / ép xung

Triệu chứng - BSOD ngẫu nhiên 0x09c (còn gọi là Machine_Check_Exception): đôi khi hệ thống chạy trong một tuần không có vấn đề gì, đôi khi gặp sự cố chỉ sau 10 phút, nhưng hầu hết thời gian nó chạy trong vài giờ.

Đã thử / kiểm tra:

  • BIOS được cập nhật lên phiên bản mới nhất (bây giờ tôi nghĩ rằng điều này đã cải thiện thời gian để hệ thống ổn định, nhưng điều đó có thể là ngẫu nhiên).
  • Windows cập nhật lên phiên bản mới nhất.
  • VMWare cập nhật lên phiên bản mới nhất.
  • Hoán đổi tất cả các thành phần và thử mọi tùy chọn khác nhau, thậm chí đã thử một ổ SSD ATX PSU và M.2 trên máy tính để bàn.
  • Đã cài đặt tất cả các hệ thống từ đầu với Ubuntu. Tôi không quen thuộc với Linux và chưa bao giờ thấy Linux BSOD và tôi vẫn không biết vì các hệ thống máy chủ không có đầu và tôi đã thử điều này ở DC. KẾT QUẢ: hệ thống sẽ bị treo và sau khi khởi động lại Linux đã báo cáo sự cố XORG (liên quan đến GPU).
  • Thay đổi cài đặt GPU trong BIOS thành 'Trên 4G', phần còn lại của BIOS là mặc định của nhà sản xuất.

Cũng thông tin:

  • Các hệ thống được đặt trong một trung tâm dữ liệu. Nhiệt độ, không khí, năng lượng và mạng là tối ưu.
  • Nhiệt độ thấp hơn mức tối đa của nhà máy
  • Chúng tôi có cùng một thiết lập phần mềm chạy trên máy tính để bàn (với phần cứng máy tính để bàn). Các hệ thống này có thể chạy tốt với 1 trong số 100 PC của chúng tôi bị sập mỗi tháng.
  • Tôi đã liên hệ với VMWare, nói rằng đây là sự cố phần cứng
  • Tôi đã liên lạc với SuperMicro, họ nói không có gì thực sự ngoại trừ một số thứ và đã thử và đây cũng có thể là một vấn đề phần mềm.

Chúng tôi đang tuyệt vọng ở đây. Ứng dụng chúng tôi chạy may mắn là loại dư thừa. Nếu một máy chủ và VM bị ngừng hoạt động, đó không phải là vấn đề như vậy, các máy chủ khác sẽ tải trong vòng 5 phút, nhưng với tốc độ này, tôi bắt buộc phải trực tuyến cả ngày để khởi động lại máy chủ.

Tôi có một kiến ​​thức phần cứng lớn nhưng điều này đã vượt qua nó, tôi đã tìm kiếm nó cả ngày trong hơn một tháng để thử tất cả các loại khác nhau. Việc các bo mạch chủ này được sử dụng với các nhà cung cấp dịch vụ lưu trữ trên quy mô lớn khiến tôi nghi ngờ rằng bản thân bo mạch là ổn. Đây chắc chắn không phải là vấn đề phần cứng cụ thể đối với RMA vì tất cả 50 bảng đều có cùng một triệu chứng. Điều duy nhất khác biệt với chúng tôi là GPU. Điều này kết hợp với thử nghiệm Linux khiến tôi nghi ngờ rằng đây chắc chắn là thứ gì đó trên làn đường PCIe. Bản thân GPU ổn định trên máy tính để bàn của mobo. Mặc dù có dung lượng bộ nhớ lớn nhưng đây là một GPU nhỏ không tiêu thụ nhiều năng lượng. Tôi sẽ nghi ngờ các thẻ riser Trung Quốc, nhưng sau đó một lần nữa chúng tôi cũng sử dụng các riser được chứng nhận SuperMicro và chúng không cho thấy sự cải thiện nào cả.

Tôi rất tuyệt vọng để tìm một giải pháp ở đây. Điều này sẽ bắt đầu với việc xác định nguyên nhân chính xác. Chúng tôi sẵn sàng trả một khoản tiền thưởng tốt cho một chuyên gia có thể phân tích một số bãi và cung cấp cho chúng tôi nhiều chi tiết hơn (hoặc thậm chí tốt hơn, một giải pháp).

Trân trọng,

Simon


Tôi có một chút quen thuộc với bảng này, có một mình ... Có quá nhiều bộ phận chuyển động ở đây và quá ít lời giải thích về những gì chúng là. Việc sử dụng VMware Workstation là gì? Ứng dụng nào đang được chạy trong chúng? GPU được truyền cho VM (s) như thế nào?
Michael Hampton

VM chạy một công ty Windows yêu cầu tải GPU. Tôi không thể giải thích điều này hơn nữa. Đây là VMWare Workstation, GPU được ảo hóa. Điều này cũng không thực sự quan trọng, nó hoạt động chính xác như nhau trên phần cứng máy tính để bàn mà không gặp vấn đề gì.
dùng349749

Nó quan trọng bởi vì bạn không chạy nó trên phần cứng máy tính để bàn!
Michael Hampton

2
Tôi nghi ngờ sự không tương thích giữa bo mạch chủ và GPU của bạn. Nếu may mắn, nó có thể là thứ có thể sửa được trong BIOS, nhưng tôi sẽ không đặt cược nhiều vào nó. Vì điều này có thể tái tạo được với kernel Linux stock, tôi sẽ cố gắng lấy thêm thông tin về sự hoảng loạn của kernel có thể xảy ra.
Luật29

Những gì chạy bên trong VM không quan trọng. Nó có thể là kết xuất nội dung khiêu dâm hoặc có thể là logaritm để tìm cách chữa trị cho viện trợ. Tất cả những gì quan trọng đó là tải GPU tiêu chuẩn. @ Luật29; Đó chính xác là cảm giác của tôi. Tôi thực sự đã không cho tôi bất kỳ sự hoảng loạn hạt nhân nào. Máy chủ không bị sập, chỉ là GUI.
user349749

Câu trả lời:


2

Vâng, điều này là siêu muộn, tôi tưởng tượng vấn đề được giải quyết vào thời điểm này? Dù bằng cách nào, 0x9C thường có nghĩa là lỗi phần cứng MCE, các hệ thống GPU của chúng tôi chạy linux như một hệ điều hành máy chủ báo cáo các lỗi này dài hơn một chút so với cửa sổ.

Dù sao, những thứ này đã xuất hiện ngẫu nhiên cho chúng tôi trên phần cứng tương tự do HP sản xuất một thời gian trước, cuối cùng nó không đủ cung cấp năng lượng cho GPU. Cụ thể là 75W được cho là do chính cổng PCIe cung cấp.

Chúng tôi đã xác nhận nó bằng đồng hồ vạn năng trên bảng đột phá PCIe. Điện áp giảm khi cả hai card mạng GPU và 10Gbe đều bị tác động mạnh cùng một lúc. Trong khi bo mạch chủ có khả năng cung cấp 75W cho khe x16, phần cung cấp năng lượng gặp khó khăn một chút khi các thẻ khác đều tiêu thụ hết năng lượng.

Riser có thể bị nghi ngờ ở đây và giảm điện áp trên tải hiện tại cao.


0

Cảm ơn vì đã trả lời. Bây giờ là 3 năm sau. Supermicro đã từ chối giúp chúng tôi bằng mọi cách có thể. Chúng tôi đã gửi nhiều máy (chính xác như được xây dựng bởi chúng tôi). Theo họ, họ đã đánh bại họ trong nhiều tuần và họ không bao giờ gặp nạn.

Đối với riser, lỗi tương tự xảy ra với GPU trực tiếp trong khe.

Supermicro tiếp tục đổ lỗi cho VMWare, một điều mà tôi đã tin tưởng cho đến khi tôi có được bàn tay mới của họ trong cùng một bảng. Không có bất kỳ bình luận nào từ Supermicro, hội đồng quản trị với Xeon D-1540 đã được cập nhật với Xeon D-1541 chỉ sau vài tháng. Bo mạch mới về cơ bản là cùng một sự hỗ trợ cho CPU mới hơn (cũng giống như tốc độ xung nhịp cao hơn một chút). Bảng cập nhật cũng có tính năng và thêm tiêu đề quạt.

Những bảng này không còn sụp đổ. Trên cùng một tải chính xác, họ sẽ chạy trong nhiều tháng mà không gặp vấn đề gì. Tôi thậm chí đã nhân bản máy móc ở đây, họ chạy phần cứng và phần mềm chính xác của những máy bị rơi.

Loại này xác nhận sự nghi ngờ của tôi. Supermicro biết có vấn đề với các bảng nhưng không muốn cho tôi biết lý do tại sao tôi đã kết thúc với gần 100 bảng này là vô dụng vì các sự cố. Họ chưa bao giờ và RMA hoặc sửa lỗi thậm chí không cập nhật BIOS cho nó vì vậy nó phải là một cái gì đó trên bảng.

Không cần phải nói, đây là lần đầu tiên và lần cuối cùng của tôi với Supermicro. Điều này có thể xảy ra với bất kỳ thương hiệu nào, nhưng sự hỗ trợ là con số không.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.