System freeze on 6.1/2 when running makeworld and dump
Hi, I can consistantly make my system freeze when building makeworld and running dump at the same time. The system actually locks - I have to hit the reset switch to bring the system back to life. I also get a core dump on current. I have mounted the file systems as follows: / /tmp /usr /usr/obj /var The freeze always happens when using dump on the /usr mount point. Most of the writes are going to /usr/obj. I have tried both SCSI hardware and IDE. I have completely swapped RAM (a few times) so I am only as confident as you can be it is not a hardware issue :) I've also tried various CPU burn and RAM testers to make sure there is no issue there. I can also duplicate the issue dumping to /dev/null as opposed to an actual tape drive through the SCSI card. If I run dump without doing a makeworld in the background the system backs up fine. If I run buildworld by itself without dump all is fine as well. Below is some information about my system configuration: GENERIC 6.1 or 6.2 kernel (or current without SMP) (note in the dmesg output it does not say GENERIC, but the CUSTOM config is an exact copy of GENERIC). I can freeze the system using either /dev/null or /dev/nsa0 below: dump -C 32 -0 -a -L -u -f /dev/null /usr The freeze does not happen till dump starts to write the files. Has anyone else experienced this? Kind regards, Geoff Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-RELEASE #0: Sun May 7 04:32:43 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (908.09-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc0440800,MMX+,3DNow+,3DNow> real memory = 1073659904 (1023 MB) avail memory = 1041719296 (993 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe780-0xe7bf at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 4.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xd400-0xd41f irq 7 at device 4.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd000-0xd01f irq 7 at device 4.3 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 4.4 (no driver attached) pcib2: at device 10.0 on pci0 pci2: on pcib2 amr0: mem 0xe300-0xe300 irq 3 at device 10.1 on pci0 amr0: Firmware GH8E, BIOS 1.46, 16MB RAM fxp0: port 0x9800-0x983f mem 0xe080-0xe0800fff,0xe000-0xe001 irq 11 at device 12.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:b7:14:52 atapci1: port 0x9400-0x9407,0x9000-0x9003,0x8800-0x8807,0x8400-0x8403,0x8000-0x803f mem 0xdf80-0xdf81 irq 10 at device 17.0 on pci0 ata2: on atapci1 ata3: on atapci1 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xc-0xcafff,0xd-0xd17ff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 uhub2: ALCOR Generic USB Hub, class 9/0, rev 1.10/1.00, addr 2 uhub2: 4 ports with 4 removable, self powered Timecounter "TSC" frequency 908090887 Hz quality 800 Timecounters tick every 1.000 msec acd0: CDRW at ata1-master PIO4 amrd0: on amr0 amrd0: 21552MB (44138496 sectors) RAID 0 (optimal) Trying to mount root from ufs:/dev/amrd0s1a fxp0: link state changed to UP /dev/ad0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad0s1e on /tmp (ufs, local, soft-updates) /dev/ad0s2e on /usr (ufs, local, soft-updates) /dev/ad0s2d on /usr/obj (ufs, local, soft-updates) /dev/ad0s1d on /var (ufs, local, soft-updates)
Re: (audit?) Panic in 6.2-PRERELEASE
On Fri, Jan 05, 2007 at 03:08:57PM +, Ceri Davies wrote: > > How reproduceable is this? > > So far it's happened this morning and yesterday morning. I haven't seen > it before that. I don't know the cause so I can't reproduce it at will, > but the logs don't give any indication. Chances are that it will happen > again tomorrow, but we'll see. This prediction didn't bear out; no panic today. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpzhBhLF64gr.pgp Description: PGP signature
Re: (audit?) Panic in 6.2-PRERELEASE
On Fri, 5 Jan 2007, Ceri Davies wrote: On Fri, Jan 05, 2007 at 01:34:04PM +, Robert Watson wrote: On Fri, 5 Jan 2007, Ceri Davies wrote: Much as I would love to trust the contents of ub there, I suspect they can't be trusted. Could you print the contents of *fp in kern_fstat() in both of those stacks? I'd particularly like to know the value of fp->f_type, and then depending on the type, possibly the contents of *(struct vnode *)fp->f_vnode for DTYPE_VNODE/TYPE_FIFO or *(struct socket *)fp->f_data in the case of DTYPE_SOCKET. Can you tell me how to get at *fp given that the stack trace shows fstat() and not kern_fstat()? Sorry if I'm being dumb but I don't know how to step into the kern_fstat() call from fstat(). It could be that the stack is hosed losing the frame, or maybe it's inlined (more likely the former I think, as kern_fstat() is a symbol used elsewhere in the kernel). The best bet may be to use the file descriptor number (uap->fd) to pull the struct file reference out of the process. Something on the order of (td->td_proc->p_fd->fd_ofiles[fd]) should return the right struct file *. OK, got it. They're both sockets, data in the attachments. How reproduceable is this? So far it's happened this morning and yesterday morning. I haven't seen it before that. I don't know the cause so I can't reproduce it at will, but the logs don't give any indication. Chances are that it will happen again tomorrow, but we'll see. Hmm. It looks like you printf *(td->td_proc->p_fd->fd_ofiles) without the array index. Could you repeat that, but with the array index -- i.e., td->td_proc->p_fd->fd_ofiles[uap->fd]? Also, it would probably be useful to print uap->fd. Right now you're printing stdin (index 0), but if the index is non-0, we want a different file. thanks, Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (audit?) Panic in 6.2-PRERELEASE
On Sat, Jan 06, 2007 at 12:01:51PM +, Robert Watson wrote: > On Fri, 5 Jan 2007, Ceri Davies wrote: > > >On Fri, Jan 05, 2007 at 01:34:04PM +, Robert Watson wrote: > >> > >>On Fri, 5 Jan 2007, Ceri Davies wrote: > >> > Much as I would love to trust the contents of ub there, I suspect they > can't be trusted. Could you print the contents of *fp in kern_fstat() > in both of those stacks? I'd particularly like to know the value of > fp->f_type, and then depending on the type, possibly the contents of > *(struct vnode *)fp->f_vnode for DTYPE_VNODE/TYPE_FIFO or *(struct > socket *)fp->f_data in the case of DTYPE_SOCKET. > >>> > >>>Can you tell me how to get at *fp given that the stack trace shows > >>>fstat() and not kern_fstat()? Sorry if I'm being dumb but I don't know > >>>how to step into the kern_fstat() call from fstat(). > >> > >>It could be that the stack is hosed losing the frame, or maybe it's > >>inlined (more likely the former I think, as kern_fstat() is a symbol used > >>elsewhere in the kernel). The best bet may be to use the file descriptor > >>number (uap->fd) to pull the struct file reference out of the process. > >>Something on the order of (td->td_proc->p_fd->fd_ofiles[fd]) should > >>return the right struct file *. > > > >OK, got it. They're both sockets, data in the attachments. > > > >>How reproduceable is this? > > > >So far it's happened this morning and yesterday morning. I haven't seen > >it before that. I don't know the cause so I can't reproduce it at will, > >but the logs don't give any indication. Chances are that it will happen > >again tomorrow, but we'll see. > > Hmm. It looks like you printf *(td->td_proc->p_fd->fd_ofiles) without the > array index. Could you repeat that, but with the array index -- i.e., > td->td_proc->p_fd->fd_ofiles[uap->fd]? Also, it would probably be useful > to print uap->fd. Right now you're printing stdin (index 0), but if the > index is non-0, we want a different file. Very tactfully put :) Sorry about that. None of the uap->fd's seem to be valid. In the first case, uap->fd is way too high for the length of fd_ofiles, which only has 21 elements: (kgdb) up 8 #8 0xc04c470d in fstat (td=0xc2eeb180, uap=0xd610dc74) at /usr/src/sys/kern/kern_descrip.c:1075 1075error = kern_fstat(td, uap->fd, &ub); (kgdb) p uap->fd $1 = 89 (kgdb) p *td->td_proc->p_fd->fd_ofiles[uap->fd] Cannot access memory at address 0x0 In the second, uap->fd is nonsense: (kgdb) up 8 #8 0xc04c470d in fstat (td=0xc3109300, uap=0xd617ec74) at /usr/src/sys/kern/kern_descrip.c:1075 1075error = kern_fstat(td, uap->fd, &ub); (kgdb) p uap->fd $1 = -1023449232 (kgdb) Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpKdhWFjvPPl.pgp Description: PGP signature
Re: System freeze on 6.1/2 when running makeworld and dump
On Sat, Jan 06, 2007 at 07:14:41PM +1100, Geoff Roberts wrote: > I can consistantly make my system freeze when building makeworld and > running dump at the same time. The system actually locks - I have to > hit the reset switch to bring the system back to life. I have an old SMP machine at work which sometimes does something similar during its daily housekeeping, where Apache and Nagios are bounced and a small MySQL database dumped. It sometimes appears to hang during the database dump. The debugger shows many processes waiting for UFS. I suspect that the problem starts several minutes earlier. All of the following help to keep the problem away: Upgrading from a several months old 5-STABLE to 6-STABLE. Inserting 60 second delays at various points. Disabling SMP. No core dump available (Mylex disk controller). My next diagnostic step will be a serial console. -- Adrian Wontroba The biggest mistake you can make is to believe that you are working for someone else. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Shutdown problem "Stray IRQ9"
> In comparison, you can search for "stray irq7" and see that > others have seen this message on certain boards where the > LPT/printer port has been disabled in the BIOS, but lpt > support is enabled in FreeBSD. (What I'm trying to say is > that the "stray irq" stuff stems from what I described in > the above paragraph. Hm! My Compaq laptop 9020 has no paralel port. In the kernel I removed all lines regarding it. I still have irq7 messages in console. They are benign, no hang. Intel; could be some controler wants to "hallo, I'm here!". Some BIOSes need full atention. If original poster has motherboard book, he could tweak over options. I recall an issue prior to remove apic on nforce3 mobo. Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Odd GNOME login behaviour
Hi, all. A few days ago I intstalled freebsd 6.1 on my laptop(Samsung X20). I am tracking RELENG_6. I updated all the ports and with it GNOME to 2.16. Now I am experiencing some odd behaviour when logging in into GNOME. gdm starts up ok and I can type my username and password. Than the splask shows up but hangs after displaying "Window Manager". But if I, before logging in, connect to the internet by assigning an adress to bge0 and adding a default route, the login proceeds smoothly. I actually have to connected it doesn't suffice to just assign an adress and a route. I am at loss here how to track down the problem. It confuses me that GNOME needs a connection anyway. And besides: I am running freebsd on a laptop so I won't be able to provide a connection to the internet all the time. Has anybody got any ideas on what is going wrong? Regards and a happy 2007, Viktor Seifert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic in 6.2-RC2
The following panic occurs every one to three hours with 6.2-RC2.
This is the same problem as kern/88472 which is still open.
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 "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
<7>key_spddelete: no SP found.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x23
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc074fc0c
stack pointer = 0x28:0xd0a4e8f8
frame pointer = 0x28:0xd0a4e908
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 = 695 (isakmpd)
trap number = 12
panic: page fault
Uptime: 1h2m52s
Dumping 255 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 255MB (65216 pages) 239 223 207 191 175 159 143 127 111 95 79 63
47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) by t
#0 doadump () at pcpu.h:165
#1 0xc068c76e in boot (howto=260) at
/var/cvsup/usr/src/sys/kern/kern_shutdown.c:409
#2 0xc068ca04 in panic (fmt=0xc08c386a "%s")
at /var/cvsup/usr/src/sys/kern/kern_shutdown.c:565
#3 0xc08690b4 in trap_fatal (frame=0xd0a4e8b8, eva=35)
at /var/cvsup/usr/src/sys/i386/i386/trap.c:837
#4 0xc0868e1b in trap_pfault (frame=0xd0a4e8b8, usermode=0, eva=35)
at /var/cvsup/usr/src/sys/i386/i386/trap.c:745
#5 0xc0868a59 in trap (frame=
{tf_fs = -1035665400, tf_es = -1035665368, tf_ds = 40, tf_edi = 3,
tf_esi = -1037761536, tf_ebp = -794498808, tf_isp = -794498844, tf_ebx
= -1030032896, tf_edx = 1, tf_ecx = 1466671235, tf_eax = 3, tf_trapno = 12,
tf_err = 0, tf_eip = -1066075124, tf_cs = 32, tf_eflags = 66054, tf_esp = 0,
tf_ss = -1030032896}) at /var/cvsup/usr/src/sys/i386/i386/trap.c:435
#6 0xc085712a in calltrap () at
/var/cvsup/usr/src/sys/i386/i386/exception.s:139
#7 0xc074fc0c in key_getsavbyspi (sah=0xc2250400, spi=1466671235)
at /var/cvsup/usr/src/sys/netkey/key.c:2977
#8 0xc07527cd in key_delete (so=0xc2452164, m=0xc29af200, mhp=0xd0a4ea64)
at /var/cvsup/usr/src/sys/netkey/key.c:5427
#9 0xc07548b9 in key_parse (m=0xc29af200, so=0xc2452164)
at /var/cvsup/usr/src/sys/netkey/key.c:7149
#10 0xc0756081 in key_output (m=0xc29af200, so=0xc2452164)
at /var/cvsup/usr/src/sys/netkey/keysock.c:119
#11 0xc07074b0 in raw_usend (so=0x576ba083, flags=0, m=0x1, nam=0x0,
control=0x3,
td=0xc22a6a80) at /var/cvsup/usr/src/sys/net/raw_usrreq.c:263
#12 0xc07565e7 in key_send (so=0xc2452164, flags=0, m=0xc29af200, nam=0x0,
control=0x0,
p=0xc22a6a80) at /var/cvsup/usr/src/sys/netkey/keysock.c:430
#13 0xc06c5863 in sosend (so=0xc2452164, addr=0x0, uio=0xc2602100,
top=0xc29af200,
control=0x0, flags=0, td=0xc22a6a80) at
/var/cvsup/usr/src/sys/kern/uipc_socket.c:836
#14 0xc06b40ee in soo_write (fp=0x3, uio=0xc2602100, active_cred=0xc2447480,
flags=0,
td=0xc22a6a80) at /var/cvsup/usr/src/sys/kern/sys_socket.c:118
#15 0xc06ae7f7 in dofilewrite (td=0xc22a6a80, fd=5, fp=0xc23a2288,
auio=0xc2602100, offset=
) at file.h:252
#16 0xc06ae69b in kern_writev (td=0xc22a6a80, fd=5, auio=0xc2602100)
at /var/cvsup/usr/src/sys/kern/sys_generic.c:402
#17 0xc06ae644 in writev (td=0xc22a6a80, uap=0xd0a4ed04)
at /var/cvsup/usr/src/sys/kern/sys_generic.c:388
#18 0xc08693cb in syscall (frame=
{tf_fs = 59, tf_es = -1078001605, tf_ds = -1078001605, tf_edi =
136368064, tf_esi = -1077941328, tf_ebp = -1077941224, tf_isp = -794497692,
tf_ebx = 5, tf_edx = 23, tf_ecx = 0, tf_eax = 121, tf_trapno = 0, tf_err =
2, tf_eip = 673519919, tf_cs = 51, tf_eflags = 582, tf_esp = -1077941364,
tf_ss = 59}) at /var/cvsup/usr/src/sys/i386/i386/trap.c:983
#19 0xc085717f in Xint0x80_syscall () at
/var/cvsup/usr/src/sys/i386/i386/exception.s:200
#20 0x0033 in ?? ()
(kgdb) q
The following messages are logged just before the panic.
Jan 6 00:34:28 vpn-gateway2 isakmpd[452]: isakmpd: quick mode done: src:
xxx.xxx.xxx.xxx dst: yyy.yyy.yyy.yyy
Jan 6 00:34:28 vpn-gateway2 isakmpd[452]: pf_key_v2_set_spi: ADD: Invalid
argument
The other end of the connection is reported to be "Cisco-based".
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Source MAC addresses when bridge(4) used
I've just noticed an number of unpexected "IP address changed MAC" messages on one of the hosts in my network. It is connected via a FreeBSD bridge to the rest of my network (there aren't enuf network ports in my son's bedroom). The configuration looks like: +-+ +-+ | | | | | laptop1 |-| desktop |--> Rest of network | |dc0 tl0| |rl0 via dumb switch +-+ +-+ The desktop network configuration is: tl0: flags=8943 mtu 1500 ether 00:00:24:28:98:9a media: Ethernet autoselect (100baseTX ) status: active rl0: flags=8943 mtu 1500 options=8 inet 192.168.123.36 netmask 0xff00 broadcast 192.168.123.255 ether 00:20:ed:78:9c:a3 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 bridge0: flags=8043 mtu 1500 ether ca:a9:aa:1e:71:32 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: tl0 flags=3 member: rl0 flags=3 laptop1 is regularly reporting that 192.168.123.36 (the IP address of the desktop) is switching between the two adapters in it: Jan 6 07:27:09 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 08:09:45 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 08:46:11 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 09:29:00 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 12:12:12 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 12:15:31 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 13:06:42 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 16:48:45 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 17:32:22 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 17:33:33 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 17:53:45 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 17:57:05 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 18:17:20 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 18:24:48 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 18:45:08 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 18:48:19 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 19:08:45 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 19:11:50 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 19:32:15 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 19:33:07 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 19:56:34 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 6 22:44:24 laptop1 kernel: arp: 192.168.123.36 moved from 00:20:ed:78:9c:a3 to 00:00:24:28:98:9a on dc0 Jan 6 23:04:26 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Even more unexpectedly, laptop1 is repeating the same "moved" message: Jan 7 00:46:55 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 01:38:09 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 02:29:26 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 03:20:39 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 04:28:59 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 05:18:50 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 06:28:31 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Jan 7 07:16:05 laptop1 kernel: arp: 192.168.123.36 moved from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Both hosts are running 6.1-STABLE: laptop1: FreeBSD laptop1.vk2pj.dyndns.org 6.1-STABLE FreeBSD 6.1-STABLE #0: Wed Nov 15 18:40:00 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/laptop i386 desktop: FreeBSD jashank.vk2pj.dyndns.org 6.1-STABLE FreeBSD 6.1-STABLE #15: Wed A
MultipleBSS and WDS and WPA for adhoc mode
Hello all, I would like to find out if these features ( MultipleBSS, WDS, WPA for adhoc mode) are supposed to be committed to stable branch RELENG_6 or if it is only in current branch RELENG_7. The features were described in the following PDF´s: http://www.bsdcan.org/2005/papers/FreeBSDWirelessNetwokringSupport.pdf http://people.freebsd.org/~sam/BAFUG2006.pdf Thank you Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: benchmark
You should try ports/net/netpipe which has the nice side effect of shoving different message sizes across, and tends to show lots of interesting performance issues. Best, George ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
