http://blog.gmane.org/gmane.os.netbsd.ports.x86-64 hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4505 <pre>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</pre> Derrick Lobo 2012-05-16T16:03:50 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4496 <pre>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</pre> Martin Husemann 2012-05-09T16:16:07 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4492 <pre>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 </pre> Edgar Fuß 2012-05-09T13:36:24 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4479 <pre>I tried to set a kerneld db breakpoint on amd64 current (6.99.6) but the system just dumped - couldn't see why since it all scrolled away. Attempts to write into code space fault in ddb. The following makes it work - but is clearly ott. --- arch/amd64/amd64/db_memrw.c 23 Nov 2011 01:15:02 -0000 1.9 +++ arch/amd64/amd64/db_memrw.c 30 Apr 2012 20:49:21 -0000 &lt; at &gt;&lt; at &gt; -146,6 +146,7 &lt; at &gt;&lt; at &gt; db_write_text(vaddr_t addr, size_t size, pmap_pte_clearbits(ppte, PG_KR); pmap_pte_setbits(ppte, PG_KW); pmap_update_pg(pgva); +tlbflushg(); /* * Page is now writable. Do as much access as we &lt; at &gt;&lt; at &gt; -160,6 +161,7 &lt; at &gt;&lt; at &gt; db_write_text(vaddr_t addr, size_t size, pmap_pte_clearbits(ppte, PG_KW); pmap_pte_setbits(ppte, PG_KR); pmap_update_pg(pgva); +tlbflushg(); } while (size != 0); } pmap_update_pg(addr) is just the single instruction 'invlpg adddr' tlbflushg() is a full tlb zap. Not looked at what invlpg is supposed to do, or whether it is an adequate synchronising instruction. cpu is an</pre> David Laight 2012-04-30T21:24:36 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4474 <pre>Hi All. I am using the /201204271810Z/ built version of BETAnetbsd6 on a H8DG6-F, it has one AMD 6272 with 16 cores.. The server crashes with no errors on the console or logs for a simple untar.. booting the server with -12(Disable SMP) boots it with one core and the server is stable.. I have the following turned on the kernel and still don't see a thing in the logs.. # Diagnostic/debugging support options options DIAGNOSTIC # expensive kernel consistency checks # XXX to be commented out on release branch options DEBUG # expensive debugging checks/support options LOCKDEBUG # expensive locking checks/support options KMEMSTATS # kernel memory statistics (vmstat -m) options DDB # in-kernel debugger options DDB_ONPANIC=1 # see also sysctl(8): `ddb.onpanic' options DDB_HISTORY_SIZE=512 # enable history editing in DDB #options KGDB # remote debugger #options </pre> Derrick Lobo 2012-04-30T18:57:04 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4470 <pre>I am looking for a PCI-E controller to run my new HP 1/8 LTO-4 Autoloader on a HP DL380/G5 Server. The DL380/G5 has 2 half height PCI-E slots and 3 full height PCI-E slots. I see on the supported hardware list the Adaptec AHA-29320LP is supported. This is a PCI-X based card. I have found a AHA-29320LPE which appears to be a PCI-E version of the card. Does anyone have any experience with this PCI-E version of this card on NetBSD/amd64 V5.1? Thank you Scott. </pre> Scott Burns 2012-04-28T01:59:44 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4467 <pre>Hello, I ran into a problem here, where NetBSD wouldn't boot as Xen dom0. I tracked it down to ACPI requesting a mapping to a memory area no allocated to the dom0: the address is just above 4GB. This looks wrong to me, because such adresss wouldn't work with i386 anyway. The attached patch got NetBSD/Xen working for me, but with these messages: mainbus0 (root) acpi_md_OsMapMemory 0x40e len 2 acpi_md_OsMapMemory 0x9d800 len 1024 acpi_md_OsMapMemory 0xe0000 len 131072 acpi_md_OsMapMemory 0xfacd0 len 36 acpi_md_OsMapMemory 0xd7e70100 len 36 acpi_md_OsMapMemory 0xd7e70100 len 132 acpi_md_OsMapMemory 0xd7e70290 len 36 acpi_md_OsMapMemory 0xd7e70290 len 244 acpi_md_OsMapMemory 0xd7e707c0 len 36 acpi_md_OsMapMemory 0xd7e94000 len 36 acpi_md_OsMapMemory 0xd7e70390 len 36 acpi_md_OsMapMemory 0xd7e70600 len 36 acpi_md_OsMapMemory 0xd7e94040 len 36 acpi_md_OsMapMemory 0xd7e7a7c0 len 36 acpi_md_OsMapMemory 0xd7e7a800 len 36 acpi_md_OsMapMemory 0xd7e7adc0 len 36 acpi_md_OsMapMemory 0xd7e7ae30 len 36 acpi_md_OsMapMemory </pre> Manuel Bouyer 2012-04-21T20:47:21 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4449 <pre>Hello, the attached patch, based on a patch sent by Mindaugas Rasiukevicius on tech-kern&lt; at &gt; some time ago, bumps the max number of CPUs to 256 for amd64, and should easily allow up to 64 for Xen/amd64. I tested it on a x86 with 64 AMD cores (lighly as this box has now known drive yet - some driver hacking is needed), 8 intel cores and with a Xen domU with 4 core. I didn't notice regressions so far. Comments before I commit ? </pre> Manuel Bouyer 2012-04-16T21:05:04 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4445 <pre> Hi, While trying to chase some unaligned memory access originally noticed on alpha, i wanted to have a way to detect this on amd64 ... Unfortunately, the attached sample code does not fail with SIGBUS on NetBSD/amd64 unlike other OSes i checked (Linux and FreeBSD). It simply tries to set the Alignment Check bit from RFLAGS register and then trigger an unaligned memory access. Any specific reason for such a behaviour ? Thanks. njoly&lt; at &gt;lanfeust [tmp/malign]&gt; uname -a NetBSD lanfeust.sis.pasteur.fr 6.99.4 NetBSD 6.99.4 (LANFEUST) #2: Mon Apr 9 23:30:03 CEST 2012 njoly&lt; at &gt;lanfeust.sis.pasteur.fr:/local/src/NetBSD/obj.amd64/sys/arch/amd64/compile/LANFEUST amd64 njoly&lt; at &gt;lanfeust [tmp/malign]&gt; cc -o malign malign.c njoly&lt; at &gt;lanfeust [tmp/malign]&gt; ./malign 0 njoly&lt; at &gt;kiri-adm1 [~]&gt; uname -a Linux kiri-adm1.cluster.pasteur.fr 2.6.18-274.12.1.el5 #1 SMP Tue Nov 29 13:37:46 EST 2011 x86_64 x86_64 x86_64 GNU/Linux njoly&lt; at &gt;kiri-adm1 [~]&gt; cc -o malign malign.c njoly&lt; at &gt;kiri-adm1 [~]&gt; ./malign zsh: bus error (core dumped) ./ma</pre> Nicolas Joly 2012-04-10T09:21:22 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4438 <pre>I'd like to switch one of my NetBSD/i386 machines to amd64. There's one that's known to run amd64, but it's not really very switchable at present, so I was looking for another one. I tried the most available one and it simply reset as soon as the bootloader had loaded the kernel off the install CD, so I assume that hardware is not recent enough to run 64bit. Is there an easy way to tell, given a root shell on a NetBSD/i386 machine, whether the hardware is NetBSD/amd64-compatible (or at least 64-bit compatible - I recognize there may be differences in supported hardware and the like in corner cases)? Looking at the list of features reported for the CPUs on the one known-to-run-amd64 machine and the one that isn't, I didn't see anything in the differences that screamed "I'm 64-bit-ready!" to me. My Web-fu is weak at best, but I did some poking around, and my best guess is that features2 including SSE3 is a pretty good correlate. Might this be correct? Or is there a better test? /~\ The ASCII Mouse</pre> Mouse 2012-04-09T16:57:37 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4426 <pre>Hi All, I've recently got a new bulldozer CPU (see all my other recent woes!), which is now running just wonderfully with NetBSD 6.0_BETA, so I thought I'd give Xen a go. Unfortunatly it seems quite crashy. Xen is built with the following kernel config, although the generic DOM0 is no better:- http://188.222.86.41/~ian/xen/salome_XEN0.txt Booting from a bootloader from around 5.99.62ish, using the following: load /netbsd.xen3 root=wd0a console=pc;multiboot /usr/pkg/xen41-kernel/xen.gz dom0_mem=12G Machine is a 6 core AMD FX-6100 (6 core bulldozer, family 0x15), AMD 880G mobo, 16 gig of memory. It will boot and stay up fine under light load, but anything heavy will bring it down to it's knees, usually after only a few minutes. (A compile of a kernel is enough.) When booting I get a lot of:- pmap_kenter_pa: mapping already present and over time dmesg fills up with: evtchn_do_event: handler 0xffffffff8021a38f didn't lower ipl 8 7 (If someone can point me how to find what's at this address I'll be h</pre> Ian Clark 2012-02-20T21:51:24 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4424 <pre>I have a machine that shows this as vmstat -i output: interrupt total rate TLB shootdown 96203 23 cpu0 timer 59370 14 ioapic0 pin 19 74663 18 ioapic0 pin 17 3 0 ioapic0 pin 18 285 0 ioapic0 pin 16 7905 1 Total 238429 59 Look at the cpu0 timer line - and imagine how this breaks everything big time. I tried hpet0 and ACPI-Fast as timecounter sources instead of TSC, but this did not seem to make a difference. Any hints what to try? Martin Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of</pre> Martin Husemann 2012-02-14T09:03:13 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4411 <pre>Hi All.. I recently got a Supermicro 6000 - 16core H8DG6-F with an AMD Opteron 6276 however the SAS controller and network adapter are not recognized by netbsd current dated yesterday. The freebsd drivers are available by Supermicro. Any help porting this to netbsd would be highly appreciated. Derrick Lobo </pre> Derrick Lobo 2012-02-02T14:34:55 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4400 <pre>Hi All, I've been having some issues with boot hanging on a new AMD 6 core bulldozer box. (6 core FX6100 - AMD 880G chipset, gigabyte GA-880GMA-USB3 with F4 bios.) http://mail-index.netbsd.org/netbsd-users/2011/11/14/msg009560.html I was able to keep it fairly stable by booting a 5.99.59 kernel without ACPI, although newer kernels seem less stable in this regard. I've reformatted / (as I had bootloader issues preventing me loading a newer kernel, and couldn't get the newest bootloader to work.) Although I am running the same contents of / (root is ffs2, hd is 500g or so) So I'm now running 5.99.59 userland (from 22nd November IIRC) and associated bootloader, with a kernel from a few days ago (5.99.62) I still get the boot pauses if I enable ACPI, and the machine, even if booted -2 won't stay up under heavy load (I can get 1 or 2 builds of the source tree in maybe if I'm lucky.) However, tonight I tried fiddling with the BIOS a bit more, and disabled HPET, C1E support and C6 support. This seemed to all</pre> Ian Clark 2012-01-31T19:33:01 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4386 <pre>I already asked some of these questions some time ago, but got zero replies. So I'll try to widen the audience. However, I'm not subscribed to port-i386. I must enlarge the storage capacity of our file server. This means updating from SCA to SAS and fron PCI-X to PCIe, so, new hardware. The current file server runs under NetBSD 4.0.1/amd64, and I'd like to run the new one under NetBSD, too (probably 5.1) although already having been asked why the hell we're not using Windo^WLinux like everybody else does. I'm not personally after buying only the most recent hardware, but it seems virtually impossible to buy non-recent one. So, are there any recommendations for current Opteron motherboards with good NetBSD support? My main concern is SAS. It looks like there's no support for any SAS-2 controller yet, only for the (SAS-1) LSI 1068. This sounds strange. What does wasabi use in their storage products? We don't need any RAID functionality because RAIDframe works well for us. Some SAS backplanes we may end up</pre> Edgar Fuß 2012-01-17T19:25:04 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4381 <pre> Hi, I do have a test code (attached) to exercise the fpsetmask() function which works fine on both i386 and alpha (if compiled with -mieee-with-inexact) but fails on amd64. For a floating point inexact result, when unmasked, a SIGFPE signal is correctly sent but the siginfo si_code member is not set to FPE_FLTRES. Do i miss something or this is a bug ? Thanks. </pre> Nicolas Joly 2012-01-10T22:37:22 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4378 <pre>Time to buy new hardware. Does anyone run 5.x on a Tyan S8212? The LAN ports are Intel 82574L and Intel 82575EB, does wm(8) support them (apart from the ``lots of ACK'' problem) in 5.x? The SAS controller is an LSI SAS1068E, I suppose that's fine with mpt(8). Does mpt(8) support/work with port multipliers? Thanks for any comments. </pre> Edgar Fuß 2012-01-02T19:34:58 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4368 <pre>Hi, I've reworked the spl code in XEN to use a single entry point into C code, and to optimise the pending event processing via spllower() See: ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/tmp/port-xen/spl.diff I'd love for as much test reportage as possible with this patch. dom0 is reported to hang on launching domUs. I'd like this verified on PAE kernels if possible. Please include relevant dmesg/console output. tech-kern&lt; at &gt; is Cc:ed for more eyes to see if I've missed anything obvious. port-i386/amd64&lt; at &gt; is Cc:ed because I've removed some of the common assembler bits from the XEN path and added some new. Review would be useful. I'm hoping this doesn't affect anything for non-XEN. Many Thanks, </pre> Cherry G. Mathew 2011-12-19T19:27:13 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4367 <pre>I am looking for a tape changer solution for numerous HP DL380 G5 machines running NetBSD/amd64 5.1. They all have the traditional HP Smart Array 3 controllers: ciss0 at pci7 dev 0 function 0: HP Smart Array 3 ciss0: interrupting at ioapic0 pin 18 ciss0: 2 LDs, HW rev 3, FW 7.22/7.22 scsibus0 at ciss0: 2 targets, 1 lun per target I am looking at the following unit as I have had good luck with the LTO-3 SCSI version of this unit: HP 1/8 G2 LTO-4 Ultrium 1760 SAS Tape Autoloader (AK377A) My question is what controller do I need to order that NetBSD will support for drive and changer support with this auto-loader? Thank you in advance Scott Burns Scott.Burns&lt; at &gt;SeQent.Com dmesg below: NetBSD 5.1 (GENERIC) #0: Sat Nov 6 13:19:33 UTC 2010 builds&lt; at &gt;b6.netbsd.org:/home/builds/ab/netbsd-5-1-RELEASE/amd64/201011061 43Z-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/amd64/compile/GENERIC total memory = 16381 MB avail memory = 15868 MB timecounter: Timecounters tick every </pre> Scott Burns 2011-12-18T01:08:18 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4359 <pre>Is there any reason all of man8/i386 shouldn't be replicated into man8/amd64? Things like mbr.8, bootselect.8, etc can all apply to an amd64 box since booting via the bios is the same still. Basically very confusing to install and amd64 box and try to figure out how to use mbr_bootsel when man -k mbr shows zero hits. James </pre> James Chacon 2011-12-15T18:38:21 http://comments.gmane.org/gmane.os.netbsd.ports.x86-64/4323 <pre>hi, what kind of the strange problems? i haven't noticed any problems on my system running this reverted. YAMAMOTO Takashi </pre> YAMAMOTO Takashi 2011-11-29T06:36:23 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.netbsd.ports.x86-64