Date: Thu, 26 Mar 2009 15:01:14 +0100 From: "Paul B. Mahol" <onemda@gmail.com> To: Coleman Kane <cokane@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted Message-ID: <3a142e750903260701p6d72342bme841c2ff3f64ea95@mail.gmail.com> In-Reply-To: <1238074249.1834.6.camel@localhost> References: <1236802980.00085518.1236789602@10.7.7.3> <49BEE5BC.30703@FreeBSD.org> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <49C8FA92.7020104@entel.upc.edu> <1237920918.1859.1.camel@balrog.2hip.net> <49C92FA6.20608@entel.upc.edu> <1237926289.1735.17.camel@localhost> <3a142e750903241732p3a7bc0a6k9810c5c8bb14eea@mail.gmail.com> <1238074249.1834.6.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/26/09, Coleman Kane <cokane@freebsd.org> wrote: > On Wed, 2009-03-25 at 01:32 +0100, Paul B. Mahol wrote: >> On 3/24/09, Coleman Kane <cokane@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@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@ >> >> >>>>> 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@freebsd.org mailing list >> >> >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> >>>> To unsubscribe, send any mail to >> >> >>>> "freebsd-current-unsubscribe@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3a142e750903260701p6d72342bme841c2ff3f64ea95>