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>