From owner-acpi-jp@jp.FreeBSD.org Wed Nov 27 07:56:51 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id gAQMupU02009;
	Wed, 27 Nov 2002 07:56:51 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id gAQMuo202004
	for <acpi-jp@jp.FreeBSD.org>; Wed, 27 Nov 2002 07:56:51 +0900 (JST)
	(envelope-from jhb@FreeBSD.org)
Received: (qmail 12028 invoked from network); 26 Nov 2002 22:56:57 -0000
Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63])
          (envelope-sender <jhb@FreeBSD.org>)
          by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP
          for <acpi-jp@jp.FreeBSD.org>; 26 Nov 2002 22:56:57 -0000
Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4])
	by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id gAQMuluH014291;
	Tue, 26 Nov 2002 17:56:47 -0500 (EST)
	(envelope-from jhb@FreeBSD.org)
Message-ID: <XFMail.20021126175652.jhb@FreeBSD.org>
X-Mailer: XFMail 1.5.2 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.BSF.4.21.0211261251520.86771-100000@root.org>
From: John Baldwin <jhb@freebsd.org>
To: Nate Lawson <nate@root.org>
Cc: acpi-jp@jp.FreeBSD.org
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Tue, 26 Nov 2002 17:56:52 -0500
X-Sequence: acpi-jp 1992
Subject: [acpi-jp 1992] RE: panic from acpiconf -s 4
Errors-To: owner-acpi-jp@jp.FreeBSD.org
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: jhb@FreeBSD.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+021111


On 26-Nov-2002 Nate Lawson wrote:
> On Tue, 26 Nov 2002, John Baldwin wrote:
>> On 26-Nov-2002 Nate Lawson wrote:
>> > While trying to suspend my IBM T23, I ran into a panic.  "acpiconf -s" for
>> > values 1,2,3 does nothing (failing with "acpi0: AcpiGetSleepTypeData
>> > failed - AE_NOT_FOUND").  But acpiconf -s 4 panics. 
>> > 
>> > scsuspend(c3352600,c32cf058,c03f4d6c,c3335d80,0) at scsuspend+0x17
>> > bus_generic_suspend(c3335480,c324d058,c03f4d6c,c3336080,e399b9f0) at bus_generic_suspend+0x5b
>> > bus_generic_suspend(c3331200) at bus_generic_suspend+0x5b
>> > isab_suspend(c3331200,c3299058,c03f4d6c,c36917c0,0) at isab_suspend+0x5c
>> > bus_generic_suspend(c3331080,c32e4058,c03f4d6c,c32eb058,c11d4600) at bus_generic_suspend+0x5b
>> > bus_generic_suspend(c11d4580,c32e3058,c03f4d6c,0,0) at bus_generic_suspend+0x5b
>> > bus_generic_suspend(c3305280,c32cc058,c03f4d6c,e399bad2,0) at bus_generic_suspend+0x5b
>> > bus_generic_suspend(c11d3c00,c32ac058,c03f4d6c,e399baa8,c3324140) at bus_generic_suspend+0x5b
>> > bus_generic_suspend(c11d3e80,c11c3058,c03f4d6c,c03cd283,6060668) at bus_generic_suspend+0x5b
>> > acpi_SetSleepState(c3305200,4,c35ef000,c36b2940,e399bb5c) at acpi_SetSleepState+0x106
>> > acpiioctl(c0442200,80045003,e399bc54,3,c35ef000) at acpiioctl+0xb2
>> > spec_ioctl(e399bb5c,e399bc28,c02c12f1,e399bb5c,e399bb70) at spec_ioctl+0x16e
>> > spec_vnoperate(e399bb5c,e399bb70,c02589bd,c04477e0,c03f43a0) at spec_vnoperate+0x18
>> > vn_ioctl(c3420d20,80045003,e399bc54,c36aed00,c35ef000) at vn_ioctl+0x1a1
>> > ioctl(c35ef000,e399bd10,c03ebece,407,3) at ioctl+0x4b6
>> > syscall(2f,2f,2f,4,3) at syscall+0x28e
>> > 
>> > Perhaps I should try SC_NO_SUSPEND_VTYSWITCH ?
>> 
>> Well, fixing the bug in scsuspend() would be good.  Can you include
>> the actual panic message (I think it's a kernel trap 12 with a fault
>> address of 0x0?  i.e. a NULL pointer deref) and compile a kernel
>> with -g, and use gdb to locate the offending line number?
> 
> It is a null pointer deref.
>  
>> (e.g. in this case gdb -k kernel.debug ; l *scsuspend+0x17 would do
>>  the trick)
> 
> Heh, tables are turned -- I'm always telling others to do that.  In this
> case, something is hosed with my kernel debug build.  I used "make
> buildkernel CONFIGARGS=-g" when I built it and kernel.debug appears in
> compile/LAPTOP.  However, gdb can't find the files to print the line
> number, even when I explicitly do "dir /sys:/sys/kern".  file(1) tells me
> that kernel.debug is not stripped so I have no clue what to look for next.  
> kernel.debug is only 4 megs, which is suspiciously small (it's normally
> 20 megs).  Ideas?

Don't use make buildkernel. :)  I don't use it at least. :)

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
