Re: iwn driver issue
On 0613T1251, David Wolfskill wrote: On Fri, Jun 13, 2014 at 09:36:35PM +0200, Edward Tomasz Napiera??a wrote: ... I normally don't spend a huge amount of time in head -- enough to build it do a quick smoke-test. So it's certainly possible that it merits further exploration. And I'm willing experiment, but I cannot test it while I'm at work (as I don't use the wireless NIC at work -- I use it almost exclusively while I'm at home (and other places), though). It would be great if you could help me with this. Basically you need to enable crashdumps, as described below, and obtain a backtrace. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html I have had crash dumps on panics running head (slice 4 of the boot device, in my case) in the past, so that process works. I just didn't get a dump this morning. :-( d130(9.3)[1] grep dump /S4/etc/rc.conf dumpdev=AUTO d130(9.3)[2] Hm. Well, if it fails the second time then I guess I'll just add a sysctl to disable the fix. But let's try to get a crashdump anyway :-) Just for the record, the easiest way to make iwn firmware panic is to enter ddb (ctrl-alt-esc), wait five seconds and exit it (center). Does that process yield useful information? (That is, is that process sufficiently similar to a sequence of events that occurs in the real world that the resulting information may be used to figure out how to make the code avoid misbehavior?) Well, it triggers the iwn firmware panic, which in turn triggers the code I've attached, which apparently causes kernel panic. But I cannot guarantee that it _will_ trigger the problem. If so, I can try that soonish (e.g., en route home today, once I've boarded the train -- vs. while I'm still on my bike :-}). Thanks. Even just replying to emails whilst on bike is impressive, especially with mutt. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Occasional GPU lockups
Hello, I get those occasional GPU lockups and just want to know if this is known problem. When they occur my monitor turn offs for few seconds and then goes back on again. My hardware: http://people.freebsd.org/~pawel/dmesg.txt Current built today, error message: drmn0: error: GPU lockup CP stall for more than 1msec drmn0: warning: GPU lockup (waiting for 0x10dd last fence id 0x10a2) drmn0: info: Saved 1879 dwords of commands on ring 0. drmn0: info: GPU softreset: 0x0003 drmn0: info: GRBM_STATUS = 0xA0003828 drmn0: info: GRBM_STATUS_SE0 = 0x0007 drmn0: info: GRBM_STATUS_SE1 = 0x0007 drmn0: info: SRBM_STATUS = 0x20C0 drmn0: info: R_008674_CP_STALLED_STAT1 = 0x drmn0: info: R_008678_CP_STALLED_STAT2 = 0x4100 drmn0: info: R_00867C_CP_BUSY_STAT = 0x00020182 drmn0: info: R_008680_CP_STAT = 0x80028243 drmn0: info: GRBM_SOFT_RESET=0x7F6B drmn0: info: GRBM_STATUS = 0x3828 drmn0: info: GRBM_STATUS_SE0 = 0x0007 drmn0: info: GRBM_STATUS_SE1 = 0x0007 drmn0: info: SRBM_STATUS = 0x20C0 drmn0: info: R_008674_CP_STALLED_STAT1 = 0x drmn0: info: R_008678_CP_STALLED_STAT2 = 0x drmn0: info: R_00867C_CP_BUSY_STAT = 0x drmn0: info: R_008680_CP_STAT = 0x drmn0: info: GPU reset succeeded, trying to resume info: [drm] probing gen 2 caps for device 1022:960b = 2/0 info: [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 info: [drm] PCIE GART of 512M enabled (table at 0x0004). drmn0: info: WB enabled drmn0: info: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x0xf800021c8c00 drmn0: info: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x0xf800021c8c0c info: [drm] ring test on 0 succeeded in 2 usecs info: [drm] ring test on 3 succeeded in 1 usecs info: [drm] ib test on ring 0 succeeded in 0 usecs info: [drm] ib test on ring 3 succeeded in 1 usecs lock order reversal: 1st 0xf80004f374b8 kmslk (kmslk) @ /old/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc.c:1960 2nd 0xf80004f370a0 drmslk (drmslk) @ /old/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_gem.c:188 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe046c8fe720 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe046c8fe7d0 witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe046c8fe860 _sx_xlock() at _sx_xlock+0x75/frame 0xfe046c8fe8a0 drm_gem_object_unreference_unlocked() at drm_gem_object_unreference_unlocked+0x37/frame 0xfe046c8fe8d0 radeon_crtc_cursor_set() at radeon_crtc_cursor_set+0x1bc/frame 0xfe046c8fe920 drm_mode_cursor_ioctl() at drm_mode_cursor_ioctl+0xc5/frame 0xfe046c8fe960 drm_ioctl() at drm_ioctl+0x381/frame 0xfe046c8fe9d0 devfs_ioctl_f() at devfs_ioctl_f+0xfb/frame 0xfe046c8fea30 kern_ioctl() at kern_ioctl+0x22b/frame 0xfe046c8fea90 sys_ioctl() at sys_ioctl+0x13c/frame 0xfe046c8feae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe046c8febf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe046c8febf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8024d176a, rsp = 0x7fffe818, rbp = 0x7fffe840 --- -- pozdrawiam / with regards Paweł Pękala ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: why is CURRENT swapping so fast?
On Sat, Jun 14, 2014 at 01:12:08AM +0200 I heard the voice of Mark Martinec, and lo! it spake thus: The situation does not improve by itself, ARC has it all, less active jobs scramble and fight for whatever free memory is left for them and most of them remain swapped out. The best curse of action to recover is to reboot. Quite a pain. You may want to check out https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 which I believe is related. Make sure you get the latest patch rather than the older one, ref's in comment 10 at http://www.denninger.net/FreeBSD-Patches/arc-patch. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
SMBus controller
I note that my TLenovo 61 has one of these: ichsmb0@pci0:0:31:3:class=0x0c0500 card=0x20a917aa chip=0x283e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) SMBus Controller' class = serial bus subclass = SMBus I'm pretty ignorant here, and I had to manually load ichsmb(4) to get it detected. How can I see what's on here and what its purpose for existence might be. seaan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SMBus controller
Hi! I note that my TLenovo 61 has one of these: ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x20a917aa chip=0x283e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) SMBus Controller' class = serial bus subclass = SMBus I'm pretty ignorant here, and I had to manually load ichsmb(4) to get it detected. How can I see what's on here and what its purpose for existence might be. It's this: http://en.wikipedia.org/wiki/System_Management_Bus You can read some system status values (CPU temp etc). In the ports, check sysutils/xmbmon or sysutils/healthd whether it detects anything. -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SMBus controller
On Jun 14, 2014, at 12:08, Sean Bruno sbr...@ignoranthack.me wrote: I note that my TLenovo 61 has one of these: ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x20a917aa chip=0x283e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) SMBus Controller' class = serial bus subclass = SMBus I'm pretty ignorant here, and I had to manually load ichsmb(4) to get it detected. How can I see what's on here and what its purpose for existence might be. It's a System Management Bus. What you can do with it depends on what's connected to the bus and depends on what the manufacturer implemented. It's probably connected (indirectly) to the battery, to the voltage sensors, to the fans, etc. smbmsg(8) is used to communicate with the other devices on the bus, but I'm not sure if scanning devices will work. -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
In tree builds broken in lib/ncurses?
Long story short. I have laptop that is normally limited in available diskspace, so I do not install profiled libraries. I however have the need for running some code under the profiler (assuming clang can generate proper profiling). I do the following, % vi /etc/src.conf (Remove WITHOUT_PROFILE) % cd /usr/src % make clean % make cleandepend % cd lib % make depend % make The build dies in lib/ncurses with the following message. building shared library libncursesw.so.8 nm: 'codes.So': No such file nm: 'expanded.So': No such file nm: 'fallback.So': No such file nm: 'lib_gen.So': No such file ... cc: error: no such file or directory: 'termcap.So' cc: error: no such file or directory: 'visbuf.So' cc: error: no such file or directory: 'lib_trace.So' ... cc: error: no such file or directory: 'codes.So' *** Error code 1 Stop. make[1]: stopped in /usr/src/lib/ncurses/ncursesw *** Error code 1 Stop. make: stopped in /usr/src/lib/ncurses Amusingly, both libncurses.a and libncurses_p.a are built just fine. Is there any chance that in-tree builds will work as they once did? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SMBus controller
On Jun 14, 2014, at 12:39, Kurt Jaeger li...@opsec.eu wrote: In the ports, check sysutils/xmbmon or sysutils/healthd whether it detects anything. Ah, I didn't realise we had ports for this already. That's nice, thanks. -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In tree builds broken in lib/ncurses?
On Sat, Jun 14, 2014 at 01:19:33PM -0700, Steve Kargl wrote: Long story short. I have laptop that is normally limited in available diskspace, so I do not install profiled libraries. I however have the need for running some code under the profiler (assuming clang can generate proper profiling). I do the following, Is it possible to using profiling on FreeBSD-current? After installing libc_p.a, I try to build math/lapack. It dies with /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** Error code 1 Stop. make[3]: stopped in /usr/ports/math/lapack/work/lapack-3.4.2_PROFILE/INSTALL *** Error code 1 Stop. make[2]: stopped in /usr/ports/math/lapack/work/lapack-3.4.2_PROFILE *** Error code 1 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: building i386 kernel on amd64 host
On 6/13/14, John Baldwin j...@freebsd.org wrote: On Friday, June 13, 2014 6:21:28 am Oliver Pinter wrote: Hi All! When I try to build i386 kernel on amd64 host running compile error due wrong cpufunc.h picked up by build system. I used the attached script to build the kernel, and I attached a build log. Any suggestion how can I fix this? To build an i386 kernel on an amd64 host do this: cd /usr/src (or some other tree) make TARGET=i386 kernel-toolchain make TARGET=i386 buildkernel make TARGET=i386 installkernel DESTDIR=/some/place And your i386 kernel will end up in /some/place/boot/kernel/kernel. (You can set things like KERNCONF to pick an alternate kernel config just as with normal 'make buildkernel'.) (Your attachment was size zero for me btw) -- John Baldwin I used this script to build the kernel: http://svnweb.freebsd.org/socsvn/soc2014/op/tools/build_kernel_32bit.csh?view=log And the error log are there: https://gist.github.com/opntr/cf8aa0e404c0c5ed6f90 . I get this error, when I first build kernel for amd64 system, and after that i386 kernel, and only the kernel. Now seems like I can build the whole system with buildworld buildkernel on vanilla master, I removed the objdir and do a clean buildworld. Now I test the modified kernel build, after the buildworld. It is broken too. When I do only make kernel-toolchain buildkernel, than this are broken for vanilla freebsd source and for my version to. summary: OK: make buildworld buildkernel BROKEN: make kernel-toolchain buildkernel Seems like someone in build environment bootstrapping are broken. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In tree builds broken in lib/ncurses?
On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: On Sat, Jun 14, 2014 at 01:19:33PM -0700, Steve Kargl wrote: Long story short. I have laptop that is normally limited in available diskspace, so I do not install profiled libraries. I however have the need for running some code under the profiler (assuming clang can generate proper profiling). I do the following, Is it possible to using profiling on FreeBSD-current? After installing libc_p.a, I try to build math/lapack. It dies with /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** Error code 1 collect2? I think you've got something odd going on there.. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: In tree builds broken in lib/ncurses?
On Sat, Jun 14, 2014 at 03:01:20PM -0700, Peter Wemm wrote: On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: On Sat, Jun 14, 2014 at 01:19:33PM -0700, Steve Kargl wrote: Long story short. I have laptop that is normally limited in available diskspace, so I do not install profiled libraries. I however have the need for running some code under the profiler (assuming clang can generate proper profiling). I do the following, Is it possible to using profiling on FreeBSD-current? After installing libc_p.a, I try to build math/lapack. It dies with /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** Error code 1 collect2? I think you've got something odd going on there.. Maybe. math/lapack is built with gfortran, which is from lang/gcc47 on my system. lang/gcc47 is probably picking up the installed devel/binutils. This would explain the /usr/local/bin/ld instead of our /usr/bin/ld. libc_p.a is built with clang, so I'm probably running into yet-another clang vs gcc problem. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In tree builds broken in lib/ncurses?
On Sat, Jun 14, 2014 at 03:12:36PM -0700, Steve Kargl wrote: On Sat, Jun 14, 2014 at 03:01:20PM -0700, Peter Wemm wrote: On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: On Sat, Jun 14, 2014 at 01:19:33PM -0700, Steve Kargl wrote: Long story short. I have laptop that is normally limited in available diskspace, so I do not install profiled libraries. I however have the need for running some code under the profiler (assuming clang can generate proper profiling). I do the following, Is it possible to using profiling on FreeBSD-current? After installing libc_p.a, I try to build math/lapack. It dies with /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** Error code 1 collect2? I think you've got something odd going on there.. Maybe. math/lapack is built with gfortran, which is from lang/gcc47 on my system. lang/gcc47 is probably picking up the installed devel/binutils. This would explain the /usr/local/bin/ld instead of our /usr/bin/ld. libc_p.a is built with clang, so I'm probably running into yet-another clang vs gcc problem. Where is the symbol _end suppose to come from? Script started on Sat Jun 14 15:26:08 2014 laptop-kargl:kargl[201] foreach i (/usr/lib/*.a) foreach? echo $i foreach? nm $i | grep 'U _end' foreach? nm $i | grep 'T _end' foreach? end /usr/lib/libc.a U _end U _endnetdnsent U _endnethtent U _endhostdnsent U _endhosthtent 0050 T _endnethtent 0ac0 T _endnetdnsent 0050 T _endhosthtent 1220 T _endhostdnsent /usr/lib/libc_p.a U _end U _endnetdnsent U _endnethtent U _endhostdnsent U _endhosthtent 0050 T _endnethtent 0b00 T _endnetdnsent 0050 T _endhosthtent 12e0 T _endhostdnsent /usr/lib/libc_pic.a U _endhostdnsent U _endhosthtent U _endnetdnsent U _endnethtent U _end 1470 T _endhostdnsent 0060 T _endhosthtent 0ba0 T _endnetdnsent 0060 T _endnethtent Script done on Sat Jun 14 15:27:01 2014 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In tree builds broken in lib/ncurses?
On Saturday 14 June 2014 15:30:02 Steve Kargl wrote: On Sat, Jun 14, 2014 at 03:12:36PM -0700, Steve Kargl wrote: On Sat, Jun 14, 2014 at 03:01:20PM -0700, Peter Wemm wrote: On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: On Sat, Jun 14, 2014 at 01:19:33PM -0700, Steve Kargl wrote: Long story short. I have laptop that is normally limited in available diskspace, so I do not install profiled libraries. I however have the need for running some code under the profiler (assuming clang can generate proper profiling). I do the following, Is it possible to using profiling on FreeBSD-current? After installing libc_p.a, I try to build math/lapack. It dies with /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** Error code 1 collect2? I think you've got something odd going on there.. Maybe. math/lapack is built with gfortran, which is from lang/gcc47 on my system. lang/gcc47 is probably picking up the installed devel/binutils. This would explain the /usr/local/bin/ld instead of our /usr/bin/ld. libc_p.a is built with clang, so I'm probably running into yet-another clang vs gcc problem. Where is the symbol _end suppose to come from? Script started on Sat Jun 14 15:26:08 2014 laptop-kargl:kargl[201] foreach i (/usr/lib/*.a) foreach? echo $i foreach? nm $i | grep 'U _end' foreach? nm $i | grep 'T _end' foreach? end /usr/lib/libc.a U _end _end is a dynamic symbol that is synthesized by ld or linker scripts. Normally that would be /usr/bin/ld peter@hub[10:35pm]~-110 grep _end /usr/libdata/ldscripts/elf_x86_64_fbsd.x ... _end. Align after .bss to ensure correct alignment even if the _end = .; PROVIDE (end = .); It used to be built into the a.out linker, but it's in the built-in linker scripts since the ELF switch. Your problem isn't clang vs gcc or libc_p, it's /usr/local/bin/ld or a linker script the gfortran stuff is using. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: SMBus controller
On Sat, 2014-06-14 at 12:08 -0700, Sean Bruno wrote: I note that my TLenovo 61 has one of these: ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x20a917aa chip=0x283e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) SMBus Controller' class = serial bus subclass = SMBus So, there's something broken in the initialization of the driver and the driver dependencies here. If I load smb.ko by itself, no other modules are loaded (ichsmb, smbus). Should it? If I load ichsmb, smbus is loaded, so that's good. But, the first time I do this, the driver seems to think I have 16 bus instances: iicsmb0: SMBus over I2C bridge on iicbus0 iicsmb1: SMBus over I2C bridge on iicbus1 iicsmb2: SMBus over I2C bridge on iicbus2 iicsmb3: SMBus over I2C bridge on iicbus3 iicsmb4: SMBus over I2C bridge on iicbus4 iicsmb5: SMBus over I2C bridge on iicbus5 iicsmb6: SMBus over I2C bridge on iicbus6 iicsmb7: SMBus over I2C bridge on iicbus7 iicsmb8: SMBus over I2C bridge on iicbus8 iicsmb9: SMBus over I2C bridge on iicbus9 iicsmb10: SMBus over I2C bridge on iicbus10 iicsmb11: SMBus over I2C bridge on iicbus11 iicsmb12: SMBus over I2C bridge on iicbus12 iicsmb13: SMBus over I2C bridge on iicbus13 iicsmb14: SMBus over I2C bridge on iicbus14 iicsmb15: SMBus over I2C bridge on iicbus15 smbus0: System Management Bus on iicsmb0 smbus1: System Management Bus on iicsmb1 smbus2: System Management Bus on iicsmb2 smbus3: System Management Bus on iicsmb3 smbus4: System Management Bus on iicsmb4 smbus5: System Management Bus on iicsmb5 smbus6: System Management Bus on iicsmb6 smbus7: System Management Bus on iicsmb7 smbus8: System Management Bus on iicsmb8 smbus9: System Management Bus on iicsmb9 smbus10: System Management Bus on iicsmb10 smbus11: System Management Bus on iicsmb11 smbus12: System Management Bus on iicsmb12 smbus13: System Management Bus on iicsmb13 smbus14: System Management Bus on iicsmb14 smbus15: System Management Bus on iicsmb15 I then load smb.ko and I get no useful output from smbmsg -p. If I try to acces /dev/smb1, ctrl-c it, unload all modules and then reload them, I get completely different (and functional) behavior. I only get ONE smbus and I can poll devices there, even though I have no idea what they are. ichsmb0: Intel 82801H (ICH8) SMBus controller port 0x1c60-0x1c7f mem 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0 smbus0: System Management Bus on ichsmb0 smb0: SMBus generic I/O on smbus0 root@bruno:/home/sbruno # smbmsg -p Probing for devices on /dev/smb0: Device @0x10: w Device @0x88: rw Device @0xa8: w Device @0xaa: rw Device @0xac: rw Device @0xae: rw Device @0xb8: rw Device @0xc2: w Device @0xc8: w Right ... so, I did the following: kldload ichsmb This seems to know to bull in smbus.ko. ichsmb0: Intel 82801H (ICH8) SMBus controller port 0x1c60-0x1c7f mem 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0 smbus0: System Management Bus on ichsmb0 This doesn't really do anything useful, until I load smb.ko: ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: why is CURRENT swapping so fast?
me wrote: Is this also fixed in the 10.0-STABLE by now? The situation does not improve by itself, ARC has it all, less active jobs scramble and fight for whatever free memory is left for them and most of them remain swapped out. The best curse of action to recover is to reboot. Quite a pain. On 2014-06-14 17:29, Matthew D. Fuller wrote: You may want to check out https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 which I believe is related. Make sure you get the latest patch rather than the older one, ref's in comment 10 at http://www.denninger.net/FreeBSD-Patches/arc-patch. Great, thank you, will apply it in the coming days. One would hope that such a serious pathological behaviour (in 10-STABLE and 11) would get the patch applied by now (patch available for two months now, problem described in March), or the former logic reverted. Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SMBus controller
On Jun 14, 2014, at 4:43 PM, Sean Bruno sbr...@ignoranthack.me wrote: On Sat, 2014-06-14 at 12:08 -0700, Sean Bruno wrote: I note that my TLenovo 61 has one of these: ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x20a917aa chip=0x283e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) SMBus Controller' class = serial bus subclass = SMBus So, there's something broken in the initialization of the driver and the driver dependencies here. If I load smb.ko by itself, no other modules are loaded (ichsmb, smbus). Should it? I don’t think so. If I kldload pci, would you expect most of the drivers in the system to be loaded? If I load ichsmb, smbus is loaded, so that's good. But, the first time I do this, the driver seems to think I have 16 bus instances: iicsmb0: SMBus over I2C bridge on iicbus0 iicsmb1: SMBus over I2C bridge on iicbus1 iicsmb2: SMBus over I2C bridge on iicbus2 iicsmb3: SMBus over I2C bridge on iicbus3 iicsmb4: SMBus over I2C bridge on iicbus4 iicsmb5: SMBus over I2C bridge on iicbus5 iicsmb6: SMBus over I2C bridge on iicbus6 iicsmb7: SMBus over I2C bridge on iicbus7 iicsmb8: SMBus over I2C bridge on iicbus8 iicsmb9: SMBus over I2C bridge on iicbus9 iicsmb10: SMBus over I2C bridge on iicbus10 iicsmb11: SMBus over I2C bridge on iicbus11 iicsmb12: SMBus over I2C bridge on iicbus12 iicsmb13: SMBus over I2C bridge on iicbus13 iicsmb14: SMBus over I2C bridge on iicbus14 iicsmb15: SMBus over I2C bridge on iicbus15 smbus0: System Management Bus on iicsmb0 smbus1: System Management Bus on iicsmb1 smbus2: System Management Bus on iicsmb2 smbus3: System Management Bus on iicsmb3 smbus4: System Management Bus on iicsmb4 smbus5: System Management Bus on iicsmb5 smbus6: System Management Bus on iicsmb6 smbus7: System Management Bus on iicsmb7 smbus8: System Management Bus on iicsmb8 smbus9: System Management Bus on iicsmb9 smbus10: System Management Bus on iicsmb10 smbus11: System Management Bus on iicsmb11 smbus12: System Management Bus on iicsmb12 smbus13: System Management Bus on iicsmb13 smbus14: System Management Bus on iicsmb14 smbus15: System Management Bus on iicsmb15 I then load smb.ko and I get no useful output from smbmsg -p. If I try to acces /dev/smb1, ctrl-c it, unload all modules and then reload them, I get completely different (and functional) behavior. I only get ONE smbus and I can poll devices there, even though I have no idea what they are. ichsmb0: Intel 82801H (ICH8) SMBus controller port 0x1c60-0x1c7f mem 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0 smbus0: System Management Bus on ichsmb0 smb0: SMBus generic I/O on smbus0 root@bruno:/home/sbruno # smbmsg -p Probing for devices on /dev/smb0: Device @0x10: w Device @0x88: rw Device @0xa8: w Device @0xaa: rw Device @0xac: rw Device @0xae: rw Device @0xb8: rw Device @0xc2: w Device @0xc8: w Right ... so, I did the following: kldload ichsmb This seems to know to bull in smbus.ko. I kinda think that’s a bug. Makes it impossible to load/unload smbus independent of ichsmb. pccard had that issue, but I fixed it eons ago. However, it might be a necessary at the moment bug due to symbols being exported from smbus.ko that are needed btt ichsmb… ichsmb0: Intel 82801H (ICH8) SMBus controller port 0x1c60-0x1c7f mem 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0 smbus0: System Management Bus on ichsmb0 This doesn't really do anything useful, until I load smb.ko”: That makes sense to me. Again, each of these things is independent, or should be. It sounds like there’s other breakage going on. You might want to see what putting it in your kernel tells you. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: building i386 kernel on amd64 host
On Jun 14, 2014, at 3:57 PM, Oliver Pinter oliver.p...@gmail.com wrote: On 6/13/14, John Baldwin j...@freebsd.org wrote: On Friday, June 13, 2014 6:21:28 am Oliver Pinter wrote: Hi All! When I try to build i386 kernel on amd64 host running compile error due wrong cpufunc.h picked up by build system. I used the attached script to build the kernel, and I attached a build log. Any suggestion how can I fix this? To build an i386 kernel on an amd64 host do this: cd /usr/src (or some other tree) make TARGET=i386 kernel-toolchain make TARGET=i386 buildkernel make TARGET=i386 installkernel DESTDIR=/some/place And your i386 kernel will end up in /some/place/boot/kernel/kernel. (You can set things like KERNCONF to pick an alternate kernel config just as with normal 'make buildkernel'.) (Your attachment was size zero for me btw) -- John Baldwin I used this script to build the kernel: http://svnweb.freebsd.org/socsvn/soc2014/op/tools/build_kernel_32bit.csh?view=log And the error log are there: https://gist.github.com/opntr/cf8aa0e404c0c5ed6f90 . I get this error, when I first build kernel for amd64 system, and after that i386 kernel, and only the kernel. Now seems like I can build the whole system with buildworld buildkernel on vanilla master, I removed the objdir and do a clean buildworld. Now I test the modified kernel build, after the buildworld. It is broken too. When I do only make kernel-toolchain buildkernel, than this are broken for vanilla freebsd source and for my version to. summary: OK: make buildworld buildkernel BROKEN: make kernel-toolchain buildkernel On the same line? O?r is that just a summary? Seems like someone in build environment bootstrapping are broken. I’ve not been able to reproduce this. rm -rf $OBJDIR make TARGET=i386 kernel-toolchain make TARGET=i386 buildkernel works just fine on current with a clean tree and an empty/missing make.conf and src.conf. As for your script, don’t define MACHINE and MACHINE_ARCH. That’s almost always wrong since that overrides things on the command line, which is what make buildkernel winds up translating to. You never need to define those yourself in any supported environment, and likely most unsupported ones. Also, I’d strongly recommend doing it as two invocations to make, not one. kernel-toolchain likely doesn’t have all the right guards in place for it that buildworld likely does. Or you can dive in and figure that out. You can’t really do anything *kernel* related until kernel-toolchain finishes… Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SMBus controller
On Sat, 2014-06-14 at 17:25 -0600, Warner Losh wrote: On Jun 14, 2014, at 4:43 PM, Sean Bruno sbr...@ignoranthack.me wrote: On Sat, 2014-06-14 at 12:08 -0700, Sean Bruno wrote: I note that my TLenovo 61 has one of these: ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x20a917aa chip=0x283e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) SMBus Controller' class = serial bus subclass = SMBus So, there's something broken in the initialization of the driver and the driver dependencies here. If I load smb.ko by itself, no other modules are loaded (ichsmb, smbus). Should it? I don’t think so. If I kldload pci, would you expect most of the drivers in the system to be loaded? Heck if I know. :-) I would suspect that of the three, ichsmb, smbus or smb, one of these should cause the other two to be loaded. This is not the case. If I load ichsmb, smbus is loaded, so that's good. But, the first time I do this, the driver seems to think I have 16 bus instances: iicsmb0: SMBus over I2C bridge on iicbus0 iicsmb1: SMBus over I2C bridge on iicbus1 iicsmb2: SMBus over I2C bridge on iicbus2 iicsmb3: SMBus over I2C bridge on iicbus3 iicsmb4: SMBus over I2C bridge on iicbus4 iicsmb5: SMBus over I2C bridge on iicbus5 iicsmb6: SMBus over I2C bridge on iicbus6 iicsmb7: SMBus over I2C bridge on iicbus7 iicsmb8: SMBus over I2C bridge on iicbus8 iicsmb9: SMBus over I2C bridge on iicbus9 iicsmb10: SMBus over I2C bridge on iicbus10 iicsmb11: SMBus over I2C bridge on iicbus11 iicsmb12: SMBus over I2C bridge on iicbus12 iicsmb13: SMBus over I2C bridge on iicbus13 iicsmb14: SMBus over I2C bridge on iicbus14 iicsmb15: SMBus over I2C bridge on iicbus15 smbus0: System Management Bus on iicsmb0 smbus1: System Management Bus on iicsmb1 smbus2: System Management Bus on iicsmb2 smbus3: System Management Bus on iicsmb3 smbus4: System Management Bus on iicsmb4 smbus5: System Management Bus on iicsmb5 smbus6: System Management Bus on iicsmb6 smbus7: System Management Bus on iicsmb7 smbus8: System Management Bus on iicsmb8 smbus9: System Management Bus on iicsmb9 smbus10: System Management Bus on iicsmb10 smbus11: System Management Bus on iicsmb11 smbus12: System Management Bus on iicsmb12 smbus13: System Management Bus on iicsmb13 smbus14: System Management Bus on iicsmb14 smbus15: System Management Bus on iicsmb15 I then load smb.ko and I get no useful output from smbmsg -p. If I try to acces /dev/smb1, ctrl-c it, unload all modules and then reload them, I get completely different (and functional) behavior. I only get ONE smbus and I can poll devices there, even though I have no idea what they are. ichsmb0: Intel 82801H (ICH8) SMBus controller port 0x1c60-0x1c7f mem 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0 smbus0: System Management Bus on ichsmb0 smb0: SMBus generic I/O on smbus0 root@bruno:/home/sbruno # smbmsg -p Probing for devices on /dev/smb0: Device @0x10: w Device @0x88: rw Device @0xa8: w Device @0xaa: rw Device @0xac: rw Device @0xae: rw Device @0xb8: rw Device @0xc2: w Device @0xc8: w Right ... so, I did the following: kldload ichsmb This seems to know to bull in smbus.ko. I kinda think that’s a bug. Makes it impossible to load/unload smbus independent of ichsmb. pccard had that issue, but I fixed it eons ago. However, it might be a necessary at the moment bug due to symbols being exported from smbus.ko that are needed btt ichsmb… ichsmb0: Intel 82801H (ICH8) SMBus controller port 0x1c60-0x1c7f mem 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0 smbus0: System Management Bus on ichsmb0 This doesn't really do anything useful, until I load smb.ko”: That makes sense to me. Again, each of these things is independent, or should be. It sounds like there’s other breakage going on. You might want to see what putting it in your kernel tells you. Warner Does it make sense that 16 devices are detected until I attempt to access a non existent one, reload the modules and then it seems to work correctly? It looks like something in initialization is hosed. sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In tree builds broken in lib/ncurses?
On Sat, Jun 14, 2014 at 03:38:58PM -0700, Peter Wemm wrote: On Saturday 14 June 2014 15:30:02 Steve Kargl wrote: On Sat, Jun 14, 2014 at 03:12:36PM -0700, Steve Kargl wrote: On Sat, Jun 14, 2014 at 03:01:20PM -0700, Peter Wemm wrote: On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: Is it possible to using profiling on FreeBSD-current? After installing libc_p.a, I try to build math/lapack. It dies with /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** Error code 1 collect2? I think you've got something odd going on there.. Maybe. math/lapack is built with gfortran, which is from lang/gcc47 on my system. lang/gcc47 is probably picking up the installed devel/binutils. This would explain the /usr/local/bin/ld instead of our /usr/bin/ld. libc_p.a is built with clang, so I'm probably running into yet-another clang vs gcc problem. Where is the symbol _end suppose to come from? Script started on Sat Jun 14 15:26:08 2014 laptop-kargl:kargl[201] foreach i (/usr/lib/*.a) foreach? echo $i foreach? nm $i | grep 'U _end' foreach? nm $i | grep 'T _end' foreach? end /usr/lib/libc.a U _end _end is a dynamic symbol that is synthesized by ld or linker scripts. Normally that would be /usr/bin/ld peter@hub[10:35pm]~-110 grep _end /usr/libdata/ldscripts/elf_x86_64_fbsd.x ... _end. Align after .bss to ensure correct alignment even if the _end = .; PROVIDE (end = .); It used to be built into the a.out linker, but it's in the built-in linker scripts since the ELF switch. Your problem isn't clang vs gcc or libc_p, it's /usr/local/bin/ld or a linker script the gfortran stuff is using. Thanks for the pointer. The problem appears to be /usr/local/bin/ld. If I move it to ld.old and then symlink /usr/local/bin/ld to /usr/bin/ld, I can build math/lapack without a problem. I guess I'll poke around in devel/bintuils. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In tree builds broken in lib/ncurses?
On Jun 14, 2014, at 7:30 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Jun 14, 2014 at 03:38:58PM -0700, Peter Wemm wrote: On Saturday 14 June 2014 15:30:02 Steve Kargl wrote: On Sat, Jun 14, 2014 at 03:12:36PM -0700, Steve Kargl wrote: On Sat, Jun 14, 2014 at 03:01:20PM -0700, Peter Wemm wrote: On Saturday 14 June 2014 14:44:39 Steve Kargl wrote: Is it possible to using profiling on FreeBSD-current? After installing libc_p.a, I try to build math/lapack. It dies with /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status *** Error code 1 collect2? I think you've got something odd going on there.. Maybe. math/lapack is built with gfortran, which is from lang/gcc47 on my system. lang/gcc47 is probably picking up the installed devel/binutils. This would explain the /usr/local/bin/ld instead of our /usr/bin/ld. libc_p.a is built with clang, so I'm probably running into yet-another clang vs gcc problem. Where is the symbol _end suppose to come from? Script started on Sat Jun 14 15:26:08 2014 laptop-kargl:kargl[201] foreach i (/usr/lib/*.a) foreach? echo $i foreach? nm $i | grep 'U _end' foreach? nm $i | grep 'T _end' foreach? end /usr/lib/libc.a U _end _end is a dynamic symbol that is synthesized by ld or linker scripts. Normally that would be /usr/bin/ld peter@hub[10:35pm]~-110 grep _end /usr/libdata/ldscripts/elf_x86_64_fbsd.x ... _end. Align after .bss to ensure correct alignment even if the _end = .; PROVIDE (end = .); It used to be built into the a.out linker, but it's in the built-in linker scripts since the ELF switch. Your problem isn't clang vs gcc or libc_p, it's /usr/local/bin/ld or a linker script the gfortran stuff is using. Thanks for the pointer. The problem appears to be /usr/local/bin/ld. If I move it to ld.old and then symlink /usr/local/bin/ld to /usr/bin/ld, I can build math/lapack without a problem. I guess I'll poke around in devel/bintuils. We don’t support building the tree with any ld but the one in the tree. However, having said that, if you can fix it, that would be awesome. I’d like to see our support expand to include latter-day versions of binutils on all platforms to help with the eventual demise of in-tree gcc... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SMBus controller
On Jun 14, 2014, at 5:48 PM, Sean Bruno sbr...@ignoranthack.me wrote: On Sat, 2014-06-14 at 17:25 -0600, Warner Losh wrote: On Jun 14, 2014, at 4:43 PM, Sean Bruno sbr...@ignoranthack.me wrote: On Sat, 2014-06-14 at 12:08 -0700, Sean Bruno wrote: I note that my TLenovo 61 has one of these: ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x20a917aa chip=0x283e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) SMBus Controller' class = serial bus subclass = SMBus So, there's something broken in the initialization of the driver and the driver dependencies here. If I load smb.ko by itself, no other modules are loaded (ichsmb, smbus). Should it? I don’t think so. If I kldload pci, would you expect most of the drivers in the system to be loaded? Heck if I know. :-) I would suspect that of the three, ichsmb, smbus or smb, one of these should cause the other two to be loaded. This is not the case. If I load ichsmb, smbus is loaded, so that's good. But, the first time I do this, the driver seems to think I have 16 bus instances: iicsmb0: SMBus over I2C bridge on iicbus0 iicsmb1: SMBus over I2C bridge on iicbus1 iicsmb2: SMBus over I2C bridge on iicbus2 iicsmb3: SMBus over I2C bridge on iicbus3 iicsmb4: SMBus over I2C bridge on iicbus4 iicsmb5: SMBus over I2C bridge on iicbus5 iicsmb6: SMBus over I2C bridge on iicbus6 iicsmb7: SMBus over I2C bridge on iicbus7 iicsmb8: SMBus over I2C bridge on iicbus8 iicsmb9: SMBus over I2C bridge on iicbus9 iicsmb10: SMBus over I2C bridge on iicbus10 iicsmb11: SMBus over I2C bridge on iicbus11 iicsmb12: SMBus over I2C bridge on iicbus12 iicsmb13: SMBus over I2C bridge on iicbus13 iicsmb14: SMBus over I2C bridge on iicbus14 iicsmb15: SMBus over I2C bridge on iicbus15 smbus0: System Management Bus on iicsmb0 smbus1: System Management Bus on iicsmb1 smbus2: System Management Bus on iicsmb2 smbus3: System Management Bus on iicsmb3 smbus4: System Management Bus on iicsmb4 smbus5: System Management Bus on iicsmb5 smbus6: System Management Bus on iicsmb6 smbus7: System Management Bus on iicsmb7 smbus8: System Management Bus on iicsmb8 smbus9: System Management Bus on iicsmb9 smbus10: System Management Bus on iicsmb10 smbus11: System Management Bus on iicsmb11 smbus12: System Management Bus on iicsmb12 smbus13: System Management Bus on iicsmb13 smbus14: System Management Bus on iicsmb14 smbus15: System Management Bus on iicsmb15 I then load smb.ko and I get no useful output from smbmsg -p. If I try to acces /dev/smb1, ctrl-c it, unload all modules and then reload them, I get completely different (and functional) behavior. I only get ONE smbus and I can poll devices there, even though I have no idea what they are. ichsmb0: Intel 82801H (ICH8) SMBus controller port 0x1c60-0x1c7f mem 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0 smbus0: System Management Bus on ichsmb0 smb0: SMBus generic I/O on smbus0 root@bruno:/home/sbruno # smbmsg -p Probing for devices on /dev/smb0: Device @0x10: w Device @0x88: rw Device @0xa8: w Device @0xaa: rw Device @0xac: rw Device @0xae: rw Device @0xb8: rw Device @0xc2: w Device @0xc8: w Right ... so, I did the following: kldload ichsmb This seems to know to bull in smbus.ko. I kinda think that’s a bug. Makes it impossible to load/unload smbus independent of ichsmb. pccard had that issue, but I fixed it eons ago. However, it might be a necessary at the moment bug due to symbols being exported from smbus.ko that are needed btt ichsmb… ichsmb0: Intel 82801H (ICH8) SMBus controller port 0x1c60-0x1c7f mem 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0 smbus0: System Management Bus on ichsmb0 This doesn't really do anything useful, until I load smb.ko”: That makes sense to me. Again, each of these things is independent, or should be. It sounds like there’s other breakage going on. You might want to see what putting it in your kernel tells you. Warner Does it make sense that 16 devices are detected until I attempt to access a non existent one, reload the modules and then it seems to work correctly? It looks like something in initialization is hosed. It does look hosed. I think that the code may assume bios interference that we need to do if we get a nonsensical result. But that’s pure speculation on my part… Warner signature.asc Description: Message signed with OpenPGP using GPGMail
What we have here, ...
Is a failure to build head/ with high make(1) -j values. Again. With empty /usr/obj, I have been seeing strange build failures on head/ with high -jN values, but even as low as -j10. The machine used to build snapshots of head/ and stable/ branches has been using -j48 for several months without issue, so I am certain this is a recent (=1 month) issue. Of all things, it looks like fonts are failing to build, giving the following error: --- MACGUJARATI.esdb --- NAME is mandatory. ENCODING is mandatory. *** [MACGUJARATI.esdb] Error code 1 make[6]: stopped in /usr/src/share/i18n/esdb/APPLE Is anyone else seeing this with empty MAKEOBJDIR ? I won't be able to reproduce the issue with log output until at least Monday, since I'm running the head/ builds with the '-jN' halved to 24, which so far seems to have made a difference. Thanks. Glen pgpwOhnRdmRHC.pgp Description: PGP signature
Re: What we have here, ...
On Jun 14, 2014, at 8:51 PM, Glen Barber g...@freebsd.org wrote: Is a failure to build head/ with high make(1) -j values. Again. There’s likely a dozen or more of these lurking in the tree. Ian’s last set of patches squashed many of the ones in lib, but I’ve not done a careful audit of the i18n code. With empty /usr/obj, I have been seeing strange build failures on head/ with high -jN values, but even as low as -j10. The machine used to build snapshots of head/ and stable/ branches has been using -j48 for several months without issue, so I am certain this is a recent (=1 month) issue. Of all things, it looks like fonts are failing to build, giving the following error: --- MACGUJARATI.esdb --- NAME is mandatory. ENCODING is mandatory. *** [MACGUJARATI.esdb] Error code 1 make[6]: stopped in /usr/src/share/i18n/esdb/APPLE Is anyone else seeing this with empty MAKEOBJDIR ? I haven’t seen it, but in -j races, that means approximately zilch… I won't be able to reproduce the issue with log output until at least Monday, since I'm running the head/ builds with the '-jN' halved to 24, which so far seems to have made a difference. How many cores in this box of yours? Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What we have here, ...
On Sat, Jun 14, 2014 at 09:03:51PM -0600, Warner Losh wrote: On Jun 14, 2014, at 8:51 PM, Glen Barber g...@freebsd.org wrote: Is a failure to build head/ with high make(1) -j values. Again. There’s likely a dozen or more of these lurking in the tree. Ian’s last set of patches squashed many of the ones in lib, but I’ve not done a careful audit of the i18n code. Ok, thanks for the info. I'm a bit unclear on how the parallelization stuff in share/ actually works, but I'm happy to help crowbar at things. With empty /usr/obj, I have been seeing strange build failures on head/ with high -jN values, but even as low as -j10. The machine used to build snapshots of head/ and stable/ branches has been using -j48 for several months without issue, so I am certain this is a recent (=1 month) issue. Of all things, it looks like fonts are failing to build, giving the following error: --- MACGUJARATI.esdb --- NAME is mandatory. ENCODING is mandatory. *** [MACGUJARATI.esdb] Error code 1 make[6]: stopped in /usr/src/share/i18n/esdb/APPLE Is anyone else seeing this with empty MAKEOBJDIR ? I haven’t seen it, but in -j races, that means approximately zilch… Yeah. To be honest, it's the similar situation I emailed you privately about a few weeks ago with the race in rescue/ that makes no sense. So while I don't entirely trust make(1) reporting what blew up, unlike the issue in rescue/, the 'NAME is mandatory' error has been about 90% reproducible between both amd64 and i386. (Without being able to build at least amd64, I cannot test other architectures. Useless data point, I know.) I won't be able to reproduce the issue with log output until at least Monday, since I'm running the head/ builds with the '-jN' halved to 24, which so far seems to have made a difference. How many cores in this box of yours? 48. Glen pgpy596uAW0sQ.pgp Description: PGP signature
Re: In tree builds broken in lib/ncurses?
On Sat, Jun 14, 2014 at 9:30 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: Thanks for the pointer. The problem appears to be /usr/local/bin/ld. If I move it to ld.old and then symlink /usr/local/bin/ld to /usr/bin/ld, I can build math/lapack without a problem. I guess I'll poke around in devel/bintuils. I would see what changes have been made to the linker scripts that ld is using for FreeBSD. Several years ago I ran into a problem when building kld modules with an out-of-tree toolchain and the root cause ended up being that the linker scripts were broken and no longer provided a necessary symbol. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
