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

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)

-- 
Paul