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

[Joel Newkirk]

On Thu, 7 May 2009 18:31:39 +0200
Davide Scaini <dscaini at gmail.com> wrote:

> I am searching for a really olg 2.6.28 kernel... (and not a .28
> mispelled that in fact it's a .29...) where can i find it? (I'm
> talking about something of the mid april...)
> thanks
> d
> 
> Ps: wifi worked nicely on that, i just used
> some /etc/network/interfaces files and getted eth0 up from
> shr-setting panel... now it semms that with .29 kernels the interface
> is not really "responding" and i get kernel panics when insisting on
> ifup ifdown eth0 [sorry i can't be more precise since i haven't found
> the point where it breaks]

I stuffed the April 14th kernel and modules up on my server, you can
pull them from
http://newkirk.us/om/testing/uImage-2.6.28-oe1+gitr119785+2bea5c68313577b214b872b0edc5968db0cf3b68-r3.2-om-gta02.bin
http://newkirk.us/om/testing/modules-2.6.28-oe1+gitr119785+2bea5c68313577b214b872b0edc5968db0cf3b68-r3.2-om-gta02.tgz

I'll leave them there through the weekend if your or anyone wants them.

j


> 2009/5/7 Vasco Névoa <vasco.nevoa at sapo.pt>
> 
> > 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
> > >
> >
> >
> > _______________________________________________
> > Openmoko community mailing list
> > community at lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> >