Kernel oops running usb storage on PI3B+ #2481
Labels
Waiting for external input
Waiting for a comment from the originator of the issue, or a collaborator.
Comments
|
The top of the stacktrace is cut off, unfortunately. Can you add |
|
same issue here: |
|
another one |
|
A patch for that bug was applied to our current branch this afternoon. The latest firmware build, available via rpi-update, includes the patch. |
|
Correction - the patch actually went in yesterday, and the firmware was also available yesterday. Your kernel is very recent, but I'm hoping it was from the release before the one with the fix. |
|
|
crashes appear after: |
|
downgrade not possible using apt-get: using archived versions: |
|
Upgrade by running |
|
It looks like the patch is going to be merged to the stable 4.14 tree as part of the 4.14.32 release (https://www.spinics.net/lists/stable/msg230368.html) 👍 |
|
Ok, so I will wait for the 4.14.32 then. Thanks. |
|
I think I'm experiencing this too. I've been posting about it in this thread on the forum: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=208821 With the latest firmware, I'm still seeing crashes: I have a USB harddrive connected to a powered hub. The Pi is connected via wifi only. |
|
+1 I'm seeing this as well. I'm running stock Raspbian Stretch fully up-to-date. Just updated kernel using rpi-update so hopefully that will have fixed it - will report back. |
|
I think this is a different issue - the TCP bug caused failures in the TCP stack, whereas this looks like the result of a corruption of some kind (memory or filing system). |
|
I could add that the system is running as NAS with cable based ethernet connection and multiple hard discs connected via USB running btrfs on top of it. Moved back to 4.9.80 and reduced the clock speed to 1200 and it seems stable for now. |
Yes.
Sigh - too many tabs open. 6612300 is my temporary ethernet driver patch. A complete fix, including pre-open phy access, is proving to be elusively timing dependent, which may explain why the author of the original patch (V2 of which has now been submitted) didn't see a problem. |
|
It seems better with 4.14.32 and arm_freq=1200 set in the config.txt. Without the arm_freq set it crashes again. |
|
My system also suffers these kernel crashes, they either start with It´s on a brand new Pi 3 B+ ( Update:
--> I´m wondering if it´s a hardware or software issue, but definitely something with the Pi 3 B+. Sending it back, trying with another one? Waiting for software updates? Anything else I can test / provide the experts here? |
|
Please try with |
|
THX, found that information here a few minutes ago and set "arm_freq=1200" & "sdram_freq=450", will now switch hardware back to 3 B+ and take a close look. You ruled out it must be the sdram_freq, so "arm_freq=1200" is not necessary? |
Yes, for now, based on user feedback. If it turns out that reducing sdram_freq doesn't help in your case then we've learnt something that reducing them both together wouldn't have told us. |
|
Okay, after some really stable hours I‘ll switch now to only cut sdram frequency. I don’t know what’s the usual sdram freq („vcgencmd get_config int“ should show), but what we buy here for stability is performance. I don’t know how much, but... is it a kernel/Software thing which can be fixed or is it a hardware issue, so not all Pi 3 B + suffer this? Depending on this I‘m thinking of sending my current hardware back, trying my luck with a new/other one... |
|
The non-turbo sdram frequency is 400MHz on all devices. May also be worth running memtester (sudo apt-get install memtester). That tends to be a very effective way of testing if the sdram is not reliable at a given frequency. |
|
Well, even it´s just a temperature benchmark, the sdram frequency (at the end resulting in temperature, right?) seems to have no direct impact to the performance (core frequency of course has (a huge one)): System running smooth with only set sdram freq to 450 MHz, core back on default (1.4 GHz). |
|
As a general rule, RAM speed will have near zero impact on the temperature reported by the thermal sensor because the thermal sensor is in the CPU, not the RAM. Additionally though, 50MHz isn't likely to make much of a difference in terms of temperature difference even if you were looking at the RAM. There's unfortunately no particularly quick and easy method to test memory performance on a Pi. A quick and dirty option (but not very accurate) is to create a tmpfs mount, put a moderately large file on it (128M seems to work well) and then use |
|
Update: already had my first (watchdog initiated) reboot since changed config to only lower sdram frequency. Message from watchdog: This is „the“ typical behavior. Seems like 1.4 GHz is too much. Ok speaking clear: I spent something between 11 to 13 hours during the last week for investigating and fixing (e. g. almost 10 external fsck’s putting the SD card to another pi) all the issues coming from this unstable system on the Pi 3 B+. I‘m therefore very frustrated (first time in 5 years of Pi experience) and I think I‘ll return that piece of faulty Pi hardware and get another one. I want stability AND performance - and spend my time for more important things -.- |
|
@bcutter Would it be possible for you to send the Pi showing these symptoms to us? We would send you back a new 3B+ plus some goodies to cover the return postage? That way we could do the testing inhouse and save you some time. Please send email to [email protected] with a FAO to James Hughes so its gets to me. Thanks. |
|
@JamesH65 : sounds good, basically. Shipping costs and times might be a barrier (Germany - UK; with 9 € it´s a fourth of the Pi 3 B+ value)... but first thank you for this offer, I´ll think about it. |
|
We'll send you something on return that compensates for the postage costs. 9 € is insignificant to us to try and help figure out what the problem is, but I want to ensure you are not out of pocket. |
|
Is there something new to report? Many Plex users have the some problem with a Raspberry Pi 3 Model B (not+). A downgrade to 4.9.x immediately fixes this problem. Has 4.14.x been pushed to the official raspbian repo? Is is possible to remove this kernel upgrade form the official repos till this issue has been fixed? |
|
This issue is specific to the 3B+. If you are seeing problems on a 3B then create another issue, including the whole of any stack traces you have, a description of your setup (hardware and software) and what the Pi was doing when it crashed. |
|
@bcutter We would really like to get our hands on your 3B+. Email me - [email protected] - and I'll explain the deal. |
|
@pelwell if it helps I could send you my B+ I can revert to a 3B till I get a replacement |
|
Sure - use the email above. |
|
@pelwell: So at the moment I‘m restoring from a backup to a fresh SD card. After that I need to retest the Pi 3B+ Hardware with that healthy SD card (don’t want you to send a proper working Pi 3 B+ without very good reasons), at the moment I can not ensure it‘s the SD card causing all my troubles, even it started at the time when upgrading from Jessie to Stretch and switching to Pi 3 B+. I‘ll come back to you in the next days. To fasten my testing process: there‘s a guide on how to stress the memory which I didn’t try yet in the raspberrypi forums. I also know how to stress test CPU and storage, if I find time I will try that with different config.txt settings and check system stability during all runs - I think that‘s what you‘d also do in the first place. And the best cross check test is to run all that tests with my stable Pi 2 B of course. |
|
SD card now is fine. Tried several as ram overvoltage settings, nothing worked. Only stable setting is armfreq=1200 with sdram freq=450. Will send it back, it’s just unacceptable. |
|
Sounds like you have an outlying outlier SoC (worst case). Best thing it return it to the supplier, unless you can wait for the SW fix which might take a few days. |
|
Won´t a software fix slow down the Pi? I don´t understand how it could be fixed, if all that under (frequency) and overclocking (overvoltage) had no positive impact? I´m in contact with dom/Phil already. I´m willing to send mine to anyone of you if it helps to diagnose/analyse. I only want one thing: a powerful and stable Pi 3 B+ :-) |
|
The link between the SoC and the SDRAM has a number of adjustable parameters, and the hope is that with the right settings there will be no need to reduce the clocks. |
|
@comdata Are you and any others still seeing the USB issue? I suspect this was a 3B+ SoC/SDRAM timing issue rather than anything related to the USB. |
JamesH65
added
the
Waiting for external input
|
no the issue seems to be related to the specific unit. with the replacement
unit I can not see this issue and it survived the stress I put on it so far.
I would suggest to have the new unit running for week and if it doesn't occur we can close the ticket.
…On Mon, Apr 23, 2018 at 2:47 PM, James Hughes ***@***.***> wrote:
@comdata <https://github.com/comdata> Are you and any others still seeing
the USB issue? I suspect this was a 3B+ SoC/SDRAM timing issue rather than
anything related to the USB.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2481 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEe6z6sKKTLbJ-AOb1aGqcLoyr1rvwACks5trc1WgaJpZM4TAe8C>
.
|
|
haven't seen this issue on the replacement units so will close this. Thanks everyone. |
|
Great, thanks for the update, glad it's all working now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I am running a PI 3B+ with hard disks attached via USB. All hard disks are self powered. When running with 4.14.30 v7 I am getting regularly kernel oops under high load (e.g. compiling something)
Here is a screenshot:
Reverting back to 4.9.80 seems to fix the issue.
Kind Regards
The text was updated successfully, but these errors were encountered: