ยกเลิกหรือจัดการข้อมูลยกเลิกเมื่อธุรกรรม AXI ตอบกลับข้อผิดพลาด

พื้นหลัง

ฉันมีระบบ ZynqMP ซึ่งมี Cortex-A53 คอร์ (PS) สี่คอร์พร้อมกับตรรกะ FPGA (PL) พวกเขาถ่ายโอนข้อมูลผ่าน AXI บัส

ฉันได้วาง Xilinx AXI Quad SPI ไว้ในการออกแบบของฉัน Linux ที่ทำงานบน PS สามารถตรวจสอบพวกมันได้สำเร็จ และสตาร์ท daemons ซึ่งขอให้ MCU บน SPI ตอบกลับก้อนข้อมูลเป็นระยะ (~ สูงสุดประมาณ 500 ไบต์ โดยแบ่งออกเป็นทุกๆ 64 ไบต์)

มันทำงานได้ดีสักพัก (ค่ามัธยฐาน 50 นาที) แต่ทันใดนั้น readl_relaxed() ในไดรเวอร์ SPI ทำให้เกิด Synchronous External Abort ซึ่งทำให้เกิด Kernel Panic ดูเหมือนว่าจะเป็นการตอบกลับข้อผิดพลาดของ AXI ตาม ARM TRM และอาจกู้คืนได้เนื่องจากเป็นแบบ "ซิงโครนัส" ซึ่งหมายความว่าการลงทะเบียนไม่เสียหาย (ในความเข้าใจของฉัน)

หลังจากการค้นหาบางอย่าง ฉันพบ do_sea( ) func ที่จัดการ SEA และยังพบว่าไม่มีโอกาสที่จะฟื้นตัวตามการใช้งาน

ฉันต้องการให้จัดการข้อผิดพลาดของ AXI เช่น: ละทิ้งการอ่าน, ส่งคืน SIGBUS และนำไปสู่กระบวนการที่ถูกฆ่า ฯลฯ

แน่นอนว่าฉันกำลังแก้ไขข้อบกพร่องของ Abort และค้นหาสาเหตุว่าทำไมมันถึงเกิดขึ้น แต่ปัจจุบันฉันยังไม่มีเบาะแส

คำถาม

ดังนั้นคำถามของฉันคือ:

  1. เหตุใด SEA จึงไม่สามารถกู้คืนได้ในการใช้งาน Linux arm64
  2. หากฉันสามารถ "จัดการ" หรือ "เพิกเฉย" ได้ ฉันจะแก้ไขโค้ดเคอร์เนล Linux ได้อย่างไร (ฉันรู้ว่ามันโง่ แต่ฉันอยากรู้ว่ามีวิธีใดบ้าง)
  3. ข้อผิดพลาดในการตอบกลับใน Quad SPI IP สามารถทำอะไรได้บ้าง readl_relaxed ที่ฉันกล่าวถึงข้างต้นอ่าน Rx data FIFO

person puhitaku    schedule 17.12.2018    source แหล่งที่มา
comment
หมายเหตุที่ไม่เกี่ยวข้องโดยสิ้นเชิง: C++1x ที่คุณอ้างอิงในโปรไฟล์ของคุณ ตอนนี้คือ C++11   -  person S.S. Anne    schedule 20.09.2019


คำตอบ (1)


1) ฉันไม่เคยเสี่ยงไปตามเส้นทางนี้ แต่สำหรับฉันดูเหมือนว่าพวกเขาจะสามารถกู้คืนได้หาก inf->fn ส่งคืนค่า 0; ซึ่งหมายความว่า ghes_notify_sea() ต้องคืนค่า 0; ดังนั้นหนึ่งในแหล่งที่มาของข้อผิดพลาด SEA จึงรายงานข้อผิดพลาดได้สำเร็จ

2) ฉันคิดว่าคุณต้องการข้อมูลเพิ่มเติมอีกเล็กน้อย ฉันจะเริ่มต้นด้วยการเปลี่ยน drivers/acpi/apei/ghes.c:732

from:
rc = ghes_read_estatus(ghes, 0);
to:
rc = ghes_read_estatus(ghes, 1);

ซึ่งน่าจะทำให้คุณได้รับข้อมูลเพิ่มเติมอีกเล็กน้อยเมื่อเกิดข้อผิดพลาด เมื่อได้รับข้อมูลดังกล่าวแล้ว คุณจำเป็นต้องค้นหาว่ามีตัวจัดการที่ทำงานผิดปกติหรือขาดหายไปหรือไม่ ไม่ว่าจะด้วยวิธีใด นี่คือสถานที่ที่จะกล่าวถึง

3) คุณกำลังเผชิญกับการนำ ACPI ไปใช้ เคอร์เนลมี 155 kloc บวกกับปริมาณที่ไม่ทราบในเฟิร์มแวร์และฮาร์ดแวร์ ดูเหมือนว่ารหัสเคอร์เนลไม่สามารถจัดการกับเงื่อนไขใด ๆ ที่คุณกำลังประสบอยู่ ขั้นแรก คุณต้องพิจารณาว่าผู้ต้องสงสัยรายใดที่เกี่ยวข้องและการโต้ตอบใดที่ล้มเหลวก่อนที่คุณจะสามารถค้นหาสาเหตุที่แท้จริงได้

มีความสุขในการขุด!

person mevets    schedule 19.12.2018
comment
ขอบคุณสำหรับข้อเสนอแนะโดยละเอียดของคุณ ฉันจะพยายามหาข้อมูลเพิ่มเติมเกี่ยวกับการยกเลิก จากนั้นเจาะลึกเข้าไปใน ACPI impl - person puhitaku; 20.12.2018