<Wizzup>
when I wrote 'just watchdog built in' I mean omap2plus_defconfig and then:
<Wizzup>
sed -i 's/CONFIG_OMAP_WATCHDOG=m/CONFIG_OMAP_WATCHDOG=y/' .config
<Wizzup>
sed -i 's/CONFIG_TWL4030_WATCHDOG=m/CONFIG_TWL4030_WATCHDOG=y/' .config
<Wizzup>
make -j16 ARCH=arm CROSS_COMPILE=armv7a-hardfloat-linux-gnueabi- oldconfig
<Wizzup>
The panic happens basically as soon as /sbin/init is started it seems
<mighty17[m]>
uvos: `gp2ap002 3-0044: read 70 mA from ADC` yay!!
<uvos>
mighty17[m]: what was the problem?
<mighty17[m]>
dont really know, added #define DEBUG and got the dmesg of driver being loaded
<uvos>
hmm
<mighty17[m]>
seems like driver was looking for adc channels before they were being loaded and causes -517, now with debugs i can confirm that gpadc and gp2a works (partially)
<uvos>
there is still something worn with the adc
inky has joined #maemo-leste
<uvos>
if you cant read any of the other channels via sysfs
<uvos>
*wrong
<mighty17[m]>
i can read all other channels as well now :D
inky_ has joined #maemo-leste
inky_ has quit [Read error: Connection reset by peer]
<bencoh>
mighty17[m]: you should probably use -EDEFER
<Wizzup>
still has a ton of drm backtraces, but I guess it was just really broken then
pere has joined #maemo-leste
<Wizzup>
same for 5.9; but that doesn't hit off mode
<Wizzup>
(didn't check 5.8 for fof mode)
uvos has quit [Ping timeout: 265 seconds]
<Wizzup>
tmlind: hmm 5.10 (no stable patches applied) also has oops that looks very much like the one we're seeing in 5.10.y and 5.15.y - https://dpaste.com/G3LLXJBTX.txt
<Wizzup>
but it might not be the same, so that will make the bisect quite annoying :(
<Wizzup>
tmlind: what about 0a27398d8969f0def188ab46f932ea1366874bd4 ?
<Wizzup>
that is ec76c2eea903947202098090bbe07a739b5246e9 upstream
inky has joined #maemo-leste
<Wizzup>
tmlind: hm on top of v5.10 I tried to revert 21b2cec61c04bd175f0860d9411a472d5a0e7ba1 (the commit that ec76c2eea903947202098090bbe07a739b5246e9 tries to fix) and when I do that I get the same oopses as I get on 5.10.y and 5.15.y
<Wizzup>
tmlind: also, your test setup, does it use sd cards?
inky has quit [Ping timeout: 240 seconds]
inky has joined #maemo-leste
<Wizzup>
hm, looks like v5.9 ... v5.10 diff also has a commit that enables off mode automatically
inky has quit [Ping timeout: 240 seconds]
<Wizzup>
ok, getting closer
<bencoh>
do you think your issue is related to off mode?
<bencoh>
if so you could disable the idle state(s)
<bencoh>
and see if it fixes it
<Wizzup>
I emailed linux-omap with some info
<Wizzup>
the problem is not ec76c2eea903947202098090bbe07a739b5246e9
<Wizzup>
It looks like it was introduced between v5.9 and v5.10 though, but if I bisect that I'll have to revert another commit all the time that causes another regressi
<Wizzup>
on
<Wizzup>
I suppose that's feasible, just not sure if that's standard practice
uvos has joined #maemo-leste
<uvos>
Wizzup: sure git bisect has a option to carry a patch for you
<uvos>
hopefully your commit is non invasive
<Wizzup>
this being a race and all I might be unlucky but reverting fb2c599f056640d289b2147fbe6d9eaee689f1b2 on top of v5.10 (with the other regression reverted as well) makes the boot problem go away
<uvos>
sure
<uvos>
might also happen at any point during the bisect
<uvos>
causeing false bad commits
<Wizzup>
I didn't do a bisect
<Wizzup>
I just took v5.10 and figured that commit might cause the problem
<bencoh>
but it could be interactions with other components yeah (pvr?)
<Wizzup>
no, it's not with powervr for sure
<Wizzup>
all my testing was without powervr
<Wizzup>
5.7,5.8,5.9,5.10,5.10.y,5.15.y - tried all without powervr
<uvos>
for all the pvr bashiing we do pvr_k so far has really not been the cause of any issues.
<Wizzup>
hehe
<bencoh>
:)
eniac_petrov has quit [Quit: Leaving]
<Wizzup>
freemangordon: btw I think maybe the d4 resource crash is because of rotation, maybe try to do some automated rotation test
<Wizzup>
freemangordon: just a hunch though
<bencoh>
you could spawn "stress" commands with various random arguments (cpu/io/vm) for random period of times and add sleeping periods in between to try to reproduce the issue with init=/bin/sh
<bencoh>
(for instance)
<Wizzup>
what problem is this exactly?
<bencoh>
?
inky_ has joined #maemo-leste
<Wizzup>
bencoh: so I don't know why this commit causes the problems, but I know that we already hit off mode on n900 in init=/bin/sh ... ah I see, you're suggesting that it only happens in OFF mode and some interactions
<bencoh>
that's more or less what you suggested as well
<bencoh>
so trying to simulate various loads from a single-user shell might help reproducing it
<Wizzup>
well, I am not sure if the problem still exists with this commit reverted
<bencoh>
(basically forcing idle transations with various load patterns)
<Wizzup>
it manifested itself even without off mode ever being hit on leste UI
<Wizzup>
and it enabled it based on some dts compatible entry
<bencoh>
I mean, keep the patch in, boot to single-user shell
<bencoh>
and try to make the issue appear
<bencoh>
ah
<Wizzup>
so it's possible that the PWRDM change is simply what causes the problems
<Wizzup>
I'll wait for Andreas/Tony to comment first, I can continue with my stuff with this commit reverted
_inky has quit [Ping timeout: 240 seconds]
inky has quit [Ping timeout: 268 seconds]
<Wizzup>
so next thing: with /etc/init.d/n900-powermanagement start, gpio_keys falsely reports slide changes
<bencoh>
I vaguely remember troubleshooting it years ago, and iirc the bottomline was that having desktop widgets prevented hildon from sleeping properly (ie it wokeup way more)
<Wizzup>
it depends on how the widget behaves I think
<Wizzup>
the calendar one is fine
<uvos>
also desktop command widget seams fine
<bencoh>
oh, the TMO/leste forum is getting some activity, nice :)
<uvos>
but the way the widgets work is _terrible_ imo
<freemangordon>
what is terrible about it?
<uvos>
having random packages load plugins into hildon-home is a bad idea form a reliablity perspective
<bencoh>
uvos: actually iirc I tried desktop command widget back then
<uvos>
and it forces a toolkit on the widgets
<uvos>
the widgets should just be embeded x windows
<bencoh>
(but heh, it was ... years ago)
<uvos>
or pixmaps the widget sends
<freemangordon>
oh, you force xorg
<uvos>
wayland has the same window embeding
<uvos>
and the toolkits abstract it
<freemangordon>
what about wayland? :P
<uvos>
so no
<freemangordon>
also, how is that going to work on windows?
<uvos>
should work on windows to
<uvos>
really
<freemangordon>
great
<uvos>
if you want
<freemangordon>
anyways, I am not in a mood to be productive :)
<freemangordon>
So lets not distract others at least
* freemangordon
is afk
<dsc_>
anyway to get "the battery status" via terminal command?
<dsc_>
or some other way to visually know what the battery charge is
<Wizzup>
yeah... this is a bit tricky
<Wizzup>
upower has the info, but mce also some
<dsc_>
I'm hooked into USB power, so the battery icon will animate, but it wont actually show the charge
<tmlind>
Wizzup: so if reverting fb2c599f056640d289b2147fbe6d9eaee689f1b2 makes things behave, sounds like the system enters some idle mode during init before things are ready or something like that
<tmlind>
Wizzup: maybe try to enable off mode automatically only with a late_initcall?
<Wizzup>
tmlind: what do you mean, late initcall? do you mean through init script?
<Wizzup>
that works
<tmlind>
hmm well omap2_common_pm_late_init() is already late_initcall it seems and that ends up calling omap3_pm_init()
<Wizzup>
well, doing it through debugfs works ok
<tmlind>
maybe twl is not fully initialized at that point yet?
<Wizzup>
also this sometimes caused problems way later in the boot process, like 300s in
<Wizzup>
so I think there's something else that this commit is also affecting
<Wizzup>
maybe wrt module loading
<tmlind>
if twl4030_power_probe() has not completed before deeper idle states the regulator voltages will be all wrong for idle modes
<Wizzup>
sorry brb 15 mins
sunshavi_ has quit [Quit: ERC (IRC client for Emacs 27.2)]