Re: ACPI and a Toshiba Tecra 8000

2003-09-23 Thread Nate Lawson
On Mon, 22 Sep 2003, Andrew Thompson wrote:
> Andrew Thompson wrote:
> > I fixed the other null derefernce in sc_bell() and the laptop is now
> > suspending with the serial console the same as without.
>
> as it should, but the second suspend it only does acpi_SetSleepState()
> -> AcpiEnterSleepStatePrep() and then the laptop suspends itself. I am
> unsure why it is not getting as far the second time...
>
> 
> Breakpoint at   acpi_SetSleepState: pushl   %ebp
> db> c
> Breakpoint at   AcpiEnterSleepStatePrep:pushl   %ebp
> db> c
> 

I'll have to look at your acpidump to have a guess.  It could be that
running the _PTS method causes your laptop to enter suspend the second
time due to an improperly resumed device from the first suspend.

acpidump -t -d > andy.asl

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ACPI and a Toshiba Tecra 8000

2003-09-21 Thread Andrew Thompson
Andrew Thompson wrote:
Nate Lawson wrote:

On Wed, 17 Sep 2003, Andrew Thompson wrote:

It has helped and the laptop is able to suspend with the serial cable
attached (further than before). It now panics on the first resume with
the following (gdb output at bottom).


You should do a quick grep through sys/dev/syscons for
"= sc->cur_scp->index" and replace them all with the above NULL check.
I'm interested if this will fix things.
Hi,

I fixed the other null derefernce in sc_bell() and the laptop is now 
suspending with the serial console the same as without.

Hi again, again,

I am a keen newbie kernel debugger but here is as far as I have got :) 
The first suspend it goes through the functions:

acpi_SetSleepState() -> AcpiEnterSleepStatePrep() -> 
acpi_sleep_machdep() ->  AcpiEnterSleepState()

as it should, but the second suspend it only does acpi_SetSleepState() 
-> AcpiEnterSleepStatePrep() and then the laptop suspends itself. I am 
unsure why it is not getting as far the second time...



db> b acpi_SetSleepState
db> b AcpiEnterSleepStatePrep
db> b acpi_sleep_machdep
db> b AcpiEnterSleepState
db> c

Breakpoint at   acpi_SetSleepState: pushl   %ebp
db> c
Breakpoint at   AcpiEnterSleepStatePrep:pushl   %ebp
db> c
Breakpoint at   acpi_sleep_machdep: pushl   %ebp
db> c
 acpi_printcpu() debug dump 
gdt[0077:c04b94c0] idt[0407:c04b9860] ldt[0028] tr[0020] efl[0096]
eax[1000] ebx[c1234d00] ecx[] edx[bfc4]
esi[] edi[c09f54b0] ebp[c62f3aa8] esp[c62f3a70]
cr0[8005003b] cr2[280b0b40] cr3[01f8c000] cr4[0091]
cs[0008] ds[0010] es[0010] fs[0018] gs[002f] ss[0010]
Breakpoint at   AcpiEnterSleepState:pushl   %ebp
db> c


Breakpoint at   acpi_SetSleepState: pushl   %ebp
db> c
Breakpoint at   AcpiEnterSleepStatePrep:pushl   %ebp
db> c



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ACPI and a Toshiba Tecra 8000

2003-09-21 Thread Andrew Thompson
Nate Lawson wrote:
On Wed, 17 Sep 2003, Andrew Thompson wrote:

It has helped and the laptop is able to suspend with the serial cable
attached (further than before). It now panics on the first resume with
the following (gdb output at bottom).
I think the serial cable is masking the problem as without it I can
suspend/resume once and it only panics on the second resume. I guess I
need the serail working to see that panic anyway.


You should do a quick grep through sys/dev/syscons for
"= sc->cur_scp->index" and replace them all with the above NULL check.
I'm interested if this will fix things.
Hi,

I fixed the other null derefernce in sc_bell() and the laptop is now 
suspending with the serial console the same as without.

Here is the output when I suspend the laptop (S3). After the first 
resume the laptop still works fine. When I suspend the laptop a second 
time no output is displayed but the laptop seems to suspend alright 
(according to the power led), but when it resumes it reboots straight 
away. Again no output on the serial.

Is there more debugging that I can turn on?


 acpi_printcpu() debug dump 
gdt[0077:c04b8ce0] idt[0407:c04b9080] ldt[0028] tr[0020] efl[0096]
eax[1000] ebx[c1234d00] ecx[] edx[bfc4]
esi[] edi[c09f53b0] ebp[c62ffaa8] esp[c62ffa70]
cr0[8005003b] cr2[280b0b40] cr3[0205b000] cr4[0091]
cs[0008] ds[0010] es[0010] fs[0018] gs[002f] ss[0010]

 acpi_printcpu() debug dump 
gdt[0077:c04b8ce0] idt[0407:c04b9080] ldt[0028] tr[0020] efl[0002]
eax[0001] ebx[c1234d00] ecx[8000] edx[c1286980]
esi[] edi[c09f53b0] ebp[c62ffaa8] esp[c62ffa70]
cr0[8005003b] cr2[280b0b40] cr3[0205b000] cr4[0091]
cs[0008] ds[0010] es[0010] fs[0018] gs[002f] ss[0010]
pcib0: slot 4 INTA is routed to irq 11
pcib0: slot 5 INTD is routed to irq 11
pcib0: slot 9 INTA is routed to irq 11
pcib0: slot 11 INTA is routed to irq 11
pcib0: slot 11 INTB is routed to irq 11
wakeup from sleeping state (slept 00:00:27)
ata0: resetting devices ..
acpi_acad0: Notify 0x80
done
ata1: resetting devices ..
done
acpi_cmbat0: battery initialization start
acpi_cmbat0: battery initialization done, tried 1 times
acpi_cmbat1: battery initialization start
acpi_cmbat1: battery initialization failed, giving up


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ACPI and a Toshiba Tecra 8000

2003-09-19 Thread Nate Lawson
On Wed, 17 Sep 2003, Andrew Thompson wrote:
> Nate Lawson wrote:
> > On Wed, 17 Sep 2003, Andrew Thompson wrote:
> >
> >>111 sc_cur_scr = sc->cur_scp->index;
> >
> > For a temporary workaround, try changing line 111 to:
> > if (sc->cur_scp == NULL)
> > return (0);
> >
> > This may not help things though.
>
> It has helped and the laptop is able to suspend with the serial cable
> attached (further than before). It now panics on the first resume with
> the following (gdb output at bottom).
>
> I think the serial cable is masking the problem as without it I can
> suspend/resume once and it only panics on the second resume. I guess I
> need the serail working to see that panic anyway.

You should do a quick grep through sys/dev/syscons for
"= sc->cur_scp->index" and replace them all with the above NULL check.
I'm interested if this will fix things.

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ACPI and a Toshiba Tecra 8000

2003-09-16 Thread Andrew Thompson
Nate Lawson wrote:
On Wed, 17 Sep 2003, Andrew Thompson wrote:

(gdb) l *scsuspend+0x17
0xc03d7b17 is in scsuspend (/usr/src/sys/isa/syscons_isa.c:111).
106 int retry = 10;
107 static int  dummy;
108 sc_softc_t  *sc;
109
110 sc = &main_softc;
111 sc_cur_scr = sc->cur_scp->index;
112
113 if (sc_no_suspend_vtswitch)
114 return (0);
115


For a temporary workaround, try changing line 111 to:
if (sc->cur_scp == NULL)
return (0);
This may not help things though.

It has helped and the laptop is able to suspend with the serial cable 
attached (further than before). It now panics on the first resume with 
the following (gdb output at bottom).

I think the serial cable is masking the problem as without it I can 
suspend/resume once and it only panics on the second resume. I guess I 
need the serail working to see that panic anyway.

tdkphy0: detached
miibus0: detached
dc0: detached
sio4: detached
wakeup from sleeping state (slept 00:00:22)
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x4
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc03aec5d
stack pointer   = 0x10:0xc5e39b0c
frame pointer   = 0x10:0xc5e39b18
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 7 (acpi_task1)
kernel: type 12 trap, code=0
Stopped at  sc_bell+0x2d:   movl0x4(%ecx),%eax
db> tr
sc_bell(0,320,5,f0,0) at sc_bell+0x2d
sc_switch_scr(c04b8ca0,0,c5e39b74,c02677bd,c1279d80) at sc_switch_scr+0x2c5
scresume(c1279d80,c1212060,c0424e7c,c1273f00,c11d4060) at scresume+0x24
bus_generic_resume(c1273f00,c11d4060,c0424e7c,c11d1d50,4d0) at 
bus_generic_resume+0x5d
bus_generic_resume(c1256b00) at bus_generic_resume+0x5d
isab_resume(c1256b00,c11f7060,c0424e7c,c1256b80,c1221060) at 
isab_resume+0x6b
bus_generic_resume(c1256b80,c1221060,c0424e7c,c1256280,c1220060) at 
bus_generic_resume+0x5d
bus_generic_resume(c1256280,c1257110,0,c1256280,c5e39c1c) at 
bus_generic_resume+0x5d
acpi_pcib_resume(c1256280,c1257110,0,c1256280,c5e39c3c) at 
acpi_pcib_resume+0x2a
acpi_pcib_acpi_resume(c1256280,c1220060,c0424e7c,c09f2580,c122b060) at 
acpi_pcib_acpi_resume+0x2a
bus_generic_resume(c09f2580,c122b060,c0424e7c,c09f1400,c120c060) at 
bus_generic_resume+0x5d
bus_generic_resume(c09f1400,c120c060,c0424e7c,0,c1256a00) at 
bus_generic_resume+0x5d
bus_generic_resume(c09f1c80,c118e060,c0424e7c,c09f1c80,7a6bb) at 
bus_generic_resume+0x5d
acpi_SetSleepState(c1256a00,3,c5e39ce0,c057f399,c1256a00) at 
acpi_SetSleepState+0x246
acpi_system_eventhandler_sleep(c1256a00,3,c058af1d,99,c0561d6f) at 
acpi_system_eventhandler_sleep+0x1d
acpi_lid_notify_status_changed(c11d1d10,0,c058be85,7b,0) at 
acpi_lid_notify_status_changed+0xf9
acpi_task_thread(0,c5e39d48,44890142,858d0824,fb94) at 
acpi_task_thread+0x105
fork_exit(c0584b80,0,c5e39d48) at fork_exit+0xb1
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xc5e39d7c, ebp = 0 ---
db>

(gdb) l *sc_bell+0x2d
0xc03aec5d is in sc_bell (/usr/src/sys/dev/syscons/syscons.c:3579).
3574sc_bell(scr_stat *scp, int pitch, int duration)
3575{
3576if (cold || shutdown_in_progress || !enable_bell)
3577return;
3578
3579if (scp != scp->sc->cur_scp && (scp->sc->flags & SC_QUIET_BELL))
3580return;
3581
3582if (scp->sc->flags & SC_VISUAL_BELL) {
3583if (scp->sc->blink_in_progress)
(gdb)


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ACPI and a Toshiba Tecra 8000

2003-09-16 Thread Nate Lawson
On Wed, 17 Sep 2003, Andrew Thompson wrote:
> (gdb) l *scsuspend+0x17
> 0xc03d7b17 is in scsuspend (/usr/src/sys/isa/syscons_isa.c:111).
> 106 int retry = 10;
> 107 static int  dummy;
> 108 sc_softc_t  *sc;
> 109
> 110 sc = &main_softc;
> 111 sc_cur_scr = sc->cur_scp->index;
> 112
> 113 if (sc_no_suspend_vtswitch)
> 114 return (0);
> 115

For a temporary workaround, try changing line 111 to:
if (sc->cur_scp == NULL)
return (0);

This may not help things though.

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ACPI and a Toshiba Tecra 8000

2003-09-16 Thread Nate Lawson
On Wed, 17 Sep 2003, Andrew Thompson wrote:
> Nate Lawson wrote:
> >gdb kernel.debug
> >l *scsuspend+0x17
> >That should show the offending code segment.
>
> (gdb) l *scsuspend+0x17
> 0xc03d7b17 is in scsuspend (/usr/src/sys/isa/syscons_isa.c:111).
> 106 int retry = 10;
> 107 static int  dummy;
> 108 sc_softc_t  *sc;
> 109
> 110 sc = &main_softc;
> 111 sc_cur_scr = sc->cur_scp->index;
> 112
> 113 if (sc_no_suspend_vtswitch)
> 114 return (0);
> 115

Ok, this shows it's not ok to unconditionally deref sc->cur_scp.  Now I'll
look for what cases it is NULL.  I'll get back to you in a day or so.

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ACPI and a Toshiba Tecra 8000

2003-09-16 Thread Andrew Thompson
Nate Lawson wrote:

Please compile your kernel with debug symbols (config -g KERNEL) and load
it into gdb to get the actual line of code that is getting that NULL
deref:
   gdb kernel.debug
   l *scsuspend+0x17
That should show the offending code segment.

 

Hopefully I have done this right :)

(gdb) l *scsuspend+0x17
0xc03d7b17 is in scsuspend (/usr/src/sys/isa/syscons_isa.c:111).
106 int retry = 10;
107 static int  dummy;
108 sc_softc_t  *sc;
109
110 sc = &main_softc;
111 sc_cur_scr = sc->cur_scp->index;
112
113 if (sc_no_suspend_vtswitch)
114 return (0);
115
(gdb)


Andy

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ACPI and a Toshiba Tecra 8000

2003-09-16 Thread Nate Lawson
Please compile your kernel with debug symbols (config -g KERNEL) and load
it into gdb to get the actual line of code that is getting that NULL
deref:

gdb kernel.debug
l *scsuspend+0x17

That should show the offending code segment.

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


ACPI and a Toshiba Tecra 8000

2003-09-16 Thread Andrew Thompson
Hi,

I have -current on my laptop as of yesterdays sources and my suspending 
isnt working quite right.  The first time I suspend (S3) it works and 
comes back to life, but the second time the laptop reboots when it 
resumes. 

I have now build a new kernel with debuging/ddb and hooked up a serial 
cable.  When I boot to the comconsole and try to suspend it panics 
straight away with the following. The asl and dmesg can be found @ 
http://www.fud.org.nz/acpi/



Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc03d7b17
stack pointer   = 0x10:0xc5e7895c
frame pointer   = 0x10:0xc5e78978
code segment= base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 504 (acpiconf)
kernel: type 12 trap, code=0
Stopped at  scsuspend+0x17: movl0(%eax),%eax
db> tr
scsuspend(c1279d80,c1212058,c0424e74,c5e78998,0) at scsuspend+0x17
bus_generic_suspend(c1273f00,c11d4058,c0424e74,c5e789f0,c5e789e0) at 
bus_generic_suspend+0x5d
bus_generic_suspend(c1256b00) at bus_generic_suspend+0x5d
isab_suspend(c1256b00,c11f7058,c0424e74,14f,0) at isab_suspend+0x7b
bus_generic_suspend(c1256b80,c1221058,c0424e74,c058ac58,c5e78a38) at 
bus_generic_suspend+0x5d
bus_generic_suspend(c1256280,c1220058,c0424e74,0,0) at 
bus_generic_suspend+0x5d
bus_generic_suspend(c09f2580,c122b058,c0424e74,c5e78ac3,0) at 
bus_generic_suspend+0x5d
bus_generic_suspend(c09f1400,c120c058,c0424e74,c5e78a98,c1250740) at 
bus_generic_suspend+0x5d
bus_generic_suspend(c09f1c80,c118e058,c0424e74,bfca02d0,74000) at 
bus_generic_suspend+0x5d
acpi_SetSleepState(c1256a00,3,c08fe6a8,c159d124,c5e78b54) at 
acpi_SetSleepState+0xfb
acpiioctl(c047eb40,80045003,c5e78c48,3,c09fb4c0) at acpiioctl+0xc2
spec_ioctl(c5e78b54,c5e78c00,c02b7e31,c5e78b54,c037be77) at spec_ioctl+0x16b
spec_vnoperate(c5e78b54,c037be77,c1599378,80,c082b258) at 
spec_vnoperate+0x18
vn_ioctl(c133894c,80045003,c5e78c48,c1597080,c09fb4c0) at vn_ioctl+0x1a1
ioctl(c09fb4c0,c5e78d10,c,c,3) at ioctl+0x61f
syscall(2f,2f,2f,3,bfbffc5c) at syscall+0x2b0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280bd54f, esp = 
0xbfbffbdc, ebp = 0xbfbffbf8 ---

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"