On Do, 2018-10-04 at 09:41 +0200, Michael Mrozek wrote:
Okay, it froze again after 1:14 hours this time.
So it's improved but still freezes (it gets very hot after a freeze, btw).
Just some idea:
* As notaz mentioned, it doesn't seem to freeze when the CPU is under load. Tonys memtest with CPU load seems to confirm that.
* I remember that Nikolaus mentioned a while ago that he did a full apt-get upgrade with the 4GB board and that worked without any freeze as well.
* It freezes pretty fast when it's idling
* It also freezes but not that fast when no drivers are loaded (when it's still idling).
So, here is my idea: Could it be that the freeze happens when the OMAP switches between voltages / frequencies (well, not always but sometimes)? Or maybe if it switches to ONE special voltage / frequency?
Because:
1. Under full load, it doesn't switch voltage / frequency 2. When idling with drivers loaded, it probably changes voltage / frequency often, as the drivers ocassionally do something 3. When idling WITHOUT all drivers loaded, a lot less is going on and it would switch voltage / frequency less often (therefore, less likely freezes)
That would explain the behaviour we have here.
Can someone create me a finished U-Boot / MLO (or wherever that information is stored) that only allows one fixed voltage / frequency?
Thanks!
On Do, 2018-10-04 at 07:51 +0200, H. Nikolaus Schaller wrote:
Well, didn't help it seems, just delayed it.
It now froze after 3 hours and 10 minutes.
I'll do another start to see if this was just random or if it also survives longer this time.
I am currently hunting another observation: on my lc15 eval board the lpae kernel freezes during boot with an older 2GB RAM board that othweise works without freezes... So it might have to do something with LPAE.
Hm, even though NOT using LPAE didn't fix the freeze for notaz' 4GB unit.
I'll let it run as long as possible (no idea how much battery it has left), but it could very well be that one driver is causing the freeze.
I'm planning to setup a small script that modprobes one driver after the other, waits for 10 minutes, and then loads up the next one - until we have the freeze.
Question: Is there a way to find out what modules are being loaded normally? So I know which ones I need to load manually with the script?
lsmod | cut -d ' ' -f 1 | fgrep -v 'Module'
omapdrm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm drm_panel_orientation_quirks bnep bluetooth ecdh_generic usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs ipv6 arc4 wl18xx wlcore mac80211 snd_soc_omap_hdmi_audio snd_soc_dmic panel_boe_w677l cfg80211 dwc3 snd_soc_simple_card snd_soc_omap_abe_twl6040 snd_soc_simple_card_utils snd_soc_twl6040 leds_gpio snd_soc_gtm601 pwm_omap_dmtimer wwan_on_off encoder_tpd12s015 connector_hdmi omapdss snd_soc_w2cbw003_bt omapdss_base generic_adc_battery cec pwm_bl ehci_omap wlcore_sdio dwc3_omap snd_soc_ts3a227e bmp280_spi bq27xxx_battery_i2c leds_is31fl319x bq2429x_charger bq27xxx_battery crtouch_mt tsc2007 ina2xx tca8418_keypad as5013 gpio_twl6040 twl6040_vibra palmas_gpadc bmp280_i2c palmas_pwrbutton bmc150_magn_i2c bmc150_accel_i2c bmp280 bmc150_magn bmc150_accel_core bno055 industrialio_triggered_buffer kfifo_buf industrialio usb3503 w2cbw003_bluetooth snd_soc_omap_aess snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_sdma
Some modules may be loaded automatically by another one.
Thanks!
Hello,
I'm back and I've done some tests, no useful conclusions though. I have 2 4GB boards now, I'll call them old one and new one.
- the old board also hangs, although it seems to take much
longer (3 hours at least)
- the new one hangs in minutes, but occasionally it can run for
half an hour or so
- u-boot tester doesn't fail on new one, although I haven't
tried it for too long (less than 10 minutes)
- memtester (on Linux) doesn't fail on new one, it also seems
to allow the new board to survive much longer. I think it survived overnight but hung later when I was at work.
ideas:
- perhaps the problem has something to do with idle/power
saving. Need to check if there are RAM registers related to that. Does anyone know if it currently tries to do RAM self-refresh while idle?
- try without any TILER patches. I can vaguely remember it was
said the TILER can't be used at all because of some errata, but Matt proved otherwise. Maybe with 4GB/LPAE the problem actually triggers.
Gražvydas
On Mon, Oct 1, 2018 at 9:15 PM H. Nikolaus Schaller < hns@goldelico.com> wrote:
Hi Askarus,
Am 01.10.2018 um 19:45 schrieb Nino Bock < askarus@openpandora.org > :
Hello everyone,
in the forums EvilDragon said: "4GB RAM boards were working with only 2GB RAM enabled (as far as I remember - as that was the reason I ordered the RAM modules back then!)"
Did anyone with a 4GB Pyra try running it with only 2GB enabled?
Yes. We did that several times. Sometimes even unplanned (copying a non-LPAE kernel to the SD card).
Might it work if we only populate it with half the amount of RAM chips?
Unlikely. There are two separate busses from OMAP5 to 2 RAM chips each. So if one bus makes trouble it still will do if the other one is not used.
The only differences may be power demand and cross-talk.
These are important questions. If one of these options does actually work it will be fine for the first batch.
Of course it's better to fix things but we are at a state where we should start production as soon as possible. Either of these possibilities would bring some Pyras to life and be of no additional cost.
Maybe that's silly but if there is a chance that EvilDragon's memories are true, then for me it's obvious what to do.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel