Call for bge(4) testers

[Gonzalo Nemmi]

On Monday 16 November 2009 3:54:50 pm Pyun YongHyeon wrote:
> On Mon, Nov 16, 2009 at 03:34:33PM -0200, Gonzalo Nemmi wrote:
> > On Sunday 15 November 2009 11:58:16 pm Pyun YongHyeon wrote:
> > > On Thu, Nov 12, 2009 at 08:39:31PM -0200, Gonzalo Nemmi wrote:
> > > > On Thursday 12 November 2009 8:05:50 pm Pyun YongHyeon wrote:
> > > > > On Thu, Nov 12, 2009 at 07:12:44PM -0200, Gonzalo Nemmi wrote:
> > > > > > On Thursday 12 November 2009 1:47:49 am Pyun YongHyeon 
wrote:
> > > > > > > On Wed, Nov 11, 2009 at 02:37:51PM -0800, Pyun YongHyeon
> >
> > wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I had been working on fixing bus_dma(9) bugs and adding
> > > > > > > > TSO capability to bge(4). Now TSO is supported for
> > > > > > > > BCM5755 or newer controllers. Actually some pre-BCM5755
> > > > > > > > controllers also support TSO with the help of special
> > > > > > > > firmware but the license issue and lower performance of
> > > > > > > > firmware based TSO as well as TSO bug I intentionally
> > > > > > > > excluded TSO support for pre-BCM5755 controllers. You
> > > > > > > > can get the patch form the following URL. The diff was
> > > > > > > > generated against latest HEAD.
> > > > > > > >
> > > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111.dif
> > > > > > > >f
> > > > > > >
> > > > > > > Eh, there was a typo so I regenerated the diff.
> > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111-1.dif
> > > > > > >f
> > > > > >
> > > > > > Hi
> > > > > > Just wanted to know before getting on to it, will your
> > > > > > patch help to resolve kern/136876?
> > > > >
> > > > > My diff includes a fix for assuming PCIe device control
> > > > > register and MSI control registers would be reside in fixed
> > > > > address. And from the pciconf output I see the your MSI
> > > > > control register is located at different address. However
> > > > > bge(4) does not touch that register for BCM5906 so I guess my
> > > > > diff may not fix the resume issue.
> > > >
> > > > Thanks a lot for your prompt, clear and straight answer.
> > >
> > > Would you try attached patch for BCM5906 resume issue? Not sure
> > > whether it help or not though.
> >
> > Hi Pyun!
> > Sorry for the delay, I was out of town and just got back.
> > I'm downloading RC3 as of now. Then I will install:
> > edit make.conf
> > edit src.conf
> > buildworld
> > buildkernel
> > installkernel
> > reboot
> >
> > mergemaster -p
> > make installworld
> > reboot
> >
> > cp bge.diff bge.patch
> > cd /usr/src/sys/dev/bge && patch < /path/to/patch
> > make
> > make install clean
> > kldunload if_bge
>
> Not sure you removed bge in GENERIC kernel configuration file.
>
> > kldload if_bge
> > pciconf -lcvb
> > ifconfig bge0 up
> > acpiconf -s3
> >
> > ... and hpefully .. resume from S3 ..
> >
> > Is that ok with you or would you like me to do it in another way?
>
> That's ok. At first I wanted to add WOL to wake up bge(4) with
> magic packet but bge(4) seems to require a lot of workaround for
> each controller and it's too complex to implement at this time.
> Just want to know whether bge(4) can resume from suspend.

Well, I proceeded as I told you I would, applied your patch and even if 
it didn't solve the problem (bge still doesn't resume) at least it 
improved the previous situation given that now it doesn't loop timing 
out once and again as before.

You can find a tail from /var/log/messages in here:
http://pastebin.com/f643555f7

As you can see, the first 3 lines corresponds to "kldload if_bge"
Line number 4 is "acpiconf -s3"

At line number 17 bge0 finally fails and let's the machine wake up at 
line 18.

Then, as soon as I could I issued a "ifconfig bge0" to see what I could 
get .. that's what you can see from line 20 to line 41. (as you can see 
in there, I found there are problems resuming umass devices as 
well ... )

Line 42 to 53 correspond to "kldnuload if_bge" .. which, by the way, 
once unloaded, I could load it again but bge0 never showed 
on "ifconfig".

Line 54 till the end correspond to "umount_msdos /dev/ad0s1" ... which 
ended with pulling the pendrive out as the system coldn't umount it ...

I also found I get wpi0 messages on resume .. it spouts:
wpi0 could not lock memory
wpi0 could not lock memory
wpi0 could not lock memory
wpi0 could not lock memory
wpi0 could not lock memory
wpi0 could not lock memory
wpi0 could not lock memory
and then it let's the system resume.

All in all  .. there's _a_lot_of_problems_on_resume_ 


Pyun, if you'd like me to try a new patch or to do some tests or 
whatever, just let me know. I'm here awaiting orders :)

Best Regards
Gonzalo Nemmi