Hi Daniel,
Let's move the discussion to opensuse-arm list.
Am 23.11.2017 um 12:07 schrieb Daniel Molkentin:
> On 11/22/2017 06:31 PM, Andreas Färber wrote:
>> Am 22.11.2017 um 04:25 schrieb Dominique Leuenberger:
>>> ==== kernel-source ====
>>> Version update (4.13.12 -> 4.14.0)
>>> Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs kernel-macros kernel-syms
>>>
>>> - Update to 4.14-final.
>> On the aarch64 based Pine64 board it has been observed that the updated
>> dtb-allwinner package now requires the axp20x-regulator module in the
>> initrd for using the MMC driver, and its parent module axp20x-rsb does
>> not get loaded automatically even if added to the initrd.
> I would prefer if that would be fixed in the kernel by adding the proper
> dependencies.
> Is there any chance for that?
There's multiple issues at play here:
1) This is not a module compile-time dependency issue, but rather a
run-time dependency issue, which AFAIU dracut is not resolving today.
As a result the JeOS images in openSUSE:Factory:ARM etc. contain a
number of add_drivers entries to load such extra modules:
https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/JeOS/conf…
That is of course ugly and would be nice to get resolved differently.
Dracut would need to parse the Device Tree in /sys/firmware/ to discover
what regulator, clock, power domain, etc. nodes are being referenced,
then read their "compatible" strings and resolve them to the modules to
add. The kernel uses generic API calls such as clk_get() and
regulator_get(), thus no compile-time dependency for e.g. mmc modules.
However when updating from 4.13 to 4.14 or from 4.14-rc4 to -rc8 it
would've still read the current Device Tree and not discovered this new
dependency for next boot. And Kiwi images get built in KVM, which will
have a different Device Tree than the user's system or even ACPI. So I
don't see a full solution yet.
Let me know if I should report this somewhere upstream - it didn't seem
a distro-specific issue for our Bugzilla.
https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_troubleshoo…
explains what info to include in a bug report, but not actually where to
file it. ;) No link on dracut.wiki.kernel.org either.
2) axp20x-rsb driver does have MODULE_DEVICE_TABLE(of, ...), so it is
unclear to me why the DT -> module resolution for auto-loading is not
working here.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri…
It is almost certainly an upstream kernel issue, possibly in sunxi-rsb
bus driver. Stefan has already reported this on #linux-sunxi.
> Otherwise, the "proper" dracut patch would
> looks something like the attached one.
Hm, instmod is just the equivalent of "add_drivers", is it? That would
not be enough here. Also not all ARM systems need this driver, it's an
extra chip on some boards only.
What you could do is more generally add all =drivers/mfd drivers. But if
we keep adding drivers by category instead of addressing the underlying
discovery issue, we risk at some point the initrd getting too large for
low-RAM systems.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Am 22.11.2017 um 04:25 schrieb Dominique Leuenberger:
> ==== kernel-source ====
> Version update (4.13.12 -> 4.14.0)
> Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs kernel-macros kernel-syms
>
> - Update to 4.14-final.
> - commit c152297
> - rpm/kernel-binary.spec.in: rename kGraft to KLP (fate#323682)
> - commit 0ed191d
On the aarch64 based Pine64 board it has been observed that the updated
dtb-allwinner package now requires the axp20x-regulator module in the
initrd for using the MMC driver, and its parent module axp20x-rsb does
not get loaded automatically even if added to the initrd.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/a…
Workaround is to add to your /etc/dracut.conf.d/sunxi_modules.conf:
force_drivers+=" axp20x-rsb "
and (if after the update) to re-run dracut by, e.g., mkinitrd.
Without such an initrd change it will wait indefinitely for the root
partition on SD card on next boot.
Selecting an older kernel in GRUB will not help - only manually loading
an older dtb in U-Boot can help (if e.g. you had multiversion enabled).
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
On 22/11/17 03:25, Dominique Leuenberger wrote:
>
> ==== kernel-source ====
> Version update (4.13.12 -> 4.14.0)
> Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs kernel-macros kernel-syms
>
> - Update to 4.14-final.
> - commit c152297
> - rpm/kernel-binary.spec.in: rename kGraft to KLP (fate#323682)
> - commit 0ed191d
>
fwiw it's seems there is a 4.14 regression with bcache
https://marc.info/?l=linux-bcache&m=151082122518597&w=2https://www.reddit.com/r/linux/comments/7eh2oz/serious_regression_in_linux_…
The fix is in https://github.com/torvalds/linux/commit/62530ed8b1d but
it missed 4.14.1
So be careful when you update to that kernel.
--
markos
SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hello,
On opensuse-arm list a kernel fault for 4.14.0 (latest TW kernel) has been reported.
Here is the kernel trace: http://paste.opensuse.org/96574215
Note that previous kernel 4.13.* was ok.
Any idea?
Guillaume
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hi all,
Some times ago (after 4.4.92 hit Leap update repository) I've filled the
following bug https://bugzilla.opensuse.org/show_bug.cgi?id=1064533 due to
warnings and kernel trace about a raid10.
Yesterday, after checking every disk with smart test long and as none of them
reported an error I've readded the previously failing harddrive.
There was one suspicious things, the resynchronisation at half an hour of the
estimate time suddendly was ok.
I've rebooted the server at that time, and then start to cry (just a bit),
filesystem stored in lv or vm image were all destroyed (fsck.ext4 couldn't fix
it auto, and even forced, when you tried to rewrite on it it failed)
I've added all the informations I can for the moment to the mentionned bug.
But I guess there's a number missing, Don't hesitate to comment here, or
directly in the bug and ask for more information.
The system as it is should still be present during the next 10 days.
Thanks for your help and advise.
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
Bareos Partner, openSUSE Member, fsfe fellowship
GPG KEY : D5C9B751C4653227
irc: tigerfoot
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
On Dienstag, 14. November 2017 17:08:18 CET Jan Engelhardt wrote:
> On Tuesday 2017-11-14 16:47, Andreas Schwab wrote:
> >On Nov 14 2017, Jan Engelhardt <jengelh(a)inai.de> wrote:
> >> I have a feeling though, that such won't be enough to get those
> >> unspeakably fat browsers to link - it may become necessary to use a
> >> 64-bit toolchain with -m32 to complete it, and then the baselibs
> >> mechanism to export the build results.>
> >Getting all build dependencies ready for -m32 would be a challenge,
> >though.
>
> It could yes. The alternative would be to run a 32-bit userspace with a
> 64-bit linker program, requiring only a few -64bit baselibs.
> If we ever do x32, modifying mkbaselibs will be a necessity anyway.
> Might as well do it now :-)
For the time being, can we just package kernel-(l)pae as kernel-obs-build on
32 bit archs, i.e. i586/armv7l?
A PAE-enabled kernel has a slight overhead, but this is likely more than
compensated by hitting the guests swap later.
This does not change the 3GByte per process limit, which may cause failing
linker runs. Using a 64bit linker is much more effort, so I would vote for a
PAE kernel first and *if* we still see OOM errors, reconsider if we should go
the 64bit userspace route (i586 is quite dead, but armv7l may stay for a bit
longer).
CC'ed opensuse-kernel, as I already sent a patch addressing kernel-obs-build a
week ago.
Kind regards,
Stefan
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hi,
The Security Team is currently evaluating IMA/EVM binary/file protection mechanisms.
Most of the stuff lives only in Tumbleweed, so could someone (Jeff Mahoney?) please
enable CONFIG_IMA and friends similar to Leap 42 and SLES?
Ciao, Marcus
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org