NetBSD Problem Report #24872

Received: (qmail 3539 invoked by uid 605); 22 Mar 2004 04:40:50 -0000
Message-Id: <20040322044048.0BF7811159@narn.netbsd.org>
Date: Mon, 22 Mar 2004 04:40:48 +0000 (UTC)
From: kazu@iijlab.net
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: kazu@iijlab.net
To: gnats-bugs@gnats.NetBSD.org
Subject: can't resume if gnome is used
X-Send-Pr-Version: www-1.0

>Number:         24872
>Category:       kern
>Synopsis:       can't resume if auich is used
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Mar 22 04:41:00 +0000 2004
>Closed-Date:    
>Last-Modified:  Sun Jul 07 20:50:01 +0000 2019
>Originator:     Kazu Yamamoto
>Release:        NetBSD 1.6ZK
>Organization:
IIJ
>Environment:
NetBSD caster.iij.ad.jp 1.6ZK NetBSD 1.6ZK (GENERIC_LAPTOP) #0: Wed Mar 17 15:12:30 JST 2004  kazu@caster.iij.ad.jp:/usr/src/sys/arch/i386/compile/GENERIC_LAPTOP i386
>Description:
I'm using ThinkPad X30 + NetBSD 1.6ZK + XFree 86 ver 4.4.0.

If I use windowmaker as a window manager, NetBSD can suspend/resume.

However, if I use Gnome installed with pkgsrc, NetBSD cannot resume correctly. It can suspend, and when I open my laptop, it displays
Gnome but no keyboard/mouse events are accepted.

The same problem occurs when I use windowmaker and executes xine. If xine
is running (playing nothing, just xine window is displayed), NetBSD cannot
resume correctly.
>How-To-Repeat:
Install gnome onto a laptop. And close the laptop to suspend NetBSD.
Then open the laptp to resume NetBSD.
>Fix:

>Release-Note:
>Audit-Trail:
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <kazu@iijlab.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/24872
Date: Wed, 10 Nov 2004 22:13:01 +0900 (JST)

 It appears that this is the same problem as:
 	http://mail-index.netbsd.org/port-i386/2004/03/16/0005.html

 Removing the volume control, ThinkPad can resume with Gnome.

 Thus, I guess this is a bug of the driver for /dev/mixer0.

 dmesg says as follows:

 auich0 at pci0 dev 31 function 5: i82801CA (ICH3) AC-97 Audio
 auich0: interrupting at irq 11
 auich0: ac97: Analog Devices AD1981A codec; headphone, 20 bit DAC, no 3D stereo
 auich0: ac97: ext id 601<AC97_22,AMAP,VRA>

 --Kazu Yamamoto
Responsible-Changed-From-To: pkg-manager->kern-bug-people
Responsible-Changed-By: wiz@netbsd.org
Responsible-Changed-When: Tue, 15 Mar 2005 16:14:57 +0000
Responsible-Changed-Why:
kernel bug (auich)


State-Changed-From-To: open->feedback
State-Changed-By: jmcneill@NetBSD.org
State-Changed-When: Wed, 24 Dec 2008 19:07:13 +0000
State-Changed-Why:
Is this still an issue?


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 15 Nov 2009 01:03:30 +0000
State-Changed-Why:
Feedback timeout. Anyone know the state of suspend/resume wrt auich(4)?


Responsible-Changed-From-To: kern-bug-people->nat
Responsible-Changed-By: nat@NetBSD.org
Responsible-Changed-When: Tue, 27 Jun 2017 00:44:30 +0000
Responsible-Changed-Why:
Take.


Responsible-Changed-From-To: nat->kern-bug-people
Responsible-Changed-By: nat@NetBSD.org
Responsible-Changed-When: Wed, 08 May 2019 21:46:04 +0000
Responsible-Changed-Why:


From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/24872 (can't resume if auich is used)
Date: Sun, 7 Jul 2019 20:46:59 +0000

 On Sun, Nov 15, 2009 at 01:03:30AM +0000, dholland@NetBSD.org wrote:
  > Synopsis: can't resume if auich is used
  > 
  > State-Changed-From-To: feedback->open
  > State-Changed-By: dholland@NetBSD.org
  > State-Changed-When: Sun, 15 Nov 2009 01:03:30 +0000
  > State-Changed-Why:
  > Feedback timeout. Anyone know the state of suspend/resume wrt auich(4)?

 Some notes since I just looked a bit:

  - auich has had suspend/resume hooks since long before this PR was
 filed; that isn't the problem.

  - a maybe-similar problem was filed in 39652, for which a patch was
 applied and then reverted with the recommendation to use
 PCI_ADDR_FIXUP instead. However, 39652 is still open.

  - I don't think we'll be able to say for sure that the original
 problem is fixed without the original submitter's hw, so at this point
 criteria for closing the PR are probably showing (a) suspend works at
 all with auich and (b) suspend still works if the audio device is
 open.

 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:

Home	PR Database Search