Bug#870185: armel/marvell kernel size

[Roger Shimizu]

On Mon, Aug 21, 2017 at 12:43 AM, Ben Hutchings  wrote:
>
> OK, then try using 4.11.6 source and bisecting the Debian config
> changes.

Result:
0905519af414d339f615d7aac974f9a9163cdbd3 is the first bad commit

Here's the detailed log.

$ git bisect log
git bisect start
# good: [327c328b5435d93c2d3294059882629a6f8f1861] Update to 4.11-rc7
(and credit Lukas for his previous work)
git bisect good 327c328b5435d93c2d3294059882629a6f8f1861
# bad: [aca58f89537f4c470cc1e9102c1249e39a4b13a3] Prepare to release
linux (4.11.3-1~exp1).
git bisect bad aca58f89537f4c470cc1e9102c1249e39a4b13a3
# good: [3f68b53e2c3d425af23d0fbc33ef1e5f932484ab] usbip: Enable
USBIP_VUDC as module
git bisect good 3f68b53e2c3d425af23d0fbc33ef1e5f932484ab
# bad: [0a348a06ca2392fe337580ba007f325bdb111ff1] [armel] udeb: Add
af_packet. firmware_class, nls_base to kernel-image (fixes FTBFS)
git bisect bad 0a348a06ca2392fe337580ba007f325bdb111ff1
# good: [472b038c1a71a837c1cd30d49f6cda385e9dd540] udeb: Move mfd-core
to kernel-image, as both input-modules and mmc-modules need it
git bisect good 472b038c1a71a837c1cd30d49f6cda385e9dd540
# bad: [2d277e1fa20d2fe1fc5414f3806fded57bf9200b] Update to 4.11
git bisect bad 2d277e1fa20d2fe1fc5414f3806fded57bf9200b
# bad: [0905519af414d339f615d7aac974f9a9163cdbd3] Clean up kconfig
using kconfigeditor2
git bisect bad 0905519af414d339f615d7aac974f9a9163cdbd3
# good: [0e0b29ad5ab36d7268f8a50fb5a5c90cea4186c9] [arm64,x86] Replace
securelevel patch set with lockdown patch set
git bisect good 0e0b29ad5ab36d7268f8a50fb5a5c90cea4186c9
# good: [259372e240d0021eb2acdc98bd61b6adb84d645e] [x86] Make
hyperv-modules depends on nic-shared-modules
git bisect good 259372e240d0021eb2acdc98bd61b6adb84d645e
# first bad commit: [0905519af414d339f615d7aac974f9a9163cdbd3] Clean
up kconfig using kconfigeditor2

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#872765: linux-image-4.13.0-rc5-amd64: cannot open audio mixer

[Ricardo Fabian Peliquero]

Package: src:linux
Version: 4.13~rc5-1~exp1
Severity: normal

Dear Maintainer,

After upgrading from linux-image-4.12.0-1-amd64 to linux-image-4.13.0-rc5-amd64,
aumix will not work.

The following error appears while booting:

  Linux hp425 4.13.0-rc5-amd64 #1 SMP Debian 4.13~rc5-1~exp1 (2017-08-14) 
x86_64 GNU/Linux

  [FAIL] Restoring mixer settings...[] failed. ... failed!

  ...

  login: [   22.327889] random: crng init done


And this error appears after running aumix (either as normal user or as root):

 aumix:  error opening mixer: No such file or directory

It is not possible to hear audio with this scenario.


I've installed alsa-utils, and alsamixer will do the job, but won't hear any 
audio after
switching back to aumix.


Downgrading to linux-image-4.12.0-1-amd64 will also solve the problem. That is, 
this
message will show while booting:

  [ ok ] Restoring mixer settings... mixer mixer1[] done..

and aumix will work as expected as normal user.


You will find dmesg's output below, but bear in mind that mixer settings 
restoring is
disabled (echo 'SAVEMIXER=no' > /etc/default/aumix).

Kindest regards,

Ricardo



-- Package-specific info:
** Version:
Linux version 4.13.0-rc5-amd64 (debian-kernel@lists.debian.org) (gcc version 
6.4.0 20170805 (Debian 6.4.0-3)) #1 SMP Debian 4.13~rc5-1~exp1 (2017-08-14)

** Command line:
auto BOOT_IMAGE=Linux ro root=UUID=d83c21d8-53d3-46e2-8772-82e9dd92546c edd=off

** Tainted: W (512)
 * Taint on warning.

** Kernel log:

[0.00] random: get_random_bytes called from start_kernel+0x3d/0x456 
with crng_init=0
[0.00] Linux version 4.13.0-rc5-amd64 (debian-kernel@lists.debian.org) 
(gcc version 6.4.0 20170805 (Debian 6.4.0-3)) #1 SMP Debian 4.13~rc5-1~exp1 
(2017-08-14)
[0.00] Command line: auto BOOT_IMAGE=Linux ro 
root=UUID=d83c21d8-53d3-46e2-8772-82e9dd92546c edd=off
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000ef000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xafce] usable
[0.00] BIOS-e820: [mem 0xafcf-0xafdcefff] reserved
[0.00] BIOS-e820: [mem 0xafdcf000-0xafecefff] ACPI NVS
[0.00] BIOS-e820: [mem 0xafecf000-0xafefefff] ACPI data
[0.00] BIOS-e820: [mem 0xafeff000-0xafef] usable
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffe0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00013fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.6 present.
[0.00] DMI: Hewlett-Packard HP 425/1475, BIOS 68DVA Ver. F.03 08/13/2010
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x14 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-D uncachable
[0.00]   E-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask 8000 write-back
[0.00]   1 base 8000 mask E000 write-back
[0.00]   2 base A000 mask F000 write-back
[0.00]   3 base 0001 mask C000 write-back
[0.00]   4 base FFE0 mask FFE0 write-protect
[0.00]   5 base FFF4 mask  write-protect
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00014000 aka 5120M
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] e820: last_pfn = 0xaff00 max_arch_pfn = 0x4
[0.00] Base memory trampoline at [94a500099000] 99000 size 24576
[0.00] Using GB pages for direct mapping
[0.00] BRK [0x12c357000, 0x12c357fff] PGTABLE
[0.00] BRK [0x12c358000, 0x12c358fff] PGTABLE
[0.00] BRK [0x12c359000, 0x12c359fff] PGTABLE
[0.00] BRK [0x12c35a000, 0x12c35afff] PGTABLE
[0.00] BRK [0x12c35b000, 0x12c35bfff] PGTABLE
[0.00] BRK [0x12c35c000, 0x12c35cfff] PGTABLE
[0.00] BRK [0x12c35d000, 0x12c35dfff] PGTABLE
[

Processed: tagging 872644, tagging 872644 ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 872644 - moreinfo
Bug #872644 [src:linux] linux-image-4.12.0-1-686-pae: 
Olinux-imag-4.12.0-1-686-pae sends crash messags at boot
Removed tag(s) moreinfo.
> tags 872644 + upstream
Bug #872644 [src:linux] linux-image-4.12.0-1-686-pae: 
Olinux-imag-4.12.0-1-686-pae sends crash messags at boot
Added tag(s) upstream.
> retitle 872644 [4.12 regression] i915 triggers WARNING in 
> drm_atomic_helper_update_legacy_modeset_state()
Bug #872644 [src:linux] linux-image-4.12.0-1-686-pae: 
Olinux-imag-4.12.0-1-686-pae sends crash messags at boot
Changed Bug title to '[4.12 regression] i915 triggers WARNING in 
drm_atomic_helper_update_legacy_modeset_state()' from 
'linux-image-4.12.0-1-686-pae: Olinux-imag-4.12.0-1-686-pae sends crash messags 
at boot'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
872644: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872644
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#872726: linux: apparmor doesn't use proper audit event ids

[Vincas Dargis]

This is upstream bug report:
https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1117804

Bug#872726: linux: apparmor doesn't use proper audit event ids

[Vincas Dargis]

On Sun, 20 Aug 2017 16:42:55 +0200 Laurent Bigonville  wrote:

IMVHO, in regard to the recent proposal of enabling apparmor in debian
by default, this needs to be addressed first.


Yes this is very important, although we have aa-logprof to be used as auditing
tool, but I agree that not seeing AppArmor events in your custom auditd report
is rather bad.

We could ask John Johansen if he has it on it's queue. He is upstreaming Ubuntu
patches to mainline Linux, so I guess we depend on his work entirely.

Bug#872644: linux-image-4.12.0-1-686-pae: Olinux-imag-4.12.0-1-686-pae sends crash messags at boot

[Hans]

> These messages should still be copied to /var/log/messages.  However if
> you're using sysvinit, they might go into /var/log/dmesg instead.
> Please check there.
> 
> Ben.

Hi Ben,

you are correct, I found these messages in /var/log/messages. I send them 
below, maybe they are useful:

--- snip ---

Aug 14 16:20:50 localhost kernel: [   22.342509] [ cut here 
]
Aug 14 16:20:50 localhost kernel: [   22.342534] WARNING: CPU: 1 PID: 102 at /
build/linux-J4LMtv/linux-4.11.6/drivers/gpu/drm/drm_atomic_helper.c:796 
drm_atomic_helper_update_legacy_modeset_state+0x232/0x260 [drm_kms_helper]
Aug 14 16:20:50 localhost kernel: [   22.342536] Modules linked in: 
snd_hda_codec_realtek snd_hda_codec_generic sg ath9k(+) ath9k_common 
snd_hda_intel ath9k_hw ath snd_hda_codec snd_hda_core snd_hwdep lpc_ich 
snd_pcm_oss mfd_core mac80211 snd_mixer_oss i915 snd_pcm rng_core snd_timer 
cfg80211 drm_kms_helper snd soundcore shpchp drm i2c_algo_bit eeepc_laptop(+) 
sparse_keymap rfkill battery ac video button wmi acpi_cpufreq gspca_sn9c20x 
gspca_main v4l2_common videodev media loop atl1 mii parport_pc ppdev lp 
parport ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto 
mbcache ecb lrw gf128mul algif_skcipher af_alg uas usb_storage dm_crypt dm_mod 
crypto_simd cryptd aes_i586 sd_mod ahci libahci libata psmouse scsi_mod 
uhci_hcd ehci_pci ehci_hcd usbcore usb_common atl1c thermal
Aug 14 16:20:50 localhost kernel: [   22.342665] CPU: 1 PID: 102 Comm: 
kworker/u4:2 Not tainted 4.11.0-1-686-pae #1 Debian 4.11.6-1
Aug 14 16:20:50 localhost kernel: [   22.342668] Hardware name: ASUSTeK 
Computer INC. \x931005HAG\x94/1005HAG, BIOS 040103/02/2010
Aug 14 16:20:50 localhost kernel: [   22.342678] Workqueue: events_unbound 
async_run_entry_fn
Aug 14 16:20:50 localhost kernel: [   22.342682] Call Trace:
Aug 14 16:20:50 localhost kernel: [   22.342695]  ? dump_stack+0x55/0x73
Aug 14 16:20:50 localhost kernel: [   22.342701]  ? __warn+0xea/0x110
Aug 14 16:20:50 localhost kernel: [   22.342716]  ? 
drm_atomic_helper_update_legacy_modeset_state+0x232/0x260 [drm_kms_helper]
Aug 14 16:20:50 localhost kernel: [   22.342729]  ? 
drm_atomic_helper_update_legacy_modeset_state+0x232/0x260 [drm_kms_helper]
Aug 14 16:20:50 localhost kernel: [   22.342735]  ? warn_slowpath_null+0x2a/
0x30
Aug 14 16:20:50 localhost kernel: [   22.342748]  ? 
drm_atomic_helper_update_legacy_modeset_state+0x232/0x260 [drm_kms_helper]
Aug 14 16:20:50 localhost kernel: [   22.342890]  ? intel_atomic_commit_tail
+0x945/0xee0 [i915]
Aug 14 16:20:50 localhost kernel: [   22.342899]  ? __switch_to+0xa1/0x3a0
Aug 14 16:20:50 localhost kernel: [   22.343031]  ? intel_atomic_commit
+0x388/0x460 [i915]
Aug 14 16:20:50 localhost kernel: [   22.343061]  ? drm_mode_object_reference
+0x3e/0x60 [drm]
Aug 14 16:20:50 localhost kernel: [   22.343089]  ? 
drm_atomic_set_crtc_for_connector+0xb1/0x100 [drm]
Aug 14 16:20:50 localhost kernel: [   22.343116]  ? drm_atomic_commit+0x4b/
0x60 [drm]
Aug 14 16:20:50 localhost kernel: [   22.343130]  ? restore_fbdev_mode
+0x153/0x2c0 [drm_kms_helper]
Aug 14 16:20:50 localhost kernel: [   22.343157]  ? drm_modeset_lock_all_ctx
+0xa4/0xb0 [drm]
Aug 14 16:20:50 localhost kernel: [   22.343171]  ? 
drm_fb_helper_restore_fbdev_mode_unlocked+0x27/0x70 [drm_kms_helper]
Aug 14 16:20:50 localhost kernel: [   22.343184]  ? drm_fb_helper_set_par
+0x2d/0x63 [drm_kms_helper]
Aug 14 16:20:50 localhost kernel: [   22.343316]  ? intel_fbdev_set_par
+0x15/0x70 [i915]
Aug 14 16:20:50 localhost kernel: [   22.343329]  ? fbcon_init+0x53d/0x590
Aug 14 16:20:50 localhost kernel: [   22.343338]  ? visual_init+0xbb/0x120
Aug 14 16:20:50 localhost kernel: [   22.343344]  ? do_bind_con_driver
+0x174/0x360
Aug 14 16:20:50 localhost kernel: [   22.343351]  ? do_take_over_console
+0x11b/0x190
Aug 14 16:20:50 localhost kernel: [   22.343358]  ? do_fbcon_takeover+0x5f/
0xc0
Aug 14 16:20:50 localhost kernel: [   22.343366]  ? notifier_call_chain+0x4e/
0x70
Aug 14 16:20:50 localhost kernel: [   22.343374]  ? 
__blocking_notifier_call_chain+0x39/0x60
Aug 14 16:20:50 localhost kernel: [   22.343381]  ? 
blocking_notifier_call_chain+0x1f/0x30
Aug 14 16:20:50 localhost kernel: [   22.343387]  ? register_framebuffer
+0x1f6/0x340
Aug 14 16:20:50 localhost kernel: [   22.343406]  ? 
drm_fb_helper_initial_config+0x23a/0x3f0 [drm_kms_helper]
Aug 14 16:20:50 localhost kernel: [   22.343541]  ? intel_fbdev_initial_config
+0x16/0x30 [i915]
Aug 14 16:20:50 localhost kernel: [   22.343551]  ? async_run_entry_fn
+0x35/0x190
Aug 14 16:20:50 localhost kernel: [   22.343558]  ? __schedule+0x2d7/0x8e0
Aug 14 16:20:50 localhost kernel: [   22.343564]  ? process_one_work
+0x150/0x380
Aug 14 16:20:50 localhost kernel: [   22.343570]  ? process_one_work
+0x150/0x380
Aug 14 16:20:50 localhost kernel: [   22.343576]  ? worker_thread+0x41/0x480
Aug 14 16:20:50 localhost kernel: [   22.343582]  ? kthread+0xdb/0x110
Aug 14 16:20:50 localhost kernel: 

Processed: tagging 872726

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 872726 + upstream
Bug #872726 [src:linux] linux: apparmor doesn't use proper audit event ids
Added tag(s) upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
872726: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872726
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#870185: armel/marvell kernel size

[Ben Hutchings]

On Sun, 2017-08-20 at 21:16 +0900, Roger Shimizu wrote:
> On Sun, Aug 20, 2017 at 6:54 AM, Ben Hutchings 
> wrote:
> > On Sun, 2017-08-20 at 02:35 +0900, Roger Shimizu wrote:
> > > 
> > > The real problem is kernel size (after decompression) increased
> > > from
> > > 5MB to 8MB. (detail is in my previous post)
> > > This looks like a bug, since usually kernel size grows gradually,
> > > not
> > > in +3MB way this time.
> > 
> > Some things to check:
> > 
> > - If you build 4.10 with the config used for 4.11 (whichever is the
> > first larger one), is the size 5 MB or 8 MB?
> 
> I build vanilla kernel with debian config, and here's the result.
> (images are under arch/arm/boot/)
> 
> linux_4.10.7 with debian 4.10.7 config
> -rwxr-xr-x 1 rosh rosh 5757504 Aug 20 06:40 Image
> -rwxr-xr-x 1 rosh rosh 2012496 Aug 20 06:40 zImage
> 
> linux_4.11.6 with debian 4.11.6 config
> -rwxr-xr-x 1 rosh rosh 8763712 Aug 20 07:03 Image
> -rwxr-xr-x 1 rosh rosh 2064576 Aug 20 07:03 zImage
> 
> linux_4.11.6 with debian 4.10.7 config
> -rwxr-xr-x 1 rosh rosh 5891216 Aug 20 07:43 Image
> -rwxr-xr-x 1 rosh rosh 2049216 Aug 20 07:43 zImage
> 
> linux_4.10.7 with debian 4.11.6 config
> -rwxr-xr-x 1 rosh rosh 5811408 Aug 20 07:56 Image
> -rwxr-xr-x 1 rosh rosh 2032704 Aug 20 07:56 zImage
> 
> So it seems the problem is pointing to config changes since 4.11.

OK, then try using 4.11.6 source and bisecting the Debian config
changes.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert
Einstein



signature.asc
Description: This is a digitally signed message part

Bug#872644: linux-image-4.12.0-1-686-pae: Olinux-imag-4.12.0-1-686-pae sends crash messags at boot

[Ben Hutchings]

On Sun, 2017-08-20 at 10:03 +0200, Hans wrote:
> I additionally attach two pictures, which show the problem.
> 
> Although these are not good pictures, you can see, it happens after /usr is 
> mounted, and /var is yet NOT mounted. 
> 
> So the crash appears just after /usr is mounted (maybe a problem with the 
> decrypt module?).
> 
> It also shows the related intel problem.

It looks like both oops/warning messages are related to the i915
driver.  They appear after mounting /usr because that's the point at
which the the initramfs hands over to the real init system and loads
more drivers.

> These pictures are just for info, not usable for bug finding. If this is 
> needed, I will try to make a better one.

These messages should still be copied to /var/log/messages.  However if
you're using sysvinit, they might go into /var/log/dmesg instead. 
Please check there.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert
Einstein



signature.asc
Description: This is a digitally signed message part

Processed: affects 872726

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> affects 872726 audit apparmor
Bug #872726 [src:linux] linux: apparmor doesn't use proper audit event ids
Added indication that 872726 affects audit and apparmor
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
872726: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872726
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#872726: linux: apparmor doesn't use proper audit event ids

[Laurent Bigonville]

Source: linux
Version: 4.12.6-1
Severity: normal

Hi,

Currently the code in the kernel is not using the expected audit event
ids (it's using the one allocated to SELinux, 1400 to 1499) when it's
logging its messages (denials,...).

This has been discussed on the linux-audit back to 2014 and again in
2016, but it seems that nothing has moved. This makes auseach and other
audit tools not list these messages as they are seen as invalids.

Upstream of the audit framework insists that AppArmor should use
events ids from the range that has been allocated to them (1500-1599).
AFAIKS, the apparmor userspace is already supporting messaging from both
ranges (would be nice if this was confirmed).

IMVHO, in regard to the recent proposal of enabling apparmor in debian
by default, this needs to be addressed first.

Regards,

Laurent Bigonville

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Re: [PATCH v2] kbuild: Do not use hyphen in exported variable name

[Masahiro Yamada]

2017-08-20 6:30 GMT+09:00 Ben Hutchings :
> This definition in Makefile.dtbinst:
>
> export dtbinst-root ?= $(obj)
>
> should define and export dtbinst-root when handling the root dts
> directory, and do nothing in the subdirectories.  However some shells,
> including dash, will not pass through environment variables whose name
> includes a hyphen.  Usually GNU make does not use a shell to recurse,
> but if e.g. $(srctree) contains '~' it will use a shell here.
>
> Rename the variable to dtbinst_root.
>
> References: https://bugs.debian.org/833561
> Fixes: 323a028d39cdi ("dts, kbuild: Implement support for dtb vendor subdirs")
> Signed-off-by: Ben Hutchings 
> ---
> v2: Revised the commit message to explain exactly how the hyphenated
> variable can be lost.
>

Thanks for figuring out the root cause!

Applied to linux-kbuild/fixes.

-- 
Best Regards
Masahiro Yamada

Bug#871701: linux 4.9: backport patches for new Loongson CPU

[YunQiang Su]

On Sun, Aug 20, 2017 at 7:15 PM, Aurelien Jarno  wrote:
> On 2017-08-11 02:39, YunQiang Su wrote:
>> Package: linux
>> Version: 4.9.30-2+deb9u2
>>
>> The support Loongson 3A/B 2000 and 3000 has been merged into upstream.
>> I test the patchset with linux 4.9.30-2+deb9u2 for stretch.
>>
>
> In the past, backporting support for newer CPUs broke the support for
> older boards. Have you check it works both for lemote 3a-itx-a1101 and
> loongson ls3a-rs780e-1w boards?

Yes. I tested it on a Lemote 6100 and a Loongson dev board,
aka, lm6100 and thor.

>
> Thanks,
> Aurelien
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net



-- 
YunQiang Su

Bug#870185: armel/marvell kernel size

[Roger Shimizu]

On Sun, Aug 20, 2017 at 6:54 AM, Ben Hutchings  wrote:
> On Sun, 2017-08-20 at 02:35 +0900, Roger Shimizu wrote:
>>
>> The real problem is kernel size (after decompression) increased from
>> 5MB to 8MB. (detail is in my previous post)
>> This looks like a bug, since usually kernel size grows gradually, not
>> in +3MB way this time.
>
> Some things to check:
>
> - If you build 4.10 with the config used for 4.11 (whichever is the
> first larger one), is the size 5 MB or 8 MB?

I build vanilla kernel with debian config, and here's the result.
(images are under arch/arm/boot/)

linux_4.10.7 with debian 4.10.7 config
-rwxr-xr-x 1 rosh rosh 5757504 Aug 20 06:40 Image
-rwxr-xr-x 1 rosh rosh 2012496 Aug 20 06:40 zImage

linux_4.11.6 with debian 4.11.6 config
-rwxr-xr-x 1 rosh rosh 8763712 Aug 20 07:03 Image
-rwxr-xr-x 1 rosh rosh 2064576 Aug 20 07:03 zImage

linux_4.11.6 with debian 4.10.7 config
-rwxr-xr-x 1 rosh rosh 5891216 Aug 20 07:43 Image
-rwxr-xr-x 1 rosh rosh 2049216 Aug 20 07:43 zImage

linux_4.10.7 with debian 4.11.6 config
-rwxr-xr-x 1 rosh rosh 5811408 Aug 20 07:56 Image
-rwxr-xr-x 1 rosh rosh 2032704 Aug 20 07:56 zImage

So it seems the problem is pointing to config changes since 4.11.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#871701: linux 4.9: backport patches for new Loongson CPU

[Aurelien Jarno]

On 2017-08-11 02:39, YunQiang Su wrote:
> Package: linux
> Version: 4.9.30-2+deb9u2
> 
> The support Loongson 3A/B 2000 and 3000 has been merged into upstream.
> I test the patchset with linux 4.9.30-2+deb9u2 for stretch.
> 

In the past, backporting support for newer CPUs broke the support for
older boards. Have you check it works both for lemote 3a-itx-a1101 and
loongson ls3a-rs780e-1w boards?

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#864807: b53_mdio module doesn't get loaded automatically on Lamobo R1

[Heinrich Schuchardt]

The following is necessary to get a running network on the Lamobo R1
with a current kernel:

Load the b53_mdio module,
file /etc/modules:

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
b53_mdio

Define a bridge,
file /etc/network/interfaces.d/br0:

auto br0
iface br0 inet dhcp

Setup the switch. With the commands below all ports are connected
together in the same vlan. For usage as a router we would have to create
at least two vlans. One for the wan port and one for ports lan1-lan4.

Maybe we should create a package with different configuration files for
the switch which the user can choose from.

File /etc/network/if-pre-up.d/switch (chmod 755):

#!/bin/sh
#
# Setup interfaces and VLANs

# Reset eth0
ip link set eth0 down
ip addr flush eth0
ip link set eth0 up

# Create VLAN 101 on interface eth0: eth0.101
ip link add link eth0 name eth0.101 type vlan id 101

# Create bridge br0 as disabled for STP (Spanning Tree Protocol).
ip link add br0 type bridge
ip link set dev br0 type bridge stp_state 0

bridge vlan

# Assign ports to bridge
ip link set lan1 master br0
bridge vlan add vid 101 dev lan1 pvid untagged
bridge vlan add vid 101 dev lan1 pvid untagged self
ip link set lan1 up

ip link set lan2 master br0
bridge vlan add vid 101 dev lan2 pvid untagged
bridge vlan add vid 101 dev lan2 pvid untagged self
ip link set lan2 up

ip link set lan3 master br0
bridge vlan add vid 101 dev lan3 pvid untagged
bridge vlan add vid 101 dev lan3 pvid untagged self
ip link set lan3 up

ip link set lan4 master br0
bridge vlan add vid 101 dev lan4 pvid untagged
bridge vlan add vid 101 dev lan4 pvid untagged self
ip link set lan4 up

ip link set wan master br0
bridge vlan add vid 101 dev wan pvid untagged
bridge vlan add vid 101 dev wan pvid untagged self
ip link set wan up

ip link set eth0.101 master br0
bridge vlan add vid 101 dev eth0.101 pvid untagged
bridge vlan add vid 101 dev eth0.101 pvid untagged self
ip link set eth0.101 up

bridge vlan


Best regards

Heinrich Schuchardt