Bug#908161: Please enable building a riscv64 kernel image

[James Cowgill]

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 
> '<>/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: 
> 0x, export: EXPORT_SYMBOL
> return_to_handlermodule: vmlinux, version: 
> 0x, 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

James



signature.asc
Description: OpenPGP digital signature

Bug#891520: linux-libc-dev: headers from 4.15 cause "redefinition of 'struct in6_addr'" in libreswan

[James Cowgill]

Package: linux-libc-dev
Version: 4.15.4-1
Severity: important
Tags: fixed-upstream
Control: affects -1 src:libreswan
X-Debbugs-CC: libres...@packages.debian.org

Hi,

I noticed libreswan FTBFS in unstable with this error:
> In file included from 
> /<>/programs/pluto/linux-copy/linux/xfrm.h:4:0,
>  from /<>/programs/pluto/kernel_netlink.c:55:
> /usr/include/linux/in6.h:33:8: error: redefinition of 'struct in6_addr'
>  struct in6_addr {
> ^~~~
> In file included from /<>/linux/include/libreswan.h:76:0,
>  from /<>/programs/pluto/kernel_netlink.c:54:
> /usr/include/netinet/in.h:211:8: note: originally defined here
>  struct in6_addr
> ^~~~
> In file included from 
> /<>/programs/pluto/linux-copy/linux/xfrm.h:4:0,
>  from /<>/programs/pluto/kernel_netlink.c:55:
> /usr/include/linux/in6.h:50:8: error: redefinition of 'struct sockaddr_in6'
>  struct sockaddr_in6 {
> ^~~~
> In file included from /<>/linux/include/libreswan.h:76:0,
>  from /<>/programs/pluto/kernel_netlink.c:54:
> /usr/include/netinet/in.h:252:8: note: originally defined here
>  struct sockaddr_in6
> ^~~~
> In file included from 
> /<>/programs/pluto/linux-copy/linux/xfrm.h:4:0,
>  from /<>/programs/pluto/kernel_netlink.c:55:
> /usr/include/linux/in6.h:60:8: error: redefinition of 'struct ipv6_mreq'
>  struct ipv6_mreq {
> ^
> In file included from /<>/linux/include/libreswan.h:76:0,
>  from /<>/programs/pluto/kernel_netlink.c:54:
> /usr/include/netinet/in.h:288:8: note: originally defined here
>  struct ipv6_mreq
> ^
> make[5]: *** [../../mk/depend.mk:34: kernel_netlink.o] Error 1
> make[4]: *** [../../mk/targets.mk:90: all] Error 2
> make[4]: Leaving directory '/<>/programs/pluto'
> make[3]: *** [../mk/targets.mk:90: recursive-all] Error 2
> make[3]: Leaving directory '/<>/programs'
> make[2]: *** [mk/targets.mk:90: recursive-all] Error 2
> make[2]: Leaving directory '/<>'
> make[1]: *** [debian/rules:23: override_dh_auto_build] Error 2
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:6: binary-arch] Error 2
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
> status 2

See also this reproducible builds log:
> https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/libreswan_3.23-4.rbuild.log

This only happens when using linux headers from 4.15.

I think the cause of this was a change in 4.15 in the if_ether.h header.
It should be fixed by this upstream patch (applied in linus's tree but
not yet in stable):
https://www.spinics.net/lists/stable/msg215023.html

da360299b6734135a5f66d7db458dcc7801c826a
"uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define"

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#883735: Re: Bug#883735: initramfs-tools: automatic resume doesn't work for lvm swap partitions

[James Cowgill]

Hi,

On 07/12/17 01:30, Ben Hutchings wrote:
> Control: reopen -1
> Control: tag -1 patch moreinfo
> 
> On Thu, 2017-12-07 at 00:22 +, James Cowgill wrote:
>> Hi,
>>
>> On 07/12/17 00:06, Ben Hutchings wrote:
>>> On Wed, 2017-12-06 at 23:48 +, James Cowgill wrote:
>>>> Package: initramfs-tools
>>>> Version: 0.130
>>>> Severity: normal
>>>>
>>>> Hi,
>>>>
>>>> I had noticed this bug for quite a while now, but since I rarely turn my
>>>> machine off I left investigating what the problem was until now.
>>>
>>> [...]
>>>> Is it possible (and a good idea) to store the /dev/mapper path instead
>>>> of the blkid when the swap partition is on LVM?
>>>>
>>>> I managed to solve my specific issue by manually setting RESUME to the
>>>> correct /dev/mapper path.
>>>
>>> This is the correct way to refer to LVs used as root, /usr or resume
>>> partition.  The reason for this is that lvm2 only activates VGs that
>>> are definitely needed, and there is no way to determine whether a
>>> filesystem UUID or label refers to an LV (or which VG it's in).
>>
>> Ok, but I don't understand why this can't be fixed. Why can't you
>> convert the /dev/dm-* path from /proc/swaps into a /dev/mapper path when
>> you generate the initramfs and store that instead?
> 
> Oh I see, I failed to parse 'automatic resume' as meaning automatic
> selection of the resume device.
> 
> Does the attached patch fix this for you?

Thanks, your patch does fix this for me.

James



signature.asc
Description: OpenPGP digital signature

Bug#883735: Re: Bug#883735: initramfs-tools: automatic resume doesn't work for lvm swap partitions

[James Cowgill]

Hi,

On 07/12/17 00:06, Ben Hutchings wrote:
> On Wed, 2017-12-06 at 23:48 +0000, James Cowgill wrote:
>> Package: initramfs-tools
>> Version: 0.130
>> Severity: normal
>>
>> Hi,
>>
>> I had noticed this bug for quite a while now, but since I rarely turn my
>> machine off I left investigating what the problem was until now.
> [...]
>> Is it possible (and a good idea) to store the /dev/mapper path instead
>> of the blkid when the swap partition is on LVM?
>>
>> I managed to solve my specific issue by manually setting RESUME to the
>> correct /dev/mapper path.
>
> This is the correct way to refer to LVs used as root, /usr or resume
> partition.  The reason for this is that lvm2 only activates VGs that
> are definitely needed, and there is no way to determine whether a
> filesystem UUID or label refers to an LV (or which VG it's in).

Ok, but I don't understand why this can't be fixed. Why can't you
convert the /dev/dm-* path from /proc/swaps into a /dev/mapper path when
you generate the initramfs and store that instead?

James



signature.asc
Description: OpenPGP digital signature

Bug#883735: initramfs-tools: automatic resume doesn't work for lvm swap partitions

[James Cowgill]

Package: initramfs-tools
Version: 0.130
Severity: normal

Hi,

I had noticed this bug for quite a while now, but since I rarely turn my
machine off I left investigating what the problem was until now.

Every time I boot my laptop, it prints a lot of messages like this,
before eventually giving up:

Begin: Waiting for suspend/resume device ...
Begin: Running /scripts/local-block ... done
[...]
Begin: Running /scripts/local-block ... done
Gave up waiting for suspend/resume device.

I traced this down to the swap device being on an LVM partition on my
laptop. The script which automatically determines which device to resume
from stores the blkid in the initramfs, but unfortunately the lvm2
local-block script does not know how to activate LVM partitions based on
blkid. This means the swap device is never created and the initramfs
will never be able to find it.

Is it possible (and a good idea) to store the /dev/mapper path instead
of the blkid when the swap partition is on LVM?

I managed to solve my specific issue by manually setting RESUME to the
correct /dev/mapper path.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#881830: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel

[James Cowgill]

Hi,

On 16/11/17 19:04, Ben Hutchings wrote:
> On Wed, 2017-11-15 at 16:50 +0000, James Cowgill wrote:
>> Since I was a little puzzled as to why keyutils built previously on
>> mips, I found this commit to 4.8 which caused the need for KEYS_COMPAT:
>>
>> commit 20f06ed9f61a185c6dabd662c310bed6189470df
>> Author: David Howells <dhowe...@redhat.com>
>> Date:   Wed Jul 27 11:43:37 2016 +0100
>>
>> KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace
>> 
>> MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than
>> calling sys_keyctl.  The latter will work in a lot of cases, thereby 
>> hiding
>> the issue.
>>
>> Now I'm thinking maybe this can be argued as a bugfix for the above
>> commit and put in upstream 4.9?
> 
> Greg, please queue up these two for 4.9:
> 
> 5c2a625937ba arm64: support keyctl() system call in 32-bit mode
> 47b2c3fff493 security/keys: add CONFIG_KEYS_COMPAT to Kconfig

Sorry, I asked for this in two places. I think it's already queued up
for 4.9 now.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#881830: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel

[James Cowgill]

Since I was a little puzzled as to why keyutils built previously on
mips, I found this commit to 4.8 which caused the need for KEYS_COMPAT:

commit 20f06ed9f61a185c6dabd662c310bed6189470df
Author: David Howells 
Date:   Wed Jul 27 11:43:37 2016 +0100

KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace

MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than
calling sys_keyctl.  The latter will work in a lot of cases, thereby hiding
the issue.

Now I'm thinking maybe this can be argued as a bugfix for the above
commit and put in upstream 4.9?

James



signature.asc
Description: OpenPGP digital signature

Bug#881830: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel

[James Cowgill]

Source: linux
Version: 4.9.51-1
Severity: wishlist
Control: fixed -1 4.12.2-1~exp1

Hi,

Is it possible to cherry-pick the following upstream commit into the
stable kernel so it is available on the buildds?

commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20
Author: Bilal Amarni 
Date:   Thu Jun 8 14:47:26 2017 +0100

security/keys: add CONFIG_KEYS_COMPAT to Kconfig

This commit moves KEYS_COMPAT to an architecture independent location
and enables it on all architectures where COMPAT is enabled. This should
allow 64-bit MIPS kernels to handle 32-bit applications using the keyctl
syscall (currently they fail with ENOSYS - see keyutils package). I
think this will also help with compiling armhf on arm64 kernels.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#877779: linux: modpost uses wrong sizes for mips-octeon kernel

[James Cowgill]

Source: linux
Version: 4.12.13-1
Severity: normal

Hi,

I recently attempted to install an out-of-tree module (an old version of
the octeon mmc driver) on an octeon machine running big endian 32-bit
mips. In this configuration, the kernel is 64-bit, but userspace is 32-bit.

The module build failed with this error:
> LD [M]  /var/lib/dkms/octeon-mmc/9/build/octeon-mmc.o
>   Building modules, stage 2.
>   MODPOST 1 modules
> FATAL: /var/lib/dkms/octeon-mmc/9/build/octeon-mmc: sizeof(struct 
> of_device_id)=196 is not a modulo of the size of section 
> __mod_of___device_table=600.
> Fix definition of struct of_device_id in mod_devicetable.h

of_device_id is defined like this in mod_devicetable.h:
> struct of_device_id {
>   charname[32];
>   chartype[32];
>   charcompatible[128];
>   const void *data;
> };

The size of this structure is 200 bytes and not 196 byte as modpost
claims because the kernel is compiled as 64-bit (so the pointer at the
end is 8 bytes instead of 4).

I think there is a bug in the way Debian compiles modpost, because using
upstream's modpost works correctly. I see that the
real-XXX/devicetable-offsets.s file gets compiled with the target
compiler, but not with the target flags so flags such as "-mabi=64
-mnoabicalls" which are used in 64-bit MIPS kernels are not used. This
will cause the compiler to default to the userspace ABI which is 32-bit
in this case.

I'm not sure what the correct solution is here. Using the target flags
directly might make modpost specific to a kernel flavour. Hacking in
some special flags for mips* doesn't sound great either.

I have not tested any other platforms, but I am guessing this issue will
affect other platforms when the size of pointers in userspace and the
kernel differ.

James




signature.asc
Description: OpenPGP digital signature

Bug#867358: mips/mipsel: mips-linux-gnu-gccgo-7: waitid: bad address

[James Cowgill]

Hi,

On 16/07/17 23:31, Ben Hutchings wrote:
> Control: tag -1 upstream patch
> 
> On Sun, 2017-07-16 at 23:21 +0100, Ben Hutchings wrote:
>> On Thu, 2017-07-06 at 13:10 +0300, Adrian Bunk wrote:
>>> Control: reassign -1 src:linux 4.9.30-2
>>> Control: retitle -1 mips/mipsel: mips-linux-gnu-gccgo-7: waitid: bad address
>>> Control: affects -1 src:golang-github-pelletier-go-toml 
>>> src:golang-github-nicksnyder-go-i18n gccgo-7
>>>
>>> On Thu, Jul 06, 2017 at 02:11:00AM +0300, Adrian Bunk wrote:
>>>> Source: golang-github-pelletier-go-toml
>>>> Version: 1.0.0-1
>>>> Severity: serious
>>>>
>>>> https://buildd.debian.org/status/package.php?p=golang-github-pelletier-go-toml=sid
>>>>
>>>> ...
>>>>dh_auto_test -a -O--buildsystem=golang
>>>>go test -v -p 4 github.com/pelletier/go-toml 
>>>> github.com/pelletier/go-toml/cmd github.com/pelletier/go-toml/cmd/tomljson 
>>>> github.com/pelletier/go-toml/cmd/tomll github.com/pelletier/go-toml/query
>>>> go build github.com/davecgh/go-spew/spew: /usr/bin/mips-linux-gnu-gccgo-7: 
>>>> waitid: bad address
>>>> FAIL   github.com/pelletier/go-toml [build failed]
>>>> ?  github.com/pelletier/go-toml/cmd[no test files]
>>>> ...
>>>
>>> James Cowgill told me that this is actually a kernel bug:
>>>   https://www.linux-mips.org/archives/linux-mips/2017-03/msg00580.html
>>
>> That's now a 404, strangely.  Did you mean "[PATCH 0/2] Fix indirect
>> syscall handler for syscalls with > 4 args"?

Hmm, I may have made a typo with that link. Here's the real one:
https://www.linux-mips.org/archives/linux-mips/2017-03/msg00575.html

> James - assuming I guessed correctly above, why is it that the second
> patch "MIPS: Remove pt_regs adjustments in indirect syscall handler"
> hasn't been applied?  Was this fixed some other way upstream?

I've just tried with v4.13-rc1 and the bug is still not fixed there. My
guess is that the first patch is more obviously correct than the second
one so was applied first. I have never received any feedback on these
patches so I don't actually know why only one of them was applied.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Lemote-3a-itx-a1101 kernel/PMON bug (Was: Bug#858405: xmlto: intermittent Segmentation fault when building manpages for libreswan on mips64el)

[James Cowgill]

Hi,

[drop some CCs since this is not directly related to the xmlto bug]

On 24/03/17 09:36, YunQiang Su wrote:
> On Fri, Mar 24, 2017 at 1:06 AM, James Cowgill <jcowg...@debian.org> wrote:
>> I believe any of the following will fix this (but have not all been tested):
>> - Reduce the stack usage in xsltproc (the upstream bug)
>> - Upgrade the relevant buildds to Linux >= 4.1
>> - Apply d1fd836dcf00 to jessie's kernel
>> - Disable PIE in xsltproc.
>> - Run xsltproc inside setarch -L / setarch -R
>>
> 
> we have some trouble to run newer kernel on some Loongson machines,
> as their pmon can only load initrd with limit size.
> So backports patch may ideal for us, now.

Are you referring to this issue?
https://lists.debian.org/debian-mips/2016/01/msg9.html

This does only affect some Loongson machines. I think all the buildds
can be safely upgraded to 4.9 except for mipsel-manda-01 which has the
buggy PMON.

Looking at the bug again, all the extra .bss space comes from the giant
mem_section array which is always used on Loongson due to
STATIC_SPARSEMEM being enabled. I am wondering if this patch might help
(and if it works for multi-node Loongsons like the 3B). The Loongson
memory initialization code takes a different path to other mips
sub-arches and avoids calling memory_present until the very end, so it
might not need STATIC_SPARSEMEM?

(patch is completely untested)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 7baddfa0e229..3bbb454ab2f5 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2559,7 +2559,7 @@ config ARCH_DISCONTIGMEM_ENABLE

 config ARCH_SPARSEMEM_ENABLE
bool
-   select SPARSEMEM_STATIC
+   select SPARSEMEM_STATIC if !MACH_LOONGSON64

 config NUMA
bool "NUMA Support"

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: Bug#858405: xmlto: intermittent Segmentation fault when building manpages for libreswan on mips64el

[James Cowgill]

reassign 858405 xsltproc
forcemerge 750593 858405
retitle 750593 xsltproc: bus error on some arches with linux < 4.1
thanks

Hi,

On 22/03/17 21:01, Daniel Kahn Gillmor wrote:
> On Wed 2017-03-22 06:22:41 -0400, James Cowgill wrote:
>> On 22/03/17 01:29, Daniel Kahn Gillmor wrote:
>>> For debian revisions of 3.20, failures happened on:
>>>
>>>   mipsel-manda-02
>>>   eberlin
>>> 
>>> Also for revisions of 3.20, successes happened on:
>>>
>>>   mipsel-sil-01
>>>   mipsel-manda-03
>>>   mipsel-manda-01
>>
>> This is a known issue and it only affects Loongson buildds.
>> Interestingly mipsel-manda-01 is Loongson and didn't fail there so there
>> may be a random element involved here. I don't think anyone's tracked
>> down the underlying issue though.
> 
> thanks, is there a public reference for the known issue that we can
> point to?

I think #750593 looks a lot like the bug here.

After some investigation, it seems I was being a bit unfair to Loongson.
This is arguably a non mips specific bug in Linux < 4.1. It just so
happens that all the Loongson buildds run jessie's 3.16 kernel and all
the other buildds run >= 4.7 from backports.

In #750593 there was lots of talk about stack overflows causing this but
there is actually another element to this. Indeed if I reduced the stack
size down with ulimit, the segfaults become more frequent, but
increasing the stack size didn't help at all. After looking at the
mappings for a failing process, I saw this (taken just after starting
xsltproc):

[...]
> fff7f5-fff7f5c000 ---p 4000 fd:00 1060250
> /usr/lib/mips64el-linux-gnuabi64/libeatmydata.so.1.1.2
> fff7f5c000-fff7f6 rw-p  fd:00 1060250
> /usr/lib/mips64el-linux-gnuabi64/libeatmydata.so.1.1.2
> fff7f6-fff7f88000 r-xp  fd:00 1060375
> /lib/mips64el-linux-gnuabi64/ld-2.24.so
> fff7f94000-fff7f98000 rw-p 00024000 fd:00 1060375
> /lib/mips64el-linux-gnuabi64/ld-2.24.so
> fff7f98000-fff7fa r-xp  fd:00 947544 
> /usr/bin/xsltproc
> fff7fa4000-fff7fac000 rw-p  00:00 0
> fff7fac000-fff7fb rw-p 4000 fd:00 947544 
> /usr/bin/xsltproc
> 1d4000-384000 rwxp  00:00 0  
> [heap]
> 9e-a04000 rwxp  00:00 0  
> [stack]
> ffc000-100 r-xp  00:00 0 
> [vdso]

Notice that there is a very small gap between the heap and the stack
here (at least compared to working xsltproc runs). I think that the heap
is growing to a point where it limits the maximum size of the stack and
so increasing the stack size with ulimit doesn't help.

The reason the program and the heap are at these very high addresses is
that xsltproc is built with PIE and the kernel is treating the
executable like a mmap and grouping it with all the other libraries. In
d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR") the behavior
changed and now the program and it's heap will be mapped at a lower
address so the bug does not affect newer kernels. Using "setarch -L" or
"setarch -R" is another workaround for this bug because that moves the
program so that there is a much larger gap between the heap and the stack.

This might affect other applications as well. Effectively it means that
PIE executables which use lots of stack space might not work properly
with jessie's kernel. The chances the bug will be hit seems to vary
between arches however (depending on what each arch does in
arch_pick_mmap_layout and arch_randomize_brk) - mips64el seems to be hit
pretty frequently. In xsltproc's case, PIE was enabled some time ago
which is why this bug is quite old.

I believe any of the following will fix this (but have not all been tested):
- Reduce the stack usage in xsltproc (the upstream bug)
- Upgrade the relevant buildds to Linux >= 4.1
- Apply d1fd836dcf00 to jessie's kernel
- Disable PIE in xsltproc.
- Run xsltproc inside setarch -L / setarch -R

>> For the moment, I'll rebuild libreswan again and hope a good buildd is
>> picked.
> 
> i see 5 mips64el rebuilds now at
> https://buildd.debian.org/status/logs.php?pkg=libreswan=3.20-6=sid,
> but none of them have succeded yet :/
> 
> 3 of the builds are from mipsel-manda-02, 1 is from eberlin, and one
> additional new "bad" builder is:
> 
>   mipsel-aql-01

There are 3 non-Loongson buildds: mipsel-aql-03, mipsel-manda-03 and
mipsel-sil-01. I expect libreswan will only build on one of those
buildds at the moment.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#851963: linux: enable SENSORS_ADM1031

[James Cowgill]

On 21/01/17 10:29, Roger Shimizu wrote:
> On Sat, Jan 21, 2017 at 6:05 PM, James Cowgill <jcowg...@debian.org> wrote:
>> Hi,
>>
>> On 21/01/17 08:05, Roger Shimizu wrote:
>>> Control: tag -1 +moreinfo
>>>
>>> On Fri, Jan 20, 2017 at 9:17 PM, James Cowgill <jcowg...@debian.org> wrote:
>>>> Source: linux
>>>> Version: 4.9.2-2
>>>> Severity: wishlist
>>>>
>>>> Hi,
>>>>
>>>> Please can you enable CONFIG_SENSORS_ADM1031 as a module.
>>>>
>>>> I have a Cavium Octeon board which needs this driver to be able to read
>>>> the CPU temperature / fan sensors.
>>>
>>> I see this module already exists in the kernel you're using.
>>> Can you help to confirm?
>>
>> I'm pretty certain it's not enabled. It is already enabled on x86 however.
> 
> Sorry, I just looked at amd64.
> So you're asking for mips64 octeon support, right?

Yes I am (although this isn't really MIPS specific, the board I have
just happens to use it).

James



signature.asc
Description: OpenPGP digital signature

Bug#851963: linux: enable SENSORS_ADM1031

[James Cowgill]

Hi,

On 21/01/17 08:05, Roger Shimizu wrote:
> Control: tag -1 +moreinfo
> 
> On Fri, Jan 20, 2017 at 9:17 PM, James Cowgill <jcowg...@debian.org> wrote:
>> Source: linux
>> Version: 4.9.2-2
>> Severity: wishlist
>>
>> Hi,
>>
>> Please can you enable CONFIG_SENSORS_ADM1031 as a module.
>>
>> I have a Cavium Octeon board which needs this driver to be able to read
>> the CPU temperature / fan sensors.
> 
> I see this module already exists in the kernel you're using.
> Can you help to confirm?

I'm pretty certain it's not enabled. It is already enabled on x86 however.

James



signature.asc
Description: OpenPGP digital signature

Bug#851963: linux: enable SENSORS_ADM1031

[James Cowgill]

Source: linux
Version: 4.9.2-2
Severity: wishlist

Hi,

Please can you enable CONFIG_SENSORS_ADM1031 as a module.

I have a Cavium Octeon board which needs this driver to be able to read
the CPU temperature / fan sensors.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#781892: (Hardware?) problem with denormal values on mipsel

[James Cowgill]

On Wed, 2015-05-27 at 20:46 +0200, Ole Streicher wrote:
 Hi all,
 
 Am 27.05.2015 um 15:45 schrieb James Cowgill:
  There's probably still a hardware bug in here somewhere, but before 3.16
  the kernel was fixing it with the math emulator.
 
 Without understanding the discussion in detail, I'd like to bring a few
 points here back: the issue is not about SIGILL on *any* call of sqrt; it is
 just when it is called with a denormal number. Using f.e. 1.134e-32 f.e.
 worked for me.

Yes the Loongson machines do not implement the sqrt.s instruction for
denormals, but it works for normalized numbers.

 Also, the minimal C analogon
 
 #include math.h
 int main(void) {
   float r = 1.1342362e-39;
   r = sqrt(r);
   exit(0);
 }

Your test case is wrong. If compiled without optimization, GCC call
'sqrt' from glibc instead of using the sqrt.s MIPS instruction. With
optimization GCC will remove the call altogether. This is different to
fortran because in fortran SQRT is a builtin intrinsic.

Try this instead (compile with -O2 -lm):

#include math.h
float x = 1.1342362e-39;
int main(void) {
  x = sqrt(x);
  return 0;
}

Thanks,
James


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

Re: (Hardware?) problem with denormal values on mipsel

[James Cowgill]

Control: reassign -1 src:linux 3.16.7-ckt9-2
Control: retitle -1 linux: mips sqrt.s instruction not emulated on Loongson 
processors
Control: tags -1 fixed-upstream
# Will be fixed in 4.1

On Tue, 2015-05-26 at 20:21 +0300, Aaro Koskinen wrote:
 On Tue, May 26, 2015 at 10:13:35AM +0100, James Cowgill wrote:
  On Sun, 2015-05-24 at 22:32 +0300, Aaro Koskinen wrote:
   On Fri, May 22, 2015 at 11:00:18PM +0100, James Cowgill wrote:
On Sat, 2015-05-23 at 00:04 +0300, Aaro Koskinen wrote:
 On Fri, May 22, 2015 at 05:27:14PM +0100, James Cowgill wrote:
  Yep it's a hardware problem. The following assembly dies (raises 
  SIGILL)
  at 'sqrt.s' on the Loongsons and works everywhere else:
  
  ===
  .set mips2
  .text
  .global main
  .type main, @function
  main:
  lui $t0, %hi(value)
  lwc1 $f0, %lo(value)($t0)
  nop
  sqrt.s $f0, $f0
  jr $ra
  
  .data
  value:
  .float 1.1342362e-39
  ===
 
 Is this a standalone reproducer program for the problem? Because
 I tried it on on my Loongson box and didn't get any SIGILL...

It should be. I tried it on some 3A machines at work and it crashed
there (and then some other machines which didn't crash). There's a 2F I
can try on Tuesday.
   
   My Loongson is 2F...
  
  I tried it on my 2F (it's a Lemote Fuloong) and it crashed there as well
  (both the gfortran and my testcase). It's running up to date jessie.
  
  What compiler versions do you have?
  What does the 'cpu model' line say in /proc/cpuinfo?
 
 I'm using binutils 2.25, GCC 5.1, Linux 4.1-rc5. The cpu model is:
 
 cpu model   : ICT Loongson-2 V0.3  FPU V0.1

Thanks! The kernel was the important part which was different to my
setup.

There's probably still a hardware bug in here somewhere, but before 3.16
the kernel was fixing it with the math emulator.

From what I can see:
Commit 08a07904e182 in 3.16 ('MIPS: math-emu: Remove most ifdefery.')
incorrectly disabled emulation of the sqrt.s instruction on processors
only supporting the mips2/mips3 ISA.

Commit 7352c8b13dd9 in 3.18 ('MIPS: Loongson: Set Loongson-3's ISA level
to MIPS64R1') worked around this in the Loongson 3s because their ISA
level was bumped to mips64r1.

Commit 2d83fea786d7 in 4.1-rc1 ('MIPS: Correct FP ISA requirements')
fixed the underlying sqrt.s emulation bug.

It would be good if the 4.1-rc1 patch or at least the 'case fsqrt_op'
part (which is the fix for this bug) can be applied to a jessie stable
kernel and then installed on the buildds. This should fix the original
problem of eso-midas failing to build on mipsel.

Thanks,
James


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

Bug#781892: (Hardware?) problem with denormal values on mipsel

[James Cowgill]

On Wed, 2015-05-27 at 18:13 +0100, Maciej W. Rozycki wrote:
 On Wed, 27 May 2015, James Cowgill wrote:
 
  Thanks! The kernel was the important part which was different to my
  setup.
  
  There's probably still a hardware bug in here somewhere, but before 3.16
  the kernel was fixing it with the math emulator.
  
  From what I can see:
  Commit 08a07904e182 in 3.16 ('MIPS: math-emu: Remove most ifdefery.')
  incorrectly disabled emulation of the sqrt.s instruction on processors
  only supporting the mips2/mips3 ISA.
  
  Commit 7352c8b13dd9 in 3.18 ('MIPS: Loongson: Set Loongson-3's ISA level
  to MIPS64R1') worked around this in the Loongson 3s because their ISA
  level was bumped to mips64r1.
  
  Commit 2d83fea786d7 in 4.1-rc1 ('MIPS: Correct FP ISA requirements')
  fixed the underlying sqrt.s emulation bug.
  
  It would be good if the 4.1-rc1 patch or at least the 'case fsqrt_op'
  part (which is the fix for this bug) can be applied to a jessie stable
  kernel and then installed on the buildds. This should fix the original
  problem of eso-midas failing to build on mipsel.
 
  What's the actual problem here, how can I help?

I just thought I would let you know since it was your patch which was
going to be applied somewhere.

The bug is that Loongson machines relied on the kernel emulating sqrt.s
for them (in certain cases) but between 3.16 and 4.1 it didn't and was
causing things to SIGILL.

Thanks,
James



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