Bí ẩn Service Processor biến mất: Hành trình debug phần cứng đầy thú vị của Oxide

Phần mềm30 tháng 5, 2026·5 phút đọc

Các kỹ sư tại Oxide đã phải đối mặt với một lỗi khó hiểu khi Service Processor (SP) trên hệ thống rack của họ đột ngột mất kết nối mạng. Quá trình điều tra sâu sắc đã hé lộ một vấn đề phức tạp liên quan đến xung nhịp FPGA, bộ nhớ đệm và cách vi xử lý ARM xử lý thuộc tính bộ nhớ.

Bí ẩn Service Processor biến mất: Hành trình debug phần cứng đầy thú vị của Oxide

Trong quá trình phát triển hệ thống Oxide rack, một trong những nguyên tắc thiết kế cốt lõi là khả năng quản lý từ xa hoàn toàn. Kỹ sư chỉ cần can thiệp vật lý khi thay thế linh kiện hỏng, chẳng hạn như ổ cứng. Tuy nhiên, đội ngũ kỹ sư của Oxide đã từng đối mặt với một tình huống khó xử khi Service Processor (SP) — bộ não quản lý hệ thống — bỗng dưng "biến mất" khỏi mạng quản lý mà không rõ nguyên nhân.

Bài viết này sẽ đi sâu vào hành trình điều tra lỗi đầy thú vị, nơi ranh giới giữa phần mềm và phần cứng trở nên mong manh, đòi hỏi sự am hiểu sâu sắc về cả hệ điều hành tùy chỉnh Hubris và kiến trúc vi xử lý ARM.

Triệu chứng lạ lùng và những giả thuyết ban đầu

Vấn đề xuất hiện khi Oxide thử nghiệm thế hệ sled Cosmo mới. Đôi khi, SP ngừng phát tín hiệu mạng, khiến việc gỡ lỗi trở nên cực kỳ khó khăn vì không có đường truy cập từ xa. Các triệu chứng đi kèm bao gồm:

  • CPU chủ AMD vẫn hoạt động (hệ thống vẫn có điện).
  • Không có gói dữ liệu nào được gửi từ SP.
  • Quạt gió quay hết công suất, cho thấy bộ điều khiển nhiệt độ có thể đã rơi vào chế độ khẩn cấp.

Kỹ sư đang kiểm tra hệ thốngKỹ sư đang kiểm tra hệ thống

Vì SP chạy trên hệ điều hành Hubris (viết bằng Rust) tùy chỉnh, nhóm kỹ sư ban đầu nghi ngờ lỗi phần mềm. Một giả thuyết được đưa ra là task starvation (tác vụ bị đói tài nguyên), nơi một tác vụ bị lỗi lặp vô tận chiếm dụng CPU, ngăn cản tác vụ mạng hoạt động. Họ cũng nghi ngờ lỗi tràn stack (stack overflow), một vấn đề phổ biến trong hệ thống nhúng khi kích thước stack được định sizing thủ công.

Để theo dõi, họ đã chỉnh sửa mã để đèn LED trên khung máy chớp tắt thay vì sáng liên tục. Tuy nhiên, kết quả lại càng thêm confusing: đôi khi đèn bị tắt hẳn, đôi khi lại sáng cố định.

Đào sâu vào phần cứng và FPGA

Khi phần mềm không tìm ra nguyên nhân rõ ràng, sự chú ý chuyển sang phần cứng. Oxide sử dụng chip STM32H7 (Cortex-M7) cho SP và kết nối với một FPGA thông qua bộ điều khiển bộ nhớ linh hoạt (FMC). FPGA này điều khiển các bộ phận quan trọng như flash của máy chủ.

Một trong những nghi ngờ lớn nhất là vấn đề về thời gian (timing) của FPGA. Nếu FPGA không xác nhận (acknowledge) bus kịp thời, CPU có thể bị treo vĩnh viễn khi cố gắng đọc thanh ghi. Để kiểm chứng, họ tạo ra một hình ảnh kiểm tra khiến FPGA cố tình treo bus FMC và kết quả cho thấy các triệu chứng rất giống với lỗi thực tế.

Nhóm đã sử dụng kỹ thuật vector catch của ARM để ngắt CPU ngay khi reset và đổ trạng thái bộ nhớ (RAM dump). Mặc dù mất dữ liệu thanh ghi, nhưng RAM vẫn được bảo toàn. Tuy nhiên, các dữ liệu này không chỉ ra rõ ràng tác vụ nào đang gây lỗi.

Điểm rơi: Sự không khớp của thuộc tính bộ nhớ

Vấn đề thực sự chỉ được phát hiện khi Oxide thực hiện công việc measured boot (khởi động đo lường) cho Root of Trust (RoT). Tính năng này yêu cầu SP tự reset nhiều lần, làm tăng đáng kể tần suất xuất hiện lỗi — từ vài ngày một lần xuống còn 10-20 phút.

Sau hàng loạt thử nghiệm không thành công, Laura Abbott và nhóm kỹ sư đã tìm ra manh mối quan trọng trong tài liệu STM32H7 và ARMv7-m. Vấn đề nằm ở Memory Protection Unit (MPU) và cách CPU xử lý bộ nhớ đệm (cache).

Trong Hubris, các tác vụ (tasks) không đặc quyền ánh xạ FMC là Uncached Device Memory. Tuy nhiên, nhân (kernel) đặc quyền lại sử dụng bản đồ bộ nhớ mặc định, nơi địa chỉ cơ sở của FMC lại được định nghĩa là Normal Cached Memory.

Kịch bản gây lỗi diễn ra như sau:

  1. Một tác vụ không đặc quyền thực hiện lệnh lưu (store) vào FMC; dữ liệu nằm trong bộ đệm lưu trữ của CPU.
  2. Một ngắt (interrupt) xảy ra, chuyển CPU sang chế độ đặc quyền (kernel).
  3. Vì kernel coi địa chỉ này là Cached, CPU cố gắng ghi dữ liệu từ cache vào bộ nhớ.
  4. Việc này vi phạm các thuộc tính bộ nhớ mong đợi của FPGA (được thiết kế cho truy cập 32-bit cụ thể), dẫn đến việc CPU bị treo khi cố gắng truy cập bus FMC.

Giải pháp và bài học

Tài liệu của ARM cảnh báo rõ ràng về việc sử dụng các thuộc tính không khớp (mismatched attributes) cho cùng một vị trí bộ nhớ. Giải pháp cuối cùng rất đơn giản nhưng tinh tế: Oxide đã thay đổi địa chỉ cơ sở của FMC sang một vùng trong bản đồ bộ nhớ mặc định của ARM có thuộc tính là Device Memory, no caching.

Kể từ khi sửa đổi này được hợp nhất, lỗi biến mất SP không còn xuất hiện nữa. Câu chuyện này là một minh chứng rõ ràng cho thấy việc debug hệ thống nhúng hiện đại đòi hỏi sự hiểu biết toàn diện từ phần mềm cấp cao đến kiến trúc phần cứng thấp. Oxide cũng nhấn mạnh tầm quan trọng của việc minh bạch trong tài liệu kỹ thuật từ các nhà sản xuất phần cứng, giúp các kỹ sư giải quyết những vấn đề "bí ẩn" như thế này.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗