Re: libfftw3.so.5: compile error on port of awesome
On Tue, Jan 17, 2012 at 5:09 PM, Marcelo/Porks wrote: > Hi guys, I do not know if this is the correct mail list to report this. > > I'm trying to compile the port x11-wm/awesome but failed with the error: > > [ 37%] Building C object CMakeFiles/awesome.dir/common/tokenize.c.o > Linking C executable awesome > [ 37%] Built target awesome > Scanning dependencies of target generated_icons > [ 38%] Generating themes/zenburn/titlebar/maximized_normal_active.png > Shared object "libfftw3.so.5" not found, required by "convert"*** Error > code 1 > > Stop in /usr/ports/x11-wm/awesome/work/awesome-3.4.11. > *** Error code 1 > > I'm using the head and the workaround of UNAME_r=9.9-CURRENT > > BARAD-DUR# uname -a > FreeBSD BARAD-DUR 9.9-CURRENT FreeBSD 10.0-CURRENT #6 r230290M: Tue Jan 17 > 22:22:46 BRST 2012 root@BARAD-DUR:/usr/clang/obj/usr/src/sys/GENERIC > amd64 > BARAD-DUR# echo $UNAME_r > u9.9-CURRENT > > (GMT-2) > > I have on my system /usr/local/lib/libfftw3.so.6 > I can compile making: > ln -s /usr/local/lib/libfftw3.so /usr/local/lib/libfftw3.so.5 > > (I know, this is a bad thing to do) > > Could someone check if on your system the same happen? > Yes, it's risky to do that. The problem is that some port on your system needs to re-link against /usr/local/lib/libfftw3.so.6. You can find the ports that link to non-existent libs by installing sysutils/bsdadminscripts and running pkg_libchk. It will list all executables that are linked against non-existent libs. Note that it does generate a few false positives. See the man page for details, but none of the false positives is likely to show up for libfftw3. Re-install any port with files linked against libfftw3.so.5. While you are at it, fix any other errors found, though you may skip openoffice and Java (false positives). -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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"
libfftw3.so.5: compile error on port of awesome
Hi guys, I do not know if this is the correct mail list to report this. I'm trying to compile the port x11-wm/awesome but failed with the error: [ 37%] Building C object CMakeFiles/awesome.dir/common/tokenize.c.o Linking C executable awesome [ 37%] Built target awesome Scanning dependencies of target generated_icons [ 38%] Generating themes/zenburn/titlebar/maximized_normal_active.png Shared object "libfftw3.so.5" not found, required by "convert"*** Error code 1 Stop in /usr/ports/x11-wm/awesome/work/awesome-3.4.11. *** Error code 1 I'm using the head and the workaround of UNAME_r=9.9-CURRENT BARAD-DUR# uname -a FreeBSD BARAD-DUR 9.9-CURRENT FreeBSD 10.0-CURRENT #6 r230290M: Tue Jan 17 22:22:46 BRST 2012 root@BARAD-DUR:/usr/clang/obj/usr/src/sys/GENERIC amd64 BARAD-DUR# echo $UNAME_r u9.9-CURRENT (GMT-2) I have on my system /usr/local/lib/libfftw3.so.6 I can compile making: ln -s /usr/local/lib/libfftw3.so /usr/local/lib/libfftw3.so.5 (I know, this is a bad thing to do) Could someone check if on your system the same happen? ___ 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: new panic in cpu_reset() with WITNESS
on 17/01/2012 17:34 m...@freebsd.org said the following:
> 2012/1/17 Gleb Smirnoff :
>> New panic has been introduced somewhere between
>> r229851 and r229932, that happens on shutdown if
>> kernel has WITNESS and doesn't have WITNESS_SKIPSPIN.
[**]
>> Uptime: 1h0m17s
>> Rebooting...
>> panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @
>> /usr/src/head/sys/kern/kern_cons.c:500
>> cpuid = 0
>> KDB: enter: panic
>> [ thread pid 1 tid 11 ]
>> Stopped at kdb_enter+0x3b: movq$0,0x514d32(%rip)
>> db>
>> db> bt
>> Tracing pid 1 tid 11 td 0xfe0001d5e000
>> kdb_enter() at kdb_enter+0x3b
>> panic() at panic+0x1c7
>> _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f
>> cnputs() at cnputs+0x7a
>> putchar() at putchar+0x11f
>> kvprintf() at kvprintf+0x83
>> vprintf() at vprintf+0x85
>> printf() at printf+0x67
>> witness_checkorder() at witness_checkorder+0x773
>> _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x99
>> uart_cnputc() at uart_cnputc+0x3e
>> cnputc() at cnputc+0x4c
>> cnputs() at cnputs+0x26
>> putchar() at putchar+0x11f
>> kvprintf() at kvprintf+0x83
>> vprintf() at vprintf+0x85
>> printf() at printf+0x67
>> cpu_reset() at cpu_reset+0x81
>> kern_reboot() at kern_reboot+0x3a5
>> --More--^M^Msys_reboot() at sys_reboot+0x42
>> amd64_syscall() at amd64_syscall+0x39e
>> Xfast_syscall() at Xfast_syscall+0xf7
>> --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ea3c, rsp =
>> 0x7fffd6d8, rbp = 0x49 ---
>> db>
>> db> show locks
>> exclusive sleep mutex Giant (Giant) r = 0 (0x809bc560) locked @
>> /usr/src/head/sys/kern/kern_module.c:101
>> exclusive spin mutex smp rendezvous (smp rendezvous) r = 0
>> (0x80a08840) locked @ /usr/src/head/sys/kern/kern_shutdown.c:542
>> db>
>>
>> So the problem is that we are holding smp rendezvous mutex during the
>> cpu_reset().
>> No mutexes should be obtained after it. However, since cpu_reset() does
>> priting
>> we obtain cnputs_mtx, and later obtain uart_hwmtx. The latter is hardcoded in
>> the subr_witness.c as mutex to obtain before smp rendezvous, this triggers
>> yet another printf from witness, that finally panics due to recursing on
>> cnputs_mtx.
>
> At $WORK we explicitly marked cnputs_mtx as NO_WITNESS since it didn't
> seem possible to fit it into the heirarchy in any sane way, since a
> print can come from basically anywhere.
This is the case for the FreeBSD tree too (at least in head).
> If anyone has a better fix, that'd be great, but I haven't been able
> to think of one.
Please note that while the panic happened on cnputs_mtx[*] (because of the
recursion), it seems to have been provoked by uart_hwmtx actually.
The root cause of the panic at hand is that smp_ipi_mtx is supposed to be a
"terminal" lock, i.e. no other lock is supposed to be acquired while smp_ipi_mtx
is held. This is the case for all the normal code, but the rule is violated for
cpu_reset() in the SMP case, because smp_ipi_mtx is acquired in shutdown_reset()
and is held till the end.
Thus, while normally smp_ipi_mtx and cnputs_mtx/uart_hwmtx should be completely
independent, they have become dependent in this reset path.
I think that normally this problem is hidden by people not using WITNESS or by
them using WITNESS_SKIPSPIN.
One obvious solution is to change the relative order of smp_ipi_mtx (aka "smp
rendezvous") and uart_hwmtx in order_lists of subr_witness.c, which predefine
some order that is expected between the locks.
Another solution is to look into the reason why smp_ipi_mtx is acquired in
shutdown_reset(). This call has been added to avoid [what used to be] a
deadlock between the stop_cpus() call with interrupts disabled on a shutdown CPU
and smp_rendezvous or some tlb ipi call on another CPU. As such it should be
sufficient to hold smp_ipi_mtx around the stop_cpus() call.
In fact, I would argue that stop_cpus() must hold smp_ipi_mtx for the above
reason. That is, all inter-CPU operations should be initiated using the same
lock.
[*]
And there is, of course, a different issue (pointed out many times by Bruce
Evans) of cnputs_mtx and now msg_lock ("msgbuf" lock) being inadequate for their
jobs as this example demonstrates. Multiplied by the problem of printf being
used where db_printf would have been a better choice.
Since printf (or db_printf) can be called truly in any situation, the locking
must handle recursion, must handle being "stuck" on another CPU, etc. In
general, these functions should strive to be lockless, but that's probably not
really practical for the normal situations in SMP environment. Still the
special situations should be detected and handled.
[**] I would expect this panic/problem to be there for a long time already
(definitely before r229851). It's surprising to me that it seems to be a recent
phenomenon.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
Re: svn stuck in read()
On Mon, Jan 16, 2012 at 03:54:02PM -0800, Steve Kargl wrote: > On Mon, Jan 16, 2012 at 10:38:04PM +0100, Dimitry Andric wrote: > > On 2012-01-16 21:42, Steve Kargl wrote: > > >Is anyone else seeing svn getting stuck while > > >updating /usr/src on an update-to-date freebsd-current? > > > > I saw this when I tried out serf instead of the default neon. For me, > > it hung in about 20% of remote operations. Reverting to neon fixed the > > problem, but I never delved any deeper. > > I'm not using serf. neon was fairly new, but I'll re-install > it to see if the problem presists. Thanks for the feedback. > After rebuilding apr-nothr-ipv6-devrandom-gdbm-db42 to not use threads, subversion works as expected. There appears to be some race condition with apr-* and libthr. -- 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: Build Option Survey results
On Thu, 2012-01-12 at 07:45:34 +, Bjoern A. Zeeb wrote: > Hey, > > after two years I had the opportunity to run the build option survey, > initially done by phk, again. The number of options seems to have grown > quite a bit it felt. I have not even looked at the results yet but here > they are fresh off the machine: > >http://people.freebsd.org/~bz/build_option_survey_20120106/ > > Special thanks go to np, sbruno and bhaga for bringing worm back to life. Cool. Is the idea to kill options that have zero effect on anything? What about options that are broken? Is it worth carrying around tons of conditionals if they don't even work? Aren't we supposed to have an army of embedded people that use all of that stuff? Or is nanobsd circumventing the WITHOUT_FOO logic? Cheers, Uli ___ 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: dhclient em0: not found rev r230054
On Tue, Jan 17, 2012 at 01:57:48PM +0200, Octavian Rinciog wrote: > Hello! > > After updating to FreeBSD 10.0-CURRENT #0 r230054, I can't do anymore > dhclient on em0. > > [root@freebsd ~]# uname -a > FreeBSD freebsd 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230054: Fri Jan > 13 14:29:36 EET 2012 root@freebsd:/usr/obj/usr/head/sys/GENERIC > i386 > > [root@freebsd ~]# cat /var/log/messages | grep em0 | tail -n 6 > Jan 13 14:41:11 freebsd kernel: em0: Connection 7.3.2> port 0x1820-0x183f mem > 0xf030-0xf031,0xf0325000-0xf0325fff irq 23 at device 25.0 on > pci0 > Jan 13 14:41:11 freebsd kernel: em0: Using an MSI interrupt > Jan 13 14:41:11 freebsd kernel: em0: Ethernet address: 00:19:99:40:76:ee > Jan 13 14:41:12 freebsd kernel: em0: link state changed to UP > Jan 13 14:41:58 freebsd dhclient[1734]: em0: not found > ... I'm not seeing the above. I don't often have occasion to use em0 while running CURRENT, but today I do, running current at r230212M (building CURRENT at r230063): d134(10.0-C)[4] uname -a FreeBSD d134.dwolf.example.net. 10.0-CURRENT FreeBSD 10.0-CURRENT #445 230212M: Mon Jan 16 05:31:35 PST 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 d134(10.0-C)[5] grep -Jw em0 /var/run/dmesg.boot em0: port 0xefe0-0xefff mem 0xf6fe-0xf6ff,0xf6fdb000-0xf6fdbfff irq 22 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:24:e8:9c:11:0f d134(10.0-C)[6] grep -Jw em0 /var/log/messages.0.bz2 | tail -12 Jan 17 10:54:39 localhost dhclient: New Broadcast Address (em0): 192.168.7.255 Jan 17 10:54:39 localhost dhclient: New Routers (em0): 192.168.7.1 Jan 17 10:57:10 localhost kernel: em0: port 0xefe0-0xefff mem 0xf6fe-0xf6ff,0xf6fdb000-0xf6fdbfff irq 22 at device 25.0 on pci0 Jan 17 10:57:10 localhost kernel: em0: Using an MSI interrupt Jan 17 10:57:10 localhost kernel: em0: Ethernet address: 00:24:e8:9c:11:0f Jan 17 10:57:14 localhost kernel: em0: link state changed to DOWN Jan 17 10:57:16 localhost kernel: em0: link state changed to UP Jan 17 10:57:16 localhost dhclient: New Hostname (em0): Jan 17 10:57:16 localhost dhclient: New IP Address (em0): 192.168.7.134 Jan 17 10:57:16 localhost dhclient: New Subnet Mask (em0): 255.255.255.0 Jan 17 10:57:16 localhost dhclient: New Broadcast Address (em0): 192.168.7.255 Jan 17 10:57:16 localhost dhclient: New Routers (em0): 192.168.7.1 d134(10.0-C)[7] Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpKfGtoZf6Tr.pgp Description: PGP signature
Re: dhclient em0: not found rev r230054
On 01/17/2012 03:57, Octavian Rinciog wrote: > Jan 13 14:41:58 freebsd dhclient[1734]: em0: not found You need to update your world and kernel together. The ability to run new kernel on an old world (as is the usual upgrade method) was broken a little while ago, and the compatibility shims to fix it haven't appeared yet. After you do this upgrade together it'll be safe to resume using the normal 2-stage upgrade method. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: new panic in cpu_reset() with WITNESS
On Tue, Jan 17, 2012 at 07:34:23AM -0800, m...@freebsd.org wrote: m> 2012/1/17 Gleb Smirnoff : m> > New panic has been introduced somewhere between m> > r229851 and r229932, that happens on shutdown if m> > kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. m> > m> > Uptime: 1h0m17s m> > Rebooting... m> > panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/head/sys/kern/kern_cons.c:500 m> > cpuid = 0 m> > KDB: enter: panic m> > [ thread pid 1 tid 11 ] m> > Stopped at kdb_enter+0x3b: movq $0,0x514d32(%rip) m> > db> m> > db> bt m> > Tracing pid 1 tid 11 td 0xfe0001d5e000 m> > kdb_enter() at kdb_enter+0x3b m> > panic() at panic+0x1c7 m> > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f m> > cnputs() at cnputs+0x7a m> > putchar() at putchar+0x11f m> > kvprintf() at kvprintf+0x83 m> > vprintf() at vprintf+0x85 m> > printf() at printf+0x67 m> > witness_checkorder() at witness_checkorder+0x773 m> > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x99 m> > uart_cnputc() at uart_cnputc+0x3e m> > cnputc() at cnputc+0x4c m> > cnputs() at cnputs+0x26 m> > putchar() at putchar+0x11f m> > kvprintf() at kvprintf+0x83 m> > vprintf() at vprintf+0x85 m> > printf() at printf+0x67 m> > cpu_reset() at cpu_reset+0x81 m> > kern_reboot() at kern_reboot+0x3a5 m> > --More--^M ^Msys_reboot() at sys_reboot+0x42 m> > amd64_syscall() at amd64_syscall+0x39e m> > Xfast_syscall() at Xfast_syscall+0xf7 m> > --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ea3c, rsp = 0x7fffd6d8, rbp = 0x49 --- m> > db> m> > db> show locks m> > exclusive sleep mutex Giant (Giant) r = 0 (0x809bc560) locked @ /usr/src/head/sys/kern/kern_module.c:101 m> > exclusive spin mutex smp rendezvous (smp rendezvous) r = 0 (0x80a08840) locked @ /usr/src/head/sys/kern/kern_shutdown.c:542 m> > db> m> > m> > So the problem is that we are holding smp rendezvous mutex during the cpu_reset(). m> > No mutexes should be obtained after it. However, since cpu_reset() does priting m> > we obtain cnputs_mtx, and later obtain uart_hwmtx. The latter is hardcoded in m> > the subr_witness.c as mutex to obtain before smp rendezvous, this triggers m> > yet another printf from witness, that finally panics due to recursing on m> > cnputs_mtx. m> m> At $WORK we explicitly marked cnputs_mtx as NO_WITNESS since it didn't m> seem possible to fit it into the heirarchy in any sane way, since a m> print can come from basically anywhere. m> m> If anyone has a better fix, that'd be great, but I haven't been able m> to think of one. Setting NO_WITNESS on cnputs_mtx won't help for the above problem, IMHO. -- Totus tuus, Glebius. ___ 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: dhclient em0: not found rev r230054
On Tue, Jan 17, 2012 at 01:57:48PM +0200, Octavian Rinciog wrote: O> Hello! O> O> After updating to FreeBSD 10.0-CURRENT #0 r230054, I can't do anymore O> dhclient on em0. O> O> [root@freebsd ~]# uname -a O> FreeBSD freebsd 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230054: Fri Jan O> 13 14:29:36 EET 2012 root@freebsd:/usr/obj/usr/head/sys/GENERIC O> i386 O> O> [root@freebsd ~]# cat /var/log/messages | grep em0 | tail -n 6 O> Jan 13 14:41:11 freebsd kernel: em0: Connection 7.3.2> port 0x1820-0x183f mem O> 0xf030-0xf031,0xf0325000-0xf0325fff irq 23 at device 25.0 on O> pci0 O> Jan 13 14:41:11 freebsd kernel: em0: Using an MSI interrupt O> Jan 13 14:41:11 freebsd kernel: em0: Ethernet address: 00:19:99:40:76:ee O> Jan 13 14:41:12 freebsd kernel: em0: link state changed to UP O> Jan 13 14:41:58 freebsd dhclient[1734]: em0: not found O> O> [root@freebsd ~]# dhclient em0 O> ifconfig: ioctl (SIOCAIFADDR): File exists O> em0: not found O> exiting. O> O> Do you know how can I fix this problem? Did you upgrade your world together with the kernel? Can you show: #ident /sbin/dhclient-script -- Totus tuus, Glebius. ___ 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: installworld: posix_memalign
Hi, * Monthadar Al Jaberi , 20120117 18:17: > But now I get another error when installworld I suspect something unrelated to my change is the culprit. Can you make sure your source tree is not modified, for example by checking out using a different cvsup mirror? Thanks, -- Ed Schouten WWW: http://80386.nl/ pgphvr7s3q0A2.pgp Description: PGP signature
Re: installworld: posix_memalign
On Mon, Jan 16, 2012 at 9:54 PM, Ed Schouten wrote: > Hi Monthadar, > > * Monthadar Al Jaberi , 20120116 18:48: >> I updated my source tree to lastest and buildworld and buildkernel >> without error. but installworld gives this error: >> >> install: posix_memalign.3.gz: No such file or directory >> >> checking the the log I see there where some changes done 6 days ago >> for this file /head/lib/libc/stdlib/Makefile.inc >> >> should this line inside Makefile.inc: >> >> MLINKS+=aligned_alloc.3 posix_memalign.3 >> >> be changed to >> >> MLINKS+=aligned_alloc.3 > > Are you sure about this? Filenames provided in MLINKS are always > provided in pairs. You specify which file needs to be linked to the > other. So the aligned_alloc man page needs to be linked to > posix_memalign. > > What happens if you remove your obj-directory before running make > buildworld/installworld? I did that and it fixed the problem, but why was it an error in the first place? shouldn't make take care of these things? > > Thanks, > -- > Ed Schouten > WWW: http://80386.nl/ But now I get another error when installworld it says: install: libsbuf.so.5: No such file or directory ** Error code 71 Stop in /usr/src/lib/libsbuf When I look it seems to have compiled libsbuf.so.6 while 5 is listed in the Obselete file my system is FreeBSD mesh 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Tue Jan 17 08:06:03 CET 2012 root@/usr/obj/usr/src/sys/GENERIC amd64 Thank you, Monthadar Al Jaberi ___ 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: new panic in cpu_reset() with WITNESS
2012/1/17 Gleb Smirnoff : > New panic has been introduced somewhere between > r229851 and r229932, that happens on shutdown if > kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. > > Uptime: 1h0m17s > Rebooting... > panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ > /usr/src/head/sys/kern/kern_cons.c:500 > cpuid = 0 > KDB: enter: panic > [ thread pid 1 tid 11 ] > Stopped at kdb_enter+0x3b: movq $0,0x514d32(%rip) > db> > db> bt > Tracing pid 1 tid 11 td 0xfe0001d5e000 > kdb_enter() at kdb_enter+0x3b > panic() at panic+0x1c7 > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f > cnputs() at cnputs+0x7a > putchar() at putchar+0x11f > kvprintf() at kvprintf+0x83 > vprintf() at vprintf+0x85 > printf() at printf+0x67 > witness_checkorder() at witness_checkorder+0x773 > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x99 > uart_cnputc() at uart_cnputc+0x3e > cnputc() at cnputc+0x4c > cnputs() at cnputs+0x26 > putchar() at putchar+0x11f > kvprintf() at kvprintf+0x83 > vprintf() at vprintf+0x85 > printf() at printf+0x67 > cpu_reset() at cpu_reset+0x81 > kern_reboot() at kern_reboot+0x3a5 > --More--^M ^Msys_reboot() at sys_reboot+0x42 > amd64_syscall() at amd64_syscall+0x39e > Xfast_syscall() at Xfast_syscall+0xf7 > --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ea3c, rsp = > 0x7fffd6d8, rbp = 0x49 --- > db> > db> show locks > exclusive sleep mutex Giant (Giant) r = 0 (0x809bc560) locked @ > /usr/src/head/sys/kern/kern_module.c:101 > exclusive spin mutex smp rendezvous (smp rendezvous) r = 0 > (0x80a08840) locked @ /usr/src/head/sys/kern/kern_shutdown.c:542 > db> > > So the problem is that we are holding smp rendezvous mutex during the > cpu_reset(). > No mutexes should be obtained after it. However, since cpu_reset() does > priting > we obtain cnputs_mtx, and later obtain uart_hwmtx. The latter is hardcoded in > the subr_witness.c as mutex to obtain before smp rendezvous, this triggers > yet another printf from witness, that finally panics due to recursing on > cnputs_mtx. At $WORK we explicitly marked cnputs_mtx as NO_WITNESS since it didn't seem possible to fit it into the heirarchy in any sane way, since a print can come from basically anywhere. If anyone has a better fix, that'd be great, but I haven't been able to think of one. Thanks, matthew ___ 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: atkbc not loaded with ACPI enabled in 9.0
On Friday, January 13, 2012 10:27:13 pm aconnoll...@yahoo.co.jp wrote:
> Please try this patch:
>
> Index: sys/dev/atkbdc/atkbdc_isa.c
> ===
> --- atkbdc_isa.c(revision 230009)
> +++ atkbdc_isa.c(working copy)
> @@ -87,6 +87,7 @@ static driver_t atkbdc_isa_driver = {
>
> static struct isa_pnp_id atkbdc_ids[] = {
> { 0x0303d041, "Keyboard controller (i8042)" },/* PNP0303 */
> +{ 0x0320d041, "Keyboard controller (i8042)" },/* PNP0320 */
> { 0 }
> };
>
>
> --
> John Baldwin
> ___
> 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
> John,
> Thanks for your help, but that patch doesn't appear to address the problem.
I edited the atkbdc_isa.c file as you instructed, rebuilt and installed my
kernel, but my integrated keyboard remains unresponsive with ACPI enabled.
> Here's the new output of dmesg -a http://pastebin.com/h6ahmD2ddevinfo -ur
http://pastebin.com/sdNcNEJUdevinfo -vr http://pastebin.com/P2yqQBLY
> Perhaps I was supposed to remove PNP0303 support?
No, the goal was to get atkbdc to try to attach to PNP0320 devices since those
have your keyboard I/O ports. Can you add some printfs to atkbdc_isa_probe()
to see how many times it is getting past the ID check, and how far along it
gets in each cases (i.e. which failure case causes the probe routine to return
an error)?
--
John Baldwin
___
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"
dhclient em0: not found rev r230054
Hello! After updating to FreeBSD 10.0-CURRENT #0 r230054, I can't do anymore dhclient on em0. [root@freebsd ~]# uname -a FreeBSD freebsd 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230054: Fri Jan 13 14:29:36 EET 2012 root@freebsd:/usr/obj/usr/head/sys/GENERIC i386 [root@freebsd ~]# cat /var/log/messages | grep em0 | tail -n 6 Jan 13 14:41:11 freebsd kernel: em0: port 0x1820-0x183f mem 0xf030-0xf031,0xf0325000-0xf0325fff irq 23 at device 25.0 on pci0 Jan 13 14:41:11 freebsd kernel: em0: Using an MSI interrupt Jan 13 14:41:11 freebsd kernel: em0: Ethernet address: 00:19:99:40:76:ee Jan 13 14:41:12 freebsd kernel: em0: link state changed to UP Jan 13 14:41:58 freebsd dhclient[1734]: em0: not found [root@freebsd ~]# dhclient em0 ifconfig: ioctl (SIOCAIFADDR): File exists em0: not found exiting. Do you know how can I fix this problem? Thank you, Octavian Rinciog ___ 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"
new panic in cpu_reset() with WITNESS
New panic has been introduced somewhere between r229851 and r229932, that happens on shutdown if kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. Uptime: 1h0m17s Rebooting... panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/head/sys/kern/kern_cons.c:500 cpuid = 0 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x3b: movq$0,0x514d32(%rip) db> db> bt Tracing pid 1 tid 11 td 0xfe0001d5e000 kdb_enter() at kdb_enter+0x3b panic() at panic+0x1c7 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f cnputs() at cnputs+0x7a putchar() at putchar+0x11f kvprintf() at kvprintf+0x83 vprintf() at vprintf+0x85 printf() at printf+0x67 witness_checkorder() at witness_checkorder+0x773 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x99 uart_cnputc() at uart_cnputc+0x3e cnputc() at cnputc+0x4c cnputs() at cnputs+0x26 putchar() at putchar+0x11f kvprintf() at kvprintf+0x83 vprintf() at vprintf+0x85 printf() at printf+0x67 cpu_reset() at cpu_reset+0x81 kern_reboot() at kern_reboot+0x3a5 --More--^M^Msys_reboot() at sys_reboot+0x42 amd64_syscall() at amd64_syscall+0x39e Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ea3c, rsp = 0x7fffd6d8, rbp = 0x49 --- db> db> show locks exclusive sleep mutex Giant (Giant) r = 0 (0x809bc560) locked @ /usr/src/head/sys/kern/kern_module.c:101 exclusive spin mutex smp rendezvous (smp rendezvous) r = 0 (0x80a08840) locked @ /usr/src/head/sys/kern/kern_shutdown.c:542 db> So the problem is that we are holding smp rendezvous mutex during the cpu_reset(). No mutexes should be obtained after it. However, since cpu_reset() does priting we obtain cnputs_mtx, and later obtain uart_hwmtx. The latter is hardcoded in the subr_witness.c as mutex to obtain before smp rendezvous, this triggers yet another printf from witness, that finally panics due to recursing on cnputs_mtx. -- Totus tuus, Glebius. ___ 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"
