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...)<br>thanks<br>d<br><br>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]<br>
<br><div class="gmail_quote">2009/5/7 Vasco Névoa <span dir="ltr"><<a href="mailto:vasco.nevoa@sapo.pt">vasco.nevoa@sapo.pt</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thanks, Paul.<br>
I ended up upgrading from shr-testing to shr-unstable, and the<br>
problems are gone.<br>
So, the non-functional kernel+g_ether must have been:<br>
<a href="http://shr.bearstech.com/shr-testing/images/om-gta02/uImage-2.6.28-stable+gitr0e5fe639e234cdeb11d8441f19c5b3109a8b6a17-r2-om-gta02.bin" target="_blank">http://shr.bearstech.com/shr-testing/images/om-gta02/uImage-2.6.28-stable+gitr0e5fe639e234cdeb11d8441f19c5b3109a8b6a17-r2-om-gta02.bin</a><br>
And the current working one is:<br>
<a href="http://shr.bearstech.com/shr-unstable/images/om-gta02/uImage-2.6.29-oe10+gitr119805+f656a97d946a2529630c9770a72c10a24dc397f9-r3.4-om-gta02.bin" target="_blank">http://shr.bearstech.com/shr-unstable/images/om-gta02/uImage-2.6.29-oe10+gitr119805+f656a97d946a2529630c9770a72c10a24dc397f9-r3.4-om-gta02.bin</a><br>
<br>
I was just surprised to see the problem getting fixed and lost and<br>
refixed at least 2 times in a row. It feels like someone made a patch<br>
and it just doesn't stick - maybe it didn't make it upstream and<br>
sometimes it isn't appllied? I don't know the kernel source stream<br>
from vanilla down to SHR, so I'm talking out of my... imagination. ;)<br>
Anyway, I'm glad it is solved, and I hope it doesn't come back so<br>
easily again.<br>
<br>
Citando Paul Fertser <<a href="mailto:fercerpav@gmail.com">fercerpav@gmail.com</a>>:<br>
<div><div></div><div class="h5"><br>
> Vasco Nevoa <<a href="mailto:vasco.nevoa@sapo.pt">vasco.nevoa@sapo.pt</a>> writes:<br>
>>> Why don't you just specify which kernel revision works and which<br>
>>> doesn't? How any kernel dev is supposed to solve your problems if you<br>
>>> even don't properly describe it? Why don't you use the kernel that<br>
>>> worked on your FR in the meantime?<br>
>>><br>
>>><br>
>> If I knew, I wouldn't have a problem, would I? :)<br>
><br>
> At least you know the date (and the place you downloaded) the kernel<br>
> had no problems and the problematic revision you use now, but you<br>
> don't specify it.<br>
><br>
> The kernel commit that finally fixed RNDIS issues was<br>
> f63e59c84aa21d2745f115209bf949eca27008b1 and it was added to<br>
> andy-tracking branch on Mar 16. I don't see anything related since<br>
> then. Since you don't specify what revision you use now, i'm unable to<br>
> even say if your rev includes the commit or not.<br>
><br>
> --<br>
> Be free, use free (<a href="http://www.gnu.org/philosophy/free-sw.html" target="_blank">http://www.gnu.org/philosophy/free-sw.html</a>) software!<br>
> mailto:<a href="mailto:fercerpav@gmail.com">fercerpav@gmail.com</a><br>
><br>
<br>
<br>
_______________________________________________<br>
Openmoko community mailing list<br>
<a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a><br>
<a href="http://lists.openmoko.org/mailman/listinfo/community" target="_blank">http://lists.openmoko.org/mailman/listinfo/community</a><br>
</div></div></blockquote></div><br>