Active Topics

 


Reply
Thread Tools
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#31
Originally Posted by wicket View Post
It looks like switch_root is being called with incompatible arguments, probably due to the previous mount errors.

Make sure you have CONFIG_BLK_DEV_LOOP enabled. That should hopefully fix the /dev/loop0 errors.
wicket, how did you know that it was switch_root and why did the config option fix it?

filip.pz: what about disabling watchdog altogether? In the N900 world one did it with a flasher.
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following User Says Thank You to marmistrz For This Useful Post:
wicket's Avatar
Posts: 634 | Thanked: 3,266 times | Joined on May 2010 @ Colombia
#32
Originally Posted by marmistrz View Post
wicket, how did you know that it was switch_root and why did the config option fix it?
The kernel log displayed the usage of BusyBox's switch_root command. Command usage is often displayed when a command is executed with invalid arguments.

The "losetup: /dev/loop0: No such file or directory" error suggested that CONFIG_BLK_DEV_LOOP might not be enabled/loaded (see the help text for this config option for a description of what it does). It turned out that this wasn't the problem as Filip already had this enabled. He fixed it by enabling DMA.
__________________
DebiaN900 - Native Debian on the N900. Deprecated in favour of Maemo Leste.

Maemo Leste for N950 and N9 (currently broken).
Devuan for N950 and N9.

Mobile devices with mainline Linux support - Help needed with documentation.

"Those who do not understand Unix are condemned to reinvent it, poorly." - Henry Spencer

Last edited by wicket; 2015-09-20 at 21:50.
 

The Following 7 Users Say Thank You to wicket For This Useful Post:
filip.pz's Avatar
Posts: 108 | Thanked: 579 times | Joined on Feb 2013 @ Požega, Croatia
#33
Just an update on progress so far (or lack of it).

I've ported hack from 3.5.3 that deals with broken watchdogs, but it hasn't made any difference. To be sure that watchdogs are not to blame, I've used flasher to disable them (good idea marmistrz):
Code:
sudo flasher --enable-rd-mode --set-rd-flags=no-omap-wd,no-ext-wd,no-lifeguard-reset
but that didn't help.
Also wehen 3.5.3 gets compiled with:
Code:
CONFIG_WATCHDOG_NOWAYOUT=y
I also get warnings about watchdogs (thanks nieldk), twice about two independent watchdogs:
Code:
omap_wdt: Unexpected close, not stopping!
twl4030_wdt twl4030_wdt: Unexpected close, watchdog still running!
...
omap_wdt: Unexpected close, not stopping!
twl4030_wdt twl4030_wdt: Unexpected close, watchdog still running!
Funny thing is that in 4.3.0-rc2: I get two warnings of single watchdog:
Code:
watchdog watchdog0: watchdog did not stop!
...
watchdog watchdog0: watchdog did not stop!
I'll rechek if kernel knows about both watchdogs (omap_wdt and twl4030_wdt), and why I get warning for just one of them as opposed to 3.5.3 where both warn about Unexpected close

If nothing helps I'll try to disable systemd services that can't work at this stage, but can make problems (loading kernel modules, starting SGX driver) - still I would expect to see somthing in console, if that's the case
 

The Following 4 Users Say Thank You to filip.pz For This Useful Post:
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#34
I don't have any computer access right now, but I'll try the same with Debian when I have it. This way we'll make sure it's not Nemo-related.
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following 3 Users Say Thank You to marmistrz For This Useful Post:
filip.pz's Avatar
Posts: 108 | Thanked: 579 times | Joined on Feb 2013 @ Požega, Croatia
#35
Originally Posted by marmistrz View Post
I don't have any computer access right now, but I'll try the same with Debian when I have it. This way we'll make sure it's not Nemo-related.
That would be awesome!
I just tried disabling the wd hack in 3.5.3, and it boots, so event without that hack boot shouldn't fail (If I got it right that hack is just for suspend state when watchdogs can't be disabled, but userspace is suspended and doesn't kick them from time to time)
 

The Following 3 Users Say Thank You to filip.pz For This Useful Post:
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#36
Filip, did you put up your sources of the 4.x kernel on GH? If no, the please just list all changes from mainline 4.x / the old config
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following User Says Thank You to marmistrz For This Useful Post:
filip.pz's Avatar
Posts: 108 | Thanked: 579 times | Joined on Feb 2013 @ Požega, Croatia
#37
Originally Posted by marmistrz View Post
Filip, did you put up your sources of the 4.x kernel on GH? If no, the please just list all changes from mainline 4.x / the old config
Nothing public yet. I'll send you and e-mail containing two patches (one for building, and one with wd hack) in a few minutes.
 

The Following 2 Users Say Thank You to filip.pz For This Useful Post:
filip.pz's Avatar
Posts: 108 | Thanked: 579 times | Joined on Feb 2013 @ Požega, Croatia
#38
OK, new theory:

In 3.5.3 watchdogs were miscdevices and accessible trough filesystem. When filesystem got re/u/mounted drivers were getting release file operation called, and kicked the watchdogs, just before init - leaving enough time for userspace to take over.

Now watchdog drivers are in their own kernel class, and only first registered watchdog is linked to /dev/watchdog miscdevice for legacy reasons. So, in our case with 2 watchdogs, only omap_wdt gets kicked and twl4030_wdt doesn't. That doesn't leave enough time for userspace to start DSME that does the kicking in Mer based distros.

Maybe krenel should kick all watchdogs one last time before calling init. I'll test that tomorrow.
 

The Following User Says Thank You to filip.pz For This Useful Post:
filip.pz's Avatar
Posts: 108 | Thanked: 579 times | Joined on Feb 2013 @ Požega, Croatia
#39
Originally Posted by marmistrz View Post
I don't have any computer access right now, but I'll try the same with Debian when I have it. This way we'll make sure it's not Nemo-related.
I got Nemo to boot (kinda: http://pastie.org/10440946). Since OBS for Nemo is in a poor state, a lot of packages are not being updated to current versions so I added Jolla repo to update them. This prevents N9 from shutting down during the boot process (DSME gets loaded earlier preventing watchdogs to kick in).

Obviously, graphics are broken and that also prevents MCE from running (even if MCE complains about "config subsystem".) For now I'll try to build new SailfishOS image and continue developing on it, but I imagine that Debian would also be able to boot (probably to nothing usable, but still...)
 

The Following 17 Users Say Thank You to filip.pz For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#40
With respect to Debian, I have started to package some of the core components from Nemo (dsme, mce-dev. mce, statefs) as part of my Gtk3 work. There not definately not perfect yet and untested on arm as I've been running in a x86_64 container.

dsme I know needs some manual editing after installation as the packaged systemd service file is looking in the wrong place (ie /usr/lib instead of /usr/lib/x86_64-linux-gnu).

Need to change container at the moment as statefs requires fuse (fine with qemu but aiming to get working via lxc) and to work out why mce is playing up (fails to start, causes boot to be delayed by 3min then starts fine)

If they are of any use to anyone, there on my github page...once I remember to upload a wip oneshot package (nemo one is full of bashisms I need to learn to fix).
 

The Following 6 Users Say Thank You to Android_808 For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 09:13.