When printing a PostScript file, the kernel panics immediately after printing: % lpr test.ps % panic: lockmgr: pid 221, not exclusive lock holder 219 unlocking Debugger("panic") Stopped at Debugger+0x35: movb $0,0xc02fc980 db> trace Debugger(c0290143) at Debugger+0x35 panic(c028f340,dd,c028f320,db,40080040) at panic+0x70 debuglockmgr(c327b838,6,0,c7a0a700,c0292ad0) at debuglockmgr+0x29c brelse(c327b810,c0948b80,10,0,0) at brelse+0x5b7 PPBUS_WRITE(c094a800,2,2000,c7a0a700,c094a800) at PPBUS_WRITE+0x1e50 spec_vnoperate(c841ae20,c0ae9700,c841ae0c,c022f139,c841ae20) at spec_vnoperate+0 x6e4 ufs_itimes(...) at ufs_itimes+0x250a ufs_vnoperatespec(...) at ufs_vnoperatespec+0x15 vn_close(...) at vn_close+0x40 debug_vn_lock(...) at debug_vnlock+0xb4 fdrop(...) at fdrop+0xb9 closef(...) at closef+0x9b fdfree(...) at fdfree+0x30 exit1(...) at exit1+0x189 exit1(...) at exit1 syscall(2f,2f,2f,0,ffffffff) at syscall+0x176 Xint0x80_syscall() at Xint0x80_syscall+0x26 db> ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 221 c7a0a700 c8419000 1 1 219 006004 2 gs 211 ... db> When converting the file by hand and printing the result, everything works fine: % gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 -sOutputFile=- - <test.ps >test.djet5 00 % lpr test.djet500 % [ no panic ] I've no idea, why this works and the other panics. Fix: You can get around this bug by converting the postscript file before printing (s. a.). How-To-Repeat: On my machine the crash occurs whenever I print a PostScript file. I have no way to check if it occurs everywhere using my config or magicfilter or ... If you need further information (memory dumps after the panic or some config parameters) don't hesitate to ask me: bn@tellique.de
Just a "me to". At the time it was always reproducible although I'm not= sure if I can remeber how atm. I would get a panic on printing from a = mac (in ps format) via lpr. /etc/printcap contains: epson-bw|lp|Epson= Color Stylus 200 (B&W):\ :sh:of=3D/usr/local/libexec/lpr/epson= _bw.sh:\ :lp=3D/dev/lpt0:sd=3D/var/spool/lpd/epson-bw:lf=3D/var= /log/lpd-errs: epson_bw.sh just runs gs with a few arguments. There pa= nic message was: lockmgr: pid 130, not exclusive lock holder 116 unloc= king. The file system was usually pretty sick after this :-( Thanks, = Andrew
State Changed From-To: open->feedback Does this problem still occur in newer versions of FreeBSD, such as 4.3-RELEASE?
Adding to Audit-Trail. On Sat, Jul 21, 2001 at 10:13:42PM -0400, parv wrote: > on Jul 21 21:50, i got this from mike... > > Synopsis: when printing through gs: panic: lockmgr: not exclusive lock ho > > > > State-Changed-From-To: open->feedback > > State-Changed-By: mike > > State-Changed-When: Sat Jul 21 18:32:32 PDT 2001 > > State-Changed-Why: > > > > Does this problem still occur in newer versions of FreeBSD, > > such as 4.3-RELEASE? > > > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18024 > > > i am running 4.3-stable, don't know about -release. > > i have printed postscript files from many programs, mainly from > enscript, w/o any problems directly (to lexmark optra e310). > > -- > so, do you like word games or scrabble? > - parv
Hi Mike, The crash does not occur on 4.3-STABLE, but I cannot tell you about -RELEASE. I had examined the problem some time ago and found out that it always happened, when a process opens /dev/lpt0, forks a child, and then terminates before the child exits. Here's a simple perl program which caused the crash on earlier releases (kill lpr before starting it, otherwise /dev/lpt0 is busy): --- printercrash --- #!/usr/bin/perl # open printer device open(PRINTER, "/dev/lpt0") or die "Cannot open /dev/lpt0: $!"; # fork() a child defined(my $pid = fork) or die "Cannot fork: $!"; # parent process exit()s exit 0 if $pid; # child waits until the parent has exited while (getppid != 1) { sleep(1); } # now the child process exit()s exit 0; --- printercrash --- Sorry for sending this program so late, but after changing my printcap/magicfilter, I forgot about the problem ... Greetings, Boris
State Changed From-To: feedback->closed Originator confirmed this is no longer a problem in 4.3-STABLE.