Bug 695068

Summary: can't kill the hpijs process
Product: [Fedora] Fedora Reporter: Damian Wrobel <dwrobel>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-26 17:18:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
dmesg output
none
sysrq-{d,t} output none

Description Damian Wrobel 2011-04-10 10:15:15 UTC 
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.
Comment 1 Chuck Ebbert 2011-04-14 01:41:47 UTC 
The output from sysrq-d (show held locks) might be useful. (Something is holding a USB mutex.)
Comment 2 Damian Wrobel 2011-05-03 09:23:09 UTC 
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
Comment 3 Josh Boyer 2011-09-26 15:24:42 UTC 
Does this still happen with the latest 2.6.40.x kernel in F15?
Comment 4 Damian Wrobel 2011-09-26 16:51:19 UTC 
No it doesn't, can be closed.
Comment 5 Josh Boyer 2011-09-26 17:18:10 UTC 
Thank you for letting us know!