lock order reversals with netmap
Hi, on FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 13:56:02 CET 2011 (GENERIC + CAPABILITIES + netmap with head.diff and bge patches applied) I get these lock order reversals when running a netmap-enabled program (details in the attachment) with syscall (54, FreeBSD ELF64, sys_ioctl): Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory allocator lock (netmap memory allocator lock) r = 0 (0xfe00027d1880) locked @ /usr/src/sys/dev/netmap/netmap.c:1484 Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) r = 0 (0xff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 The application does not invoke the offending function (netmap_malloc()) itself. Regards, René -- http://www.rene-ladan.nl:8080/ GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC (subkeys.pgp.net) Dec 1 15:41:20 acer kernel: FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 13:56:02 CET 2011 Dec 1 15:41:20 acer kernel: real memory = 4294967296 (4096 MB) Dec 1 15:41:20 acer kernel: avail memory = 4080091136 (3891 MB) Dec 1 15:41:20 acer kernel: 001.05 netmap_memory_init [1627] netmap_buffer_base 0xff8117eaa000 (offset 679936) Dec 1 15:41:20 acer kernel: 001.06 netmap_memory_init [1636] Have 129 MB, use 661KB for rings, 65862 buffers at 0xff8117eaa000 Dec 1 15:41:20 acer kernel: netmap: loaded module with 129 Mbytes Dec 1 15:41:20 acer kernel: bge0: Broadcom NetLink Gigabit Ethernet Controller, ASIC rev. 0x5784100 mem 0xf510-0xf510 irq 16 at device 0.0 on pci2 Dec 1 15:41:20 acer kernel: bge0: CHIP ID 0x05784100; ASIC REV 0x5784; CHIP REV 0x57841; PCI-E Dec 1 15:41:20 acer kernel: miibus0: MII bus on bge0 Dec 1 15:41:20 acer kernel: brgphy0: BCM5784 10/100/1000baseT PHY PHY 1 on miibus0 Dec 1 15:41:20 acer kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Dec 1 15:41:20 acer kernel: bge0: Ethernet address: 00:26:2d:5e:d8:ee Dec 1 15:41:20 acer kernel: 001.09 netmap_attach [1243] ok for bge0 Dec 1 16:23:09 acer kernel: 989.882634 netmap_set_ringid [779] ringid bge0 set to SW RING Dec 1 16:23:09 acer kernel: uma_zalloc_arg: zone 64 with the following non-sleepable locks held: Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory allocator lock (netmap memory allocator lock) r = 0 (0xfe00027d1880) locked @ /usr/src/sys/dev/netmap/netmap.c:1484 Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) r = 0 (0xff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 Dec 1 16:23:09 acer kernel: KDB: stack backtrace: Dec 1 16:23:09 acer kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 1 16:23:10 acer kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 1 16:23:10 acer kernel: _witness_debugger() at _witness_debugger+0x2c Dec 1 16:23:10 acer kernel: witness_warn() at witness_warn+0x2c2 Dec 1 16:23:10 acer kernel: uma_zalloc_arg() at uma_zalloc_arg+0x335 Dec 1 16:23:10 acer kernel: malloc() at malloc+0xbe Dec 1 16:23:10 acer kernel: netmap_malloc() at netmap_malloc+0x86 Dec 1 16:23:10 acer kernel: netmap_ioctl() at netmap_ioctl+0x5bd Dec 1 16:23:10 acer kernel: devfs_ioctl_f() at devfs_ioctl_f+0x7a Dec 1 16:23:10 acer kernel: kern_ioctl() at kern_ioctl+0xcd Dec 1 16:23:10 acer kernel: sys_ioctl() at sys_ioctl+0xfd Dec 1 16:23:10 acer kernel: amd64_syscall() at amd64_syscall+0x3ac Dec 1 16:23:10 acer kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 1 16:23:10 acer kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8022aef0c, rsp = 0x7fffd4b8, rbp = 0x802bfb100 --- Dec 1 16:23:10 acer kernel: uma_zalloc_arg: zone 64 with the following non-sleepable locks held: Dec 1 16:23:10 acer kernel: exclusive sleep mutex netmap memory allocator lock (netmap memory allocator lock) r = 0 (0xfe00027d1880) locked @ /usr/src/sys/dev/netmap/netmap.c:1484 Dec 1 16:23:10 acer kernel: exclusive sleep mutex bge0 (network driver) r = 0 (0xff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 Dec 1 16:23:10 acer kernel: KDB: stack backtrace: Dec 1 16:23:10 acer kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 1 16:23:10 acer kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 1 16:23:10 acer kernel: _witness_debugger() at _witness_debugger+0x2c Dec 1 16:23:10 acer kernel: witness_warn() at witness_warn+0x2c2 Dec 1 16:23:10 acer kernel: uma_zalloc_arg() at uma_zalloc_arg+0x335 Dec 1 16:23:10 acer kernel: malloc() at malloc+0xbe Dec 1 16:23:10 acer kernel: netmap_malloc() at netmap_malloc+0x86 Dec 1 16:23:10 acer kernel: netmap_ioctl() at netmap_ioctl+0x817 Dec 1 16:23:10 acer kernel: devfs_ioctl_f() at devfs_ioctl_f+0x7a Dec 1 16:23:10 acer kernel: kern_ioctl() at kern_ioctl+0xcd Dec 1 16:23:10 acer kernel: sys_ioctl() at sys_ioctl+0xfd Dec 1 16:23:10 acer kernel: amd64_syscall() at amd64_syscall+0x3ac Dec 1
iwn panic with 9.0-BETA3-amd64
Hi, just experienced a panic with if_iwn on 9.0-BETA3-amd64 (base and kernel compiled with clang, CPUTYPE?=core2, GENERIC with CAPABILITIES). My network card: iwn0: Intel(R) WiFi Link 5100 mem 0xf520-0xf5201fff irq 17 at device 0.0 on pci3 iwn0: flags=8803UP,BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:26:c6:xx:xx:xx nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect mode 11b status: associated Some snippets from /var/crash/core.txt.24 : Unread portion of the kernel message buffer: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex iwn0 (network driver) r = 0 (0xff8000882018) locked @ /usr/src/9/sys/dev/iwn/if_iwn.c:3135 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b kdb_backtrace() at kdb_backtrace+0x39 witness_warn() at witness_warn+0x438 trap() at trap+0x14c calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x804fd1c7, rsp = 0xff811850a9d0, rbp = 0xff811850aa30 --- iwn_ampdu_tx_done() at iwn_ampdu_tx_done+0xa7 iwn_notif_intr() at iwn_notif_intr+0x523 iwn_intr() at iwn_intr+0x60c intr_event_execute_handlers() at intr_event_execute_handlers+0x7e ithread_loop() at ithread_loop+0xf0 fork_exit() at fork_exit+0x80 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff811850ad00, rbp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xa fault code = supervisor read data, page not present instruction pointer = 0x20:0x804fd1c7 stack pointer = 0x28:0xff811850a9d0 frame pointer = 0x28:0xff811850aa30 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq259: iwn0) trap number = 12 panic: page fault cpuid = 0 Uptime: 1h23m24s Dumping 692 out of 4055 MB:..3%..12%..21%..31%..42%..51%..61%..72%..81%..91% No symbol dumptid in current context. [...] #0 sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/src/9/sys/kern/sched_ule.c:1854 1854/usr/src/9/sys/kern/sched_ule.c: No such file or directory. in /usr/src/9/sys/kern/sched_ule.c (kgdb) #0 sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/src/9/sys/kern/sched_ule.c:1854 #1 0x807f23c9 in mi_switch (flags=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/src/9/sys/kern/kern_synch.c:448 #2 0x in ?? () #3 0xff811c0367d0 in ?? () #4 0x0046 in ?? () #5 0xff811c036810 in ?? () #6 0x807c2075 in intr_event_handle (ie=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/src/9/sys/kern/kern_intr.c:1476 Previous frame inner to this frame (corrupt stack?) [...] More information upon request. Regards, René -- http://www.rene-ladan.nl:8080/ GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC (subkeys.pgp.net) ___ 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: userland weirdness between r216351 and r216738
Op 31-12-2010 23:43, Alexander Kabaev schreef: On Fri, 31 Dec 2010 22:35:05 +0100 René Ladan r...@freebsd.org wrote: Hi, somewhere between 9.0-amd64 r216351 and r216738, I've noticed some userland weirdness. Symptoms are: - pseudo-random number generator not starting, preventing ssh(d) from working - fonts in X.org (xfce4) missing or replaced - mouse only working when hald is running I don't know if the above symptoms are somehow related, or what causes them. The kernel is GENERIC without (u)lpt and umass and with these modules loaded: fdescfs.ko if_iwn.ko snd_hda.ko sound.ko umass.ko iwn5000fw.ko nvidia.ko (256.53) linux.ko cuse4bsd.ko atapicam.ko linprocfs.ko Kernel and world are compiled with FreeBSD clang version 2.8 (tags/RELEASE_28 115870) 20101007 Reverting to r216351 (kernel, world, mergemaster) brought things back to normal. I can do a binary search if desired. Did someone else also see this? Happy 2011, Rene Try backing out rtld down to version prior to this commit http://svn.freebsd.org/changeset/base/216695 . There is an issue with rtld's use of SSE on amd64 which will be fixed soon. Backing out src/libexec/rtld-elf to r216694 solved it for now :) Rene -- http://www.rene-ladan.nl/ GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC (subkeys.pgp.net) ___ 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: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt
On 22-10-2010 16:30, Ed Schouten wrote: Hello everyone, At EuroBSDCon I was talking with some committers active in the area of Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC 4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed implementation called libcompiler_rt. See: http://compiler-rt.llvm.org/ [...] I've created a branch in Subversion which replaces libgcc.a and libgcc_p.a with libcompiler_rt.a and libcompiler_rt_p.a and symlinks it to the original names. It seems to survive a `make universe' and it works properly on at least amd64. [...] How to test this: - Check out the branch from SVN: svn co svn://svn.freebsd.org/base/user/ed/compiler-rt/ - Rebuild and reinstall world (and kernel). - Rebuild all your software (yes, I know it's unfortunate). - See whether software crashes or misbehaves, while it didn't do that previously. I noticed that the nvidia driver (from ports/x11/nvidia-driver*) needs to be recompiled after upgrading from HEAD to this branch. If you don't, it will load, but cause a panic when used by X. Rene ___ 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: Clang now builds world and kernel, on i386 and amd64
On 22-09-2010 18:45, Bartosz Stec wrote:
On 2010-09-22 12:42, René Ladan wrote:
2010/9/22 Dimitry Andricd...@freebsd.org:
Hi,
As of r212979, you should now be able to build world and kernel on i386
and amd64 with clang, without any additional patches!
To do so, make sure you have updated your installed world to at least
r212904 (which has the most recently imported clang/llvm snapshot), and
put the following in /etc/src.conf:
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
Just tried it. World has been builded without any problems, but stge
kernel module failed to compile:
=== stge (all)
clang -O2 -pipe -march=athlon-xp -fno-strict-aliasing -D_KERNEL
-DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/ATHLON9/opt_global.h -I. -I@ -I@/contrib/altq
-fno-common -I/usr/obj/usr/src/sys/ATHLON9 -mno-mmx -mno-3dnow
-mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -c /usr/src/sys/modules/stge/../../dev/stge/if_stge.c
/usr/src/sys/modules/stge/../../dev/stge/if_stge.c:1947:5: error:
'break' statement not in loop or switch statement
break;
^
/usr/src/sys/modules/stge/../../dev/stge/if_stge.c:1953:6: error:
'break' statement not in loop or switch statement
break
Hmm, works for me:
acer# ls -l /boot/kernel/if_stge.ko*
-r-xr-xr-x 1 root wheel 39344 Sep 22 13:34 /boot/kernel/if_stge.ko
-r-xr-xr-x 1 root wheel 218248 Sep 22 13:34
/boot/kernel/if_stge.ko.symbols
acer#
This is with the default GENERIC kernel.
Rene
--
http://www.rene-ladan.nl/
GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC
(subkeys.pgp.net)
___
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: Filesystem wedge, SUJ-related?
On 18-07-2010 15:02, Gavin Atkinson wrote: On Sat, 17 Jul 2010, Gavin Atkinson wrote: Semi-regularly (every two-three days) I'm seeing what appears to be some sort of filesystem wedge. I usually see it initially with web browsers, but it's possible that's only because it's what produces most disk activity on this machine. I've seen it with both Opera and Firefox. I've been seeing this too. It still happens with kernel r211000. What happens is that the process will just wedge. A procstat -kk on it shows the following stack backtrace: 9012 100243 firefox-bin initial thread mi_switch+0x21d sleepq_switch+0x123 sleepq_wait+0x4d _sleep+0x357 getdirtybuf+0x21e flush_deplist+0x6f softdep_sync_metadata+0x153 ffs_syncvnode+0x213 ffs_fsync+0x43 fsync+0x148 syscallenter+0x1b5 syscall+0x4c Xfast_syscall+0xe2 Firefox is the usual first sign: acer % ps ax|grep firefox 82117 v0 T 16:24,08 /usr/local/lib/firefox3/firefox-bin 13416 3 S+ 0:00,00 grep firefox acer % procstat -kk 82117 PIDTID COMM TDNAME KSTACK 82117 100195 firefox-bin -mi_switch+0x219 thread_suspend_switch+0x103 thread_single+0x25c exit1+0x81 sigexit+0x84 cursig+0 ast+0x1aa doreti_ast+0x1f 82117 100221 firefox-bin initial thread mi_switch+0x219 sleepq_switch+0xfa sleepq_wait+0x46 _sleep+0x256 getdirtybuf+0x1af flush_deplist+0x6a softdep_sync_metadata+0x153 ffs_syncvnode+0x22d ffs_fsync+0x43 fsync+0x13d syscallenter+0x194 syscall+0x41 Xfast_syscall+0xe2 acer % A bit more detail: it does look like whatever is supposed to periodically flush the journal just stops doing it's job. Presumably this is also the root cause of the softdep: Out of journal space! messages I have been seeing in the past, which I had assumed may have been fixed by r209717. I haven't seen any softdep: Out of journal space! messages since June 24, but I've indeed seen it once before (somewhere after June 11). (I'm running r209723 at the moment) While processes are starting to hang, sh ffs from ddb shows: db sh ffs mp 0xff0002c45be0 / devvp 0xff0002c51000 fs 0xff0002c67000 su_wl 0 su_wl_in 0 su_deps 0 su_req 0 mp 0xff0002d705f0 /tmp devvp 0xff0002d48780 fs 0xff0002c64800 su_wl 0 su_wl_in 0 su_deps 0 su_req 0 mp 0xff0002c458e8 /usr devvp 0xff0002d485a0 fs 0xff0002c66000 su_wl 0 su_wl_in 0 su_deps 17345 su_req 0 mp 0xff0002c455f0 /var devvp 0xff0002d483c0 fs 0xff0002c66800 su_wl 0 su_wl_in 0 su_deps 55 su_req 0 Leaving it another couple of hours, I then see: db sh ffs mp 0xff0002c45be0 / devvp 0xff0002c51000 fs 0xff0002c67000 su_wl 0 su_wl_in 0 su_deps 0 su_req 0 mp 0xff0002d705f0 /tmp devvp 0xff0002d48780 fs 0xff0002c64800 su_wl 0 su_wl_in 0 su_deps 36 su_req 0 mp 0xff0002c458e8 /usr devvp 0xff0002d485a0 fs 0xff0002c66000 su_wl 0 su_wl_in 0 su_deps 31899 su_req 0 mp 0xff0002c455f0 /var devvp 0xff0002d483c0 fs 0xff0002c66800 su_wl 0 su_wl_in 0 su_deps 95 su_req 0 so, su_deps is increasing significantly. During reboot, vnlru failed to stop within 60 seconds, and gave up on syncing 125 vnodes and 140 buffers (no idea if these are related). On reboot, SU+J fsck shows for /usr: ** SU+J Recovering /dev/ad4s1f ** Reading 33554432 byte journal from inode 150. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 405991 journal records in 18194944 bytes for 71.40% utilization ** Freed 3872 inodes (0 dirs) 48157 blocks, and 8744 frags. Similar here. So it seems clear that somehow the journal is filling up, and never being written. Any other suggestions as to where I should go from here? Disabling the journal would be a solution, but not desirable. Maybe any lock order reversals to look out for (most are ufs-related) ? I don't know if it is related, but yesterday a full fsck on /usr cleared up two unallocated files in /usr/ports/editors/openoffice-3/work/ (they were in userland as having a bad file descriptor), which the journal didn't catch. Regards, Rene -- http://www.rene-ladan.nl/ GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC (subkeys.pgp.net) ___ 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: thunderbird-3.0.6 stuck in ucond upon start
FWIW, thunderbird-3.1.1 runs fine on exactly the same kernel. Regards, Rene On 03-08-2010 15:45, Etienne Robillard wrote: Could this be a side effect from DEADLKRES or as a result of a exclusive mutex lock (lock order reversal) ? I'd add option DEBUG_LOCKS and/or WITNESS_SKIPSPIN, to disable witness checks on spin mutexes, as explained in the NOTES file. cheers, Etienne René Ladan wrote: It should just be the GENERIC kernel, it is attached for completeness. Rene 2010/8/3 Etienne Robillard e...@gthcfoundation.org: Please show us the kernel config too. It compiles and runs without side effects on FreeBSD 8.1 (GENERIC) and native gcc... cheers! Etienne On 08/02/10 17:18, René Ladan wrote: Fair enough... a trace of about the first 10 seconds generated by 'ktrace -di thunderbird' is available at ftp://rene-ladan.nl/pub/freebsd/ktrace.out You'll need a amd64 machine to kdump it. Note that nothing user-visible happens when I start thunderbird. Regards, Rene 2010/8/2 Etienne Robillarde...@gthcfoundation.org: a kernel backtrace would be a nice visual aid to debug!!! Cheers, Etienne René Ladan wrote: Hi, it looks like on this CURRENT: FreeBSD acer 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r210736: Sun Aug 1 21:51:37 CEST 2010 r...@acer:/usr/obj/usr/home/rene/freebsd/clangbsd/sys/GENERIC amd64 thunderbird is always stuck in ucond upon start, however it is killable. This is a clangbsd kernel (GENERIC, with WITNESS), r210319 with gccbsd userland, r209980 and gcc-compiled up-to-date ports. The following modules are loaded: acer % kldstat Id Refs Address Size Name 1 26 0x8010 f96790 kernel 2 1 0x81097000 570f8 iwn5000fw.ko 3 1 0x810ef000 29778 snd_hda.ko 4 2 0x81119000 85e20 sound.ko 5 1 0x8119f000 1c480 if_iwn.ko 6 1 0x81212000 3a85 linprocfs.ko 7 1 0x81216000 1de5d linux.ko acer % Regards, Rene ___ 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 ___ 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 -- http://www.rene-ladan.nl/ GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC (subkeys.pgp.net) ___ 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: [TESTING]: updated clang/LLVM needs testing in ClangBSD
On 15-07-2010 19:42, Roman Divacky wrote: I updated clang/LLVM in clangbsd to a newer version which I believe will fix thas. can you rene (and everyone else) please retest with updated ClangBSD and report back? The updated version builds and installs fine, I'm now running the clangbsd kernel. The clangbsd world (chrooted with make distribution DESTDIR=/usr/clangbsd and mount -t devfs devfs /usr/clangbsd/dev) seems to work fine, some basic commands work. Using a clang kernel with gcc kernel modules also works fine :) Regards, Rene On Thu, Jul 15, 2010 at 01:33:04PM +0200, Ren? Ladan wrote: 2010/7/14 Roman Divacky rdiva...@freebsd.org: hi, ClangBSD was updated to LLVM/clang revision r108243 which we plan to merge into HEAD. We would like that revision to be tested as much as possible and therefore we ask you to test ClangBSD to assure that the revision we are updating to does not have some really embarassing bugs. How to do it (on i386 and amd64): 0) install fresh devel/llvm-devel port 1) svn co http://svn.freebsd.org/base/projects/clangbsd src 2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf 3) cd src make buildworld And here my buildworld fails with: === lib/clang/libclanglex (depend) tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Common /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticCommonKinds.inc.h tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Lex /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticLexKinds.inc.h rm -f .depend CC='clang -isysroot /usr/obj/usr/home/rene/freebsd/clangbsd/tmp -B/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/ -L/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/' mkdep -f .depend -a -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -DCLANG_VENDOR=\FreeBSD\ \ -DSVN_REVISION=\108243\ -DCLANG_VENDOR_SUFFIX=\\ 20100713\ /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/LiteralSupport.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroArgs.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroInfo.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPCaching.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPDirectives.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPExpressions.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPLexerChange.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPMacroExpansion.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PTHLexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Pragma.cpp
Re: nvidia-driver crashing kernel on head
On 08-07-2010 22:09, Doug Barton wrote: On Thu, 8 Jul 2010, John Baldwin wrote: These freezes and panics are due to the driver using a spin mutex instead of a regular mutex for the per-file descriptor event_mtx. If you patch the driver to change it to be a regular mutex I think that should fix the problems. Can you give an example? :) I don't mind creating a patch for all of them if you can illustrate what needs to be changed. See the attached patch -- http://www.rene-ladan.nl/ GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC (subkeys.pgp.net) --- src/nvidia_ctl.c.orig 2010-06-17 03:28:57.0 +0200 +++ src/nvidia_ctl.c2010-07-08 15:30:10.0 +0200 @@ -53,7 +53,7 @@ } filep-nv = nv; -mtx_init(filep-event_mtx, event_mtx, NULL, (MTX_SPIN | MTX_RECURSE)); +mtx_init(filep-event_mtx, event_mtx, NULL, (MTX_DEF | MTX_RECURSE)); STAILQ_INIT(filep-event_queue); nv_lock_api(nv); @@ -123,7 +123,7 @@ if (status != 0) return status; -mtx_lock_spin(filep-event_mtx); +mtx_lock(filep-event_mtx); et = STAILQ_FIRST(filep-event_queue); if (et == NULL) @@ -131,7 +131,7 @@ else mask = (events (POLLIN | POLLPRI | POLLRDNORM)); -mtx_unlock_spin(filep-event_mtx); +mtx_unlock(filep-event_mtx); return mask; } --- src/nvidia_dev.c.orig 2010-06-17 03:28:57.0 +0200 +++ src/nvidia_dev.c2010-07-08 15:29:54.0 +0200 @@ -52,7 +52,7 @@ } filep-nv = nv; -mtx_init(filep-event_mtx, event_mtx, NULL, (MTX_SPIN | MTX_RECURSE)); +mtx_init(filep-event_mtx, event_mtx, NULL, (MTX_DEF | MTX_RECURSE)); STAILQ_INIT(filep-event_queue); nv_lock_api(nv); @@ -123,7 +123,7 @@ if (status != 0) return status; -mtx_lock_spin(filep-event_mtx); +mtx_lock(filep-event_mtx); et = STAILQ_FIRST(filep-event_queue); if (et == NULL) @@ -131,7 +131,7 @@ else mask = (events (POLLIN | POLLPRI | POLLRDNORM)); -mtx_unlock_spin(filep-event_mtx); +mtx_unlock(filep-event_mtx); return mask; } ___ 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: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 14-06-2010 23:31, Christian Zander wrote:
On Mon, Jun 14, 2010 at 02:30:03PM -0700, Rene Ladan wrote:
(...)
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any news on this? I have updated to the latest current so I'm
running the nv driver now, but I'd like to get the nvidia driver running
again.
Yes, the unnecessary (and now problematic) wiring and unwiring calls will
be
removed in a future release of the driver.
Excellent! Any ETA? Or are there patches against an existing version of
the driver?
I would just remove the calls to vm_page_wire() and vm_page_unwire() along
with the immediately adjacent calls to vm_page_{un,}lock_queues().
Just to confirm, like the attached patch?
Yes.
This is with a GeForce GT 240M, current/amd64 r209035, nvidia-driver
195.36.15
I haven't runtime-tested it yet...
Using the above configuration, X still locks up but now after showing
the NVIDIA splash screen. Without the patch it locks up before that
point. Pinging the computer doesn't work anymore, no panic or logs, a
hard reset is required.
Would disabling DRI and/or Accel in xorg.conf or updating the driver /
operating system somehow help?
Rene
--
http://www.rene-ladan.nl/
GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC
(subkeys.pgp.net)
___
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: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 14-06-2010 14:48, John Baldwin wrote:
On Sunday 13 June 2010 11:23:07 pm Doug Barton wrote:
On 06/13/10 19:09, Alan Cox wrote:
On Sun, Jun 13, 2010 at 8:38 PM, Doug Bartondo...@freebsd.org wrote:
On 06/01/10 08:26, John Baldwin wrote:
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any news on this? I have updated to the latest current so I'm
running the nv driver now, but I'd like to get the nvidia driver running
again.
Yes, the unnecessary (and now problematic) wiring and unwiring calls will
be
removed in a future release of the driver.
Excellent! Any ETA? Or are there patches against an existing version of
the driver?
I would just remove the calls to vm_page_wire() and vm_page_unwire() along
with the immediately adjacent calls to vm_page_{un,}lock_queues().
Just to confirm, like the attached patch?
This is with a GeForce GT 240M, current/amd64 r209035, nvidia-driver
195.36.15
I haven't runtime-tested it yet...
Rene
--
http://www.rene-ladan.nl/
GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6
(subkeys.pgp.net)
--- src/nvidia_subr.c.orig 2010-03-12 17:48:52.0 +0100
+++ src/nvidia_subr.c 2010-06-14 23:25:28.0 +0200
@@ -1301,9 +1301,6 @@
for (i = 0; i count; i++) {
pte_array[i] = at-pte_array[i].physical_address;
-vm_page_lock_queues();
-vm_page_wire(PHYS_TO_VM_PAGE(pte_array[i]));
-vm_page_unlock_queues();
sglist_append_phys(at-sg_list, pte_array[i], PAGE_SIZE);
}
@@ -1365,9 +1362,6 @@
os_flush_cpu_cache();
for (i = 0; i count; i++) {
-vm_page_lock_queues();
-vm_page_unwire(PHYS_TO_VM_PAGE(at-pte_array[i].physical_address), 0);
-vm_page_unlock_queues();
kmem_free(kernel_map,
at-pte_array[i].virtual_address, PAGE_SIZE);
malloc_type_freed(M_NVIDIA, PAGE_SIZE);
___
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
kldload(8) might panic
Hi,
on my 5.1R-box, I sometimes get the below panic message when loading a module into the
kernel with kldload(8).
It seems that some part of the linker reports a bogus value for the required memory.
Other times loading modules works fine.
Rene
Script started on Fri Jul 18 19:35:09 2003
[EMAIL PROTECTED]:/usr/home/rene$ uname -a
FreeBSD n188.dial.tue.nl 5.1-RELEASE FreeBSD 5.1-RELEASE #0: Thu Jul 17 15:34:28 CEST
2003 [EMAIL PROTECTED]:/usr/src-releng51/sys/i386/compile/RENE_2003-07-17 i386
[EMAIL PROTECTED]:/usr/home/rene$ cat /usr/tmp/gdbk.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: from debugger
panic messages:
---
panic: kmem_malloc(42766336): kmem_map too small: 55050240 total allocated
panic: from debugger
Uptime: 8h50m15s
Dumping 191 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176
---
Reading symbols from /boot/kernel/vesa.ko...done.
Loaded symbols for /boot/kernel/vesa.ko
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/blank_saver.ko...done.
Loaded symbols for /boot/kernel/blank_saver.ko
Reading symbols from /boot/kernel/umodem.ko...done.
Loaded symbols for /boot/kernel/umodem.ko
#0 doadump () at ../../../kern/kern_shutdown.c:238
238 ../../../kern/kern_shutdown.c: No such file or directory.
in ../../../kern/kern_shutdown.c
(kgdb) bt full
#0 doadump () at ../../../kern/kern_shutdown.c:238
No locals.
#1 0xc024eafd in boot (howto=260) at ../../../kern/kern_shutdown.c:370
No locals.
#2 0xc024ef48 in panic () at ../../../kern/kern_shutdown.c:543
td = (struct thread *) 0xc226c000
bootopt = 260
newpanic = 0
buf = from debugger\0766336): kmem_map too small: 55050240 total allocated,
'\0' repeats 188 times
#3 0xc0130b75 in db_panic () at ../../../ddb/db_command.c:448
No locals.
#4 0xc0130ad2 in db_command (last_cmdp=0xc042b5e0, cmd_table=0x0,
aux_cmd_tablep=0xc0426f38, aux_cmd_tablep_end=0xc0426f3c)
at ../../../ddb/db_command.c:346
cmd = (struct command *) 0xc03eccb4
t = 0
modif =
\08ÌÏ\bâ9ÀÐß9ÀØÞ9À\200wJÀ`äHÀàeGÀ\b\217KÀP8ÌÏíÞ9À°Þ9À9ò(À`äHÀx\0\0\0àeGÀ\b\217KÀx8ÌÏ\a/\023À°.\023À\215#\023À\0\0\0\0\020\0\0\0\b\217KÀáì;À.$\023Àð\\023À\020'\023Àx\0\0\0\003\0\0\0¼9ÌÏ
addr = -1069890249
count = -1
have_addr = 0
result = 0
#5 0xc0130c16 in db_command_loop () at ../../../ddb/db_command.c:470
No locals.
#6 0xc013446b in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
bkpt = 0
#7 0xc03ac205 in kdb_trap (type=3, code=0, regs=0xcfcc3974)
at ../../../i386/i386/db_interface.c:170
ef = 70
ddb_mode = 1
#8 0xc03c082c in trap (frame=
{tf_fs = -1069875176, tf_es = 16, tf_ds = -1068826608, tf_edi = -1037647872,
tf_esi = 1, tf_ebp = -808699456, tf_isp = -808699488, tf_ebx = 0, tf_edx = 0, tf_ecx =
0, tf_eax = -1069890250, tf_trapno = 3, tf_err = 0, tf_eip = -1069890249, tf_cs = 8,
tf_eflags = 663, tf_esp = -1069413180, tf_ss = -1069477935})
at ../../../i386/i386/trap.c:593
td = (struct thread *) 0xc226c000
p = (struct proc *) 0xc226bd20
sticks = 1
i = 0
ucode = 0
type = 3
code = 0
eva = 0
#9 0xc03ae1ee in calltrap () at {standard input}:96
No locals.
#10 0xc024ee9b in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:527
td = (struct thread *) 0xc226c000
bootopt = 256
newpanic = 1
buf = from debugger\0766336): kmem_map too small: 55050240 total allocated,
'\0' repeats 188 times
#11 0xc035c6ea in kmem_malloc (map=0xc082f0b0, size=42766336, flags=2)
at ../../../vm/vm_kern.c:339
offset = 3224838192
i = 3257833656
entry = (struct vm_map_entry *) 0xc0372440
addr = 3234832384
m = (struct vm_page *) 0x0
pflags = -1070128770
#12 0xc0370e3d in page_alloc (zone=0x0, bytes=0, pflag=0x0, wait=0)
at ../../../vm/uma_core.c:803
p = (void *) 0x0
#13 0xc037327e in uma_large_malloc (size=42766336, wait=2)
at ../../../vm/uma_core.c:2034
mem = (void *) 0x0
slab = (struct uma_slab *) 0xc22e98b8
flags = 2 '\002'
#14 0xc02413c1 in malloc (size=42766336, type=0xc045cd20, flags=2)
at ../../../kern/kern_malloc.c:240
indx = 42766336
va = 0xc226c000 ½Â
zone = (struct uma_zone *) 0xcfcc3b44
ksp = (struct malloc_type *) 0xc045cd20
#15 0xc0275ffc in kmupetext (nhighpc=3289623160)
at
