Re: $PATH and buildworld not getting along
On Fri, 18.02.2011 at 16:36:13 +, Alexander Best wrote: On Fri Feb 18 11, Ulrich Spörlein wrote: On Tue, 15.02.2011 at 21:10:29 +, Alexander Best wrote: hi there, i've run into an issue where $PATH doesn't get discarded during buildworld. is this behavior to be expected? to reproduce do: 1) be sure /usr/local/bin comes *before* /usr/bin in your $PATH 2) ln -s /bin/cat /usr/local/bin/cc (some sh script would be better) 3) cd /usr/src ; make SRCCONF=/dev/null __MAKE_CONF=/dev/null buildworld 4) see how buildworld fails, because cat(1) gets invoked instead of cc(1). ... buildkernel on the other hand seems to be immune to such an issue. The bootstrap stage needs *some* compiler on the host system to build the (cross)compiler that is then used during the rest of buildworld (and all of buildkernel). If you remove cc or c++ or libstdc++.so then you're screwed. sure, but cc resides in in /usr/bin. so there's no need to invoke anything from /usr/local/bin at all. As to whether the user's PATH should be honored for building the bootstrap/cross/build-tools, I'd say yes. i'd say no. imo nothing from /usr/local/* should ever be invoked when compiling a target in /usr/src. everything that's needed is in /usr/* (excluding local). You're assuming a build of FreeBSD on FreeBSD. But people might want to build FreeBSD on NetBSD and use the initial bootstrap cc from /usr/pkg/bin (or whatever). FreeBSD should be about tools, not policy. If you shoot yourself in the foot by messing with PATH + cc(1), that's your problem. hth 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[2]: About panic: bufwrite: buffer is not busy???
On week -current I have same problem, my box paniced every 2-15 min. I resolve problem by next steps - unplug network connectors from 2 intel em (82574L) cards. I think last time that mpd5 related panic, but mpd5 work with another re interface interated on MB. I think it may be em related panic, or em+mpd5. Wed, 16 Feb 2011 12:08:30 -0500 письмо от Andrew Boyer abo...@averesystems.com: Moving this to -current and -stable and following up... Something is broken with coredumps on stable/8 amd64. I tried a vanilla 8.2-RC3 and yesterday's csup of stable/8; neither can dump a core with 'sysctl debug.kdb.panic=1'. For the 8.2-RC3 / amd64 / GENERIC install, I used the memstick image, installed on ad7 (a 250GB SATA drive), used the default partition map, and set dumpdev to AUTO. I added enough tracing to show that the second panic is due to the syncer process flushing buffers to the other filesystems in parallel with the dump. I've seen this panic and a similar one 'buffer not locked' coming from ffs_write(). One time out of about 30 the core ran to completion, but slowly (~1MB/sec). Other times the dump just locks up completely with no other output. Does anyone know what might have changed to expose this problem? I don't ever see it under 7.1. Thanks, Andrew On Feb 3, 2011, at 12:11 AM, Eugene Grosbein wrote: On 02.02.2011 00:50, Gleb Smirnoff wrote: E Uptime: 8h3m51s E Dumping 4087 MB (3 chunks) E chunk 0: 1MB (150 pages) ... ok E chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? E cpuid = 3 E Uptime: 8h3m52s E Automatic reboot in 15 seconds - press a key on the console to abort Can you add KDB_TRACE option to kernel? Your boxes for some reason can't dump core, but with this option we will have at least trace. I see Mike Tancsa's box has bufwrite: buffer is not busy??? problem too. Has anyone a thought how to fix generation of crashdumps? Eugene Grosbein ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org -- Andrew Boyer abo...@averesystems.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 ___ 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: About panic: bufwrite: buffer is not busy???
On 2/20/2011 9:33 AM, Andrey Smagin wrote:
On week -current I have same problem, my box paniced every 2-15 min. I
resolve problem by next steps - unplug network connectors from 2 intel em
(82574L) cards. I think last time that mpd5 related panic, but mpd5 work with
another re interface interated on MB. I think it may be em related panic, or
em+mpd5.
The latest panic I saw didnt have anything to do with em. Are you sure
your crashes are because of the nic drive ?
The latest I saw was on Friday.
# kgdb /usr/obj/usr/src/sys/router/kernel.debug vmcore.11
(kgdb) bt
#0 doadump () at pcpu.h:231
#1 0xc04a51f9 in db_fncall (dummy1=1, dummy2=0, dummy3=-106856,
dummy4=0xc6b9696c ) at /usr/src/sys/ddb/db_command.c:548
#2 0xc04a55f1 in db_command (last_cmdp=0xc096f73c, cmd_table=0x0,
dopager=1) at /usr/src/sys/ddb/db_command.c:445
#3 0xc04a574a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#4 0xc04a764d in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:229
#5 0xc068ba7e in kdb_trap (type=12, code=0, tf=0xc6b96b94) at
/usr/src/sys/kern/subr_kdb.c:546
#6 0xc088056f in trap_fatal (frame=0xc6b96b94, eva=52) at
/usr/src/sys/i386/i386/trap.c:937
#7 0xc0880830 in trap_pfault (frame=0xc6b96b94, usermode=0, eva=52) at
/usr/src/sys/i386/i386/trap.c:859
#8 0xc0880d4a in trap (frame=0xc6b96b94) at
/usr/src/sys/i386/i386/trap.c:532
#9 0xc086716c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248
#11 0xc0654ec9 in crcopy (dest=0xce3ee800, src=0xce3ee600) at
/usr/src/sys/kern/kern_prot.c:1873
#12 0xc0654fd1 in crcopysafe (p=0xc90cc810, cr=0xce3ee800) at
/usr/src/sys/kern/kern_prot.c:1950
#13 0xc0656d7f in seteuid (td=0xc9196b80, uap=0xc6b96cec) at
/usr/src/sys/kern/kern_prot.c:615
#14 0xc06985ff in syscallenter (td=0xc9196b80, sa=0xc6b96ce4) at
/usr/src/sys/kern/subr_trap.c:315
#15 0xc0880884 in syscall (frame=0xc6b96d28) at
/usr/src/sys/i386/i386/trap.c:1061
#16 0xc08671d1 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:264
#17 0x0033 in ?? ()
(kgdb) frame 10
#10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248
1248{
(kgdb) list
1243 * Place another refcount on a uidinfo struct.
1244 */
1245void
1246uihold(uip)
1247struct uidinfo *uip;
1248{
1249
1250refcount_acquire(uip-ui_ref);
1251}
1252
(kgdb) p *uip
Cannot access memory at address 0x0
(kgdb) p uip
$1 = (struct uidinfo *) 0x0
(kgdb)
Wed, 16 Feb 2011 12:08:30 -0500 письмо от Andrew Boyer
abo...@averesystems.com:
Moving this to -current and -stable and following up...
Something is broken with coredumps on stable/8 amd64. I tried a vanilla
8.2-RC3 and yesterday's csup of stable/8; neither can dump a core with
'sysctl
debug.kdb.panic=1'.
For the 8.2-RC3 / amd64 / GENERIC install, I used the memstick image,
installed on ad7 (a 250GB SATA drive), used the default partition map, and
set
dumpdev to AUTO.
I added enough tracing to show that the second panic is due to the syncer
process flushing buffers to the other filesystems in parallel with the dump.
I've seen this panic and a similar one 'buffer not locked' coming from
ffs_write(). One time out of about 30 the core ran to completion, but slowly
(~1MB/sec). Other times the dump just locks up completely with no other
output.
Does anyone know what might have changed to expose this problem?
I don't ever see it under 7.1.
Thanks,
Andrew
On Feb 3, 2011, at 12:11 AM, Eugene Grosbein wrote:
On 02.02.2011 00:50, Gleb Smirnoff wrote:
E Uptime: 8h3m51s
E Dumping 4087 MB (3 chunks)
E chunk 0: 1MB (150 pages) ... ok
E chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not
busy???
E cpuid = 3
E Uptime: 8h3m52s
E Automatic reboot in 15 seconds - press a key on the console to abort
Can you add KDB_TRACE option to kernel? Your boxes for some reason can't
dump core, but with this option we will have at least trace.
I see Mike Tancsa's box has bufwrite: buffer is not busy??? problem too.
Has anyone a thought how to fix generation of crashdumps?
Eugene Grosbein
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
--
Andrew Boyer abo...@averesystems.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
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
Re: [RFC] Force stdio output streams to line-buffered mode
On Sat, Feb 19, 2011 at 02:37:29PM -0600, Matthew D. Fuller wrote: On Sat, Feb 19, 2011 at 07:50:43PM +0100 I heard the voice of Jeremie Le Hen, and lo! it spake thus: I've attached a small patch for stdio, so if the environment variable STDIO_IOLBF is set, the output streams will be line-oriented by default. iostat -x 1 | env STDIO_IOLBF=1 grep -v ad10 | cat -n I've no real comment on anything else (sounds like an interesting hack, whatever else), but just for this particular case, you know that grep has a --line-buffered arg, right? Yes indeed, my example wasn't especially smart :). Actually, I often stumble on this problem with an awk script I use to columize output. -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ 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: About panic: bufwrite: buffer is not busy???
On Feb 20, 2011, at 10:46 AM, Jeremy Chadwick wrote: On Sun, Feb 20, 2011 at 10:30:52AM -0500, Mike Tancsa wrote: On 2/20/2011 9:33 AM, Andrey Smagin wrote: On week -current I have same problem, my box paniced every 2-15 min. I resolve problem by next steps - unplug network connectors from 2 intel em (82574L) cards. I think last time that mpd5 related panic, but mpd5 work with another re interface interated on MB. I think it may be em related panic, or em+mpd5. The latest panic I saw didnt have anything to do with em. Are you sure your crashes are because of the nic drive ? Not to mention, the error string the OP provided (see Subject) is only contained in one file: sys/ufs/ffs/ffs_vfsops.c, function ffs_bufwrite(). So, that would be some kind of weird filesystem-related issue, not NIC-specific. I have no idea how to debug said problem. The issue is the file system activity occurring in parallel with the coredump, which is strange. It seems like everything else should be halted before the dump begins but I couldn't find a place in the code that actually tries to stop the other CPUs. My question isn't about the initial panic (I was using the sysctl to provoke one), but about the secondary panic. This is on 8-core systems. -Andrew -- Andrew Boyerabo...@averesystems.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: About panic: bufwrite: buffer is not busy???
On Sun, Feb 20, 2011 at 10:30:52AM -0500, Mike Tancsa wrote: On 2/20/2011 9:33 AM, Andrey Smagin wrote: On week -current I have same problem, my box paniced every 2-15 min. I resolve problem by next steps - unplug network connectors from 2 intel em (82574L) cards. I think last time that mpd5 related panic, but mpd5 work with another re interface interated on MB. I think it may be em related panic, or em+mpd5. The latest panic I saw didnt have anything to do with em. Are you sure your crashes are because of the nic drive ? Not to mention, the error string the OP provided (see Subject) is only contained in one file: sys/ufs/ffs/ffs_vfsops.c, function ffs_bufwrite(). So, that would be some kind of weird filesystem-related issue, not NIC-specific. I have no idea how to debug said problem. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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[2]: About panic: bufwrite: buffer is not busy???
Sun, 20 Feb 2011 10:30:52 -0500 письмо от Mike Tancsa m...@sentex.net:
On 2/20/2011 9:33 AM, Andrey Smagin wrote:
On week -current I have same problem, my box paniced every 2-15 min. I
resolve problem by next steps - unplug network connectors from 2 intel em
(82574L) cards. I think last time that mpd5 related panic, but mpd5 work with
another re interface interated on MB. I think it may be em related panic, or
em+mpd5.
The latest panic I saw didnt have anything to do with em. Are you sure
your crashes are because of the nic drive ?
I not shure crash because nic driver, I say only because my box after unplug 2
em nic's
have uptime from moment of unplug to right now moment. About all last week I
tried
understand source of panic. My box :
Phenom x4
12GB
2 re nic
2 em nic
through re0 em1 em2 work mpd5
re0 pptp client
em0 pppoe client
em1 l2tp client
The latest I saw was on Friday.
# kgdb /usr/obj/usr/src/sys/router/kernel.debug vmcore.11
(kgdb) bt
#0 doadump () at pcpu.h:231
#1 0xc04a51f9 in db_fncall (dummy1=1, dummy2=0, dummy3=-106856,
dummy4=0xc6b9696c ) at /usr/src/sys/ddb/db_command.c:548
#2 0xc04a55f1 in db_command (last_cmdp=0xc096f73c, cmd_table=0x0,
dopager=1) at /usr/src/sys/ddb/db_command.c:445
#3 0xc04a574a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#4 0xc04a764d in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:229
#5 0xc068ba7e in kdb_trap (type=12, code=0, tf=0xc6b96b94) at
/usr/src/sys/kern/subr_kdb.c:546
#6 0xc088056f in trap_fatal (frame=0xc6b96b94, eva=52) at
/usr/src/sys/i386/i386/trap.c:937
#7 0xc0880830 in trap_pfault (frame=0xc6b96b94, usermode=0, eva=52) at
/usr/src/sys/i386/i386/trap.c:859
#8 0xc0880d4a in trap (frame=0xc6b96b94) at
/usr/src/sys/i386/i386/trap.c:532
#9 0xc086716c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248
#11 0xc0654ec9 in crcopy (dest=0xce3ee800, src=0xce3ee600) at
/usr/src/sys/kern/kern_prot.c:1873
#12 0xc0654fd1 in crcopysafe (p=0xc90cc810, cr=0xce3ee800) at
/usr/src/sys/kern/kern_prot.c:1950
#13 0xc0656d7f in seteuid (td=0xc9196b80, uap=0xc6b96cec) at
/usr/src/sys/kern/kern_prot.c:615
#14 0xc06985ff in syscallenter (td=0xc9196b80, sa=0xc6b96ce4) at
/usr/src/sys/kern/subr_trap.c:315
#15 0xc0880884 in syscall (frame=0xc6b96d28) at
/usr/src/sys/i386/i386/trap.c:1061
#16 0xc08671d1 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:264
#17 0x0033 in ?? ()
(kgdb) frame 10
#10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248
1248{
(kgdb) list
1243 * Place another refcount on a uidinfo struct.
1244 */
1245void
1246uihold(uip)
1247struct uidinfo *uip;
1248{
1249
1250refcount_acquire(uip-ui_ref);
1251}
1252
(kgdb) p *uip
Cannot access memory at address 0x0
(kgdb) p uip
$1 = (struct uidinfo *) 0x0
(kgdb)
Wed, 16 Feb 2011 12:08:30 -0500 письмо от Andrew Boyer
abo...@averesystems.com:
Moving this to -current and -stable and following up...
Something is broken with coredumps on stable/8 amd64. I tried a vanilla
8.2-RC3 and yesterday's csup of stable/8; neither can dump a core with
'sysctl
debug.kdb.panic=1'.
For the 8.2-RC3 / amd64 / GENERIC install, I used the memstick image,
installed on ad7 (a 250GB SATA drive), used the default partition map, and
set
dumpdev to AUTO.
I added enough tracing to show that the second panic is due to the syncer
process flushing buffers to the other filesystems in parallel with the
dump.
I've seen this panic and a similar one 'buffer not locked' coming from
ffs_write(). One time out of about 30 the core ran to completion, but
slowly
(~1MB/sec). Other times the dump just locks up completely with no other
output.
Does anyone know what might have changed to expose this problem?
I don't ever see it under 7.1.
Thanks,
Andrew
On Feb 3, 2011, at 12:11 AM, Eugene Grosbein wrote:
On 02.02.2011 00:50, Gleb Smirnoff wrote:
E Uptime: 8h3m51s
E Dumping 4087 MB (3 chunks)
E chunk 0: 1MB (150 pages) ... ok
E chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is
not
busy???
E cpuid = 3
E Uptime: 8h3m52s
E Automatic reboot in 15 seconds - press a key on the console to abort
Can you add KDB_TRACE option to kernel? Your boxes for some reason can't
dump core, but with this option we will have at least trace.
I see Mike Tancsa's box has bufwrite: buffer is not busy??? problem too.
Has anyone a thought how to fix generation of crashdumps?
Eugene Grosbein
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
--
Andrew Boyer
Re: CFR: importing openresolv
On Thu, 19 Aug 2010, Hajimu UMEMOTO wrote: Hi, I wish to import openresolv 3.3.5 into our base tree. It makes merging the DNS server addresses informed from DHCP, DHCPv6, PPP, ... into /etc/resolv.conf easier. http://roy.marples.name/projects/openresolv My patch against 9-CURRENT can be obtained from: http://www.imasy.or.jp/~ume/FreeBSD/openresolv-20100818.diff.gz Do you have an updated patch for 3.4.1 or 3.3.6? I'd like to help to you get it in for 9.0-R. I wouldn't even mind if some ports would conflict with it for a while not making the situation any worse than it is these days. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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
Sade(8) compile problem
Hello guys, I have amd64 FreeBSD-Current box (r214751) and want to build fresh system to install, but compile fails every time . Configuration files are same. The failure is in sade(8), where compiller try to find dialog h in /usr/src/usr.sbin/../../gnu/lib/libdialog/dialog.h , not in libadialog directory. First appearance of this failure is about month ago (I have autobuild system) make.conf is /dev/null src.conf contains following keys turned on: WITHOUT_ATM WITHOUT_AMD WITH_BSD_GREP WITHOUT_CTM WITHOUT_FLOPPY WITHOUT_FREEBSD_UPDATE WITHOUT_IPFILTER WITHOUT_IPFW WITHOUT_IPX WITHOUT_NIS WITHOUT_NLS_CATALOGS WITHOUT_RCMDS WITHOUT_TCSH WITH_BIND_LARGE_FILE WITH_BIND_SIGCHASE WITH_GPIO ___ 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: Sade(8) compile problem
On Sun, Feb 20, 2011 at 11:08 AM, Eir Nym eir...@gmail.com wrote: Hello guys, I have amd64 FreeBSD-Current box (r214751) and want to build fresh system to install, but compile fails every time . Configuration files are same. The failure is in sade(8), where compiller try to find dialog h in /usr/src/usr.sbin/../../gnu/lib/libdialog/dialog.h , not in libadialog directory. First appearance of this failure is about month ago (I have autobuild system) Works for me: FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218082M: Sun Jan 30 00:20:08 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Make sure to update the Makefile to point at libodialog instead of libdialog. See this commit for more details: http://svn.freebsd.org/viewvc/base?view=revisionrevision=217309 . HTH, -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: CFR: importing openresolv
On Wed, Aug 18, 2010 at 11:27 AM, Hajimu UMEMOTO u...@freebsd.org wrote:
Hi,
I wish to import openresolv 3.3.5 into our base tree. It makes
merging the DNS server addresses informed from DHCP, DHCPv6, PPP, ...
into /etc/resolv.conf easier.
http://roy.marples.name/projects/openresolv
My patch against 9-CURRENT can be obtained from:
http://www.imasy.or.jp/~ume/FreeBSD/openresolv-20100818.diff.gz
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
Sounds like a fine plan. I will help test as time allows. I had a
test patch incorporating openresolv quite some time ago, and it was
straight forward, and worked well in my limited testing with dual
stack multiple DNS providers. (DHCPv6/RFC5006-RDNSS/DHCPv4/Avahi)
From talking to Roy Marples in the past, this code has already been
imported into netbsd at some level, and I believe that he was
recommending the use of the latest code from the repository due to
some bug fixes, but it is worthy of another conversation since quite
some time has elapsed since my last query.
Good Luck.
_Dave
___
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: DTrace Broken?
On Fri, 18 Feb 2011, Shawn Webb wrote: Hey fellow current users, Looks like dtrace is broken in current: # dtrace -l -f acl dtrace: invalid probe specifier acl: /usr/lib/dtrace/psinfo.d, line 37: syntax error near uid_t Error messages along these lines almost always mean that the kernel was built without WITH_CTF (causing dtrace to be unable to find the type information it requires). Robert Line 37 shows: uid_t pr_uid; /* real user id */ Looks good to me, but why is dtrace complaining? Thanks, Shawn Webb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Dell 370 bluetooth minicard
Hello all, On a Dell E6400 the bluetooth wireless minicard (Dell 370 = BCM2046B1 if i am right) does not attach to any driver. Is this ship supported by the btbcmfw driver? Any comment would be helpfull. Thanks. rmgls 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
