Câu hỏi này khá dài, vì vậy tôi sẽ đặt câu hỏi ở đầu và sau đó đi qua phương pháp của tôi để đến với câu hỏi:
- Có phải rm (dựa trên Busybox) không thực thi vì không đủ RAM liền kề?
- Nếu vậy, có một phương pháp nhẹ để chống phân mảnh DMA - mà không cần dùng đến hệ thống khởi động lại không?
- Nếu không, điều gì gây ra nó? Làm thế nào tôi có thể ngăn chặn nó xảy ra trong tương lai?
Sau khi hệ thống kiểm tra của chúng tôi hoạt động khá mạnh trong vài ngày qua - tôi đã telnet vào hệ thống và kiểm tra kết quả kiểm tra. Khi tôi đến để xóa một số dữ liệu, hệ thống trả về dòng lệnh (như thể lệnh đã thực thi đúng). Khi tôi đến để kiểm tra thư mục cho một tập kết quả khác, tôi thấy tệp vẫn tồn tại (sử dụng ls).
Sau này, tôi nhận thấy ngày càng nhiều lệnh shell của mình không hoạt động như mong đợi.
Tôi sẽ bắt đầu với một đầu ra từ dmesg sau khi rm không thực thi đúng:
Phân bổ chiều dài 61440 từ quy trình 6821 (rm) không thành công
DMA mỗi cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Active_anon: 0 active_file: 1 inactive_anon: 0 inactive_file: 0 không thể mô tả: 6 bẩn: 0 writBack: 0 không ổn định: 0 miễn phí: 821 slab: 353 ánh xạ: 0 pagetables: 0 nảy: 0
DMA miễn phí: 3284kB phút: 360kB thấp: 448kB cao: 540kB active_anon: 0kB inactive_anon: 0kB active_file: 4kB inactive_file: 0kB không thể xác định: 24kB hiện tại: 8128 trang Không
lowmem_reserve []: 0 0 0
DMA: 31 * 4kB 47 * 8kB 42 * 16kB 64 * 32kB 1 * 64kB 0 * 128kB 0 * 256kB 0 * 512kB 0 * 1024kB 0 * 2048kB 0 * 4096kB = 3284kB
Tổng cộng 14 trang pagecache
Không thể phân bổ RAM cho dữ liệu quá trình, errno 12
Ban đầu, tôi nghĩ rằng tôi không thể chạy chương trình trong phần lớn nhất của bộ nhớ liền kề. Có nghĩa là DMA quá phân mảnh và tôi sẽ phải tìm cách để hệ thống chống phân mảnh bộ nhớ.
Sau đó, tôi đã thực hiện kiểm tra toán / vệ sinh nhanh chóng và nhận ra rằng chương trình lẽ ra đã có thể chạy trong khe cắm bộ nhớ liền kề 64kB. Rm đã yêu cầu 61440 byte (60kB).
Tôi đã thực hiện một "chống phân mảnh thủ công" cũ và khởi động lại hệ thống. Khi tôi khởi động lại sytem, tôi xuất / Proc / Buddyinfo:
Node 0, zone DMA 2 8 3 12 0 1 0 1 0 1 0
Mà tôi nghi ngờ bản đồ tới:
- 2 x 4 kB
- 8 x 8 kB
- 3 x 16 kB
- 12 x 32 kB
- 1 x 128 kB
- 1 x 512 kB
Nhưng nếu tổng hợp danh sách các giá trị ở trên, nó không khớp với đầu ra của / Proc / meminfo :
MemTotal: 6580 kB
MemFree: 3164 kB
Buffers: 0 kB
Cached: 728 kB
SwapCached: 0 kB
Active: 176 kB
Inactive: 524 kB
Active(anon): 0 kB
Inactive(anon): 0 kB
Active(file): 176 kB
Inactive(file): 524 kB`
Unevictable: 0 kB
Mlocked: 0 kB
MmapCopy: 844 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 0 kB
Mapped: 0 kB
Slab: 1268 kB
SReclaimable: 196 kB
SUnreclaim: 1072 kB
PageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 3288 kB
Committed_AS: 0 kB
VmallocTotal: 0 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
Tóm lại, câu hỏi của tôi là:
- Có phải rm không thực thi vì không đủ RAM liền kề?
- Nếu vậy, có một phương pháp nhẹ để chống phân mảnh DMA - mà không cần dùng đến hệ thống khởi động lại không?
- Nếu không, điều gì gây ra nó? Làm thế nào tôi có thể ngăn chặn nó xảy ra trong tương lai?
Tôi đang sử dụng XPort Pro của Lantronix (8MB, HĐH Linux) chạy phiên bản uClinux 2.6.30. Vỏ đang sử dụng thì im lặng.