On Thu, 7 May 2009 18:31:39 +0200 Davide Scaini <dsca...@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.ne...@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 <fercer...@gmail.com>: > > > > > Vasco Nevoa <vasco.ne...@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:fercer...@gmail.com > > > > > > > > > _______________________________________________ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community