2010-08-21 17 views
19

Tôi tìm thấy trình điều khiển tsc2007 và sửa đổi theo nhu cầu của chúng tôi. Công ty chúng tôi đang sản xuất bảng TI DM365 của riêng mình. Trong bảng này, chúng tôi đã sử dụng TSC2007 và pin PENIRQ được kết nối với GPIO0 của DM365. Nó đang được nhìn thấy OK trên trình điều khiển. khi tôi chạm vào con trỏ màn hình cảm ứng đang di chuyển nhưng đồng thời tôi nhận đượcCách giải quyết "BUG: lập lịch trong khi nguyên tử: swapper/0x00000103/0, CPU # 0"? trong trình điều khiển TSC2007?

BUG: scheduling while atomic: swapper /0x00000103/0, CPU#0 

cảnh báo và nhúng Linux đang bị lỗi. có 2 tệp mà tôi đã sửa đổi và tải lên http://www.muhendislikhizmeti.com/touchscreen.zip một là với bộ hẹn giờ mà bộ kia không có. nó cho lỗi này trong mọi trường hợp.

Tôi đã tìm thấy giải pháp trên web mà tôi cần sử dụng hàng đợi công việc và gọi bằng cách sử dụng API schedule_work(). nhưng bây giờ họ đang mờ dần. Có ai có bất kỳ ý tưởng làm thế nào để giải quyết vấn đề này và có thể cho tôi một số lời khuyên nơi để bắt đầu sử dụng hàng đợi công việc.

Trả lời

28

"Lập lịch trong khi nguyên tử" cho biết bạn đã cố gắng ngủ ở đâu đó mà bạn không nên - như trong phần quan trọng được bảo vệ bởi spinlock hoặc trình xử lý ngắt.

Ví dụ phổ biến về những thứ có thể ngủ là mutex_lock(), kmalloc(..., GFP_KERNEL), get_user()put_user().

12

Chính xác như đã nói trong câu trả lời đầu tiên, lập lịch trong khi nguyên tử xảy ra khi trình lên lịch bị nhầm lẫn và do đó không thể hoạt động bình thường và điều này vì bộ lập lịch đã cố gắng thực hiện "lịch biểu()" trong phần chứa mã có thể lập lịch bên trong không thể lên lịch.

Ví dụ bằng cách sử dụng chế độ ngủ bên trong phần được bảo vệ bởi ổ xoay. Cố gắng sử dụng một khóa khác (semaphores, mutexes ..) bên trong mã spinlock-proteced cũng có thể làm phiền lên lịch trình. Ngoài ra, việc sử dụng các khóa spinlocks trong không gian người dùng có thể khiến trình lên lịch hoạt động như vậy. Hy vọng điều này sẽ giúp

2

Cảm ơn các cựu hai câu trả lời, trong trường hợp của tôi nó là đủ để vô hiệu hóa các đòn phủ đầu:

preempt_disable(); 

// Your code with locks and schedule() 

preempt_enable(); 
+0

không đủ chính xác: như quán cà phê cho biết, khóa không được ngủ. chỉ spinlock đủ điều kiện cho điều đó. Không thể sử dụng khóa mutex (tôi không chắc chắn?), khi khóa mutex bắt đầu đợi, CPU có thể được lên lịch cho bộ xử lý khác (vì bên trong mutex_lock() là cuộc gọi hàm "might_sleep()", có thể dẫn đến tự nguyện sắp xếp lại - bởi vì cond_resched() được gọi, ngay cả khi bạn đã đặt cờ trước để tắt (có thể dẫn đến lỗi khác?), khi lập lịch tự nguyện được thực hiện khi cờ tiền thưởng được bật? hãy thảo luận. –

4

Đối với bất cứ ai khác với một lỗi tương tự - Tôi có vấn đề này bởi vì tôi đã có một chức năng, được gọi từ ngữ cảnh nguyên tử, sử dụng kzalloc(..., GFP_KERN) khi cần sử dụng GFP_NOWAIT hoặc GFP_ATOMIC.

Đây chỉ là một ví dụ về chức năng ngủ khi bạn không muốn, đó là điều bạn phải cẩn thận trong lập trình hạt nhân.

Hy vọng điều này hữu ích cho người khác!

Các vấn đề liên quan