Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 06/14/10 19:14, Doug Barton wrote: Details, I'm running today's -current (r209174) and I've had it up for 4.5 hours already, which is 3 hours longer than I was able to run with anything > 195.22 for months. I've done full "normal" use which includes lots of terminals, tbird, firefox, flash, etc. I may have spoke too soon. About 90 minutes after sending this message, and after 1 hour+ of watching a flash video (a CISSP training course) I got a lockup which required me to power off my laptop. After fsck'ing I got back to my desktop, opened firefox, opened my flash video again, and it locked up almost instantly. This time I got a core though. I'm not sure if this is related to the nvidia driver or not, but there 'tis: Unread portion of the kernel message buffer: panic: mi_switch: switch in a critical section cpuid = 1 panic: bufwrite: buffer is not busy??? cpuid = 1 Uptime: 11m11s #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc05f697f in boot (howto=260) at /usr/local/src/sys/kern/kern_shutdown.c:416 #2 0xc05f6c62 in panic (fmt=Variable "fmt" is not available. ) at /usr/local/src/sys/kern/kern_shutdown.c:590 #3 0xc07f881e in ffs_bufwrite (bp=0xd8d687f8) at /usr/local/src/sys/ufs/ffs/ffs_vfsops.c:1858 #4 0xc066bfa8 in vfs_bio_awrite (bp=0xd8d687f8) at buf.h:386 #5 0xc067592b in vop_stdfsync (ap=0xd8f59c6c) at /usr/local/src/sys/kern/vfs_default.c:650 #6 0xc0588a5c in devfs_fsync (ap=0xd8f59c6c) at /usr/local/src/sys/fs/devfs/devfs_vnops.c:566 #7 0xc088ec95 in VOP_FSYNC_APV (vop=0xc0947080, a=0xd8f59c6c) at vnode_if.c:1267 #8 0xc0686928 in sync_vnode (slp=0xc4f50bf8, bo=0xd8f59cd8, td=0xc5964780) at vnode_if.h:549 #9 0xc0686c73 in sched_sync () at /usr/local/src/sys/kern/vfs_subr.c:1819 #10 0xc05cd378 in fork_exit (callout=0xc0686a00 , arg=0x0, frame=0xd8f59d28) at /usr/local/src/sys/kern/kern_fork.c:843 #11 0xc08568d0 in fork_trampoline () at /usr/local/src/sys/i386/i386/exception.s:270 (kgdb) Full file is core.txt.2 in my freefall home directory. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Mon, Jun 14, 2010 at 2:31 PM, 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...
>>
>> Rene
>> --
>> http://www.rene-ladan.nl/
>>
>> GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6
>> (subkeys.pgp.net)
>
> Content-Description: patch-jhb-current
>> --- 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);
I'll give it a quick shot on my desktop to see how things go.
FWIW, nvidia-driver-195.36.15 has been a rock solid release as well,
with or without the patch.
Cheers,
-Garrett
___
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 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...
>
> Rene
> --
> http://www.rene-ladan.nl/
>
> GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6
> (subkeys.pgp.net)
Content-Description: patch-jhb-current
> --- src/nvidia_subr.c.orig2010-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);
--
christian zander
ch?zan...@nvidia.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: 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 Barton 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"
Re: [CFT] BSDL iconv in base system
Gabor Kovesdan writes: [...] > The rather big patch (42,5M) is available here: > http://www.kovesdan.org/patches/iconv_base_integrate.diff Why not compress it with gzip(1) or xz(1)? > > Any comments, suggestions or bugreports are very welcome. ___ 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 06/14/10 14:30, Rene Ladan wrote:
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 Barton 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...
This worked great, thanks! I'm re-attaching the patch for Alexey's
benefit, just in case.
Details, I'm running today's -current (r209174) and I've had it up for
4.5 hours already, which is 3 hours longer than I was able to run with
anything > 195.22 for months. I've done full "normal" use which includes
lots of terminals, tbird, firefox, flash, etc.
Thanks again,
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
--- 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"
Re: [CFT] BSDL iconv in base system
On Mon, Jun 14, 2010 at 7:13 PM, Gabor Kovesdan wrote: > Hello Folks, > > during the last summer, Google generously founded my Summer of Code project, > which was providing a BSD-licensed iconv implementation for FreeBSD. I'm > proud to announce that the work has been completed and a patch is available > to add it to the base system. > > The results of this work are: > - The Citrus implementation has been ported from NetBSD. > - Some utilities have been added. There is a conversion table generator, > which can compare conversion tables to reference data generated by GNU > libiconv. This helps ensuring conversion compatibility. > - UTF-16 surrogate support and some endianness issues have been fixed. > - The rather chaotic Makefiles to build metadata have been refactored and > cleaned up, now it is easy to read and it is also easier to add support for > new encodings. > - A bunch of new encodings and encoding aliases have been added. > - Support for 1->2, 1->3 and 1->4 mappings, which is needed for > transliterating with flying accents as GNU does, like "u. > - Lots of warnings have been fixed, the major part of the code is now > WARNS=6 clean. > - New section 1 and section 5 manual pages have been added. > - Some GNU-specific calls have been implemented: iconvlist(), iconvctl(), > iconv_canonicalize(), iconv_open_into() > - Support for GNU's //IGNORE suffix has been added. > - The "-" argument for stdin is now recognized in iconv(1) as per POSIX. > - The Big5 conversion module has been fixed. > - The iconv.h header files is supposed to be compatible with the GNU > version, i.e. sources should build with base iconv.h and GNU libiconv. I've > just did a very quick test and it seems ports can safely link to GNU > libiconv, there's no conflict. > - Various cleanups and style(9) fixes. > - A bachelor thesis written in Hungarian language: > http://www.kovesdan.org/files/bsc_iconv.pdf > > The rather big patch (42,5M) is available here: > http://www.kovesdan.org/patches/iconv_base_integrate.diff Over 40 Megabytes?! WOW. Thank you for this incredible amount of work, I know the FreeBSD community will benefit greatly from it. I think this effort deserves some hardcore testing, so now to the FreeBSD community -- I know it will get the attention it deserves :) -Brandon ___ 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"
[CFT] BSDL iconv in base system
Hello Folks, during the last summer, Google generously founded my Summer of Code project, which was providing a BSD-licensed iconv implementation for FreeBSD. I'm proud to announce that the work has been completed and a patch is available to add it to the base system. The results of this work are: - The Citrus implementation has been ported from NetBSD. - Some utilities have been added. There is a conversion table generator, which can compare conversion tables to reference data generated by GNU libiconv. This helps ensuring conversion compatibility. - UTF-16 surrogate support and some endianness issues have been fixed. - The rather chaotic Makefiles to build metadata have been refactored and cleaned up, now it is easy to read and it is also easier to add support for new encodings. - A bunch of new encodings and encoding aliases have been added. - Support for 1->2, 1->3 and 1->4 mappings, which is needed for transliterating with flying accents as GNU does, like "u. - Lots of warnings have been fixed, the major part of the code is now WARNS=6 clean. - New section 1 and section 5 manual pages have been added. - Some GNU-specific calls have been implemented: iconvlist(), iconvctl(), iconv_canonicalize(), iconv_open_into() - Support for GNU's //IGNORE suffix has been added. - The "-" argument for stdin is now recognized in iconv(1) as per POSIX. - The Big5 conversion module has been fixed. - The iconv.h header files is supposed to be compatible with the GNU version, i.e. sources should build with base iconv.h and GNU libiconv. I've just did a very quick test and it seems ports can safely link to GNU libiconv, there's no conflict. - Various cleanups and style(9) fixes. - A bachelor thesis written in Hungarian language: http://www.kovesdan.org/files/bsc_iconv.pdf The rather big patch (42,5M) is available here: http://www.kovesdan.org/patches/iconv_base_integrate.diff Any comments, suggestions or bugreports are very welcome. -- Gabor Kovesdan FreeBSD Volunteer EMAIL:ga...@freebsd.org .:|:.ga...@kovesdan.org WEB:http://people.FreeBSD.org/~gabor .:|:.http://kovesdan.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"
Re: two buildworld problems
2010/6/14 Dag-Erling Smørgrav : > Alexander Best writes: >> .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) && >> exists(/usr/local/bin/gcc44) >> CC = gcc44 >> CXX = g++44 >> CPP = cpp44 >> .endif > > What happens when .CURDIR = /usr/src? i'm now using .if !target(buildworld) && !target(buildkernel) && exists(/usr/local/bin/gcc44) CC = /usr/local/bin/gcc44 CXX = /usr/local/bin/g++44 CPP = /usr/local/bin/cpp44 .endif which works quite well. right now i'm trying to solve a different issue which i outlined in my previous posts. would be nice if somebody could try building world with the settings i have in src.conf (see earlier post). cheers. alex > > DES > -- > Dag-Erling Smørgrav - d...@des.no > -- Alexander Best ___ 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: [patch] Misc warnings found by clang.
On Monday 14 June 2010 23:22:42 Pawel Worach wrote: > Here is a patch that fixes a couple of "warning: format string is not a > string literal" and a couple of unused/never read variable "len" warnings > in lib/libugidfw. I'm not sure about the intention behind the len assignements in libugidfw - might be just a leftover - but if the idea is to teach a model that "we generally care about the return value of snprintf()", a void cast might be the more protable solution. > http://pes.vlakno.cz/~pwo/clang-warn-fix-head.diff Regards, Max ___ 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: Multiple stability issues with r208557, r208809 on amd64
On Tue, Jun 8, 2010 at 5:37 PM, Garrett Cooper wrote: > On Tue, Jun 8, 2010 at 4:59 PM, Xin LI wrote: >> Do you mean between the two revisions or something? I committed >> r208557 which doesn't seem likely to cause any runtime issue; 208809 >> is isp(4) change which is not part of your kernel... >> >> [delp...@delta] /usr/src> svn log -r 208557 >> >> r208557 | delphij | 2010-05-25 15:19:51 -0700 (Tue, 25 May 2010) | 4 lines >> >> Grammar nits. >> >> Submitted by: b. f. >> >> >> [delp...@delta] /usr/src> svn diff -c 208557 >> Index: release/doc/en_US.ISO8859-1/relnotes/article.sgml >> === >> --- release/doc/en_US.ISO8859-1/relnotes/article.sgml (revision 208556) >> +++ release/doc/en_US.ISO8859-1/relnotes/article.sgml (revision 208557) >> @@ -327,7 +327,7 @@ >> based on libarchive, have replaced the GNU >> Binutils versions of these utilities. >> >> - BSD-licensed version of &man.bc.1; and &man.dc.1; has >> + BSD-licensed versions of &man.bc.1; and &man.dc.1; have >> replaced their GNU counterparts. >> >> &man.chflags.1; now supports a >> -v flag for >> @@ -378,7 +378,7 @@ >> disable the use of TCP options. >> >> &man.nc.1;'s -o switch has been deprecated. >> - It will be removed in future release. >> + It will be removed in a future release. >> >> The &man.ping6.8; utility now returns 2 >> when the packet transmission was successful but no responses > > Hi Xin! > > Well, I hope that that wouldn't cause my machine to tank (otherwise it > likes to be a grammar nazi too much :P)... > > What I was trying to identify is a general trend in terms of > evaluation of different versions of CURRENT; somewhere after the code > revision that I noted (r206173), the code appears to be regressing > more and more to the point where CURRENT has become completely > unusable to me in a development scenario, other than just a throwaway > NFS rootfs, s.t. recent code changes need to be thoroughly inspected > and the regression / multiple regressions needs to be root caused > before 9.0-RELEASE, otherwise this will definitely gate multiple > people from upgrading to newer versions of FreeBSD. This probably is > somewhat related to the locking changes, and the fact that several > drivers might have been broken before, but because there were > safeguards around certain sections of code, or because it was > operating at a slow enough rate, the system itself appeared sane and > happy from the outside. But that's probably just useless conjecture > anyhow... > > I realize that CURRENT is supposed to be relatively in flux and it's > primarily for development and evaluation, but I thought that the whole > point of having development branches was to avoid the scenario where > the software itself was completely unusable on dev boxes so that > several folks could work in parallel with [relatively] minor conflicts > between each others' changes. Part of the reason why I've avoided > passing along pkg_install patches -- I want to make sure that I do my > job in testing things to a large degree so I don't break other > peoples' machines unnecessarily (and I'm sure that the bulk majority > of developers on the project feel the same as well). Long story short, I downgraded to 8-STABLE (r209169), and the issue appears to be occurring with ipfw whenever I push through a non-trivial (but not large) number of packets on my bce(4) enabled interface. I'll bring this up with the net@ folks. If this keeps up, I might have to downgrade further down 8-STABLE until I figure out the root cause :(... Thanks, -Garrett ___ 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"
[patch] Misc warnings found by clang.
Here is a patch that fixes a couple of "warning: format string is not a string literal" and a couple of unused/never read variable "len" warnings in lib/libugidfw. http://pes.vlakno.cz/~pwo/clang-warn-fix-head.diff Regards -- Pawel ___ 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: RFC: etcupdate tool in base?
On Thu, Jun 10, 2010 at 10:46 AM, John Baldwin wrote: > I've had several folks ask me recently about importing etcupdate > (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate > tool for updating /etc during upgrades. Do folks have any strong objections > to doing so? More details about how it works and an HTML version of the > manpage can be found at the URL above. Finally got around to looking at this. Some comments: 1. Script doesn't check to see whether or not it has write access (and doesn't catch some errors): $ etcupdate mkdir: /var/db/etcupdate: Permission denied /usr/sbin/etcupdate: cannot create /var/db/etcupdate/log: No such file or directory Eventually it stops though, so maybe it's not really a big issue... 2. Some messages are a bit misleading: $ etcupdate /usr/sbin/etcupdate: cannot create /var/db/etcupdate/log: Permission denied $ ls -l /var/db/etcupdate/log -rw-r--r-- 1 root wheel 0 Jun 14 14:06 /var/db/etcupdate/log $ whoami garrcoop 3. Workflow comments. i. Ok... I know I'm doing a downgrade, but what now? $ sudo etcupdate No previous tree to compare against, a sane comparison is not possible. ii. Did a bit more reading, and I think that `etcupdate build' is what I want... but it wasn't happy when I did that: $ sudo etcupdate build Missing required tarball. usage: etcupdate [-nBF] [-d workdir] [-r | -s source | -t tarball] [-A patterns] [-D destdir] [-I patterns] [-L logfile] [-M options] etcupdate build [-B] [-d workdir] [-s source] [-L logfile] [-M options] etcupdate diff [-d workdir] [-D destdir] [-I patterns] [-L logfile] etcupdate extract [-B] [-d workdir] [-s source | -t tarball] [-L logfile] [-M options] etcupdate resolve [-d workdir] [-D destdir] [-L logfile] etcupdate status [-d workdir] So uh... ok? Manpage and usage were a bit confusing (but not too bad). After I fixed my arguments, here's what I came up with: $ sudo etcupdate build -s /data/scratch/src/stable/8/ /root/etcupdate-stable8.tbz $ sudo etcupdate extract -t /root/etcupdate-stable8.tbz $ Wait -- what happened...? What's going on isn't overly apparent from running extract. It's nice having clean utilities, but I'm not used to the etcupdate workflow, so having some verbosity would be helpful :D. Thanks, -Garrett ___ 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: two buildworld problems
Alexander Best writes: > .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) && > exists(/usr/local/bin/gcc44) > CC = gcc44 > CXX = g++44 > CPP = cpp44 > .endif What happens when .CURDIR = /usr/src? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Dell bluetooth wireless card
On Mon, 14 Jun 2010 20:31:52 +0200 Tobias Lott wrote: > On Mon, 14 Jun 2010 15:25:14 +0200 > Raoul wrote: >> >> >> Hello all, >> >> Please, can you tell me what to do to make my bluetooth >> card detected on current. >> >> It is a Dell Wireless 370 Bluetooth Mini-card, running on a Dell >> E6400 laptop. OS: FBSD current r208665. >> Thanks in advance. >> >> Raoul >> rm...@free.fr > kldload ng_ubt > Which is actually panic-ing my Inspiron 9200 alas, it is already loaded! and /etc/rc.bluetooth start ubt0 gives: ngctl: send msg: No such file or directory the card is not detected at all (no mention in dmesg). best regards Raoul rm...@free.fr ___ 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: two buildworld problems
On Mon, Jun 14, 2010 at 4:17 PM, Anonymous wrote: > Alexander Best writes: > >> On Mon, Jun 14, 2010 at 12:05 PM, Roman Divacky wrote: >>> On Sun, Jun 13, 2010 at 10:28:23PM +0200, Alexander Best wrote: hi there. i'm experiencing two problems during buildworld. i'm not sure if these are the result of me doing weird stuff or a problem in the src structure: 1. i have the following in my make.conf: .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) && exists(/usr/local/bin/gcc44) CC = gcc44 CXX = g++44 CPP = cpp44 .endif >>> >>> you may want to reverse the condition, ie. >>> >>> .if !empty(.CURDIR:M/usr/ports/*) >> >> yeah i had something like that in my make.conf beforehand. the problem >> was however that this would only use gcc44 when 'make' was run in the >> ports directory. however i want make to ALWAYS use gcc44 apart from >> /usr/src. > > It may be easier to make gcc44 symlinks for cc/c++/gcc/g++ in > e.g. HOME/.bin and add it to PATH before /usr/bin[1]. make buildworld > overrides its own PATH and shouldn't be affected but pretty much > anything else will use gcc44, not only make(1) targets. > > You can create basegcc/baseg++ symlinks then for things that don't > compile by gcc44 but in case of portmaster you'd have to teach it > respect user-defined PATH in order for CC=basegcc in make.conf to work. > > [1] *after* ccache if you have it installed, e.g. > PATH=$LOCALBASE/libexec/ccache:$HOME/.bin:...:/usr/bin:... thanks for hint. right now my main problem is that i'm not able to sucessfull do 'buildworld' with CC/CXX/CPP set in src.conf. this should be reproducable quite easy by either adding: CC=gcc CXX=g++ CPP=cpp to src.conf or CC=clang CXX=clang++ CPP=clang i posted the error output beforehand. this problems has nothing to do with anything in make.conf since i commented out every gcc44 stuff and even CFLAGS and so forth. for me the only way to successfully do 'buildworld' is to make sure CC/CXX/CPP aren't set in src.conf or as envars. cheers. alex > -- Alexander Best ___ 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: ZFS LORs: syncer vs. zfs and devfs vs. zfs
On Mon, Jun 14, 2010 at 05:00:00PM +, Bruce Cran wrote: > I got the attached ZFS LORs when building ports on a new install of > 9.0-CURRENT-20100610-JPSNAP. I know there have been some ZFS checkins in the > last few days so I don't know if they've already been fixed? The LORs are not specific to ZFS, are caused by VFS layer, and I my recollection is that they are false positives. > > -- > Bruce > > > lock order reversal: > 1st 0xff000a846458 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1201 > 2nd 0xff000a846638 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1250 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > __lockmgr_args() at __lockmgr_args+0xd11 > vop_stdlock() at vop_stdlock+0x39 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x47 > ffs_flushfiles() at ffs_flushfiles+0xb5 > ffs_unmount() at ffs_unmount+0x70 > dounmount() at dounmount+0x2e6 > unmount() at unmount+0x27e > syscallenter() at syscallenter+0xf0 > syscall() at syscall+0x4c > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (22, FreeBSD ELF64, unmount), rip = 0x8006a23ec, rsp = > 0x7fffe3c8, rbp = 0x800c09bb0 --- > > lock order reversal: > 1st 0xff000a857bd8 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1713 > 2nd 0xff0127b389f8 zfs (zfs) @ > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:152 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > __lockmgr_args() at __lockmgr_args+0xd11 > vop_stdlock() at vop_stdlock+0x39 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x47 > zfs_znode_cache_constructor() at zfs_znode_cache_constructor+0x57 > zfs_znode_alloc() at zfs_znode_alloc+0x39 > zfs_zget() at zfs_zget+0x2a7 > zfs_get_data() at zfs_get_data+0x4d > zil_commit() at zil_commit+0x532 > zfs_sync() at zfs_sync+0xa6 > sync_fsync() at sync_fsync+0x13a > sync_vnode() at sync_vnode+0x157 > sched_sync() at sched_sync+0x1d1 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff8323b0ad30, rbp = 0 --- > ___ > 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" pgpiy66KDIttf.pgp Description: PGP signature
Re: Dell bluetooth wireless card
On Mon, 14 Jun 2010 15:25:14 +0200 Raoul wrote: > > > Hello all, > > Please, can you tell me what to do to make my bluetooth > card detected on current. > > It is a Dell Wireless 370 Bluetooth Mini-card, running on a Dell > E6400 laptop. OS: FBSD current r208665. > Thanks in advance. > > Raoul > rm...@free.fr > ___ > 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 ng_ubt Which is actually panic-ing my Inspiron 9200 ___ 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"
[head tinderbox] failure on sparc64/sun4v
TB --- 2010-06-14 17:15:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-14 17:15:01 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-06-14 17:15:01 - cleaning the object tree TB --- 2010-06-14 17:15:10 - cvsupping the source tree TB --- 2010-06-14 17:15:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-06-14 17:15:51 - building world TB --- 2010-06-14 17:15:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-14 17:15:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-14 17:15:51 - TARGET=sun4v TB --- 2010-06-14 17:15:51 - TARGET_ARCH=sparc64 TB --- 2010-06-14 17:15:51 - TZ=UTC TB --- 2010-06-14 17:15:51 - __MAKE_CONF=/dev/null TB --- 2010-06-14 17:15:51 - cd /src TB --- 2010-06-14 17:15:51 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 14 17:15:51 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/config.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/devices.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/dhcp.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/disks.c cc1: warnings being treated as errors /src/usr.sbin/sysinstall/disks.c: In function 'diskPartitionWrite': /src/usr.sbin/sysinstall/disks.c:893: warning: implicit declaration of function 'bootalloc' /src/usr.sbin/sysinstall/disks.c:893: warning: assignment makes pointer from integer without a cast *** Error code 1 Stop in /src/usr.sbin/sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-14 18:13:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-14 18:13:06 - ERROR: failed to build world TB --- 2010-06-14 18:13:06 - 2760.70 user 553.52 system 3484.88 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full ___ 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"
[head tinderbox] failure on powerpc/powerpc
TB --- 2010-06-14 16:34:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-14 16:34:51 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-06-14 16:34:51 - cleaning the object tree TB --- 2010-06-14 16:35:02 - cvsupping the source tree TB --- 2010-06-14 16:35:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-06-14 16:40:21 - building world TB --- 2010-06-14 16:40:21 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-14 16:40:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-14 16:40:21 - TARGET=powerpc TB --- 2010-06-14 16:40:21 - TARGET_ARCH=powerpc TB --- 2010-06-14 16:40:21 - TZ=UTC TB --- 2010-06-14 16:40:21 - __MAKE_CONF=/dev/null TB --- 2010-06-14 16:40:21 - cd /src TB --- 2010-06-14 16:40:21 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 14 16:40:21 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] echo watchdogd: /obj/powerpc/src/tmp/usr/lib/libc.a /obj/powerpc/src/tmp/usr/lib/libm.a /obj/powerpc/src/tmp/usr/lib/libutil.a >> .depend ===> usr.sbin/wlandebug (depend) rm -f .depend mkdep -f .depend -a /src/usr.sbin/wlandebug/wlandebug.c echo wlandebug: /obj/powerpc/src/tmp/usr/lib/libc.a >> .depend ===> usr.sbin/wpa (depend) ===> usr.sbin/wpa/wpa_supplicant (depend) make: don't know how to make l2_packet_freebsd.c. Stop *** Error code 2 Stop in /src/usr.sbin/wpa. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-14 17:43:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-14 17:43:31 - ERROR: failed to build world TB --- 2010-06-14 17:43:31 - 3023.17 user 531.48 system 4119.47 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ 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"
[head tinderbox] failure on sparc64/sparc64
TB --- 2010-06-14 16:41:38 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-14 16:41:38 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-06-14 16:41:38 - cleaning the object tree TB --- 2010-06-14 16:41:47 - cvsupping the source tree TB --- 2010-06-14 16:41:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-06-14 16:42:44 - building world TB --- 2010-06-14 16:42:44 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-14 16:42:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-14 16:42:44 - TARGET=sparc64 TB --- 2010-06-14 16:42:44 - TARGET_ARCH=sparc64 TB --- 2010-06-14 16:42:44 - TZ=UTC TB --- 2010-06-14 16:42:44 - __MAKE_CONF=/dev/null TB --- 2010-06-14 16:42:44 - cd /src TB --- 2010-06-14 16:42:44 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 14 16:42:45 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/config.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/devices.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/dhcp.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/disks.c cc1: warnings being treated as errors /src/usr.sbin/sysinstall/disks.c: In function 'diskPartitionWrite': /src/usr.sbin/sysinstall/disks.c:893: warning: implicit declaration of function 'bootalloc' /src/usr.sbin/sysinstall/disks.c:893: warning: assignment makes pointer from integer without a cast *** Error code 1 Stop in /src/usr.sbin/sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-14 17:43:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-14 17:43:21 - ERROR: failed to build world TB --- 2010-06-14 17:43:21 - 2732.12 user 587.49 system 3703.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ 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: Cleanup for cryptographic algorithms vs. compiler optimizations
On Friday 11 June 2010 23:31:57 Dag-Erling Smørgrav wrote: > Tijl Coosemans writes: >> Dag-Erling Smørgrav writes: >>> #define FORCE_ASSIGN(type, var, value) \ >>> *(volatile type *)&(var) = (value) >> memset can be optimised away as well. The only way is to declare >> those variables volatile. > > Assigning through a volatile pointer, as in FORCE_ASSIGN(), also > works, even if the variable itself is not volatile. Just thought of problem with this macro when var is a pointer. Then volatile applies to the referenced memory and not the variable. So you should move the volatile keyword, like so: #define FORCE_ASSIGN(type, var, value) \ *(type volatile *)&(var) = (value) And if you can use GNU extensions this can be simplified to: #define FORCE_ASSIGN(var, value) \ *(typeof(var) volatile *)&(var) = (value) ___ 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"
ZFS LORs: syncer vs. zfs and devfs vs. zfs
I got the attached ZFS LORs when building ports on a new install of 9.0-CURRENT-20100610-JPSNAP. I know there have been some ZFS checkins in the last few days so I don't know if they've already been fixed? -- Bruce lock order reversal: 1st 0xff000a846458 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1201 2nd 0xff000a846638 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1250 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xd11 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 ffs_flushfiles() at ffs_flushfiles+0xb5 ffs_unmount() at ffs_unmount+0x70 dounmount() at dounmount+0x2e6 unmount() at unmount+0x27e syscallenter() at syscallenter+0xf0 syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (22, FreeBSD ELF64, unmount), rip = 0x8006a23ec, rsp = 0x7fffe3c8, rbp = 0x800c09bb0 --- lock order reversal: 1st 0xff000a857bd8 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1713 2nd 0xff0127b389f8 zfs (zfs) @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:152 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xd11 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 zfs_znode_cache_constructor() at zfs_znode_cache_constructor+0x57 zfs_znode_alloc() at zfs_znode_alloc+0x39 zfs_zget() at zfs_zget+0x2a7 zfs_get_data() at zfs_get_data+0x4d zil_commit() at zil_commit+0x532 zfs_sync() at zfs_sync+0xa6 sync_fsync() at sync_fsync+0x13a sync_vnode() at sync_vnode+0x157 sched_sync() at sched_sync+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8323b0ad30, rbp = 0 --- ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
AK-san, PseudoCylon wrote: > - Original Message > >> From: Ganbold >> To: PseudoCylon >> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu >> Sent: Thu, June 10, 2010 10:53:30 AM >> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >> >> It seems like it is running without any problem so far, no more adsl >> modem problem. >> I can see arp packets in wlan0 interface as well as in macbook. >> I will continue testing and let you know if there comes any problem. >> >> thanks again, >> >> Ganbold >> > > Hello, > > Glad to hear. It was an encryption problem. A client was dropping packets.. > > Please let me know if you find another bug. (Hope there won't be) > Well, looks like I was too fast :( It seems like client is not receiving any arp packets when rspro doesn't first initiate ping (maybe arp request) to client. If I first ping to client from rspro, later on arp packets can be seen on client. When I ping from rspro to client, response is very different: # arp -a ? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] ? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] ? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] ? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1200 seconds [ethernet] ? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 824 seconds [ethernet] # ping 192.168.1.50 PING 192.168.1.50 (192.168.1.50): 56 data bytes 64 bytes from 192.168.1.50: icmp_seq=0 ttl=64 time=2.694 ms 64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=302.177 ms 64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1.041 ms 64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=5234.417 ms 64 bytes from 192.168.1.50: icmp_seq=5 ttl=64 time=4225.060 ms 64 bytes from 192.168.1.50: icmp_seq=6 ttl=64 time=3214.908 ms 64 bytes from 192.168.1.50: icmp_seq=7 ttl=64 time=2207.241 ms 64 bytes from 192.168.1.50: icmp_seq=8 ttl=64 time=1197.061 ms 64 bytes from 192.168.1.50: icmp_seq=9 ttl=64 time=186.833 ms ^C --- 192.168.1.50 ping statistics --- 11 packets transmitted, 9 packets received, 18.2% packet loss round-trip min/avg/max/stddev = 1.041/1841.270/5234.417/1870.962 ms # arp -a ? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] ? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] ? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] ? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1183 seconds [ethernet] ? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 805 seconds [ethernet] ? (192.168.1.50) at 00:26:bb:17:f6:61 on arge0 expires in 1186 seconds [ethernet] # ping 192.168.1.50 PING 192.168.1.50 (192.168.1.50): 56 data bytes 64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1590.035 ms 64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=580.201 ms 64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=528.019 ms ^C --- 192.168.1.50 ping statistics --- 5 packets transmitted, 3 packets received, 40.0% packet loss round-trip min/avg/max/stddev = 528.019/899.418/1590.035/488.804 ms Any idea? thanks, Ganbold > Thank you for testing > > AK > > > > > -- Computer programmers never die, they just get lost in the processing. ___ 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 Mon, Jun 14, 2010 at 05:48:55AM -0700, 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().
>
That's all I did. The next 256.xx build will pick these changes up.
--
christian zander
ch?zan...@nvidia.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"
[head tinderbox] failure on arm/arm
TB --- 2010-06-14 13:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-14 13:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2010-06-14 13:50:00 - cleaning the object tree TB --- 2010-06-14 13:50:16 - cvsupping the source tree TB --- 2010-06-14 13:50:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2010-06-14 13:54:57 - building world TB --- 2010-06-14 13:54:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-14 13:54:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-14 13:54:57 - TARGET=arm TB --- 2010-06-14 13:54:57 - TARGET_ARCH=arm TB --- 2010-06-14 13:54:57 - TZ=UTC TB --- 2010-06-14 13:54:57 - __MAKE_CONF=/dev/null TB --- 2010-06-14 13:54:57 - cd /src TB --- 2010-06-14 13:54:57 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 14 13:54:58 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] mkdep -f .depend -a-I/src/sys/boot/uboot/lib/../../../../lib/libstand/ -I/src/sys/boot/uboot/lib/../../../../sys/contrib/libfdt/ -I/src/sys/boot/uboot/lib/../../common -I/src/sys/boot/uboot/lib/../../.. -I. /src/sys/boot/uboot/lib/devicename.c /src/sys/boot/uboot/lib/elf_freebsd.c /src/sys/boot/uboot/lib/console.c /src/sys/boot/uboot/lib/copy.c /src/sys/boot/uboot/lib/disk.c /src/sys/boot/uboot/lib/module.c /src/sys/boot/uboot/lib/net.c /src/sys/boot/uboot/lib/reboot.c /src/sys/boot/uboot/lib/time.c /src/sys/boot/uboot/lib/glue.c ===> sys/boot/arm (depend) ===> sys/boot/arm/uboot (depend) sh /src/sys/boot/arm/uboot/../../common/newvers.sh /src/sys/boot/arm/uboot/version "U-Boot loader" arm rm -f .depend mkdep -f .depend -a-DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/arm/uboot/../../ficl -I/src/sys/boot/arm/uboot/../../ficl/arm -I/src/sys/boot/arm/uboot/../../common -I. -I/src/sys/boot/arm/uboot/../../uboot/common -I/src/sys/boot/arm/uboot/../../uboot/lib -I/obj/arm/src/sys/boot/arm/uboot/../../uboot/lib -I/src/sys/boot/arm/uboot/../../../../lib/libstand/ /src/sys/boot/arm/uboot/start.S /src/sys/boot/arm/uboot/conf.c vers.c /src/sys/boot/arm/uboot/../../common/boot.c /src/sys/boot/arm/uboot/../../common/commands.c /src/sys/boot/arm/uboot/../../common/console.c /src/sys/boot/arm/uboot/../../common/devopen.c /src/sys/boot/arm/uboot/../../common/interp.c /src/sys/boot/arm/uboot/../../common/interp_backslash.c /src/sys/boot/arm/uboot/../../common/interp_parse.c /src/sys/boot/arm/uboot/../../common/ls.c /src/sys/boot/arm/uboot/../../common/misc.c /src/sys/boot/arm/uboot/../../common/module.c /src/sys/boot/ar! m/uboot/../../common/panic.c /src/sys/boot/arm/uboot/../../common/load_elf32.c /src/sys/boot/arm/uboot/../../common/reloc_elf32.c /src/sys/boot/arm/uboot/../../common/dev_net.c /src/sys/boot/arm/uboot/../../common/interp_forth.c /src/sys/boot/arm/uboot/../../uboot/common/main.c /src/sys/boot/arm/uboot/../../uboot/common/metadata.c /src/sys/boot/arm/uboot/../../uboot/common/metadata.c:40:30: error: machine/bootinfo.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/sys/boot/arm/uboot. *** Error code 1 Stop in /src/sys/boot/arm. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-14 14:22:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-14 14:22:40 - ERROR: failed to build world TB --- 2010-06-14 14:22:40 - 1248.82 user 343.84 system 1959.61 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ 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: two buildworld problems
Alexander Best writes: > On Mon, Jun 14, 2010 at 12:05 PM, Roman Divacky wrote: >> On Sun, Jun 13, 2010 at 10:28:23PM +0200, Alexander Best wrote: >>> hi there. i'm experiencing two problems during buildworld. i'm not >>> sure if these are the result of me doing weird stuff or a problem in >>> the src structure: >>> >>> 1. i have the following in my make.conf: >>> >>> .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) && >>> exists(/usr/local/bin/gcc44) >>> CC = gcc44 >>> CXX = g++44 >>> CPP = cpp44 >>> .endif >> >> you may want to reverse the condition, ie. >> >> .if !empty(.CURDIR:M/usr/ports/*) > > yeah i had something like that in my make.conf beforehand. the problem > was however that this would only use gcc44 when 'make' was run in the > ports directory. however i want make to ALWAYS use gcc44 apart from > /usr/src. It may be easier to make gcc44 symlinks for cc/c++/gcc/g++ in e.g. HOME/.bin and add it to PATH before /usr/bin[1]. make buildworld overrides its own PATH and shouldn't be affected but pretty much anything else will use gcc44, not only make(1) targets. You can create basegcc/baseg++ symlinks then for things that don't compile by gcc44 but in case of portmaster you'd have to teach it respect user-defined PATH in order for CC=basegcc in make.conf to work. [1] *after* ccache if you have it installed, e.g. PATH=$LOCALBASE/libexec/ccache:$HOME/.bin:...:/usr/bin:... ___ 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 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 Barton 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().
--
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"
Dell bluetooth wireless card
Hello all, Please, can you tell me what to do to make my bluetooth card detected on current. It is a Dell Wireless 370 Bluetooth Mini-card, running on a Dell E6400 laptop. OS: FBSD current r208665. Thanks in advance. Raoul rm...@free.fr ___ 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: wpa_supplicant update? CTRL-EVENT-SCAN-RESULTS
On 14 Jun 2010, at 03:11, Ulrich Spörlein wrote: > On Sun, 13.06.2010 at 12:03:05 -0700, Rui Paulo wrote: >> On 13 Jun 2010, at 04:23, Jakub Lach wrote: >> >>> >>> Hello. >>> >>> Is update of wpa_supplicant planned? >>> >>> Current version in STABLE as well as CURRENT >>> (v0.6.8) is suffering from CTRL-EVENT-SCAN-RESULTS >>> log spam. >>> >>> If it's the same problem, looks like it's fixed in v0.6.10 >>> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539915 >> >> I'll likely work on this soon. > > Great news, > > btw, are you aware of WPA problems with the iwi(4) driver? I had no > problems and good performance early this year, but since March or so, > the driver gets stuck regularly. For example I can no longer boot up > with if_iwi loaded and the WPA bits in rc.conf, as the immediate startup > of wpa_supplicant will somehow wedge things (I have a couple of traces > for this): ifconfig wlan0 down will get stuck, killing wpa_supplicant is > no longer possible, etc. > > What works for me (please don't laugh): > - boot up without if_iwi loaded > - disable wlan radio using hotkey > - load if_iwi, devd will automatically start wpa_supplicant > - wpa_supplicant will eventually (1-2 min) associate with my ath(4) > based AP > - turn on radio per hotkey > - check ifconfig wlan0 to see if everything is alright > - ifconfig lagg0 laggport wlan0 for wired/wireless roaming. > > Here's a trace of when 'ifconfig wlan0 down' was stuck, too bad the > trace for wpa_supplicant doesn't show up in the textdump > > Tracing command ifconfig pid 1894 tid 100121 td 0xc4d76c30 > sched_switch(c4d76c30,0,104,191,3593fa53,...) at sched_switch+0x2fc > mi_switch(104,0,c092b242,1eb,5c,...) at mi_switch+0x200 > sleepq_switch(c4d76c30,0,c092b242,260,0,...) at sleepq_switch+0x15f > sleepq_wait(c41862d8,5c,c091c518,0,0,...) at sleepq_wait+0x63 > _sleep(c41862d8,c3f02494,5c,c091c518,0,...) at _sleep+0x365 > taskqueue_drain(c3f02480,c41862d8,48d,c0935b10,fb51cab8,...) at > taskqueue_drain+0xf5 > ieee80211_vap_detach(c4186000,fb51cae4,0,fb51cacc,c06bac77,...) at > ieee80211_vap_detach+0x78 > iwi_vap_delete(c4186000,fb51cae4,c0694457,c413f000,c413f000,...) at > iwi_vap_delete+0x12 > wlan_clone_destroy(c413f000,c413f000,c413f000,c413f000,fb51cb10,...) at > wlan_clone_destroy+0x17 > ifc_simple_destroy(c099c260,c413f000,c09362cc,105,c099c290,...) at > ifc_simple_destroy+0x27 > if_clone_destroyif(c099c260,c413f000,c09362cc,e0,c42225c0,...) at > if_clone_destroyif+0x12e > if_clone_destroy(c42225c0,19c,c0954c7d,c091ead3,3,...) at > if_clone_destroy+0xa2 > ifioctl(c3c4f670,80206979,c42225c0,c4d76c30,c4415100,...) at ifioctl+0x476 > soo_ioctl(c44433b8,80206979,c42225c0,c44b2700,c4d76c30,...) at soo_ioctl+0x40f > kern_ioctl(c4d76c30,3,80206979,c42225c0,6230b0,...) at kern_ioctl+0x1fd > ioctl(c4d76c30,fb51ccf8,c09615aa,c09492c0,c4d6d2a8,...) at ioctl+0x134 > syscall(fb51cd38) at syscall+0x220 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281cbb13, esp = 0xbfbfe44c, > ebp = 0xbfbfe468 --- Please update your sources. I think this was fixed a while ago. -- 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: two buildworld problems
On Mon, Jun 14, 2010 at 12:05 PM, Roman Divacky wrote: > On Sun, Jun 13, 2010 at 10:28:23PM +0200, Alexander Best wrote: >> hi there. i'm experiencing two problems during buildworld. i'm not >> sure if these are the result of me doing weird stuff or a problem in >> the src structure: >> >> 1. i have the following in my make.conf: >> >> .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) && >> exists(/usr/local/bin/gcc44) >> CC = gcc44 >> CXX = g++44 >> CPP = cpp44 >> .endif > > you may want to reverse the condition, ie. > > .if !empty(.CURDIR:M/usr/ports/*) yeah i had something like that in my make.conf beforehand. the problem was however that this would only use gcc44 when 'make' was run in the ports directory. however i want make to ALWAYS use gcc44 apart from /usr/src. I think this solution works quite well now: .if !target(buildworld) && !target(buildkernel) && exists(/usr/local/bin/gcc44) CC = /usr/local/bin/gcc44 CXX = /usr/local/bin/g++44 CPP = /usr/local/bin/cpp44 .endif so here're the results: 1. (buildworld without CC/CXX/CPP set in src.conf) => suceeds. 2. (buildworld with CC=gcc CXX=g++ CPP=cpp in src.conf) mkdep -f .depend -a-I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S^M cc -O2 -pipe -fno-strict-aliasing -funroll-loops -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari cc -O2 -pipe -fno-strict-aliasing -funroll-loops -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari cc -O2 -pipe -fno-strict-aliasing -funroll-loops -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari cc -O2 -pipe -fno-strict-aliasing -funroll-loops -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari /usr/src/lib/csu/i386-elf/crt1_s.S: Assembler messages:^M /usr/src/lib/csu/i386-elf/crt1_s.S:34: Error: suffix or operands invalid for `push'^M /usr/src/lib/csu/i386-elf/crt1_s.S:37: Error: `8(%ebp)' is not a valid 64 bit base/index expression^M /usr/src/lib/csu/i386-elf/crt1_s.S:38: Error: suffix or operands invalid for `push'^M /usr/src/lib/csu/i386-elf/crt1_s.S:39: Error: `4(%ebp)' is not a valid 64 bit base/index expression^M /usr/src/lib/csu/i386-elf/crt1_s.S:40: Error: suffix or operands invalid for `push'^M *** Error code 1^M ^M Stop in /usr/src/lib/csu/i386-elf.^M *** Error code 1^M ^M Stop in /usr/src.^M *** Error code 1^M ^M Stop in /usr/src.^M *** Error code 1^M ^M Stop in /usr/src.^M *** Error code 1^M ^M Stop in /usr/src.^M ^[[1m^[[7m%^[[27m^[[1m^[[m 3. (buildworld with CC=clang CXX=clang++ CPP=clang in src.conf) clang: warning: argument unused during compilation: '-funroll-loops'^M clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLF clang: warning: argument unused during compilation: '-funroll-loops'^M ^[[1m/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/rc5/rc5_skey.c:122:11: ^[[0m^[[0;1;31merror: ^[[0m^[[1munsupported inline asm: input with type 'unsigned long' matching output with type 'unsigned int'^M ^[[0mA=S[ii]=ROTATE_l32(k,3);^M ^[[0;1;32m^~~^M ^[[0m/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/rc5/rc5_skey.c:122:22: note: instantiated from:^M A=S[ii]=ROTATE_l32(k,3);^M ^[[0;1;32m ^^M ^[[0m^[[1m/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/rc5/rc5_skey.c:125:11: ^[[0m^[[0;1;31merror: ^[[0m^[[1munsupported inline asm: input with type 'unsigned long' matching output with type 'unsigned int'^M ^[[0mB=L[jj]=ROTATE_l32(k,m);^M ^[[0;1;32m^~~^M ^[[0m/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/rc5/rc5_skey.c:125:22: note: instantiated from:^M B=L[jj]=ROTATE_l32(k,m);^M ^[[0;1;32m ^^M ^[[0m2 errors generated.^M *** Error code 1^M ^M Stop in /usr/src/secure/lib/libcrypto.^M *** Error code 1^M ^M Stop in /usr/src.^M *** Error code 1^M ^M Stop in /usr/src.^M *** Error code 1^M ^M Stop in /usr/src.^M *** Error code 1^M ^M Stop in /us
Re: wpa_supplicant update? CTRL-EVENT-SCAN-RESULTS
On Sun, 13.06.2010 at 12:03:05 -0700, Rui Paulo wrote: > On 13 Jun 2010, at 04:23, Jakub Lach wrote: > > > > > Hello. > > > > Is update of wpa_supplicant planned? > > > > Current version in STABLE as well as CURRENT > > (v0.6.8) is suffering from CTRL-EVENT-SCAN-RESULTS > > log spam. > > > > If it's the same problem, looks like it's fixed in v0.6.10 > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539915 > > I'll likely work on this soon. Great news, btw, are you aware of WPA problems with the iwi(4) driver? I had no problems and good performance early this year, but since March or so, the driver gets stuck regularly. For example I can no longer boot up with if_iwi loaded and the WPA bits in rc.conf, as the immediate startup of wpa_supplicant will somehow wedge things (I have a couple of traces for this): ifconfig wlan0 down will get stuck, killing wpa_supplicant is no longer possible, etc. What works for me (please don't laugh): - boot up without if_iwi loaded - disable wlan radio using hotkey - load if_iwi, devd will automatically start wpa_supplicant - wpa_supplicant will eventually (1-2 min) associate with my ath(4) based AP - turn on radio per hotkey - check ifconfig wlan0 to see if everything is alright - ifconfig lagg0 laggport wlan0 for wired/wireless roaming. Here's a trace of when 'ifconfig wlan0 down' was stuck, too bad the trace for wpa_supplicant doesn't show up in the textdump Tracing command ifconfig pid 1894 tid 100121 td 0xc4d76c30 sched_switch(c4d76c30,0,104,191,3593fa53,...) at sched_switch+0x2fc mi_switch(104,0,c092b242,1eb,5c,...) at mi_switch+0x200 sleepq_switch(c4d76c30,0,c092b242,260,0,...) at sleepq_switch+0x15f sleepq_wait(c41862d8,5c,c091c518,0,0,...) at sleepq_wait+0x63 _sleep(c41862d8,c3f02494,5c,c091c518,0,...) at _sleep+0x365 taskqueue_drain(c3f02480,c41862d8,48d,c0935b10,fb51cab8,...) at taskqueue_drain+0xf5 ieee80211_vap_detach(c4186000,fb51cae4,0,fb51cacc,c06bac77,...) at ieee80211_vap_detach+0x78 iwi_vap_delete(c4186000,fb51cae4,c0694457,c413f000,c413f000,...) at iwi_vap_delete+0x12 wlan_clone_destroy(c413f000,c413f000,c413f000,c413f000,fb51cb10,...) at wlan_clone_destroy+0x17 ifc_simple_destroy(c099c260,c413f000,c09362cc,105,c099c290,...) at ifc_simple_destroy+0x27 if_clone_destroyif(c099c260,c413f000,c09362cc,e0,c42225c0,...) at if_clone_destroyif+0x12e if_clone_destroy(c42225c0,19c,c0954c7d,c091ead3,3,...) at if_clone_destroy+0xa2 ifioctl(c3c4f670,80206979,c42225c0,c4d76c30,c4415100,...) at ifioctl+0x476 soo_ioctl(c44433b8,80206979,c42225c0,c44b2700,c4d76c30,...) at soo_ioctl+0x40f kern_ioctl(c4d76c30,3,80206979,c42225c0,6230b0,...) at kern_ioctl+0x1fd ioctl(c4d76c30,fb51ccf8,c09615aa,c09492c0,c4d6d2a8,...) at ioctl+0x134 syscall(fb51cd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281cbb13, esp = 0xbfbfe44c, ebp = 0xbfbfe468 --- 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: two buildworld problems
On Sun, Jun 13, 2010 at 10:28:23PM +0200, Alexander Best wrote: > hi there. i'm experiencing two problems during buildworld. i'm not > sure if these are the result of me doing weird stuff or a problem in > the src structure: > > 1. i have the following in my make.conf: > > .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) && > exists(/usr/local/bin/gcc44) > CC = gcc44 > CXX = g++44 > CPP = cpp44 > .endif you may want to reverse the condition, ie. .if !empty(.CURDIR:M/usr/ports/*) ___ 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: two buildworld problems
On Mon, Jun 14, 2010 at 6:58 AM, Ed Schouten wrote: > * Alexander Best wrote: >> CC=gcc44 >> CXX=g++44 >> CPP=cpp44 > > As I mentioned before, "gcc44" and "/usr/local/bin/gcc44" are spelled > differently. yes, but the point is: i don't want gcc44 to be used at all during buildworld/buildkernel. so even if buildworld/buildkernel are chaging $PATH it shouldn't cause any problems because both targets should never use gcc44. i changed the values of CC/CXX/CPP like you suggested however because somewhere else (apart from /usr/src) $PATH might get changed somehow. what i'm now trying to do in order to having everything being built with gcc44 expect buildworld and buildkernel is this (in make.conf): .if !target(buildworld) && !target(buildkernel) && exists(/usr/local/bin/gcc44) CC = /usr/local/bin/gcc44 CXX = /usr/local/bin/g++44 CPP = /usr/local/bin/cpp44 .endif i'm just running buildworld to see if it works. cheers. alex btw: making 'buildworld' with clang also failed when CXX was set to 'clang++' (CCC/CPP remained being set to 'clang'). here's the output: clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLF clang: warning: argument unused during compilation: '-funroll-loops'^M clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLF clang: warning: argument unused during compilation: '-funroll-loops'^M ^[[1m/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/rc5/rc5_skey.c:122:11: ^[[0m^[[0;1;31merror: ^[[0m^[[1munsupported inline asm: input with type 'unsigned long' matching output with type 'unsigned int'^M ^[[0mA=S[ii]=ROTATE_l32(k,3);^M ^[[0;1;32m^~~^M ^[[0m/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/rc5/rc5_skey.c:122:22: note: instantiated from:^M A=S[ii]=ROTATE_l32(k,3);^M ^[[0;1;32m ^^M ^[[0m^[[1m/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/rc5/rc5_skey.c:125:11: ^[[0m^[[0;1;31merror: ^[[0m^[[1munsupported inline asm: input with type 'unsigned long' matching output with type 'unsigned int'^M ^[[0mB=L[jj]=ROTATE_l32(k,m);^M ^[[0;1;32m^~~^M ^[[0m/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/rc5/rc5_skey.c:125:22: note: instantiated from:^M B=L[jj]=ROTATE_l32(k,m);^M ^[[0;1;32m ^^M ^[[0m2 errors generated.^M *** Error code 1^M ^M Stop in /usr/src/secure/lib/libcrypto.^M *** Error code 1^M ^M Stop in /usr/src.^M *** Error code 1^M ^M Stop in /usr/src.^M *** Error code 1^M ^M Stop in /usr/src.^M *** Error code 1^M ^M Stop in /usr/src.^M > > -- > Ed Schouten > WWW: http://80386.nl/ > -- Alexander Best ___ 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: Cleanup for cryptographic algorithms vs. compiler optimizations
Bernd Walter writes: > Dag-Erling Smørgrav writes: > > Those are freestanding environments, where printf() and puts() don't > > exist as far as the C standard is concerned. > Most controller environments have some kind of libc. They are still freestanding environments. Can we agree not to discuss this any further until you've read chapters 1 through 5 of the C standard? > Anyway - printf=>puts isn't scarying as such, it is more that this > might happen in other cases as well. Yes, it might, and if you run into trouble because of it, it means you've broken the rules somewhere. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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"
