Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Sep 2005 10:14:19 -0400
From:      John Baldwin <jhb@FreeBSD.org>
To:        Nate Lawson <nate@root.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/dev/bge if_bge.c
Message-ID:  <200509301014.21572.jhb@FreeBSD.org>
In-Reply-To: <433C441A.8050508@root.org>
References:  <20050928192056.B7E6D16A42B@hub.freebsd.org> <200509291406.19775.jhb@FreeBSD.org> <433C441A.8050508@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 29 September 2005 03:44 pm, Nate Lawson wrote:
> John Baldwin wrote:
> > On Thursday 29 September 2005 01:49 pm, Nate Lawson wrote:
> >>John Baldwin wrote:
> >>>On Wednesday 28 September 2005 04:36 pm, Nate Lawson wrote:
> >>>>I've heard disabling apic helps T42s, otherwise they get a hard hang.
> >>>>It's difficult to print the driver progress while suspending because
> >>>> the function call stack is recursive, not iterative.  For example,
> >>>> root_suspend -> pci_suspend -> fxp_suspend -> mii_suspend (if that
> >>>> exists).  You'd have to add a printf in every driver and bus.  A
> >>>> better way might be to add printf or KTR to bus_generic_suspend() to
> >>>> print the device name before calling its method.
> >>>>
> >>>>BTW, I'm working on committing a patch that adds KTR to acpi so we can
> >>>>track down issues like this although the device suspending stuff should
> >>>>be done separately as listed above.
> >>>
> >>>BTW, the issue with APIC on some systems is that when we use the APIC,
> >>>the current code doesn't end up doing suspend/resume for the ATPIC and
> >>> so it ends up in some random state.
> >>
> >>Ah, is a fix for that upcoming?  :)
> >
> > It's in my head.  I think I need to rework the suspend/resume support in
> > the x86 interrupt code to instead of doing all the interrupt sources,
> > having the atpic and apic code register pic devices in a separate list
> > that gets iterated on suspend and resume.
>
> I think that makes sense since they have different programming methods.
>   Does it make sense to separate them into different newbus devices as
> well, so you get proper ordering?

Getting interrupt controllers into new-bus is a far-off goal I think.  It 
needs all that multipass stuff in place first.

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



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