Parallel port printing crashes 7.0 system

Tue Sep 25 04:28:23 PDT 2007

25.09.07, 13:07, Kris Kennaway (kris at FreeBSD.org):

> S.N.Grigoriev wrote:
> > Hi, list,
> > 
> > This problem has already been reported this year at least twice.
> > I can confirm it still exists. Probably it has been introduced
> > near the beginning of May because April and earlyer sources
> > handle parallel printing correctly.
> So we can cross-reference, what number is your PR?
> Kris

Hi, Kris,

The following messages posted to freebsd-current@
this year:

On Wen May 16 I wrote:

> From: S.N.Grigoriev <serguey-grigoriev at yandex.ru> 
> To: freebsd-current at freebsd.org
> Subject: Crash during sending print jobs
>
> Hi,
>
> beginning with last week my 7-Current amd64 system panics
> during sending print jobs (especially PostScript) to my
> LPT connected laser printer. Kernels compiled with April
> or March sources still work fine. Does anybody find this
> problem?

On Mon, Jun 4 I wrote:

> The problem persists. GENERIC compiled with today sources
> crashes with the following output:

> panic: bad stray interrupt
> cpuid = 0
> KDB: enter: panic
> [thread pid = 11 tid 100002 ]
> Stopped at kdb_enter+0x2f: leave
>
>
> The call stack trace is:
>
> Tracing pid 11 tid 100002 td 0xffffff003db84990
> kdb_enter() at kdb_enter+0x30
> intr_execute_handlers() at intr_execute_handlers+0x183
> Xapic_isr1() at Xapic_isr1()+0x7f
> --- interrupt, rip = 0xffffffff8071ec56, rsp = 0xffffffffa075fbd0, rbp > = 0xffffffffa075fbe0 ---
> acpi_cpu_c1() at acpi_cpu_c1+0x6
> acpi_cpu_idle() at acpi_cpu_idle+0x27c
> sched_idletd() at sched_idletd+0x35
> fork_exit() at fork_exit+0x153
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffffffa075fd30, rbp = 0 ---

On Tue Jul 3 Gary Jennejohn wrote:

> Date:      Tue, 3 Jul 2007 11:42:48 +0200
> From:      Gary Jennejohn <garyj at jennejohn.org>
> To:        freebsd-current at freebsd.org
> Subject:   panic when printing
> Message-ID:  <20070703114248.37a2019b.garyj at jennejohn.org>
> 
> I haven't seen this reported before.
>
> Trying to print to my parallel printer with a -current kernel from July
> 2 (amd64) results in a kernel panic. A kernel from June 16 (i386) does
> not cause a panic.
>
> If I boot with the printer turned on then the kernel sees it (PnP)
> with no problem. Just printing causes a panic.
>
> BTW this kernel is using the SMP-scheduler from Jeff Roberson, but
> IIRC a different kernel (June 29) w/o that scheduler also panics.
>
> I can't say whether it's amd64-specific or just due to recent changes to
> the sources. I'm rather reluctant to generate a new i386 kernel to check
> that, but I could be persuaded to do it.
>
> Below a typescript of a very limited kgdb session:
>
> root:peedub:crash:bash:1> gdb /boot/kernel/kernel vmcore.1
> [GDB will not be able to debug user-mode
> threads: /usr/lib/libthread_db.so: Undefined symbol
> "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free
> Software Foundation, Inc. GDB is free software, covered by the GNU
> General Public License, and you are welcome to change it and/or
> distribute copies of it under certain conditions. Type "show copying"
> to see the conditions. There is absolutely no warranty for GDB.  Type
> "show warranty" for details. This GDB was configured as
> "amd64-marcel-freebsd".
>
> Unread portion of the kernel message buffer:
> lpt0: [GIANT-LOCKED]
> lpt0: [ITHREAD]
> lpt0: [GIANT-LOCKED]
> lpt0: [ITHREAD]
> lpt0: [GIANT-LOCKED]
> lpt0: [ITHREAD]
> lpt0: [GIANT-LOCKED]
> lpt0: [ITHREAD]
> lpt0: [GIANT-LOCKED]
> lpt0: [ITHREAD]
> lpt0: [GIANT-LOCKED]
> lpt0: [ITHREAD]
> lpt0: [GIANT-LOCKED]
> lpt0: [ITHREAD]
> lpt0: [GIANT-LOCKED]
> lpt0: [ITHREAD]
> lpt0: [GIANT-LOCKED]
> lpt0: [ITHREAD]
>
>
> Fatal trap 30: reserved (unknown) fault while in kernel mode
> cpuid = 1; apic id = 01
> instruction pointer	= 0x8:0xffffffff804ece83
> stack pointer	        = 0x10:0xffffffffaf97a760
> frame pointer	        = 0x10:0xffffffffaf97a780
> code segment		= base 0x0, limit 0xfffff, type 0x1b
>			= DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags	= interrupt enabled, IOPL = 0
> current process		= 1980 (lpd)
> trap number		= 30
> panic: reserved (unknown) fault
> cpuid = 1
> Uptime: 2h41m43s
> Physical memory: 2037 MB
> Dumping 977 MB: 961 945 929 913 897 881 865 849 833 817 801 785 769 753
> 737 721 705 689 673 657 641 625 609 593 577 561 545 529 513 497 481 465
> 449 433 417 401 385 369 353 337 321 305 289 273 257 241 225 209 193 177
> 161 145 129 113 97 81 65 49 33 17 1
>
> #0  doadump () at pcpu.h:194
> 194	pcpu.h: No such file or directory.
>	in pcpu.h
> (kgdb) bt
> #0  doadump () at pcpu.h:194
> #1  0xffffffff802f94db in boot (howto=260)
>    at /usr/src/sys/kern/kern_shutdown.c:409
> #2  0xffffffff802f97de in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:563
> #3  0xffffffff804fec9c in trap_fatal (frame=0xffffffffaf97a6b0, eva=0)
>     at /usr/src/sys/amd64/amd64/trap.c:695
> #4  0xffffffff804ffaa3 in trap (frame=0xffffffffaf97a6b0)
>    at /usr/src/sys/amd64/amd64/trap.c:498
> #5  0xffffffff804e566e in calltrap ()
>    at /usr/src/sys/amd64/amd64/exception.S:169
> #6  0xffffffff804ece83 in spinlock_exit () at cpufunc.h:391
> #7  0xffffffff804e9291 in ioapic_program_intpin
> #(intpin=0xffffff0001043208)
>     at /usr/src/sys/amd64/amd64/io_apic.c:273
> #8  0xffffffff804e967a in ioapic_disable_intr (isrc=0xffffff0001043208)
>    at /usr/src/sys/amd64/amd64/io_apic.c:375
> #9  0xffffffff804e843d in intr_remove_handler (cookie=Variable "cookie"
> #is not available.
> )
>    at /usr/src/sys/amd64/amd64/intr_machdep.c:217
> #10 0xffffffff804f23bc in nexus_teardown_intr (dev=Variable "dev" is
> #not available.
> )
>    at /usr/src/sys/amd64/amd64/nexus.c:451
> #11 0xffffffff8031bf8f in bus_generic_teardown_intr
> #(dev=0xffffffffabf30000, 
>    child=0xffffff0003285b00, irq=0xffffff0003316480, 
>    cookie=0xffffff001bf44100) at bus_if.h:416
> #12 0xffffffff8022fc9d in ppc_teardown_intr (bus=0xffffff0001216500, 
>     child=0xffffff0003285b00, r=0xffffff0003316480,
> ih=0xffffff001bf44100) at bus_if.h:416
> #13 0xffffffff8022e3f4 in ppbus_teardown_intr (bus=0xffffff0003286e00, 
>    child=0xffffff0003285b00, r=Variable "r" is not available.
> ) at bus_if.h:416
> #14 0xffffffff8022ef6a in ppb_release_bus (bus=0xffffff0003286e00, 
>     dev=0xffffff0003285b00) at bus_if.h:416
> #15 0xffffffff8022a9a5 in lpt_release_ppbus (dev=0xffffff0003285b00)
>    at /usr/src/sys/dev/ppbus/lpt.c:227
> #16 0xffffffff8022b796 in lptwrite (dev=Variable "dev" is not available.
> ) at /usr/src/sys/dev/ppbus/lpt.c:826
> #17 0xffffffff802c6f61 in giant_write (dev=0xffffff00032fe800, 
>    uio=0xffffffffaf97ab00, ioflag=0)
> at /usr/src/sys/kern/kern_conf.c:358
> #18 0xffffffff8028b9f7 in devfs_write_f (fp=0xffffff0003b092d0, 
>    uio=0xffffffffaf97ab00, cred=Variable "cred" is not available.
> ) at /usr/src/sys/fs/devfs/devfs_vnops.c:1290
> #19 0xffffffff8033058a in dofilewrite (td=0xffffff00039c5360, fd=6, 
>    fp=0xffffff0003b092d0, auio=0xffffffffaf97ab00, offset=Variable
> "offset" is not available. ) at file.h:254
> #20 0xffffffff8033080f in kern_writev (td=0xffffff00039c5360, fd=6, 
>    auio=0xffffffffaf97ab00) at /usr/src/sys/kern/sys_generic.c:373
> #21 0xffffffff8033088b in write (td=0xffffffffabf30000, uap=0x1e)
>    at /usr/src/sys/kern/sys_generic.c:303
> #22 0xffffffff804ff2d1 in syscall (frame=0xffffffffaf97ac70)
>    at /usr/src/sys/amd64/amd64/trap.c:820
> #23 0xffffffff804e581b in Xfast_syscall ()
>    at /usr/src/sys/amd64/amd64/exception.S:272
> #24 0x000000080071ccac in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb) q
>
> --- 
> Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg

On Mon, 23 Jul John Baldwin <jhb at freebsd.org> wrote:

> On Tuesday 03 July 2007 05:42:48 am Gary Jennejohn wrote:
> > I haven't seen this reported before.
> > 
> > Trying to print to my parallel printer with a -current kernel from
> > July 2 (amd64) results in a kernel panic. A kernel from June 16
> > (i386) does not cause a panic.
> > 
> > If I boot with the printer turned on then the kernel sees it (PnP)
> > with no problem. Just printing causes a panic.
> > 
> > BTW this kernel is using the SMP-scheduler from Jeff Roberson, but
> > IIRC a different kernel (June 29) w/o that scheduler also panics.
> > 
> > I can't say whether it's amd64-specific or just due to recent
> > changes to the sources. I'm rather reluctant to generate a new i386
> > kernel to check that, but I could be persuaded to do it.
> > 
> > Below a typescript of a very limited kgdb session:
> 
> You got an interrupt after the lpt driver removed its handler.
> Really the ppbus device should not be so stupid and should have its
> own interrupt handler that routes interrupts to the "active" child.
> 

Regards,
Serguey.