Làm cách nào để sửa lỗi BUG: khóa mềm - CPU # 0 bị kẹt trong 17163091968s?


14

CẬP NHẬT: Tôi đã cập nhật tiêu đề của tin nhắn, vì gần đây tôi đã thấy nhiều vấn đề hơn với lượng thời gian chính xác này 17163091968s. Điều này sẽ giúp mọi người điều tra các triệu chứng để tìm trang này. Xem câu trả lời (tự-) được chấp nhận của tôi dưới đây.


Tôi có một bó Ubuntu 10.04 LTS VM 64 bit trong trung tâm dữ liệu VMware vSphere. Các công cụ VMware đã được cài đặt (vSphere Client nói "OK").

Tôi đã thấy một số VM bị treo vài lần với lỗi sau trong syslog. Khi kiểm tra tình hình từ vSphere, bảng điều khiển có màu đen và lệnh "Khởi động lại khách" không làm gì cả, vì vậy tôi phải cấp nguồn cho VM.

Dec  1 11:44:15 s0 kernel: [18446744060.007150] BUG: soft lockup - CPU#0 stuck for 17163091988s! [jed:26674]
Dec  1 11:44:15 s0 kernel: [18446744060.026854] Modules linked in: btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs xt_tcpudp iptable_filter ip_tables x_tables acpiphp fbcon tileblit font bitblit softcursor ppdev vga16fb psmouse parport_pc shpchp vgastate i2c_piix4 lp parport serio_raw intel_agp floppy mptspi mptscsih vmw_pvscsi e1000 mptbase
Dec  1 11:44:15 s0 kernel: [18446744060.026899] CPU 0:
Dec  1 11:44:15 s0 kernel: [18446744060.026900] Modules linked in: btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs xt_tcpudp iptable_filter ip_tables x_tables acpiphp fbcon tileblit font bitblit softcursor ppdev vga16fb psmouse parport_pc shpchp vgastate i2c_piix4 lp parport serio_raw intel_agp floppy mptspi mptscsih vmw_pvscsi e1000 mptbase
Dec  1 11:44:15 s0 kernel: [18446744060.026920] Pid: 26674, comm: jed Not tainted 2.6.32-30-server #59-Ubuntu VMware Virtual Platform
Dec  1 11:44:15 s0 kernel: [18446744060.026922] RIP: 0033:[<00007f92e03d2ce6>]  [<00007f92e03d2ce6>] 0x7f92e03d2ce6
Dec  1 11:44:15 s0 kernel: [18446744060.026930] RSP: 002b:00007fff6069b770  EFLAGS: 00000202
Dec  1 11:44:15 s0 kernel: [18446744060.026932] RAX: 00007f92e27e7e10 RBX: 00007f92e06d5e40 RCX: 0000000000020000
Dec  1 11:44:15 s0 kernel: [18446744060.026933] RDX: 00007f92e27e7e10 RSI: 0000000000020209 RDI: 0000000000000002
Dec  1 11:44:15 s0 kernel: [18446744060.026934] RBP: ffffffff81013cae R08: 0000000000000001 R09: 0000000000000000
Dec  1 11:44:15 s0 kernel: [18446744060.026935] R10: 00007f92e06d6398 R11: 0000000000000870 R12: 00000000000000c0
Dec  1 11:44:15 s0 kernel: [18446744060.026937] R13: 00007f92e299dca0 R14: 0000000000000020 R15: 00007f92e06d5e40
Dec  1 11:44:15 s0 kernel: [18446744060.026939] FS:  00007f92e105b700(0000) GS:ffff880009c00000(0000) knlGS:0000000000000000
Dec  1 11:44:15 s0 kernel: [18446744060.026940] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec  1 11:44:15 s0 kernel: [18446744060.026941] CR2: 00007ff12ea15000 CR3: 0000000267067000 CR4: 00000000000006f0
Dec  1 11:44:15 s0 kernel: [18446744060.026968] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Dec  1 11:44:15 s0 kernel: [18446744060.026989] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Dec  1 11:44:15 s0 kernel: [18446744060.026991] Call Trace:

(Không có dấu vết - đó là dòng cuối cùng.)

Tôi dường như không còn các lỗi khác nữa, nhưng tôi khá chắc chắn rằng quy trình được đề cập ở trên ( jed) khác với các bãi khác.

  • Điều gì có thể gây ra vấn đề này?

  • Làm thế nào để ngăn chặn điều này xảy ra?

Một số thông tin thêm:

  • Giá trị 17163091988là một chút (ý định chơi chữ) đáng ngờ - đó là 1111111111000000000000000000010100ở dạng nhị phân. Có lẽ lỗi đã cố nói 20 giây ( 10100ở dạng nhị phân)?

  • Tôi không chắc vấn đề có còn tồn tại với kernel 10.04 mới nhất (2.6.32-35) hay không.

  • Tôi cũng đã thấy task ... blocked for more than 120 secondsvấn đề - có lẽ chúng có thể liên quan?

  • máy khách vSphere không hiển thị các cảnh báo hoặc tác vụ di chuyển cho VM.


có thể có gì đó sai thời gian? Bạn có thể chơi với clocksource. Ngoài ra trạng thái C của CPU là một dự đoán tốt.
SaveTheRbtz

Câu trả lời:


12

Cảm ơn tất cả các bình luận viên. Tôi nghĩ rằng tôi đã tìm thấy câu trả lời. Dường như có một lỗi thời gian trong ít nhất là phiên bản kernel 2.6.32-30 của Ubuntu. Lỗi đôi khi (?) Giết chết máy khi chúng đạt thời gian hoạt động khoảng 200..210 ngày. Trên thực tế, việc dừng lại không xảy ra ngay sau khi đạt đến giới hạn, nhưng được kích hoạt bởi một số thao tác (trong trường hợp của tôi apt-get install ...:).

Lưu ý: 200 ngày là khoảng 2 ^ 32 lần 1/250 giây và 250 là giá trị mặc định cho CONFIG_HZ.

Hiện tại, tôi chưa tìm thấy dữ liệu về vấn đề đã được khắc phục trong các hạt nhân gần đây hơn. Tôi biết rằng nó dường như không ảnh hưởng đến một nhân cũ hơn (máy chủ 2.6.32-26). Từ tất cả các thông tin này, tôi cho rằng nếu nó chưa được sửa, thì có thể tránh được bằng cách:

  • khởi động máy sau mỗi 190 ngày (dù sao cũng nên nâng cấp kernel)
  • điều chỉnh CONFIG_HZ thành 100 và do đó cứ sau 497 ngày. Tuy nhiên, điều này có thể có tác dụng phụ khá bất ngờ, đặc biệt là trong môi trường ảo. Và nó không giải quyết được vấn đề.

Đây là một báo cáo lỗi cho Ubuntu.


Tìm kiếm tốt - tự hỏi nếu nó
lừa

Vì tò mò: Bạn đang sử dụng NTP hoặc đồng bộ hóa thời gian qua vmware? Nghe có vẻ như thay đổi thời gian liên tục hoặc một cái gì đó tương tự .. nên có các mục nhập thời gian thay đổi trong syslog.
pauseka

Tôi vừa thấy một cái gì đó có vẻ liên quan đến debian, kernel 2.6.32-5-amd64 hiển thị hai khóa mềm đang hoạt động "kỳ quặc"
James

5

Đây thực sự là một lỗi kernel đã được sửa bởi kernel kernel sau:

http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=4cecf6d401a01d054afc1e5f605bcbfe553cb9b9

Bạn có thể tìm kiếm LKML cho tiêu đề sau (không thể đăng nhiều hơn 2 liên kết): [ổn định] 2.6.32.21 - sự cố liên quan đến thời gian hoạt động?

Và đây là lỗi LP # mang đến sửa lỗi kernel:

https://bugs.launchpad.net/ubfox/+source/linux/+orms/902317

Nâng cấp lên kernel mới nhất trong các bản cập nhật sáng suốt sẽ khắc phục vấn đề này cho tốt.

HTH


2

Có thể là máy chủ ảo hóa có một số tính năng tiết kiệm năng lượng ("Green IT") được kích hoạt có thể gửi các lõi không sử dụng sang chế độ ngủ / công suất thấp, gây ra sự gián đoạn thú vị trong các máy ảo sử dụng lõi đó? Tôi đã nghe điều này từng là một vấn đề chủ yếu trong môi trường HyperV nhưng nó có thể là một cái gì đó để xem xét.


1

Trong trường hợp người khác tìm thấy điều này, một bản nâng cấp kernel đã khắc phục một vấn đề tương tự đối với tôi. Tôi đã có một JBOD được gắn vào hệ thống thông qua bộ điều khiển SAS3 ném các lỗi Softlock CPU này khi khởi động.

Tôi đã có Ubuntu 14.04.2 kernel phiên bản 3.16.0-30 và thực hiện "nâng cấp apt -y" đã kết thúc tôi tại kernel 3.16.0-49 và điều đó đã giải quyết được vấn đề.

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.