Hi
On 8.01.2016 04:26, Tony Lindgren wrote:
Yes it seems there's some other issue too. Maybe you can run git bisect
again and carry the fix along as an extra patch?
No sane way to bisect, I don't really know what triggers the issue.
Neither it is triggered regularly. It might happen on the first reboot
or on the tenth, or ... And it looks like the problems happens sometimes
on oops too. Not to say that it seems I should have fully booted
userspace (so there is enough pressure on the ubi/mdt/nand subsystems),
which is impossible with upstream without some n900 specific patches :(
Maybe we can get some ideas on what and where to look from ubifs people?
Though I don't know whom to cc, feel free to help :)
My best bet aiui, is comparing what nokia omap1 kernel does vs upstream.
Or looking at the commit log in ubi/mtd/onenand - who knows, I might get
lucky once again the same way as with that phonet oops in
__netif_receive_skb_core.
OK then it really seems like we do have another bug lurking around.
:nod:
Maybe you can figure out an easier way to reproduce it?
I doubt, but who knows.
The problem is that between NOLO and kernel there is u-boot. And even if I
am almost sure it doesn't touch onenand configs, I can't be absolutely sure.
So those timings are not 100% reliable IMO, though close to that.
Hmm yes I'm only booting with u-boot here as my device sits in my rack.
I booted the device via flasher with initrd from the so-called rescueos
(https://n900.quitesimple.org/rescueOS/rescueOS-1.2/) - it provides
shell with tons of useful tools if your device is in bootloop etc. CS0
registers were the same as with u-boot, so it is not that one.
OK will push it out then.
Thanks,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
