Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #62013 > unrolled thread

Bug#908161: Please enable building a riscv64 kernel image

Back to article view | Back to linux.debian.kernel

Contents

  Bug#908161: Please enable building a riscv64 kernel image Karsten Merker <merker@debian.org> - 2018-09-06 22:10 +0200
    Bug#908161: Please enable building a riscv64 kernel image Ben Hutchings <ben@decadent.org.uk> - 2018-09-06 23:40 +0200
      Bug#908161: Please enable building a riscv64 kernel image Ben Hutchings <ben@decadent.org.uk> - 2018-09-06 23:50 +0200
      Bug#908161: Please enable building a riscv64 kernel image Karsten Merker <merker@debian.org> - 2018-09-08 20:20 +0200
        Bug#908161: Please enable building a riscv64 kernel image Ben Hutchings <ben@decadent.org.uk> - 2018-09-09 00:30 +0200
          Bug#908161: Please enable building a riscv64 kernel image Karsten Merker <merker@debian.org> - 2018-09-18 21:10 +0200
            Bug#908161: Please enable building a riscv64 kernel image Karsten Merker <merker@debian.org> - 2018-10-11 21:50 +0200
    Processed: Re: Bug#908161: Please enable building a riscv64  kernel image "Debian Bug Tracking System" <owner@bugs.debian.org> - 2018-09-06 23:40 +0200
    Bug#908161: Please enable building a riscv64 kernel image Ben Hutchings <ben@decadent.org.uk> - 2018-09-07 01:10 +0200
    Processed: Re: Bug#908161: Please enable building a riscv64  kernel image "Debian Bug Tracking System" <owner@bugs.debian.org> - 2018-09-09 00:30 +0200
    Processed: Re: Bug#908161: Please enable building a riscv64  kernel image "Debian Bug Tracking System" <owner@bugs.debian.org> - 2018-10-11 21:50 +0200

#62013 — Bug#908161: Please enable building a riscv64 kernel image

[Multipart message — attachments visible in raw view] — view raw

Source: linux
Version: 4.19~rc2-1~exp1
Severity: wishlist
Tags: patch
X-Debbugs-CC: debian-riscv@lists.debian.org
User: debian-riscv@lists.debian.org
Usertags: riscv64

Hello,

starting with version 4.19rc2, the mainline Linux kernel includes
all drivers necessary for running a riscv64 system in qemu, so it
would be great if the "linux" source package could be extended to
build a linux-image-*-riscv64 binary package.

Attached is a patch that tries to add the necessary bits. 
Unfortunately, with the patch applied the kernel itself builds
successfully, but the package build process then fails with

-----8<----------8<----------8<----------8<----------8<-----

make[3]: Leaving directory '<<builddir>>/linux-4.19~rc2/debian/build/build_riscv64_none_riscv64'
debian/bin/buildcheck.py debian/build/build_riscv64_none_riscv64 riscv64 none riscv64
ABI is not completely versioned!  Refusing to continue.

Unversioned symbols:
_mcount                                          module: vmlinux, version: 0x00000000, export: EXPORT_SYMBOL
return_to_handler                                module: vmlinux, version: 0x00000000, export: EXPORT_SYMBOL
Can't read ABI reference.  ABI not checked!
make[2]: *** [debian/rules.real:217: debian/stamps/build_riscv64_none_riscv64] Fehler 1

-----8<----------8<----------8<----------8<----------8<-----

I'm somewhat stuck here - is this an upstream issue or
have I overlooked something on the packaging side? Pointers
welcome :).

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[toc] | [next] | [standalone]

#62017

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 - patch

On Thu, 2018-09-06 at 22:06 +0200, Karsten Merker wrote:
> Source: linux
> Version: 4.19~rc2-1~exp1
> Severity: wishlist
> Tags: patch
> X-Debbugs-CC: debian-riscv@lists.debian.org
> User: debian-riscv@lists.debian.org
> Usertags: riscv64
> 
> Hello,
> 
> starting with version 4.19rc2, the mainline Linux kernel includes
> all drivers necessary for running a riscv64 system in qemu, so it
> would be great if the "linux" source package could be extended to
> build a linux-image-*-riscv64 binary package.
> 
> Attached is a patch that tries to add the necessary bits.

This config sets a whole lot of things to be built-in, but our policy
is to build everything as modules if it works properly work as a
module.  This will also cause the building of installer udebs to fail
(empty packages are treated as a fatal error).

It also seems to have some redundant settings.  debian/config/config is
always used first (see README.source), so don't repeat anything that's
in there.

Finally you should use kconfigeditor2 to add headings to the config
file.  You need to check out the kernel-team.git repository, and then
in the linux repository run something like:

    ../kernel-team/utils/kconfigeditor2/process.py .

> Unfortunately, with the patch applied the kernel itself builds
> successfully, but the package build process then fails with
> 
> -----8<----------8<----------8<----------8<----------8<-----
> 
> make[3]: Leaving directory '<<builddir>>/linux-4.19~rc2/debian/build/build_riscv64_none_riscv64'
> debian/bin/buildcheck.py debian/build/build_riscv64_none_riscv64 riscv64 none riscv64
> ABI is not completely versioned!  Refusing to continue.
> 
> Unversioned symbols:
> _mcount                                          module: vmlinux, version: 0x00000000, export: EXPORT_SYMBOL
> return_to_handler                                module: vmlinux, version: 0x00000000, export: EXPORT_SYMBOL
> Can't read ABI reference.  ABI not checked!
> make[2]: *** [debian/rules.real:217: debian/stamps/build_riscv64_none_riscv64] Fehler 1
> 
> -----8<----------8<----------8<----------8<----------8<-----
> 
> I'm somewhat stuck here - is this an upstream issue or
> have I overlooked something on the packaging side? Pointers
> welcome :).

It's an upstream issue, but not a fatal error there.  For Debian it is
a fatal error becasue unversioned symbols potentially undermine code
signing.

Any symbol exported from an assembly-language file won't automatically
get a symbol version, since there's no type information there.  The way
to fix this is to include (or directly) add the function prototypes in
arch/riscv/include/asm/asm-prototypes.h.

I don't think that return_to_handler should be exported at all.  No
other architecture does.  As for _mcount, that is declared in
<asm/ftrace.h>, so <asm/asm-prototypes.h> should just be:

/* SPDX-License-Identifier: GPL-2.0 */
#include <asm/ftrace.h>

--

Finally, you have added module lists for installer udebs, but this
won't have any effect unless you also add the new architecture and
flavour to debian/installer/kernel-versions.

--

I'm removing the patch tag as this patch isn't usable.  Please add it
again when you send another patch.  Also, you are welcome to send a
merge request on Gitlab instead of a patch; I find easier to discuss
changes that way.

Ben.

> Regards,
> Karsten
-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett

[toc] | [prev] | [next] | [standalone]

#62019

[Multipart message — attachments visible in raw view] — view raw

Some minor clarifications:

On Thu, 2018-09-06 at 22:28 +0100, Ben Hutchings wrote:
[...]
> Any symbol exported from an assembly-language file won't automatically
> get a symbol version, since there's no type information there.  The way
> to fix this is to include (or directly) add the function prototypes in

"... include (or directly add) ..."

> arch/riscv/include/asm/asm-prototypes.h.
> 
> I don't think that return_to_handler should be exported at all.  No
> other architecture does.

"No other architecture exports it."

[...]
> I'm removing the patch tag as this patch isn't usable.  Please add it
> again when you send another patch.  Also, you are welcome to send a
> merge request on Gitlab instead of a patch; I find easier to discuss
> changes that way.

By "Gitlab" I mean salsa.debian.org.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett

[toc] | [prev] | [next] | [standalone]

#62046

On Thu, Sep 06, 2018 at 10:28:19PM +0100, Ben Hutchings wrote:
> On Thu, 2018-09-06 at 22:06 +0200, Karsten Merker wrote:
> > Source: linux
> > Version: 4.19~rc2-1~exp1
> > Severity: wishlist
[...]
> > starting with version 4.19rc2, the mainline Linux kernel includes
> > all drivers necessary for running a riscv64 system in qemu, so it
> > would be great if the "linux" source package could be extended to
> > build a linux-image-*-riscv64 binary package.
> > 
> > Attached is a patch that tries to add the necessary bits.
> 
> This config sets a whole lot of things to be built-in, but our policy
> is to build everything as modules if it works properly work as a
> module.  This will also cause the building of installer udebs to fail
> (empty packages are treated as a fatal error).

Hello,

the reason for using a static config was that using an initrd
isn't possible on riscv64 with kernel 4.19rc2.  This will
hopefully change sometime before the final 4.19 release so that
we can move to a fully modularized config, but for now everyting
required to mount the rootfs and bring up init has to be
built-in.  I can probably trim down the current static config a
bit more, but e.g. filesystem drivers need to be built-in for
now, otherwise mounting the rootfs isn't possible.

> It also seems to have some redundant settings.  debian/config/config is
> always used first (see README.source), so don't repeat anything that's
> in there.

Many thanks for the pointer, I'll take that into account for the
next version of the patch.

> Finally you should use kconfigeditor2 to add headings to the config
> file.  You need to check out the kernel-team.git repository, and then
> in the linux repository run something like:
> 
>     ../kernel-team/utils/kconfigeditor2/process.py .

Ok, will do.

> > Unfortunately, with the patch applied the kernel itself builds
> > successfully, but the package build process then fails with
> > 
> > -----8<----------8<----------8<----------8<----------8<-----
> > 
> > make[3]: Leaving directory '<<builddir>>/linux-4.19~rc2/debian/build/build_riscv64_none_riscv64'
> > debian/bin/buildcheck.py debian/build/build_riscv64_none_riscv64 riscv64 none riscv64
> > ABI is not completely versioned!  Refusing to continue.
> > 
> > Unversioned symbols:
> > _mcount                                          module: vmlinux, version: 0x00000000, export: EXPORT_SYMBOL
> > return_to_handler                                module: vmlinux, version: 0x00000000, export: EXPORT_SYMBOL
> > Can't read ABI reference.  ABI not checked!
> > make[2]: *** [debian/rules.real:217: debian/stamps/build_riscv64_none_riscv64] Fehler 1
> > 
> > -----8<----------8<----------8<----------8<----------8<-----
> > 
> > I'm somewhat stuck here - is this an upstream issue or
> > have I overlooked something on the packaging side? Pointers
> > welcome :).
> 
> It's an upstream issue, but not a fatal error there.  For Debian it is
> a fatal error becasue unversioned symbols potentially undermine code
> signing.
> 
> Any symbol exported from an assembly-language file won't automatically
> get a symbol version, since there's no type information there.  The way
> to fix this is to include (or directly) add the function prototypes in
> arch/riscv/include/asm/asm-prototypes.h.
> 
> I don't think that return_to_handler should be exported at all.  No
> other architecture does.  As for _mcount, that is declared in
> <asm/ftrace.h>, so <asm/asm-prototypes.h> should just be:
> 
> /* SPDX-License-Identifier: GPL-2.0 */
> #include <asm/ftrace.h>

Thanks for the explanation, I'll contact the upstream RISC-V
kernel maintainer regarding this.

> Finally, you have added module lists for installer udebs, but this
> won't have any effect unless you also add the new architecture and
> flavour to debian/installer/kernel-versions.

Again thanks for the pointer, I'll look into it.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[toc] | [prev] | [next] | [standalone]

#62052

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 moreinfo

On Sat, 2018-09-08 at 20:07 +0200, Karsten Merker wrote:
> On Thu, Sep 06, 2018 at 10:28:19PM +0100, Ben Hutchings wrote:
> > On Thu, 2018-09-06 at 22:06 +0200, Karsten Merker wrote:
> > > Source: linux
> > > Version: 4.19~rc2-1~exp1
> > > Severity: wishlist
> 
> [...]
> > > starting with version 4.19rc2, the mainline Linux kernel includes
> > > all drivers necessary for running a riscv64 system in qemu, so it
> > > would be great if the "linux" source package could be extended to
> > > build a linux-image-*-riscv64 binary package.
> > > 
> > > Attached is a patch that tries to add the necessary bits.
> > 
> > This config sets a whole lot of things to be built-in, but our policy
> > is to build everything as modules if it works properly work as a
> > module.  This will also cause the building of installer udebs to fail
> > (empty packages are treated as a fatal error).
> 
> Hello,
> 
> the reason for using a static config was that using an initrd
> isn't possible on riscv64 with kernel 4.19rc2.  This will
> hopefully change sometime before the final 4.19 release so that
> we can move to a fully modularized config, but for now everyting
> required to mount the rootfs and bring up init has to be
> built-in.  I can probably trim down the current static config a
> bit more, but e.g. filesystem drivers need to be built-in for
> now, otherwise mounting the rootfs isn't possible.
[...]

This is not OK for distribution kernel packages.  The addition of riscv
will have to wait until it has support for an initramfs.

Is this commit sufficient to make booting with an initramfs work:

commit cdc7274029ca5984350a057a2399aaa340d3be2d
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Aug 28 17:33:46 2018 -0700

    riscv: Do not overwrite initrd_start and initrd_end

or are more changes needed?

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, on joining IRC

[toc] | [prev] | [next] | [standalone]

#62179

On Sat, Sep 08, 2018 at 11:15:36PM +0100, Ben Hutchings wrote:

[Building a linux-image-*-riscv64 binary package]

> The addition of riscv will have to wait until it has support
> for an initramfs.
> 
> Is this commit sufficient to make booting with an initramfs work:
> 
> commit cdc7274029ca5984350a057a2399aaa340d3be2d
> Author: Guenter Roeck <linux@roeck-us.net>
> Date:   Tue Aug 28 17:33:46 2018 -0700
> 
>     riscv: Do not overwrite initrd_start and initrd_end
> 
> or are more changes needed?

Hello,

just a short status update: the aforementioned patch has been
included in the upstream 4.19-rc4 release and I can confirm
that the initramfs support for riscv64 works with 4.19-rc4.

The other major issue in this bug (unversioned symbols breaking
the package build) is still unresolved; I'll report back as soon
as I have received feedback from the upstream RISC-V architecture
maintainer.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[toc] | [prev] | [next] | [standalone]

#62350

[Multipart message — attachments visible in raw view] — view raw

Control: tags 908161 + patch

On Tue, Sep 18, 2018 at 08:57:01PM +0200, Karsten Merker wrote:
> On Sat, Sep 08, 2018 at 11:15:36PM +0100, Ben Hutchings wrote:
> 
> [Building a linux-image-*-riscv64 binary package]
> 
> > The addition of riscv will have to wait until it has support
> > for an initramfs.
> > 
> > Is this commit sufficient to make booting with an initramfs work:
> > 
> > commit cdc7274029ca5984350a057a2399aaa340d3be2d
> > Author: Guenter Roeck <linux@roeck-us.net>
> > Date:   Tue Aug 28 17:33:46 2018 -0700
> > 
> >     riscv: Do not overwrite initrd_start and initrd_end
> > 
> > or are more changes needed?
> 
> Hello,
> 
> just a short status update: the aforementioned patch has been
> included in the upstream 4.19-rc4 release and I can confirm
> that the initramfs support for riscv64 works with 4.19-rc4.
> 
> The other major issue in this bug (unversioned symbols breaking
> the package build) is still unresolved; I'll report back as soon
> as I have received feedback from the upstream RISC-V architecture
> maintainer.

Hello,

all previously mentioned issues have been addressed in
the meantime:

- The broken initrd support has been fixed upstream in kernel
  4.19-rc4.

- The symbol version issue has been fixed upstream in kernel
  4.19-rc6.

- The riscv64 kernel config has been modularized as far as
  possible and all redundant entries have been removed.

- Headings have been added to the kernel config.

Attached is a new patch, alternatively it is available as a merge
request on salsa as suggested earlier in the discussion:

  https://salsa.debian.org/kernel-team/linux/merge_requests/66

The resulting kernel has been successfully tested on a qemu
"virt" board:

[    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[    0.000000] Linux version 4.19.0-rc7-riscv64 (debian-kernel@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-7)) #1 SMP Debian 4.19~rc7-1~exp2 (2018-10-08)
[    0.000000] bootconsole [early0] enabled
[    0.000000] Initial ramdisk at: 0x(____ptrval____) (43521258 bytes)
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x00002fffffffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080200000-0x00000002ffffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000002ffffffff]
[    0.000000] On node 0 totalpages: 2620928
[    0.000000]   DMA32 zone: 8184 pages used for memmap
[    0.000000]   DMA32 zone: 0 pages reserved
[    0.000000]   DMA32 zone: 523776 pages, LIFO batch:63
[    0.000000]   Normal zone: 32768 pages used for memmap
[    0.000000]   Normal zone: 2097152 pages, LIFO batch:63
[    0.000000] software IO TLB: mapped [mem 0xfbfff000-0xfffff000] (64MB)
[    0.000000] elf_hwcap is 0x112d
[    0.000000] percpu: Embedded 19 pages/cpu @(____ptrval____) s39384 r8192 d30248 u77824
[    0.000000] pcpu-alloc: s39384 r8192 d30248 u77824 alloc=19*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 2579976
[    0.000000] Kernel command line: console=ttyS0 ro root=/dev/vda
[    0.000000] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes)
[    0.000000] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[    0.000000] Sorting __ex_table...
[    0.000000] Memory: 10178016K/10483712K available (4955K kernel code, 504K rwdata, 1633K rodata, 446K init, 934K bss, 305696K reserved, 0K cma-reserved)
[    0.000000] random: get_random_u64 called from __kmem_cache_create+0x46/0x55c with crng_init=0
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] ftrace: allocating 21055 entries in 83 pages
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
[    0.000000] plic: mapped 10 interrupts to 4 (out of 8) handlers.
[    0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns
[    0.004000] Console: colour dummy device 80x25
[    0.008000] Calibrating delay loop (skipped), value calculated using timer frequency.. 20.00 BogoMIPS (lpj=40000)
[    0.012000] pid_max: default: 32768 minimum: 301
[    0.016000] Security Framework initialized
[    0.016000] Yama: disabled by default; enable with sysctl kernel.yama.*
[    0.020000] AppArmor: AppArmor initialized
[    0.024000] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes)
[    0.028000] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes)
[    0.072000] rcu: Hierarchical SRCU implementation.
[    0.092000] smp: Bringing up secondary CPUs ...
[    0.112000] smp: Brought up 1 node, 4 CPUs
[    0.160000] devtmpfs: initialized
[    0.176000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.180000] futex hash table entries: 1024 (order: 4, 65536 bytes)
[    0.188000] NET: Registered protocol family 16
[    0.192000] audit: initializing netlink subsys (disabled)
[    0.196000] audit: type=2000 audit(0.192:1): state=initialized audit_enabled=0 res=1
[    0.244000] vgaarb: loaded
[    0.244000] pps_core: LinuxPPS API ver. 1 registered
[    0.244000] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.248000] PTP clock support registered
[    0.264000] clocksource: Switched to clocksource riscv_clocksource
[    0.368000] VFS: Disk quotas dquot_6.6.0
[    0.368000] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.376000] AppArmor: AppArmor Filesystem Enabled
[    0.464000] NET: Registered protocol family 2
[    0.476000] tcp_listen_portaddr_hash hash table entries: 8192 (order: 5, 131072 bytes)
[    0.476000] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.476000] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.480000] TCP: Hash tables configured (established 131072 bind 65536)
[    0.480000] UDP hash table entries: 8192 (order: 6, 262144 bytes)
[    0.484000] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)
[    0.488000] NET: Registered protocol family 1
[    0.488000] PCI: CLS 0 bytes, default 64
[    0.496000] Unpacking initramfs...
[    6.288000] Initialise system trusted keyrings
[    6.292000] workingset: timestamp_bits=46 max_order=22 bucket_order=0
[    6.320000] zbud: loaded
[    7.464000] Key type asymmetric registered
[    7.464000] Asymmetric key parser 'x509' registered
[    7.468000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[    7.468000] io scheduler noop registered
[    7.472000] io scheduler deadline registered
[    7.472000] io scheduler cfq registered (default)
[    7.472000] io scheduler mq-deadline registered
[    7.492000] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    7.508000] console [ttyS0] disabled
[    7.508000] 10000000.uart: ttyS0 at MMIO 0x10000000 (irq = 10, base_baud = 230400) is a 16550A
[    7.552000] console [ttyS0] enabled
[    7.556000] mousedev: PS/2 mouse device common for all mice
[    7.560000] ledtrig-cpu: registered to indicate activity on CPUs
[    7.568000] NET: Registered protocol family 10
[    7.788000] Segment Routing with IPv6
[    7.788000] mip6: Mobile IPv6
[    7.792000] NET: Registered protocol family 17
[    7.792000] mpls_gso: MPLS GSO support
[    7.800000] bootconsole [early0] uses init memory and must be disabled even before the real one is ready
[    7.800000] bootconsole [early0] disabled
[    7.804000] registered taskstats version 1
[    7.804000] Loading compiled-in X.509 certificates
[    7.972000] Loaded X.509 cert 'secure-boot-test-key-lfaraone: 97c1b25cddf9873ca78a58f3d73bf727d2cf78ff'
[    7.976000] zswap: loaded using pool lzo/zbud
[    7.980000] AppArmor: AppArmor sha1 policy hashing enabled
[    7.980000] hctosys: unable to open rtc device (rtc0)
[    8.928000] Freeing unused kernel memory: 444K
[    8.928000] This architecture does not have kernel memory protection.
[    8.928000] Run /init as init process
[   11.472000] virtio_blk virtio1: [vda] 419430400 512-byte logical blocks (215 GB/200 GiB)
[   13.768000] EXT4-fs (vda): mounted filesystem with ordered data mode. Opts: (null)
[   18.532000] random: fast init done
[   27.072000] random: crng init done
[   32.004000] EXT4-fs (vda): re-mounted. Opts: (null)

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[toc] | [prev] | [next] | [standalone]

#62018 — Processed: Re: Bug#908161: Please enable building a riscv64 kernel image

Processing control commands:

> tag -1 - patch
Bug #908161 [src:linux] Please enable building a riscv64 kernel image
Removed tag(s) patch.

-- 
908161: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908161
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#62021

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2018-09-06 at 22:59 +0100, James Cowgill wrote:
> Hi!
> 
> On 06/09/2018 21:06, Karsten Merker wrote:
> > Unfortunately, with the patch applied the kernel itself builds
> > successfully, but the package build process then fails with
> > 
> > -----8<----------8<----------8<----------8<----------8<-----
> > 
> > make[3]: Leaving directory '<<builddir>>/linux-4.19~rc2/debian/build/build_riscv64_none_riscv64'
> > debian/bin/buildcheck.py debian/build/build_riscv64_none_riscv64 riscv64 none riscv64
> > ABI is not completely versioned!  Refusing to continue.
> > 
> > Unversioned symbols:
> > _mcount                                          module: vmlinux, version: 0x00000000, export: EXPORT_SYMBOL
> > return_to_handler                                module: vmlinux, version: 0x00000000, export: EXPORT_SYMBOL
> > Can't read ABI reference.  ABI not checked!
> > make[2]: *** [debian/rules.real:217: debian/stamps/build_riscv64_none_riscv64] Fehler 1
> > 
> > -----8<----------8<----------8<----------8<----------8<-----
> > 
> > I'm somewhat stuck here - is this an upstream issue or
> > have I overlooked something on the packaging side? Pointers
> > welcome :).
> 
> I sent this upstream patch for this:
> http://lists.infradead.org/pipermail/linux-riscv/2018-September/001372.html

Why not remove the export of return_to_handler?

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett

[toc] | [prev] | [next] | [standalone]

#62053 — Processed: Re: Bug#908161: Please enable building a riscv64 kernel image

Processing control commands:

> tag -1 moreinfo
Bug #908161 [src:linux] Please enable building a riscv64 kernel image
Added tag(s) moreinfo.

-- 
908161: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908161
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#62349 — Processed: Re: Bug#908161: Please enable building a riscv64 kernel image

Processing control commands:

> tags 908161 + patch
Bug #908161 [src:linux] Please enable building a riscv64 kernel image
Added tag(s) patch.

-- 
908161: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908161
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web