Re: Stack panic with em driver unload
On Thu, 5 Apr 2007, Jack Vogel wrote: Our test group uses a script that does 100 iterations of a module load, then bring up all interfaces, and then unload driver. Depending on the system in anything from just a few iterations to 20 or more, the system will panic. Just a "me too" here. :p Its doing an em_detach() which calls ether_ifdetach() which goes to if_detach, in_delmulti_ifp, in_delmulti_locked, and finally if_delmulti(). The panic is always happening on a cmpxchgq instruction so I assume its the LOCK macro, whats odd is that its not always the same reason, sometimes one register is 0 so its a page fault trap, but on other iterations its a general protection fault because the register is some big invalid number :) I run into this panic regularly. Apparently the result and condition to trigger the panic are the same as yours: running "while true; do ifconfig xxx up; kldunload if_xxx; done" and ending up with panicking at the cmpxchgq instruction. I am hardpressed to see this as a driver problem, but I'm willing to be proven wrong, does someone who knows the stack code better than me have any insights or ideas? It also appears system dependent, I have a couple machines I've tried to reproduce in on and have been unable. I also am told it happens on both amd64 and i386, but it seems easier to reproduce on the former. Dunno about amd64 since I only have i386 around; however, I'm sure the panic I observed is reproducible on my -CURRENT driver development box. Lastly, from evidence so far I think this doesnt happen on CURRENT, but the test group hasnt checked that only I have and I dont have as much hardware :) FWIW, I usually run into this panic after upgrading to a newer HEAD. Sometimes I can make the aforementioned ifconfig/kldunload script to survive longer by doing a clean rebuild on my driver. -- Cheers, Tai-hwa Liang ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Changing Console Resolution - Vidcontrol
On Thu, Apr 05, 2007 at 04:27:46PM +0200, Oliver Fromme wrote: > I think 800x600x4 would be even quicker, because no VESA > calls are required at all for screen output. Oops, I was mistaken. 800x600x4 (MODE_258) is what I'm using. 800x600x8 returns "Operation not supported" when trying to switch to it, as do both 4 and 8 bit 1024x768 modes. 16-bit and 32-bit modes work at the higher resolution but they're slow as molasses so I don't use them(1). I'd rather use 4-bit anyway as IMO there's very few reasons to have more than 16 colors in console mode. elinks is the only program I know of that claims to be able to use more and syscons may not even support the control codes it's using. > (All x4 modes use a planar layout. If such a bitplane is > larger than 64K, so-called bank switching is required to > access all of the video memory, because the VGA address > space allows only a 64K window for access at once. VESA > calls are required to perform the bank switching. As yes, I'm having flashbacks to the "good ol' days" right now :) I mostly stuck to tweaking the VGA registers at the lower resolution modes as VESA support was pretty spotty on most hardware at the time. I do remember using bank switching on occasion though. > I think FreeBSD's syscons supports it via "flags 0x80" > for the sc device in the kernel config file. See the > section "Driver Flags" in the sc(4) manual page. Thanks for the tip, but this doesn't work for me. Setting that flag in device.hints results in a blank screen and only a single virtual terminal (ALT+F? just beep). I _am_ able to log in blind and issue commands however. Checking dmesg over ssh didn't show any errors or clues. In any case, allscreens_flags works acceptably for my needs. Strange that it works but the 0x80 flag doesn't. (1) Interesting data point, syscons apparently doesn't use VESA very efficiently. 1024x768x16 mode is very slow -- I can see the screen redrawing line by line in something like top. However, I'm currently using the VESA driver for X at the moment as the trident driver has some problems with the chip in this laptop. 1024x768x16 mode using VESA is fast in X, almost as fast as the accelerated driver. So I know the hardware is capable of it. Unfortunately X has some other issues on this machine, like a weird kkeybooardd ssstutteringg problem when Xkb is enabled, so I tend to use the console a lot. Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Repeatable crash with mkdir causing a divide by zero error
On Fri, Apr 06, 2007 at 11:05:22AM +0100, Tom Judge wrote: > Hi, > > I have seen some problems with a new file system that I created > yesterday in that I could repeatedly get the system to crash in with a > mkdir. > > Here is the disk information > mfid1: on mfi1 > mfid1: 5716992MB (11708399616 sectors) RAID volume 'Images' is optimal > > I created a new file system tuned for 64k blocks, an average file size > of 1Mb, and 2500 files per directory. > > newfs -b 65535 -g 1048576 -h 2500 /dev/mfid1p1 > mount /dev/mfid1p1 /compere > mkdir /compere/images > mkdir /compere/images/1999 > > (Also tested with mkdir test; mkdir test/1998) > > The system is and amd64 system running 6.2-RELEASE and the pmap.c patch. > I have 3 cores cause by 3 different apps (rsync, gmkdir, mkdir) and > can provide any more information if required. I have attached a back > trace, unfortunatly I cannot do any testing as the system is now in > testing (newfs -b 65535 -g 1048576 /dev/mfid1p1 was used and seems not > to cause the bug). This might be simple to fix, but please file a PR if it does not get picked up by someone on this list. Kris > > > kgdb /usr/obj/usr/src/sys/PE2950/kernel.debug /var/crash/vmcore.2 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > 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". > > Unread portion of the kernel message buffer: > > > Fatal trap 18: integer divide fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x8:0x80391347 > stack pointer = 0x10:0xa78736f0 > frame pointer = 0x10:0xff0001d7a600 > 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 = 1206 (mkdir) > trap number = 18 > panic: integer divide fault > cpuid = 0 > Uptime: 4m29s > Dumping 1023 MB (2 chunks) > chunk 0: 1MB (156 pages) ... ok > chunk 1: 1023MB (261800 pages) 1007 991 975 959 943 927 911 895 879 > 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 > 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 > 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:172 > 172 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:172 > #1 0x0004 in ?? () > #2 0x8029a557 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:409 > #3 0x8029abf1 in panic (fmt=0xff0029753000 "X?/") at > /usr/src/sys/kern/kern_shutdown.c:565 > #4 0x803f62ff in trap_fatal (frame=0xff0029753000, > eva=18446742974994109272) at /usr/src/sys/amd64/amd64/trap.c:660 > #5 0x803f67a2 in trap (frame= > {tf_rdi = 0, tf_rsi = 0, tf_rdx = 0, tf_rcx = 1951858688, tf_r8 = > 2500, tf_r9 = 2975, tf_rax = 1951858688, tf_rbx = -2050457600, tf_rbp = > -1099480717824, tf_r10 = 246016, tf_r11 = 184512, tf_r12 = > -1098707543808, tf_r13 = 246015, tf_r14 = -2050457600, tf_r15 = 255, > tf_trapno = 18, tf_addr = 0, tf_flags = 2147483648012, tf_err = 0, > tf_rip = -2143743161, tf_cs = 8, tf_rflags = 66182, tf_rsp = > -1484310784, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:469 > #6 0x803e1a6b in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:168 > #7 0x80391347 in ffs_valloc (pvp=0xff002f24d7c0, > mode=16877, cred=0x0, vpp=0xa7873798) at libkern.h:56 > #8 0x803b8a5e in ufs_mkdir (ap=0xa78739a0) at > /usr/src/sys/ufs/ufs/ufs_vnops.c:1386 > #9 0x8043b355 in VOP_MKDIR_APV (vop=0x7457, > a=0xa78739a0) at vnode_if.c:1251 > #10 0x80310e19 in kern_mkdir (td=0xff002f24d7c0, > path=0xff003dabe400 "", segflg=4, mode=511) at vnode_if.h:653 > #11 0x803f7151 in syscall (frame= > {tf_rdi = 140737488348678, tf_rsi = 511, tf_rdx = 4294967295, > tf_rcx = 1, tf_r8 = 0, tf_r9 = 140737488347272, tf_rax = 136, tf_rbx = > 2, tf_rbp = 140737488348024, tf_r10 = 4294967295, tf_r11 = 582, tf_r12 = > 140737488348678, tf_r13 = 140737488348008, tf_r14 = 0, tf_r15 = 0, > tf_trapno = 12, tf_addr = 34367037072, tf_flags = 0, tf_err = 2, tf_rip > = 34367037084, tf_cs = 43, tf_rflags = 518, tf_rsp = 140737488347720, > tf_ss = 35}) > at /usr/src/sys/amd64/amd64/trap.c:792 > #12 0x803e1c08 in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:270 > #13 0x0008006f5e9c in ?? () > Previo
Re: No buffer space available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, April 06, 2007 06:17:04 +0100 Chris <[EMAIL PROTECTED]> wrote: > I am seeing the no buffer space error on a machine running 6.2 STABLE > feb 24 code, the machine isn't using gmirror. I had to recude > recvspace and sendspace to lower values then I want to get round the > problem. > > 67/1163/1230 mbufs in use (current/cache/total) > 65/275/340/65536 mbuf clusters in use (current/cache/total/max) > 65/255 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) > 146K/840K/987K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/56/8704 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 20233 requests for I/O initiated by sendfile > 7740 calls to protocol drain routines What ethernet driver are you using? In my case, its an fxp device ... trying to see if there is *some* sort of common denominator here :( I just upgraded to the latest kernel last night, to see if maybe a recent commit had a side-effect of fixing it, but won't know anything for another 48 hours or so ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGFpJ44QvfyHIvDvMRAny4AKCOVStyCBOi5Pwt5uyelgze3ML/kQCgxqCp 6VZ/f9U4ibx/zahMLWu+Fs0= =U8Y1 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADS UP: ncurses is updated
Hi all, I just merged ncurses 5.6 and wide character support from HEAD to 6.x. That means ncurses in 6.x is now up-to-date and has wide character support, i.e., ncursesw library. Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Changing Console Resolution - Vidcontrol
> Date: Fri, 06 Apr 2007 15:13:33 +0300 > From: Stefan Lambrev <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > Hi list, > > All those things work only under i386 right ? > There is no option VESA in amd64 ? > > Andrei Kolu wrote: > > On Friday 06 April 2007 02:43, Kevin Oberman wrote: > > > >> I always run a 2000 line scrollback buffer. 200 won't make it to the > >> start of my boot. And, it's SC_HISTORY_SIZE. I'm unclear as to what you > >> refer to as 'slideshow" like teleporting', though. > >> > > > > in case someone want colourful console > > > > options SC_HISTORY_SIZE=1000 > > options SC_NORM_ATTR=(FG_LIGHTGREEN|BG_BLACK) > > options SC_NORM_REV_ATTR=(FG_YELLOW|BG_BLACK) > > options SC_KERNEL_CONS_ATTR=(FG_LIGHTBLUE|BG_BLACK) > > options SC_KERNEL_CONS_REV_ATTR=(FG_LIGHTRED|BG_BLACK) Please don't top post! I don't think you need VESA for any of these...certainly not the SC_HISTORY_SIZE. You do need it for SC_PIXEL_MODE to get more modes on systems that lack that capability (like my T43 laptop). If you can set it to a mode that makes you happy, those commands should work, but some systems offer very few modes without VESA. The T43 offers four...all 80 characters wide from 25 to 60 lines. :-( -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpPMLSLFdx1M.pgp Description: PGP signature
Re: Call for Testers: ncurses 5.6 update
On 4/7/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: Hi list, Rong-en Fan wrote: > On 3/13/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: >> Hello, >> >> Rong-en Fan wrote: >> > On 3/12/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: >> >> Rong-en Fan wrote: >> >> > Hi folks, >> >> > >> >> > ncurses in 6.x is pretty old. We have update-to-date ncurses in 7.x >> >> > with wide character support now. The patch at >> >> > >> >> > >> >> >> http://people.freebsd.org/~rafan/ncurses/ncursesw-5.6-all-fbsd6-20070310.diff.gz >> >> >> >> >> > >> >> > >> >> > gives you ncurses 5.6 and wide character support in 6.x. Please >> >> > apply with 'patch -p0' under /usr/src. >> >> > >> >> > For more information, please visit >> >> > >> >> > http://people.freebsd.org/~rafan/ncurses/ >> >> > >> >> > You can also find individual patches, say ncurses update and wide >> >> > character support, there. >> >> > >> >> > Feedbacks and suggestions are welcome. >> >> > >> >> > P.S. Due to some lib32 issues, the patch above contains changes >> >> > made by ru@ recently for src/Makefile.inc1. >> >> make installworld failed: >> >> >> >> cd /usr/src; /usr/obj/usr/src/make.amd64/make -f Makefile.inc1 >> install32 >> >> mkdir -p /usr/lib32 # XXX add to mtree >> > [...] >> > >> > Sorry about this. I messed up the lib32 changes in the all-in-one >> patch. >> > Could you please use this one instead? >> > >> > >> http://people.freebsd.org/~rafan/ncurses/ncursesw-5.6-all-fbsd6-20070312.diff.gz >> This patch doesn't seems to work anymore on 6.2-stable i386 (my previous test was on amd64) It seems that part of this patch is already in -stable :) If I'm right the patch for src/Makefile.inc1 should be replaced by : --- Makefile.inc1 Fri Apr 6 20:03:35 2007 +++ /root/Makefile.inc1.origFri Apr 6 20:03:17 2007 @@ -894,8 +894,7 @@ bin/csh \ bin/sh \ ${_rescue} \ -lib/ncurses/ncurses \ -lib/ncurses/ncursesw \ +lib/libncurses \ ${_share} \ ${_aicasm} \ usr.bin/awk \ @@ -1000,8 +999,7 @@ _prebuild_libs+= lib/libbz2 lib/libcom_err lib/libcrypt lib/libexpat \ lib/libkvm lib/libmd \ - lib/ncurses/ncurses lib/ncurses/ncursesw \ - lib/libnetgraph lib/libopie lib/libpam \ + lib/libncurses lib/libnetgraph lib/libopie lib/libpam \ lib/libradius \ lib/libsbuf lib/libtacplus lib/libutil \ lib/libz lib/msun I'm still compiling and will let you know if things still works. Yes, you are right. I merged Makefile.inc1 changes two days ago. I'm going to merge the whole changes later. Enjoy! Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Call for Testers: ncurses 5.6 update
Hi list, Rong-en Fan wrote: On 3/13/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: Hello, Rong-en Fan wrote: > On 3/12/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: >> Rong-en Fan wrote: >> > Hi folks, >> > >> > ncurses in 6.x is pretty old. We have update-to-date ncurses in 7.x >> > with wide character support now. The patch at >> > >> > >> http://people.freebsd.org/~rafan/ncurses/ncursesw-5.6-all-fbsd6-20070310.diff.gz >> >> > >> > >> > gives you ncurses 5.6 and wide character support in 6.x. Please >> > apply with 'patch -p0' under /usr/src. >> > >> > For more information, please visit >> > >> > http://people.freebsd.org/~rafan/ncurses/ >> > >> > You can also find individual patches, say ncurses update and wide >> > character support, there. >> > >> > Feedbacks and suggestions are welcome. >> > >> > P.S. Due to some lib32 issues, the patch above contains changes >> > made by ru@ recently for src/Makefile.inc1. >> make installworld failed: >> >> cd /usr/src; /usr/obj/usr/src/make.amd64/make -f Makefile.inc1 install32 >> mkdir -p /usr/lib32 # XXX add to mtree > [...] > > Sorry about this. I messed up the lib32 changes in the all-in-one patch. > Could you please use this one instead? > > http://people.freebsd.org/~rafan/ncurses/ncursesw-5.6-all-fbsd6-20070312.diff.gz This patch doesn't seems to work anymore on 6.2-stable i386 (my previous test was on amd64) It seems that part of this patch is already in -stable :) If I'm right the patch for src/Makefile.inc1 should be replaced by : --- Makefile.inc1 Fri Apr 6 20:03:35 2007 +++ /root/Makefile.inc1.origFri Apr 6 20:03:17 2007 @@ -894,8 +894,7 @@ bin/csh \ bin/sh \ ${_rescue} \ -lib/ncurses/ncurses \ -lib/ncurses/ncursesw \ +lib/libncurses \ ${_share} \ ${_aicasm} \ usr.bin/awk \ @@ -1000,8 +999,7 @@ _prebuild_libs+= lib/libbz2 lib/libcom_err lib/libcrypt lib/libexpat \ lib/libkvm lib/libmd \ - lib/ncurses/ncurses lib/ncurses/ncursesw \ - lib/libnetgraph lib/libopie lib/libpam \ + lib/libncurses lib/libnetgraph lib/libopie lib/libpam \ lib/libradius \ lib/libsbuf lib/libtacplus lib/libutil \ lib/libz lib/msun I'm still compiling and will let you know if things still works. > This works for me (at least make buildworld && make installworld finished without problems). Thanks for testing. Should I recompile and the kernel again or the patch is only in contrib ? :) No you don't. Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 watchdog timeout with nfs
LI Xin wrote: > Hi, Jack, > > Jack Vogel wrote: >>> [EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086 >>> rev=0x02 >>> hdr=0x00 > [...] >> The driver in 6.2 RELEASE fixed all known problems with >> watchdogs, other than REAL issues with the network/hardware. >> Have you tried installing that? > > A friend of mine has reported similar problem, with different em(4) > hardware. The server runs lighttpd on ufs, and the watchdog timeout > occurs no matter whether there is heavy traffic. > > Here is some pciconf -l output which can be interesting. > > [EMAIL PROTECTED] /usr/local/etc]# pciconf -l|grep em > [EMAIL PROTECTED]:0:0: class=0x02 card=0x30a38086 chip=0x108b8086 > rev=0x03 > hdr=0x00 > [EMAIL PROTECTED]:5:0: class=0x02 card=0x30a18086 chip=0x10768086 > rev=0x05 > hdr=0x00 > > Should more debugging aid / information is needed to narrow down the > issue please let us know, thanks! I've reported similar problems multiple times w/o any response. My nic is onboard (no msi involved, no polling used): [EMAIL PROTECTED]:1:0: class=0x02 card=0x80f71043 chip=0x10198086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82547EI Gigabit Ethernet Controller (LOM)' class = network subclass = ethernet trouble% ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:11:2f:9e:c0:e5 inet 10.0.0.248 netmask 0xff00 broadcast 10.0.0.255 media: Ethernet autoselect (1000baseTX ) status: active When I boot I also see massive #'s of link state transitions while dhclient fetches a lease. I've swapped cables, switch ports, etc. I can believe it might be a h/w failure but was hoping I could isolate the issue to be certain (don't like discarding the onboard nic). This is a very current HEAD and has been a problem for several months (all against HEAD). Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 watchdog timeout with nfs
LI Xin wrote: > Hi, Jack, > > Jack Vogel wrote: >>> [EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086 >>> rev=0x02 >>> hdr=0x00 > [...] >> The driver in 6.2 RELEASE fixed all known problems with >> watchdogs, other than REAL issues with the network/hardware. >> Have you tried installing that? > > A friend of mine has reported similar problem, with different em(4) > hardware. The server runs lighttpd on ufs, and the watchdog timeout > occurs no matter whether there is heavy traffic. > > Here is some pciconf -l output which can be interesting. > > [EMAIL PROTECTED] /usr/local/etc]# pciconf -l|grep em > [EMAIL PROTECTED]:0:0: class=0x02 card=0x30a38086 chip=0x108b8086 > rev=0x03 > hdr=0x00 > [EMAIL PROTECTED]:5:0: class=0x02 card=0x30a18086 chip=0x10768086 > rev=0x05 > hdr=0x00 > > Should more debugging aid / information is needed to narrow down the > issue please let us know, thanks! Forgot to mention, the em0 (which have watchdog issue) has device polling turned on. Cheers, -- Xin LI <[EMAIL PROTECTED]> http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: em0 watchdog timeout with nfs
Hi, Jack, Jack Vogel wrote: >> [EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086 >> rev=0x02 >> hdr=0x00 [...] > The driver in 6.2 RELEASE fixed all known problems with > watchdogs, other than REAL issues with the network/hardware. > Have you tried installing that? A friend of mine has reported similar problem, with different em(4) hardware. The server runs lighttpd on ufs, and the watchdog timeout occurs no matter whether there is heavy traffic. Here is some pciconf -l output which can be interesting. [EMAIL PROTECTED] /usr/local/etc]# pciconf -l|grep em [EMAIL PROTECTED]:0:0: class=0x02 card=0x30a38086 chip=0x108b8086 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:5:0: class=0x02 card=0x30a18086 chip=0x10768086 rev=0x05 hdr=0x00 Should more debugging aid / information is needed to narrow down the issue please let us know, thanks! Cheers, -- Xin LI <[EMAIL PROTECTED]> http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: re(4) can't receive some multicast ?
From: FUJITA Kazutoshi <[EMAIL PROTECTED]> Subject: re(4) can't receive some multicast ? Date: Fri, 06 Apr 2007 20:01:05 +0900 (JST) > I have ASUS P5B, running FreeBSD 6.2-STABLE. > It has on-board re(4) as follows, > It seems re0 can't receive IPv6 RA message. > But in promisc mode(running tcpdump on another terminal), > it receives RA. Sorry, this is known problem. -CURRENT re(4) handles variant and it works fine for me. Regards, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ggate + gmirror write performance woes
On Thursday, 5 April 2007 at 16:15:35 -0400, Sven Willenberger wrote: > On Thu, 2007-04-05 at 17:38 +0100, Tom Judge wrote: > > Dmitriy Kirhlarov wrote: > > > On Thu, Apr 05, 2007 at 10:58:56AM -0400, Sven Willenberger wrote: > > >> I am trying to set up a HA type system involving two identical boxes and > > >> have gone through the following to set up the systems: > > >> > > >> Slave server: > > >> ggated -R 196608 -S 196608 > > >> (exporting /dev/amrd1 ) > > >> net.inet.tcp.sendspace: 65536 > > >> net.inet.tcp.recvspace: 131072 > > > > > > Try > > > net.local.stream.recvspace=65535 > > > net.local.stream.sendspace=65535 > > > > > > Also, try increase this sysctls with > > > net.inet.tcp.rfc1323=1 > > > > > > I use it on FreeBSD 5.x with: > > > net.inet.tcp.sendspace=131072 > > > net.inet.tcp.recvspace=131072 > > > net.local.stream.recvspace=65535 > > > net.local.stream.sendspace=65535 > > > > > > ggated -R 1048576 -S 1048576 > > > ggatec -R 1048576 -S 1048576 > > > > > > WBR. > > > Dmitriy > > > ___ > > > freebsd-stable@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > > > > I have seen sustained writes of 30Mb/s using the following configuration: > > > > cat /boot/loader.conf > > kern.ipc.nmbclusters="32768" > > > > cat /etc/sysctl.conf > > net.inet.tcp.sendspace=1048576 > > net.inet.tcp.recvspace=1048576 > > > > Server: > > /sbin/ggated -S 1310720 -R 1310720 -a 172.31.0.18 /etc/gg.exports > > > > Client: > > /sbin/ggatec create -q 2048 -t 5 -S 1310720 -R 1310720 172.31.0.18 > > /dev/amrd0s2 > > > > The raid array is a RAID 1 volume on a dell PERC4 (Dell PE1850) with > > adaptive read ahead and write back caching. > > > > Tom > > I have tried both the settings ideas suggested above but I cannot even > get out of the gate with those. Setting net.inet.tcp.{send,recv}space to > anything higher that 131072 results in ggated bailing with the error: > # ggated -v -a 10.10.0.19 > info: Reading exports file (/etc/gg.exports). > debug: Added 10.10.0.0/24 /dev/amrd1 RW to exports list. > debug: Added 10.10.0.0/24 /dev/amrd3 RW to exports list. > info: Exporting 2 object(s). > error: Cannot open stream socket: No buffer space available. > error: Exiting. For values of net.inet.tcp.{send,recv}space more than 524288 you also need to adjust kern.ipc.maxsockbuf Try this configuration for example: kern.ipc.maxsockbuf=2049152 net.inet.tcp.recvspace=1024576 net.inet.tcp.sendspace=1024576 > > setting net.inet.tcp.{send,recv}space to 131072 allows me to start > ggated with the default R and S values of 131072; anything higher > results in "no buffer space" errors. At 131072 ggated starts but then I > cannot even open a new connection (like ssh) to the server as the ssh > client bails with "no buffer space available". > > more information: > # netstat -m > 514/641/1155 mbufs in use (current/cache/total) > 512/284/796/32768 mbuf clusters in use (current/cache/total/max) > 512/256 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) > 1152K/728K/1880K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/4/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > This is on a FreeBSD 6.2-RELENG box i386 SMP using the amr driver (SATA > Raid using LSiMegaRaid. > > The odd thing is that even after I set the send and recvspace down to > values like 65536, I continue to get the no buffer error when trying to > connect to it remotely again. > > Sven > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- == - Best regards, Nikolay Pavlov. <<<--- == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Changing Console Resolution - Vidcontrol
Hi list, All those things work only under i386 right ? There is no option VESA in amd64 ? Andrei Kolu wrote: On Friday 06 April 2007 02:43, Kevin Oberman wrote: I always run a 2000 line scrollback buffer. 200 won't make it to the start of my boot. And, it's SC_HISTORY_SIZE. I'm unclear as to what you refer to as 'slideshow" like teleporting', though. in case someone want colourful console options SC_HISTORY_SIZE=1000 options SC_NORM_ATTR=(FG_LIGHTGREEN|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_BLACK) options SC_KERNEL_CONS_ATTR=(FG_LIGHTBLUE|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_LIGHTRED|BG_BLACK) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
re(4) can't receive some multicast ?
Hi, I have ASUS P5B, running FreeBSD 6.2-STABLE. It has on-board re(4) as follows, re0: port 0xa800-0xa8ff mem 0xfe9ff000-0xfe9f irq 19 at device 0.0 on pci3 miibus1: on re0 rgephy0: on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1a:92:6e:f2:a5 re0: [FAST] pciconf -lv [EMAIL PROTECTED]:0:0: class=0x02 card=0x81aa1043 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' class = network subclass = ethernet # ifconfig re0 re0: flags=8843 mtu 1500 options=1b inet6 fe80::21a:92ff:fe6e:f2a5%re0 prefixlen 64 scopeid 0x2 inet 172.19.3.78 netmask 0x broadcast 172.19.255.255 ether 00:1a:92:6e:f2:a5 media: Ethernet autoselect (1000baseTX ) status: active # sysctl net.inet6.ip6.accept_rtadv net.inet6.ip6.accept_rtadv: 1 # rtsol -d re0 checking if re0 is ready... re0 is ready send RS on re0, whose state is 2 send RS on re0, whose state is 2 send RS on re0, whose state is 2 No answer after sending 3 RSs stop timer for re0 there is no timer It seems re0 can't receive IPv6 RA message. But in promisc mode(running tcpdump on another terminal), it receives RA. # ifconfig re0 re0: flags=8943 mtu 1500 options=1b inet6 fe80::21a:92ff:fe6e:f2a5%re0 prefixlen 64 scopeid 0x2 inet 172.19.3.78 netmask 0x broadcast 172.19.255.255 ether 00:1a:92:6e:f2:a5 media: Ethernet autoselect (1000baseTX ) status: active # rtsol -d re0 checking if re0 is ready... re0 is ready send RS on re0, whose state is 2 received RA from fe80::230:48ff:fe81:e3fd on re0, state is 2 stop timer for re0 there is no timer # ifconfig re0 re0: flags=8943 mtu 1500 options=1b inet6 fe80::21a:92ff:fe6e:f2a5%re0 prefixlen 64 scopeid 0x2 inet 172.19.3.78 netmask 0x broadcast 172.19.255.255 inet6 2001:240:c4:1:21a:92ff:fe6e:f2a5 prefixlen 64 autoconf ether 00:1a:92:6e:f2:a5 media: Ethernet autoselect (1000baseTX ) status: active Any suggestions? Regards, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Changing Console Resolution - Vidcontrol
On Friday 06 April 2007 02:43, Kevin Oberman wrote: > I always run a 2000 line scrollback buffer. 200 won't make it to the > start of my boot. And, it's SC_HISTORY_SIZE. I'm unclear as to what you > refer to as 'slideshow" like teleporting', though. in case someone want colourful console options SC_HISTORY_SIZE=1000 options SC_NORM_ATTR=(FG_LIGHTGREEN|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_BLACK) options SC_KERNEL_CONS_ATTR=(FG_LIGHTBLUE|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_LIGHTRED|BG_BLACK) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ggate + gmirror write performance woes
Sven Willenberger wrote: On Thu, 2007-04-05 at 17:38 +0100, Tom Judge wrote: Dmitriy Kirhlarov wrote: On Thu, Apr 05, 2007 at 10:58:56AM -0400, Sven Willenberger wrote: I am trying to set up a HA type system involving two identical boxes and have gone through the following to set up the systems: Slave server: ggated -R 196608 -S 196608 (exporting /dev/amrd1 ) net.inet.tcp.sendspace: 65536 net.inet.tcp.recvspace: 131072 Try net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 Also, try increase this sysctls with net.inet.tcp.rfc1323=1 I use it on FreeBSD 5.x with: net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 ggated -R 1048576 -S 1048576 ggatec -R 1048576 -S 1048576 WBR. Dmitriy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" I have seen sustained writes of 30Mb/s using the following configuration: cat /boot/loader.conf kern.ipc.nmbclusters="32768" cat /etc/sysctl.conf net.inet.tcp.sendspace=1048576 net.inet.tcp.recvspace=1048576 Server: /sbin/ggated -S 1310720 -R 1310720 -a 172.31.0.18 /etc/gg.exports Client: /sbin/ggatec create -q 2048 -t 5 -S 1310720 -R 1310720 172.31.0.18 /dev/amrd0s2 The raid array is a RAID 1 volume on a dell PERC4 (Dell PE1850) with adaptive read ahead and write back caching. Tom I have tried both the settings ideas suggested above but I cannot even get out of the gate with those. Setting net.inet.tcp.{send,recv}space to anything higher that 131072 results in ggated bailing with the error: # ggated -v -a 10.10.0.19 info: Reading exports file (/etc/gg.exports). debug: Added 10.10.0.0/24 /dev/amrd1 RW to exports list. debug: Added 10.10.0.0/24 /dev/amrd3 RW to exports list. info: Exporting 2 object(s). error: Cannot open stream socket: No buffer space available. error: Exiting. setting net.inet.tcp.{send,recv}space to 131072 allows me to start ggated with the default R and S values of 131072; anything higher results in "no buffer space" errors. At 131072 ggated starts but then I cannot even open a new connection (like ssh) to the server as the ssh client bails with "no buffer space available". Did you also set kern.ipc.nmbclusters="32768" in /boot/loader.conf and reboot? It sounds like you did not as this is the exact same problem I came across before adjusting that value. <> This is on a FreeBSD 6.2-RELENG box i386 SMP using the amr driver (SATA Raid using LSiMegaRaid. Do you have the cache BBU fitted (Batery Backup Unit) and the array caching set to write back? Also have you tested writing to the array locally without ggate to test the write speed? The odd thing is that even after I set the send and recvspace down to values like 65536, I continue to get the no buffer error when trying to connect to it remotely again. I found that the easyest way to fix this was to reboot the system with good values for net.inet.tcp.{send,recv}space. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Do we need this junk?
Dag-Erling Smørgrav wrote: "Nikolas Britton" <[EMAIL PROTECTED]> writes: Can anything in the list below be removed from CURRENT? No. Modern i386 and amd64 still have an ISA bus, and devices connected to that bus, even if they don't have ISA slots. Some mainboards for industrial use even have them today... And the main CPU is a Pentium 4 or AMD 64 ;) Philipp -- www.familie-ost.info/~pj ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Repeatable crash with mkdir causing a divide by zero error
Hi, I have seen some problems with a new file system that I created yesterday in that I could repeatedly get the system to crash in with a mkdir. Here is the disk information mfid1: on mfi1 mfid1: 5716992MB (11708399616 sectors) RAID volume 'Images' is optimal I created a new file system tuned for 64k blocks, an average file size of 1Mb, and 2500 files per directory. newfs -b 65535 -g 1048576 -h 2500 /dev/mfid1p1 mount /dev/mfid1p1 /compere mkdir /compere/images mkdir /compere/images/1999 (Also tested with mkdir test; mkdir test/1998) The system is and amd64 system running 6.2-RELEASE and the pmap.c patch. I have 3 cores cause by 3 different apps (rsync, gmkdir, mkdir) and can provide any more information if required. I have attached a back trace, unfortunatly I cannot do any testing as the system is now in testing (newfs -b 65535 -g 1048576 /dev/mfid1p1 was used and seems not to cause the bug). kgdb /usr/obj/usr/src/sys/PE2950/kernel.debug /var/crash/vmcore.2 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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". Unread portion of the kernel message buffer: Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0x80391347 stack pointer = 0x10:0xa78736f0 frame pointer = 0x10:0xff0001d7a600 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 = 1206 (mkdir) trap number = 18 panic: integer divide fault cpuid = 0 Uptime: 4m29s Dumping 1023 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 1023MB (261800 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:172 #1 0x0004 in ?? () #2 0x8029a557 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0x8029abf1 in panic (fmt=0xff0029753000 "X?/") at /usr/src/sys/kern/kern_shutdown.c:565 #4 0x803f62ff in trap_fatal (frame=0xff0029753000, eva=18446742974994109272) at /usr/src/sys/amd64/amd64/trap.c:660 #5 0x803f67a2 in trap (frame= {tf_rdi = 0, tf_rsi = 0, tf_rdx = 0, tf_rcx = 1951858688, tf_r8 = 2500, tf_r9 = 2975, tf_rax = 1951858688, tf_rbx = -2050457600, tf_rbp = -1099480717824, tf_r10 = 246016, tf_r11 = 184512, tf_r12 = -1098707543808, tf_r13 = 246015, tf_r14 = -2050457600, tf_r15 = 255, tf_trapno = 18, tf_addr = 0, tf_flags = 2147483648012, tf_err = 0, tf_rip = -2143743161, tf_cs = 8, tf_rflags = 66182, tf_rsp = -1484310784, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:469 #6 0x803e1a6b in calltrap () at /usr/src/sys/amd64/amd64/exception.S:168 #7 0x80391347 in ffs_valloc (pvp=0xff002f24d7c0, mode=16877, cred=0x0, vpp=0xa7873798) at libkern.h:56 #8 0x803b8a5e in ufs_mkdir (ap=0xa78739a0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:1386 #9 0x8043b355 in VOP_MKDIR_APV (vop=0x7457, a=0xa78739a0) at vnode_if.c:1251 #10 0x80310e19 in kern_mkdir (td=0xff002f24d7c0, path=0xff003dabe400 "", segflg=4, mode=511) at vnode_if.h:653 #11 0x803f7151 in syscall (frame= {tf_rdi = 140737488348678, tf_rsi = 511, tf_rdx = 4294967295, tf_rcx = 1, tf_r8 = 0, tf_r9 = 140737488347272, tf_rax = 136, tf_rbx = 2, tf_rbp = 140737488348024, tf_r10 = 4294967295, tf_r11 = 582, tf_r12 = 140737488348678, tf_r13 = 140737488348008, tf_r14 = 0, tf_r15 = 0, tf_trapno = 12, tf_addr = 34367037072, tf_flags = 0, tf_err = 2, tf_rip = 34367037084, tf_cs = 43, tf_rflags = 518, tf_rsp = 140737488347720, tf_ss = 35}) at /usr/src/sys/amd64/amd64/trap.c:792 #12 0x803e1c08 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:270 #13 0x0008006f5e9c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 7 #7 0x80391347 in ffs_valloc (pvp=0xff002f24d7c0, mode=16877, cred=0x0, vpp=0xa7873798) at libkern.h:56 56 static __inline u_int min(u_int a, u_int b) { return (a < b ? a : b); } (kgdb) list 51 static __inline int imax(int a, int b) { return (a > b ? a : b); } 52 static __
Re: ggate + gmirror write performance woes
Hi! On Thu, Apr 05, 2007 at 04:15:35PM -0400, Sven Willenberger wrote: > I have tried both the settings ideas suggested above but I cannot even > get out of the gate with those. Setting net.inet.tcp.{send,recv}space to > > setting net.inet.tcp.{send,recv}space to 131072 allows me to start Now you have good chance to check differences with other recommended sysctl's. :) WBR Dmitriy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"