Re: [linux-sunxi] Current u-boot crashes my cubietruck!
Hi, On 04/07/2014 10:54 PM, Olliver Schinagl wrote: On 04/02/2014 10:31 AM, Hans de Goede wrote: Hi, On 04/01/2014 10:45 PM, Olliver Schinagl wrote: Top Posting! I found the culprit. FAST_MBUS breaks it. After 48 hours of runs, enabling fast_mbus immediately breaks it even after boot. Jens and Emilio hinted that the 3.4 driver reads the FEX file for the voltage. So the higher freq. runs at a lower voltage and that may cause it. That is an interesting theory, which should be easy to verify. When you've some time can you edit the fex file and change dcdc3_vol to 1300 in there, generate a new script.bin and give that a try with a u-boot with FAST_MBUS enabled ? So I'll run without fast mbus for now, and it's stable again. Rock Solid if I may. Sorry for all the noise :( No need to be sorry this is very valuable info! Either we need to revert FAST_MBUS support or update dcdc3_vol in all fex files for boards which have FAST_MBUS set. I did change the dcdc3_voltage in the fex files, but it didn't change a thing unfortunately. I think I only mentioned that on IRC ... So my board seems to dislike FAST_MBUS. The only thing I want to try in a while, is bumping the voltage even more, 1.35V or 1.4V So maybe we should disable FAST_MBUS by default then, at least on the cubietruck? IMHO stability is much more important then squeezing out the last bits of performance. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 04/02/2014 10:31 AM, Hans de Goede wrote: Hi, On 04/01/2014 10:45 PM, Olliver Schinagl wrote: Top Posting! I found the culprit. FAST_MBUS breaks it. After 48 hours of runs, enabling fast_mbus immediately breaks it even after boot. Jens and Emilio hinted that the 3.4 driver reads the FEX file for the voltage. So the higher freq. runs at a lower voltage and that may cause it. That is an interesting theory, which should be easy to verify. When you've some time can you edit the fex file and change dcdc3_vol to 1300 in there, generate a new script.bin and give that a try with a u-boot with FAST_MBUS enabled ? So I'll run without fast mbus for now, and it's stable again. Rock Solid if I may. Sorry for all the noise :( No need to be sorry this is very valuable info! Either we need to revert FAST_MBUS support or update dcdc3_vol in all fex files for boards which have FAST_MBUS set. I did change the dcdc3_voltage in the fex files, but it didn't change a thing unfortunately. I think I only mentioned that on IRC ... So my board seems to dislike FAST_MBUS. The only thing I want to try in a while, is bumping the voltage even more, 1.35V or 1.4V Olliver Regards, Hans Olliver On 03/30/2014 08:56 PM, Olliver Schinagl wrote: On 03/30/2014 05:59 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 14:26 +0200, Olliver Schinagl wrote: That said the sorts of random crashed you've been posting sound a lot like either a DRAM issue or overheating. Either of which could be down to u-boot setting up something wrong or bad hardware I suppose. Overheating, maybe. It feels hottish to the touch, but can hold a finger on it without any problem whatsoever. Not close to the pain point. So I estimate 50 C? Shouldn't be reason to be concerned imo. Doesn't sound like it. Power might be the problem, i see the input voltage under heavy load drop to 4.65 Volts @ 0.9 amps Could be that. Have you checked the checksum of the tarball you are extracting and tried unpacking it on a known good system? The sha1sum matches, calculated on the board, so that's good. xz -d completed successfully! tar xvf fails however, with a big ass 5 page long oops. I'd have thought that xz -d would be *far* more CPU intensive and therefore liable to cause issues than tar xvf. If you were using spinning rust rather than an SSD then I would be inclined to suspect the power draw, but with you using an SSD I'm just not sure. I agree! though even a heavily stressed CPU doesn't change power draw hugely. Ssvb and I did some power tests a few months ago on the list. Additionally! I should mention, my CT has a battery backup which should be near full charge. a 1220 mAh battery, so even if the power supply should drop to low or something, Wens assured me that the battery would take over and no problem should be caused by bad power. Unless the battery has run down of course, which I highly doubt, especially seeing the constant current draw over USB. So for now, I just hope it's not user error ... Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
Hi, On 04/01/2014 10:45 PM, Olliver Schinagl wrote: Top Posting! I found the culprit. FAST_MBUS breaks it. After 48 hours of runs, enabling fast_mbus immediately breaks it even after boot. Jens and Emilio hinted that the 3.4 driver reads the FEX file for the voltage. So the higher freq. runs at a lower voltage and that may cause it. That is an interesting theory, which should be easy to verify. When you've some time can you edit the fex file and change dcdc3_vol to 1300 in there, generate a new script.bin and give that a try with a u-boot with FAST_MBUS enabled ? So I'll run without fast mbus for now, and it's stable again. Rock Solid if I may. Sorry for all the noise :( No need to be sorry this is very valuable info! Either we need to revert FAST_MBUS support or update dcdc3_vol in all fex files for boards which have FAST_MBUS set. Regards, Hans Olliver On 03/30/2014 08:56 PM, Olliver Schinagl wrote: On 03/30/2014 05:59 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 14:26 +0200, Olliver Schinagl wrote: That said the sorts of random crashed you've been posting sound a lot like either a DRAM issue or overheating. Either of which could be down to u-boot setting up something wrong or bad hardware I suppose. Overheating, maybe. It feels hottish to the touch, but can hold a finger on it without any problem whatsoever. Not close to the pain point. So I estimate 50 C? Shouldn't be reason to be concerned imo. Doesn't sound like it. Power might be the problem, i see the input voltage under heavy load drop to 4.65 Volts @ 0.9 amps Could be that. Have you checked the checksum of the tarball you are extracting and tried unpacking it on a known good system? The sha1sum matches, calculated on the board, so that's good. xz -d completed successfully! tar xvf fails however, with a big ass 5 page long oops. I'd have thought that xz -d would be *far* more CPU intensive and therefore liable to cause issues than tar xvf. If you were using spinning rust rather than an SSD then I would be inclined to suspect the power draw, but with you using an SSD I'm just not sure. I agree! though even a heavily stressed CPU doesn't change power draw hugely. Ssvb and I did some power tests a few months ago on the list. Additionally! I should mention, my CT has a battery backup which should be near full charge. a 1220 mAh battery, so even if the power supply should drop to low or something, Wens assured me that the battery would take over and no problem should be caused by bad power. Unless the battery has run down of course, which I highly doubt, especially seeing the constant current draw over USB. So for now, I just hope it's not user error ... Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 08:56 PM, Olliver Schinagl wrote: On 03/30/2014 05:59 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 14:26 +0200, Olliver Schinagl wrote: That said the sorts of random crashed you've been posting sound a lot like either a DRAM issue or overheating. Either of which could be down to u-boot setting up something wrong or bad hardware I suppose. Overheating, maybe. It feels hottish to the touch, but can hold a finger on it without any problem whatsoever. Not close to the pain point. So I estimate 50 C? Shouldn't be reason to be concerned imo. Doesn't sound like it. Power might be the problem, i see the input voltage under heavy load drop to 4.65 Volts @ 0.9 amps Could be that. Have you checked the checksum of the tarball you are extracting and tried unpacking it on a known good system? The sha1sum matches, calculated on the board, so that's good. xz -d completed successfully! tar xvf fails however, with a big ass 5 page long oops. I'd have thought that xz -d would be *far* more CPU intensive and therefore liable to cause issues than tar xvf. If you were using spinning rust rather than an SSD then I would be inclined to suspect the power draw, but with you using an SSD I'm just not sure. I agree! though even a heavily stressed CPU doesn't change power draw hugely. Ssvb and I did some power tests a few months ago on the list. Additionally! I should mention, my CT has a battery backup which should be near full charge. a 1220 mAh battery, so even if the power supply should drop to low or something, Wens assured me that the battery would take over and no problem should be caused by bad power. Unless the battery has run down of course, which I highly doubt, especially seeing the constant current draw over USB. So for now, I just hope it's not user error ... It is not, it is FAST_MBUS, the board is still happily compiling, 24 hours later, latest u-boot, but without FAST_MBUS. It managed to do about 43 compiles this time :) So for now, FAST_MBUS should be conciderd an 'overclocking option'. I'll try to enable it again;a nd maybe tune the voltage a little higher, then again; i don't have time fort hat right now ... Olliver Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 1 April 2014 15:48, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Sun, 30 Mar 2014 20:56:57 +0200 Olliver Schinagl oliver+l...@schinagl.nl wrote: Too bad that really few people are willing or able to do the current draw measurements on their hardware. But at the same time, tweaking the CPU clock speed seems to be somewhat popular. It is not good when people overclock their CPU and decide that this is 'stable' after only letting it idle for a while. Then the very same people may encounter problems later and blame the first random thing that seems to be 'wrong' in their opinion, for example using the non-mainline kernel :-) To make power consumption measurements easier even for inexperienced users, I tried to hack on the AXP209 voltage/current monitoring support and sent some preliminary patches: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg03447.html This is very nice. There is always this option http://www.dx.com/p/usb-av-usb-power-current-voltage-tester-translucent-blue-silver-235090 but you still have to power down the board, find enough adaptors to put that thing in between the board and the PSU, and then the measurements aren't scriptable, anyway. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
Top Posting! I found the culprit. FAST_MBUS breaks it. After 48 hours of runs, enabling fast_mbus immediately breaks it even after boot. Jens and Emilio hinted that the 3.4 driver reads the FEX file for the voltage. So the higher freq. runs at a lower voltage and that may cause it. So I'll run without fast mbus for now, and it's stable again. Rock Solid if I may. Sorry for all the noise :( Olliver On 03/30/2014 08:56 PM, Olliver Schinagl wrote: On 03/30/2014 05:59 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 14:26 +0200, Olliver Schinagl wrote: That said the sorts of random crashed you've been posting sound a lot like either a DRAM issue or overheating. Either of which could be down to u-boot setting up something wrong or bad hardware I suppose. Overheating, maybe. It feels hottish to the touch, but can hold a finger on it without any problem whatsoever. Not close to the pain point. So I estimate 50 C? Shouldn't be reason to be concerned imo. Doesn't sound like it. Power might be the problem, i see the input voltage under heavy load drop to 4.65 Volts @ 0.9 amps Could be that. Have you checked the checksum of the tarball you are extracting and tried unpacking it on a known good system? The sha1sum matches, calculated on the board, so that's good. xz -d completed successfully! tar xvf fails however, with a big ass 5 page long oops. I'd have thought that xz -d would be *far* more CPU intensive and therefore liable to cause issues than tar xvf. If you were using spinning rust rather than an SSD then I would be inclined to suspect the power draw, but with you using an SSD I'm just not sure. I agree! though even a heavily stressed CPU doesn't change power draw hugely. Ssvb and I did some power tests a few months ago on the list. Additionally! I should mention, my CT has a battery backup which should be near full charge. a 1220 mAh battery, so even if the power supply should drop to low or something, Wens assured me that the battery would take over and no problem should be caused by bad power. Unless the battery has run down of course, which I highly doubt, especially seeing the constant current draw over USB. So for now, I just hope it's not user error ... Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
Hi, On 03/30/2014 02:40 PM, Olliver Schinagl wrote: On 03/30/2014 02:25 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote: I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. So, I did the git clone, checkout, config and make all -j4 has been running for quite a while now (10 minutes) with no errors. While the make was running I've messed around with git archive to produce a tar.xz, got bored waiting for that, used wget to download a tar.xz from kernel.org and unpacked it. All with no errors. IOW I'm afraid it all looks OK to me. This is all running from a SATA disk with a 2A power supply. I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. Looking forward to the result, but I'm sure it'll be fine ;) So i changed to the u-boot that comes with fedora 19 from hans, as I did all my previous work with that, and untarring of the extracted tarball works now. I have to make a deadline for my book (building the BSP, hence i bumped into this) and will do more compile/extraction tests in the next few days as time permits on hans's u-boot. I'll run some of ssvb's benchmarks to test various things. If this is all deemed stable; then it can only be u-boot that somehow broke. The only thing I can imagine is tolerances or power usage somehow. Speaking of, during the extraction power jumped from just under 0.5 amps @ 4.85V = idle; to about 0.85 amps @ 4.75V. Hmm, this might be caused by the FAST_MBUS stuff we've for A20 now a days. You could try removing FAST_MBUS from the boards.cfg config options for the cubietruck, and see how a recent u-boot build that way works. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
Hi, On 03/31/2014 08:49 AM, Hans de Goede wrote: Hi, On 03/30/2014 02:40 PM, Olliver Schinagl wrote: On 03/30/2014 02:25 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote: I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. So, I did the git clone, checkout, config and make all -j4 has been running for quite a while now (10 minutes) with no errors. While the make was running I've messed around with git archive to produce a tar.xz, got bored waiting for that, used wget to download a tar.xz from kernel.org and unpacked it. All with no errors. IOW I'm afraid it all looks OK to me. This is all running from a SATA disk with a 2A power supply. I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. Looking forward to the result, but I'm sure it'll be fine ;) So i changed to the u-boot that comes with fedora 19 from hans, as I did all my previous work with that, and untarring of the extracted tarball works now. I have to make a deadline for my book (building the BSP, hence i bumped into this) and will do more compile/extraction tests in the next few days as time permits on hans's u-boot. I'll run some of ssvb's benchmarks to test various things. If this is all deemed stable; then it can only be u-boot that somehow broke. The only thing I can imagine is tolerances or power usage somehow. Speaking of, during the extraction power jumped from just under 0.5 amps @ 4.85V = idle; to about 0.85 amps @ 4.75V. Hmm, this might be caused by the FAST_MBUS stuff we've for A20 now a days. You could try removing FAST_MBUS from the boards.cfg config options for the cubietruck, and see how a recent u-boot build that way works. Oh and another thing to test is to try replacing your powersupply, if is dropping that far below 5V then likely it is also outputting quite a bit of noise and spikes on the powerline. Your battery won't help you there since the power likely is not far enough below 5V to make it switch, so the board keeps using the bad powersupply taking in all the noise and power spikes. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/31/2014 08:04 PM, Olliver Schinagl wrote: On 03/31/2014 08:59 AM, Hans de Goede wrote: Hi, On 03/31/2014 08:49 AM, Hans de Goede wrote: Hi, On 03/30/2014 02:40 PM, Olliver Schinagl wrote: On 03/30/2014 02:25 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote: I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. So, I did the git clone, checkout, config and make all -j4 has been running for quite a while now (10 minutes) with no errors. While the make was running I've messed around with git archive to produce a tar.xz, got bored waiting for that, used wget to download a tar.xz from kernel.org and unpacked it. All with no errors. IOW I'm afraid it all looks OK to me. This is all running from a SATA disk with a 2A power supply. I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. Looking forward to the result, but I'm sure it'll be fine ;) So i changed to the u-boot that comes with fedora 19 from hans, as I did all my previous work with that, and untarring of the extracted tarball works now. I have to make a deadline for my book (building the BSP, hence i bumped into this) and will do more compile/extraction tests in the next few days as time permits on hans's u-boot. I'll run some of ssvb's benchmarks to test various things. If this is all deemed stable; then it can only be u-boot that somehow broke. The only thing I can imagine is tolerances or power usage somehow. Speaking of, during the extraction power jumped from just under 0.5 amps @ 4.85V = idle; to about 0.85 amps @ 4.75V. Hmm, this might be caused by the FAST_MBUS stuff we've for A20 now a days. You could try removing FAST_MBUS from the boards.cfg config options for the cubietruck, and see how a recent u-boot build that way works. Oh and another thing to test is to try replacing your powersupply, if is dropping that far below 5V then likely it is also outputting quite a bit of noise and spikes on the powerline. Your battery won't help you there since the power likely is not far enough below 5V to make it switch, so the board keeps using the bad powersupply taking in all the noise and power spikes. While sensible, I doubt it, it's a high-end samsung charger; I could hook it up to my oscope and see how noise the line is. But the FAST_MBUS thing, yes I will tripple check that. A small update however, I ran a unpack, compile, rm -rf run and while it only managed to complete 37 loops in 24 hours, it completed them appearantly error free (I didn't check the entire log, just the last entry). So this u-boot runs fine and is stable. I will do the loop again (with less itterations) using fast-less u-boot. So far so good, it has run through a few loops which seem to work fine. So the Fast MBUS may not always work too well on all boards ... I'll let it run a bit longer, I'll get back to this tomorrow ... Olliver Olliver Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/29/2014 05:37 PM, Ian Campbell wrote: On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote: Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. Oh dear. Aye! Using the merge tag seems to be fine however, d2a8c8da1. So it is one of the newer patches, will slowly progress the line, as time permits, to find the culprit. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. Which branch are you running? u-boot-sunxi/sunxi I guess but you mention Hans' series so maybe jwrdegoede/sunxi-next? for u-boot, the linux-sunxi u-boot variant. for the kernel, hans's 3.4 that comes with fedora 19; but I initially experienced these problems with one the sunxi nightlies, a 3.4.79+ I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) The obvious first one to try would be d2a8c8da1c6 Merge tag 'v2014.04-rc2' into sunxi. Its immediate parent on the sunxi side is d9aa5dd3d which you've already found to be stable. If you can rule that out then the rest should be fairly tractable to bisect... Looking at gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master most of them are supposed to be no semantic change type cleanups or things which don't touch cubietruck... If it does turn out to be the merge then I think it will be time to take a fine toothed comb to the merge... Luckily, this does not seem the case. I will keep you all posted. Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 12:25 PM, Olliver Schinagl wrote: Status update: d2a8c8d Merge tag 'v2014.04-rc2' into sunxi seems stable and was able to compile u-boot on itself ;) linux-sunxi kept failing due to remote hung endpoints while fetching the full git tree, nothing unexpected there. 4362605 Merge remote-tracking branch 'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz causes no issues yet. I'll keep using that rev for a few hours then go onto the next one. I shouted too early :( [ 508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0) [ 508.901743] Stack: (0xee5f9e78 to 0xee5fa000) [ 508.910451] 9e60: 01f9 c006bab0 [ 508.923123] 9e80: d1015788 ee825a78 b7caf08b 0003 ee825a8c c0782b28 d1015788 ee5f9f10 [ 508.935835] 9ea0: 0001 c00d5498 ee5f9f10 0001 ee5f8010 c051a038 c012bc38 [ 508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921 ee639800 ee63989c [ 508.961336] 9ee0: 0001 ee63990c ee58cb40 c0292cbc 0007 c05442e4 c0292504 c077f97c [ 508.974074] 9f00: ee5f8000 ee5c72c0 0001 ee639800 ee5f8000 ee5f8028 ee5f8000 [ 508.986932] 9f20: 0005 c02935c0 ee825a40 0001 ee5f8000 c000e108 c003d5b8 [ 508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18 ee4f9880 ee5038f0 c023b764 [ 509.012692] 9f60: ee4f98b8 eeb9d080 ee5f8000 00f8 c000e108 ee5f8000 [ 509.025742] 9f80: 0005 c003db38 0006efae b6f4 b6f4 00f8 c003dbc4 [ 509.038900] 9fa0: c000df00 0006efae b6f4 0006ef9a b6fbc4c0 [ 509.052039] 9fc0: 0006efae b6f4 b6f4 00f8 00857898 008513f8 000171d8 0005 [ 509.065171] 9fe0: 00f8 be9a7834 b6f0a0f3 b6eaef96 6030 [ 509.078413] [c0299810] (tty_ldisc_hangup+0x3c/0x2a4) from [c0292cbc] (__tty_hangup+0x124/0x378) [ 509.097651] [c0292cbc] (__tty_hangup+0x124/0x378) from [c02935c0] (disassociate_ctty+0x7c/0x240) [ 509.117536] [c02935c0] (disassociate_ctty+0x7c/0x240) from [c003d5b8] (do_exit+0x294/0x784) [ 509.131797] [c003d5b8] (do_exit+0x294/0x784) from [c003db38] (do_group_exit+0x54/0xc8) [ 509.145622] [c003db38] (do_group_exit+0x54/0xc8) from [c003dbc4] (__wake_up_parent+0x0/0x20) [ 509.159980] Code: e2066002 e2505000 0a18 e5953000 (e5933018) [ 509.171733] ---[ end trace 0b4cd254dfcafc0c ]--- [ 509.181906] Fixing recursive fault but reboot is needed! Going back to the parent rev, d3686aa sunxi: use a 4MB malloc pool and report then :) olliver On 03/30/2014 11:05 AM, Olliver Schinagl wrote: On 03/29/2014 05:37 PM, Ian Campbell wrote: On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote: Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. Oh dear. Aye! Using the merge tag seems to be fine however, d2a8c8da1. So it is one of the newer patches, will slowly progress the line, as time permits, to find the culprit. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. Which branch are you running? u-boot-sunxi/sunxi I guess but you mention Hans' series so maybe jwrdegoede/sunxi-next? for u-boot, the linux-sunxi u-boot variant. for the kernel, hans's 3.4 that comes with fedora 19; but I initially experienced these problems with one the sunxi nightlies, a 3.4.79+ I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) The obvious first one to try would be d2a8c8da1c6 Merge tag 'v2014.04-rc2' into sunxi. Its immediate parent on the sunxi side is d9aa5dd3d which you've already found to be stable. If you can rule that out then the rest should be fairly tractable to bisect... Looking at gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master most of them are supposed to be no semantic change type cleanups or things which don't touch cubietruck... If it does turn out to be the merge then I think it will be time to take a fine toothed comb to the merge... Luckily, this does not seem the case. I will keep you all posted. Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 12:33 PM, Olliver Schinagl wrote: On 03/30/2014 12:25 PM, Olliver Schinagl wrote: Status update: d2a8c8d Merge tag 'v2014.04-rc2' into sunxi seems stable and was able to compile u-boot on itself ;) linux-sunxi kept failing due to remote hung endpoints while fetching the full git tree, nothing unexpected there. 4362605 Merge remote-tracking branch 'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz causes no issues yet. I'll keep using that rev for a few hours then go onto the next one. I shouted too early :( [ 508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0) [ 508.901743] Stack: (0xee5f9e78 to 0xee5fa000) [ 508.910451] 9e60: 01f9 c006bab0 [ 508.923123] 9e80: d1015788 ee825a78 b7caf08b 0003 ee825a8c c0782b28 d1015788 ee5f9f10 [ 508.935835] 9ea0: 0001 c00d5498 ee5f9f10 0001 ee5f8010 c051a038 c012bc38 [ 508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921 ee639800 ee63989c [ 508.961336] 9ee0: 0001 ee63990c ee58cb40 c0292cbc 0007 c05442e4 c0292504 c077f97c [ 508.974074] 9f00: ee5f8000 ee5c72c0 0001 ee639800 ee5f8000 ee5f8028 ee5f8000 [ 508.986932] 9f20: 0005 c02935c0 ee825a40 0001 ee5f8000 c000e108 c003d5b8 [ 508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18 ee4f9880 ee5038f0 c023b764 [ 509.012692] 9f60: ee4f98b8 eeb9d080 ee5f8000 00f8 c000e108 ee5f8000 [ 509.025742] 9f80: 0005 c003db38 0006efae b6f4 b6f4 00f8 c003dbc4 [ 509.038900] 9fa0: c000df00 0006efae b6f4 0006ef9a b6fbc4c0 [ 509.052039] 9fc0: 0006efae b6f4 b6f4 00f8 00857898 008513f8 000171d8 0005 [ 509.065171] 9fe0: 00f8 be9a7834 b6f0a0f3 b6eaef96 6030 [ 509.078413] [c0299810] (tty_ldisc_hangup+0x3c/0x2a4) from [c0292cbc] (__tty_hangup+0x124/0x378) [ 509.097651] [c0292cbc] (__tty_hangup+0x124/0x378) from [c02935c0] (disassociate_ctty+0x7c/0x240) [ 509.117536] [c02935c0] (disassociate_ctty+0x7c/0x240) from [c003d5b8] (do_exit+0x294/0x784) [ 509.131797] [c003d5b8] (do_exit+0x294/0x784) from [c003db38] (do_group_exit+0x54/0xc8) [ 509.145622] [c003db38] (do_group_exit+0x54/0xc8) from [c003dbc4] (__wake_up_parent+0x0/0x20) [ 509.159980] Code: e2066002 e2505000 0a18 e5953000 (e5933018) [ 509.171733] ---[ end trace 0b4cd254dfcafc0c ]--- [ 509.181906] Fixing recursive fault but reboot is needed! Going back to the parent rev, d3686aa sunxi: use a 4MB malloc pool and report then :) Right, this one doesn't seem to crash; but I cant extract the .xz either... linux-sunxi/.git/objects/pack/pack-06962d550c8aab83282655647120ce3552ca5b0e.idx xz: (stdin): Compressed data is corrupt tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now and that constantly, sometimes it gets to go 1 file further ... ironically the sha1 calculation worked fine I'll go back to pre-merge and double check that. olliver On 03/30/2014 11:05 AM, Olliver Schinagl wrote: On 03/29/2014 05:37 PM, Ian Campbell wrote: On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote: Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. Oh dear. Aye! Using the merge tag seems to be fine however, d2a8c8da1. So it is one of the newer patches, will slowly progress the line, as time permits, to find the culprit. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. Which branch are you running? u-boot-sunxi/sunxi I guess but you mention Hans' series so maybe jwrdegoede/sunxi-next? for u-boot, the linux-sunxi u-boot variant. for the kernel, hans's 3.4 that comes with fedora 19; but I initially experienced these problems with one the sunxi nightlies, a 3.4.79+ I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) The obvious first one to try would be d2a8c8da1c6 Merge tag 'v2014.04-rc2' into sunxi. Its immediate parent on the sunxi side is d9aa5dd3d which you've already found to be stable. If you can rule that out then the rest should be fairly tractable to bisect... Looking at gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master most of them are supposed to be no semantic change type cleanups or things which don't touch cubietruck... If it does turn out to be the merge then I think it will be time to take a fine toothed comb to the merge... Luckily, this does not seem the case. I will keep you all posted. Olliver Ian.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 12:43 PM, Olliver Schinagl wrote: On 03/30/2014 12:33 PM, Olliver Schinagl wrote: On 03/30/2014 12:25 PM, Olliver Schinagl wrote: Status update: d2a8c8d Merge tag 'v2014.04-rc2' into sunxi seems stable and was able to compile u-boot on itself ;) linux-sunxi kept failing due to remote hung endpoints while fetching the full git tree, nothing unexpected there. 4362605 Merge remote-tracking branch 'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz causes no issues yet. I'll keep using that rev for a few hours then go onto the next one. I shouted too early :( [ 508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0) [ 508.901743] Stack: (0xee5f9e78 to 0xee5fa000) [ 508.910451] 9e60: 01f9 c006bab0 [ 508.923123] 9e80: d1015788 ee825a78 b7caf08b 0003 ee825a8c c0782b28 d1015788 ee5f9f10 [ 508.935835] 9ea0: 0001 c00d5498 ee5f9f10 0001 ee5f8010 c051a038 c012bc38 [ 508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921 ee639800 ee63989c [ 508.961336] 9ee0: 0001 ee63990c ee58cb40 c0292cbc 0007 c05442e4 c0292504 c077f97c [ 508.974074] 9f00: ee5f8000 ee5c72c0 0001 ee639800 ee5f8000 ee5f8028 ee5f8000 [ 508.986932] 9f20: 0005 c02935c0 ee825a40 0001 ee5f8000 c000e108 c003d5b8 [ 508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18 ee4f9880 ee5038f0 c023b764 [ 509.012692] 9f60: ee4f98b8 eeb9d080 ee5f8000 00f8 c000e108 ee5f8000 [ 509.025742] 9f80: 0005 c003db38 0006efae b6f4 b6f4 00f8 c003dbc4 [ 509.038900] 9fa0: c000df00 0006efae b6f4 0006ef9a b6fbc4c0 [ 509.052039] 9fc0: 0006efae b6f4 b6f4 00f8 00857898 008513f8 000171d8 0005 [ 509.065171] 9fe0: 00f8 be9a7834 b6f0a0f3 b6eaef96 6030 [ 509.078413] [c0299810] (tty_ldisc_hangup+0x3c/0x2a4) from [c0292cbc] (__tty_hangup+0x124/0x378) [ 509.097651] [c0292cbc] (__tty_hangup+0x124/0x378) from [c02935c0] (disassociate_ctty+0x7c/0x240) [ 509.117536] [c02935c0] (disassociate_ctty+0x7c/0x240) from [c003d5b8] (do_exit+0x294/0x784) [ 509.131797] [c003d5b8] (do_exit+0x294/0x784) from [c003db38] (do_group_exit+0x54/0xc8) [ 509.145622] [c003db38] (do_group_exit+0x54/0xc8) from [c003dbc4] (__wake_up_parent+0x0/0x20) [ 509.159980] Code: e2066002 e2505000 0a18 e5953000 (e5933018) [ 509.171733] ---[ end trace 0b4cd254dfcafc0c ]--- [ 509.181906] Fixing recursive fault but reboot is needed! Going back to the parent rev, d3686aa sunxi: use a 4MB malloc pool and report then :) Right, this one doesn't seem to crash; but I cant extract the .xz either... linux-sunxi/.git/objects/pack/pack-06962d550c8aab83282655647120ce3552ca5b0e.idx xz: (stdin): Compressed data is corrupt tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now and that constantly, sometimes it gets to go 1 file further ... ironically the sha1 calculation worked fine I'll go back to pre-merge and double check that. 4271202 sunxi: add board hcore hc860 seems to be un-able to extract the tar-ball and causes an oops. [ 450.179006] [c02449fc] (__list_del_entry+0x8/0xb8) from [c0244ab8] (list_del+0xc/0x24) [ 450.199528] [c0244ab8] (list_del+0xc/0x24) from [c00e48c0] (__rmqueue+0x70/0x370) [ 450.219659] [c00e48c0] (__rmqueue+0x70/0x370) from [c00e563c] (get_page_from_freelist+0x324/0x4b8) [ 450.253607] [c00e563c] (get_page_from_freelist+0x324/0x4b8) from [c00e6154] (__alloc_pages_nodemask+0x18c/0x7b4) [ 450.289644] [c00e6154] (__alloc_pages_nodemask+0x18c/0x7b4) from [c0115560] (new_slab+0x84/0x23c) [ 450.325304] [c0115560] (new_slab+0x84/0x23c) from [c0509ad0] (__slab_alloc.constprop.54+0x20c/0x450) [ 450.362016] [c0509ad0] (__slab_alloc.constprop.54+0x20c/0x450) from [c0116e84] (kmem_cache_alloc+0x70/0x18c) [ 450.400291] [c0116e84] (kmem_cache_alloc+0x70/0x18c) from [c019cb34] (ext4_alloc_inode+0x20/0xbc) [ 450.438405] [c019cb34] (ext4_alloc_inode+0x20/0xbc) from [c0133230] (alloc_inode+0x24/0x9c) [ 450.462253] [c0133230] (alloc_inode+0x24/0x9c) from [c0134c30] (new_inode_pseudo+0x10/0x50) [ 450.486131] [c0134c30] (new_inode_pseudo+0x10/0x50) from [c0134c80] (new_inode+0x10/0x24) [ 450.509985] [c0134c80] (new_inode+0x10/0x24) from [c0184ff8] (ext4_new_inode+0x94/0xee0) [ 450.533711] [c0184ff8] (ext4_new_inode+0x94/0xee0) from [c0191318] (ext4_create+0xb0/0x150) [ 450.557750] [c0191318] (ext4_create+0xb0/0x150) from [c012905c] (vfs_create+0x98/0x11c) [ 450.581516] [c012905c] (vfs_create+0x98/0x11c) from [c01294f8] (do_last+0x418/0x7e8) [ 450.605109] [c01294f8] (do_last+0x418/0x7e8) from [c012a164] (path_openat+0xc4/0x39c) [ 450.628904] [c012a164] (path_openat+0xc4/0x39c) from [c012a530] (do_filp_open+0x34/0x80) [ 450.653058] [c012a530] (do_filp_open+0x34/0x80) from [c011b7e0] (do_sys_open+0xf0/0x17c)
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On Sun, 2014-03-30 at 12:58 +0200, Olliver Schinagl wrote: 4271202 sunxi: add board hcore hc860 seems to be un-able to extract the tar-ball and causes an oops. That's from ages ago, isn't it? Are you sure it isn't some other component which has changed recently, e.g. the kernel? That said the sorts of random crashed you've been posting sound a lot like either a DRAM issue or overheating. Either of which could be down to u-boot setting up something wrong or bad hardware I suppose. This is on an SSD, with a 2amps charger. I ran tinymembenches before never exceeding 0.7 amps; could someone confirm this on the cubietruck? I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. Have you checked the checksum of the tarball you are extracting and tried unpacking it on a known good system? Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 01:26 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:58 +0200, Olliver Schinagl wrote: 4271202 sunxi: add board hcore hc860 seems to be un-able to extract the tar-ball and causes an oops. That's from ages ago, isn't it? It is! I will now use the u-boot from even older; that came with fedora19, very conservative, but also 'known to be somewhat good' Are you sure it isn't some other component which has changed recently, e.g. the kernel? Software wise, i'm running it quite conservative really, really old stuff so to say. That said the sorts of random crashed you've been posting sound a lot like either a DRAM issue or overheating. Either of which could be down to u-boot setting up something wrong or bad hardware I suppose. Overheating, maybe. It feels hottish to the touch, but can hold a finger on it without any problem whatsoever. Not close to the pain point. So I estimate 50 C? Shouldn't be reason to be concerned imo. Power might be the problem, i see the input voltage under heavy load drop to 4.65 Volts @ 0.9 amps This is on an SSD, with a 2amps charger. I ran tinymembenches before never exceeding 0.7 amps; could someone confirm this on the cubietruck? I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. Cool, the strange thing is, u-boot cloned and compiled fine :( Have you checked the checksum of the tarball you are extracting and tried unpacking it on a known good system? The sha1sum matches, calculated on the board, so that's good. xz -d completed successfully! tar xvf fails however, with a big ass 5 page long oops. Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote: I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. So, I did the git clone, checkout, config and make all -j4 has been running for quite a while now (10 minutes) with no errors. While the make was running I've messed around with git archive to produce a tar.xz, got bored waiting for that, used wget to download a tar.xz from kernel.org and unpacked it. All with no errors. IOW I'm afraid it all looks OK to me. This is all running from a SATA disk with a 2A power supply. I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. This is all on a cubietruck BTW. Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 02:25 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote: I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. So, I did the git clone, checkout, config and make all -j4 has been running for quite a while now (10 minutes) with no errors. While the make was running I've messed around with git archive to produce a tar.xz, got bored waiting for that, used wget to download a tar.xz from kernel.org and unpacked it. All with no errors. IOW I'm afraid it all looks OK to me. This is all running from a SATA disk with a 2A power supply. I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. Looking forward to the result, but I'm sure it'll be fine ;) So i changed to the u-boot that comes with fedora 19 from hans, as I did all my previous work with that, and untarring of the extracted tarball works now. I have to make a deadline for my book (building the BSP, hence i bumped into this) and will do more compile/extraction tests in the next few days as time permits on hans's u-boot. I'll run some of ssvb's benchmarks to test various things. If this is all deemed stable; then it can only be u-boot that somehow broke. The only thing I can imagine is tolerances or power usage somehow. Speaking of, during the extraction power jumped from just under 0.5 amps @ 4.85V = idle; to about 0.85 amps @ 4.75V. Olliver This is all on a cubietruck BTW. ditto ;) Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On Sun, 2014-03-30 at 13:25 +0100, Ian Campbell wrote: I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. It was fine. I've left it running in a loop repeatedly building kernels. Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On Sun, 2014-03-30 at 14:26 +0200, Olliver Schinagl wrote: That said the sorts of random crashed you've been posting sound a lot like either a DRAM issue or overheating. Either of which could be down to u-boot setting up something wrong or bad hardware I suppose. Overheating, maybe. It feels hottish to the touch, but can hold a finger on it without any problem whatsoever. Not close to the pain point. So I estimate 50 C? Shouldn't be reason to be concerned imo. Doesn't sound like it. Power might be the problem, i see the input voltage under heavy load drop to 4.65 Volts @ 0.9 amps Could be that. Have you checked the checksum of the tarball you are extracting and tried unpacking it on a known good system? The sha1sum matches, calculated on the board, so that's good. xz -d completed successfully! tar xvf fails however, with a big ass 5 page long oops. I'd have thought that xz -d would be *far* more CPU intensive and therefore liable to cause issues than tar xvf. If you were using spinning rust rather than an SSD then I would be inclined to suspect the power draw, but with you using an SSD I'm just not sure. Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Current u-boot crashes my cubietruck!
Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) Olliver -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote: Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. Oh dear. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. Which branch are you running? u-boot-sunxi/sunxi I guess but you mention Hans' series so maybe jwrdegoede/sunxi-next? I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) The obvious first one to try would be d2a8c8da1c6 Merge tag 'v2014.04-rc2' into sunxi. Its immediate parent on the sunxi side is d9aa5dd3d which you've already found to be stable. If you can rule that out then the rest should be fairly tractable to bisect... Looking at gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master most of them are supposed to be no semantic change type cleanups or things which don't touch cubietruck... If it does turn out to be the merge then I think it will be time to take a fine toothed comb to the merge... Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
