Can you try adding "iommu=soft" on the kernel command line (edit syslinux.cfg on the USB memory stick).
Posts by milhouse
-
-
This isn't the behaviour I've seen with my motherboard/CPU, which is listed in the wiki page you linked, as it boots LE from USB without any issue, and based on the lack of problem reports this would seem to be a very rare issue which makes me a little wary of this being the correct cause/solution for what you are experiencing.
Can you link to a working community build, in particular the kernel config?
-
Are you trying to boot LE as a guest OS from a USB inside a VM?
LibreELEC boots without problems from a USB on my AMD FX-8350/Asus Sabertooth 990FX R2, but that's without using a VM - just "bare metal".
The LE Generic ova image should also boot successfully when installed as a VMWare guest.
LibreELEC-Generic.x86_64-8.2.4.ova
Helpful video:
External Content www.youtube.comContent embedded from external sources will not be displayed without your consent.Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy. -
Also for those that are not booting - are there any LED blink patterns?
-
If anyone affected by 8.2.4 issues is overclocking, can they re-test 8.2.4 without overclocks and confirm if there is any change.
Also, installing 8.2.4 firmware after downgrading to 8.2.3 would be another useful test - if the resulting "hybrid" 8.2.3/8.2.4 installation has the same problems as 8.2.4 then we know it's a problem with the new 8.2.4 firmware. First, downgrade to 8.2.3 and confirm all is back to normal. Then, install the contents of 8.2.4 firmware (zip) in the root partition (overwriting the files of the same name) and re-test and confirm if there is any change. This firmware is suitable for both RPi0W and CM3. To restore your original 8.2.3 firmware, use 8.2.3 firmware (zip)
Obviously we want to get to the bottom of this issue and the first step is eliminating variables such as overclocking, then firmware. Fortunately there isn't an awful lot else changed in 8.2.4.
-
The heatspreader does add 0.5mm-1mm height to the overall package however the FLIRC case includes a squishy thermal interface material that will accommodate the increased z-height of the Pi3+.
Any "heatsink" type case with zero tolerance (when using a Pi3) may have a problem with the Pi3+, but the FLIRC should be OK.
Edit: I've moved my Pi3+ into a FLIRC case and it fits without any problem. Temperature is reduced by 15-20C during 1080p HEVC playback.
-
During HEVC 1080p test which bitrate are you able to play smootly with your overclock settings?
I don't have an extensive library of HEVC material but everything I've tried has played flawlessly. Sorry.
-
Do you use heatsink + fan?
Not at the moment - a heatsink (eg. Flirc case) should help manage temperatures when decoding HEVC.
Only 1450 MHz for the CPU freq?
Yes, it's only a moderate ARM overclock and the large over_voltage may not be worthwhile due to the extra heat that is generated - I just wanted to see how far I could push it (since this is an early sample the headroom may have improved on production boards).
The gpu_freq overclock on my board does require the extra volts however.
It's totally stable at this overclock but does get a little warm with HEVC playback so I may end up winding it back down to keep the temps in check (overclocking sdram_freq gives the most benefit with HEVC decoding, anyway).
A large +6 over_voltage also has another disadvantage which is that the new mid-level throttle at 70C will no longer reduce the arm voltage and only the freq will be reduced to 1200Mhz (normally the voltage would also be reduced back to 1.25v/+2).
-
What is the default sdram_freq and gpu_freq?
gpu_freq isn't a single frequency on Pi3+ so there is no single default - setting gpu_freq sets the frequency for several hardware blocks (core, h264, isp, v3d) as explained here.
gpu_freq=560 sets all of the hardware blocks to 560Mhz, overclocking core by +160Mhz and h264/isp/v3d by +260Mhz.
If you want to fine tune individual blocks then use the individual config settings.
-
These are my RPi3+ overclock settings:
Codearm_freq=1450 gpu_freq=560 over_voltage=6 force_turbo=1 sdram_freq=720 over_voltage_sdram=8 sdram_schmoo=0x02000020
As always when overclocking, do your own testing to determine the stable limits of your device - the above overclock may not be stable with every Pi3+ device.
-
When upgrading from Pi2 to Pi3 using the same SD card it should be noted that any overclocks in config.txt that work with your Pi2 may now be applied to the Pi3 causing the Pi3 to lock up, either on boot or shortly afterwards. The same is true when switching back to Pi2 from Pi3 (indeed, overclocked Pi3 settings are far more likely to prevent a Pi2 booting).
The solution is to use conditional filters, configuring separate overclock settings for the Pi2 and Pi3. The correct overclock settings will then be used automatically.
-
So is safty allow On raspberry pi smb v1?
You can enable SMB1 in the LibreELEC Samba server so it will work with insecure and outdated clients such as your Minix, but I wouldn't call it "safe".
You really should upgrade (or replace) your Minix rather than downgrade the security of your network and risk data loss, ransom ware, etc.
-
With Kodi 17.6/LE 8.2.3 there's no longer any need to add lines to user.conf - simply set "Maximum protocol" to SMB1 and enable "Use legacy security", and this should get Kodi working with your Asus router. With LE 8.2.3 you should remove the workarounds from user.conf and just let Kodi manage it.
I can't really say why the Asus Samba server doesn't require a password - that's a server configuration issue so you should contact Asus.
You should also contact Asus about fixing their decade-old insecure version of Samba - apparently Samba 4 requires more space (ie. NAND flash) which makes upgrading to Samba 4 more difficult, but this doesn't really excuse Asus continuing to ship Samba 3 on new hardware where they could have increased NAND storage.
You'll also be glad to know that Samba will be announcing important security updates tomorrow, which we will incorporate into future LE8 releases. Needless to say, your Asus router won't have these updates and will remain exposed.
My advice would be to disable Samba 3 entirely in the Asus router and use an alternative, modern and more secure server - you could even use LibreELEC on an RPi. Asus are either too cheap, or don't care about end-user security, or both. Now that all distros are dropping SMB1 support (including and in particular Microsoft) it will be interesting to see if Asus change course.
Changing the default root password is not supported in LE8 but is supported in LE9 (due in about 2-3 months).
-
You'll need Kodi 18 for hw 10 bit support.
-
gprintemps your log snippet shows nothing useful, upload your full log if you're not able to locate the error.
-
The list of available versions seems not to be updated - just a reboot helps to get the new versions.
Yes this is a known issue.
-
Or start with a clean minimalist system that shows minimal private information? And nobody cares about your internal LAN IPs - we all have them, and they're all pretty much the same.
As an alternative to submitting a log, are you able to identify the first nightly build with this issue? Although if the issue is in LE 8 then it's likely the test builds prior to LE 8 are no longer available.
The oldest nightly build of mine is from 12 months ago, does that have this issue?
-
Can you post the link to your complete debug log (a log that includes the same failure as above)?