Re: HEADS UP: ncurses is updated
On 4/10/07, Nikolay Pavlov <[EMAIL PROTECTED]> wrote: On Monday, 9 April 2007 at 11:48:08 -0700, Jeremy Chadwick wrote: > On Mon, Apr 09, 2007 at 11:21:08AM -0700, Jeremy Chadwick wrote: > > On Tue, Apr 10, 2007 at 01:49:32AM +0800, Rong-en Fan wrote: > > > On 4/10/07, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > > >The only thing I've found, though, is that dialog(1) does not appear to > > > >properly handle UTF-8 encoding. Line drawing characters show up as > > > >gibberish (alphanumeric characters). I realise dialog isn't part of > > > >ncurses, but it does rely on it. We should consider updating dialog to > > > >match this change. > > > > > > You mean it display sometihng like "tqxu" instead of line drawing > > > characters? > > > Last time I checked, I thought it is terminal related. When I use screen, it > > > uses line drawing character. For PuTTY, see: > > > > > > http://lists.freebsd.org/pipermail/freebsd-questions/2007-April/146577.html > > This is quite applicable. I just now got around to reading it > (should've done this before I sent my previous Email). Yep, that's the > exact problem: > > /usr/bin/dialog: > libdialog.so.5 => /usr/lib/libdialog.so.5 (0x3807e000) > libncurses.so.6 => /lib/libncurses.so.6 (0x38099000) > libc.so.6 => /lib/libc.so.6 (0x380dd000) > > At least I have a workaround with NCURSES_NO_UTF8_ACS=1. :-) I am not sure, but maybe this is related to ncurses update. I am getting this trying to run sysinstall utility: Probing devices, please wait (this can take a while)...BARF 170 <105> Than goes EOL and exit... It's a current from April 6. The ncurses update to 5.6 is in late Jan, and enable wide character support it in late Feb. My sysinstall runs just fine under console and rxvt-unicode on my currenct as of yesterday. -- == - 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: watchdog network card
Wow. Somehow we've slipped through a one-year timewarp: On Tue, Mar 28, 2006 at 07:47:54AM -0300, JoaoBR wrote: > On Tuesday 28 March 2006 07:40, Andrew Reilly wrote: > > > > After the last rebuild on my amd64-x2 box, both the nve ethernet > > on the motherboard and the dc ethernet that I had been using to > > work around other problems in the nve driver stopped working in > > this way. DEVICE_POLLING and ifconfig...polling has got me > > going again. I thoroughly recommend it. > > > > nve does not run polling mode but dc does > > I guess you have an IRQ conflict, nve and dc on the same hw interrupt, and > that setting dc in polling mode worked around this problem then > > you could check vmstat -i with and without polling enabled to see it Thanks for the tip. I haven't been running dc or nve for about a year, now :-) Nfe has been working beautifully for me, without polling. I guess that I should have a look to see if nve has improved in the interim, but it's difficult to make oneself mess with something that isn't broken... Cheers, -- Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Quarterly Status Report, First Quarter of 2007
Introduction This report covers FreeBSD related projects between January and March 2007. This quarter ended with a big bang as a port of Sun's critically acclaimed ZFS was added to the tree and thus will be available in the upcoming FreeBSD 7.0 release. Earlier this year exciting benchmark results showed the fruits of our SMP work. Read more on the details in the "SMP Scalability" report. During the summer, FreeBSD will once again take part in Google's Summer of Code initiative. Student selection is underway and we are looking forward to a couple of exciting projects to come. BSDCan is approaching rapidly, and will be held May 16-19th in Ottawa. Thanks to all the reporters for the excellent work! We hope you enjoy reading. _ Projects * FreeBSD and ZFS * SMP Scalability * USB FreeBSD Team Reports * FreeBSD Security Officer and Security Team * Problem Report Database * Release Engineering * The FreeBSD Foundation Kernel * Building Linux Device Drivers on FreeBSD * Update of the Linux compatibility environment in the kernel Network Infrastructure * FAST_IPSEC Upgrade * Importing trunk(4) from OpenBSD * Intel 3945ABG Wireless LAN Driver: wpi * Multi-link PPP daemon (MPD) Userland Programs * GCC 4.1 integration * malloc(3) Ports * Ports Collection * X.Org 7.2 integration Miscellaneous * BSDCan 2007 * EuroBSDCon 2007 _ BSDCan 2007 URL: http://www.bsdcan.org/2007/ Contact: Dan Langille <[EMAIL PROTECTED]> The Schedule and the Tutorials have been released. Once again, we have a very strong collection of Speakers . BSDCan: Low Cost. High Value. Something for Everyone. Everyone is going to be there. Make your plans now. _ Building Linux Device Drivers on FreeBSD URL: http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html Contact: Luigi Rizzo <[EMAIL PROTECTED]> The above URL documents some work done around January to build an emulation layer for the Linux kernel API that would allow Linux device driver to be built on FreeBSD with as little as possible modifications. Initially the project focused on USB webcams, a category of devices for which there was basically no support so far. The emulation layer, available as a port ( devel/linux-kmod-compat ) simulates enough of the Linux USB stack to let us build, from unmodified Linux sources, two webcam drivers, also available as ports ( multimedia/linux-gspca-kmod and multimedia/linux-ov511-kmod ), with the former supporting over 200 different cameras. While some of the functions map one-to-one, for others it was necessary to build a full emulation (e.g. collecting input from various function calls, and then mapping sets of Linux data structures into functionally equivalent sets of FreeBSD data structures). But overall, this project shows that the software interfaces are reasonably orthogonal to each other so one does not need to implement the full Linux kernel API to get something working. More work is necessary to cover other aspects of the Linux kernel API, e.g. memory mapping, PCI bus access, and the network stack API, so we can extend support to other families of peripherals. Open tasks: 1. Implement more subsystems (e.g. the network interface API; the memory management/pci bus access API). 2. Address licensing issues. In the current port, the C code is entirely new and under a FreeBSD license. Many of the headers have been rewritten (and documented) from scratch (and so under a FreeBSD license as well). Some of the other headers are still taken from various Linux distributions and need to be rewritten to generate BSD-licensed code that can be imported in the kernel instead of being made available as a port. While this is not a concern with GNU drivers, it may be an important feature for drivers that are available under a dual license. _ EuroBSDCon 2007 URL: http://2007.EuroBSDCon.org/ Contact: EuroBSDCon 2007 Organizing Committee <[EMAIL PROTECTED]> The sixth EuroBSDCon will take place at Symbion in Copenhagen, Denmark on Friday the 14th and Saturday 15th of September 2007. The estimated price for the two day conference is 200EUR, excluding Legoland trip and social event. The whole-day trip to Legoland is expected to cost around 130EUR including transportation, some food on the way, and entry fee. Arrangements have been made with a newly renovated Hostel which offers beds for 23EUR per night and 10EUR breakfast. A lounge with sponsored Internet c
Re: Panic on 6.2 AMD
I have a similar problem, maybe its the same
RAM is checked. they look fine.
tips welcome :)
(SMP kernel from Wed Apr 4 17:42:46 GMT)
El lun, 09-04-2007 a las 13:51 -0400, Michael R. Wayne escribió:
> Nobody has any ideas on this one?
> >fault code = supervisor read, page not present
[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 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x38
fault code = supervisor write data, page not present
instruction pointer = 0x8:0x8046c33f
stack pointer = 0x10:0xb776c790
frame pointer = 0x10:0xa0cf1358
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 = 1793 (bmon)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 1d19h58m47s
Dumping 2047 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0xa2
fault code = supervisor write data, page not present
instruction pointer = 0x8:0x805c67a0
stack pointer = 0x10:0xb499d970
frame pointer = 0x10:0xff0005e301f0
code segment= base 0x0, limit 0xf, type 0x1b 1551
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 40 (syncer)
trap number = 12
1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311
1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055
1039 1023 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 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) list *0x805c67a0
0x805c67a0 is in vm_object_pip_add (/usr/src/sys/vm/vm_object.c:281).
276 void
277 vm_object_pip_add(vm_object_t object, short i)
278 {
279
280 VM_OBJECT_LOCK_ASSERT(object, MA_OWNED);
281 object->paging_in_progress += i;
282 }
283
284 void
285 vm_object_pip_subtract(vm_object_t object, short i)
(kgdb) bt
#0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x804156d7 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#3 0x80415d71 in panic (fmt=0xff0072a78980 "X�Kl") at
/usr/src/sys/kern/kern_shutdown.c:565
#4 0x8063a0cf in trap_fatal (frame=0xff0072a78980,
eva=18446742976014820184) at /usr/src/sys/amd64/amd64/trap.c:668
#5 0x8063a44c in trap_pfault (frame=0xb776c6e0, usermode=0) at
/usr/src/sys/amd64/amd64/trap.c:580
#6 0x8063a703 in trap (frame=
{tf_rdi = -1597041832, tf_rsi = -1097588045440, tf_rdx = -1097405784824,
tf_rcx = 4, tf_r8 = -1098265798384, tf_r9 = -1098676372624, tf_rax = 4, tf_rbx
= 4, tf_rbp = -1597041832, tf_r10 = -1097492439552, tf_r11 = -1097588045440,
tf_r12 = 0, tf_r13 = -1597041832, tf_r14 = -1098676373072, tf_r15 =
-1597041832, tf_trapno = 12, tf_addr = 56, tf_flags = -2142769062, tf_err = 2,
tf_rip = -2142846145, tf_cs = 8, tf_rflags = 66050, tf_rsp = -1216952416, tf_ss
= 16}) at /usr/src/sys/amd64/amd64/trap.c:353
#7 0x80622dab in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:168
#8 0x8046c33f in vfs_setdirty (bp=0xa0cf1358) at atomic.h:139
#9 0x80470773 in bdwrite (bp=0xa0cf1358) at
/usr/src/sys/kern/vfs_bio.c:963
#10 0x805a3514 in ffs_write (ap=0xb776ca30) at
/usr/src/sys/ufs/ffs/ffs_vnops.c:772
#11 0x80691c4b in VOP_WRITE_APV (vop=0x808e5900,
a=0xb776ca30) at vnode_if.c:698
#12 0x8049137a in vn_write (fp=0xff004b7a7708,
uio=0xb776cb50, active_cred=0xff007d849d08, flags=0,
td=0xff0072a78980) at vnode_if.h:372
#13 0x80440d67 in dofilewrite (td=0xff0072a78980, fd=3,
fp=0xff004b7a7708,
Re: FreeBSD 6.1-RELEASE source update fails during compilation
Kris Kennaway wrote:
On Mon, Apr 09, 2007 at 09:59:58AM +0200, Robert Joosten wrote:
Hi,
---cut!--
/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genattrtab.c:6240:
internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
{standard input}: Assembler messages:
{standard input}:14060: Warning: partial line at end of file ignored
*** Error code 1
Stop in /usr/src/gnu/usr.bin/cc/cc_tools.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
Yeah, I observed this too a few times. All the times on a poor little
pentium 1/150 with 48meg ram (according dmesg). It's somewhat difficult
too check but I suspect I run out of memory every time.
You will see it logged by syslog and/or on the console if you run out
of memory (and swap) and a process is killed to make room (it will
also usually not die with signal 11, rather signal 9). If you do not
see this then out-of-memory is not the cause, and it is also almost
certain to be marginal or failing hardware.
Kris
I'll agree with Kris here. I have been banging my head against a
P4 1.6GHZ machine running 6.2 for a couple of weeks.
It would not do a "portsanp extract" without falling over with a sig 11
in the middle of the extract - leaving a few file clusters in
questionable state.
As it was a test machine, I swapped in a different HD controller, fresh
HD and it still failed. Then I installed 5.5 and it worked fine, but
very slowly compared to 6.2
So I went back to the 6.2 and it failed again. All on hardware I thought
was rock solid. Then I ran Memtest again and sure enough, the RAM had
gone bad. Popped in a fresh stick and now I'm running memtest for two
days without error now.
Sometimes the older hardware just isn't worth the grief...
Ralph
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: ncurses is updated
On Monday, 9 April 2007 at 11:48:08 -0700, Jeremy Chadwick wrote: > On Mon, Apr 09, 2007 at 11:21:08AM -0700, Jeremy Chadwick wrote: > > On Tue, Apr 10, 2007 at 01:49:32AM +0800, Rong-en Fan wrote: > > > On 4/10/07, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > > >The only thing I've found, though, is that dialog(1) does not appear to > > > >properly handle UTF-8 encoding. Line drawing characters show up as > > > >gibberish (alphanumeric characters). I realise dialog isn't part of > > > >ncurses, but it does rely on it. We should consider updating dialog to > > > >match this change. > > > > > > You mean it display sometihng like "tqxu" instead of line drawing > > > characters? > > > Last time I checked, I thought it is terminal related. When I use screen, > > > it > > > uses line drawing character. For PuTTY, see: > > > > > > http://lists.freebsd.org/pipermail/freebsd-questions/2007-April/146577.html > > This is quite applicable. I just now got around to reading it > (should've done this before I sent my previous Email). Yep, that's the > exact problem: > > /usr/bin/dialog: > libdialog.so.5 => /usr/lib/libdialog.so.5 (0x3807e000) > libncurses.so.6 => /lib/libncurses.so.6 (0x38099000) > libc.so.6 => /lib/libc.so.6 (0x380dd000) > > At least I have a workaround with NCURSES_NO_UTF8_ACS=1. :-) I am not sure, but maybe this is related to ncurses update. I am getting this trying to run sysinstall utility: Probing devices, please wait (this can take a while)...BARF 170 <105> Than goes EOL and exit... It's a current from April 6. -- == - 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: HEADS UP: ncurses is updated
On Tue, Apr 10, 2007 at 01:49:32AM +0800, Rong-en Fan wrote: ... > You mean it display sometihng like "tqxu" instead of line drawing > characters? > Last time I checked, I thought it is terminal related. When I use screen, it > uses line drawing character. For PuTTY, see: PuTTY implemented UTF-8 much later than screen and Linux console. Those (the last two) tend to have $TERM set properly (at least half the time). I could let ncurses guess what to do based on $TERM and locale. For PuTTY, most users have it incorrectly set to "xterm"(*). There are no clues - so I added the environment variable to help. (*) It's incorrect because in several areas it does not match xterm. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpZMNr5k30YW.pgp Description: PGP signature
Re: Stack panic with em driver unload
On 4/6/07, Tai-hwa Liang <[EMAIL PROTECTED]> wrote: 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. I have learned what causes it, at least in our test group's setup... They have an entry in /etc/rc.conf for the device like: ifconfig_emX="addr netmask" And then the script they run assigns emX a DIFFERENT address, thats why you get into the multicast code and then hit the panic. I still would like to see the panic not happen, but to avoid it just dont go assigning different addresses :) Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: ncurses is updated
On Mon, Apr 09, 2007 at 11:21:08AM -0700, Jeremy Chadwick wrote: > On Tue, Apr 10, 2007 at 01:49:32AM +0800, Rong-en Fan wrote: > > On 4/10/07, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > >The only thing I've found, though, is that dialog(1) does not appear to > > >properly handle UTF-8 encoding. Line drawing characters show up as > > >gibberish (alphanumeric characters). I realise dialog isn't part of > > >ncurses, but it does rely on it. We should consider updating dialog to > > >match this change. > > > > You mean it display sometihng like "tqxu" instead of line drawing > > characters? > > Last time I checked, I thought it is terminal related. When I use screen, it > > uses line drawing character. For PuTTY, see: > > > > http://lists.freebsd.org/pipermail/freebsd-questions/2007-April/146577.html This is quite applicable. I just now got around to reading it (should've done this before I sent my previous Email). Yep, that's the exact problem: /usr/bin/dialog: libdialog.so.5 => /usr/lib/libdialog.so.5 (0x3807e000) libncurses.so.6 => /lib/libncurses.so.6 (0x38099000) libc.so.6 => /lib/libc.so.6 (0x380dd000) At least I have a workaround with NCURSES_NO_UTF8_ACS=1. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: ncurses is updated
On Tue, Apr 10, 2007 at 01:49:32AM +0800, Rong-en Fan wrote: > On 4/10/07, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > >The only thing I've found, though, is that dialog(1) does not appear to > >properly handle UTF-8 encoding. Line drawing characters show up as > >gibberish (alphanumeric characters). I realise dialog isn't part of > >ncurses, but it does rely on it. We should consider updating dialog to > >match this change. > > You mean it display sometihng like "tqxu" instead of line drawing > characters? > Last time I checked, I thought it is terminal related. When I use screen, it > uses line drawing character. For PuTTY, see: > > http://lists.freebsd.org/pipermail/freebsd-questions/2007-April/146577.html > > The current dialog + utf8 MacOS's Term.app seems work just fine. > I'm playing with devel/cdialog and no matter it uses ncurses or ncursesw > the result is the same. > > I'm CCing ache@ who imports GNU's dialog to our base and cdialog/ncurses > author, hope they can comment :-) So here's how to reproduce this. I'm using PuTTY 0.59 (and I have tried using the snapshots as well, same behaviour) on Windows, using a font that has Unicode line-drawing characters. PuTTY is set for ISO-8859-1 encoding/translation. My UNIX environment: TERM="xterm" export LANG="en_GB.ISO8859-1" export LC_CTYPE="en_GB.ISO8859-1" export LC_COLLATE="C" Results of COLUMNS=40 dialog --msgbox "testing" 6 30 (sorry if this doesn't come across right, but if I save it to a file and cat it, it does appear correctly): ââââââââââââââââââââââââââââââ â testingâ ââ âââââââââââââââââââââââââââââ⤠â[ OK ]â ââââââââââââââââââââââââââââââ Now we change PuTTY encoding/translation to UTF-8, and the UNIX environment to: export LANG="en_GB.UTF-8" export LC_CTYPE="en_GB.UTF-8" Results of COLUMNS=40 dialog --msgbox "testing" 6 30 : lk x testingx xx tu x[ OK ]x mj mutt and other apps, however, draw line characters just fine with this configuration. This is what I meant by "specific to dialog(1)". Hope this helps. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic on 6.2 AMD
Nobody has any ideas on this one?
> uname:
>FreeBSD 6.2-RELEASE-p2 FreeBSD 6.2-RELEASE-p2
>
> conf file:
>include GENERIC
>ident MsenWeb
>options QUOTA # Add quotas
>options SMP # Support multiple processors
>makeoptions DEBUG=-g
>
>
> Console messages (via serial port):
>cpuid = 0; apic id = 00
>fault virtual address = 0x18c
>fault code = supervisor read, page not present
>instruction pointer = 0x8:0x803eead7
>stack pointer = 0x10:0xa54e9b60
>frame pointer = 0x10:0x4
>code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
>processor eflags= resume, IOPL = 0
>current process = 5 (thread taskq)
>trap number = 12
>panic: page fault
>cpuid = 0
>Uptime: 9d11h33m44s
>
> info file:
>Dump header from device /dev/twed0s1b
> Architecture: amd64
> Architecture Version: 2
> Dump Length: 1073184768B (1023 MB)
> Blocksize: 512
> Dumptime: Thu Apr 5 15:41:03 2007
> Hostname: ww8.msen.com
> Magic: FreeBSD Kernel Dump
> Version String: FreeBSD 6.2-RELEASE-p2 #0: Wed Mar 14 09:38:47 EST 2007
>[EMAIL PROTECTED]:/usr/obj/usr/src/sys/WW8
> Panic String: page fault
> Dump Parity: 2156304966
> Bounds: 13
> Dump Status: good
>
> gdb:
>[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:
>kernel trap 12 with interrupts disabled
>
>
>Fatal trap 12: page fault while in kernel mode
>cpuid = 0; apic id = 00
>fault virtual address = 0x18c
>fault code = supervisor read, page not present
>instruction pointer = 0x8:0x803eead7
>stack pointer = 0x10:0xa54e9b60
>frame pointer = 0x10:0x4
>code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
>processor eflags= resume, IOPL = 0
>current process = 5 (thread taskq)
>trap number = 12
>panic: page fault
>cpuid = 0
>Uptime: 9d11h33m44s
>Dumping 1023 MB (2 chunks)
> chunk 0: 1MB (151 pages) ... ok
> chunk 1: 1023MB (261856 pages) 1007 991 975twe0: completion event for
> nonbusy command
> 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 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
>(kgdb) list *0x803eead7
>0x803eead7 is in _mtx_lock_sleep
> (/usr/src/sys/kern/kern_mutex.c:548).
>543 * If the current owner of the lock is executing
> on another
>544 * CPU, spin instead of blocking.
>545 */
>546 owner = (struct thread *)(v & MTX_FLAGMASK);
>547 #ifdef ADAPTIVE_GIANT
>548 if (TD_IS_RUNNING(owner)) {
>549 #else
>550 if (m != &Giant && TD_IS_RUNNING(owner)) {
>551 #endif
>552 turnstile_release(&m->mtx_object);
>(kgdb) backtrace
>#0 doadump () at pcpu.h:172
>#1 0x0004 in ?? ()
>#2 0x803f9067 in boot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:409
>#3 0x803f9701 in panic (fmt=0xff003dbb6260 "???=") at
> /usr/src/sys/kern/kern_shutdown.c:565
>#4 0x8061a1ef in trap_fatal (frame=0xff003dbb6260,
> eva=18446742975233640112) at /usr/src/sys/amd64/amd64/trap.c:660
>#5 0x8061a716 in trap (frame=
>{tf_rdi = 108, tf_rsi = -1098475937184, tf_rdx = 6, tf_rcx =
> 3221225730, tf_r8 = -1521574640, tf_r9 = -1098687417816, tf_rax = 1, tf_rbx =
> -1099181396776, tf_rbp = 4, tf_r10 = -2138022504, tf_r11 = 0, tf_r12 =
> -1098475937184, tf_r13 = 4, tf_r14 = 1, tf_r15 = 20, tf_trapno = 12, tf_addr
> = 396, tf_flags = -1099181396776, tf_err = 0, tf_rip = -2143360297, tf_cs =
> 8, tf_rflags = 65538, tf_rsp = -1521575056, tf_ss = 16}) at
> /usr/src/sys/amd64/amd64/trap.c:238
>#6 0x80
Re: HEADS UP: ncurses is updated
On 4/10/07, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: On Sat, Apr 07, 2007 at 02:05:45AM +0800, Rong-en Fan wrote: > 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. I just wanted to take a moment to thank you for this. You have no idea how long I've been waiting (okay, now you do: years!), as I never felt comfortable with having two versions of ncurses installed on a single box (base + port). So far it works great. Thank you so much! You are welcome. The only thing I've found, though, is that dialog(1) does not appear to properly handle UTF-8 encoding. Line drawing characters show up as gibberish (alphanumeric characters). I realise dialog isn't part of ncurses, but it does rely on it. We should consider updating dialog to match this change. You mean it display sometihng like "tqxu" instead of line drawing characters? Last time I checked, I thought it is terminal related. When I use screen, it uses line drawing character. For PuTTY, see: http://lists.freebsd.org/pipermail/freebsd-questions/2007-April/146577.html The current dialog + utf8 MacOS's Term.app seems work just fine. I'm playing with devel/cdialog and no matter it uses ncurses or ncursesw the result is the same. I'm CCing ache@ who imports GNU's dialog to our base and cdialog/ncurses author, hope they can comment :-) Regards, Rong-En Fan -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-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: ggate + gmirror write performance woes
Hi!
On Mon, Apr 09, 2007 at 12:55:43PM -0400, Sven Willenberger wrote:
> The next part of the project will be writing the freevrrp failover
> scripts to deal with I/O locking issues that will happen if the ggated
> server fails, etc.
check carp(4) and ports/net/ifstated. You can use identical advbase
configuration on both nodes and prevent service migration back from
second node to first, if first node will reboot.
also, take a look one{start,stop,restart} options for rcNG designed
initscripts.
WBR
Dmitriy
___
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 Fri, 2007-04-06 at 16:18 +0300, Nikolay Pavlov wrote:
> 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
>
kern.ipc.maxsockbuf was the issue here; I increased its value and now I
no longer get the buffer space error. Furthermore, the write speed issue
was also tied to a hardware raid controller issue. After fixing that
issue, and with just the following:
kern.ipc.maxsockbuf=1048576
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072
I can start ggated with -R 262144 -S 262144 as well as the ggatec and
see write speeds of 60+MB/s. I may play around with the settings more
(and see if any further speed improvements occur), but this is quite
acceptable at this point. (For the record nmbclusters is set to 32768).
The next part of the project will be writing the freevrrp failover
scripts to deal with I/O locking issues that will happen if the ggated
server fails, etc.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: ncurses is updated
On Sat, Apr 07, 2007 at 02:05:45AM +0800, Rong-en Fan wrote: > 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. I just wanted to take a moment to thank you for this. You have no idea how long I've been waiting (okay, now you do: years!), as I never felt comfortable with having two versions of ncurses installed on a single box (base + port). So far it works great. Thank you so much! The only thing I've found, though, is that dialog(1) does not appear to properly handle UTF-8 encoding. Line drawing characters show up as gibberish (alphanumeric characters). I realise dialog isn't part of ncurses, but it does rely on it. We should consider updating dialog to match this change. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1-RELEASE source update fails during compilation
On Mon, Apr 09, 2007 at 09:59:58AM +0200, Robert Joosten wrote:
> Hi,
>
> ---cut!--
> > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genattrtab.c:6240:
> > internal compiler error: Segmentation fault: 11
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See http://gcc.gnu.org/bugs.html> for instructions.
> > {standard input}: Assembler messages:
> > {standard input}:14060: Warning: partial line at end of file ignored
> > *** Error code 1
> > Stop in /usr/src/gnu/usr.bin/cc/cc_tools.
> > *** Error code 1
> > Stop in /usr/src.
> > *** Error code 1
> > Stop in /usr/src.
> > *** Error code 1
> > Stop in /usr/src.
>
> Yeah, I observed this too a few times. All the times on a poor little
> pentium 1/150 with 48meg ram (according dmesg). It's somewhat difficult
> too check but I suspect I run out of memory every time.
You will see it logged by syslog and/or on the console if you run out
of memory (and swap) and a process is killed to make room (it will
also usually not die with signal 11, rather signal 9). If you do not
see this then out-of-memory is not the cause, and it is also almost
certain to be marginal or failing hardware.
Kris
pgpEfUwXnHGLc.pgp
Description: PGP signature
Re: FreeBSD 6.1-RELEASE source update fails during compilation
Hi,
---cut!--
> /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genattrtab.c:6240:
> internal compiler error: Segmentation fault: 11
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> {standard input}: Assembler messages:
> {standard input}:14060: Warning: partial line at end of file ignored
> *** Error code 1
> Stop in /usr/src/gnu/usr.bin/cc/cc_tools.
> *** Error code 1
> Stop in /usr/src.
> *** Error code 1
> Stop in /usr/src.
> *** Error code 1
> Stop in /usr/src.
Yeah, I observed this too a few times. All the times on a poor little
pentium 1/150 with 48meg ram (according dmesg). It's somewhat difficult
too check but I suspect I run out of memory every time.
I happened to run make installworld with a DESTDIR pointing to this box
using nfs using a more recent athlon 3000 :-)
That slow box runs postfix and procmail to a nfs-mounted spool. It runs
great without any sign indicating bad memory; did not run a memcheck
though. Increasing swap didn't solve this matter.
Hth.
Cheers,
Robert
PS: recommend to check out releng_6_2 if able; just to be sure.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
