Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Oct 2006 13:00:48 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Nate Lawson <nate@root.org>
Cc:        freebsd-acpi@freebsd.org, Andrea Bittau <a.bittau@cs.ucl.ac.uk>, freebsd-mobile@freebsd.org
Subject:   Re: hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP]
Message-ID:  <200610031300.49509.jhb@freebsd.org>
In-Reply-To: <45218C97.5050802@root.org>
References:  <20060921000628.GA1832@shorty.sorbonet.org> <200610021424.18562.jhb@freebsd.org> <45218C97.5050802@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 02 October 2006 18:03, Nate Lawson wrote:
> John Baldwin wrote:
> > On Wednesday 20 September 2006 20:06, Andrea Bittau wrote:
> >> This is a half working hack for getting suspend/resume to "work" on an 
IBM
> >>
> >> ...
> >>
> >> 2) apic.  FreeBSD reconfigures the io apic upon resume, but not the local 
> > apic.
> >>    The patch attached to this mail fixes this.  Indeed, it almost does so 
in 
> > the
> >>    "proper" way and not so much of a hack =D.
> > 
> > I actually have made a full patch for APIC I think (thanks for your work 
as it 
> > reminded me about needing to resume lapic).  You can find it at 
> > http://www.FreeBSD.org/~jhb/patches/apic_resume.patch  It changes the x86 
> > interrupt code to resume interrupt controllers, not interrupt sources.  It 
> > then uses this to make sure the 8259A PICs are properly reset on resume as 
> > well as resuming the local APIC.  Can you test this w/o SMP and make sure 
it 
> > works?
> 
> Great to see this work going on.  I just got a Core Duo laptop so this 
> would be great to see fixed.
> 
> I'm kinda disappointed you're not using newbus for your device methods, 
> but I think I mentioned that before.

I'll do that once we have multi-pass device probing, but for now we need to 
make sure interrupts are working before we start resuming other devices.

> On the reset code, shouldn't there be some delays between writes to the 
> registers?
> 
> +	outb(IO_ICU1, ICW1_RESET | ICW1_IC4);
> +	outb(IO_ICU1 + ICU_IMR_OFFSET, IDT_IO_INTS);
> [delay?]
> +	outb(IO_ICU1 + ICU_IMR_OFFSET, 1 << 2);
> [delay?]
> +	outb(IO_ICU1 + ICU_IMR_OFFSET, ICW4_8086);
> [delay?]
> +	outb(IO_ICU1 + ICU_IMR_OFFSET, 0xff);
> +	outb(IO_ICU1, OCW3_SEL | OCW3_RR);
> +
> +	outb(IO_ICU2, ICW1_RESET | ICW1_IC4);
> +	outb(IO_ICU2 + ICU_IMR_OFFSET, IDT_IO_INTS + 8);
> [delay?]
> +	outb(IO_ICU2 + ICU_IMR_OFFSET, 2);
> [delay?]
> +	outb(IO_ICU2 + ICU_IMR_OFFSET, ICW4_8086);
> [delay?]
> +	outb(IO_ICU2 + ICU_IMR_OFFSET, 0xff);
> +	outb(IO_ICU2, OCW3_SEL | OCW3_RR);

Note that I just ripped this code out from amd64/amd64/machdep.c where there 
are no delays.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610031300.49509.jhb>