NetBSD Problem Report #46225

From petar@starling.smokva.net  Mon Mar 19 03:42:43 2012
Return-Path: <petar@starling.smokva.net>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 61DAD63B946
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 19 Mar 2012 03:42:43 +0000 (UTC)
Message-Id: <20120319024611.BA0E417830A0@starling.smokva.net>
Date: Mon, 19 Mar 2012 03:46:11 +0100 (CET)
From: Petar Bogdanovic <petar@smokva.net>
To: gnats-bugs@gnats.NetBSD.org
Subject: printing to /dev/lpt0 hangs in lptwrite(), probably lptwrite2
X-Send-Pr-Version: 3.95

>Number:         46225
>Category:       kern
>Synopsis:       printing to /dev/lpt0 hangs in lptwrite(), probably lptwrite2
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Mar 19 03:45:00 +0000 2012
>Last-Modified:  Sat Mar 24 17:05:02 +0000 2012
>Originator:     Petar Bogdanovic
>Release:        NetBSD 6.0_BETA (16.03.2012)
>Organization:
>Environment:
	amd64
>Description:
	Since upgrading from 5.99.54 to 6.0_BETA, my parallel printer
	stopped working.  A process writing to /dev/lpt0 (cups or cat)
	ends up waiting forever in lptwrite(), probably lptwrite2.

	$ ident /netbsd-5.99.54 | grep lpt
	     $NetBSD: lpt.c,v 1.78 2009/11/25 14:28:50 rmind Exp $
	     $NetBSD: lpt_isa.c,v 1.68 2009/11/23 02:13:47 rmind Exp $
	     $NetBSD: lpt_puc.c,v 1.14 2008/03/07 17:15:52 cube Exp $
	     $NetBSD: ulpt.c,v 1.86 2011/03/29 07:48:13 mbalmer Exp $

	$ ident /netbsd-6.0_BETA | grep lpt
	     $NetBSD: lpt.c,v 1.78 2009/11/25 14:28:50 rmind Exp $
	     $NetBSD: lpt_isa.c,v 1.68 2009/11/23 02:13:47 rmind Exp $
	     $NetBSD: lpt_puc.c,v 1.14 2008/03/07 17:15:52 cube Exp $
	     $NetBSD: ulpt.c,v 1.88 2011/12/23 00:51:47 jakllsch Exp $

>How-To-Repeat:
	Write to /dev/lpt0 while running 6.0_BETA.
>Fix:
	none

>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46225: printing to /dev/lpt0 hangs in lptwrite(), probably
 lptwrite2
Date: Mon, 19 Mar 2012 03:51:06 +0000

 On Mon, Mar 19, 2012 at 03:45:00AM +0000, Petar Bogdanovic wrote:
  > 	Since upgrading from 5.99.54 to 6.0_BETA, my parallel printer
  > 	stopped working.  A process writing to /dev/lpt0 (cups or cat)
  > 	ends up waiting forever in lptwrite(), probably lptwrite2.
  > 
  > 	$ ident /netbsd-5.99.54 | grep lpt
  > 	     $NetBSD: lpt.c,v 1.78 2009/11/25 14:28:50 rmind Exp $
  > 	     $NetBSD: lpt_isa.c,v 1.68 2009/11/23 02:13:47 rmind Exp $
  > 	     $NetBSD: lpt_puc.c,v 1.14 2008/03/07 17:15:52 cube Exp $
  > 	     $NetBSD: ulpt.c,v 1.86 2011/03/29 07:48:13 mbalmer Exp $
  > 
  > 	$ ident /netbsd-6.0_BETA | grep lpt
  > 	     $NetBSD: lpt.c,v 1.78 2009/11/25 14:28:50 rmind Exp $
  > 	     $NetBSD: lpt_isa.c,v 1.68 2009/11/23 02:13:47 rmind Exp $
  > 	     $NetBSD: lpt_puc.c,v 1.14 2008/03/07 17:15:52 cube Exp $
  > 	     $NetBSD: ulpt.c,v 1.88 2011/12/23 00:51:47 jakllsch Exp $

 How is lpt0 attached? isa? Or is it an ulpt?

 It's somewhat odd that it would stop working without being changed...

 -- 
 David A. Holland
 dholland@netbsd.org

From: Petar Bogdanovic <petar@smokva.net>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/46225: printing to /dev/lpt0 hangs in lptwrite(), probably
 lptwrite2
Date: Mon, 19 Mar 2012 05:20:55 +0100

 On Mon, Mar 19, 2012 at 03:55:02AM +0000, David Holland wrote:
 >
 >  How is lpt0 attached? isa? Or is it an ulpt?

 	$ dmesg | grep lpt
 	lpt0 at isa0 port 0x378-0x37b irq 7


 >  It's somewhat odd that it would stop working without being changed...

 It's so odd that I switched kernels twice just to make sure it was no
 fluke.


 BTW: ps(1) told me that every /dev/lpt0 writer hangs in lptwrit, which
 I assume is the truncated version of `lptwrite2' somewhere in lpt.c.

 Also interesting: The LED on the printer that indicates incoming jobs,
 turns on as soon as a writer enters lptwrite()/lptwrite2.

From: Petar Bogdanovic <petar@smokva.net>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/46225: printing to /dev/lpt0 hangs in lptwrite(), probably
 lptwrite2
Date: Tue, 20 Mar 2012 02:05:43 +0100

 Quick follow-up, it seems like it's not entirely broken, just dead-slow.
 The reason is probably that 6.0_BETA somehow doesn't trigger the lpt
 interrupt handler lptintr anymore (not once) so it runs only about four
 times per second due to lptwakeup and its HZ/4 timeout/callout.

From: Petar Bogdanovic <petar@smokva.net>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/46225: printing to /dev/lpt0 hangs in lptwrite(), probably
 lptwrite2
Date: Tue, 20 Mar 2012 20:11:42 +0100

 It seems like both tpm(4) and lpt(4) were claiming the same irq:

     lpt0 at isa0 port 0x378-0x37b irq 7
     tpm0 at isa0 iomem 0xfed40000-0xfed44fff irq 7: IFX SLB 9635 TT 1.2 rev 0x10

 so I disabled tpm* and lptintr was running again, which means that
 my printer works fine now.

 Perhaps it would be wise to drop tpm(4) from GENERIC---at least in
 netbsd-6.

 Thanks,

 		Petar Bogdanovic

From: Martin Husemann <martin@duskware.de>
To: Petar Bogdanovic <petar@smokva.net>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/46225: printing to /dev/lpt0 hangs in lptwrite(), probably lptwrite2
Date: Tue, 20 Mar 2012 23:00:34 +0100

 On Tue, Mar 20, 2012 at 08:11:42PM +0100, Petar Bogdanovic wrote:
 > Perhaps it would be wise to drop tpm(4) from GENERIC---at least in
 > netbsd-6.

 Or at least remove the "irq 7" part of the attachement - according to its
 manual page, the default mode should be "polled", but i386/amd64 GENERIC
 kernels configure it with interrupt handler instead.

 Martin

From: Petar Bogdanovic <petar@smokva.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46225: printing to /dev/lpt0 hangs in lptwrite(), probably
 lptwrite2
Date: Tue, 20 Mar 2012 23:22:17 +0100

 On Tue, Mar 20, 2012 at 10:05:03PM +0000, Martin Husemann wrote:
 >
 > Or at least remove the "irq 7" part of the attachement - according to its
 > manual page, the default mode should be "polled", but i386/amd64 GENERIC
 > kernels configure it with interrupt handler instead.

 Seems to work and I can print too:

     lpt0 at isa0 port 0x378-0x37b irq 7
     tpm0 at isa0 iomem 0xfed40000-0xfed44fff irq : IFX SLB 9635 TT (...)

From: christos@zoulas.com (Christos Zoulas)
To: Petar Bogdanovic <petar@smokva.net>, gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, 
	netbsd-bugs@netbsd.org
Subject: Re: kern/46225: printing to /dev/lpt0 hangs in lptwrite(), probably lptwrite2
Date: Tue, 20 Mar 2012 18:24:49 -0400

 On Mar 20,  8:11pm, petar@smokva.net (Petar Bogdanovic) wrote:
 -- Subject: Re: kern/46225: printing to /dev/lpt0 hangs in lptwrite(), probab

 | It seems like both tpm(4) and lpt(4) were claiming the same irq:
 | 
 |     lpt0 at isa0 port 0x378-0x37b irq 7
 |     tpm0 at isa0 iomem 0xfed40000-0xfed44fff irq 7: IFX SLB 9635 TT 1.2 rev 0x10
 | 
 | so I disabled tpm* and lptintr was running again, which means that
 | my printer works fine now.
 | 
 | Perhaps it would be wise to drop tpm(4) from GENERIC---at least in
 | netbsd-6.

 Or see if the interrupt handler can be fixed.

 christos

From: Petar Bogdanovic <petar@smokva.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46225: printing to /dev/lpt0 hangs in lptwrite(), probably
 lptwrite2
Date: Tue, 20 Mar 2012 23:59:18 +0100

 On Tue, Mar 20, 2012 at 10:25:07PM +0000, Christos Zoulas wrote:
 >
 > Or see if the interrupt handler can be fixed.

 lptintr or tpm_intr?  I was rather looking into intr.c with INTRDEBUG
 defined but the table from intr_printconfig didn't seem complete so I
 gave up:

     (...)
     cpu0 source 0 is pin 9 from pic ioapic0 maxlevel 6
             handler 0xffffffff80454aa1 level 6
     cpu0 source 1 is pin 19 from pic ioapic0 maxlevel 6
             handler 0xffffffff80454aa1 level 6
     cpu0 source 2 is pin 20 from pic ioapic0 maxlevel 6
             handler 0xffffffff80454aa1 level 6
             handler 0xffffffff80454aa1 level 6
             handler 0xffffffff80454aa1 level 6
     cpu0 source 3 is pin 21 from pic ioapic0 maxlevel 7
             handler 0xffffffff80320828 level 7
             handler 0xffffffff80454aa1 level 6
             handler 0xffffffff80454aa1 level 6
     cpu0 source 4 is pin 22 from pic ioapic0 maxlevel 6
             handler 0xffffffff80454aa1 level 6
     cpu0 source 5 is pin 14 from pic ioapic0 maxlevel 6
             handler 0xffffffff80454aa1 level 6
     cpu0 source 6 is pin 15 from pic ioapic0 maxlevel 6
             handler 0xffffffff80454aa1 level 6
     cpu0 source 7 is pin 7 from pic ioapic0 maxlevel 6
             handler 0xffffffff80454aa1 level 6
             handler 0xffffffff80454aa1 level 6
     cpu0 source 8 is pin 4 from pic ioapic0 maxlevel 8
             handler 0xffffffff8024d493 level 8
     cpu0 source 9 is pin 6 from pic ioapic0 maxlevel 6
             handler 0xffffffff80454aa1 level 6
     (...)

 When looked up in ddb, all addresses point to some unrelated handlers
 but none of them to lptintr or tpm_intr (no matter if tpm was enabled
 or not).

 What was interesting though is that intr_printconfig didn't list any
 interrupt masks for cpu0 when lpt and tpm were enabled, both at irq 7.
 With tpm disabled, the listing returned:

     cpu0: interrupt masks:
     IPL 0 mask 1fffc00 unmask fe0003ff
     IPL 1 mask 3fffc00 unmask fc0003ff
     IPL 2 mask 7fffc00 unmask f80003ff
     IPL 3 mask ffffc00 unmask f00003ff
     IPL 4 mask 1ffffc00 unmask e00003ff
     IPL 5 mask 3ffffc00 unmask c00003ff
     IPL 6 mask 3ffffeff unmask c0000100
     IPL 7 mask 7ffffeff unmask 80000100
     IPL 8 mask ffffffff unmask 0

 Thats when I figured out I'm floating in the ocean.

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46225: printing to /dev/lpt0 hangs in lptwrite(), probably
 lptwrite2
Date: Sat, 24 Mar 2012 17:04:03 +0000

 On Tue, Mar 20, 2012 at 07:15:04PM +0000, Petar Bogdanovic wrote:
  >  so I disabled tpm* and lptintr was running again, which means that
  >  my printer works fine now.
  >  
  >  Perhaps it would be wise to drop tpm(4) from GENERIC---at least in
  >  netbsd-6.

 I thought tpm was supposed to be disabled by default.

 -- 
 David A. Holland
 dholland@netbsd.org

Home	PR Database Search