Re: [HEADSUP] amd64 suspend/resume code to be comitted

On 3/26/09, Coleman Kane <cokane_at_freebsd.org> wrote:
> On Wed, 2009-03-25 at 01:32 +0100, Paul B. Mahol wrote:
>> On 3/24/09, Coleman Kane <cokane_at_freebsd.org> wrote:
>> > On Tue, 2009-03-24 at 20:08 +0100, Gustau Perez wrote:
>> >> Robert Noland wrote:
>> >> > On Tue, 2009-03-24 at 16:21 +0100, Gustau Perez wrote:
>> >> >
>> >> >> Brandon Gooch wrote:
>> >> >>
>> >> >>> On Mon, Mar 16, 2009 at 7:53 PM, Jung-uk Kim <jkim_at_freebsd.org>
>> >> >>> wrote:
>> >> >>>
>> >> >>>
>> >> >>>> On Monday 16 March 2009 07:50 pm, Alexander Motin wrote:
>> >> >>>>
>> >> >>>>
>> >> >>>>> Jung-uk Kim wrote:
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>> With popular demands, I will commit the following patch in next
>> >> >>>>>> few days unless a showstopper is found or "over-my-dead-body"
>> >> >>>>>> type of review is received. ;-)
>> >> >>>>>>
>> >> >>>>>> http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff
>> >> >>>>>>
>> >> >>>>>> FYI, it was originally posted here:
>> >> >>>>>>
>> >> >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim
>> >> >>>>>>
>> >> >>>>>> and here:
>> >> >>>>>>
>> >> >>>>>> http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim
>> >> >>>>>>
>> >> >>>>>> Please read the original threads for more information about the
>> >> >>>>>> patch.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>> Have just retested this with just updated 8-CURRENT. Still works
>> >> >>>>> fine as before with my Acer TM6292
>> >> >>>>> (Core2Duo+i965GM+ICH8M+bge+iwn+sdhci amd64 SMP). Writing this
>> >> >>>>> letter just after successful resume.
>> >> >>>>>
>> >> >>>>> There is still some DRI resume problems (will try one rnoland_at_
>> >> >>>>> patch tomorrow) and my touch pad does not wakes up for some
>> >> >>>>> reason,
>> >> >>>>> but that is probably unrelated.
>> >> >>>>>
>> >> >>>>>
>> >> >>>> I went ahead and committed slightly different version.  Please
>> >> >>>> resync
>> >> >>>> the source if you tested the old version.
>> >> >>>>
>> >> >>>> Cheers,
>> >> >>>>
>> >> >>>> Jung-uk Kim
>> >> >>>> _______________________________________________
>> >> >>>> freebsd-current_at_freebsd.org mailing list
>> >> >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> >> >>>> To unsubscribe, send any mail to
>> >> >>>> "freebsd-current-unsubscribe_at_freebsd.org"
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>    Hi there,
>> >> >>
>> >> >>    in my Latitude D630 with 8-0 current updated this morning (+1
>> >> >> UTC)
>> >> >> it
>> >> >> seems is trying to work. It has no xorg, just text console.
>> >> >>
>> >> >
>> >> > The D630 should have an Intel 965GM in it with suspend/resume support
>> >> > in
>> >> > drm, so X *should* be good to go.
>> >> >
>> >> > robert.
>> >> >
>> >> >
>> >>    Hi Roland,
>> >>
>> >>    this one comes with an nvidia Quadro NVS 135M (I think they made two
>> >> o three different models). It was possible to customize them via web.
>> >> My
>> >> mistake was to choose an nvidia (well, I've been able to play nice
>> >> games
>> >> with it, but now it's giving me a lot of headaches).
>> >>
>> >>    With this model (without X's, just text console) suspending and
>> >> resuming seems to work except the video. I can type thing and send them
>> >> to a file (checked). After resuming, it throws a little of text (i can
>> >> see some debug about suspending and resuming firewire and usb) and then
>> >> video is lost. With if_bge within the kernel I don't get that
>> >> semi-successful result. It starts complaining about PHY read/write
>> >> timeout so I have it as a module.
>> >>
>> >>   Offtopic :  In the other hand right now I'm going to try the patch
>> >> you
>> >> sent to use nouveau in i386 mode (not amd64, I have a separate
>> >> partition
>> >> for amd64) with libdrm and xf86-video-nouveau.I tried inserting the .ko
>> >> before leaving to home (and I worked). Will let you now my results in
>> >> the Take two thread :)
>> >>
>> >>    Greets,
>> >>
>> >>    Gus
>> >>
>> >
>> > I've been seeing the exact same problem that you are with the if_bge
>> > driver (including jkim's earlier patches). Does it do this for anyone
>> > using i386? I have not been able to make this work for me no matter what
>> > I try. Have you managed to get if_bge working after a resume? Could I be
>> > CC'd on any patches that might solve this problem in the future?
>> >
>> > if_bge has a strange bootstrapping sequence which I think might be core
>> > to the problem. It seems that you are supposed to write a value to a
>> > register, then wait for that register to read something else before
>> > proceeding (yes, I've simplified the actual sequence of steps). This
>> > process complicates debugging the hardware, and I've been unsuccessful
>> > in trying to simply kldunload if_bge and then saving/restoring the PCI
>> > register space before/after suspend/resume... Any insight would be
>> > helpful. Maybe I should browse the Linux kernel commit logs for this one
>> > and see if it bit them too...
>> >
>> > I also see that there is some issue that breaks NDIS on resume as well,
>> > but I am not sure why at the moment.
>>
>> I would say that there is no any real support for NDISulator after
>> resume. It is NDISulator bug.
>> Workarodund is to unload module before suspend and load it again after
>> resume, and device must be in D3 state before suspending
>> (hw.pci.do_power_nodriver=3)
>>
>
> I have this set in my /boot/loader.conf, and I verified that it is still
> set by running "sysctl hw.pci.do_power_nodriver" after boot.
>
> In rc.suspend, I've got (to unload the modules before suspend):
> kldunload if_bge
> kldunload ndis
> kldunload if_ndis
>
> I get the exact same behavior (not working) from bge and ndis no matter
> what I try. I manually re-load the modules after resume, and neither
> will work.
>
> Attached is the dmesg output of bge0 during the process. You can see
> where the system unloads the driver (detached), and then where I re-load
> the driver.
>
> Any ideas?

In my case I need to load some another kernel device module(the one
that resumes correctly ...) otherwise devices without driver attached
would not be put back into D3 state.

eg, in my case I unload snd_hda and load it again _before_ suspend.

With "pciconf -lvc" you can inspect device power states.

-- 
Paul