Re: buildworld fails after patch (FreeBSD-SA-06:23.openssl)
Ruslan Ermilov wrote: On Fri, Sep 29, 2006 at 09:21:56PM +0200, Uwe Doering wrote: Ruslan Ermilov wrote: It doesn't matter. What you suggest is not the correct way. Perhaps the buildworld is broken, but that's a separate issue. My understanding so far is that the files under '/usr/include' don't get touched until I run 'installworld'. So the 'buildworld' universe has to be self-contained. That's what I was trying to point out. Yes, they are not touched. During buildworld, a special version of the compiler is built that looks headers up in the temporary location, normally /usr/obj/usr/src/tmp/usr/include. Then all (new) headers are installed there, then new libraries are built, then all the rest. If buildworld touched /usr/include, you could easily end up with a partially upgraded system, e.g. if build failed in the middle. If it still fails for you (the buildworld), please collect and put the full combiled stdout + stderr output from running "make buildworld" available somewhere for download and analysis. Colin said he did build all worlds, on all patched branches. Unfortunately I can no longer reproduce the error because I fixed the problem by hand, as pointed out above. Sorry. OK, you had 4.11 and what were you trying to build? RELENG_4? So I can try to reproduce the problem here. Yes, I use RELENG_4. Thanks for your help. Worked for me building fresh RELENG_4: : > uname -srm : FreeBSD 4.10-RELEASE i386 : > tail -3 build.log : rm -f freebsd.submit.cf : m4 -D_CF_DIR_=/spool/ru_tmp/src/etc/sendmail/../../contrib/sendmail/cf/ /spool/ru_tmp/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /spool/ru_tmp/src/etc/sendmail/freebsd.submit.mc > freebsd.submit.cf : chmod 444 freebsd.submit.cf : > Thanks for testing it. So this problem seems to be specific to my workstation. If it happens again I'll investigate it more thoroughly. Regards, Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers [EMAIL PROTECTED] | http://www.escapebox.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Frequent VFS crashes with RELENG_6
I've been getting random crashes like the one below, once or twice a
week, always in the same code path. The system is a RELENG_6 as of Wed
Sep 27 11:42:57 EEST 2006, running on amd64.
-- cut here --
#0 doadump () at pcpu.h:172
No locals.
#1 0x8022d033 in boot (howto=260) at ../../../kern/kern_shutdown.c:409
first_buf_printf = 1
#2 0x8022d687 in panic (fmt=0xff002bb6e260 "°ö¾\"") at
../../../kern/kern_shutdown.c:565
bootopt = 260
newpanic = 0
ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =
0xa7995790, reg_save_area = 0xa79956b0}}
buf = "vm_page_unwire: invalid wire count: 0", '\0'
#3 0x8036980b in vm_page_unwire (m=0xff003e5c79e8,
activate=0) at ../../../vm/vm_page.c:1265
No locals.
#4 0x80282c15 in vfs_vmio_release (bp=0x9a6c2430) at
../../../kern/vfs_bio.c:1470
i = 1
m = 0xff003e5c79e8
#5 0x80285f78 in getnewbuf (slpflag=0, slptimeo=0, size=0,
maxsize=16384) at ../../../kern/vfs_bio.c:1779
addr = 18446744072226429136
bp = (struct buf *) 0x9a6c2430
nbp = (struct buf *) 0x9a69ac48
defrag = 0
nqindex = 1
flushingbufs = 0
#6 0x802863c0 in getblk (vp=0xff001015c5d0, blkno=0,
size=2048, slpflag=0, slptimeo=0, flags=0) at
../../../kern/vfs_bio.c:2486
bsize = 0
maxsize = 0
vmio = 1
offset = 0
bp = (struct buf *) 0x0
bo = (struct bufobj *) 0xff001015c720
#7 0x802880ec in breadn (vp=0xff001015c5d0, blkno=0,
size=0, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at
../../../kern/vfs_bio.c:738
bp = (struct buf *) 0xa79958f0
rabp = (struct buf *) 0x344
i = -1
rv = 0
readwait = 0
#8 0x8028850e in bread (vp=0x0, blkno=0, size=0, cred=0x0,
bpp=0x0) at ../../../kern/vfs_bio.c:719
No locals.
#9 0x803427a5 in ffs_read (ap=0x0) at ../../../ufs/ffs/ffs_vnops.c:523
vp = (struct vnode *) 0xff001015c5d0
ip = (struct inode *) 0xff0017978780
uio = (struct uio *) 0xa7995b50
fs = (struct fs *) 0xff0012347000
bp = (struct buf *) 0x0
lbn = 0
nextlbn = 1
bytesinfile = 0
size = 2048
xfersize = 836
blkoffset = 0
error = 0
orig_resid = 4096
seqcount = 2
ioflag = 131072
#10 0x803b374a in VOP_READ_APV (vop=0x0, a=0x0) at vnode_if.c:643
rc = 0
#11 0x802a74e0 in vn_read (fp=0xff001e5f8078,
uio=0xa7995b50, active_cred=0x0, flags=0,
td=0xff002bb6e260) at vnode_if.h:343
vp = (struct vnode *) 0xff001015c5d0
error = 0
ioflag = 131072
#12 0x80257b64 in dofileread (td=0xff002bb6e260, fd=5,
fp=0xff001e5f8078, auio=0xa7995b50, offset=0, flags=0) at
file.h:240
cnt = 4096
error = 509575288
ktruio = (struct uio *) 0x0
#13 0x80257de0 in kern_readv (td=0xff002bb6e260, fd=5,
auio=0xa7995b50) at ../../../kern/sys_generic.c:192
fp = (struct file *) 0xff001e5f8078
error = 0
#14 0x80257eda in read (td=0x0, uap=0x0) at
../../../kern/sys_generic.c:116
auio = {uio_iov = 0xa7995b40, uio_iovcnt = 1,
uio_offset = 0, uio_resid = 4096, uio_segflg = UIO_USERSPACE, uio_rw =
UIO_READ, uio_td = 0xff002bb6e260}
aiov = {iov_base = 0x666000, iov_len = 4096}
#15 0x8038b2d8 in syscall (frame=
{tf_rdi = 5, tf_rsi = 6709248, tf_rdx = 4096, tf_rcx =
542953472, tf_r8 = 1, tf_r9 = 0, tf_rax = 3, tf_rbx = 6151168, tf_rbp
= 4294967295, tf_r10 = 3260, tf_r11 = 518, tf_r12 = 0, tf_r13 =
140737488327200, tf_r14 = 140737488327328, tf_r15 = 5, tf_trapno = 12,
tf_addr = 9093168, tf_flags = 0, tf_err = 2, tf_rip = 550694412, tf_cs
= 43, tf_rflags = 518, tf_rsp = 140737488327160, tf_ss = 35}) at
../../../amd64/amd64/trap.c:792
params = 0x7fff9200
callp = (struct sysent *) 0x80502ae8
p = (struct proc *) 0xff0022bef6b0
orig_tf_rflags = 518
sticks = 116
error = 0
narg = 3
args = {5, 6709248, 4096, 542953472, 1, 0, 140737488327328, 5}
argp = (register_t *) 0x0
code = 3
reg = 48
regcnt = 6
#16 0x80377bc8 in Xfast_syscall () at
../../../amd64/amd64/exception.S:270
-- and here --
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildworld fails after patch (FreeBSD-SA-06:23.openssl)
On Sat, Sep 30, 2006 at 09:29:06AM +0200, Uwe Doering wrote: > Ruslan Ermilov wrote: [...] > >>>OK, you had 4.11 and what were you trying to build? RELENG_4? > >>>So I can try to reproduce the problem here. > >>Yes, I use RELENG_4. Thanks for your help. > >> > >Worked for me building fresh RELENG_4: > > > >: > uname -srm > >: FreeBSD 4.10-RELEASE i386 > >: > tail -3 build.log > >: rm -f freebsd.submit.cf > >: m4 -D_CF_DIR_=/spool/ru_tmp/src/etc/sendmail/../../contrib/sendmail/cf/ > >/spool/ru_tmp/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 > >/spool/ru_tmp/src/etc/sendmail/freebsd.submit.mc > freebsd.submit.cf > >: chmod 444 freebsd.submit.cf > >: > > > Thanks for testing it. So this problem seems to be specific to my > workstation. If it happens again I'll investigate it more thoroughly. > Don't hesitate to let me know (I'll need a full combined stdout+stderr output to investigate). Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp5qng82oj0P.pgp Description: PGP signature
Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2
On Sat, 30 Sep 2006, Scott Long wrote: David G Lawrence wrote: Attached is a simple user program that will immediately cause pretty much all of the network drivers (at least the ones I own) to stop working and get watchdog timeouts. I am runnign this on a single processor machine with an SMP kernel and it does not have any effect. I dont tink I have any single processor machines running a non SMP kernel to try it on though. Not particularly helpful I know. I'll Actually, I think it is helpful to know that the program only has an effect on some machines. We just need to figure out what the common denominator is. Are you enabling an option, like IPv6, that puts Giant over the network stack? IPv6 has Giant over its netisr, but not over the entire network stack. If Giant is being placed over the stack due to use of an option that forces it (such as KAME IPSEC) you should be able to grep this out of dmesg by doing something along the lines of the following: grep "WARNING: debug.mpsafenet" /var/run/dmesg 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: 6.2 SHOWSTOPPER - em completely unusable on 6.2
On Fri, 29 Sep 2006, David G Lawrence wrote: Are you enabling an option, like IPv6, that puts Giant over the network stack? From dmesg: WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. ...the kernel has IPSEC. If you're not using IPv6 over IPSEC, consider trying FAST_IPSEC isntead. 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: DELL CX300 storage
On Fri, Sep 29, 2006 at 10:11:31PM -0700, Matthew Jacob wrote.. > Or LSI-Logic. Uh, yes. Never worked with LSI-Logic FC HBAs, so I forgot about that one ;) > On 9/29/06, Wilko Bulte <[EMAIL PROTECTED]> wrote: > >On Fri, Sep 29, 2006 at 06:01:25PM -0300, Eduardo Meyer wrote.. > >> How sad :~ > >> > >> But thank you for the quick reply. I hope bsdstats initiative may help > >> somehow this kind of problem. > > > >All this said, I think you will find a Qlogic FC HBA will happily talk to > >your EMC CX! > > > >> >No, there is no Emulex FC driver for FreeBSD. I don't know about the > >> >current situation, but Emulex used to only supply docs under NDA. > >> > > >> >Qlogic was/is much easier in this respect. > >> > > >> >Wilko Bulte [EMAIL PROTECTED] > >> > > >> > >> -- > >> === > >> Eduardo Meyer > >> pessoal: [EMAIL PROTECTED] > >> profissional: [EMAIL PROTECTED] > >> ___ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to > >"[EMAIL PROTECTED]" > >--- end of quoted text --- > > > >-- > >Wilko Bulte [EMAIL PROTECTED] > >___ > >freebsd-stable@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > --- end of quoted text --- -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
western digital mybook (external usb drive, 250gb) takes 15 minutes to be recognized
i'm seeing strange behavior for a wd mybook on freebsd 6.1-RELEASE-p5,
GENERIC kernel.
- the system hangs on boot if it's attached. it stops right after it has
recognized my internal hard drives and dvd writer. perhaps it would
eventually complete the booting process, but i give up after several
minutes, unplug the usb drive and press the reset button.
- after boot, if i attach the drive i see this message on the first
terminal:
-
umass0: Western Digital External HDD, rev 2.00/2.06, addr 2
-
about 15 minutes later (!), i see:
-
da0 at umass-sim0 bus 0 target 0 lun 0
da0: Fixed Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C)
-
no other messages related to the drive are displayed on the console during
these 15 minutes.
once the da0 device is recognized, i can mount the partitions (i've got it
split into two roughly equal-sized primary partitions, one ext2fs and one
msdos), e.g.:
mount -t ext2fs /dev/da0s1/mnt/backup
here is what i see about my usb hardware with dmesg:
-
uhci0: port 0xd400-0xd41f at device 16.0 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 at device 16.1 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
uhci2: port 0xb800-0xb81f at device 16.2 on pci0
uhci2: [GIANT-LOCKED]
usb2: on uhci2
usb2: USB revision 1.0
uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
ehci0: mem 0xed80-0xed8000ff at device
16.3 on pci0
ehci0: [GIANT-LOCKED]
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3: on ehci0
usb3: USB revision 2.0
uhub3: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub3: 6 ports with 6 removable, self powered
-
here is my /etc/usbd.conf file (i've never modified it, i guess this is the
default):
-
# Configuration file the USB daemon.
#
# See usbd.conf(5) for the description of the format of the file.
#
# $FreeBSD: src/etc/usbd.conf,v 1.15 2004/11/28 23:16:00 iedowse Exp $
# Firmware download into the ActiveWire board. After the firmware download
is
# done the device detaches and reappears as something new and shiny
automatically.
#
device "ActiveWire board, firmware download"
vendor 0x0854
product 0x0100
release 0x
attach "/usr/local/bin/ezdownload -f
/usr/local/share/usb/firmware/0854.0100.0_01.hex ${DEVNAME}"
# Firmware download for Entrega Serial DB25 adapter.
#
device "Entrega Serial with UART"
product 0x8001
vendor 0x1645
release 0x0101
attach "if ! kldstat -n usio > /dev/null 2>&1 ; then kldload usio;
fi"
attach "/usr/sbin/ezdownload -v -f
/usr/share/usb/firmware/1645.8001.0101 /dev/${DEVNAME}"
# This entry starts the ColdSync tool in daemon mode. Make sure you have an
up
# to date /usr/local/etc/palms. We override the 'listen' settings for port
and
# type in /usr/local/etc/coldsync.conf.
device "Handspring Visor"
devname "ugen[0-9]+"
vendor 0x082d
product 0x0100
release 0x0100
attach "/usr/local/bin/coldsync -md -p /dev/${DEVNAME} -t usb"
# The fallthrough entry: Nothing is specified, nothing is done. And it
isn't
# necessary at all :-). Just for pretty printing in debugging mode.
#
device "USB device"
-
what could be causing this delay between the attachment of the drive and
registration of the da0 device?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Frequent VFS crashes with RELENG_6
Hi,
1.) Bad ram ? Have you run some memory tester ?
2.) Have you background fsck running on this disk ? If
so try to boot into single user and do a full fsck on this
disk.
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP:
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
On Sat, 30 Sep 2006, Vlad GALU wrote:
I've been getting random crashes like the one below, once or twice a
week, always in the same code path. The system is a RELENG_6 as of Wed
Sep 27 11:42:57 EEST 2006, running on amd64.
-- cut here --
#0 doadump () at pcpu.h:172
No locals.
#1 0x8022d033 in boot (howto=260) at
../../../kern/kern_shutdown.c:409
first_buf_printf = 1
#2 0x8022d687 in panic (fmt=0xff002bb6e260 "°ö¾\"") at
../../../kern/kern_shutdown.c:565
bootopt = 260
newpanic = 0
ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =
0xa7995790, reg_save_area = 0xa79956b0}}
buf = "vm_page_unwire: invalid wire count: 0", '\0' times>___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: western digital mybook (external usb drive, 250gb) takes 15 minutes to be recognized
On Sat, Sep 30, 2006 at 12:34:10PM +0200, Brian King wrote: > i'm seeing strange behavior for a wd mybook on freebsd 6.1-RELEASE-p5, > GENERIC kernel. > > - the system hangs on boot if it's attached. it stops right after it has > recognized my internal hard drives and dvd writer. perhaps it would > eventually complete the booting process, but i give up after several > minutes, unplug the usb drive and press the reset button. > - after boot, if i attach the drive i see this message on the first > terminal: > - > umass0: Western Digital External HDD, rev 2.00/2.06, addr 2 > - > > about 15 minutes later (!), i see: > - > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) > - I've got an external harddrive with a WD disk. It works without problems; umass0: Prolific Technology Inc. Mass Storage Device, rev 2.00/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) I've encrypted mine with GEOM_ELI though, and put a single filesystem on the encryped disk. > no other messages related to the drive are displayed on the console during > these 15 minutes. > > once the da0 device is recognized, i can mount the partitions (i've got it > split into two roughly equal-sized primary partitions, one ext2fs and one > msdos), e.g.: > mount -t ext2fs /dev/da0s1/mnt/backup Maybe the driver is looking for FreeBSD slices? Do you see any disk activity during this 15 minute period? > here is what i see about my usb hardware with dmesg: > - > uhci0: port 0xd400-0xd41f at device 16.0 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 at device 16.1 on pci0 > uhci1: [GIANT-LOCKED] > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 > uhub3: 6 ports with 6 removable, self powered > - Got more or less the same here. A couple of 83C572's with a VT6202 for USB 2.0. > here is my /etc/usbd.conf file (i've never modified it, i guess this is the > default): > - Have you even enabled it? It's disabled by default. As I understand, it's deprecated in favour of devd. I can't find any devd events on my system for the drive, probably because it's handled by atapicam(4). > what could be causing this delay between the attachment of the drive and > registration of the da0 device? Looking for FreeBSD slices is one thing I can think of. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpcaJk8lqkAf.pgp Description: PGP signature
Re: ath0 attach problems
On Fri, 29 Sep 2006 23:05:14 -0700 Sam Leffler <[EMAIL PROTECTED]> wrote: > Vulpes Velox wrote: > > Any suggestions on this? The card in question one supplied by > > Toshiba in their laptops. > > > > ath0: irq 17 at device 0.0 on pci3 > > ath0: 0x1 bytes of rid 0x10 res 3 failed (0, 0x). > > ath0: cannot map register space > > device_attach: ath0 attach returned 6 > > > > > > From lsci -v > > > > 03:00.0 Ethernet controller: Atheros Communications, Inc. Unknown > > device 001c (rev 01) Subsystem: Askey Computer Corp. Unknown > > device 7096 Flags: bus master, fast devsel, latency 0, IRQ 17 > > Memory at (64-bit, non-prefetchable) > > Capabilities: [40] Power Management version 2 > > Capabilities: [50] Message Signalled Interrupts: 64bit- > > Queue=0/0 Enable- Capabilities: [60] Express Legacy Endpoint IRQ 0 > > Capabilities: [90] MSI-X: Enable- Mask- TabSize=1 > > This is likely an ACPI/ASL issue. I saw this on an hp nx6125 laptop > when trying to use the express card slot. The BIOS did not > identify how to map the resources associated with the bridge. Very possibly given some of the funny stuff that shows up in dmesg if I when I poll the processor frequency and temp. Going to check into the ACPI list, iirc there is one, when I get home tomorrow then. Any suggestions on other places to check as well or the like? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Frequent VFS crashes with RELENG_6
On 9/30/06, Martin Blapp <[EMAIL PROTECTED]> wrote:
Hi,
1.) Bad ram ? Have you run some memory tester ?
Yes, memtest86 didn't show anything weird.
2.) Have you background fsck running on this disk ? If
so try to boot into single user and do a full fsck on this
disk.
I have background_fsck="NO" in rc.conf and I checked the whole disk
several times.
Something I forgot to mention earlier: the crash is easier to
reproduce when running rtorrent. The machine did crash without running
it as well, but far more seldom.
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP:
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
On Sat, 30 Sep 2006, Vlad GALU wrote:
> I've been getting random crashes like the one below, once or twice a
> week, always in the same code path. The system is a RELENG_6 as of Wed
> Sep 27 11:42:57 EEST 2006, running on amd64.
>
> -- cut here --
> #0 doadump () at pcpu.h:172
> No locals.
> #1 0x8022d033 in boot (howto=260) at
> ../../../kern/kern_shutdown.c:409
> first_buf_printf = 1
> #2 0x8022d687 in panic (fmt=0xff002bb6e260 "°ö¾\"") at
> ../../../kern/kern_shutdown.c:565
> bootopt = 260
> newpanic = 0
> ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =
> 0xa7995790, reg_save_area = 0xa79956b0}}
> buf = "vm_page_unwire: invalid wire count: 0", '\0' times>
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Poor write performance with LSI 320-2 on 6.1-STABLE
Albert Chin wrote: The arrays are configured with "write-thru" write policy, "adaptive" read policy, and "cachedio" cache policy. cachedio will slow you down on the old LSI cards. Only enable it on the PCI-X and above adapters. /Martin ___ 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! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]
On Fri, Sep 29, 2006 at 11:05:35PM -0700, Paul Allen wrote: > >From Kris Kennaway <[EMAIL PROTECTED]>, Fri, Sep 29, 2006 at 09:42:42PM > >-0400: > > On Fri, Sep 29, 2006 at 08:34:39PM -0500, Craig Boston wrote: > > > On Fri, Sep 29, 2006 at 08:19:04PM -0500, Craig Boston wrote: > > > > On Thu, Sep 28, 2006 at 01:48:42PM -0600, Scott Long wrote: > > > > > http://people.freebsd.org/~scottl/usb_fastintr_RELENG_6.diff > > > > > > > > At first glance it appeared to work, but I'm about to do some more > > > > testing since I just discovered that I have to kldload something > > > > (anything) first in order to reproduce the problem. Weird. > > > > > > I can confirm that despite the other side effect I already mentioned, > > > this patch does fix or at least mask the problem I'm seing with em (and > > > probably usb). > > > > Which is odd since the hypothesis Scott was working on should have > > shown up clearly in the mutex trace, but did not. > > But it is consistent with there being a beat-frequency problem with > respect to the scheduler. I think the number you really need is not > how long giant was held but how long was spent waiting for it. It also seemed to show that nothing was really waiting for it (the cnt_* entries). Kris pgpfcLLwtdeCE.pgp Description: PGP signature
Disappearing IPv6 default route
Dear list, I've had IPv6 connectivity for some years via an IPv6 in IPv4 gif tunnel courtesy of my ISP. However, about a week ago, when I upgraded to 6.2-PRERELEASE, I noticed it had mysteriously stopped working. (It may have died before last week though; but that is the probable time) So this weekend I set out to find out why. After much head scratching, I discovered that the IPv6 default route was not present on the system. If I added it back manually, voilà: IPv6 connectivity back again ... for a few seconds. This is completely reproducible: happy-idiot-talk:~:% sudo route add -inet6 default -interface gif0 ; ping6 clueless.aaisp.net.uk add net default: gateway gif0 PING6(56=40+8+8 bytes) 2001:8b0:151:1::1 --> 2001:8b0:0:81::51bb:5115 16 bytes from 2001:8b0:0:81::51bb:5115, icmp_seq=0 hlim=61 time=32.221 ms 16 bytes from 2001:8b0:0:81::51bb:5115, icmp_seq=1 hlim=61 time=29.856 ms 16 bytes from 2001:8b0:0:81::51bb:5115, icmp_seq=2 hlim=61 time=29.560 ms 16 bytes from 2001:8b0:0:81::51bb:5115, icmp_seq=3 hlim=61 time=30.348 ms 16 bytes from 2001:8b0:0:81::51bb:5115, icmp_seq=4 hlim=61 time=28.957 ms 16 bytes from 2001:8b0:0:81::51bb:5115, icmp_seq=5 hlim=61 time=30.626 ms 16 bytes from 2001:8b0:0:81::51bb:5115, icmp_seq=6 hlim=61 time=29.384 ms 16 bytes from 2001:8b0:0:81::51bb:5115, icmp_seq=7 hlim=61 time=31.815 ms ping6: sendmsg: No route to host ping6: wrote clueless.aaisp.net.uk 16 chars, ret=-1 ping6: sendmsg: No route to host ping6: wrote clueless.aaisp.net.uk 16 chars, ret=-1 ping6: sendmsg: No route to host ping6: wrote clueless.aaisp.net.uk 16 chars, ret=-1 ping6: sendmsg: No route to host ping6: wrote clueless.aaisp.net.uk 16 chars, ret=-1 ping6: sendmsg: No route to host ping6: wrote clueless.aaisp.net.uk 16 chars, ret=-1 ^C --- clueless.aaisp.net.uk ping6 statistics --- 13 packets transmitted, 8 packets received, 38.5% packet loss round-trip min/avg/max/std-dev = 28.957/30.346/32.221/1.088 ms After 8 pings, the default route disappears. tcpdump shows no other traffic to/from the tunnel end-point than the pings and responses. I can't find anything similar reported elsewhere on the 'net. Any clues gratefully received. OS Version: happy-idiot-talk:~:% uname -a FreeBSD happy-idiot-talk.infracaninophile.co.uk 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #9: Fri Sep 29 01:08:43 BST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HAPPY-IDIOT-TALK i386 IPv6 related stuff from rc.conf: gif_interfaces="gif0" gifconfig_gif0="81.187.76.162 81.187.81.6" ipv6_enable="YES" ipv6_defaultrouter="-interface gif0" ipv6_default_interface="gif0" ipv6_ifconfig_gif0="2001:08b0:0151:0001::1 prefixlen 64" ipv6_gateway_enable="YES" happy-idiot-talk:~:% ifconfig gif0 gif0: flags=8051 mtu 1280 tunnel inet 81.187.76.162 --> 81.187.81.6 inet6 fe80::240:5ff:fea5:8db7%gif0 prefixlen 64 scopeid 0x3 inet6 2001:8b0:151:1::1 prefixlen 64 Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Disappearing IPv6 default route
On Sat, Sep 30, 2006 at 08:33:11PM +0100, Matthew Seaman wrote:
>
> Dear list,
>
> I've had IPv6 connectivity for some years via an IPv6 in IPv4 gif tunnel
> courtesy of my ISP. However, about a week ago, when I upgraded to
> 6.2-PRERELEASE, I noticed it had mysteriously stopped working. (It may have
> died before last week though; but that is the probable time) So this
> weekend I set out to find out why.
It is a known problem that I caused. We are working on it. If you
want to, you can try this patch. It should fix your problem.
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
Index: sys/netinet6/nd6.c
===
RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.67
retrieving revision 1.69
diff -I$FreeBSD: -u -r1.67 -r1.69
--- sys/netinet6/nd6.c 16 Sep 2006 06:24:28 - 1.67
+++ sys/netinet6/nd6.c 30 Sep 2006 20:25:33 - 1.69
@@ -1390,7 +1390,8 @@
ip6_sprintf(&llsol), error));
}
}
- } else if (req == RTM_ADD && SDL(gate)->sdl_alen == 0) {
+ } else if (req == RTM_ADD && SDL(gate)->sdl_alen == 0 &&
+ (rt->rt_flags & RTF_HOST) != 0) {
ln->ln_state = ND6_LLINFO_INCOMPLETE;
}
break;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: western digital mybook (external usb drive, 250gb) takes 15 minutes to be recognized
thanks for the response, Roland! On 9/30/06, Roland Smith <[EMAIL PROTECTED]> wrote: I've got an external harddrive with a WD disk. It works without problems; umass0: Prolific Technology Inc. Mass Storage Device, rev 2.00/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) I've encrypted mine with GEOM_ELI though, and put a single filesystem on the encryped disk. interesting. perhaps it's something specific to the MyBook. i'm guessing that you don't have a MyBook? no other messages related to the drive are displayed on the console during > these 15 minutes. > > once the da0 device is recognized, i can mount the partitions (i've got it > split into two roughly equal-sized primary partitions, one ext2fs and one > msdos), e.g.: > mount -t ext2fs /dev/da0s1/mnt/backup Maybe the driver is looking for FreeBSD slices? Do you see any disk activity during this 15 minute period? no, i haven't noticed any. in fact, after about 10 minutes the disk spins down because there's been no activity. Have you even enabled it? It's disabled by default. As I understand, it's deprecated in favour of devd. I can't find any devd events on my system for the drive, probably because it's handled by atapicam(4). i did have usbd enabled; i had enabled it while following some old instructions about how to mount a usb flash stick. i've disabled it now; the behavior remains the same. in fact, i tried running usbd verbosely it in the foreground ( /usr/sbin/usbd -v -v -d ). when attaching the MyBook the following was displayed (immediately): - usbd: device-attach event at 1159638275.878767000, External HDD, Western Digital: vndr=0x1058 prdct=0x0901 rlse=0x0206 clss=0x subclss=0x prtcl=0x device names: umass0 === match attempt: umass0 usbd: Found action 'USB device' for External HDD, Western Digital at umass0 usbd: action 0: USB device usbd: Setting DEVNAME='umass0' - ... and then the long pause before it attaches to da0 (nothing more is displayed at time of attachment) "camcontrol devlist" gives this right after plugging in the drive: at scbus0 target 0 lun 0 (probe0) and after it finally attaches to da0 "camcontrol devlist" gives: at scbus0 target 0 lun 0 (pass0,da0) so it seems that the probe phase is what is taking so long. is there any way to specify what action to take when this specific drive is attached, instead of having the system probe it? i also tried running devd verbosely in the foreground (/sbin/devd -d -D). here is the output when the drive is attached: Processing event '? at port=3 vendor=0x1058 product=0x0901 devclass=0x00 devsubclass=0x00 release=0x0206 sernum="57442D5743414E4B34373234312421" on uhub3' Pushing table setting port=3 setting vendor=0x1058 setting product=0x0901 setting devclass=0x00 setting devsubclass=0x00 setting release=0x0206 setting sernum=57442D5743414E4B34373234312421 setting bus=uhub3 Processing nomatch event Popping table Processing event '+umass0 vendor=0x1058 product=0x0901 devclass=0x00 devsubclass=0x00 release=0x0206 sernum="57442D5743414E4B34373234312421" intclass=0x08 intsubclass=0x06 at port=3 interface=0 vendor=0x1058 product=0x0901 devclass=0x00 devsubclass=0x00 release=0x0206 sernum="57442D5743414E4B34373234312421" intclass=0x08 intsubclass=0x06 on uhub3' Pushing table setting device-name=umass0 setting vendor=0x1058 setting product=0x0901 setting devclass=0x00 setting devsubclass=0x00 setting release=0x0206 setting sernum=57442D5743414E4B34373234312421 setting intclass=0x08 setting intsubclass=0x06 Processing attach event Testing device-name=umass0 against ^ed50 Testing device-name=umass0 against ^ubt[0-9]+ Testing device-name=umass0 against ^ukbd0 Testing device-name=umass0 against ^ums[0-9]+ Testing media type of umass0 against 0x20 Testing media type of umass0 against 0x80 Testing device-name=umass0 against ^(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Popping table ... and then the long pause before it attaches to da0 (nothing more is displayed at time of attachment) this MyBook doesn't have any delay when connecting on linux (ubuntu 6.06) or on windows xp on this computer. any ideas? i'm stumped at this point... ___ 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! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]
On Sat, Sep 30, 2006 at 12:14:17AM -0600, Scott Long wrote: > >One thing this patch definitely did do though, is break the nvidia > >driver pretty badly. Couldn't keep the X server running for more than a > >minute before it froze solid. Lots of Xid: blah blah blah messages. > >Yes I remembered to rebuild the kernel module ;) > > My patch shouldn't have a single effect on nvidia. It just gets the USB > out of the way of other drivers. Weird. But what does 'blah blah' > translate into? It didn't make any sense to me either after looking at the patch... I'm 100% sure that was the only change between boots, and it started working again after I reverted the sys/dev/usb directory and rebuilt. (svk is great for juggling patch sets around) That's one of the reasons I briefly suspected the nvidia driver causing problems somewhere, so I removed that from the mix just to be sure. 'blah blah' translates into numbers that mean nothing to me, but they may be useful to someone: Sep 29 16:57:09 kernel: NVRM: Xid (0001:00): 16, Head Count 0ae5 Sep 29 16:57:09 kernel: NVRM: Xid (0001:00): 16, Head 0001 Count 0ae4 Sep 29 16:57:11 kernel: NVRM: Xid (0001:00): 8, Channel Sep 29 16:57:17 kernel: NVRM: Xid (0001:00): 16, Head Count 0ae6 Sep 29 16:57:17 kernel: NVRM: Xid (0001:00): 16, Head 0001 Count 0ae5 Sep 29 16:57:19 kernel: NVRM: Xid (0001:00): 8, Channel 001e Sep 29 16:57:25 kernel: NVRM: Xid (0001:00): 16, Head Count 0ae7 Sep 29 16:57:25 kernel: NVRM: Xid (0001:00): 16, Head 0001 Count 0ae6 Sep 29 16:57:27 kernel: NVRM: Xid (0001:00): 8, Channel 001e Sep 29 16:57:33 kernel: NVRM: Xid (0001:00): 16, Head Count 0ae8 Sep 29 16:57:33 kernel: NVRM: Xid (0001:00): 16, Head 0001 Count 0ae7 Sep 29 16:57:35 kernel: NVRM: Xid (0001:00): 8, Channel 001e Sep 29 16:57:41 kernel: NVRM: Xid (0001:00): 16, Head Count 0ae9 Sep 29 16:57:41 kernel: NVRM: Xid (0001:00): 16, Head 0001 Count 0ae8 Sep 29 16:57:43 kernel: NVRM: Xid (0001:00): 8, Channel 001e Sep 29 16:57:49 kernel: NVRM: Xid (0001:00): 16, Head Count 0aea Sep 29 16:58:19 kernel: NVRM: Xid (0001:00): 8, Channel Sep 29 16:58:27 kernel: NVRM: Xid (0001:00): 8, Channel 001e Sep 29 16:58:51 last message repeated 3 times Sep 29 16:58:51 kernel: NVRM: Xid (0001:00): 7, Ch 0001 M D bfef0007 intr 0001 ___ 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! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]
On Sat, Sep 30, 2006 at 02:39:06PM -0400, Kris Kennaway wrote: > > > Which is odd since the hypothesis Scott was working on should have > > > shown up clearly in the mutex trace, but did not. > > > > But it is consistent with there being a beat-frequency problem with > > respect to the scheduler. I think the number you really need is not > > how long giant was held but how long was spent waiting for it. > > It also seemed to show that nothing was really waiting for it (the > cnt_* entries). I can set up a serial console an poke around in DDB during my test case if anyone thinks some useful information can be found. Unfortunately I'm remote from the machine right now so I won't be able to do that until Monday :/ Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: western digital mybook (external usb drive, 250gb) takes 15 minutes to be recognized
On Sun, Oct 01, 2006 at 12:32:06AM +0200, Brian King wrote: > >I've got an external harddrive with a WD disk. It works without > >problems; > interesting. perhaps it's something specific to the MyBook. i'm guessing > that you don't have a MyBook? Correct. > >no other messages related to the drive are displayed on the console during > >> these 15 minutes. > >> > >> once the da0 device is recognized, i can mount the partitions (i've got > >it > >> split into two roughly equal-sized primary partitions, one ext2fs and > >one > >> msdos), e.g.: > >> mount -t ext2fs /dev/da0s1/mnt/backup > > > >Maybe the driver is looking for FreeBSD slices? Do you see any disk > >activity > >during this 15 minute period? > > > no, i haven't noticed any. in fact, after about 10 minutes the disk spins > down because there's been no activity. Then I guess it's time for some kernel debugging. ;-) > ... and then the long pause before it attaches to da0 (nothing more is > displayed at time of attachment) > > "camcontrol devlist" gives this right after plugging in the drive: > at scbus0 target 0 lun 0 (probe0) > > and after it finally attaches to da0 "camcontrol devlist" gives: > at scbus0 target 0 lun 0 (pass0,da0) > > so it seems that the probe phase is what is taking so long. Could be. But it could also be the creation of the appropriate devices. So it might be CAM, devfs or a combination of the two. > is there any > way to specify what action to take when this specific drive is attached, > instead of having the system probe it? Sorry, I don't know. > i also tried running devd verbosely in the foreground (/sbin/devd -d -D). > here is the output when the drive is attached: > > > ... and then the long pause before it attaches to da0 (nothing more is > displayed at time of attachment) That more or less rules out devd, I'd say. > this MyBook doesn't have any delay when connecting on linux (ubuntu 6.06) or > on windows xp on this computer. > > any ideas? i'm stumped at this point... Could you test if it makes a difference if there are BSD slices on it? Otherwisw check the partition table with fdisk to see if the partition table is OK. According to §7.3 of "The design and implementation of the FreeBSD operating system" attach operations for da devices are handled in the "CAM peripheral layer", one ot the three layers in the CAM subsystem. It might be usefull to build a kernel with the CAM driver built-in complete with the CAMDEBUG option, see cam(4). You can then use camcontrol(8) to enable debugging options, e.g. CAM_DEBUG_CDB. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpdKdFEIv2km.pgp Description: PGP signature
Re: Frequent VFS crashes with RELENG_6
In message <[EMAIL PROTECTED]>, "Vlad GALU" writes: > On 9/30/06, Martin Blapp <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > 1.) Bad ram ? Have you run some memory tester ? > >Yes, memtest86 didn't show anything weird. > > > 2.) Have you background fsck running on this disk ? If > > so try to boot into single user and do a full fsck on this > > disk. > > > >I have background_fsck="NO" in rc.conf and I checked the whole disk > several times. >Something I forgot to mention earlier: the crash is easier to > reproduce when running rtorrent. The machine did crash without running > it as well, but far more seldom. I've been experiencing the same problem as well. I discovered that the disk on which the filesystem was had some bad sectors causing dump -0Lauf to fail while taking snapshot causing the system to panic. Running smartctl on the device indicated that there were bad sectors 40% within the surface scan being performed by SMART. The drive, an 80 GB Maxtor, was replaced with a 250 GB Western Digital (for a very good price, so good a price I purchased two of them). It was 906 days old, having only been powered off maybe a dozen times over the last three years. -- Cheers, Cy Schubert <[EMAIL PROTECTED]> FreeBSD UNIX: <[EMAIL PROTECTED]> Web: http://www.FreeBSD.org e**(i*pi)+1=0 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipfilter nat w/IPFILTER_DEFAULT_BLOCK kernel
Hi.
As the Subject states, I'm trying to get a FreeBSD 6.1 on sparc64 to be a
firewall/gateway/nat machine using a IPFILTER_DEFAULT_BLOCK kernel.
(hme0 is the external NIC. hme1 is the internal NIC.)
If I remove the line:
pass in quick on hme0 all
none of the machines inside the NAT can reach the Internet although I can still
ssh
into the firewall/gateway machine from inside the NAT.
i.e. NAT breaks without "pass in quick on hme0 all"
"pass in quick on hme0 all" pretty obviously defeats the purpose of the
IPFILTER_DEFAULT_BLOCK kernel so I'm trying to figure out a rule set that
will work with NAT. I'm running a caching named on 127.0.0.1 if that makes
any difference.
All the files are attached.
--
Announcing your plans is a good way to hear the gods' laughter.
# $Id: dhcpd.conf,v 1.6 2001/06/01 06:09:25 mason Exp $
authoritative;
ddns-updates off;
ddns-update-style none;
# Class C, 10/24
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.10 192.168.0.40;
default-lease-time 66;
max-lease-time 1288000;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;
option domain-name-servers 192.168.0.1;
# option domain-name-servers 68.87.71.226 68.87.73.242;
host elink0 {
hardware ethernet 00:11:94:C2:4D:D2;
fixed-address 192.168.0.51;
}
host elink1 {
hardware ethernet 00:11:94:CF:34:CF;
fixed-address 192.168.0.52;
}
host BGH {
hardware ethernet 02:11:24:21:29:36;
fixed-address 192.168.0.53;
}
host bung {
hardware ethernet 00:0F:3D:AE:36:E0;
fixed-address 192.168.0.41;
}
}
# Shebang! not needed.
#
# external interface is hme0 IP obtained via DHCP from ISP
# internal interface is hme1 at 192.168.0.1
pass out quick on hme0 all
pass in quick on hme0 all
pass out quick on hme1 all
pass in quick on hme1 all
pass in quick on lo0 all
pass out quick on lo0 all
# Allow internal traffic
pass in quick on hme1 from 192.168.0.0/24 to any
pass out quick on hme1 from 192.168.0.0/24 to any
pass out quick on hme1 from any to 127.0.0.0/8
# Allow outgoing DNS requests from our servers on .1, .2, and .3
pass in quick on hme1 proto tcp/udp from 192.168.0.0/24 to any port = domain
keep state
pass out quick on hme0 proto tcp/udp from 0/32 to any port = domain keep state
pass out quick on hme0 proto tcp/udp from 192.168.0.0/24 to any port = domain
keep state
# Allow NTP from any internal hosts to any external NTP server.
pass in quick on hme1 proto udp from 192.168.0.0/24 to any port = 123 keep state
pass out quick on hme0 proto udp from any to any port = 123 keep state
# Allow incoming mail
pass in quick on hme0 proto tcp from any to 0/32 port = smtp keep state
pass out quick on hme0 proto tcp from 192.168.1.0/24 to any port = smtp keep
state
# Allow outgoing connections: SSH, WWW, NNTP, mail, whois
pass in quick on hme1 proto tcp from 192.168.0.0/24 to any port = 33654 keep
state
pass out quick on hme0 proto tcp from 192.168.0.0/24 to any port = 33654 keep
state
pass in quick on hme1 proto tcp from 192.168.0.0/24 to any port = 80 keep state
pass out quick on hme0 proto tcp from 192.168.0.0/24 to any port = 80 keep state
pass in quick on hme1 proto tcp from 192.168.0.0/24 to any port = 443 keep state
pass out quick on hme0 proto tcp from 192.168.0.0/24 to any port = 443 keep
state
pass in quick on hme1 proto tcp from 192.168.0.0/24 to any port = smtp keep
state
pass in quick on hme0 proto tcp from 192.168.0.0/24 to any port = whois keep
state
pass out quick on hme1 proto tcp from any to any port = whois keep state
# Allow ssh from offsite
pass in quick on hme0 proto tcp from any to 0/32 port = 33654 keep state
# Allow ping out
pass in quick on hme1 proto icmp all keep state
pass out quick on hme0 proto icmp all keep state
# allow auth out
pass out quick on hme0 proto tcp from 0/32 to any port = 113 keep state
pass out quick on hme0 proto tcp from 0/32 port = 113 to any keep state
#rdr hme0 0.0.0.0/0 port 80 -> 192.168.0.52 port 80 tcp
#rdr ne0 0.0.0.0/0 port 3658 -> 10.0.0.10 port 3658 udp
#rdr ne0 0.0.0.0/0 port 443 -> 10.0.0.2 port 443 tcp
#rdr ne0 0.0.0.0/0 port 53 -> 10.0.0.2 port 53 tcp
#rdr ne0 0.0.0.0/0 port 53 -> 10.0.0.2 port 53 udp
#rdr ne0 0.0.0.0/0 port 80 -> 10.0.0.2 port 80 tcp
#map ne0 10.0.0.0/24 -> 0/32 proxy port ftp ftp/tcp
# rdr hme0 0.0.0.0/0 port 8660 >< 7000 -> 192.168.0.53 port 8660 >< 7000 tcp
#rdr hme0 0.0.0.0/0 port 6889 -> 192.168.0.27 port 6889 tcp
#map hme0 192.168.0.0/24 -> 0/32 portmap tcp/udp 1:65000
#map hme0 192.168.0.0/24 -> 0/32
map hme0 192.168.0.0/24 -> 0.0.0.0/32 portmap tcp/udp 4:65000
map hme0 192.168.0.0/24 -> 0.0.0.0/32
// $FreeBSD: src/etc/namedb/named.conf,v 1.21.2.1 2005/09/10 08:27:27 dougb Exp
$
//
// Refer to the named.conf(5) and named(8) man pages, and the docum
Re: NFS/TCP
I thought I had MFC'ed the fix to releng_6. Maybe I did not :(. Sorry... I don't know if it is too late to get this into 6.1 or not. cc:ing re: for his comments. This is a pretty serious bug, and if there are last minute fixes being accepted, I would like this to go in. Unfortunately, cvs.freebsd.org seems to have changed from what I was familiar with. Now that website displays some perforce nonsense, which I can't grok. I am trying to see if there's a link someplace where I can see cvs comments. mohan --- Kris Kennaway <[EMAIL PROTECTED]> wrote: > I don't know if mohan already committed it, so perhaps he can comment. > > Kris > > On Fri, Sep 29, 2006 at 10:10:02AM +0200, Yuri Khotyaintsev wrote: > > Will a fix for NFS/TCP (nfs_socket.c rev 1.138) be ever committed to stable? > > > > Yuri Khotyaintsev wrote: > > >On Monday 08 May 2006 19:41, Kris Kennaway wrote: > > > > > >>On Mon, May 08, 2006 at 01:54:58PM +0200, Yuri Khotyaintsev wrote: > > >> > > >>>I have an NSF server and several clients which write large text files to > > >>>the server. All machines are running max one week old STABLE and are > > >>>connected to the same gigabit switch, and have identical nics (em). Amd > > >>>mount options are: /defaults > > >>>type:=nfs;cache:=all;opts:=rw,intr,nosuid,grpid,nfsv3,tcp,resvport,soft > > >>> > > >>>Almost all the time I get the following messages on the server: > > >>> > > >>>nfsd send error 32 > > >>>nfsd send error 32 > > >>>nfsd send error 32 > > >>>nfsd send error 32 > > >>>nfsd send error 32 > > >>>... > > >>> > > >>>And corresponding messages on a client: > > >>> > > >>>impossible packet length (8996061) from nfs server db:/export/data1/caa > > >>>impossible packet length (3123011) from nfs server db:/export/data1/caa > > >>>impossible packet length (893006905) from nfs server db:/export/data1/caa > > >>>impossible packet length (842018868) from nfs server db:/export/data1/caa > > >>>impossible packet length (874220) from nfs server db:/export/data1/caa > > >>>impossible packet length (14182767) from nfs server db:/export/data1/caa > > >>>impossible packet length (16777216) from nfs server db:/export/data1/caa > > >>>impossible packet length (758134573) from nfs server db:/export/data1/caa > > >>>impossible packet length (1503661568) from nfs server > > >>>db:/export/data1/caa impossible packet length (1300840) from nfs server > > >>>db:/export/data1/caa ... > > >>> > > >>>And from time to time the files which are written to the server get > > >>>truncated (regardless of the file size)... > > >>> > > >>>Does anybody have an idea how to make it work reliably and not to > > >>>truncate the files? > > >>> > > >>mohan committed a fix for one such problem a few days ago. It will > > >>not be in 6.1-RELEASE, but you should be able to apply the patch > > >>yourself. It would be nice to know how it works for you. > > >> > > >> > > >>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/nfsclient/nfs_socket.c.diff?r > > >>1=text&tr1=1.136&r2=text&tr2=1.139 > > >> > > > > > >I have patched nfs_socket.c on all clients and run the same kind of > > >processing which was causing the problem. I can report that the problem is > > >gone with nfs_socket.c rev 1.139. I only got one "nfs send error 35" on > > >one of the clients instead of hundreds of messages I was seeing before. > > >Thank you very much! > > > > > -- > > Dr. Yuri Khotyaintsev > > Institutet f??r rymdfysik (IRF), Uppsala > > > > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS/TCP
On Sat, Sep 30, 2006 at 06:42:02PM -0700, Mohan Srinivasan wrote: > I thought I had MFC'ed the fix to releng_6. Maybe I did not :(. Sorry... > > I don't know if it is too late to get this into 6.1 or not. cc:ing re: for > his comments. > This is a pretty serious bug, and if there are last minute fixes being > accepted, > I would like this to go in. It should be fine still. > Unfortunately, cvs.freebsd.org seems to have changed from what I was familiar > with. > > Now that website displays some perforce nonsense, which I can't grok. > > I am trying to see if there's a link someplace where I can see cvs comments. cvsweb.freebsd.org is the web interface you are probably thinking of Kris pgpWZCpugEbvn.pgp Description: PGP signature
Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2
I wonder if this is related to the breakage of the Rocketport driver (PR is open, but it appears that nobody has looked at it.) It breaks specifically when I use a piece of software that does a lot of SELECTs on a terminal line to do pretty much what "poll" does but it is not specific to a uniprocessor or SMP kernel - it is reliably hosed in both cases. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind On Fri, Sep 29, 2006 at 05:14:33AM -0700, David G Lawrence wrote: > > >Do you have any history of seeing the watchdog timeout problem on your > > > machine? > > > > On this machine no - but it's the only one running em0. On other > > machines running bge0 then, yes, I see it a lot. But those are all > > SMP machines, aside from one. On that one I am currently building > > the latest 6-STABLE and when it's done (give it a couple of hours) > > I will give it a shot with your code and see what happens. > >Another data point: After rebooting my machine, the program no longer > causes the problem. It appears that something else has to occur first on > the machine to put it into a state that makes it suspectible to the > program. > > -DG > > David G. Lawrence > President > Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 > The FreeBSD Project - http://www.freebsd.org > Pave the road of life with opportunities. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > %SPAMBLOCK-SYS: Matched [EMAIL PROTECTED], message ok ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS/TCP
> > I don't know if it is too late to get this into 6.1 or not. cc:ing re: for > > his comments. > > This is a pretty serious bug, and if there are last minute fixes being > > accepted, > > I would like this to go in. > > It should be fine still. Great. Asking Scott permission before I MFC - the change in question is nfsclient/nfs_socket.c:1.138. This is an important fix that fixes potential data corruptions, very frequent NFS/TCP disconnects and the like. I will MFC to releng_6 once you OK it. mohan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ath0 attach problems
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vulpes Velox Sent: Saturday, September 30, 2006 9:04 AM To: Sam Leffler Cc: freebsd-stable@freebsd.org Subject: Re: ath0 attach problems On Fri, 29 Sep 2006 23:05:14 -0700 Sam Leffler <[EMAIL PROTECTED]> wrote: > Vulpes Velox wrote: > > Any suggestions on this? The card in question one supplied by > > Toshiba in their laptops. > > > > ath0: irq 17 at device 0.0 on pci3 > > ath0: 0x1 bytes of rid 0x10 res 3 failed (0, 0x). > > ath0: cannot map register space > > device_attach: ath0 attach returned 6 > > > > > > From lsci -v > > > > 03:00.0 Ethernet controller: Atheros Communications, Inc. Unknown > > device 001c (rev 01) Subsystem: Askey Computer Corp. Unknown > > device 7096 Flags: bus master, fast devsel, latency 0, IRQ 17 > > Memory at (64-bit, non-prefetchable) > > Capabilities: [40] Power Management version 2 > > Capabilities: [50] Message Signalled Interrupts: 64bit- > > Queue=0/0 Enable- Capabilities: [60] Express Legacy Endpoint IRQ 0 > > Capabilities: [90] MSI-X: Enable- Mask- TabSize=1 > > This is likely an ACPI/ASL issue. I saw this on an hp nx6125 laptop > when trying to use the express card slot. The BIOS did not > identify how to map the resources associated with the bridge. Very possibly given some of the funny stuff that shows up in dmesg if I when I poll the processor frequency and temp. Going to check into the ACPI list, iirc there is one, when I get home tomorrow then. Any suggestions on other places to check as well or the like? [Dustin Coates] Also try freebsd-mobile, as they may have encountered this problem before. ___ 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: NFS/TCP
On Sat, 2006-09-30 at 19:41 -0700, Mohan Srinivasan wrote: > > > I don't know if it is too late to get this into 6.1 or not. cc:ing re: > > > for his comments. > > > This is a pretty serious bug, and if there are last minute fixes being > > > accepted, > > > I would like this to go in. > > > > It should be fine still. > > Great. > > Asking Scott permission before I MFC - the change in question is > nfsclient/nfs_socket.c:1.138. > This is an important fix that fixes potential data corruptions, very frequent > NFS/TCP > disconnects and the like. > > I will MFC to releng_6 once you OK it. > > mohan Approved. Thanks. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: Drives always come up dirty after shutdown on 6.2-PRERELEASE.
On Fri, 2006-09-29 at 15:58 +0100, Josef Karthauser wrote:
> On Fri, Sep 29, 2006 at 09:44:07AM -0500, Brooks Davis wrote:
> > > On my laptop running 6.2-PRERELEASE the drives always mount dirty, which
> > > suggests that they are not being shutdown clean; however the machine
> > > always syncs the disks and switches itself off after a 'shutdown -p
> > > now', and so I'm not sure what it could be.
> > >
> > > Has anyone else seen this?
> >
> > I haven't seen any other reports of this. Have you tried running a
> > "fsck -f" on the drives? It's possible there's a latent error that
> > isn't being fixed by bgfsck.
>
> I thought I did; I'll try again now and see what happens. It's strange
> though because it's every partition.
The /var partition on this 6.1-STABLE box was always mounting dirty,
until I realised that its fstab entry had its Pass# field set to 0:
/dev/ad0s4e /varufs rw 0 0
If you run fsck ("fsck -n" is sufficient) without specifying a file
system so that it reads the list of which file systems to check from
fstab, does it check all those with a non-zero Pass#?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
