bind 9.6.2 dnssec validation bug
I haven't seen any mention of this anywhere. Are there any plans to update BIND in the 8.1/8.2 branches? https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record -- Russell A. Jackson r...@csub.edu Network Analyst California State University, Bakersfield ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bind 9.6.2 dnssec validation bug
On 02/06/2011 10:16 PM, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/06/2011 20:58, Jeremy Chadwick wrote: | On Sun, Feb 06, 2011 at 05:05:08PM -0800, Russell Jackson wrote: | I haven't seen any mention of this anywhere. Are there any plans to | update BIND in the 8.1/8.2 branches? | | https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record | | This was discussed vehemently in December 2010: | | http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/thread.html#60640 Different issue. :) | RELENG_8 (8.2-PRERELEASE as of the time of this writing) now has the | official 9.6.3 as of a commit done by Doug Barton only a few hours ago: | | http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/ | http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/README The 9.6.3 update was in ports the same day it was released, and is now in HEAD and RELENG_8. It's not relevant to RELENG_7, which is the issue that Jeremy posted above. I've sent the information about this problem to the release engineers, whether or not it makes it into 8.2-RELEASE is completely in their hands. However, the material that I sent them about this problem boiled down to the following: 1. This IS a significant bug for those who have DNSSEC validation enabled, however 2. Only a minority of our users have it enabled, and the named.conf in the base does not. 3. The bug can be worked around by restarting the affected name server _after_ it sees the new DS record, however 4. The only way to detect this problem is to wait for it to break. There are also the additional long-standing points that the latest releases of BIND are always in the ports, and anyone doing serious DNSSEC at this stage will want to be running 9.7.x (or the upcoming 9.8.x) because it supports RFC 5011 trust anchor rollover, among other nice DNSSEC features. | As for whether or not this will be backported to the RELENG_8_1 tag, I | would say probably, but Doug would be authoritative on that. Back-porting it that far is definitely not being considered at the moment, and is unlikely to happen. Looks like I should just suck it up and start using the bind97 port. Thanks. -- Russell A. Jackson r...@csub.edu Network Analyst California State University, Bakersfield ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Performance with hundreds of nullfs mounts?
Ivan Voras wrote: hi, I seem to remember hearing an anecdote somewhere that using hundreds (or thousands?) nullfs mounts for jails results in unreasonably bad file system access performance. Does somebody have this kind of setup / is it true? I was doing this with jails --before we moved to VMware ESX (for better or worse)-- and didn't see any noticeable performance degradation at the time (6.x series). For those interested, the biggest plus for going to the ESX model is that it decoupled low utilization Windows boxes from over-spec'ed hardware and made it available for FreeBSD to use ;-). The downsides are that it's proprietary, it's expensive, it's inefficient (e.g. duplicated files and kernel instances everywhere), and you need freak'in Windows boxes to manage it. -- Russell A. Jackson r...@csub.edu Network Analyst California State University, Bakersfield The first thing I do in the morning is brush my teeth and sharpen my tongue. -- Dorothy Parker signature.asc Description: OpenPGP digital signature
Re: questionable feature- rcvar woes
Frank Behrens wrote: John Baldwin [EMAIL PROTECTED] wrote on 28 Nov 2007 14:37: Use forcestart or forcestop to manage services that are not enabled in rc.conf. This is normal. If you got a warning, then on shutdown every rc.d Most (all?) people recommend in this thread the use of forcestart / forcestop. Is it not better to use onestart / onestop? When I remember right the force ignores any failed preconditions. Regards, Frank Yes. one(start|stop) is far more sensible. -- Russell A. Jackson [EMAIL PROTECTED] Network Analyst California State University, Bakersfield QOTD: Every morning I read the obituaries; if my name's not there, I go to work. smime.p7s Description: S/MIME Cryptographic Signature
Re: update on dell precision 670 vs em death match
On Fri, Nov 10, 2006 at 11:56:21PM -0800, Russell Jackson wrote: Whatever that last em commit was, it seems to have made the interrupt issues better. It still seems high, but it's a lot better than the 2000/s I was getting before. interrupt total rate irq1: atkbd0 54 0 irq6: fdc010 0 irq14: ata0 16 0 irq15: ata1 47 0 irq16: nvidia0+++1095231677 irq18: uhci2+ 3421 2 irq23: ehci0 1 0 irq48: em0115315 71 cpu0: timer 3230219 1997 cpu1: timer 3228221 1996 Total7672535 4744 It appears that I hit upon a fluke. The machine finally hung again after a few days of use, and I found after the hard reset that the interrupt problem was back. So, I'm back to running sans apic for now. Actually, after re-reading all the previous threads again, it doesn't appear that any of the recent fixes to em had anything to do with the shared irq issues anyhow. I'm now left feeling a bit confused, but that may just be due to lack of sleep. -- Russell A. Jackson Network Analyst California State University, Bakersfield ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
update on dell precision 670 vs em death match
Whatever that last em commit was, it seems to have made the interrupt issues better. It still seems high, but it's a lot better than the 2000/s I was getting before. interrupt total rate irq1: atkbd0 54 0 irq6: fdc010 0 irq14: ata0 16 0 irq15: ata1 47 0 irq16: nvidia0+++1095231677 irq18: uhci2+ 3421 2 irq23: ehci0 1 0 irq48: em0115315 71 cpu0: timer 3230219 1997 cpu1: timer 3228221 1996 Total7672535 4744 -- Russell A. Jackson [EMAIL PROTECTED] Network Analyst California State University, Bakersfield ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvidia0 em0 shared irq problem persists on dell precision 670
On Wed, Nov 08, 2006 at 07:39:52PM -0700, Scott Long wrote: Is the firewire controller something that you can disable? Can you selectively disable some of the USB controllers? Scott I've tried disabling every combination of devices possible. The only change that fixed the problem (surprise, surprise) was disabling the integrated em NIC and or the nvidia card. I don't have another PCI express video board to swap with unfortunatly; so, I can't test that route. I should mention that disabling acpi also works, but it appears that SMP won't work without acpi. vmstat -i without apic: interrupt total rate irq0: clk1371151999 irq1: atkbd0 288 0 irq5: ehci01 0 irq6: fdc011 0 irq7: ppc0 6 0 irq8: rtc 175479127 irq9: uhci2 acpi0+ 6204 4 irq11: nvidia0 em*610237444 irq14: ata0 17 0 irq15: ata1 48 0 Total2163442 1576 Oddly, the dmesg output is the same weither or not the apics are enabled or not? 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-PRERELEASE #0: Wed Nov 8 16:01:29 PST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CSERV65.SMP MPTable: DELL WS 670 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.51-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf43 Stepping = 3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2010NX,LM Logical CPUs per core: 2 real memory = 1072209920 (1022 MB) avail memory = 1035890688 (987 MB) pnpbios: Bad PnP BIOS data checksum ioapic0: Changing APIC ID to 8 ioapic0: Assuming intbase of 0 ioapic1: Changing APIC ID to 9 ioapic1: Assuming intbase of 24 ioapic2: Changing APIC ID to 10 ioapic2: Assuming intbase of 48 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard kbd1 at kbdmux0 kqemu version 0x00010300 kqemu: KQEMU installed, max_locked_mem=517120kB. cpu0 on motherboard pcib0: MPTable Host-PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib0: unable to route slot 2 INTA pcib0: unable to route slot 3 INTA pcib0: unable to route slot 4 INTA pci0: unknown at device 0.1 (no driver attached) pcib1: PCI-PCI bridge irq 11 at device 2.0 on pci0 pci1: PCI bus on pcib1 pcib2: MPTable PCI-PCI bridge at device 0.0 on pci1 pci2: PCI bus on pcib2 pcib3: MPTable PCI-PCI bridge at device 0.2 on pci1 pci3: PCI bus on pcib3 em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xdcc0-0xdcff mem 0xdfee-0xdfef irq 48 at device 14.0 on pci3 em0: Ethernet address: 00:13:72:78:b9:e3 pcib4: MPTable PCI-PCI bridge irq 11 at device 3.0 on pci0 pci4: PCI bus on pcib4 pcib5: MPTable PCI-PCI bridge irq 11 at device 4.0 on pci0 pci5: PCI bus on pcib5 nvidia0: Quadro PCI-E Series mem 0xdd00-0xddff,0xc000-0xcfff,0xde00-0xdeff irq 16 at device 0.0 on pci5 nvidia0: [GIANT-LOCKED] uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xff80-0xff9f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xff60-0xff7f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xff20-0xff3f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xffa80800-0xffa80bff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: waiting for BIOS to
Re: nvidia0 em0 shared irq problem persists on dell precision 670
On Wed, Nov 08, 2006 at 09:23:45PM -0500, Chuck Swiger wrote: Russell Jackson wrote: [ ... ] pnpbios: Bad PnP BIOS data checksum Did you notice this? Try reflashing your motherboard to the latest available BIOS revision, doing a load defaults, and then clearing and reseting the ESCD. I reflashed the BIOS (several times in fact), but the checksum message persists. The bios setup program on this machine doesn't seem to have a way to clear the ESCD AFAIK. I'm starting to believe this box is just a typical Dell POS. -- Russell A. Jackson [EMAIL PROTECTED] Network Analyst California State University, Bakersfield ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
nvidia0 em0 shared irq problem persists on dell precision 670
I synced sources today and tested the em changes, and the problem has not gone away for me. nvidia0 and em0 are shown as shared with ioacpi disabled using a device hint. interrupt total rate irq1: atkbd0 60 0 irq6: fdc010 0 irq14: ata0 16 0 irq15: ata1 47 0 irq16: nvidia0+++1267513 2162 irq18: uhci2+ 52688 89 irq23: ehci0 1 0 irq48: em0106712182 cpu0: timer 1167964 1993 cpu1: timer 1165966 1989 Total3760977 6418 When disabling the ioapic, the rate falls to the 600s which is still a tad high no? I was running it with apic disabled as a work around, but I plan on buying another processor for this box soon. Running it with a SMP kernel with hyperthreading seems to allieviate some of the latency caused by the high interrupt rate; however, I did have it hang once today. 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-PRERELEASE #0: Wed Nov 8 16:01:29 PST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CSERV65.SMP ACPI APIC Table: DELL WS 670 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf43 Stepping = 3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2010NX,LM Logical CPUs per core: 2 real memory = 1072209920 (1022 MB) avail memory = 1035874304 (987 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 pnpbios: Bad PnP BIOS data checksum ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard lapic0: Forcing LINT1 to edge trigger kqemu version 0x00010300 kqemu: KQEMU installed, max_locked_mem=517120kB. kbd1 at kbdmux0 acpi0: DELL WS 670 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xdcc0-0xdcff mem 0xdfee-0xdfef irq 48 at device 14.0 on pci3 em0: Ethernet address: 00:13:72:78:b9:e3 pcib4: ACPI PCI-PCI bridge irq 16 at device 3.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0 pci5: ACPI PCI bus on pcib5 nvidia0: Quadro PCI-E Series mem 0xdd00-0xddff,0xc000-0xcfff,0xde00-0xdeff irq 16 at device 0.0 on pci5 nvidia0: [GIANT-LOCKED] uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xff80-0xff9f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xff60-0xff7f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xff20-0xff3f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xffa80800-0xffa80bff irq 23 at
Re: nvidia0 em0 shared irq problem persists on dell precision 670
On Wed, Nov 08, 2006 at 09:23:45PM -0500, Chuck Swiger wrote: Russell Jackson wrote: [ ... ] pnpbios: Bad PnP BIOS data checksum Did you notice this? Try reflashing your motherboard to the latest available BIOS revision, doing a load defaults, and then clearing and reseting the ESCD. The box came from Dell with the latest revision already and there hasn't been a newer one released since. I vaguely remember bringing this up on the list shortly after the 6.1 release only to be told it was harmless. I guess I can try reflashing just to be sure. Thanks, -- Russell A. Jackson Network Analyst California State University, Bakersfield ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvidia0 em0 shared irq problem persists on dell precision 670
On Wed, Nov 08, 2006 at 07:39:52PM -0700, Scott Long wrote: Is the firewire controller something that you can disable? Can you selectively disable some of the USB controllers? Scott I'll have to try that tomorrow at work. I did disable the em NIC in the BIOS setup, and (not surprisingly) the problem went away. -- Russell A. Jackson Network Analyst California State University, Bakersfield ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
On Mon, Oct 23, 2006 at 02:50:44PM -0400, Mikhail Teterin wrote: ? 23 ??? 2006 13:37, Mikhail Teterin ???: We aren't currently speaking about performance, we need to know whether kernel with DEVICE_POLLING option makes NIC work stable. Yes, that seems to be the case... I spoke too soon :-( It took a lot longer this time (without polling), but the network hung again on the box. Everything recovered by itself after I walked over and simply pushed the Shift button on the machine's keyboard... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] I believe we had the same exact experience the other day when a dell pe2850 dropped off the network for two hours in the morning. I wasn't there at the time, but a coworker said that after he touched the keyboard it seemed to come back to life. We decided to move to 6.2-PRERELEASE after that incident to see if would help. So far, we haven't had another incident of that type, but it hasn't been running for more than a few days with the changes. I also have not had the chance to test the recent if_em merge. Just to note, I have the usb controller disabled in the bios due to it causing interrupt problems with the em NIC when I first installed 6.1-RELEASE as others have reported. I haven't tried turning it back on to see if the problem remains. The apic is also enabled (SMP box). I have not tried enabling DEVICE_POLLING. data point: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet xxx.xxx.1.5 netmask 0x broadcast xxx.xxx.255.255 inet xxx.xxx.1.91 netmask 0x broadcast xxx.xxx.1.91 inet xxx.xxx.1.8 netmask 0x broadcast xxx.xxx.1.8 inet xxx.xxx.1.56 netmask 0x broadcast xxx.xxx.1.56 ether 00:13:72:4b:70:e7 media: Ethernet autoselect (1000baseTX full-duplex) status: active em1: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU ether 00:13:72:4b:70:e8 media: Ethernet autoselect status: no carrier lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 interrupt total rate irq1: atkbd01195 0 irq4: sio0 12374 0 irq6: fdc012 0 irq14: ata0 140 0 irq46: amr0 32780148 98 irq64: em0 65465147196 cpu0: timer663314472 1993 cpu1: timer663568256 1994 Total 1425141744 4282 [EMAIL PROTECTED]:0:0: class=0x06 card=0x016d1028 chip=0x35908086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'E752x Server Memory Controller Hub' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:2:0: class=0x060400 card=0x0050 chip=0x35958086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = 'E752x Memory Controller Hub PCI Express Port A0' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:4:0: class=0x060400 card=0x0050 chip=0x35978086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = 'E752x Memory Controller Hub PCI Express Port B0' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:5:0: class=0x060400 card=0x0050 chip=0x35988086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = 'E752x Memory Controller Hub PCI Express Port B1' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:6:0: class=0x060400 card=0x0050 chip=0x35998086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = 'E752x Memory Controller Hub PCI Express Port C0' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:30:0: class=0x060400 card=0x chip=0x244e8086 rev=0xc2 hdr=0x01 vendor = 'Intel Corporation' device = '82801BA/CA/DB/DBL/EB/ER/FB (ICH2/3/4/4/5/5/6), 6300ESB Hub Interface to PCI Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:31:0: class=0x060100 card=0x chip=0x24d08086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) LPC Interface Bridge' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:31:1: class=0x01018a card=0x016d1028 chip=0x24db8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) EIDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0044 chip=0x03308086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' device = '80332 [Dobson] I/O processor A-segment
Re: isc-dhcpd and jails bound to an aliased ip
On Mon, Sep 18, 2006 at 01:08:28PM -0700, Russell Jackson wrote: Attempting to run isc-dhcpd (using USE_SOCKETS) inside a jail bound to an aliased ip does not appear to work. The process never seems to recieve any broadcast traffic; however, it does see unicast traffic as would be expected. I'm not sure how to debug this since one cannot run tcpdump in the jail to see what traffic is getting there obviously. It works fine if I change the jail to bind to the primary ip on the interface. Not surprisingly, it also works fine if I run it outside of a jail using BPF. Changing the broadcast addresses on the aliases does not seem to change anything. It is just that the kernel will not deliver broadcasts to jails on ip aliases as I suspect? Yes, I now I have a zombied jail in the jls listing. There are no processes with a JID of 2 running, and I'm reluctant to reboot the machine because it's in production. If I have to run the jail on the primary ip address, that's okay. I would just prefer to have it running in a seperate jail and still have ssh running on the standard port (less confusing to users). Relevant configuration: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet6 fe80::213:72ff:fe4b:70e7%em0 prefixlen 64 scopeid 0x1 inet 136.168.1.5 netmask 0x broadcast 136.168.255.255 inet 136.168.1.8 netmask 0x broadcast 136.168.1.8 inet 136.168.1.91 netmask 0x broadcast 136.168.1.91 ether 00:13:72:4b:70:e7 media: Ethernet autoselect (1000baseTX full-duplex) status: active # global jail knobs jail_enable=YES jail_list=ns1 netstat jail_set_hostname_allow=NO # ns1 jail jail_ns1_rootdir=/usr/jail/ns1 jail_ns1_hostname=ns1.csub.edu jail_ns1_ip=136.168.1.91 jail_ns1_exec_start=/bin/sh /etc/rc jail_ns1_devfs_enable=YES jail_ns1_mount_enable=YES # netstat jail jail_netstat_rootdir=/usr/jail/netstat jail_netstat_hostname=netstat.csub.edu jail_netstat_ip=136.168.1.8 jail_netstat_exec_start=/bin/sh /etc/rc jail_netstat_devfs_enable=YES jail_netstat_mount_enable=YES JID IP Address Hostname Path 8 136.168.1.91ns1.csub.edu /usr/jail/ns1 4 136.168.1.8 netstat.csub.edu /usr/jail/netstat 2 136.168.1.91ns1.csub.edu /usr/jail/ns1 I should have mentioned I'm running a 6.1-STABLE system built on the 21st of Aug. RELEASE had problems with interrupt storms if I recall correctly. Here's dmesg.boot if it helps any: 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-STABLE #0: Mon Aug 21 00:59:05 PDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NETSTAT ACPI APIC Table: DELL PE BKC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.71-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf43 Stepping = 3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2010NX,LM real memory = 2147221504 (2047 MB) avail memory = 2096189440 (1999 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 7 ioapic1: Changing APIC ID to 8 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 9 ioapic2: WARNING: intbase 64 != expected base 56 ioapic3: Changing APIC ID to 10 ioapic3: WARNING: intbase 96 != expected base 88 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 32-55 on motherboard ioapic2 Version 2.0 irqs 64-87 on motherboard ioapic3 Version 2.0 irqs 96-119 on motherboard acpi0: DELL PE BKC on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 amr0: LSILogic MegaRAID 1.53 mem 0xf80f-0xf80f,0xfeac-0xfeaf irq 46 at device 14.0 on pci2 amr0: delete logical drives supported by controller amr0: LSILogic PERC 4e/Di Firmware 521X, BIOS H430, 256MB RAM pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 4.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 5.0 on pci0 pci5: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 0.0 on pci5 pci6: ACPI PCI bus on pcib6 em0: Intel(R) PRO/1000
isc-dhcpd and jails bound to an aliased ip
Attempting to run isc-dhcpd (using USE_SOCKETS) inside a jail bound to an aliased ip does not appear to work. The process never seems to recieve any broadcast traffic; however, it does see unicast traffic as would be expected. I'm not sure how to debug this since one cannot run tcpdump in the jail to see what traffic is getting there obviously. It works fine if I change the jail to bind to the primary ip on the interface. Not surprisingly, it also works fine if I run it outside of a jail using BPF. Changing the broadcast addresses on the aliases does not seem to change anything. It is just that the kernel will not deliver broadcasts to jails on ip aliases as I suspect? Yes, I now I have a zombied jail in the jls listing. There are no processes with a JID of 2 running, and I'm reluctant to reboot the machine because it's in production. If I have to run the jail on the primary ip address, that's okay. I would just prefer to have it running in a seperate jail and still have ssh running on the standard port (less confusing to users). Relevant configuration: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet6 fe80::213:72ff:fe4b:70e7%em0 prefixlen 64 scopeid 0x1 inet 136.168.1.5 netmask 0x broadcast 136.168.255.255 inet 136.168.1.8 netmask 0x broadcast 136.168.1.8 inet 136.168.1.91 netmask 0x broadcast 136.168.1.91 ether 00:13:72:4b:70:e7 media: Ethernet autoselect (1000baseTX full-duplex) status: active # global jail knobs jail_enable=YES jail_list=ns1 netstat jail_set_hostname_allow=NO # ns1 jail jail_ns1_rootdir=/usr/jail/ns1 jail_ns1_hostname=ns1.csub.edu jail_ns1_ip=136.168.1.91 jail_ns1_exec_start=/bin/sh /etc/rc jail_ns1_devfs_enable=YES jail_ns1_mount_enable=YES # netstat jail jail_netstat_rootdir=/usr/jail/netstat jail_netstat_hostname=netstat.csub.edu jail_netstat_ip=136.168.1.8 jail_netstat_exec_start=/bin/sh /etc/rc jail_netstat_devfs_enable=YES jail_netstat_mount_enable=YES JID IP Address Hostname Path 8 136.168.1.91ns1.csub.edu /usr/jail/ns1 4 136.168.1.8 netstat.csub.edu /usr/jail/netstat 2 136.168.1.91ns1.csub.edu /usr/jail/ns1 Thanks, -- Russell A. Jackson [EMAIL PROTECTED] Network Analyst CSUB Network Services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why is the STABLE branch not so stable anymore?
Jordan Hubbard wrote: Short answer: -stable builds fine. Long answer: It only builds fine if you don't use non-standard build flags like SHARED=symlinks, which some people appear to be using since they're reporting problems. On a completely stock -stable system as of yesterday, I can report: elf make world started on Sun Jun 10 12:28:33 PDT 2001 elf make world completed on Sun Jun 10 13:23:54 PDT 2001 Kernel build for WINSTON started on Sun Jun 10 13:23:54 PDT 2001 Kernel build for WINSTON completed on Sun Jun 10 13:30:25 PDT 2001 So both the world and the kernel build just fine if you don't try to do things your own way right now and if you have a stock -stable source tree without local modifications. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message I have no non-standard build flags; I have no modifications. I just cvsup'ed yet again, and now it errors at pam instead of perl. It seems to be breaking earlier and ealier. cvsup command used: cvsup -P - stable-supfile (the file provided for in the manual) make.conf: CFLAGS=-O -pipe COPTFLAGS=-O -pipe NOPROFILE=true build commands used: script /root/mw.out cd /usr/src make -j4 buildworld exit script /root/mw.out cd /usr/src make buildworld exit current error: === lib/libpam/libpam rm -f a.out pam_account.o pam_auth.o pam_data.o pam_delay.o pam_dispatch.o pam_end.o pam_env.o pam_handlers.o pam_item.o pam_log.o pam_misc.o pam_password.o pam_second.o pam_session.o pam_start.o pam_strerror.o help_env.o misc_conv.o xstrdup.o pam_get_pass.o pam_prompt.o pam_std_option.o pam_static_modules.o pam_account.o.tmp pam_auth.o.tmp pam_data.o.tmp pam_delay.o.tmp pam_dispatch.o.tmp pam_end.o.tmp pam_env.o.tmp pam_handlers.o.tmp pam_item.o.tmp pam_log.o.tmp pam_misc.o.tmp pam_password.o.tmp pam_second.o.tmp pam_session.o.tmp pam_start.o.tmp pam_strerror.o.tmp help_env.o.tmp misc_conv.o.tmp xstrdup.o.tmp pam_get_pass.o.tmp pam_prompt.o.tmp pam_std_option.o.tmp security pam_static.o setdef0.o _pam_static_modules.o setdef1.o setdef0.c setdef1.c setdefs.h pam_authenticate.3.gz pam_chauthtok.3.gz pam_fail_delay.3.gz pam_open_session.3.gz pam_setcred.3.gz pam_start.3.gz pam_strerror.3.gz pam.8.gz pam_authenticate.3.cat.gz pam_chauthtok.3.cat.gz pam_fail_delay.3.cat.gz pam_open_session.3.cat.gz pam_setcred.3.cat.gz pam_start.3.cat.gz pam_strerror.3.cat.gz pam.8.cat.gz rm: security: is a directory *** Error code 1 Stop in /usr/src/lib/libpam/libpam. *** Error code 1 Stop in /usr/src/lib/libpam/libpam. *** Error code 1 Stop in /usr/src/lib/libpam. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Why is the STABLE branch not so stable anymore?
Jordan Hubbard wrote: Hmmm. It seems like this thread has degraded to simple project-bashing so I'll not be a party to keeping it on life support any longer. Suffice it to say that people make mistakes and of far greater importance is whether or not they realize it when they do and correct those mistakes. The pam/ssh suckage was backed out by Mark, with profuse apologies for his mistake, and the rest of the reports we've already covered so I think we can just let that rest. Finally, let's not forget that nobody is FORCING you to run -stable. In fact, users in your category are always recommended to stick with the releases and not upgrade until a new one comes out so I'm not even sure why we're having this conversation in the first place. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message I appologize if I seemed to be bashing the project in some way. That was entirely not the intent of my posts. I simply wish to know why the build is breaking (if for no more reason than to know I'm not an complete idiot). Stable never did this before, and I'm tired of getting the you aren't doing it right answer. I have the upmost respect for the freebsd development team. Sorry again. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
