10:44 <perul> dv_: any news about your changes to the patch of bfederau?

10:44 <perul> please let me know if I can help and/or test.

10:48 <dv_> perul: yes. I just pushed the updates

10:48 <dv_> please check if the fix still works

10:51 <perul> ok, I'll let you know

10:52 <dv_> perul: regarding the mem allocator error, what kernel were you using?

11:05 <dv_> in fact, please provide me a full dmesg output

11:15 <perul> mom

11:17 <perul> http://pastebin.com/64pXBcra

11:20 <perul> afk

12:25 <perul> So kernel version 3.0.35. We got this from the OEM and have little chance of updating, because we would need to migrate to device tree

12:44 <dv_> I meant up to the point when the error happens, not just the booting :)

12:44 <perul> ah ok, sorry :)

12:58 <perul> Here you go: http://pastebin.com/avFQ3ZFC

13:15 <dv_> perul: try out these two wandboard kernel patches: https://github.com/wandboard-org/linux/commit/b65ef76276775ed1781f7a767610f52d7939cf86 https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233

14:04 <perul> dv_: the patch of bfederau seems to have the same effect after your modifications. The SW does not hang and I also see the same two bugs already mentioned.

14:04 <perul> I'll try out the two kernel patches now.

16:39 <rz2k> perul: stop using that OEM (advantech) or demand update or chargebacks will appear. these guys wont do anything until you have them in corner. your bsp seems to be compiled at January (!), do something about this or you'll be stuck with updating everything by hand.

16:40 <rz2k> I've got sooo fed up with technexion crap on my previous job :)

16:44 <perul> I know it is frustrating. Mgmt already knows the situation and implications, especially risk.

17:32 <aholler> all an oem should have to do is to provide a correct dts.

17:41 <rz2k> aholler: that is when it is a simple SBC, but when you have hardcore SBC with tons of stuff done in external crappy drivers aimed for platformdevice kernels or a SoM type of system, you will have a lot of struggle, which should be taken care of by OEM itself

17:41 <rz2k> not by you

17:46 <aholler> I won't, the soc-manufacturer or arm should be responsible to provide drivers

17:47 <aholler> they decided which ip to use

17:48 <aholler> most arm boards don't contain much besides the soc

17:49 <jas-hacks> My experience the ODM/OEM expects the devs to do the donkey work.

17:50 <aholler> yes, but it isn't there fault. oems don't have the resources nor the knowledge to write drivers

17:51 <aholler> as said, drivers should be written by the people responsible for the stuff a driver is necessary. most other people don't even have the necessary documentation.

17:56 <aholler> the problem is that most arm-soc-builders are hw-people without much knowledge about sw. That worked in old 74xx times, but is a problem today ;)

18:07 <aholler> if I would have to rely on drivers from asus, dell, or similiar I likely would have stopped to use any pc. ;)