Re: Peculiar problem with kmail on AMD64 current

[Dave Tyson]

On Monday 06 February 2017 09:44:17 Martin Husemann wrote:
> On Sun, Feb 05, 2017 at 06:51:19PM +, Dave Tyson wrote:
> > So it would appear that a userland program which should be insulated
> > from the underlying hardware by the kernel is being affected by different
> > H/W.
> Can you show the output from
> 
>   cpuctl identify 0
> 
> on both machines?
> 
> Some userland software detects cpu features at build time and hard codes
> that decsion into the binaries. This is a bug, of course.
> 
> Martin


Hi Martin,

Idents below.

Laptop which works:

laptoproot(laptop)root$ cpuctl identify 0
cpu0: highest basic info 000d
cpu0: highest extended info 8008
cpu0: "Intel(R) Core(TM)2 Duo CPU P8600  @ 2.40GHz"
cpu0: Intel Xeon 31xx, 33xx, 52xx, 54xx, Core 2 Quad 8xxx and 9xxx (686-
class), 2394.13 MHz
cpu0: family 0x6 model 0x17 stepping 0xa (id 0x1067a)
cpu0: features 
0xbfebfbff
cpu0: features 0xbfebfbff
cpu0: features 0xbfebfbff
cpu0: features1 0xc08e3fd
cpu0: features1 0xc08e3fd
cpu0: features2 0x2800
cpu0: features3 0x1
cpu0: xsave features 0x3
cpu0: xsave area size: current 576, maximum 576, xgetbv enabled
cpu0: enabled xsave 0x3
cpu0: I-cache 32KB 64B/line 8-way, D-cache 32KB 64B/line 8-way
cpu0: L2 cache 3MB 64B/line 12-way
cpu0: 64B prefetching
cpu0: ITLB 128 4KB entries 4-way, 8 2M/4 4M entries
cpu0: DTLB 256 4KB entries 4-way, 16 4MB entries 4-way
cpu0: Initial APIC ID 0
cpu0: Cluster/Package ID 0
cpu0: Core ID 0
cpu0: DSPM-eax 0x3
cpu0: DSPM-ecx 0x3
cpu0: SEF highest subleaf 
cpu0: microcode version 0xa0c, platform ID 7

Desktop which doesn't:

cruncherroot(cruncher)root$ cpuctl identify 0
cpu0: highest basic info 000d
cpu0: highest extended info 8008
cpu0: "Intel(R) Core(TM) i5-2320 CPU @ 3.00GHz"
cpu0: Intel Xeon E3-12xx, 2nd gen i7, i5, i3 2xxx (686-class), 2993.40 MHz
cpu0: family 0x6 model 0x2a stepping 0x7 (id 0x206a7)
cpu0: features 
0xbfebfbff
cpu0: features 0xbfebfbff
cpu0: features 0xbfebfbff
cpu0: features1 0x1f9ae3bf
cpu0: features1 0x1f9ae3bf
cpu0: features1 0x1f9ae3bf
cpu0: features2 0x28100800
cpu0: features3 0x1
cpu0: xsave features 0x7
cpu0: xsave instructions 0x1
cpu0: xsave area size: current 832, maximum 832, xgetbv enabled
cpu0: enabled xsave 0x7
cpu0: I-cache 32KB 64B/line 8-way, D-cache 32KB 64B/line 8-way
cpu0: L2 cache 256KB 64B/line 8-way
cpu0: L3 cache 6MB 64B/line 12-way
cpu0: 64B prefetching
cpu0: ITLB 128 4KB entries 4-way, 2M/4M: 8 entries
cpu0: DTLB 64 4KB entries 4-way, 2M/4M: 32 entries (L0)
cpu0: L2 STLB 512 4KB entries 4-way
cpu0: Initial APIC ID 0
cpu0: Cluster/Package ID 0
cpu0: Core ID 0
cpu0: SMT ID 0
cpu0: DSPM-eax 0x77
cpu0: DSPM-ecx 0x9
cpu0: SEF highest subleaf 
cpu0: microcode version 0x23, platform ID 1

Dave

Re: Peculiar problem with kmail on AMD64 current

[Martin Husemann]

On Sun, Feb 05, 2017 at 06:51:19PM +, Dave Tyson wrote:
> So it would appear that a userland program which should be insulated 
> from the underlying hardware by the kernel is being affected by different H/W.

Can you show the output from 

cpuctl identify 0

on both machines?

Some userland software detects cpu features at build time and hard codes
that decsion into the binaries. This is a bug, of course.

Martin

Peculiar problem with kmail on AMD64 current

[Dave Tyson]

I have run into a peculiar problem with kmail where it performs fine on one 
AMD64 system and yet the same kernel/userland/packages on other AMD64 
hardware results in kmail crashing when replying or forwarding a mail. 

I built/installed an recent 7.99.21 kernel/userland on a dual processor Dell 
AMD64 system and then built a whole raft of packages (pkgsrc current) and did 
some  basic testing. Pretty much everything worked as expected, including 
sound on kde etc. I  copied the binary packages and config files to two other 
AMD64 systems, a T400 laptop also running 7.99.21 and a quad processor system 
(same release) which is my main desktop system and I spotted the problem on 
the latter. Kmail worked fine for new mails/reading mail, but if you replied 
or forwarded a mail inline it crashed - a segment violation.

Strangely the laptop didn't suffer this problem whatsoever and I assumed some 
slight variation of config files/libraries/etc was triggering an issue in 
kmail on the other systems.

However if I removed the laptop disk and used it to boot the other systems, 
the kmail problem showed up - and now there was no doubt the software was the 
same! 

So it would appear that a userland program which should be insulated 
from the underlying hardware by the kernel is being affected by different H/W. 
The only thing kmail is doing is opening a new window under X and no other 
program has shown the problem so I am discounting an issue with the underlying 
X video kit. If a mail was forwarded as an attachment then it worked fine on 
any system so I guess its something to do with memory allocation. The systems 
all have differing amounts of physical memory - the laptop has 3g, the Dell 4g 
and the other system 16g. 

Can anyone suggest what's going on. A pkgsrc build from about a year ago on a  
correspondingly old version of current has worked faultlessly with kmail  
behaving as expected on all three systems... A more recent build of the latest 
current + pkgsrc still shows the same problem on the Dell - but I haven't 
tried moving the disk on the laptop yet.
   

   
Cheers, 
   
Dave