The HP-inkjet ran out of ink and stopped accepting printjobs. For some reason, FreeBSD never got the message. lpq continued to claim, lp is online and printing. The cat(1) process launched by the apsfilter hung in the `swwrt' state. According to fstat(1), the process had the ulpt0 open. It could not be killed (tried SIGKILL and SIGBUS). Disconnecting and re-connecting the printer did not help. Nor did changing the cartridge. After I changed the cartridge, lprm-ed the hung job restarted lpd, and resubmitted the job, the top 20% of the page got printed, after which hpijs (HP's printer program, integrated with GhostScript) started spewing out: Aug 28 14:39:41 symbion hpijs: unable to write to output, fd=6, count=4096: m Aug 28 14:40:12 symbion last message repeated 398514 times Aug 28 14:42:12 symbion last message repeated 1797112 times [...] My attempts to reboot (shutdown -r now 'USB stuck?') resulted in the following (double?) panic (how did the text survive the panic to appear in the log file?): Aug 28 14:43:09 symbion shutdown: reboot by mi: USB stuck? Aug 28 14:43:09 symbion hpijs: unable to write to output, fd=6, count=4096: m Aug 28 14:43:12 symbion last message repeated 40487 times Aug 28 14:43:12 symbion /kernel: fxp0: promiscuous mode disabled Aug 28 14:43:12 symbion hpijs: unable to write to output, fd=6, count=4096: m Aug 28 14:43:13 symbion last message repeated 15376 times Aug 28 14:43:13 symbion syslogd: exiting on signal 15 Aug 28 14:48:03 symbion /kernel: kernel trap 22 with interrupts disabled Aug 28 14:48:03 symbion /kernel: kernel trap 12 with interrupts disabled Aug 28 14:48:03 symbion /kernel: Aug 28 14:48:03 symbion /kernel: Aug 28 14:48:03 symbion /kernel: Fatal trap 12: page fault while in kernel mode Aug 28 14:48:03 symbion /kernel: fault virtual address = 0xc2451e08 Aug 28 14:48:03 symbion /kernel: fault code = supervisor read, page not present Aug 28 14:48:03 symbion /kernel: instruction pointer = 0x8:0xc166e1d7 Aug 28 14:48:03 symbion /kernel: stack pointer = 0x10:0xde0eed28 Aug 28 14:48:03 symbion /kernel: frame pointer = 0x10:0xde0eed38 Aug 28 14:48:03 symbion /kernel: code segment = base rx0, limit 0xfffff, type 0x1b Aug 28 14:48:03 symbion /kernel: = DPL 0, pres 1, def32 1, gran 1 Aug 28 14:48:03 symbion /kernel: processor eflags = resume, IOPL = 0 Aug 28 14:48:03 symbion /kernel: current process = 30306 (cat) Aug 28 14:48:03 symbion /kernel: interrupt mask = none Aug 28 14:48:03 symbion /kernel: trap number = 12 Aug 28 14:48:03 symbion /kernel: panic: page fault Aug 28 14:48:03 symbion /kernel: Aug 28 14:48:03 symbion /kernel: syncing disks... 33 6 2 Aug 28 14:48:03 symbion /kernel: done Aug 28 14:48:03 symbion /kernel: Uptime: 10d21h41m24s Aug 28 14:48:03 symbion /kernel: Terminate ACPI Aug 28 14:48:03 symbion /kernel: Automatic reboot in 15 seconds - press a key on the console to abort Aug 28 14:48:03 symbion /kernel: Rebooting... The 'current process' in the above panic is the cat launched by apsfilter. All functions in the kernel itself (according to nm /kernel) are at 0xc0* addresses. The panic must've been in one of the kernel modules, most probably, in the ulpt, of course. Fix: Don't print if the printer is not ready, which defeats some of the lpd(8)'s purpose. How-To-Repeat: A USB printer turned on (we have the HP-7110 here, but any other HP should do), but with an empty cartridge should do -- simply cat-ing into /dev/ulpt0 should hang the cat.
Responsible Changed From-To: freebsd-bugs->freebsd-usb Reassign to appropriate mailing list.
I'm seeing the same thing with a different system running 5.3-stable and a different HP printer. A freshly booted system prints fine, but after some uptime an attempt to print results in some commotion on the printer and a flood of messages like: Jan 26 12:19:32 aldan hpijs: unable to write to output, fd=6, count=4096: m Jan 26 12:19:32 aldan hpijs: unable to send DeviceStatus: m Jan 26 12:19:32 aldan hpijs: unable to write to output, fd=6, count=4096: m Jan 26 12:19:32 aldan hpijs: unable to write to output, fd=6, count=4096: m Jan 26 12:19:32 aldan hpijs: unable to send DeviceStatus: m (Indeed, hpijs is programmed to keep trying after a write(2) fails.) After some time, the whole machine panics -- even if I manage to kill the "offending" hpijs process. Could it be, that after some time it is harder for the driver to get memory and the shortage-handling code is broken? This is quite embarassing, actually. A simple print job to panic a server? -mi
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Seems to be duplicate of 122483. The problem has already been fixed, though. *** This bug has been marked as a duplicate of bug 122483 ***