[linux-sunxi] Re: [BUG report] kworker issue on A20 SoC with kernel >= 4.12.0
Am Freitag, 27. April 2018 11:16:00 UTC+2 schrieb Kai: > > > > On 4.16.4 . > I'm not able to debug it myself for now, however, A20 was abandoned by > everyone? > I don't think A20 was abandond - at least not when it comes to using the devices. Development might be stalled since Linux support is mostly feature complete, though. I can't test your issue as I'm using plain Debian with an older Linux kernel 4.9.x on my A20 devices. But for debugging, I would suggest to start with a vanilla kernel build. Armbians kernel caries quite a few patches (+100), so you can't be sure whether your issue comes from these patches or whether all users of a mainline kernel are affected. -- 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] Re: sun4i-ts hwmon broken with linux 4.10
Hi Michael, Am Mittwoch, 8. März 2017 15:34:03 UTC+1 schrieb Michael Weiser: > Not everyone is working off the defconfig though. My custom config > started out with sunxi_defconfig but now I just 'make oldconfig' it from > the one kernel version to the next. I decide on new options based on the > help text. In this case THERMAL_OF was not enabled because it wasn't > necessary and not in the defconfig before. For such cases a clear(er) > pointer to the necessity of THERMAL_OF in the help text of SUN4I_GPADC > might be helpful. > I use a similar approach, but I always check the diff of sunxi_defconfig when moving to a new major release. There have been quite a few changes in the past where new options were required to make previously working things working again or where options have been renamed, etc. That's why I got accustomed to looking at the changes in sunxi_defconfig first, before I try to generate my own config for a new major release. And while that really makes things easier, it's of course no guarantee that something might still have slipped through and needs to be added/fixed in the next relase. Regards, Timo -- 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] Re: Mainline stability (overvolting/undervolting) etc. (u-boot/linux)
Hi Olliver, Am Dienstag, 25. Oktober 2016 16:36:17 UTC+2 schrieb Olliver Schinagl: > > Hey all, > > as some of you are probably aware, some users occasionally experience > some instability using the mainline components. I specifically only want > to focus on mainline, as with the 3.4 stuff ... well lets just not even > go there. > > [TL;DR] We should offer the user a stable u-boot/kernel combo. Playing > with frequencies/voltages is up to the user (via overlay etc). > > So stability. First in case you haven't heard we released our product, > the Ultimaker 3, which features an Olimex Lime2 board. During the past > development year we noticed some stability issues but haven't pinpointed > the exact cause. > > For example, we noticed quite some stability problems with the ondemand > governor, especially as it was running on the medium ranges. Switching > to performance fixed this mostly for us, but we do very seldom still see > a crash. > This sounds somewhat similar to what lead to the increase of the voltages of the Banana Pi. See below... > > With olimex change request on the 11th of oktober to lower the memory > freq. [0], we seem to have atleast some form of confirmation that there > really is a stability problem for others as well. With that request, > they lowered the DRAM frequency of their A20 boards. > > Does that solve the stability? Or does that also reduce the failure rate > to be less noticeable. > > Or are both a problem, cpu voltage/freq and dram freq. > Hard to tell. But if changing the cpufreq governor to performance makes such a difference, it's likely the lower voltages contribute to your issues. > I think it is fair to say, before writing the next paragraph, that the > defaults users get from mainline components should be rock solid and > stable. Playing with settings is fine for a user to do, but the defaults > should be solid. > Absolutely! > > So one, is to investigate the memory claims of Olimex. Even lowering the > frequency to 384 MHz may not be as stable as some expect, but I'm sure > ssvb can pitch in here :) > > Secondly, are our operating points sane and safe? For example this patch > [1] from the banana-pi folks increased the voltages of the middle > frequencies. Now this could have been because of two reasons, and > unfortunately the patch does not mention this clearly. A larger user > base found issues here and changed it to solve the issues. Or the > banana-pi has a bad board design, where the requested voltage does not > reach the SoC, and thus needs some compensation. If the later is the > case, a comment in the dts should have been added and the commit message > should have stated this. > The full story behind raising the voltages is buried in the mailing list here somewhere, but the gist is this: Initially I wrote a patch to merely add the regulator definitions to the Banana Pi device tree. The reason was that sun4i/sun7i had gotten cpufreq support in mainline before, but without regulator definitions the Banana Pi would run at 1.4 volts regardless of the frequency. After my patch was accepted into linux-next, there were reports of crashes and boot failures with some Banana Pis which were due to the lower voltages now being used at lower frequencies. Thus, in a new iteration of the patch, new operating points were added to the Banana Pi dts with higher voltages. There was speculation as to whether the higher voltages are needed due to a design issue of the Banana Pi itself or due to a more general issue on the A20. I had emailed LeMaker about that back then, but never got a response. Lacking official statements or user reports that would show that this might be a more general issue, the consensus back then was to raise the voltages for the Banana Pi only and not all A20 boards/devices. Btw. The voltage definitions were taken directly from the fex file that LeMaker distributes [1] and for which no problems had been reported. The only differences were the two opp 912MHz and 960Mhz for which I left the voltages at 1.4 volts, while LeMaker uses slightly overvolted settings here. But since nobody ever reported any issues with these frequencies at 1.4 volts in mainline, it seemed safe enough to keep them. > > Since however, some people notice the same problem on other boards, this > may not be a board routing issue. Anyway, we are just guessing in that > regard now. > > Digging a little deeper, what strikes me as odd, is that Allwinner says > in the A20 datasheet, that 1.4V is the maximum recommended voltage for > the SoC, yet we have 2 frequencies that operate on 1.4v. This, to me, > indicates something strange. Either 960 MHz is stable at 1.4 and thus > the 912 Mhz voltage should be lower, or the 960 Mhz is slightly > undervolted. > > We do not have reliable data from Allwinner, and we don't have the > resources to properly test many boards to determine stable operating > points. But by going with somewhat
Re: [linux-sunxi] Re: random decryption errors with sun4i-ss on dm-crypt
Short update:
Corentin's fix (crypto: sun4i-ss - Replace spinlock_bh by
spin_lock_irq{save|restore}) finally made it into the stable/longterm
updates: Greg has just released the versions 4.4.12, 4.5.6 and 4.6.1 -
all of which contain the patch.
Regards,
Timo
On Wed, Apr 20, 2016 at 9:27 AM, LABBE Corentin
wrote:
> On Tue, Apr 19, 2016 at 08:29:23AM -0700, txsan...@gmail.com wrote:
>> Still nothing :( it seems i can convert my encrypted storage back to XTS, as
>> i've only converted it to CBC for the hw encryption.
>>
>
> I hàve sent the patch (https://lkml.org/lkml/2016/3/23/302) solving this
> issue, but it is not present in any tree.
> Anywày, XTS is the recommended wày for disk encryption and it have nearly the
> same speed than CBC with hw.
>
> Regards
>
> --
> You received this message because you are subscribed to a topic in the Google
> Groups "linux-sunxi" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/linux-sunxi/InsDjSm3J6A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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] Re: random decryption errors with sun4i-ss on dm-crypt
Hi Corentin, Am 13.03.2016 17:32 schrieb "Corentin LABBE" : > > Le 13/03/2016 16:21, txsan...@gmail.com a écrit : > > http://irclog.whitequark.org/linux-sunxi/2016-03-11 > > > > Chat from timestamp 18:25 > > > > Hello > > And I have just sent an email asking for help https://lkml.org/lkml/2016/3/13/64. > > Regards Thanks for the update and work on this. Are you sure that the issue occurs only when deciphering? When I ran my tests, I was under the impression, that this also happens during encryption or ciphering. Because when I downloaded a large iso image to the encrypted container, unmounted it immediately after, unloaded the sun4i-ss module, mounted the container again and then verified the checksum, it showed a corrupted file. I thought that means something went wrong during encryption already. But my knowledge of all this is little, so I might be wrong. Regards, Timo -- 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] Re: random decryption errors with sun4i-ss on dm-crypt
Hi, On Sun, Mar 6, 2016 at 1:32 PM, wrote: > 2016. február 17., szerda 18:16:09 UTC+1 időpontban txsa...@gmail.com a > következőt írta: >> Hi >> >> I have a Cubieboard2 device, is Allwinner A20 SOC, running and Armbian 5.00 >> with kernel 4.4.1. >> >> As in the latest version the sun4i-ss module is added, i tried the hardware >> crypto acceleration with my 2 TB LUKS encrypted HDD, with 256bit >> AES-CBC-PLAIN64 encryption. >> >> It was fast, but i noticed that when playing videos from that HDD, there are >> random errors coming from somewhere. As the same happened when streaming the >> video on DLNA, and SAMBA, i did some tests. >> >> As the HDD is also used for a backup storage, i compared the original files >> with the backup on the encrypted HDD, and the most of the bigger files were >> different. >> >> So i've unloaded sun4i-ss module with "rmmod sun4i_ss" and everything become >> OK, no video errors, the backup and the original files are identical. >> >> So there is something wrong with this module, as i see only the decryption >> side is faulty, the encryption seems to be OK. >> >> Any suggestions? > > Any news? In the meantime, I re-ran my tests with a fresh kernel 4.4.4 (clean mainline/stable build, no additional patches). The problem still persists. With sun4i-ss the data is corrupted, without it, everything is ok. Regards, Timo -- 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] Re: random decryption errors with sun4i-ss on dm-crypt
Hi, On Tue, Feb 23, 2016 at 3:22 AM, Stefan Monnier wrote: >> Thanks, I installed your cryptotest suite including your new lukstest >> tool and ran some tests on a Banana Pi tonight. The results were all >> good. After a first successful run of lukstest, I modified the script >> and increased the sample size by a factor of 100 (and the image file, >> too). Even with the increased sample size, I didn't see any errors >> (because of the increased test duration, I ran only 5 iterations, >> though). Tests were done on an Armbian installation with Kernel 4.4.1 >> (with your patch "Add missing state size" on top of it) in order to >> resemble the original reporters conditions more closely. I was >> planning to do tests with 4.4.2 as well, but since all tests succeeded >> so far, I don't think that would change anything. > > [ Just a random shot in the dark from someone who knows nothing about > these things. ] > > My guess is that to reproduce the problem, you need to have maybe the > same intertwined sequence of decryption and disk access (who I have no > idea what kind of disk he's using). > IOW it could be linked to some interference from the disk's interrupts > or something. I probably know less about these things than you - but I sounds interesting. I will give it another try lathr this week and set up a samba share on that drive to put some stress on the drive while the lukstest is running. Then we should have interrupts from both the SATA controller and the ehternet controller at the same time. Regards, Timo -- 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] Re: random decryption errors with sun4i-ss on dm-crypt
Hi Correntin, On Mon, Feb 22, 2016 at 11:24 AM, LABBE Corentin wrote: > On Sun, Feb 21, 2016 at 07:24:36AM -0800, m.silentcr...@gmail.com wrote: >> Hi, >> >> Am Mittwoch, 17. Februar 2016 18:16:09 UTC+1 schrieb txsa...@gmail.com: >> > Hi >> > >> > I have a Cubieboard2 device, is Allwinner A20 SOC, running and Armbian >> > 5.00 with kernel 4.4.1. >> > >> > As in the latest version the sun4i-ss module is added, i tried the >> > hardware crypto acceleration with my 2 TB LUKS encrypted HDD, with 256bit >> > AES-CBC-PLAIN64 encryption. >> > >> > It was fast, but i noticed that when playing videos from that HDD, there >> > are random errors coming from somewhere. As the same happened when >> > streaming the video on DLNA, and SAMBA, i did some tests. >> > >> > As the HDD is also used for a backup storage, i compared the original >> > files with the backup on the encrypted HDD, and the most of the bigger >> > files were different. >> > >> > So i've unloaded sun4i-ss module with "rmmod sun4i_ss" and everything >> > become OK, no video errors, the backup and the original files are >> > identical. >> > >> > So there is something wrong with this module, as i see only the decryption >> > side is faulty, the encryption seems to be OK. >> > >> > Any suggestions? >> >> If there are any easy-to-setup tests I could run to help identify this >> issue, I'd be happy to run some tests on a spare Banana Pi I have. If there >> really is a bug in the sun4i-ss driver or in the accelerator itself that >> causes data corruption, I'd rather have it found as soon as possible. >> >> @Correntin: Is it possible to let your cryptotest testsuite run tests >> specifically for large data blocks? >> >> Regards, >> >> Timo > > Hello > > Changing the cryptotest is useless since cryptsetup/dm-crypt cipher data by > blocks of 512. > So the length of data changes only the statistic to hit the bug. > So I have writed a test (lukstest) which use cryptsetup, create files on a > cipherered partiton and checked it. > If you could test it for knowing if it find the issue. (Just uploaded it on > github). > > Actualy all my works is to try to reproduce this issue on my setup. > I also try to know if this thread > https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg17926.html is > related. > > Regards > Thanks, I installed your cryptotest suite including your new lukstest tool and ran some tests on a Banana Pi tonight. The results were all good. After a first successful run of lukstest, I modified the script and increased the sample size by a factor of 100 (and the image file, too). Even with the increased sample size, I didn't see any errors (because of the increased test duration, I ran only 5 iterations, though). Tests were done on an Armbian installation with Kernel 4.4.1 (with your patch "Add missing state size" on top of it) in order to resemble the original reporters conditions more closely. I was planning to do tests with 4.4.2 as well, but since all tests succeeded so far, I don't think that would change anything. Regards, Timo -- 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] Re: [PATCH] touchscreen: sun4i-ts: Really fix A10 temperature reporting
Hi Hans, On Wed, Jun 24, 2015 at 9:16 AM, Hans de Goede wrote: Ah yes, something went wrong during the 4.1 cycle wrt merging ARM patches > which have caused almost all ARM patches intended for 4.1 to get delayed to > 4.2, including that one, that is the problem. > > We did our best to update the driver and the dts in lockstep, and you > should > have never seen this problem, but the missing of the merge window for all > ARM patches during the 4.1 cycle has caused our carefully planned lock-step > update to fail, sorry about that. > No need to apologize. Things happen. Glad to see this cleared up so quickly. Thanks for the help (and all the other work you do ;)). Kind regards, Timo -- 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] [Bug?] [4.1] clocksource hstimer messages spamming syslog
Hi Maxime, so, I tried your patch (had to adjust it slightly, since there is no sun5i.dtsi file in 4.1) and it works perfectly. There is now exactly one such message in dmesg in the early boot process, but after that, they are gone completely. Very nice. See my further comments below inline: On Mon, Jun 22, 2015 at 12:15 PM, Maxime Ripard < maxime.rip...@free-electrons.com> wrote: > Please keep my in the recipient list when you reply. > Sorry about that. I used the Google groups web interface when I answered you and apparently that stripped your address. Note that this is not an issue. It's just the kernel doing its job as > it should. > Ok, the content of the message does not reflect an issue. Yet, I still wouldn't consider constant useless messages going to the console/syslog normal behaviour. > It does not qualify for a patch that can be merged in stable: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/stable_kernel_rules.txt#n9 > Point taken. Too bad. I guess I have to adjust my workflow then to take the 4.1.x sources from kernel.org and always patch them manually. If that's an issue, you can change the default loglevel to remove the > info messages from the console output. > Yes, but I still prefer a solution that doesn't even produce these messages if they are useless. Especially people who use an SD card for their rootfs might wanna take mesaures to prevent the constant writes to syslog wearing out their storage. Now, one could adjust the kernel log level and the syslog rules, but your patch is a much nicer solution ;) Anyway, thanks for your time and help. Much apreciated. Kind regards, Timo -- 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.
