gmane.os.netbsd.ports.x86-64

RE: py-m2crypto fails for pkgsrc build Q12012

Derrick Lobo — 2012-05-16T16:11:41

Updating typo..

-----Original Message-----
From: port-amd64-owner< at >NetBSD.org [mailto:port-amd64-owner< at >NetBSD.org] On
Behalf Of Derrick Lobo
Sent: Wednesday, May 16, 2012 12:04 PM
To: 'Port-Amd64< at >Netbsd. Org'
Subject: pu-m2crypto fails for pkgsrc build Q12012

Hi All
building m2crypto fails with the following error.




Crypto.__m2crypto' extension
swigging SWIG/_m2crypto.i to SWIG/_m2crypto_wrap.c swig -python
-I/usr/pkg/include/python2.6 -I/usr/include -o SWIG/_m2crypto_wrap.c
SWIG/_m2crypto.i
SWIG/_bio.i:64: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_rand.i:21: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_evp.i:159: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_dh.i:36: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_rsa.i:43: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_dsa.i:31: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_ssl.i:214:

pu-m2crypto fails for pkgsrc build Q12012

Derrick Lobo — 2012-05-16T16:03:50

Hi All
building m2crypto fails with the following error.




Crypto.__m2crypto' extension
swigging SWIG/_m2crypto.i to SWIG/_m2crypto_wrap.c
swig -python -I/usr/pkg/include/python2.6 -I/usr/include -o
SWIG/_m2crypto_wrap.c SWIG/_m2crypto.i
SWIG/_bio.i:64: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_rand.i:21: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_evp.i:159: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_dh.i:36: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_rsa.i:43: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_dsa.i:31: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_ssl.i:214: Warning(454): Setting a pointer/reference variable may leak
memory.
SWIG/_x509.i:323: Warning(454): Setting a pointer/reference variable may
leak memory.
SWIG/_pkcs7.i:44: Warning(454): Setting a pointer/reference variable may
leak memory.
SWIG/_pkcs7.i:44: War

Re: linux emulation: rt_sigtimedwait

Christos Zoulas — 2012-05-10T23:18:36

In article <20120510202424.GG10705< at >trav.math.uni-bonn.de>,
Edgar Fuß  <ef< at >math.uni-bonn.de> wrote:

You probably don't use objdirs?
WRKOBJDIR=              /usr/obj/${MACHINE}/pkgsrc


christos

Re: linux emulation: rt_sigtimedwait

Edgar Fuß — 2012-05-10T20:24:25

Marvellous! Thanks so much.
Will this be pulled up to 6.0?

Oops? I have
/usr/pkg/emul/linux32/opt/tivoli/tsm/client/ba/bin/dsm.opt -> ../../../../../../../../etc/tsm/dsm.opt
and I don't think I changed something in that part since the version I uploaded.

Re: linux emulation: rt_sigtimedwait

Christos Zoulas — 2012-05-10T19:41:05

In article <20120509213526.GK428< at >trav.math.uni-bonn.de>,
Edgar Fuß  <ef< at >math.uni-bonn.de> wrote:

Fixed on head, runs with suse-12.1. FYI the package installs symlinks
pointing to the build directory for dsm.opt and dsm.sys

christos

Re: Dell Vostro 200 boot problems

Martin Husemann — 2012-05-10T15:54:54

I found options MPDEBUG and tried it:

as exected, it dies early when attaching cpu1 with "did not become ready".
I set a breakpoint on cpu_hatch, but it never makes it there.

It runs through mp_startup, since I find the cpu_trace[] array contains
0x40, 0x1, 0xff, so it should have passed the HALT(1) there.

pmap_largepages is 1.

Can somebody with more x86 knowledge please help me track this down?

Side question: should we cope better and detach that cpu (or something)
so the machine would at least come up as UP?

Martin

Re: linux emulation: rt_sigtimedwait

Edgar Fuß — 2012-05-09T21:35:27

I can't since it's IBM's proprietary TSM client.

The current state of my attempt to pkgsrc the TSM client can be found here:
http://www.math.uni-bonn.de/people/ef/tsm.tgz
Currently, it's switched to using SuSE 10 because that allows me to
circumvent the problem by setting emul.linux32.kern.osrelease to 2.4.18.
You can just comment out the suse-10 lines to make it use the default 11.

Re: linux emulation: rt_sigtimedwait

Christos Zoulas — 2012-05-09T18:21:53

In article <F6478A84-F8EF-4030-920A-F18AFBDD454C< at >math.uni-bonn.de>,
Edgar Fuß  <ef< at >math.uni-bonn.de> wrote:

You'll need to add debugging to it to see where it fails or put the binary
up for ftp so that others can debug this.

christos

Re: linux emulation: rt_sigtimedwait

Edgar Fuß — 2012-05-09T16:24:29

EF> Or is it the bumped Linux kernel version that may cause the binary to use
EF> or not use that system call?
EF> 
EF> When I set emul.linux32.kern.osrelease=2.4.18 (as in 4.0), I simply get
EF> "FATAL: kernel too old".
OK, when I downgrade to SuSE 10.0 and emul.linux32.kern.osrelease=2.4.18,
it works. So I at least have a workaround.

Dell Vostro 200 boot problems

Martin Husemann — 2012-05-09T16:16:07

After seeing reports about some Dell machines not being able to boot our
stock install CDs, I walk around the office and tested a -current amd64 CD
on all Dell machines I found.

One of them, a slightly oldish Vostro 200, indeed failed to boot it.

There are two separate problems. First, the usb keyboard is turned into
a legacy pc keyboard via some emulation by the bios. Maybe this can be
turned off, but I didn't want to change too many settings, as it is not
my personal machine.

This, however, is both good an bad. Bad, because the keyboard does not
work - keyboard attaches at pckbc, but later the usb port is blocked
and bios does not give up ownership. Then our usb code disables the port,
and the keyboard is dead. Good, because by booting with -c and disabling
ehci and uhci I get a working keyboard very early, even before ukbd would
have a chance to attach.

Now let us ignore the keyboard problem for now. The machine hangs when it
should discover ATA devices. Everything waits for those to finish probing
an

Re: linux emulation: rt_sigtimedwait

Edgar Fuß — 2012-05-09T15:57:10

My impression is that id did work in 4.0.
Or is it the bumped Linux kernel version that may cause the binary to use
or not use that system call?

When I set emul.linux32.kern.osrelease=2.4.18 (as in 4.0), I simply get
"FATAL: kernel too old".

Re: linux emulation: rt_sigtimedwait

Edgar Fuß — 2012-05-09T14:14:37

Yes. As far as I can see, the TSM client is available as a 64-bit application only from 6.3 onwards, which requires a 6.x server.
However, the server I use runs 5.5.

Oops. Any hints how to fix that?

Re: linux emulation: rt_sigtimedwait

Joerg Sonnenberger — 2012-05-09T13:53:35

I take it you are running a 32bit binary? The rt_sigtimedwait in linux32
is completely bogus...

Joerg

linux emulation: rt_sigtimedwait

Edgar Fuß — 2012-05-09T13:36:24

So I'ved pkgsrc-ed IBM's proprietary Tivoli Storage Manager client, and, on 6.0_BETA/amd64, I get:

 14453  14453 dsmc     CALL  mmap2(0,0x400000,7,0x20022,0xffffffff,0)
 14453  14453 dsmc     RET   mmap2 4212715520/0xfb18f000
 14453  14453 dsmc     CALL  mprotect(0xfb18f000,0x1000,0)
 14453  14453 dsmc     RET   mprotect 0
 14453  14453 dsmc     CALL  clone(0x3d0f00,0xfb58e494,0xfb58ebd8,0xbfffec60,0xfb58ebd8)
 14453  14453 dsmc     RET   clone 29374/0x72be
 14453  14453 dsmc     CALL  select(0,0,0,0,0xbfffed58)
 14453  29374 dsmc     RET   fork 0
 14453  29374 dsmc     CALL  set_robust_list(0xfb58ebe0,0xc)
 14453  29374 dsmc     RET   set_robust_list 0
 14453  29374 dsmc     CALL  rt_sigtimedwait(0x8455b3c,0,0,8,0x841faf8,0xfb58e2f8)
 14453  29374 dsmc     RET   rt_sigtimedwait -1 errno -14 Bad address
 14453  29374 dsmc     CALL  time(0)
 14453  29374 dsmc     RET   time 1336570114/0x4faa7102
 14453  29374 dsmc     CALL  netbsd32_write(3,0xfb58a8d0,0x36)
 14453  29374 dsmc     GIO   fd 3 wrote 54 bytes

Re: BETA6.0 - AMD Opetron 6272 (16 core) multiprocessor config crashes

Tom Ivar Helbekkmo — 2012-05-08T08:57:22


This box has been getting these hangs annoyingly often, and has also
been dropping into the debugger on NMI from time to time.  One or the
other, most often the hang, would happen once or twice per day.  I never
wrote down any backtraces from the NMI traps, thinking it was a flaky
RAM module (even though this was kind of strange, since the machine has
redundant (mirrored) RAM), but at least once I noticed the kernel was
doing something memory mapping-related when it happened.

Then, Martin Husemann suggested I try disabling the direct map stuff, by
editing sys/arch/amd64/include/types.h, and getting rid of these defines,
near the end of the file:

#include "opt_xen.h"
#if defined(__x86_64__) && !defined(XEN)
#define__HAVE_DIRECT_MAP 1
#define__HAVE_MM_MD_DIRECT_MAPPED_IO
#define__HAVE_MM_MD_DIRECT_MAPPED_PHYS
#define__HAVE_CPU_UAREA_ROUTINES
#endif
#endif

I wrapped the block of four defines in an #if 0 / #endif pair, and built
a new kernel.  This was five days ago, and there hasn't been a single
incid

Re: ddb fails to write breakpoint

David Laight — 2012-05-02T18:58:12

cpu0: Intel Pentium Pro, II or III (686-class), 3511.64 MHz, id 0x206a7
cpu0: features  0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features  0xbfebfbff<PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR>
cpu0: features  0xbfebfbff<SSE,SSE2,SS,HTT,TM,SBF>
cpu0: features2 0x179ae3bf<SSE3,PCLMULQDQ,DTES64,MONITOR,DS-CPL,VMX,EST,TM2>
cpu0: features2 0x179ae3bf<SSSE3,CX16,xTPR,PDCM,PCID,SSE41,SSE42,POPCNT,B24>
cpu0: features2 0x179ae3bf<AES,XSAVE,AVX>
cpu0: features3 0x28100800<SYSCALL/SYSRET,XD,EM64T>
cpu0: features4 0x1<LAHF>
cpu0: "Intel(R) Core(TM) i7-2700K CPU < at > 3.50GHz"
cpu0: ITLB 64 4KB entries 4-way
cpu0: DTLB 64 4KB entries 4-way
cpu0: Initial APIC ID 0
cpu0: Cluster/Package ID 0
cpu0: Core ID 0
cpu0: SMT ID 0
cpu0: family 06 model 0a extfamily 00 extmodel 02 stepping 07
cpu0: UCode version: ?

David

Re: BETA6.0 - AMD Opetron 6272 (16 core) multiprocessor config crashes

Tom Ivar Helbekkmo — 2012-05-02T17:56:40


It happened again after updating to -current as of May 1st.  I've now
booted it with SMP disabled.  If it stays up for a few days running on
one CPU, that should be a reasonably good indication that the problem is
SMP related.


I'd still like to get this to work with a serial console.  Any hints?

-tih

Re: BETA6.0 - AMD Opetron 6272 (16 core) multiprocessor config crashes

Manuel Bouyer — 2012-05-01T18:10:10

I tested again with an up-to-date HEAD kernel on the 4-6282 server.
I've scp'ed 29GB of data, containing both small files (src and pkgsrc trees)
and large ones (xen disk images). No problems.

Could it be related to some BIOS settings ? I don't remember the details;
I think I just disabled the on-board IDE controller. Console is on
com2 (which I had to enable in the kernel) if that makes a difference.
The network controller is:
wm0 at pci2 dev 0 function 0: 82576 1000BaseT Ethernet (rev. 0x01)

connected to a 100Mbs switch. Disk controller is:
mpii0 at pci1 dev 0 function 0: vendor 0x1000 product 0x0072 (rev. 0x03)

RE: BETA6.0 - AMD Opetron 6272 (16 core) multiprocessor config crashes

Derrick Lobo — 2012-05-01T15:38:59

Manuel

I have tried the latest HEAD kernel from yesterdays build and the server
crashed when I started scp'ing a file..

I can replicate this issue on all three of the new servers.. 

I am also using a LSI 2108 as the primary disk controller so not sure if
theres some irq clash.. however seems like disabling SMP seems to fix the
issue rightaway.. I was also able to build couple of custom kernel by
turning of SMP...

Derrick


-----Original Message-----
From: Manuel Bouyer [mailto:bouyer< at >antioche.eu.org] 
Sent: Monday, April 30, 2012 4:01 PM
To: Derrick Lobo
Cc: 'Port-Amd64< at >Netbsd. Org'
Subject: Re: BETA6.0 - AMD Opetron 6272 (16 core) multiprocessor config
crashes

On Mon, Apr 30, 2012 at 02:57:04PM -0400, Derrick Lobo wrote:

Can you try a HEAD kernel ? I've been playing with NetBSD on a 4-6282 system
and couldn't make the kernel crash ...

--
Manuel Bouyer <bouyer< at >antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

Re: ddb fails to write breakpoint

Jean-Yves Migeon — 2012-05-01T13:19:13

Le 01/05/12 08:38, David Laight a écrit :

Also a possibility. Could you send me the result of 'cpuctl identify 0', 
please?

Re: BETA6.0 - AMD Opetron 6272 (16 core) multiprocessor config crashes

Martin Husemann — 2012-05-01T09:00:32

I have one machine (phenom II x6) which locks up on heavy disk access
"sometimes". Usually a build.sh -j 12 is good enough to trigger it.
Lockup is realy hard, no ddb.

I have no idea how to debug this :-(

On other amd64 machines -current runs just fine for me, no matter how hard
I beat on it.

Martin