Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Mar 2009 09:30:49 -0400
From:      Coleman Kane <cokane@FreeBSD.org>
To:        "Paul B. Mahol" <onemda@gmail.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: [HEADSUP] amd64 suspend/resume code to be comitted
Message-ID:  <1238074249.1834.6.camel@localhost>
In-Reply-To: <3a142e750903241732p3a7bc0a6k9810c5c8bb14eea@mail.gmail.com>
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>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

--=-uTDqcNHk7nJPUzN6NM5r
Content-Type: multipart/mixed; boundary="=-STKx1gEJh86K8kqzmQDH"


--=-STKx1gEJh86K8kqzmQDH
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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> wr=
ote:
> >> >>>
> >> >>>
> >> >>>> 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 reas=
on,
> >> >>>>> but that is probably unrelated.
> >> >>>>>
> >> >>>>>
> >> >>>> I went ahead and committed slightly different version.  Please re=
sync
> >> >>>> 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 UT=
C)
> >> >> 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 suppor=
t 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 tw=
o
> >> 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 gam=
es
> >> 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 the=
m
> >> 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 the=
n
> >> 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 y=
ou
> >> sent to use nouveau in i386 mode (not amd64, I have a separate partiti=
on
> >> for amd64) with libdrm and xf86-video-nouveau.I tried inserting the .k=
o
> >> 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 wha=
t
> > I try. Have you managed to get if_bge working after a resume? Could I b=
e
> > 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 on=
e
> > 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.
>=20
> 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=3D3)
>=20

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?

--=20
Coleman Kane

--=-STKx1gEJh86K8kqzmQDH
Content-Disposition: attachment; filename="bge-dmesg.txt"
Content-Transfer-Encoding: base64
Content-Type: text/plain; name="bge-dmesg.txt"; charset="UTF-8"

YmdlMDogPEJyb2FkY29tIEJDTTU3NTQvNTc4NyBBMiwgQVNJQyByZXYuIDB4YjAwMj4gbWVtIDB4
ZDAwMDAwMDAtMHhkMDAwZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxNg0KYmdlMDog
RXRoZXJuZXQgYWRkcmVzczogMDA6MWE6NGI6NzQ6Mzk6OTYNCmJnZTA6IFtJVEhSRUFEXQ0KYmdl
MDogZGV0YWNoZWQNCmJnZTA6IDxCcm9hZGNvbSBCQ001NzU0LzU3ODcgQTIsIEFTSUMgcmV2LiAw
eGIwMDI+IG1lbSAweGQwMDAwMDAwLTB4ZDAwMGZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24g
cGNpMTYNCmJnZTA6IGZpcm13YXJlIGhhbmRzaGFrZSB0aW1lZCBvdXQsIGZvdW5kIDB4NGI2NTc2
NTQNCmJnZTA6IGZpcm13YXJlIGhhbmRzaGFrZSB0aW1lZCBvdXQsIGZvdW5kIDB4NGI2NTc2NTQN
CmJnZTA6IFBIWSByZWFkIHRpbWVkIG91dCAocGh5IDEsIHJlZyAxLCB2YWwgMHhmZmZmZmZmZikN
CmJnZTA6IFRyeSBhZ2Fpbg0KYmdlMDogUEhZIHdyaXRlIHRpbWVkIG91dCAocGh5IDEsIHJlZyAw
LCB2YWwgMzI3NjgpDQpiZ2UwOiBQSFkgcmVhZCB0aW1lZCBvdXQgKHBoeSAxLCByZWcgMSwgdmFs
IDB4ZmZmZmZmZmYpDQpiZ2UwOiBUcnkgYWdhaW4NCmJnZTA6IFBIWSB3cml0ZSB0aW1lZCBvdXQg
KHBoeSAxLCByZWcgMCwgdmFsIDMyNzY4KQ0KYmdlMDogUEhZIHJlYWQgdGltZWQgb3V0IChwaHkg
MSwgcmVnIDEsIHZhbCAweGZmZmZmZmZmKQ0KYmdlMDogVHJ5IGFnYWluDQpiZ2UwOiBQSFkgd3Jp
dGUgdGltZWQgb3V0IChwaHkgMSwgcmVnIDAsIHZhbCAzMjc2OCkNCmJnZTA6IFBIWSByZWFkIHRp
bWVkIG91dCAocGh5IDEsIHJlZyAxLCB2YWwgMHhmZmZmZmZmZikNCmJnZTA6IFRyeSBhZ2Fpbg0K
YmdlMDogUEhZIHdyaXRlIHRpbWVkIG91dCAocGh5IDEsIHJlZyAwLCB2YWwgMzI3NjgpDQpiZ2Uw
OiBQSFkgcmVhZCB0aW1lZCBvdXQgKHBoeSAxLCByZWcgMSwgdmFsIDB4ZmZmZmZmZmYpDQpiZ2Uw
OiBNSUkgd2l0aG91dCBhbnkgUEhZIQ0K


--=-STKx1gEJh86K8kqzmQDH--

--=-uTDqcNHk7nJPUzN6NM5r
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEABECAAYFAknLg4YACgkQcMSxQcXat5fM/ACfTKnkUWN8I0WcoWZHqmhzkhj1
9VwAniShyMIgZUe/6oXULANNV628ofHG
=3jv+
-----END PGP SIGNATURE-----

--=-uTDqcNHk7nJPUzN6NM5r--




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?1238074249.1834.6.camel>