No idea if either of you 'flash' many devices at once. But it would be good to be 100% sure where, and why this issue occurs.
I have not experienced this issue at all. But quite honestly I think I've flashed the eMMC of only 3 different boards a few times each. In each case, rsync work flawlessly, and the whole copy operation was done in well under 2 minutes. The image I've used: BBB-blank-debian-8.5-console-armhf-2016-06-19-2gb.img.xz Powered by USB even, but a good known solid USB 3.0 port. When I check the PMIC registers, it says it set to 1300mA. So I have to assume that helps. I do not know what else to add for the procedure I use. I use . . . william@eee-pc:~$ uname -r 3.2.0-4-686-pae To dd the image above to sdcard. Then it's been just a simple matter of booting the given board with the sdcard inserted . .. But anyway, I would not rule out power related issues in any case. It's not looking likely, but not impossible. On Tue, Oct 4, 2016 at 5:27 PM, William Hermans <[email protected]> wrote: > Instead of deferring until memory is available, or even just proceeding >> without DMA, the omap_hsmmc driver immediately fails the request with an >> error, thus pretty much guaranteeing loss of data or even filesystem >> corruption. I personally think this is completely unacceptable behaviour of >> a block driver. >> > > I agree with you 100%. Completely irresponsible and unacceptable. Problem > is . . . 'open source', or in this case where the term 'open sores' I think > applies. > > On Tue, Oct 4, 2016 at 12:00 PM, Matthijs van Duin < > [email protected]> wrote: > >> I've also run into this once during an apt-get upgrade, leaving the >> system in a pretty hosed state. I managed to recover it but it required a >> lot of effort. Although evidently rare, this is clearly a very serious >> issue. >> >> The direct cause is edma_prep_slave_sg() failing to allocate memory for >> the struct edma_desc. I don't know whether the kernel is genuinely out of >> memory or if it simply cannot free it up immediately (the allocation is >> done with GPF_ATOMIC), and whether this is because it is filled with a >> backlog of writes or whether a leak of some sort is going on. >> >> Instead of deferring until memory is available, or even just proceeding >> without DMA, the omap_hsmmc driver immediately fails the request with an >> error, thus pretty much guaranteeing loss of data or even filesystem >> corruption. I personally think this is completely unacceptable behaviour of >> a block driver. >> >> I've been meaning to persue this matter on the linux-mmc and/or >> linux-omap lists, but since it was a single isolated incident and I have >> lots of other stuff to do I haven't been able to find the time and >> motivation yet. >> >> Matthijs >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/beagleboard/c052b765-78da-4257-857c-09a6046fe395%40googlegroups.com >> <https://groups.google.com/d/msgid/beagleboard/c052b765-78da-4257-857c-09a6046fe395%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrxVer85%2B%3D%3DrOLa5O2-JZ8KaEnCZb5hwsostofPM%2By-qw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
