[shr-testing] kernel with working g_ether to Windoze connection?

[Vasco Névoa]

Thanks, Paul.
I ended up upgrading from shr-testing to shr-unstable, and the  
problems are gone.
So, the non-functional kernel+g_ether must have been:
http://shr.bearstech.com/shr-testing/images/om-gta02/uImage-2.6.28-stable+gitr0e5fe639e234cdeb11d8441f19c5b3109a8b6a17-r2-om-gta02.bin
And the current working one is:
http://shr.bearstech.com/shr-unstable/images/om-gta02/uImage-2.6.29-oe10+gitr119805+f656a97d946a2529630c9770a72c10a24dc397f9-r3.4-om-gta02.bin

I was just surprised to see the problem getting fixed and lost and  
refixed at least 2 times in a row. It feels like someone made a patch  
and it just doesn't stick - maybe it didn't make it upstream and  
sometimes it isn't appllied? I don't know the kernel source stream  
from vanilla down to SHR, so I'm talking out of my... imagination. ;)  
Anyway, I'm glad it is solved, and I hope it doesn't come back so  
easily again.

Citando Paul Fertser <fercerpav at gmail.com>:

> Vasco Nevoa <vasco.nevoa at sapo.pt> writes:
>>> Why don't you just specify which kernel revision works and which
>>> doesn't? How any kernel dev is supposed to solve your problems if you
>>> even don't properly describe it? Why don't you use the kernel that
>>> worked on your FR in the meantime?
>>>
>>>
>> If I knew, I wouldn't have a problem, would I? :)
>
> At least you know the date (and the place you downloaded) the kernel
> had no problems and the problematic revision you use now, but you
> don't specify it.
>
> The kernel commit that finally fixed RNDIS issues was
> f63e59c84aa21d2745f115209bf949eca27008b1 and it was added to
> andy-tracking branch on Mar 16. I don't see anything related since
> then. Since you don't specify what revision you use now, i'm unable to
> even say if your rev includes the commit or not.
>
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercerpav at gmail.com
>