Hide Forgot
Created attachment 491060 [details] dmesg output Description of problem: can't kill the hpijs process Version-Release number of selected component (if applicable): It's F13 fully updated with the kernel 2.6.38.2-10.fc13.i686.PAE rebuild locally without any changes from the http://kojipkgs.fedoraproject.org/packages/kernel/2.6.38.2/10.fc15/src/kernel-2.6.38.2-10.fc15.src.rpm How reproducible: Once a week. Steps to Reproduce: 1. print occasionally some pdf documents on the printer connected to the usb port. Actual results: The first symptom is the following error in the log: hp[9696]: prnt/backend/hp.c 833: ERROR: null print job total=0 Them I've tried to kill the hpijs process: $ ps 9704 PID TTY STAT TIME COMMAND 9704 ? D 0:00 hpijs $ su -c 'kill -9 9704' $ echo t > /proc/sysrq-trigger But the process didn't get killed: [225616.678034] hpijs D c406fda0 0 9704 1 0x00000084 [225616.678034] c406fdb0 00200086 00000002 c406fda0 00000000 00000000 a8e09043 0000ccb6 [225616.678034] c0b15180 c25f9920 c0b15180 c25f9bb0 c25f9bac c25f9bac c0b15180 c0b15180 [225616.678034] 00000000 00000000 ef6bf800 0000ccb6 c25f9920 c406fd68 c05ece7f f516b020 [225616.678034] Call Trace: [225616.678034] [<c05ece7f>] ? list_del+0xb/0x1b [225616.678034] [<c04bd431>] ? __rmqueue+0x87/0x31c [225616.678034] [<c043075f>] ? kmap_atomic_prot+0x150/0x152 [225616.678034] [<c04bceee>] ? zone_watermark_ok+0x30/0x37 [225616.678034] [<c07f7c3a>] __mutex_lock_common+0xe9/0x136 [225616.678034] [<c07f7ca4>] __mutex_lock_slowpath+0x1d/0x1f [225616.678034] [<c07f7d9e>] ? mutex_lock+0x30/0x3e [225616.678034] [<c07f7d9e>] mutex_lock+0x30/0x3e [225616.678034] [<c06ed305>] usbdev_open+0xd5/0x1e7 [225616.678034] [<c06ecf94>] ? match_devt+0x0/0x16 [225616.678034] [<c04f8f98>] ? exact_match+0x0/0xc [225616.678034] [<c04f92ec>] chrdev_open+0xf1/0x10e [225616.678034] [<c04f5203>] __dentry_open+0x13b/0x21d [225616.678034] [<c04f53b0>] nameidata_to_filp+0x52/0x5e [225616.678034] [<c04f91fb>] ? chrdev_open+0x0/0x10e [225616.678034] [<c04ff87e>] finish_open+0x7f/0x13c [225616.678034] [<c0500636>] ? do_path_lookup+0x5b/0xe3 [225616.678034] [<c050121b>] do_filp_open+0x183/0x4f9 [225616.678034] [<c04e8cc9>] ? slab_pre_alloc_hook+0x29/0x2d [225616.678034] [<c05e815a>] ? might_fault+0x1e/0x20 [225616.678034] [<c04f4fc1>] do_sys_open+0x56/0xdc [225616.678034] [<c04f509b>] sys_open+0x28/0x2e [225616.678034] [<c07f8d64>] syscall_call+0x7/0xb Expected results: The process should be killed.
The output from sysrq-d (show held locks) might be useful. (Something is holding a USB mutex.)
Created attachment 496467 [details] sysrq-{d,t} output Please find attached sysrq-d from the similar situation using the kernel compiled from the http://kojipkgs.fedoraproject.org/packages/kernel/2.6.38.4/20.fc15/src/kernel-2.6.38.4-20.fc15.src.rpm Showing all locks held in the system: 3 locks held by khubd/24: #0: (&__lockdep_no_validate__){+.+.+.}, at: [<c0712f59>] hub_thread+0x114/0x1117 #1: (&__lockdep_no_validate__){+.+.+.}, at: [<c0712b4d>] usb_disconnect+0x6f/0x135 #2: (&__lockdep_no_validate__){+.+.+.}, at: [<c06c2b88>] device_release_driver+0x18/0x2a 1 lock held by mingetty/2361: #0: (&tty->atomic_read_lock){+.+.+.}, at: [<c0694178>] n_tty_read+0x1d7/0x5ec 1 lock held by mingetty/2363: #0: (&tty->atomic_read_lock){+.+.+.}, at: [<c0694178>] n_tty_read+0x1d7/0x5ec 1 lock held by mingetty/2365: #0: (&tty->atomic_read_lock){+.+.+.}, at: [<c0694178>] n_tty_read+0x1d7/0x5ec 1 lock held by mingetty/2369: #0: (&tty->atomic_read_lock){+.+.+.}, at: [<c0694178>] n_tty_read+0x1d7/0x5ec 1 lock held by mingetty/2373: #0: (&tty->atomic_read_lock){+.+.+.}, at: [<c0694178>] n_tty_read+0x1d7/0x5ec 1 lock held by bash/2946: #0: (&tty->atomic_read_lock){+.+.+.}, at: [<c0694178>] n_tty_read+0x1d7/0x5ec 2 locks held by bash/3214: #0: (sysrq_key_table_lock){......}, at: [<c069961b>] __handle_sysrq+0x1d/0x122 #1: (tasklist_lock){.?.?.-}, at: [<c047135c>] debug_show_all_locks+0x43/0x176 1 lock held by bash/3315: #0: (&tty->atomic_read_lock){+.+.+.}, at: [<c0694178>] n_tty_read+0x1d7/0x5ec
Does this still happen with the latest 2.6.40.x kernel in F15?
No it doesn't, can be closed.
Thank you for letting us know!