Re: IDE DVD playback on 5.1-CURRENT
Adam K Kirchhoff wrote: I've asked this same question on freebsd-questions an on #freebsd (freenode), but haven't gotten any answer, so I thought I'd ask on here. I'm hoping someone can help me out here. I recently moved a firewire card and DVD drive that had been in my FreeBSD box to another computer. I replaced it with an IDE DVD drive. The probelm is that now I can't get mplayer or vlc to play any DVDs that had previously worked with the firewire drive. I have, of course, made sure that /dev/dvd is a symbolic link to /dev/acd0 instead of /dev/cd0 (as it used to be). The only difference that I can think of is that FreeBSD sees the firewire drive as a scsi drive and sees the ide drive as an ide drive. Have you tried (from mplayer's man page): -dvd-device path to device Override default DVD device name /dev/dvd. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pcic device causes kernel build failure
M. Warner Losh wrote: Don't build pcic with newcard. It is broken, doesn't work and isn't supported. I have a rewrite in my p4 tree that I'm slugging through, but pcic is likely to coninue to not compile until that's committed. Will that eventually fix support for the following (dmesg fragment from 4.8-STABLE)?: pcic0: Vadem 469 at port 0x3e0 iomem 0xd on isa0 pcic0: Polling mode pccard0: PC Card 16-bit bus (classic) on pcic0 pccard1: PC Card 16-bit bus (classic) on pcic0 I'd like to run CURRENT on this laptop, but this thwarted me last time by revoking my network. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
bsd.lib.mk and bsd.own.mk ignore /etc/make.conf(INSTALL)
Hi
Any idea why '-C' is hard coded for bsd.lib.mk and bsd.own.mk? I
thought that the make.conf variable was there to allow or disallow
this. The following comes from bsd.lib.mk:
.if defined(LIB) !empty(LIB) !defined(NOINSTALLLIB)
${INSTALL} -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \
${_INSTALLFLAGS} lib${LIB}.a ${DESTDIR}${LIBDIR}
.endif
.if !defined(NOPROFILE) defined(LIB) !empty(LIB)
${INSTALL} -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \
${_INSTALLFLAGS} lib${LIB}_p.a ${DESTDIR}${LIBDIR}
.endif
Ian
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /lib symlinks problem?
Doug Barton wrote: On Mon, 1 Sep 2003, M. Warner Losh wrote: My tool is initially just a 'delete these files' tool, but now that I think about it, it wouldn't be hard to say also 'create these symlinks'. The hard part here is generating the 'obsolete' lists. I posted one approach to this today... touch a file right before you start installworld, then consider anything not newer than that file a candidate for disposal. There is currently something weird going on in /usr/lib though... a lot of the files don't have newer dates, I haven't tracked down why yet. That's because bsd.lib.mk and bsd.own.mk hardcode '-C' for install. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /lib symlinks problem?
Sheldon Hearn wrote: On (2003/09/02 09:43), Ian Freislich wrote: I posted one approach to this today... touch a file right before you start installworld, then consider anything not newer than that file a candidate for disposal. There is currently something weird going on in /usr/lib though... a lot of the files don't have newer dates, I haven't tracked down why yet. That's because bsd.lib.mk and bsd.own.mk hardcode '-C' for install. Which a few of us have complained about and subsequently settled on local patches for. :-( Which is what I eventually did too after nearly destroying half of /usr/lib because /usr/src/share/examples/etc/make.conf and make.conf(5) *LIE* about (or at the very least misrepresent) what really happens. The explanation 'these files are dependencies' doesn't really explain the need for install -C to me and just makes it harder to find what was installed and what was stale. I propose the following patch to make.conf(5) and something similar to make.conf: Index: make.conf.5 === RCS file: /home/ncvs/src/share/man/man5/make.conf.5,v retrieving revision 1.78 diff -u -d -r1.78 make.conf.5 --- make.conf.5 29 Aug 2003 11:24:53 - 1.78 +++ make.conf.5 2 Sep 2003 08:11:10 - @@ -181,11 +181,15 @@ .It Va INSTALL .Pq Vt str the default install command. -To have commands compared before doing +To have targets compared with the source before doing the install, use .Bd -literal -offset indent INSTALL=install -C .Ed +Note that some system Makefile includes +hardcode options for +the supplied install command. +Your mileage may vary. .It Va LOCAL_DIRS .Pq Vt str List any directories that should be entered when doing ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
bsdlabel wierd.
Hi I was experimenting with growfs yesterday and I noticed this wierd thing crop up in my label. Notice the 'a' partition which I can no longer get rid of and appears automatically. using bsdlabel -e I have to delete this partition if I want to change any of the other partitions (it complains about overlapping partitions otherwise). [brane-dead] / # bsdlabel /dev/ad0s1 # /dev/ad0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 20044064 16unused0 0 c: 200440800unused 1024 8192 # raw part, don't edit e: 2004408004.2BSD 1024 8192 46248 What am I missing? BTW, growfs barfed too with a 'rdfs: read error'. [brane-dead] /var/log # fdisk /dev/ad0 *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=19885 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=19885 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 0, size 20044080 (9787 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 1; end: cyl 428/ head 15/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Why does bsdlabel autogenerate the 'a' partition?
Hi Why does the bsdlabel program autogenerate the 'a' partition? If I edit the disk label removing all partitions except for 'c' and then save it, a subsequent read of the disk label shows an 'a' partition has been made covering the whole disk. Even if I make another partition using the whole disk, it still makes 'a', which has to be deleted to create other partitions because of the resulting overlap. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New Kernel Breaks IPFW
Daniel C. Sobral wrote: John Stockdale wrote: Hey everyone, I just cvsup'd my src today and was going to buildworld later tonight but when I installed the newly built kernel with IPFIREWALL etc. and rebooted, ipfw fell over, specifically, even after ipfw firewall enable, an ipfw show resulted in a core dump. If its useful, I can post the ipfw core dump. Any ideas why this is? Probably because the ABI between ipfw(8) and it's kernel counterpart has changed. Since you failed to follow the safe path of upgrade (mergemaster -p, builworld, buildkernel, installkernel, reboot -s (fall back in case of problems), mount fs and installkernel, mergemaster), this sort of things can happen. Alas make buildworld fails for the past few days: === usr.sbin/config snip In file included from config.c:1: /usr/include/stdlib.h:102: conflicting types for `restrict' /usr/include/stdlib.h:102: previous declaration of `restrict' /usr/include/stdlib.h:102: warning: redundant redeclaration of `restrict' in same scope /usr/include/stdlib.h:102: warning: previous declaration of `restrict' /usr/include/stdlib.h:103: conflicting types for `restrict' snip (and also stdio.h, string.h, sys/types.h, select.h) Someone posted a link to the failure that I get, so I'll crib: http://www.0xfce3.net/error.txt Granted, that rather laborious process is usually unnecessary. I, myself, often use only buildworld, kernel, installworld, mergemaster and then reboot. And, of course, I'm fully prepared to take Murphy's Revenge upon my shoulder if these simple steps fail to yield a working system (a broken kernel, for instance, with a new world incompatible with the previous kernel). Short term, cd /usr/src/sbin/ipfw; make depend make all install ought to fix it. I tried that as well, but the new binary also dumps core, but works well with previous versions of the firewall. Even back as far as my kernel.working from May 7 2003. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New Kernel Breaks IPFW
Terry Lambert wrote: Apparently, someone hosed the compiler flags. Looking at your cribbed link: Someone posted a link to the failure that I get, so I'll crib: http://www.0xfce3.net/error.txt We see: cc -O -pipe -std=iso9899:1999 -I/usr/obj/usr/src/i386/legacy/usr/include -static -L/usr/obj/usr/src/i386/legacy/usr/lib -o xinstall xinstall.o -legacy Works. cc -O -pipe -I. -I/usr/src/usr.sbin/config -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Winline -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -std=iso9899:1999 -I/usr/obj/usr/src/i386/legacy/usr/include -c config.c Hmmm, BDEFLAGS. config.c appears to compile without them. Short term, cd /usr/src/sbin/ipfw; make depend make all install ought to fix it. I tried that as well, but the new binary also dumps core, but works well with previous versions of the firewall. Even back as far as my kernel.working from May 7 2003. Bogus header files; specifically, netinet/ip_fw.h. Because you can't build world, you are compiling the ipfw program with the old system include files instead of the new ones. You may also be missing a cvs update on the ipfw sources themselves (specifically, ipfw2.c). No, it did compile ipfw2.c (r1.24). I also installed all new includes before I compiled ipfw and re-worlding to no avail. I figured an old kernel with a working firewall was better than a new kernel with no firewall. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New Kernel Breaks IPFW
Andre Guibert de Bruet wrote: Ian, The new ipfw binary will work with an up-to-date kernel. What you need to do is boot this new kernel and only then try out the new ipfw binary. That doesn't really explain why the new ipfw binary core dumped with the new kernel, but worked fine with old kernels. Now that I've removed BDECFLAGS, it seems that my buildworld will succeed and whatever it was that was broken that ipfw linked in (statically) will hopefully be fixed and all will be good in my land of -CURRENT, for the moment that is. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ULE crash
Hi
About 4.5 minutes after rebooting with a SCHED_ULE kernel (I give
ULE a go every few months), top started looking really wierd (the
CPU % just kept on accumulating for each process). Before dnetc
started, httpd showed 17% CPU, but the system was supposedly 100%
idle at the time according to top. Then dnetc started and things
got wierd.
last pid: 607; load averages: 1.83, 0.63, 0.25up 0+00:04:23 16:00:48
35 processes: 3 running, 32 sleeping
CPU states: 0.0% user, 99.0% nice, 0.6% system, 0.4% interrupt, 0.0% idle
Mem: 20M Active, 14M Inact, 19M Wired, 20K Cache, 25M Buf, 130M Free
Swap: 512M Total, 512M Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND
603 ianf 139 20 1072K 880K RUN0 0:39 105.47% 105.47% dnetc
575 ianf 139 20 1072K 880K CPU1 1 1:15 102.34% 102.34% dnetc
505 root 760 7208K 5420K select 0 0:01 17.97% 17.97% httpd
375 root40 1276K 948K accept 0 0:00 9.38% 9.38% nfsd
526 nobody 760 9280K 8564K select 1 0:04 5.47% 5.47% squid
607 ianf 760 2196K 1444K CPU0 0 0:00 2.34% 2.34% top
Then it froze. When I got home I found that it had at least dumped
vmcore.24. I'll keep it around for a while and perform any inspections
people want me to. This was with sources updated at 13h30 GMT today.
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x38
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01e094d
stack pointer = 0x10:0xce772be4
frame pointer = 0x10:0xce772bf4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 603 (dnetc)
trap number = 12
panic: page fault
cpuid = 1; lapic.id = 0100
Stack backtrace:
boot() called on cpu#1
syncing disks, buffers remaining... panic: absolutely cannot call smp_ipi_shootdown
with interrupts already disabled
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 4m15s
Dumping 191 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176
---
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc01cbe7f in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc01cc2b8 in panic () at ../../../kern/kern_shutdown.c:550
#3 0xc02e8f89 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0)
at ../../../i386/i386/mp_machdep.c:2356
#4 0xc02e92a9 in smp_invlpg_range (addr1=0, addr2=0)
at ../../../i386/i386/mp_machdep.c:2488
#5 0xc02eb548 in pmap_invalidate_range (pmap=0xc03996e0, sva=3365310464,
eva=3365314560) at ../../../i386/i386/pmap.c:721
#6 0xc02eb83d in pmap_qenter (sva=3365310464, m=0xce772884, count=0)
at ../../../i386/i386/pmap.c:948
#7 0xc0218a31 in vm_hold_load_pages (bp=0xc76039a0, from=0, to=3365318656)
at ../../../kern/vfs_bio.c:3574
#8 0xc0216f5a in allocbuf (bp=0xc76039a0, size=8192)
at ../../../kern/vfs_bio.c:2752
#9 0xc0216cee in geteblk (size=8192) at ../../../kern/vfs_bio.c:2634
#10 0xc0213980 in bwrite (bp=0xc75b65d8) at ../../../kern/vfs_bio.c:818
#11 0xc02142dc in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1153
#12 0xc021d89a in vop_stdfsync (ap=0xce772a14)
at ../../../kern/vfs_default.c:742
#13 0xc0193570 in spec_fsync (ap=0xce772a14)
at ../../../fs/specfs/spec_vnops.c:417
#14 0xc0192a38 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:122
#15 0xc0294c62 in ffs_sync (mp=0xc3950a00, waitfor=2, cred=0xc0d06e80,
td=0xc03702a0) at vnode_if.h:624
#16 0xc022b15b in sync (td=0xc03702a0, uap=0x0)
at ../../../kern/vfs_syscalls.c:142
#17 0xc01cb9a1 in boot (howto=256) at ../../../kern/kern_shutdown.c:281
#18 0xc01cc2b8 in panic () at ../../../kern/kern_shutdown.c:550
#19 0xc02f0da2 in trap_fatal (frame=0xce772ba4, eva=0)
at ../../../i386/i386/trap.c:836
#20 0xc02f0333 in trap (frame=
{tf_fs = -1060044776, tf_es = -831062000, tf_ds = -1071775728, tf_edi =
-1014422336, tf_esi = -1070107520, tf_ebp = -831050764, tf_isp = -831050800, tf_ebx =
0, tf_edx = 0, tf_ecx = -1059988168, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip =
-1071773363, tf_cs = 8, tf_eflags = 66194, tf_esp = -1070107520, tf_ss = 0}) at
../../../i386/i386/trap.c:256
#21 0xc02d8eb8 in calltrap () at {standard input}:97
#22 0xc01e188b in sched_choose () at ../../../kern/sched_ule.c:1161
#23 0xc01d25e6 in choosethread () at ../../../kern/kern_switch.c:140
#24 0xc01d422f in mi_switch () at ../../../kern/kern_synch.c:525
#25 0xc01c1db6 in _mtx_lock_sleep (m=0xc0374a40, opts=0, file=0x0, line=0)
at ../../../kern/kern_mutex.c:636
#26 0xc01ca585 in getrusage (td=0x0, uap=0xce772d10)
at ../../../kern/kern_resource.c:773
#27 0xc02f10fc in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47,
Re: ULE crash
Jeff Roberson wrote: On Wed, 25 Jun 2003, Ian Freislich wrote: Hi About 4.5 minutes after rebooting with a SCHED_ULE kernel (I give ULE a go every few months), top started looking really wierd (the CPU % just kept on accumulating for each process). Before dnetc started, httpd showed 17% CPU, but the system was supposedly 100% idle at the time according to top. Then dnetc started and things got wierd. There is some bug that is preventing sleeping processes from loosing old cpu usage. I'm looking into that. Can you tell me what version of the sched_ule.c file you have? This looks like an old panic. $FreeBSD: src/sys/kern/sched_ule.c,v 1.46 2003/06/21 02:31:49 jeff Exp $ Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Making a disk bootable...
Hi This might sound like a really simple question, but what used to work no longer does. How do you partition, label and make a disk bootable? I've used fdisk to create one slice (da0s1). I then used bsdlabel to make make the partitions a, b, e and f. Then to put the boot block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0' it trashes the label. Then I copy all my filesystems off the IDE drive I'm trying to rid myself of onto the SCSI disk. When I tell the BIOS to boot off SCSI, it complains 'Missing Operating System'. So I try to dd the first 512 bytes of ad0 onto da0. The BIOS now doesn't complain about a missing operating system, it just hangs and the label on da0 is trashed. So, after about 7 cycles of fdisk, label, newfs, dump, restore, boot SCSI die 'Missing Operating System', boot IDE I give up and try to use sysinstall compiled on July 9 from sources of the same thinking 'surely the installer must be able to make a disk bootable'. It can't either. BTW, it doesn't even make the filesystems when you 'w'rite the changes in the label editor, even though it say's it's makeing the filesystems. So for the moment, I have to keep the IDE disk just for the MBR and type '1:da(0,a)/boot/loader' which is a bit inconvenient. Does anyone have any suggestions short of putting the disks I want labeled in a -STABLE box (which will be a major PITA since my -STABLE box doesn't have SCSI and the controler is on-board on my -CURRENT box)? Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making a disk bootable...
Peter McGarvey wrote: * Ian Freislich [EMAIL PROTECTED] [2003-07-14 13:58:39 BST]: Hi This might sound like a really simple question, but what used to work no longer does. How do you partition, label and make a disk bootable? And this may sound like a really stupid answer, but have you considered using /stand/sysinstall? Yes. See paragraph 4. Aside, I'd like to be able to do this from the command line anyway. I've used fdisk to create one slice (da0s1). I then used bsdlabel to make make the partitions a, b, e and f. Then to put the boot block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0' it trashes the label. Then I copy all my filesystems off the IDE drive I'm trying to rid myself of onto the SCSI disk. When I tell the BIOS to boot off SCSI, it complains 'Missing Operating System'. So I try to dd the first 512 bytes of ad0 onto da0. The BIOS now doesn't complain about a missing operating system, it just hangs and the label on da0 is trashed. So, after about 7 cycles of fdisk, label, newfs, dump, restore, # boot SCSI die 'Missing Operating System', boot IDE I give up and # try to use sysinstall compiled on July 9 from sources of the same # thinking 'surely the installer must be able to make a disk bootable'. # It can't either. BTW, it doesn't even make the filesystems when # you 'w'rite the changes in the label editor, even though it say's it's makeing the filesystems. So for the moment, I have to keep the IDE disk just for the MBR and type '1:da(0,a)/boot/loader' which is a bit inconvenient. Does anyone have any suggestions short of putting the disks I want labeled in a -STABLE box (which will be a major PITA since my -STABLE box doesn't have SCSI and the controler is on-board on my -CURRENT box)? Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- TTFN, FNORD Peter McGarvey Freelance FreeBSD Hacker (will work for bandwidth) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making a disk bootable...
Mark Murray wrote: Hi Ian! Ian Freislich writes: I've used fdisk to create one slice (da0s1). I then used bsdlabel to make make the partitions a, b, e and f. Then to put the boot block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0' it trashes the label. Then I copy all my filesystems off the IDE drive I'm trying to rid myself of onto the SCSI disk. When I tell the BIOS to boot off SCSI, it complains 'Missing Operating System'. Then, when you fdisk, make damn sure that the probed geometry is used. After that, you shouldn't have probelms. If that fixes your problem, please report it in detail to [EMAIL PROTECTED] so we can get a more permanent fix. I've just tried this dd'ing /dev/zero over the front of the disk first to no avail (the probed geometry is the geometry that fdisk used anyway). I also tried your much loved ficticious geometry of 255H 64S and that didn't work. It's a RPITA. In the end I dangerously dedicated the disk and that works. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Process stats wrong under ULE
Kris Kennaway wrote: I'm seeing the following kind of behaviour under ULE on a UP machine (kernel updated earlier this evening). Notice that the total CPU% adds up to way more than 100%; indeed one single process is allegedly using more than 100% CPU, and (not clear from the top(1) output) the processes that are sleeping do not have their CPU% updated until the next time they run. Jeff is aware of this and has said it is on his list of things to fix. Not sure where on his list it is though. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
libstdc++ fallout? mongodb fails to build.
Hi Is this libstdc++ fallout? The system is AMD64 with all ports successfully rebuilt except for mongodb. In file included from src/mongo/shell/dbshell.cpp:26: In file included from src/mongo/base/initializer.h:21: In file included from src/mongo/base/configuration_variable_manager.h:24: src/mongo/platform/unordered_map.h:51:16: error: no member named 'tr1' in namespace 'std' using std::tr1::unordered_map; ~^ In file included from src/mongo/shell/dbshell.cpp:26: In file included from src/mongo/base/initializer.h:24: In file included from src/mongo/base/initializer_dependency_graph.h:26: src/mongo/platform/unordered_set.h:51:16: error: no member named 'tr1' in namespace 'std' using std::tr1::unordered_set; ~^ 2 errors generated. scons: *** [build/freebsd/cc_cc/cxx_c++/ssl/use-system-pcre/use-system-snappy/use-system-v8/usev8/mongo/shell/dbshell.o] Error 1 scons: building terminated because of errors. *** Error code 2 Stop. make[1]: stopped in /usr/ports/databases/mongodb *** Error code 1 Stop. make: stopped in /usr/ports/databases/mongodb Ian -- Ian Freislich ___ 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: libstdc++ fallout? mongodb fails to build.
Florent Peterschmitt wrote: Le 20/09/2013 10:04, Ian FREISLICH a =E9crit : Hi Is this libstdc++ fallout? You can try these patchs: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/182110 I am sorry that I did not see your message until today. This fixes the build. Thanks very much. Ian -- Meditating Guru Ian Freislich ___ 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: Time keeping Issues with the low-resolution TSC timecounter
Jung-uk Kim wrote: On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote: Can you please try the attached patch? It should disable TSC/TSC-low timecounter for your CPU models, I think. Sorry, I attached a wrong patch. Please ignore the previous one and try this, instead. TSC-low is not presented as an option any more: CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.03-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics Event timer LAPIC quality 400 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 atrtc0: AT realtime clock port 0x70-0x77 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer RTC frequency 32768 Hz quality 0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 attimer0: AT timer port 0x40-0x43,0x50-0x53 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 kern.timecounter.choice: TSC(-1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) -- Ian Freislich ___ 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
Kernel compile failure in ATH.
Hi Just got this error making a new kernel: cc -c -O -pipe -march=prescott -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c -I/usr/src/sys/dev/ath cc1: warnings being treated as errors /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'isEepromValid': /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: implicit declaration of function 'HALDEBUG_G' /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: nested extern declaration of 'HALDEBUG_G' [-Wnested-externs] /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: 'HAL_DEBUG_REGDOMAIN' undeclared (first use in this function) /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: (Each undeclared identifier is reported only once /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: for each function it appears in.) /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'ath_hal_mapgsm': /usr/src/sys/dev/ath/ath_hal/ah_regdomain.c:612: error: 'HAL_DEBUG_ANY' undeclared (first use in this function) *** Error code 1 -- Ian Freislich ___ 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
cvsup servers broken?
Hi I've been seeing this all day: # cvsup -L2 /root/supfile-cvs Parsing supfile /root/supfile-cvs Connecting to cvsup6.freebsd.org Connected to cvsup6.freebsd.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection cvsroot-common/cvs Updating collection src-all/cvs Updating collection ports-all/cvs Detailer failed: Premature EOF from server Will retry at 18:32:04 Which coincides with: (Timestamps UTC+0200) 18:27:12.004603 IP 41.154.88.19.52564 128.205.32.24.5999: Flags [.], ack 102802, win 8225, options [nop,nop,TS val 3651903 ecr 3047757560], length 1400 18:27:12.006713 IP 128.205.32.24.5999 41.154.88.19.52564: Flags [.], ack 14659685, win 8225, options [nop,nop,TS val 3047757730 ecr 3651472], length 0 18:27:12.145079 IP 128.205.32.24.5999 41.154.88.19.52564: Flags [.], ack 14662485, win 8050, options [nop,nop,TS val 3047757867 ecr 3651688], length 10 18:27:12.157567 IP 128.205.32.24.5999 41.154.88.19.52564: Flags [.], ack 14663885, win 8225, options [nop,nop,TS val 3047757880 ecr 3651688], length 0 18:27:12.245335 IP 41.154.88.19.52564 128.205.32.24.5999: Flags [P.], ack 102812, win 8225, options [nop,nop,TS val 3652146 ecr 3047757867], length 342 18:27:12.578479 IP 128.205.32.24.5999 41.154.88.19.52564: Flags [R], seq 1059787102, win 0, length 0 It looks like the server is just exiting. I've tested cvsup4 and cvsup5 as well. Is cvsup deprecated these days or has something else broken it? Ian -- Ian Freislich ___ 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: cvsup servers broken?
Matt wrote: On 07/01/11 09:34, Ian FREISLICH wrote: It looks like the server is just exiting. I've tested cvsup4 and cvsup5 as well. Is cvsup deprecated these days or has something else broken it? Try csup instead of cvsup...I've found it works better. Any possibility of network issues? csup gets into an infinite loop near the end of the ports tree and starts growing in memory consumption. I killed it after it grew to about 500M resident. The following is a ktrace snippet after it stalls: 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) The first part of csup's stack trace. It appears to be corrupted with several null frames, and is very, very deep. (gdb) bt #0 0x2832c1f3 in ioctl () from /lib/libc.so.7 #1 0x2832bdbc in tcgetattr () from /lib/libc.so.7 #2 0x2832b7ea in isatty () from /lib/libc.so.7 #3 0x08051832 in fnmatch () #4 0x08051906 in fnmatch () #5 0x08052135 in fnmatch () #6 0x08059c19 in fnmatch () #7 0x08059a76 in fnmatch () #8 0x0804c1ff in ?? () #9 0x28c11380 in ?? () #10 0x2845f402 in ?? () [mini] /usr/home/ianf # procstat -f 75390 PID COMM FD T V FLAGSREF OFFSET PRO NAME 75390 csup text v r r--- - - - /usr/bin/csup 75390 csup ctty v c rw-- - - - /dev/pts/1 75390 csup cwd v d r--- - - - /usr/src 75390 csup root v d r--- - - - / 75390 csup0 v c rw-- 14 10464115 - /dev/pts/1 75390 csup1 v c rw-- 14 10464115 - /dev/pts/1 75390 csup2 v c rw-- 14 10464115 - /dev/pts/1 75390 csup3 s - rw-- 2 0 TCP 10.0.2.67:19238 128.205.32.24:5999 75390 csup4 v r r--- 1 0 - /usr/home/ncvs/ports/x11/wbar/Makefile,v 75390 csup5 v r r--- 11023 - /var/db/sup/ports-all/checkouts 75390 csup6 v r r--- 1 24492073 - /var/db/sup/ports-all/checkouts 75390 csup7 v r -w-- 1 24491389 - /var/db/sup/ports-all/#cvs.csup-75390.0 filedescriptor 4's directory listing: [mini] /usr/home/ncvs/ports/x11/wbar # ls -la total 24 drwxr-xr-x3 root wheel512 Jul 1 07:21 . drwxr-xr-x 694 root wheel 14848 Jun 28 16:29 .. -r--r--r--1 root wheel 0 Feb 8 22:51 Makefile,v -r--r--r--1 root wheel 0 Mar 19 14:38 distinfo,v drwxr-xr-x2 root wheel512 Jul 1 07:21 files -r--r--r--1 root wheel 0 Feb 8 22:51 pkg-descr,v -r--r--r--1 root wheel 0 Feb 8 22:51 pkg-plist,v After removing the zero sized files, csup continued until it hit x11-toolkits/Makefile,v and then ports/x11-wm/Makefile,v which was also zero sized. Having deleted all the zero files, both cvsup and csup complete their run. So, why does it fail so absurdly on this condition? Ian -- Ian Freislich ___ 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: cvsup servers broken?
Gavin Atkinson wrote: On Sat, 2 Jul 2011, Ian FREISLICH wrote: Matt wrote: On 07/01/11 09:34, Ian FREISLICH wrote: It looks like the server is just exiting. I've tested cvsup4 and cvsup5 as well. Is cvsup deprecated these days or has something else broken it? Try csup instead of cvsup...I've found it works better. Any possibility of network issues? csup gets into an infinite loop near the end of the ports tree and starts growing in memory consumption. I killed it after it grew to about 500M resident. The following is a ktrace snippet after it stalls: 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) The first part of csup's stack trace. It appears to be corrupted with several null frames, and is very, very deep. (gdb) bt #0 0x2832c1f3 in ioctl () from /lib/libc.so.7 #1 0x2832bdbc in tcgetattr () from /lib/libc.so.7 #2 0x2832b7ea in isatty () from /lib/libc.so.7 #3 0x08051832 in fnmatch () #4 0x08051906 in fnmatch () #5 0x08052135 in fnmatch () #6 0x08059c19 in fnmatch () #7 0x08059a76 in fnmatch () #8 0x0804c1ff in ?? () #9 0x28c11380 in ?? () #10 0x2845f402 in ?? () [mini] /usr/home/ianf # procstat -f 75390 PID COMM FD T V FLAGSREF OFFSET PRO NAME 75390 csup text v r r--- - - - /usr/bin/csup 75390 csup ctty v c rw-- - - - /dev/pts/1 75390 csup cwd v d r--- - - - /usr/src 75390 csup root v d r--- - - - / 75390 csup0 v c rw-- 14 10464115 - /dev/pts/1 75390 csup1 v c rw-- 14 10464115 - /dev/pts/1 75390 csup2 v c rw-- 14 10464115 - /dev/pts/1 75390 csup3 s - rw-- 2 0 TCP 10.0.2.67:19238 12 8.205.32.24:5999 75390 csup4 v r r--- 1 0 - /usr/home/ncvs/por ts/x11/wbar/Makefile,v 75390 csup5 v r r--- 11023 - /var/db/sup/ports- all/checkouts 75390 csup6 v r r--- 1 24492073 - /var/db/sup/ports -all/checkouts 75390 csup7 v r -w-- 1 24491389 - /var/db/sup/ports -all/#cvs.csup-75390.0 filedescriptor 4's directory listing: [mini] /usr/home/ncvs/ports/x11/wbar # ls -la total 24 drwxr-xr-x3 root wheel512 Jul 1 07:21 . drwxr-xr-x 694 root wheel 14848 Jun 28 16:29 .. -r--r--r--1 root wheel 0 Feb 8 22:51 Makefile,v -r--r--r--1 root wheel 0 Mar 19 14:38 distinfo,v drwxr-xr-x2 root wheel512 Jul 1 07:21 files -r--r--r--1 root wheel 0 Feb 8 22:51 pkg-descr,v -r--r--r--1 root wheel 0 Feb 8 22:51 pkg-plist,v After removing the zero sized files, csup continued until it hit x11-toolkits/Makefile,v and then ports/x11-wm/Makefile,v which was also zero sized. Having deleted all the zero files, both cvsup and csup complete their run. I don't think you'll get much interest in fixing cvsup, but if you can recreate this at will with csup and haven't had a response in a few days, could you please submit a PR? This debugging above was with csup. cvsup would cause the remote to exit (hence the RST). csup would just consume all RAM and CPU when it encounters an empty ,v file. Ian -- Ian Freislich ___ 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: recovering data from a RAID1 array from a single disk on a different system
Alban Hertroys wrote: On 28 Jul 2011, at 21:13, Lee Whalen wrote: I'm no expert, but I'll add my insights regardless ;) 1. Using CCD or one of the other utilities, I need to add this USB-caged disk into a temporary RAID-1 array in a 'degraded' state so FreeBSD sees As far as I know, CCD (concatenated disk) can not do mirroring, so your RAID-1 disk won't be created using CCD. If it's a ccd, just configure a 1 disk mirror using ccdconfig. See ccdconfig(8) for more info. But it sounds like this may be some proprietry RAID format used by the controller in the NAS device. Often the controller doesn't actually do the RAID, so the OP might have some success using ataraid(4) to attach the disks. Ian -- Ian Freislich ___ 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
fdescfs mount causes hard lock
Hi Since CURRENT Aug 2, my machine has hardlocked at boot time on Mounting local filesystems. I traced it this morning to fdesc /dev/fd fdescfs rw 0 0 Not mounting this stopped the hardlock. I added it because one installed port requeried it, but I can't remember which port that was. Is this related to the panic recently reported by David Wolfskill? Ian -- Ian Freislich ___ 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: High Network Perfomance
Victor Detoni wrote: Hi Guys, I'm trying tunning a FreeBSD 8.2 to high perfomance network with pf. My server configuration is: Dell 1950 CPU: Intel(R) Xeon(R) CPU5130 @ 2.00GHz (1995.03-MHz K8-class CPU) 4 x CPU 2 NIC (Broadcom NetXtreme II BCM5708 1000Base-T) 1 NIC (em0: Intel(R) PRO/1000 Network Connection 7.1.9) I want to reach the high processing of packets per second and use pf as synproxy and we still processor to handle others packets or flows. Benchmarking I did a few years ago showed a strong correlation between forwarding rate and CPU L1 cache size. As well as an inverse relationship to the number of CPUs in the system. At the time, some architectures were worse than others. Intel Pentium4/Xeons had a halving and AMD Opteron/Athlon had about a 7% reduction in forwarding rate with SMP compared to UP. I haven't had the chance to re-run these tests recently. Set net.inet.ip.fastforwarding=1 and run benchmarks to test your forwarding rates with different configurations. See for some results: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=77846+0+archive/2008/freebsd-net/20080120.freebsd-net Ian -- Ian Freislich ___ 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: howto: enabling journaling on softupdates
Niclas Zeising wrote: Can you please detail a little more the steps you took to enable SU+J and your experience with it? It sounds like a good start for a howto or an inclusion in the handbook. It's really simple... You need a kernel compiled with options SOFTUPDATES # Enable FFS soft updates support In single-user mode or unmounted filesystems: tunefs -j enable device Ian -- Ian Freislich ___ 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
3 show-stopper issues with 9-BETA3
Hi In no particular order: 1. bce(4) transmit and recieve ring buffer overruns On a moderately busy router with a full BGP table and aggregate throughput of between 200mbps and 800mbps, I get these buffer overruns at an average rate of 28 per second on the busiest interface. [firewall1.jnb1] ~ # sysctl dev.bce |grep com_no_buffers dev.bce.0.com_no_buffers: 101 dev.bce.1.com_no_buffers: 0 dev.bce.2.com_no_buffers: 32547 dev.bce.3.com_no_buffers: 444 I've tried increasing the TX_PAGES and RX_PAGES in sys/dev/bce/if_bcereg.h as I've done in the past (to 64) which is what resolved this problem on 8.2-STABLE to no avail. It appears that there is a hard limit of 8 according to bce_set_tunables() in if_bce.c. But no values to hw.bce.tx_pages and hw.bce.rx_pages makes the slightest difference. 2. carp(4) on my backup router randomly takes over MASTER on the standby host, but when ifconfig claims the carp interface is master tcpdump shows that it's not broadcasting its advertisement. The actual master still broadcasts and no setting of advskew or advbase changes the 9-BETA host's idea of who is actually master. I have to reboot the host to reset the carp interfaces. destroying and re-creating them just brings them up as backup for about a second and then they regress to master. 3. PF doesn't expire state. The state table on my older host (pre OpenBSD-4.5) has the following stats: Status: Enabled for 0 days 00:37:17 Debug: Urgent State Table Total Rate current entries 169546 searches9438745142193.8/s inserts 4012389 1793.6/s removals 3842843 1717.9/s The 9-BETA3 host's current entries exactly match the number of inserts until it hits the hard limit of 1.5M entries and can add no more. It takes about 10 minutes to fill up and then no new flows are routed. We're in a quiet period at the moment, so I can keep a 9-X host around for a few days. I'll be able to try things until I have to downgrade the other host at the end of the week. Incompatibility between pf on 8.2-STABLE and 9-X after 2011-06-28 makes testing a little difficult though because I'm not able to synchronise state. FWIW, the tuning that has been done eliminates the issue on 8.2-STABLE: [firewall1.jnb1] ~ # cat /boot/loader.conf net.isr.maxthreads=8 net.isr.defaultqlimit=4096 net.isr.maxqlimit=81920 net.isr.direct=1 kern.ipc.nmbclusters=262144 kern.maxusers=1024 [firewall1.jnb1] ~ # cat /etc/sysctl.conf net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.ip.fastforwarding=1 net.inet.carp.preempt=1 net.inet.icmp.icmplim_output=0 net.inet.icmp.icmplim=0 kern.random.sys.harvest.interrupt=0 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.point_to_point=0 net.route.netisr_maxqlen=8192 diff -u -d -r1.26.2.7 if_bcereg.h --- if_bcereg.h 15 Aug 2010 23:56:57 - 1.26.2.7 +++ if_bcereg.h 5 Oct 2011 14:29:15 - @@ -6150,7 +6150,7 @@ * Page count must remain a power of 2 for all * of the math to work correctly. */ -#define TX_PAGES 2 +#define TX_PAGES 64 #define TOTAL_TX_BD_PER_PAGE (BCM_PAGE_SIZE / sizeof(struct tx_bd)) #define USABLE_TX_BD_PER_PAGE (TOTAL_TX_BD_PER_PAGE - 1) #define TOTAL_TX_BD (TOTAL_TX_BD_PER_PAGE * TX_PAGES) @@ -6170,7 +6170,7 @@ * Page count must remain a power of 2 for all * of the math to work correctly. */ -#define RX_PAGES 2 +#define RX_PAGES 64 #define TOTAL_RX_BD_PER_PAGE (BCM_PAGE_SIZE / sizeof(struct rx_bd)) #define USABLE_RX_BD_PER_PAGE (TOTAL_RX_BD_PER_PAGE - 1) #define TOTAL_RX_BD (TOTAL_RX_BD_PER_PAGE * RX_PAGES) Ian -- Ian Freislich ___ 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: PF NAT issue with 9.0-BETA3 and RELENG_9 'head'
Florian Wilkemeyer wrote: On Tue, Oct 18, 2011 at 6:16 PM, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote: Hello, i recently switched a router in our test-environment to FreeBSD 9.0-Beta= 3 (and after things didnt worked ... checked out the current RELENG_9 and recompiled kernel world .. ) freebsd-pf archives might be a good start and the better list ... Okay, thanks i'll post it there.. Did you by chance, run out of state entries? I believe the work-around is to load pf as a module until the issue is fixed. Ian -- Ian Freislich ___ 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
Speaking of ship blockers for 9....
Garrett Cooper Is this is in 9.1 -PRERELEASE, -RELEASE (or whatever the official label is...)? If so, it seems like this would be a ship blocker. I have a problem that's been getting progressively worse as the source progresses. So much so that it's had me searching all the way from 8.0-RELEASE to 10-CURRENT without luck on both amd64 and i386. pf(4) erroneously mismatches state and then blocks an active flow. It seems that 8.X does so silently and 9 to -CURRENT do so verbosely. Whether silent or loud, the effect on traffic makes it impracticle to use FreeBSD+PF for a firewall in any setting (my use is home, small office, large office and moderately large datacenter core router). It appears that this has actually been a forever problem that just being tickled more now. Here's from my home firewall: Status: Enabled for 7 days 02:57:58 Debug: Urgent State Table Total Rate current entries 1653 searches45792251 74.4/s inserts 4283750.7/s removals 4267220.7/s ... state-mismatch 15860.0/s Here's from a moderately busy firewall: Status: Enabled for 0 days 21:40:44 Debug: Urgent State Table Total Rate current entries 122395 searches 442864168556745.4/s inserts202644593 2596.5/s removals 202522198 2595.0/s ... state-mismatch2777673.6/s That's 277767 flows terminated in the last almost 22 hours due to this pf bug. (!!!) 9.1-PRERELEASE logs (as does -CURRENT): Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60985, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:52995, a1: 41.154.2.100:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60095, a1: 206.223.136.200:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:50463, a1: 206.223.136.200:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:56748, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if=tun0, stored af=2, a0: 10.0.2.220:60793, a1: 192.41.162.30:53, proto=17, found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Ian -- Ian Freislich ___ 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: Speaking of ship blockers for 9....
Gleb Smirnoff wrote: Let me give you link to my branch of pf: http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006662.html In that branch the code that puts the reverse pointer on state keys, as well as the m_addr_changed() function and the pf_compare_state_keys() had been cut away. So, this exact bug definitely can't be reproduced there. However, others may hide in :) Thanks. I'll be able to work on this next week. My system is pretty similar to yours - 16 cores, full BGP RIB, 20+ VLANs + CARP on 4*bce(4), PF+Sync, 400k+ states, NAT, tables, anchors etc. The complication is that the production system is on 8 and the pfsync is incompatible with 9 and CURRENT. And, 9/CURRENT is unuseable for me as a backup without this fix because of the state mismatch rate. Ian -- Ian Freislich ___ 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: Speaking of ship blockers for 9....
Gleb Smirnoff wrote: I Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if= I tun0, stored af=2, a0: 10.0.2.220:60985, a1: 192.41.162.30:53, proto=17, I found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Let me give you link to my branch of pf: http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006662.html In that branch the code that puts the reverse pointer on state keys, as well as the m_addr_changed() function and the pf_compare_state_keys() had been cut away. So, this exact bug definitely can't be reproduced there. However, others may hide in :) Let me encourage you to try and test my branch (instructions in URLs above). I do see much better performance, however, I'm seeing this panic after about 23 minutes (the slightly higher uptime was a result of a manual fsck). This system is not particularly loaded. It's a UP Pentium-m which is our office gateway. I can give you access to inspect if you like. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc046f8f4 stack pointer = 0x28:0xeb7b7bd8 frame pointer = 0x28:0xeb7b7bec code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 4 (pf purge) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c0819c2b,eb7b7a78,c05d5829,c0816ff2,c08acca0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0816ff2,c08acca0,c07f2736,eb7b7a84,eb7b7a84,...) at kdb_backtrace+0x29 panic(c07f2736,c0845a85,c559fd68,1,1,...) at panic+0xc9 trap_fatal(0,c60c826c,c610b31c,c610ac44,8,...) at trap_fatal+0x353 trap_pfault(eb7b7b18,c05c0a2d,c0ecc500,c0ecc608,c54ec000,...) at trap_pfault+0xd9 trap(eb7b7b98) at trap+0x418 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc046f8f4, esp = 0xeb7b7bd8, ebp = 0xeb7b7bec --- pf_state_key_detach(eb7b7c18,c046af2a,502a6f69,0,8000,...) at pf_state_key_detach+0x74 pf_detach_state(c64d5d00,0,8000,0,c559fbc0,...) at pf_detach_state+0x1c6 pf_unlink_state(c64d5d00,1,0,0,c0870398,...) at pf_unlink_state+0x1c5 pf_purge_expired_states(c08947c0,0,0,c07eadbf,64,...) at pf_purge_expired_states+0xe6 pf_purge_thread(0,eb7b7d08,0,c54ec000,0,...) at pf_purge_thread+0x14f fork_exit(c0471b60,0,eb7b7d08) at fork_exit+0xa2 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xeb7b7d40, ebp = 0 --- Uptime: 57m29s Physical memory: 2038 MB Dumping 189 MB: 174 158 142 126 110 94 78 62 46 30 14 (kgdb) bt #0 doadump (textdump=1) at pcpu.h:249 #1 0xc05d563a in kern_reboot (howto=260) at /usr/src.pflock/sys/kern/kern_shutdown.c:449 #2 0xc05d5888 in panic (fmt=Variable fmt is not available.) at /usr/src.pflock/sys/kern/kern_shutdown.c:637 #3 0xc07b8b23 in trap_fatal (frame=0xeb7b7b98, eva=0) at /usr/src.pflock/sys/i386/i386/trap.c:1028 #4 0xc07b8c09 in trap_pfault (frame=0xeb7b7b98, usermode=0, eva=0) at /usr/src.pflock/sys/i386/i386/trap.c:881 #5 0xc07b9a58 in trap (frame=dwarf2_read_address: Corrupted DWARF expression.) at /usr/src.pflock/sys/i386/i386/trap.c:552 #6 0xc07a579c in calltrap () at /usr/src.pflock/sys/i386/i386/exception.s:169 #7 0xc046f8f4 in pf_state_key_detach (s=0xc64d5d00, idx=1) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1040 #8 0xc04713f6 in pf_detach_state (s=0xc64d5d00) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1006 #9 0xc0471975 in pf_unlink_state (s=0xc64d5d00, flags=Variable flags is not available.) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1520 #10 0xc0471a96 in pf_purge_expired_states (maxcheck=148) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1573 #11 0xc0471caf in pf_purge_thread (v=0x0) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1371 #12 0xc05a5af2 in fork_exit (callout=0xc0471b60 pf_purge_thread, arg=0x0, frame=0xeb7b7d08) at /usr/src.pflock/sys/kern/kern_fork.c:995 #13 0xc07a5814 in fork_trampoline () at /usr/src.pflock/sys/i386/i386/exception.s:276 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
Lev Serebryakov wrote: Hello, Lev. You wrote 15 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2012 =D0=B3., 0:45:= 42: LS Answer looks trivial: router CPU is bottleneck. But here is one additi= onal LS detail: `top' never shows less than 50% of idle when torrents are LS active. And `idle' time with torrents traffic is ALWAYS is higher than LS without them, but with WiFi traffic. Ok, additional information: it seems, that `top' is liar when POLLING is enabled for em0 and vr1 NICs. I'm turned POLLING off, and speeds are the same, but `idle' is no more 50%, it is `0%' when gateway is overloaded. But i still feezes under load with ULE. It looks like ULE is broken. Are you sure it's a freeze and not a panic? I'm seeing very frequent panics on -CURRENT running as a gateway. Often, it doesn't come back without a powercycle because it's unable to complete a crashdump. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
Lev Serebryakov wrote: Hello, Lev. You wrote 15 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2012 =D0=B3., 0:45:= 42: LS Answer looks trivial: router CPU is bottleneck. But here is one additi= onal LS detail: `top' never shows less than 50% of idle when torrents are LS active. And `idle' time with torrents traffic is ALWAYS is higher than LS without them, but with WiFi traffic. Ok, additional information: it seems, that `top' is liar when POLLING is enabled for em0 and vr1 NICs. I'm turned POLLING off, and speeds are the same, but `idle' is no more 50%, it is `0%' when gateway is overloaded. But i still feezes under load with ULE. It looks like ULE is broken. Are you sure it's a freeze and not a panic? I'm seeing very frequent panics on -CURRENT running as a gateway. Often, it doesn't come back without a powercycle because it's unable to complete a crashdump. Ian -- Ian Freislich ___ 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
Panic on use of deleted route.
Hi I was wondering if anyone else is seeing this... I get a panic shortly after ppp(8) exits. I haven't been able to get a crashdump from a recent -CURRENT system, so in that absence, I'll include output from an older system. Interestingly, the route partially persists past the destruction of the interface. And the panic is triggered apparently by the use of the route. I've also been unable to delete routes added on the system. We're running a kernel compiled with options RADIX_MPATH. [root@pbx ~]# pppctl -p pass 3000 quit all Connection closed [root@pbx ~]# ifconfig tun0 ifconfig: interface tun0 does not exist [root@pbx ~]# netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire defaulttun0 US 04 Here's the crash from another system: KDB: stack backtrace: #0 0x8051ed16 at kdb_backtrace+0x66 #1 0x804e828e at panic+0x1ce #2 0x806dcff0 at trap_fatal+0x290 #3 0x806dd327 at trap_pfault+0x1e7 #4 0x806dd92e at trap+0x3be #5 0x806c792f at calltrap+0x8 #6 0x805a975c at rn_walktree+0x7c #7 0x805b085e at sysctl_rtsock+0x2ee #8 0x804f1bd8 at sysctl_root+0x128 #9 0x804f1eb5 at userland_sysctl+0x145 #10 0x804f23ea at sys___sysctl+0xaa #11 0x806dc910 at amd64_syscall+0x530 #12 0x806c7c17 at Xfast_syscall+0xf7 Uptime: 2d12h15m1s #0 doadump (textdump=Variable textdump is not available. ) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=Variable textdump is not available. ) at pcpu.h:229 #1 0x804e7d74 in kern_reboot (howto=260) at /usr/src.pflock/sys/kern/kern_shutdown.c:449 #2 0x804e8267 in panic (fmt=0x1 Address 0x1 out of bounds) at /usr/src.pflock/sys/kern/kern_shutdown.c:637 #3 0x806dcff0 in trap_fatal (frame=0xc, eva=Variable eva is not available. ) at /usr/src.pflock/sys/amd64/amd64/trap.c:853 #4 0x806dd327 in trap_pfault (frame=0xff82355bf6b0, usermode=0) at /usr/src.pflock/sys/amd64/amd64/trap.c:770 #5 0x806dd92e in trap (frame=0xff82355bf6b0) at /usr/src.pflock/sys/amd64/amd64/trap.c:458 #6 0x806c792f in calltrap () at /usr/src.pflock/sys/amd64/amd64/exception.S:228 #7 0x805ae525 in sysctl_dumpentry (rn=0xfe0007398e10, vw=Variable vw is not available. ) at /usr/src.pflock/sys/net/rtsock.c:1527 #8 0x805a975c in rn_walktree (h=Variable h is not available. ) at /usr/src.pflock/sys/net/radix.c:1112 #9 0x805b085e in sysctl_rtsock (oidp=Variable oidp is not available. ) at /usr/src.pflock/sys/net/rtsock.c:1888 #10 0x804f1bd8 in sysctl_root (oidp=Variable oidp is not available. ) at /usr/src.pflock/sys/kern/kern_sysctl.c:1513 #11 0x804f1eb5 in userland_sysctl (td=Variable td is not available. ) at /usr/src.pflock/sys/kern/kern_sysctl.c:1623 #12 0x804f23ea in sys___sysctl (td=0xfe0007189000, uap=0xff82355bfb70) at /usr/src.pflock/sys/kern/kern_sysctl.c:1549 #13 0x806dc910 in amd64_syscall (td=0xfe0007189000, traced=0) at subr_syscall.c:135 #14 0x806c7c17 in Xfast_syscall () at /usr/src.pflock/sys/amd64/amd64/exception.S:387 #15 0x000801debc6c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- Ian Freislich ___ 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: r240825 -current fault with backtrace
Gleb Smirnoff wrote: On Sat, Sep 22, 2012 at 02:13:58PM -0400, Kim Culhan wrote: K serial terminal not available, backtrace is a screen pic: Why didn't you make dump? db call doadump I reliably get this panic on my routers when I reboot the carp backup. Shortly after the syncdev: igb0 looses link, the running sync host panics: db bt Tracing pid 11 tid 100123 td 0xfe000b053480 m_copym() at m_copym+0x37 ip_fragment() at ip_fragment+0x1c4 ip_output() at ip_output+0x6c1 pfsyncintr() at pfsyncintr+0xf5 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd ithread_loop() at ithread_loop+0x9e fork_exit() at fork_exit+0x11e fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8463866cb0, rbp = 0 --- My kernel dumps are however useless. I do have serial console to do whatever debugging we may need. Ian -- Ian Freislich ___ 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: [head tinderbox] failure on arm/arm
FreeBSD Tinderbox wrote: cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict -prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-sh ow-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contri b/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-comm on -finline-limit=8000 --param inline-unit-growth=100 --param large-function-gr owth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/ata/ata-sata.c /src/sys/dev/ata/ata-sata.c: In function 'ata_sata_phy_reset': /src/sys/dev/ata/ata-sata.c:158: error: 'struct ata_channel' has no member na med 'user' *** Error code 1 ata_channel member user is only defined if ATA_CAM is defined. Ian -- Ian Freislich ___ 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: Dynamic Ticks/HZ
Joe Holden wrote: It looks like the device polling is what was causing it, once I'd removed that from kernconf it returned to normal - full interupt rate is ok though if I can increase the rate to a decent level FWIW, this is how my igb(4) system is tuned and with PF, it's able to fill 4xigb interfaces: /boot/loader.conf: # 16 CPUs net.isr.maxthreads=8 net.isr.defaultqlimit=4096 net.isr.maxqlimit=81920 net.isr.direct=1 net.isr.direct_force=1 net.isr.bindthreads=0 kern.ipc.nmbclusters=262144 hw.igb.max_interrupt_rate=32000 hw.igb.rx_process_limit=500 hw.igb.header_split=1 #This setting doesn't seem to work hw.igb.txd=4096 hw.igb.rxd=4096 /etc/sysctl.conf: net.inet.ip.fastforwarding=1 kern.random.sys.harvest.interrupt=0 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.point_to_point=0 Ian -- Ian Freislich ___ 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
cvsup/csup servers stale?
Hi Has the svn-cvs exporter died? Or have the cvsup/csup servers been retired as threatened in a previous thread (I might have missed the headsup)? Ian -- Ian Freislich ___ 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
netisr panic?
Hi
I have this consistently with:
FreeBSD firewall2.jnb1.gp-online.net 10.0-CURRENT FreeBSD 10.0-CURRENT #30
r243156: Fri Nov 16 20:12:33 SAST 2012
i...@firewall2.jnb1.gp-online.net:/usr/obj/usr/src/sys/FIREWALL amd64
Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0xc
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x8050f534
stack pointer = 0x28:0xff846384e9c0
frame pointer = 0x28:0xff846384ea00
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 11 (irq266: igb1:que 0)
trap number = 12
panic: page fault
cpuid = 4
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x1ce
trap_fatal() at trap_fatal+0x290
trap_pfault() at trap_pfault+0x21f
trap() at trap+0x2b4
calltrap() at calltrap+0x8
--- trap 0xc, rip = 0x8050f534, rsp = 0xff846384e9c0, rbp =
0xff846384ea00 ---
ether_nh_input() at ether_nh_input+0x94
netisr_dispatch_src() at netisr_dispatch_src+0x212
igb_rxeof() at igb_rxeof+0x3f0
igb_msix_que() at igb_msix_que+0xfa
intr_event_execute_handlers() at intr_event_execute_handlers+0xfd
ithread_loop() at ithread_loop+0x9e
fork_exit() at fork_exit+0x11e
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff846384ecb0, rbp = 0 ---
Uptime: 2h2m15s
Dumping 1241 out of 16368 MB:..2%..11%..21%..31%..42%..51%..61%..71%..82%..91%
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266
266 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266
#1 0x8044af04 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:449
#2 0x8044b487 in panic (fmt=0x1 Address 0x1 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:637
#3 0x80605bd0 in trap_fatal (frame=0xc, eva=value optimized out)
at /usr/src/sys/amd64/amd64/trap.c:872
#4 0x80605f3f in trap_pfault (frame=0xff846384e910, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:789
#5 0x806062f4 in trap (frame=0xff846384e910)
at /usr/src/sys/amd64/amd64/trap.c:463
#6 0x805eff6f in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#7 0x8050f534 in ether_nh_input (m=0xfe012521e700)
at /usr/src/sys/net/if_ethersubr.c:484
#8 0x8051a602 in netisr_dispatch_src (proto=9,
source=value optimized out, m=value optimized out)
at /usr/src/sys/net/netisr.c:1013
#9 0x803188b0 in igb_rxeof (que=0xfe000a183800, count=499,
done=0x0) at /usr/src/sys/dev/e1000/if_igb.c:4688
#10 0x803218da in igb_msix_que (arg=value optimized out)
at /usr/src/sys/dev/e1000/if_igb.c:1596
#11 0x804208cd in intr_event_execute_handlers (
p=value optimized out, ie=0xfe000a19f100)
at /usr/src/sys/kern/kern_intr.c:1272
#12 0x804220fe in ithread_loop (arg=0xfe000a1c6660)
at /usr/src/sys/kern/kern_intr.c:1285
#13 0x8041d52e in fork_exit (
callout=0x80422060 ithread_loop, arg=0xfe000a1c6660,
frame=0xff846384ec00) at /usr/src/sys/kern/kern_fork.c:995
#14 0x805f042e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:602
#15 0x in ?? ()
--
Meditating Guru
Ian Freislich
___
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: netisr panic?
Adrian Chadd wrote:
It's a NULL ponter deref. This is my line 484 in if_ethersubr.c:
eh = mtod(m, struct ether_header *);
.. if that's yours, see if eh is NULL?
(kgdb) frame 7
#7 0x8050f534 in ether_nh_input (m=0xfe012521e700)
at /usr/src/sys/net/if_ethersubr.c:484
484 eh = mtod(m, struct ether_header *);
(kgdb) print eh
No symbol eh in current context.
(kgdb) print *m
$2 = {m_hdr = {mh_next = 0x100, mh_nextpkt = 0x100,
mh_data = 0x0, mh_len = 60, mh_flags = 4259842, mh_type = 0,
pad = \000\000\000\000\000}, M_dat = {MH = {MH_pkthdr = {
rcvif = 0xfe000a1c2000, header = 0x, len = 60, flowid = 0,
csum_flags = 3840, csum_data = 65535, tso_segsz = 0, PH_vt = {
vt_vtag = 4, vt_nrecs = 4}, tags = {slh_first = 0x3c00}},
MH_dat = {MH_ext = {
ext_buf = 0x69e54986 Address 0x69e54986 out of
bounds, ext_free = 0x10602, ext_arg1 = 0xc0007, ext_arg2 = 0x100,
ext_size = 2048, ref_cnt = 0xfe0125236d8c, ext_type = 6},
MH_databuf =
\000\000\000\000\206Iåi\002\006\001\000\000\000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\214m#%\001þÿÿ\006,
'\0' repeats 118 times}},
M_databuf = \000
\034\n\000þÿÿ\000\000\000\000\000\000\000\000\000\000\000\000\017\000\000ÿÿ\000\000\000\000\004\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\206Iåi\002\006\001\000\000\000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\214m#%\001þÿÿ\006,
'\0' repeats 118 times}}
Ian
--
Ian Freislich
___
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: netisr panic?
Gleb Smirnoff wrote: On Sat, Nov 17, 2012 at 05:07:54PM +0200, Ian FREISLICH wrote: I I have this consistently with: I I FreeBSD firewall2.jnb1.gp-online.net 10.0-CURRENT FreeBSD 10.0-CURRENT #30 r243156: Fri Nov 16 20:12:33 SAST 2012 i...@firewall2.jnb1.gp-online.net:/ usr/obj/usr/src/sys/FIREWALL amd64 Pretty sure this is a new version of wrong byte order panic, which no longer can happen in HEAD. Can you please try this patch? It survived the night, which it hasn't managed before. I'll keep you posted. Ian -- Ian Freislich ___ 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: netisr panic?
Ian FREISLICH wrote:
Gleb Smirnoff wrote:
On Sat, Nov 17, 2012 at 05:07:54PM +0200, Ian FREISLICH wrote:
I I have this consistently with:
I
I FreeBSD firewall2.jnb1.gp-online.net 10.0-CURRENT FreeBSD 10.0-CURRENT #
30
r243156: Fri Nov 16 20:12:33 SAST 2012 i...@firewall2.jnb1.gp-online.net
:/
usr/obj/usr/src/sys/FIREWALL amd64
Pretty sure this is a new version of wrong byte order panic, which
no longer can happen in HEAD.
Can you please try this patch?
It survived the night, which it hasn't managed before. I'll keep you posted.
Jubilation short lived:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xc
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x8050f494
stack pointer = 0x28:0xff84637a19d0
frame pointer = 0x28:0xff84637a1a10
code segment= base 0x0, limit 0xf, type 0x1b
Fatal trap 12: page fault while in kernel mode
= DPL 0, pres 1, long 1, def32 0, gran 1
cpuid = 7; apic id = 07
processor eflags= fault virtual address = 0xc
interrupt enabled, fault code = supervisor read data, page not present
resume, IOPL = 0
instruction pointer = 0x20:0x8050f494
stack pointer = 0x28:0xff846386c9d0
current process = 11 (irq261: igb0:que 0)
frame pointer = 0x28:0xff846386ca10
trap number = 12
code segment= base 0x0, limit 0xf, type 0x1b
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x1ce
trap_fatal() at trap_fatal+0x290
trap_pfault() at trap_pfault+0x21f
trap() at trap+0x2b4
calltrap() at calltrap+0x8
--- trap 0xc, rip = 0x8050f494, rsp = 0xff84637a19d0, rbp =
0xff84637a1a10 ---
ether_nh_input() at ether_nh_input+0x94
netisr_dispatch_src() at netisr_dispatch_src+0x212
igb_rxeof() at igb_rxeof+0x384
igb_msix_que() at igb_msix_que+0xfa
intr_event_execute_handlers() at intr_event_execute_handlers+0xfd
ithread_loop() at ithread_loop+0x9e
fork_exit() at fork_exit+0x11e
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff84637a1cb0, rbp = 0 ---
Uptime: 19h5m45s
Dumping 2654 out of 16368 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266
266 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266
#1 0x8044ae64 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:449
#2 0x8044b3e7 in panic (fmt=0x1 Address 0x1 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:637
#3 0x80605b30 in trap_fatal (frame=0xc, eva=value optimized out)
at /usr/src/sys/amd64/amd64/trap.c:872
#4 0x80605e9f in trap_pfault (frame=0xff84637a1920, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:789
#5 0x80606254 in trap (frame=0xff84637a1920)
at /usr/src/sys/amd64/amd64/trap.c:463
#6 0x805efecf in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#7 0x8050f494 in ether_nh_input (m=0xfe004f3bde00)
at /usr/src/sys/net/if_ethersubr.c:484
#8 0x8051a562 in netisr_dispatch_src (proto=9,
source=value optimized out, m=value optimized out)
at /usr/src/sys/net/netisr.c:1013
#9 0x80318844 in igb_rxeof (que=0xfe000a183a00, count=499,
done=0x0) at /usr/src/sys/dev/e1000/if_igb.c:4688
#10 0x8032183a in igb_msix_que (arg=value optimized out)
at /usr/src/sys/dev/e1000/if_igb.c:1596
#11 0x8042082d in intr_event_execute_handlers (
p=value optimized out, ie=0xfe000a109e00)
at /usr/src/sys/kern/kern_intr.c:1272
#12 0x8042205e in ithread_loop (arg=0xfe000a1a16e0)
at /usr/src/sys/kern/kern_intr.c:1285
#13 0x8041d48e in fork_exit (
callout=0x80421fc0 ithread_loop, arg=0xfe000a1a16e0,
frame=0xff84637a1c00) at /usr/src/sys/kern/kern_fork.c:995
#14 0x805f038e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:602
#15 0x in ?? ()
--
Meditating Guru
Ian Freislich
___
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
ixgbe(4) and SFP+ (un)supported module
Hi
I've just had this card installed in our servers:
ix0@pci0:12:0:0:class=0x02 card=0x7a118086 chip=0x10fb8086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = '82599EB 10-Gigabit SFI/SFP+ Network Connection'
class = network
subclass = ethernet
cap 01[40] = powerspec 3 supports D0 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit, vector masks
cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled
cap 10[a0] = PCI-Express 2 endpoint max data 512(512) FLR link x8(x8)
speed 2.5(5.0)
cap 03[e0] = VPD
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0003[140] = Serial 1 90e2ba2b92e8
ecap 000e[150] = ARI 1
ecap 0010[160] = SRIOV 1
Which yielded the following error initializing the driver:
ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.0 port 0xbcc
ix0: Using MSIX interrupts with 9 vectors
ix0: Unsupported SFP+ Module
device_attach: ix0 attach returned 5
ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.0 port 0xbce
ix0: Using MSIX interrupts with 9 vectors
ix0: Unsupported SFP+ Module
device_attach: ix0 attach returned 5
ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.0 port 0xbcc
ix0: Using MSIX interrupts with 9 vectors
ix0: Unsupported SFP+ Module
device_attach: ix0 attach returned 5
ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.0 port 0xbce
ix0: Using MSIX interrupts with 9 vectors
ix0: Unsupported SFP+ Module
device_attach: ix0 attach returned 5
The README in /usr/src/sys/dev/ixgbe claims that the module we have,
AFBR-703SDZ-IN is supported. I had to make the following change
to get the driver to attach. I get the feeling it's not the
correct fix however:
[firewall2.jnb1] /usr/src/sys/dev/ixgbe # svn diff
Index: ixgbe_phy.c
===
--- ixgbe_phy.c (revision 243808)
+++ ixgbe_phy.c (working copy)
@@ -955,7 +955,7 @@
u8 oui_bytes[3] = {0, 0, 0};
u8 cable_tech = 0;
u8 cable_spec = 0;
- u16 enforce_sfp = 0;
+ u16 enforce_sfp = 1;
DEBUGFUNC(ixgbe_identify_sfp_module_generic);
Ian
--
Ian Freislich
___
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: ixgbe(4) and SFP+ (un)supported module
Jack Vogel wrote: Look again closely, AFBR-703SDZ-IN2 and AFBR-703SDDZ-IN1 are supported, AFBR-703SDZ-IN is not. Sorry, that was a cutpasto. We have the AFBR-703SDZ-IN2. The full detail from the box according the guy on site is: AFBR-703SDZ-IN2 (INTEL)FTLX8571D3BCL Ian -- Ian Freislich ___ 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
route add ... -iface fails
Hi This used to work on tunX, but no more. tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1492 options=8LINKSTATE inet 41.135.82.18 -- 41.135.70.1 netmask 0x Opened by PID 2387 [router] ~ # route add 41.154.2.53 -iface tun0 route: bad address: tun0 It also doesn't work on ngX PPP interfaces. ng2: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST metric 0 mtu 1490 inet 41.135.82.120 -- 41.135.70.1 netmask 0x [router] ~ # route add 41.154.2.53 -iface ng2 route: bad address: ng2 [router] ~ # route add 41.154.2.53 -interface ng2 route: bad address: ng2 I have several PPP conections on several ADSL lines with the same provider that doesn't do multi link PPP, so I need to be able to set the destination interface. Ian -- Meditating Guru Ian Freislich ___ 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
-iface option to route(8) is broken
Hi Adding routes using the -iface option to route(8) doesn't work any more. This was useful to select a specific interface for a route when the remote gateway has the same IP address. Are there plans to restore this functionality? tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1492 options=8LINKSTATE inet 41.135.82.18 -- 41.135.70.1 netmask 0x Opened by PID 2387 [router] ~ # route add 41.154.2.53 -iface tun0 route: bad address: tun0 It also doesn't work on ngX PPP interfaces. ng1: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST metric 0 mtu 1490 inet 197.87.27.111 -- 41.135.70.1 netmask 0x ng2: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST metric 0 mtu 1490 inet 41.135.82.120 -- 41.135.70.1 netmask 0x [router] ~ # route add 41.154.2.53 -iface ng2 route: bad address: ng2 [router] ~ # route add 41.154.2.53 -interface ng2 route: bad address: ng2 Ian -- Ian Freislich ___ 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: Awkward booting issue
Mark wrote: Hi, I have been trying to get FreeBSD 9 amd64 to boot on my 1U server but am unsuccesful and am out of ideas. I tried to boot the iso from CD-ROM, I tried multiple USB memory sticks and I even tried to boot from hard discs, I'll explain this further below. Oddly enough every boot attempt fails. Right after the hard discs are recognised the system just sits there, silent, with no errors. The last Have you tried waiting a long long long time? I have a problem where the boot hangs but it does actually eventually boot. The most infomation I managed to get out of the system before I had to give up and revert to the previous config was that although Hz was configured as 1000, it was only ticking 19 times a second, so machine time was running about 50 slower than wallclock time. You might or not be experiencing the same issue. Ian -- Ian Freislich ___ 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
panic in vfs_lookup/kern_statat_vnhook?
NDINIT_ATRIGHTS(nd, LOOKUP, ((flag AT_SYMLINK_NOFOLLOW) ?
NOFOLLOW :
2430FOLLOW) | LOCKSHARED | LOCKLEAF | AUDITVNODE1 | MPSAFE,
pathseg,
2431path, fd, CAP_FSTAT, td);
2432
2433if ((error = namei(nd)) != 0)
2434return (error);
2435vfslocked = NDHASGIANT(nd);
2436error = vn_stat(nd.ni_vp, sb, td-td_ucred, NOCRED, td);
2437if (!error) {
This same panic was reported some time back in:
Subject: [panic] zfs_zget() panic during 'svn update'
From: Glen Barber g...@freebsd.org
Date: Thu, 17 May 2012 16:18:51 -0400
To: freebsd-current@FreeBSD.org
http://people.freebsd.org/~gjb/zfs_zget-panic.kgdb.txt
Ian
--
Ian Freislich
___
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: panic in vfs_lookup/kern_statat_vnhook?
John Baldwin wrote:
On Tuesday, May 22, 2012 2:36:06 pm Ian FREISLICH wrote:
Hi
I've had quite a few reproduceable panics that look to be VFS
related. The trigger is relatively heavy concurrent disk IO.
I can trigger it easily two ways:
1. running my backup script which essentially does:
cd /; rsync --one-file-system --delete -aHv . /backup
cd /tmp; rsync --one-file-system --delete -aHv . /backup/tmp
cd /usr; rsync --one-file-system --delete -aHv . /backup/usr
cd /var; rsync --one-file-system --delete -aHv . /backup/var
2. While updating with cvsup or csup, launch firefox.
Both reliably provoke the panic:
#0 doadump (textdump=1) at pcpu.h:244
#1 0xc06aa895 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:454
#2 0xc06aad36 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:642
#3 0xc087adee in trap_fatal (frame=0xedb365c8, eva=28)
at /usr/src/sys/i386/i386/trap.c:1022
#4 0xc087aed8 in trap_pfault (frame=0xedb365c8, usermode=0, eva=28)
at /usr/src/sys/i386/i386/trap.c:875
#5 0xc087bc4d in trap (frame=0xedb365c8) at /usr/src/sys/i386/i386/trap.c:
546
#6 0xc086687c in calltrap () at /usr/src/sys/i386/i386/exception.s:169
#7 0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 '\a'
,
m=0xc3073f70, prot=7 '\a', wired=1) at /usr/src/sys/i386/i386/pmap.c:15
96
This is the actual panic. Can you go to this frame? The VFS bits don't
matter, the pmap code blew up trying to malloc another vnode.
(kgdb) frame 7
#7 0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 '\a',
m=0xc191bf70, prot=7 '\a', wired=1) at /usr/src/sys/i386/i386/pmap.c:1596
1596root = vm_page_splay(mpte-pindex, root);
(kgdb) l
1591root = pmap-pm_root;
1592if (root == NULL) {
1593mpte-left = NULL;
1594mpte-right = NULL;
1595} else {
1596root = vm_page_splay(mpte-pindex, root);
1597if (mpte-pindex root-pindex) {
1598mpte-left = root-left;
1599mpte-right = root;
1600root-left = NULL;
Ian
--
Ian Freislich
___
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
(no subject)
John Baldwin wrote:
On Wednesday, May 23, 2012 12:28:53 am Ian FREISLICH wrote:
(kgdb) frame 7
#7 0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 '\a'
,
m=0xc191bf70, prot=7 '\a', wired=1) at
/usr/src/sys/i386/i386/pmap.c:1596
1596root = vm_page_splay(mpte-pindex, root);
(kgdb) l
1591root = pmap-pm_root;
1592if (root == NULL) {
1593mpte-left = NULL;
1594mpte-right = NULL;
1595} else {
1596root = vm_page_splay(mpte-pindex, root);
1597if (mpte-pindex root-pindex) {
1598mpte-left = root-left;
1599mpte-right = root;
1600root-left = NULL;
Ok, can you do 'p root', 'p mpte', and 'p *mpte'?
(kgdb) frame 7
#7 0xc0878682 in pmap_enter (pmap=0xc09e4060, va=3359633408, access=7 '\a',
m=0xc191bf70, prot=7 '\a', wired=1) at /usr/src/sys/i386/i386/pmap.c:1596
1596root = vm_page_splay(mpte-pindex, root);
(kgdb) p root
No symbol root in current context.
(kgdb) p mpte
$1 = 0x0
(kgdb) p *mpte
Cannot access memory at address 0x0
--
Ian Freislich
___
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: (no subject) (was panic in vfs_lookup/kern_statat_vnhook?)
Konstantin Belousov wrote:
On Wed, May 23, 2012 at 03:42:14PM +0200, Ian FREISLICH wrote:
John Baldwin wrote:
On Wednesday, May 23, 2012 12:28:53 am Ian FREISLICH wrote:
(kgdb) frame 7
#7 0xc0878682 in pmap_enter (pmap=3D0xc09e4060, va=3D3359633408, acc=
ess=3D7 '\a'
,=20
m=3D0xc191bf70, prot=3D7 '\a', wired=3D1) at=20
/usr/src/sys/i386/i386/pmap.c:1596
1596root =3D vm_page_splay(mpte-pindex, root);
(kgdb) l
1591root =3D pmap-pm_root;
1592if (root =3D=3D NULL) {
1593mpte-left =3D NULL;
1594mpte-right =3D NULL;
1595} else {
1596root =3D vm_page_splay(mpte-pindex, root);
1597if (mpte-pindex root-pindex) {
1598mpte-left =3D root-left;
1599mpte-right =3D root;
1600root-left =3D NULL;
=20
Ok, can you do 'p root', 'p mpte', and 'p *mpte'?
=20
(kgdb) frame 7
#7 0xc0878682 in pmap_enter (pmap=3D0xc09e4060, va=3D3359633408, access=
=3D7 '\a',=20
m=3D0xc191bf70, prot=3D7 '\a', wired=3D1) at /usr/src/sys/i386/i386/p=
map.c:1596
1596root =3D vm_page_splay(mpte-pindex, root);
(kgdb) p root
No symbol root in current context.
(kgdb) p mpte
$1 =3D 0x0
(kgdb) p *mpte
Cannot access memory at address 0x0
Do you have r235776 in your tree ? This could be another manifestation of
this bug.
I'm not sure. I'm still using cvs. But, it happened with sources
updated last night if that helps.
Ian
--
Ian Freislich
___
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
uath panic on insert.
Hi I get this panic on insertion of a uath USB dongle. On amd-64: uath0: Atheros Communications Inc USB WLAN Device, rev 2.00/0.01, addr 3 on us bus1 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0x80628f6a stack pointer = 0x28:0xff8112ee3750 frame pointer = 0x28:0xff8112ee37b0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (usbus1) trap number = 12 panic: page fault cpuid = 1 Uptime: 7s Dumping 237 out of 3971 MB:..7%..14%..21%..34%..41%..54%..61%..75%..81%..95% Reading symbols from /boot/kernel/acpi_asus_wmi.ko...Reading symbols from /boot/kernel/acpi_asus_wmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_asus_wmi.ko Reading symbols from /boot/kernel/acpi_wmi.ko...Reading symbols from /boot/kernel/acpi_wmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_wmi.ko Reading symbols from /boot/kernel/if_uath.ko...Reading symbols from /boot/kernel/if_uath.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_uath.ko #0 doadump (textdump=value optimized out) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:229 #1 0x in ?? () The i386 panic is only slightly more useful: ugen4.3: Atheros Communications Inc at usbus4 uath0: Atheros Communications Inc USB WLAN Device, rev 2.00/0.01, addr 3 on us bus4 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc08ae31f stack pointer = 0x28:0xebbf8adc frame pointer = 0x28:0xebbf8b10 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (usbus4) trap number = 12 panic: page fault cpuid = 0 Uptime: 16s Physical memory: 2027 MB Dumping 85 MB: 70 54 38 22 6 Reading symbols from /boot/kernel/acpi_video.ko...Reading symbols from /boot/ker nel/acpi_video.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_video.ko Reading symbols from /boot/kernel/ohci.ko...Reading symbols from /boot/kernel/oh ci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ohci.ko Reading symbols from /boot/kernel/xhci.ko...Reading symbols from /boot/kernel/xh ci.ko.symbols...done. done. Loaded symbols for /boot/kernel/xhci.ko Reading symbols from /boot/kernel/if_uath.ko...Reading symbols from /boot/kernel /if_uath.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_uath.ko Reading symbols from /boot/kernel/u3g.ko...Reading symbols from /boot/kernel/u3g .ko.symbols...done. done. Loaded symbols for /boot/kernel/u3g.ko #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:249 #1 0xc06a69d5 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:446 #2 0xc06a6c32 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:753 #3 0xc08b05ac in trap_fatal (frame=0xebbf8a9c, eva=0) at /usr/src/sys/i386/i386/trap.c:1046 #4 0xc08b06a2 in trap_pfault (frame=0xebbf8a9c, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:899 #5 0xc08b1476 in trap (frame=0xebbf8a9c) at /usr/src/sys/i386/i386/trap.c:556 #6 0xc089b0dc in calltrap () at /usr/src/sys/i386/i386/exception.s:169 #7 0xc08ae31f in bzero () at /usr/src/sys/i386/i386/support.s:56 Previous frame inner to this frame (corrupt stack?) (kgdb) Ian -- Ian Freislich ___ 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: uath panic on insert.
Hans Petter Selasky wrote: On Friday 08 February 2013 19:21:24 Ian FREISLICH wrote: Uptime: 7s Dumping 237 out of 3971 MB:..7%..14%..21%..34%..41%..54%..61%..75%..81%..95% Reading symbols from /boot/kernel/acpi_asus_wmi.ko...Reading symbols from /boot/kernel/acpi_asus_wmi.ko.symbols...done. do Maybe you can also look into /var/crash for more information? This is from /var/crash. The vmcore is quite badly corrupted. [new] /var/crash # kgdb -c vmcore.4 /boot/kernel/kernel GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0x8041a3e4 in doadump () (kgdb) I've just noticed that I had USB_DEBUG=yes set. I'm trying a kernel without that set just in case that tickles an issue. It's been ages (2 years or more) since I used this card so a binary search is nearly out of the question. I'm trying to ressurect it because I got a new laptop with a totally useless new iwn(4) Centrino Advanced-N 6235 card in it that can't do 40MHz channels and can't stay connected to a 20MHz channel for longer than 15 minutes at a stretch. And, the antenna cables have w-FL connectors so I can't just replace it with a good old AR9285. I'm not sure I'll be able to desolder the w-FL connectors and move them to my Atheros card without destroying them. I'll try to capture some more useful debugging data, but it blows up pretty badly when the card is inserted. Ian -- Ian Freislich ___ 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: uath panic on insert.
Hans Petter Selasky wrote: On Friday 08 February 2013 22:43:17 Ian FREISLICH wrote: Hans Petter Selasky wrote: Hi, Your problem should be fixed by: http://svnweb.freebsd.org/changeset/base/246565 Please test and report back if it doesn't. It doesn't panic anymore. Thanks. There's a new problem though: uath0: Atheros Communications Inc USB WLAN Device, rev 2.00/0.01, addr 5 on usbus1 wlan1: Ethernet address: 00:11:95:d3:4a:af Hi, Can you try this patch: http://svnweb.freebsd.org/changeset/base/246570 ugen1.5: Atheros Communications Inc at usbus1 Atheros Communications Inc USB WLAN Device, rev 2.00/0.01, addr 5 on usbus1 Ethernet address: 00:11:95:d3:4a:af uath_cmdsend: empty inactive queue could not init Tx queues, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 at uhub2, port 2, addr 5 (disconnected) --- uath_cmdsend: empty inactive queue uath_cmdsend: empty inactive queue ugen1.5: Atheros Communications Inc at usbus1 (disconnected) The card still disconnects after attempting to scan unsupported frequencies. The sequence above happens when I 'ifconfig wlan1 up'. Also, the uath driver reports 2.4GHz and 5GHz as supported channels for this chip but it's a D-Link DWL-G132 which is a 2.4GHz device. Is this a problem for Adrian to look at? Ian -- Ian Freislich ___ 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: 7+ days of dogfood
Steve Kargl wrote: Firefox segfaults after ~10 seconds. Chrome gets stuck in a uwait state and never becomes responsive. Libreoffice displays its splash screen and immediately segfaults. Xorg does not start because it cannot load the xf86-video-driver (unless it is explicitly recompiled with /usr/bin/gcc). Once I got Xorg working, there were a few silent reboots (ie., nothing in /var/log/message, no core file, etc). snip KERNCONF=MOBILE CPUTYPE?=core2 #DISABLE_MAKE_JOBS=YES WITHOUT_CLANG=YES WITH_GCC=YES Shouldn't this be WITHOUT_CLANG_IS_CC=yes? I must say that my experience of -CURRENT dogfood has been entirely different. I can't remember the last time I didn't run -CURRENT as my desktop. I also have run -CURRENT in production for the last several years although it's a ruating load, not a compute load. Others might not agree with what I'm about to say. 1. WITHOUT_CLANG_IS_CC=yes I don't think clang is ready for prime time in FreeBSD, or FreeBSD isn't ready to use clang in prime time. I got a new laptop (ASUS UX31A) and found that a lot of the ports I needed to install didn't compile or core dumped. (Sorry I didn't report these to the project). This option sorted that problem out. However you will need to rebuild everything including world and kernel with gcc before you start building ports with gcc or you will still have problems. 2. MALLOC_PRODUCTION=yes Maybe it's the placebo effect. Binaries are smaller in memory and things seem faster 3. xorg, firefox18, WITH_NEW_XORG=yes, WITH_KMS=yes I've found that HAL is a waste of time with X. It's hit and miss when it comes to reporting hardware to X, better to just not use it. Xorg has always worked well for me. My new laptop required that I use the new xorg port to get anything resembling decent performance. Getting KMS to work was a bit unsettling and X only seems to work when it's launched by hand from a real terminal. xdm won't start from /etc/ttys with NEW_XORG, but I can live with that. I've just upgraded firefox-18.0 to firefox-18.0.2 without a hitch. I have flash working without a hitch. Even the acroread plugin works for viewing PDFs in browser. 4. Sound. I've had less success with this, but I think my problems would be the same on 8 and 9. It seems common for HDA these days to put the useful sound bits on different devices: pcm0: Realtek ALC269 (Internal Analog) (play/rec) default pcm1: Realtek ALC269 (Left Analog Headphones) (play) pcm2: Intel Panther Point (HDMI/DP 8ch) (play) So my headphone jack doesn't work. On my other laptor, the builtin mic doesn't work because it's on pcm1 and there's not a way to make pcm1 the default input device and pcm0 the default output device. I need to spend some time with a verbose boot and see if I can figure out the audio routing. Ian -- Ian Freislich ___ 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
Unable to build audio/sox: undefined reference to 'open_memstream'
Hi I get this error building building sox on amd64, but not i386. CC is gcc on both systems. I can't figure out what the configure options difference is between the two hosts that has it fail on the amd64 system. All the dependencies have the same options configured. /bin/sh ../libtool --silent --tag=CC --silent --mode=link cc -Wconversion -I/usr/local/include -O2 -pipe -march=nocona -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes -Wstrict-prototypes -pedantic -fopenmp -version-info 1:0:0 -lltdl -L/usr/local/lib -pthread -o libsox.la -rpath /usr/local/lib libsox_la-adpcms.lo libsox_la-aiff.lo libsox_la-cvsd.lo libsox_la-g711.lo libsox_la-g721.lo libsox_la-g723_24.lo libsox_la-g723_40.lo libsox_la-g72x.lo libsox_la-vox.lo libsox_la-raw.lo libsox_la-formats.lo libsox_la-formats_i.lo libsox_la-skelform.lo libsox_la-xmalloc.lo libsox_la-getopt.lo libsox_la-getopt1.lo libsox_la-util.lo libsox_la-libsox.lo libsox_la-libsox_i.lo libsox_la-sox-fmt.lo libsox_la-bend.lo libsox_la-biquad.lo libsox_la-biquads.lo libsox_la-chorus.lo libsox_la-compand.lo libsox_la-crop.lo libsox_la-compandt.lo libsox_la-contrast.lo libsox_la-dcshift.lo libsox_la-delay.lo libsox_la-dft_filter.lo libsox_la-dither.lo libsox_la-divid e.lo libsox_la-earwax.lo libsox_la-echo.lo libsox_la-echos.lo libsox_la-effects.lo libsox_la-effects_i.lo libsox_la-effects_i_dsp.lo libsox_la-fade.lo libsox_la-fft4g.lo libsox_la-filter.lo libsox_la-fir.lo libsox_la-firfit.lo libsox_la-flanger.lo libsox_la-gain.lo libsox_la-input.lo libsox_la-ladspa.lo libsox_la-loudness.lo libsox_la-mcompand.lo libsox_la-mixer.lo libsox_la-noiseprof.lo libsox_la-noisered.lo libsox_la-output.lo libsox_la-overdrive.lo libsox_la-pad.lo libsox_la-pan.lo libsox_la-phaser.lo libsox_la-rate.lo libsox_la-remix.lo libsox_la-repeat.lo libsox_la-reverb.lo libsox_la-reverse.lo libsox_la-silence.lo libsox_la-sinc.lo libsox_la-skeleff.lo libsox_la-speed.lo libsox_la-speexdsp.lo libsox_la-splice.lo libsox_la-stat.lo libsox_la-stats.lo libsox_la-stretch.lo libsox_la-swap.lo libsox_la-synth.lo libsox_la-tempo.lo libsox_la-tremolo.lo libsox_la-trim.lo libsox_la-vad.lo libsox_la-vol.lo libsox_la-spectrogram.lo libsox_la-raw-fmt.lo libsox_la -s1-fmt.lo libsox_la-s2-fmt.lo libsox_la-s3-fmt.lo libsox_la-s4-fmt.lo libsox_la-u1-fmt.lo libsox_la-u2-fmt.lo libsox_la-u3-fmt.lo libsox_la-u4-fmt.lo libsox_la-al-fmt.lo libsox_la-la-fmt.lo libsox_la-ul-fmt.lo libsox_la-lu-fmt.lo libsox_la-8svx.lo libsox_la-aiff-fmt.lo libsox_la-aifc-fmt.lo libsox_la-au.lo libsox_la-avr.lo libsox_la-cdr.lo libsox_la-cvsd-fmt.lo libsox_la-dvms-fmt.lo libsox_la-dat.lo libsox_la-hcom.lo libsox_la-htk.lo libsox_la-maud.lo libsox_la-prc.lo libsox_la-sf.lo libsox_la-smp.lo libsox_la-sounder.lo libsox_la-soundtool.lo libsox_la-sphere.lo libsox_la-tx16w.lo libsox_la-voc.lo libsox_la-vox-fmt.lo libsox_la-ima-fmt.lo libsox_la-adpcm.lo libsox_la-ima_rw.lo libsox_la-wav.lo libsox_la-wve.lo libsox_la-xa.lo libsox_la-nulfile.lo libsox_la-f4-fmt.lo libsox_la-f8-fmt.lo libsox_la-gsrt.lo libsox_la-alsa.lolibsox_la-ao.lo libsox_la-ffmpeg.lo libsox_la-flac.lo libsox_la-gsm.lo libsox_la-lpc10.lo libsox_la-mp3.lo libsox_la-oss.lo lib sox_la-vorbis.lo libsox_la-sndfile.lo libsox_la-caf.lo libsox_la-mat4.lo libsox_la-mat5.lo libsox_la-paf.lo libsox_la-fap.lo libsox_la-w64.lo libsox_la-xi.lo libsox_la-pvf.lo libsox_la-sd2.lo -lpng -lz -lmagic -lgomp -lgsm ../lpc10/liblpc10.la -lasound-lao -lavformat -lavcodec -L/usr/local/lib -lavutil -lFLAC -lvorbisenc -lvorbisfile -lvorbis -logg -lgsm -lmad -lid3tag -lz -lmp3lame -lvorbisenc -lvorbisfile -lvorbis -logg -L/usr/local/lib -lsndfile -lm /bin/sh ../libtool --silent --tag=CC --silent --mode=link cc -Wconversion -O2 -pipe -march=nocona -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes -Wstrict-prototypes -pedantic -fopenmp -avoid-version -module -L/usr/local/lib -pthread -o sox sox.o libsox.la -lm ./.libs/libsox.so: undefined reference to `open_memstream' *** [sox] Error code 1 Stop in /usr/ports/audio/sox/work/sox-14.3.2/src. *** [all-recursive] Error code 1 Stop in /usr/ports/audio/sox/work/sox-14.3.2. *** [do-build] Error code 1 Stop in /usr/ports/audio/sox. *** [build] Error code 1 Stop in /usr/ports/audio/sox. Ian -- Ian Freislich ___ 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
Centrino Advanced-N 6235 wireless
Hi I have one of these Advanced controlers in my laptop. It's up for grabs for an interested developer after this coming week-end. I need to de-solder the w.FL connectors to to put them on a supported non-Intel card to get working wifi. I will replace the on-card connectors with u.FL. iwn0@pci0:2:0:0:class=0x028000 card=0x40608086 chip=0x088e8086 rev=0x24 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Advanced-N 6235' class = network Contact me in private email if you're interested. The issues are: 1. Need the latest Intel firmware (iwlwifi-6000g2b-18.168.6.1) to get anything approaching connectivity. 2. The 2.4GHz radio will absolutely not use a 20MHz channel if the AP will do 40MHz. 3. 40MHz channels don't work. 4. Random disconnects every 30 minutes or so requiring a wlan0 destroy/create to recover. Ian -- Ian Freislich ___ 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: using multiple interfaces for same Network Card
Yasir hussan wrote: Thanks for notic but all the elebration was for make alias on one interface but i want to have multiple interface, i can no where that some one would have tring to creating new interfaces and using them, or may be i am missing something, just send its solution if have, solution should be for I still think you're confusing Linux semantics with FreeBSD semantics. On linux you would have: eth0 Link encap:Ethernet HWaddr 00:1E:C9:53:0B:61 inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::21e:c9ff:fe53:b61/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:211328068 errors:0 dropped:0 overruns:0 frame:0 TX packets:368394006 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:34065846811 (31.7 GiB) TX bytes:476377525764 (443.6 GiB) Interrupt:169 Memory:e600-e6011100 eth0:1Link encap:Ethernet HWaddr 00:1E:C9:53:0B:61 inet addr:10.0.1.1 Bcast:10.0.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:169 Memory:e600-e6011100 On FreeBSD you would have: re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE ether 54:04:a6:96:0c:1e inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 inet 10.0.1.1 netmask 0xff00 broadcast 10.0.1.255 media: Ethernet autoselect (1000baseT full-duplex) status: active These are both the same thing. Is there any particular reason that you want multiple interfaces? I can't see a use for it beyond it's what I'm used to seeing unless they're VLAN interfaces. Ian -- Ian Freislich ___ 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: using multiple interfaces for same Network Card
Yasir hussan wrote: --20cf3005141ab7271904d7be84ff Yes, i want to use them as vlan interface, Does any one has used *vlandev*, after seen this http://www.cyberciti.biz/faq/howto-configure-freebsd-vlans-with-ifconfig-comm and/i tried to use it as ifconfig vlan11 create 10.10.11.1 255.255.255.0 vlan 11 vlandev arge0 ifconfig vlan12 create 10.10.12.1 255.255.255.0 vlan 12 vlandev arge0 ifconfig vlan13 create 10.10.13.1 255.255.255.0 vlan 13 vlandev arge0 ifconfig vlan14 create 10.10.14.1 255.255.255.0 vlan 14 vlandev arge0 you want: ifconfig vlan11 create vlan 11 vlandev arge0 inet 10.10.11.1 netmask 255.255.255.0 or ifconfig vlan11 create vlan 11 vlandev arge0 inet 10.10.11.1/24 Ian -- Ian Freislich ___ 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
mirror site ftp3.za.freebsd.org
Hi For quite some time this mirror site has been unreachable. AFAICT, my ex colleagues who used to maintain it have moved on and it's now been left unmaintained. I left there in 2004 and Mark Murray who set it up left shortly thereafter. Perhaps it should be dropped from the mirror list. Ian -- Ian Freislich ___ 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
amd64 buildworld lib32 flags fail
Hi I have some amd64 systems that fail cleaning up lib32 and some that don't. I have to chflags noschg these files before starting a buildworld. I can't figure out what the difference is between the systems that work and those that don't. -- Rebuilding the temporary build tree -- rm -rf /usr/obj/usr/src/tmp rm -rf /usr/obj/usr/src/lib32 rm: /usr/obj/usr/src/lib32/usr/lib32/libc.so.7: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/libcrypt.so.5: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/libthr.so.3: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/librt.so.1: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32: Directory not empty rm: /usr/obj/usr/src/lib32/usr: Directory not empty rm: /usr/obj/usr/src/lib32: Directory not empty *** [_worldtmp] Error code 1 Ian -- Ian Freislich ___ 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: amd64 buildworld lib32 flags fail
Konstantin Belousov wrote: rm: /usr/obj/usr/src/lib32: Directory not empty *** [_worldtmp] Error code 1 =20 Maybe you buildworld is jailed? This is the usual consequence of the install -S usage, e.g. by setting INSTALL=install -CS in the make.conf. Ah, thanks. That would be the difference, except that I have: INSTALL=install Ian -- Ian Freislich ___ 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
'service named reload' with non-default system directories.
Hi
I often run named outside of the system default directories so that
amongst other things a mergemaster fumble doesn't break my name
servers. This however breaks rndc because it is not imbued with
the clue of where to find its key.
/etc/rc.d/named does create the key file in the correct place
according to the configured chroot directory. The reload section
just doesn't tell rndc where to find it.
Can I suggest for a minimal change:
--- /usr/src/etc/rc.d/named 2013-04-15 20:17:58.0 +0200
+++ /etc/rc.d/named 2013-04-24 16:16:52.0 +0200
@@ -109,7 +109,7 @@
named_reload()
{
- ${command%/named}/rndc reload
+ ${command%/named}/rndc -k ${named_confdir}/rndc.key reload
}
find_pidfile()
A more invasive change:
The bind9 reference suggests that named loading rndc.key is for
backwards compatibility.
Since the rndc.key feature is only intended to allow the
backward-compatible usage of BIND 8 configuration files, this
feature does not have a high degree of configurability. You
cannot easily change the key name or the size of the secret, so
you should make a rndc.conf with your own key if you wish to
change those things.
So, I 'include path/to/rndc.key;' in named.conf, add a controls
section that uses this named key and I use the following rndc.conf:
---named.conf---
include /etc/namedb/rndc.key;
controls {
inet 127.0.0.1 allow { 127.0.0.1; } keys { rndc-key; };
};
---named.conf---
---rndc.conf---
include /etc/namedb/rndc.key;
options {
default-server localhost;
default-key rndc-key;
};
server localhost {
key rndc-key;
};
---rndc.conf---
And the following version of the above patch:
--- /usr/src/etc/rc.d/named 2013-04-15 20:17:58.0 +0200
+++ /etc/rc.d/named 2013-04-24 16:16:52.0 +0200
@@ -109,7 +109,7 @@
named_reload()
{
- ${command%/named}/rndc reload
+ ${command%/named}/rndc -c ${named_confdir}/rndc.conf reload
}
find_pidfile()
this will allow the rc system to reload and stop named (without a
kill) no matter what the configured chroot is.
Ian
--
Ian Freislich
___
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: 'service named reload' with non-default system directories.
Sean Bruno wrote:
Would we need a change to /etc/defaults/rc.conf to set ${named_confdir}
to the default location if not set?
I'm not sure. It's derived:
load_rc_config $name
# Updating the following variables requires that rc.conf be loaded first
#
required_dirs=$named_chrootdir# if it is set, it must exist
named_confdir=${named_chrootdir}${named_conf%/*}
I don't think that I did a particularly good job of making it work
for all instances. It's more of an opening move to get this working
properly wherever the admin chooses to put the named chroot. I'm
still expecting comments from Doug Barton.
Also, there already appears to be a ${named_conf} that points to
whatever named.conf specified (defaults to /etc/namedb/named.conf). Is
this complementary to what you're poking at?
This is specifically rndc (not named) that fails to find its key
or config if you choose to use a chrootdir that isn't the default.
Ian
--
Ian Freislich
___
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
ip_output.c:625: warning: cast discards qualifier
Hi /usr/src/sys/netinet/ip_output.c: In function 'ip_output': /usr/src/sys/netinet/ip_output.c:625: warning: cast discards qualifiers from pointer target type /usr/src/sys/netinet/ip_output.c:659: warning: cast discards qualifiers from pointer target type *** [ip_output.o] Error code 1 gw is defined 'const'. @625: error = (*ifp-if_output)(ifp, m, (struct sockaddr *)gw, ro) if_output arg3 needs to be protoyped const or gw needs to not be declared const. Ian -- Ian Freislich ___ 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
panic: in_pcblookup_local (?)
Hi I've been getting the following panic on recent current r249717. Sadly the crashdump is useless. Fatal trap 9: general protection fault while in kernel mode cpuid = 15; apic id = 0f instruction pointer = 0x20:0x80546fbc stack pointer = 0x28:0xff846b60 frame pointer = 0x28:0xff846b6777b0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 4361 (zabbix_agentd) trap number = 9 panic: general protection fault cpuid = 15 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b677410 panic() at panic+0x13d/frame 0xff846b677510 trap_fatal() at trap_fatal+0x290/frame 0xff846b677570 trap() at trap+0xff/frame 0xff846b6776b0 calltrap() at calltrap+0x8/frame 0xff846b6776b0 --- trap 0x9, rip = 0x80546fbc, rsp = 0xff846b60, rbp = 0xff846b6777b0 --- in_pcblookup_local() at in_pcblookup_local+0x5c/frame 0xff846b6777b0 in_pcb_lport() at in_pcb_lport+0x109/frame 0xff846b677820 in_pcbbind_setup() at in_pcbbind_setup+0x16a/frame 0xff846b6778a0 in_pcbconnect_setup() at in_pcbconnect_setup+0x71e/frame 0xff846b677990 in_pcbconnect_mbuf() at in_pcbconnect_mbuf+0x59/frame 0xff846b6779e0 udp_connect() at udp_connect+0x11e/frame 0xff846b677a30 kern_connectat() at kern_connectat+0x1f5/frame 0xff846b677a90 sys_connect() at sys_connect+0x41/frame 0xff846b677ad0 amd64_syscall() at amd64_syscall+0x572/frame 0xff846b677bf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b677bf0 --- syscall (98, FreeBSD ELF64, sys_connect), rip = 0x80127104a, rsp = 0x7fff97a8, rbp = 0x8014f68d4 --- Uptime: 20m13s Dumping 1688 out of 16368 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 15 Ian -- Ian Freislich ___ 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
LOR: two vfs_bio.c:3070, ufs_dirhash.c:284 and vfs_mount.c:851, vfs_subr.c:2167
Hi I'm getting these two LORs at boot time, they don't seem to be known on http://ipv4.sources.zabbadoz.net/freebsd/lor.html lock order reversal: 1st 0xff83e37ee938 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3070 2nd 0xfe0030283800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b756410 _witness_debugger() at _witness_debugger+0x65/frame 0xff846b756430 witness_checkorder() at witness_checkorder+0x857/frame 0xff846b7564e0 _sx_xlock() at _sx_xlock+0x6e/frame 0xff846b756510 ufsdirhash_acquire() at ufsdirhash_acquire+0x33/frame 0xff846b756530 ufsdirhash_add() at ufsdirhash_add+0x19/frame 0xff846b756560 ufs_direnter() at ufs_direnter+0x976/frame 0xff846b756630 ufs_makeinode() at ufs_makeinode+0x296/frame 0xff846b7567f0 VOP_CREATE_APV() at VOP_CREATE_APV+0x8c/frame 0xff846b756820 vn_open_cred() at vn_open_cred+0x2da/frame 0xff846b756970 kern_openat() at kern_openat+0x1de/frame 0xff846b756ad0 amd64_syscall() at amd64_syscall+0x26c/frame 0xff846b756bf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b756bf0 --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x800b6f99a, rsp = 0x7fffd84 lock order reversal: 1st 0xfe003082f068 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:851 2nd 0xfe032a133240 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2167 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b408410 _witness_debugger() at _witness_debugger+0x65/frame 0xff846b408430 witness_checkorder() at witness_checkorder+0x857/frame 0xff846b4084e0 __lockmgr_args() at __lockmgr_args+0xda4/frame 0xff846b4085b0 vop_stdlock() at vop_stdlock+0x39/frame 0xff846b4085d0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x97/frame 0xff846b408600 _vn_lock() at _vn_lock+0x5e/frame 0xff846b408680 vget() at vget+0x63/frame 0xff846b4086d0 devfs_allocv() at devfs_allocv+0x13c/frame 0xff846b408730 devfs_root() at devfs_root+0x4d/frame 0xff846b408770 vfs_donmount() at vfs_donmount+0xa55/frame 0xff846b408a90 sys_nmount() at sys_nmount+0x6d/frame 0xff846b408ad0 amd64_syscall() at amd64_syscall+0x26c/frame 0xff846b408bf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b408bf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a96daa, rsp = 0x7fffccc8, rbp = 0x7fffcce0 --- Ian -- Ian Freislich ___ 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: panic: in_pcblookup_local (?)
John Baldwin wrote: On Thursday, May 02, 2013 7:25:08 am Robert N. M. Watson wrote: On 2 May 2013, at 11:42, Glen Barber wrote: Hmm. Perhaps it would be worthwhile for me to rebuild the current kernel with DDB support. It looks like the machine has panicked a few times over the last two weeks or so, but based on the timestamps of the crash dumps and nagios complaints, happened during the middle of the night when I would not have really noticed, or otherwise would have just blamed my ISP. Two of the panics are ath(4) related. One looks similar to the one referenced in this thread, similarly triggered by a CFEngine process. In that case, the backtrace looks like: #4 0x808cdbb3 at calltrap+0x8 #5 0x807371d8 at in_pcb_lport+0x128 #6 0x8073745a at in_pcbbind_setup+0x16a #7 0x80737d8e at in_pcbconnect_setup+0x71e #8 0x80737df9 at in_pcbconnect_mbuf+0x59 #9 0x807bf29f at udp_connect+0x11f #10 0x80680615 at kern_connectat+0x275 Regarding DDB though, it would be rather difficult to access the machine if it drops to a DDB debugger session, since the machine acts as my firewall. Thanks -- will take a look at the attached. FWIW, though, I'm worried by the number of panics you are seeing, especiall y given that they involve multiple subsystems, and in particular, John's observation about a potentially corrupted pointer. This makes me wonder whether (a) you are experiencing hardware faults -- it would be worth running some memory/cpu/etc tests and (b) if we might be seeing a software memory corruption bug of some sort. Other users have reported this (Ian Lepore), and Peter Wemm can now reproduce these at will as well, so I think this is a software bug. What might be easiest if we can't figure this out from the crashdump is just to bisect the offending revision. I've started a binary search. I'll let you know what that turns up. Ian -- Ian Freislich ___ 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: panic: in_pcblookup_local (?)
Peter Wemm wrote: offending revision. I've started a binary search. I'll let you know what that turns up. Thanks, and sorry for getting my Ian's mixed up. :-/ -- John Baldwin There's been two separate machines, at least twice each on this exact panic / trace. Always with doing a 'svn update'. Rolling back to April 5th 249172 solves it. (There's nothing particular about that rev, except it was top-of-tree when the last update was done). I see a number locking changes in the area. Note that this is UDP, most likely a dns lookup. I'll work to confirm this here. I was a little slow in bisecting because I spent 2 days trying to figure out what revision caused PF to rapidly expire its entire state table which prevented testing this condition. Ian -- Ian Freislich ___ 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
panic: pfsync_insert_state: st-sync_state == PFSYNC_S_NONE
=0x80427330 ithread_loop, arg=0xfe003088f0e0, frame=0xff846b3c3c00) at /usr/src/sys/kern/kern_fork.c:991 #23 0x805ff39e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 #24 0x in ?? () Ian -- Ian Freislich ___ 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
Recurring panic
Hi
I have the following recurring panic on all my heavily network
loaded -CURRENT routers. The current process is always different.
Gleb, can you please chime in with what you've managed to uncover.
Unread portion of the kernel message buffer:
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 21363 (kgdb)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b4de530
panic() at panic+0x13d/frame 0xff846b4de630
trap_fatal() at trap_fatal+0x290/frame 0xff846b4de690
trap_pfault() at trap_pfault+0x21f/frame 0xff846b4de6f0
trap() at trap+0x2b4/frame 0xff846b4de830
calltrap() at calltrap+0x8/frame 0xff846b4de830
--- trap 0xc, rip = 0x8044872d, rsp = 0xff846b4de8f0, rbp =
0xff846b4de910 ---
__mtx_lock_sleep() at __mtx_lock_sleep+0x5d/frame 0xff846b4de910
selfdfree() at selfdfree+0xef/frame 0xff846b4de930
sys_poll() at sys_poll+0x332/frame 0xff846b4dead0
amd64_syscall() at amd64_syscall+0x572/frame 0xff846b4debf0
Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b4debf0
--- syscall (209, FreeBSD ELF64, sys_poll), rip = 0x80160670a, rsp =
0x7fffcc68, rbp = 0 ---
Uptime: 3d5h49m17s
Dumping 2580 out of 16368 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:264
264 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:264
#1 0x8045a424 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2 0x8045a927 in panic (fmt=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:754
#3 0x8061e950 in trap_fatal (frame=0xc, eva=value optimized out)
at /usr/src/sys/amd64/amd64/trap.c:872
#4 0x8061ecbf in trap_pfault (frame=0xff846b4de840, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:789
#5 0x8061f074 in trap (frame=0xff846b4de840)
at /usr/src/sys/amd64/amd64/trap.c:463
#6 0x806088ef in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#7 0x8044872d in __mtx_lock_sleep (c=0xff8006e551e8,
tid=18446741875506397184, opts=value optimized out,
file=value optimized out, line=0) at /usr/src/sys/kern/kern_mutex.c:425
#8 0x804a574f in selfdfree (stp=value optimized out,
sfp=0xfe02bbf92690) at /usr/src/sys/kern/sys_generic.c:1524
#9 0x804a6e82 in sys_poll (td=0xfe0030e1c000,
uap=0xff846b4deb70) at /usr/src/sys/kern/sys_generic.c:1369
#10 0x8061e2b2 in amd64_syscall (td=0xfe0030e1c000, traced=0)
at subr_syscall.c:134
#11 0x80608bd7 in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:387
#12 0x00080160670a in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Ian
--
Ian Freislich
___
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
Panic in tcp_input
0x80420814 in fork_exit ( callout=0x804236c0 ithread_loop, arg=0xfe002e0431a0, frame=0xff846b258c00) at /usr/src/sys/kern/kern_fork.c:991 #25 0x805f5d7e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 #26 0x in ?? () Current language: auto; currently minimal (kgdb) -- Ian Freislich ___ 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: Panic in tcp_input
Andre Oppermann wrote: On 19.06.2013 11:10, Ian FREISLICH wrote: Hi I'm seeing this panic quite regularly now. Most recent sighting on r251858. This panic message is not very informative and very hard to extract any meaningful hints. Do you have a core dump and matching debug kernel? I do. If you can send me your public ssh key in private email, I can give you access to the server in question. Ian -- Ian Freislich ___ 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: Panic in tcp_input
Gleb Smirnoff wrote: A This seems to be a fallout of the recent UMA changes and its interaction A with the per-cpu counter(9) system. A A Adding in and handing over to Gleb and Jeff as they touched this area last . Ian has reported this panic several days before Jeff's changes :( Do you want me to try to find the revision of origin? I have a verified sighting at r251615 and I'm pretty sure I've seen it earlier than that. Subjectively, it seems to have got a lot worse lately. Maybe the recent UMA changes have exposed some latent issue? Ian -- Ian Freislich ___ 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
usb ACM device doesn't work
Hi I bought a relay control board that has a USB interface. It presents a serial port to Linux on /dev/ttyACMx. However when I plug it into my FreeBSD host, it detects as follows: ugen0.2: KMT at usbus0 umodem0: KMT USB CDC COM, class 2/0, rev 1.10/1.00, addr 1 on usbus0 umodem0: data interface 1, has no CM over data, has no break and I cannot communicate with it. Any ideas how to communicate with it? This is the output of 'usbconfig -d ugen0.2 dump_curr_config_desc': ugen0.2: USB CDC COM KMT at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA) Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0043 bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x00c0 bMaxPower = 0x Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0001 bInterfaceClass = 0x0002 bInterfaceSubClass = 0x0002 bInterfaceProtocol = 0x0001 iInterface = 0x no string Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x05, 0x24, 0x00, 0x10, 0x01 Additional Descriptor bLength = 0x04 bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x04, 0x24, 0x02, 0x02 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x05, 0x24, 0x06, 0x00, 0x01 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x05, 0x24, 0x01, 0x00, 0x01 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 IN bmAttributes = 0x0003 INTERRUPT wMaxPacketSize = 0x0008 bInterval = 0x00fa bRefresh = 0x bSynchAddress = 0x Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x000a bInterfaceSubClass = 0x bInterfaceProtocol = 0x iInterface = 0x no string Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0040 bInterval = 0x0001 bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0040 bInterval = 0x0001 bRefresh = 0x bSynchAddress = 0x Ian -- Ian Freislich ___ 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: usb ACM device doesn't work
Daniel O'Connor wrote: On 22/06/2013, at 4:10, Ian FREISLICH i...@clue.co.za wrote: I bought a relay control board that has a USB interface. It presents a serial port to Linux on /dev/ttyACMx. However when I plug it into my FreeBSD host, it detects as follows: ugen0.2: KMT at usbus0 umodem0: KMT USB CDC COM, class 2/0, rev 1.10/1.00, addr 1 on usbus0 umodem0: data interface 1, has no CM over data, has no break and I cannot communicate with it. Any ideas how to communicate with it? Have you tried anything? It should create /dev/cuaUx and /dev/ttyUx (where x is 0 in your case) I'w sorry, I should have been more specific. I have a device that controls a bunch of relays with commands issued to it over a serial port. This serial port is CDC-ACM on a USB interface. The device uses a PIC microcontroller and PICKIT2 from Microchip Technology Inc (vendorID 0x04d8). Linux correctly detects the device with CM over data and I'm able to communicate with it on /dev/ttyACM0 and the TX/RX LEDs on the device blink when transferring data. FreeBSD on the other hand detects it as having no CM over data and while I can open /dev/cuaU0 and write data to it, the RX/TX lights on the device don't blink and reads time out. As previously stated I cannot communicate with it. I tried adding the quirk UQ_ASSUME_CM_OVER_DATA, but then the terminal program locks up and won't exit until I pull the USB cable. The same happens when I force the CM over Data capability in the umodem driverwhen attaching the device, so there's some issue with our CDC/ACM support or Linux is working harder to make non-compliant usb hardware work. Also, our usbdevs is incorrect in listing vedor 0x04d8 as I-Tuner Networks. It is in fact licensed to Microchip Tochnology Inc. which then sub-licenses productIDs royalty free to third parties providing certain conditions are met. See: http://ww1.microchip.com/downloads/en/DeviceDoc/APPLICATION%20FOR%20SUBLICENSE%20TO%20USB%20VID%20revised%2012110.pdf I don't have the knowledge to fix the FreeBSD USD driver and for the $45 it cost me it's not worth the effort to reinstall the host I'm using with linux. If there's no fix forthcoming I'll just get the EIA-485 version of the device with no hard feelings. Ian -- Ian Freislich ___ 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: usb ACM device doesn't work
Hans Petter Selasky wrote: On 06/22/13 20:54, Ian FREISLICH wrote: Daniel O'Connor wrote: On 22/06/2013, at 4:10, Ian FREISLICH i...@clue.co.za wrote: I bought a relay control board that has a USB interface. It presents a serial port to Linux on /dev/ttyACMx. However when I plug it into my FreeBSD host, it detects as follows: ugen0.2: KMT at usbus0 umodem0: KMT USB CDC COM, class 2/0, rev 1.10/1.00, addr 1 on usbus0 umodem0: data interface 1, has no CM over data, has no break and I cannot communicate with it. Any ideas how to communicate with it? Have you tried anything? It should create /dev/cuaUx and /dev/ttyUx (where x is 0 in your case) I'w sorry, I should have been more specific. I have a device that controls a bunch of relays with commands issued to it over a serial port. This serial port is CDC-ACM on a USB interface. The device uses a PIC microcontroller and PICKIT2 from Microchip Technology Inc (vendorID 0x04d8). Linux correctly detects the device with CM over data and I'm able to communicate with it on /dev/ttyACM0 and the TX/RX LEDs on the device blink when transferring data. FreeBSD on the other hand detects it as having no CM over data and while I can open /dev/cuaU0 and write data to it, the RX/TX lights on the device don't blink and reads time out. As previously stated I cannot communicate with it. I tried adding the quirk UQ_ASSUME_CM_OVER_DATA, but then the terminal program locks up and won't exit until I pull the USB cable. The same happens when I force the CM over Data capability in the umodem driverwhen attaching the device, so there's some issue with our CDC/ACM support or Linux is working harder to make non-compliant usb hardware work. Also, our usbdevs is incorrect in listing vedor 0x04d8 as I-Tuner Networks. It is in fact licensed to Microchip Tochnology Inc. which then sub-licenses productIDs royalty free to third parties providing certain conditions are met. See: http://ww1.microchip.com/downloads/en/DeviceDoc/APPLICATION%20FOR%20SUBLICE NSE%20TO%20USB%20VID%20revised%2012110.pdf I don't have the knowledge to fix the FreeBSD USD driver and for the $45 it cost me it's not worth the effort to reinstall the host I'm using with linux. If there's no fix forthcoming I'll just get the EIA-485 version of the device with no hard feelings. Ian Hi Ian, Have you tried using usbdump to capture the USB traffic? It might be something like clear-stall which fails, and make the device broken: usbdump -i usbusX -f Y -vvv -s 65536 I can't see anything obvious. As I plug the device in: 10:23:59.519700 usbus0.2 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 80 06 00 01 00 00 08 00 -- -- -- -- -- -- -- -- || frame[1] READ 8 bytes flags 0x10 PROXY_BUFFER|0 status 0xca1a3 OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:23:59.521660 usbus0.2 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 8 bytes 12 01 10 01 02 00 00 08 -- -- -- -- -- -- -- -- || flags 0x10 PROXY_BUFFER|0 status 0xca1a1 OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:23:59.521694 usbus0.2 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 80 06 00 01 00 00 12 00 -- -- -- -- -- -- -- -- || frame[1] READ 18 bytes flags 0x10 PROXY_BUFFER|0 status 0xea1a3 OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:23:59.522736 usbus0.2 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 18 bytes 12 01 10 01 02 00 00 08 D8 04 F9 FE 00 01 01 02 || 0010 00 01 -- -- -- -- -- -- -- -- -- -- -- -- -- -- |.. | flags 0x10 PROXY_BUFFER|0 status 0xea1a1 OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:23:59.522769 usbus0.2 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 80 06 00 03 00 00 02 00 -- -- -- -- -- -- -- -- || frame[1] READ 2 bytes flags 0x10 PROXY_BUFFER|0 status 0xca1a3 OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:23:59.523344 usbus0.2 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 2 bytes 04 03 -- -- -- -- -- -- -- -- -- -- -- -- -- -- |.. | flags 0x10 PROXY_BUFFER|0 status 0xca1a1 OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:23:59.523371 usbus0.2 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 80 06 00 03 00 00 04 00
Re: usb ACM device doesn't work
Hans Petter Selasky wrote: On 06/23/13 10:33, Ian FREISLICH wrote: status 0xea1a1 OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SET UP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0 10:29:19.904434 usbus0.2 SUBM-BULK-EP=0002,SPD=FULL,NFR=1,SLEN=4,IVAL=0 frame[0] WRITE 1 bytes 6F -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- |o | flags 0x9 FORCE_SHORT_XFER|PIPE_BOF|0 status 0x4a023 OPEN|TRANSFERRING|STARTED|BDMA_ENABLE|BDMA_SETUP|CAN_CANC EL_IMMED|0 If you don't get a DONE-BULK-EP=0002, then the device does not receive the data. It is blocking the write. Did you set the correct baud rate? I did. It's 9600. Also, what does usbconfig -d X.Y dump_device_desc dump_curr_config_desc say ? [zen] ~ # usbconfig -d ugen0.2 dump_device_desc ugen0.2: USB CDC COM KMT at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0002 bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x04d8 idProduct = 0xfef9 bcdDevice = 0x0100 iManufacturer = 0x0001 KMT iProduct = 0x0002 USB CDC COM iSerialNumber = 0x no string bNumConfigurations = 0x0001 [zen] ~ # usbconfig -d ugen0.2 dump_curr_config_desc ugen0.2: USB CDC COM KMT at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA) Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0043 bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x00c0 bMaxPower = 0x Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0001 bInterfaceClass = 0x0002 bInterfaceSubClass = 0x0002 bInterfaceProtocol = 0x0001 iInterface = 0x no string Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x05, 0x24, 0x00, 0x10, 0x01 Additional Descriptor bLength = 0x04 bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x04, 0x24, 0x02, 0x02 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x05, 0x24, 0x06, 0x00, 0x01 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x05, 0x24, 0x01, 0x00, 0x01 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 IN bmAttributes = 0x0003 INTERRUPT wMaxPacketSize = 0x0008 bInterval = 0x00fa bRefresh = 0x bSynchAddress = 0x Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x000a bInterfaceSubClass = 0x bInterfaceProtocol = 0x iInterface = 0x no string Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0040 bInterval = 0x0001 bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0040 bInterval = 0x0001 bRefresh = 0x bSynchAddress = 0x -- Ian Freislich ___ 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
network.subr (r252360) changes break ifconfig_aliasX
Hi I can't figure out how to use rc.conf to configure my interfaces after these recent charges. My use case is that I have interfaces to configure but I don't need to put an IP address on them. I do need to change the MAC address though. What I have been doing is probably wrong, but it worked up until r252360: lagg0: link state changed to DOWN /etc/rc: WARNING: $ifconfig_lagg0_alias0 needs inet keyword for an IPv4 address. ifconfig: ether: bad value But, there is no ip address for this interface. The config looks like: cloned_interfaces=lagg0 \ vlan2 vlan3 vlan4 vlan5 vlan6 vlan7 vlan8 vlan9 vlan14 vlan15 vlan19 \ vlan20 vlan21 vlan22 vlan23 vlan24 vlan25 vlan26 vlan27 vlan30 \ vlan33 vlan37 vlan39 vlan40 vlan41 vlan44 vlan45 vlan999 \ ifconfig_igb0=up ifconfig_igb1=up ifconfig_igb2=up ifconfig_igb3=up ifconfig_lagg0=up laggproto lacp laggport igb0 laggport igb1 laggport igb2 laggport igb3 ifconfig_lagg0_alias0=ether 00:1e:c9:53:3e:15 # Neotel ifconfig_vlan2=vlandev lagg0 vlan 2 #should probably be create_args ifconfig_vlan2_alias0=inet 41.161.56.4/29 ifconfig_vlan2_alias1=inet 41.154.2.106/29 ifconfig_vlan2_alias2=inet 196.46.25.156/25 ifconfig_vlan2_alias3=inet 41.161.56.2/29 vhid 2 pass XXX advskew 20 ifconfig_vlan2_alias4=inet 41.154.2.105/29 vhid 2 pass XXX advskew 20 ifconfig_vlan2_alias5=inet 196.46.25.155/25 vhid 2 pass XXX advskew 20 etc. I've tried create_args but I still get the following error: ifconfig: ether: bad value and, I cannot use ifconfig_lagg0 to set the MAC address because the rc system just seems to ignore the configured string. I can however 'ifconfig lagg0 ether 00:1e:c9:53:3e:15' from the cammand line, so there's something in the rc scripts that's mangling the argument. Ian -- Ian Freislich ___ 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: network.subr (r252360) changes break ifconfig_aliasX
Ian FREISLICH wrote: What I have been doing is probably wrong, but it worked up until r252360: I see from the commit log that it was actually 252015 that broke my router. -- Ian Freislich ___ 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: network.subr (r252360) changes break ifconfig_aliasX
Hiroki Sato wrote: ia I can't figure out how to use rc.conf to configure my interfaces ia after these recent charges. My use case is that I have interfaces ia to configure but I don't need to put an IP address on them. I do ia need to change the MAC address though. Please try r252426. Thanks. That fixes it. BTW, nice new features in network.subr. Ian -- Ian Freislich ___ 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
Filesystem wedges caused by r251446
Hi I've been experiencing process wedges writing files. It occurs reliably under heavy IO activity, perhaps with large files but I'm not entirely sure what the trigger is. The symptom is that during an installworld, it reliably hangs the install process on /usr/bin/clang (sometimes it hangs earlier at the mtree on /usr) The problem leaves the filesystem in a state where it cannot be cleanly unmounted. A binary search pins the offending commit on r251446. The major differences between the working system and the broken one are, CPU, RAM and arch (i386/amd64) they are otherwise identical Dell R200 servers. Working: CPU: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz (2400.14-MHz 686-class CPU) RAM:2G Arch: i386 Broken: CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2666.82-MHz K8-class CPU) RAM:4G Arch: amd64 The compiler, gcc, clang (trunk or release) has no effect. Working CPU: FreeBSD 10.0-CURRENT #6 r252384: Sun Jun 30 08:36:31 SAST 2013 ianf@fw2:/usr/obj/usr/src/sys/FIREWALL i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz (2400.14-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6fd Family = 0x6 Model = 0xf Stepping = 13 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 2076581888 (1980 MB) Broken on: FreeBSD 10.0-CURRENT #19 r251445: Thu Jul 4 08:39:21 SAST 2013 ianf@fw1:/usr/obj/usr/src/sys/FIREWALL amd64 FreeBSD clang version 3.3 (trunk 178860) 20130405 CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2666.82-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10676 Family = 0x6 Model = 0x17 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x8e39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3970727936 (3786 MB) Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Filesystem wedges caused by r251446
Konstantin Belousov wrote: Care to provide any useful information ? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html Well, the system doesn't deadlock it's perfectly useable so long as you don't touch the file that's wedged. A lot of the time the userland process is unkillable, but often it is killable. How do I get from from the PID to where the FS is stuck in the kernel? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Filesystem wedges caused by r251446
John Baldwin wrote: On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: Konstantin Belousov wrote: Care to provide any useful information ? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- handbook/kerneldebug-deadlocks.html Well, the system doesn't deadlock it's perfectly useable so long as you don't touch the file that's wedged. A lot of the time the userland process is unkillable, but often it is killable. How do I get from from the PID to where the FS is stuck in the kernel? Use kgdb. 'proc pid', then 'bt'. So, I setup a remote kbgd session, but I still can't figure out how to get at the information we need. (kgdb) proc 5176 only supported for core file target In the mean time, I'll just force it to make a core dump from ddb. However, I can't reacreate the issue while the mirror (gmirror) is rebuilding, so we'll have to wait for that to finish. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Filesystem wedges caused by r251446
John Baldwin wrote: On Thursday, July 11, 2013 6:54:35 am Ian FREISLICH wrote: John Baldwin wrote: On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: Konstantin Belousov wrote: Care to provide any useful information ? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- handbook/kerneldebug-deadlocks.html Well, the system doesn't deadlock it's perfectly useable so long as you don't touch the file that's wedged. A lot of the time the userland process is unkillable, but often it is killable. How do I get from from the PID to where the FS is stuck in the kernel? Use kgdb. 'proc pid', then 'bt'. So, I setup a remote kbgd session, but I still can't figure out how to get at the information we need. (kgdb) proc 5176 only supported for core file target In the mean time, I'll just force it to make a core dump from ddb. However, I can't reacreate the issue while the mirror (gmirror) is rebuilding, so we'll have to wait for that to finish. Sorrry, just run 'sudo kgdb' on the box itself. You can inspect the running kernel without having to stop it. So, this machine's installworld *always* stalls installing clang. The install can be stopped (ctrl-c) leaving behind this process: root23147 0.0 0.0 9268 1512 1 D 7:51PM 0:00.01 install -s -o root -g wheel -m 555 clang /usr/bin/clang This is the backtrace from gdb. I suspect frame 4. (kgdb) proc 23147 [Switching to thread 117 (Thread 100059)]#0 sched_switch ( td=0xfe000c012920, newtd=0x0, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1954 1954cpuid = PCPU_GET(cpuid); Current language: auto; currently minimal (kgdb) bt #0 sched_switch (td=0xfe000c012920, newtd=0x0, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1954 #1 0x8047539e in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:487 #2 0x804acbea in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:620 #3 0x80474ee9 in _sleep (ident=value optimized out, lock=0x80a20300, priority=84, wmesg=0x8071129a wdrain, sbt=value optimized out, pr=0, flags=value optimized out) at /usr/src/sys/kern/kern_synch.c:249 #4 0x804e6523 in waitrunningbufspace () at /usr/src/sys/kern/vfs_bio.c:564 #5 0x804e6073 in bufwrite (bp=value optimized out) at /usr/src/sys/kern/vfs_bio.c:1226 #6 0x804f05ed in cluster_wbuild (vp=0xfe008fec4000, size=32768, start_lbn=136, len=value optimized out, gbflags=value optimized out) at /usr/src/sys/kern/vfs_cluster.c:1002 #7 0x804efbc3 in cluster_write (vp=0xfe008fec4000, bp=0xff80f83da6f0, filesize=4456448, seqcount=127, gbflags=value optimized out) at /usr/src/sys/kern/vfs_cluster.c:592 #8 0x805c1032 in ffs_write (ap=0xff8121c81850) at /usr/src/sys/ufs/ffs/ffs_vnops.c:801 #9 0x8067fe21 in VOP_WRITE_APV (vop=value optimized out, ---Type return to continue, or q return to quit--- a=value optimized out) at vnode_if.c:999 #10 0x80511eca in vn_write (fp=0xfe006a5f7410, uio=0xff8121c81a90, active_cred=0x0, flags=value optimized out, td=0x0) at vnode_if.h:413 #11 0x8050eb3a in vn_io_fault (fp=0xfe006a5f7410, uio=0xff8121c81a90, active_cred=0xfe006a6ca000, flags=0, td=0xfe000c012920) at /usr/src/sys/kern/vfs_vnops.c:983 #12 0x804b506a in dofilewrite (td=0xfe000c012920, fd=5, fp=0xfe006a5f7410, auio=0xff8121c81a90, offset=value optimized out, flags=0) at file.h:290 #13 0x804b4cde in sys_write (td=0xfe000c012920, uap=value optimized out) at /usr/src/sys/kern/sys_generic.c:460 #14 0x8061807a in amd64_syscall (td=0xfe000c012920, traced=0) at subr_syscall.c:134 #15 0x806017ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #16 0x0044e75a in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Any other process attempting to for instance stat /usr/bin/clang also gets stuck: root23198 0.0 0.0 8056 1780 1 D+7:58PM 0:00.00 stat /usr/bin/clang #0 sched_switch (td=0x80a67b20, newtd=0x0, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1954 1954cpuid = PCPU_GET(cpuid); (kgdb) proc 23198 [Switching to thread 107 (Thread 100131)]#0 sched_switch ( td=0xfe000ce9a000, newtd=0x0, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1954 1954cpuid = PCPU_GET(cpuid); Current language: auto; currently minimal (kgdb) bt #0 sched_switch (td=0xfe000ce9a000, newtd=0x0, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1954 #1 0x8047539e in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:487 #2 0x804acbea
Re: Filesystem wedges caused by r251446
Konstantin Belousov wrote: --rMuTkhzRlt+HYtLC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 08:11:36PM +0200, Ian FREISLICH wrote: John Baldwin wrote: On Thursday, July 11, 2013 6:54:35 am Ian FREISLICH wrote: John Baldwin wrote: On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: Konstantin Belousov wrote: =20 Care to provide any useful information ? =20 http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- handbook/kerneldebug-deadlocks.html =20 Well, the system doesn't deadlock it's perfectly useable so long as you don't touch the file that's wedged. A lot of the time the userland process is unkillable, but often it is killable. How do I get from from the PID to where the FS is stuck in the kernel? =20 Use kgdb. 'proc pid', then 'bt'. =20 So, I setup a remote kbgd session, but I still can't figure out how to get at the information we need. =20 (kgdb) proc 5176 only supported for core file target =20 In the mean time, I'll just force it to make a core dump from ddb. However, I can't reacreate the issue while the mirror (gmirror) is rebuilding, so we'll have to wait for that to finish. =20 Sorrry, just run 'sudo kgdb' on the box itself. You can inspect the ru= nning kernel without having to stop it. =20 So, this machine's installworld *always* stalls installing clang. The install can be stopped (ctrl-c) leaving behind this process: =20 root23147 0.0 0.0 9268 1512 1 D 7:51PM 0:00.01 install -= s -o root -g wheel -m 555 clang /usr/bin/clang =20 This is the backtrace from gdb. I suspect frame 4. =20 (kgdb) proc 23147 [Switching to thread 117 (Thread 100059)]#0 sched_switch ( td=3D0xfe000c012920, newtd=3D0x0, flags=3Dvalue optimized out) at /usr/src/sys/kern/sched_ule.c:1954 1954cpuid =3D PCPU_GET(cpuid); Current language: auto; currently minimal (kgdb) bt #0 sched_switch (td=3D0xfe000c012920, newtd=3D0x0,=20 flags=3Dvalue optimized out) at /usr/src/sys/kern/sched_ule.c:1954 #1 0x8047539e in mi_switch (flags=3D260, newtd=3D0x0) at /usr/src/sys/kern/kern_synch.c:487 #2 0x804acbea in sleepq_wait (wchan=3D0x0, pri=3D0) at /usr/src/sys/kern/subr_sleepqueue.c:620 #3 0x80474ee9 in _sleep (ident=3Dvalue optimized out,=20 lock=3D0x80a20300, priority=3D84, wmesg=3D0x8071129a = wdrain,=20 sbt=3Dvalue optimized out, pr=3D0, flags=3Dvalue optimized out) at /usr/src/sys/kern/kern_synch.c:249 #4 0x804e6523 in waitrunningbufspace () at /usr/src/sys/kern/vfs_bio.c:564 #5 0x804e6073 in bufwrite (bp=3Dvalue optimized out) at /usr/src/sys/kern/vfs_bio.c:1226 #6 0x804f05ed in cluster_wbuild (vp=3D0xfe008fec4000, size= =3D32768,=20 start_lbn=3D136, len=3Dvalue optimized out, gbflags=3Dvalue optimi= zed out) at /usr/src/sys/kern/vfs_cluster.c:1002 #7 0x804efbc3 in cluster_write (vp=3D0xfe008fec4000,=20 bp=3D0xff80f83da6f0, filesize=3D4456448, seqcount=3D127,=20 gbflags=3Dvalue optimized out) at /usr/src/sys/kern/vfs_cluster.c:5= 92 #8 0x805c1032 in ffs_write (ap=3D0xff8121c81850) at /usr/src/sys/ufs/ffs/ffs_vnops.c:801 #9 0x8067fe21 in VOP_WRITE_APV (vop=3Dvalue optimized out,=20 ---Type return to continue, or q return to quit---=20 a=3Dvalue optimized out) at vnode_if.c:999 #10 0x80511eca in vn_write (fp=3D0xfe006a5f7410,=20 uio=3D0xff8121c81a90, active_cred=3D0x0, flags=3Dvalue optimized= out,=20 td=3D0x0) at vnode_if.h:413 #11 0x8050eb3a in vn_io_fault (fp=3D0xfe006a5f7410,=20 uio=3D0xff8121c81a90, active_cred=3D0xfe006a6ca000, flags=3D0= ,=20 td=3D0xfe000c012920) at /usr/src/sys/kern/vfs_vnops.c:983 #12 0x804b506a in dofilewrite (td=3D0xfe000c012920, fd=3D5,= =20 fp=3D0xfe006a5f7410, auio=3D0xff8121c81a90,=20 offset=3Dvalue optimized out, flags=3D0) at file.h:290 #13 0x804b4cde in sys_write (td=3D0xfe000c012920,=20 uap=3Dvalue optimized out) at /usr/src/sys/kern/sys_generic.c:460 #14 0x8061807a in amd64_syscall (td=3D0xfe000c012920, traced= =3D0) at subr_syscall.c:134 #15 0x806017ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #16 0x0044e75a in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 Please apply (mostly debugging) patch below, then reproduce the issue. I need the backtrace of the 'main' hung process, assuming it is stuck in the waitrunningbufspace(). Also, from the same kgdb session, print runningbufreq, runningbufspace and lorunningspace
Re: Filesystem wedges caused by r251446
Konstantin Belousov wrote: On Fri, Jul 12, 2013 at 11:34:18PM +0200, Ian FREISLICH wrote: (kgdb) print runningbufreq $1 = 1 (kgdb) print runningbufspace $2 = 0 (kgdb) print lorunningspace $3 = 4587520 (kgdb) print hirunningspace $4 = 4194304 This is extremely weird. The hirunningspace is less then lorunningspace, am I right ? This causes the runningbufspace machinery to never wake up Yes. This state of affairs doesn't happen on r251445 and further testing on my side shows it doesn't hapen on all my amd64 servers. It appears that this particular server type (Dell R200) running amd64 with geom_mirror is affected. I will have to test further by destroying the mirror and removing it from the kernel and see if I can still reproduce the issue. Perhaps r251446 exposes insufficient locking on opperations affecting these variables. FWIW, I cannot reproduce the problem if the mirror is rebuilding. I just verified on the 4G VM on amd64, my numbers for lo is 4587520, for high 6881280. Verify your tuning and kernel options, which you should have provided with the original report, I think. Sorry about that (and I'm relieved:) I had originally compiled with CPUTYPE?=opteron which is incorrect for this CPU. However the problem persists with CPUTYPE?=core2, but I'm not sure how much of a difference this makes with clang. Also, I have another affected host that's compiled with gcc and the correct CPUTYPE so I doubt it's the compiler. I've attached make.conf, kernelconfig and dmesg.boot. You'll notice it's r251446M - which is a result of your patch. Ian -- Ian Freislich cpu HAMMER ident FIREWALL options SCHED_ULE options INET#InterNETworking options FFS #Berkeley Fast Filesystem options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options SOFTUPDATES #Enable FFS soft updates support options PSEUDOFS#Pseudo-filesystem framework options PROCFS options GEOM_PART_GPT options GEOM_LABEL options GEOM_MIRROR options GEOM_GATE # Userland services. options COMPAT_43 options COMPAT_43TTY# BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD32 options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options COMPAT_FREEBSD5 #Compatible with FreeBSD4 options COMPAT_FREEBSD6 #Compatible with FreeBSD4 options COMPAT_FREEBSD7 #Compatible with FreeBSD4 options COMPAT_LINUX32 options LINPROCFS options LINSYSFS options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options CONSPEED=115200 options PRINTF_BUFR_SIZE=128 device pf device pflog device pfsync options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options KDB_TRACE options KDB_UNATTENDED options ALT_BREAK_TO_DEBUGGER options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC makeoptions DEBUG=-g # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel device cpufreq device acpi device pci device smb device smbus device ichsmb # ATA controllers device mfi device scbus # SCSI bus (required for ATA/SCSI) device ahci# AHCI-compatible SATA controllers device ata device ada # Direct Access (disks) device da # Direct Access (disks) device cd # CD device pass# Passthrough device (direct ATA/SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device kbdmux device psm # PS/2 mouse device vga # VGA video card driver device sc device agp # support several AGP chipsets # Serial (COM) ports device uart device
Re: Filesystem wedges caused by r251446
Konstantin Belousov wrote: Yes. This state of affairs doesn't happen on r251445 and further testing on my side shows it doesn't hapen on all my amd64 servers. It appears that this particular server type (Dell R200) running amd64 with geom_mirror is affected. I will have to test further by destroying the mirror and removing it from the kernel and see if I can still reproduce the issue. Perhaps r251446 exposes insufficient locking on opperations affecting these variables. No. The lorunningspace is constant for the system lifetime. It can only be changed by the sysctl vfs.lorunningspace. Look into /etc/sysctl.conf or scripts which apply sysctl settings. Wipes egg from face. /etc/sysctl.conf: vfs.hirunningspace=4194304 So, then did r251446 actually start using this value or did other values get significantly tuned up? I recall now setting this nearly a year ago when we did our ZFS tuning and it was a four fold increase on the defaults. Sorry for the noise. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Filesystem wedges caused by r251446
Konstantin Belousov wrote: So, then did r251446 actually start using this value or did other values get significantly tuned up? I recall now setting this nearly a year ago when we did our ZFS tuning and it was a four fold increase on the defaults. r251446 optimized the wakeups by only doing wakeups when runningbufspace actually crossed the lorunningspace. Before, wakeups were performed always on the runningbufspace changes. For ZFS, these settings are completely irrelevant, ZFS does not use buffer cache. A year is so long ago... It might have been tuning for our postgres servers. It might be worth while putting in a sanity check that doesn't allow hirunningspace to be set lower than lorunningspace. Thanks for your patience. Ian -- Ian Freislich ___ 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
Ports with daemons on uninstall...
Hi I have to ask if there's a standard for the way ports should handle their daemons when the port is uninstalled. I've encountered 3 varients of ports behaviour on uninstall: 1. Do nothing 2. Stop the daemon 3. Ask if the daemon should be stopped #1 closely followed by #3 are the least irritating when it comes to portupgrade because you can at least have the service running while upgrading. At least with #3 the upgrade gets paused until the propmpt is answered and you're then aware that some service will go away immediately so you can be prepared to restart it. #2 is extremely irritating because upgrading with portupgrade etc kills the service. For instance isc-dhcpd* does this which means that for some time, dhcp may be unavailable. It could be less irritating if it would automatically start the service, but that can have its own problems. Does the project have a preferred method for handling running daenmons on uninstall? I know that Linux will even start daemons on install. Ian -- Ian Freislich ___ 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
r253351 implicit definition of 'critical_exit'.
Hi Recent change: - # svn log ./sys/sys/sf_buf.h |less r253351 | ae | 2013-07-15 08:16:57 +0200 (Mon, 15 Jul 2013) | 6 lines Introduce new structure sfstat for collecting sendfile's statistics and remove corresponding fields from struct mbstat. Use PCPU counters and SFSTAT_INC() macro for update these statistics. - Includes sys/counter.h in sys/sf_buf.h. sys/counter.h uses macros defined in sys/systm.h resulting in implicit definitions of critical_exit and others and then errors in conflicting types for critical_exit later when sys/system.h is includd _after_ sys/sf_buf.h in sys/i386/i386/uio_machdep.c. I haven't checked amd64 yet, but this patch fixes the build: Index: /usr/src/sys/i386/i386/uio_machdep.c === --- /usr/src/sys/i386/i386/uio_machdep.c(revision 253361) +++ /usr/src/sys/i386/i386/uio_machdep.c(working copy) @@ -44,8 +44,8 @@ #include sys/mutex.h #include sys/proc.h #include sys/sched.h +#include sys/systm.h #include sys/sf_buf.h -#include sys/systm.h #include sys/uio.h #include vm/vm.h However, sys/system.h coul equally be included in sys/sf_buf.h before sys/counter.h. I don't know which is the correct fix. Ian -- Ian Freislich ___ 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: Ports with daemons on uninstall...
Walter Hurry wrote: On Mon, 15 Jul 2013 08:34:05 -0500, Mark Felder wrote: As long as this behavior only happens during pkg installs and never with ports, I'm OK. The worst is when a coworker forgets that the mysql port stops the daemon and my coworker upgrades with portmaster... the daemon is off the entire time mysql slowly compiles... I'm not familiar with portmaster, since I use portupgrade. That does the build first, then the deinstall old/install new. Seems a sensible approach anyway, in case the build fails. Doesn't portmaster work similarly? Try doing a 'portupgrade -f isc-dhcp41-server' and watch it leave dhcpd not running. I eventually made the following change so that it wouldn't leave my system in a broken state: /usr/ports/net/isc-dhcp41-server # make clean === Cleaning for isc-dhcp41-server-4.1.e_7,2 [fw2.smmt] /usr/ports/net/isc-dhcp41-server # svn diff Index: pkg-plist === --- pkg-plist (revision 323024) +++ pkg-plist (working copy) @@ -1,6 +1,4 @@ @comment $FreeBSD$ -@unexec %D/etc/rc.d/isc-dhcpd forcestop 2/dev/null || true -%%IPV6%%@unexec %D/etc/rc.d/isc-dhcpd6 forcestop 2/dev/null || true @unexec if cmp -s %D/etc/dhcpd.conf.sample %D/etc/dhcpd.conf; then rm -f %D/etc/dhcpd.conf; fi etc/dhcpd.conf.sample @exec if [ ! -f %D/etc/dhcpd.conf ] ; then cp -p %D/%F %B/dhcpd.conf; fi I don't mind it stopping the daemon, but if it's going to automatically stop it, it should automatically start it too. It's also not consistent - random sample of two: exim and quagga just leave the daemon running. I'm just asking if there's a stated project guideline for what should happen because at the moment it's hard to know what to expect. Maybe its as simple as an install exec that does a 'service foo start'. If it's a first install it will fail because foo_enable=yes won't be set in /etc/rc.conf. Personally, I'd rather that the package management system ports,pkg,etc doesn't take liberties with my running daemons. If I want to kill them off, I'll kill them off, but there have been several times where I've left uninstalled things running while the system was in flux during an upgrade. It was nice to be able to do that. Ian -- Ian Freislich ___ 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
sshd sandbox failure
Hi Since the openssh update in recent -CURRENT, I get these in my auth.log until I disable sandbox UsePrivilegeSeparation in sshd_config. Feb 3 10:02:14 firewall1 sshd[90062]: fatal: ssh_sandbox_child: failed to limit the network socket [preauth] Is there something that I missed during the update? Ian -- Ian Freislich ___ 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
netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory
Hi While recieving my routing table I used to be able to check how far it got by counting the output netstat -rn. It takes about 2 seconds to recieve the routes from my route-server, but over a minute to update the kernel routing table. I'm now getting this error until zebra completes route insertion. [firewall1.jnb1] ~ $ netstat -rn |wc -l netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory 1 [firewall1.jnb1] ~ $ netstat -rn |wc -l 480446 Is there a sysctl that controls this? There's lots of free memory (14GB). I've tuned other limits to stop dummynet crashing which may have affected this, but in the absence of any documentation of which mbuf sysctls affect dummynet I'm shooting in the dark: net.inet.ip.fw.one_pass=0 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.hash_size=1024 net.pf.states_hashsize=1048576 kern.ipc.nmbclusters=1048576 kern.ipc.maxmbufmem=10737418240 kern.ipc.nmbufs=13045170 Ian -- Ian Freislich ___ 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: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory
Hiroki Sato wrote: ia While recieving my routing table I used to be able to check how far ia it got by counting the output netstat -rn. It takes about 2 seconds ia to recieve the routes from my route-server, but over a minute to ia update the kernel routing table. ia ia I'm now getting this error until zebra completes route insertion. ia ia [firewall1.jnb1] ~ $ netstat -rn |wc -l ia netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory ia1 ia [firewall1.jnb1] ~ $ netstat -rn |wc -l ia 480446 Perhaps does the attached patch fix this? Sadly, not. Ian -- Ian Freislich ___ 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: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory
Hiroki Sato wrote: Hm, how about the attached one? I think the cause is just a race when length of the sysctl's output is changed in kernel after the buffer allocation in userspace, not memory shortage. Size of the routing table can quickly change. You are correct. It's growing at about 9000 entries per second (I wish it were faster). This is what the output looks like now. I guess I'm not the average case. [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory 1 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying 314032 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying 332293 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying 340368 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying 374400 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory 1 [firewall1.jnb1] ~ # netstat -rn |wc -l 480073 Ian -- Ian Freislich ___ 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: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory
Hiroki Sato wrote: ia Hiroki Sato wrote: ia Hm, how about the attached one? ia ia I think the cause is just a race when length of the sysctl's output ia is changed in kernel after the buffer allocation in userspace, not ia memory shortage. Size of the routing table can quickly change. ia ia You are correct. It's growing at about 9000 entries per second (I ia wish it were faster). ia ia This is what the output looks like now. I guess I'm not the average ia case. Can you try the attached patch? It will attempt to enlarge the buffer every retry. I think the routing table grows too fast. It still fails. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In-kernel PPPoE
David Rhodus wrote: Does mpd work in -current ? Last tried I, netgraph had problems with mpd. I have successfully used it on -CURRENT as late as: FreeBSD mini 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Wed Nov 17 07:11:06 SAST 2010 i...@mini:/usr/obj/usr/src/sys/APPLE i386 Ian -- Ian Freislich ___ 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: More if_ath churn coming your way!
Adrian Chadd wrote: On 20 January 2011 13:51, Adrian Chadd adrian.ch...@gmail.com wrote: Hi everyone, I'm in the process of merging in the non-intrusive changes to the if_ath code into -HEAD. Ok, so I lied - the ANI changes were slightly intrusive. But all in all the code was just shuffled around a bit. Someone's reported that the AR9285 was once stable but now isn't. I'd really appreciate it if others who are using AR9280/AR9285 chipsets would test this out and get back to me. Oddly enough, I think my AR9285 uses less power now. This I do know however: at boot, it associates much much faster. I used to have to wait at least 10 seconds for the default route interface. Now, association and DHCP blazes through without pausing. Ian -- Ian Freislich ___ 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
