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_at_ 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.Received on Tue Sep 25 2007 - 09:28:23 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:18 UTC